| 00:26.25 | IriX64 | i'll simply pastebin the symptoms, and if anybody has time, can you comment? |
| 01:07.26 | IriX64 | is opengl support new tobrlcad as of 7.8.4? or has it always been there and im missing it? |
| 02:02.07 | IriX64 | do these tools such as rtedge have a help screen i tried both --help and -h. |
| 03:49.12 | *** join/#brlcad IriX64 (n=mario_du@bas3-sudbury98-1168050142.dsl.bell.ca) | |
| 05:36.08 | brlcad | IriX64: yes, please report the bug in here first .. you should generally only submit formal bug reports for non-custom configurations problems, and preferably issues that are perfectly repeatable |
| 05:36.33 | brlcad | mention the issue in here first.. I'll let you know when/if you should submit a more formal report |
| 05:37.55 | brlcad | that will generally only be something that I'm fairly confident is a prevalent problem .. like mged crashing on certain inputs .. but NOT build problems -- build problems are rarely bug-report-worthy as they're usually configuration issues or temporary |
| 05:39.57 | brlcad | opengl support has been there for over a decade, whether it's compiled in or not depends on how we feel come release-time (I usually try to disable opengl if I can remember to due to a bug on some platforms) .. again.. it provides no NEW functionality -- it's just a different low-level implementation, one of many that all do the same thing -- don't get caught up on the familiar name |
| 05:40.52 | brlcad | help is provided via manual pages, rarely ever -h --help options .. try "brlman rtedge" |
| 06:01.02 | IriX64 | ty understood. |
| 06:01.40 | IriX64 | found help after i opened the database... manual. |
| 06:06.34 | IriX64 | louipc: Did you ever use OS/2, I quite liked it when I ran it many years ago. |
| 06:07.08 | IriX64 | cept for the runaway swap file thing :) |
| 06:09.30 | IriX64 | visit www.spaces.live.com/IriX64 there a picture of it running there. |
| 06:19.53 | IriX64 | That virtual disk is formmated hpfs. |
| 08:19.45 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:53.39 | clock_ | brlcad: is it OK to define a region as (combination - region)? |
| 08:53.56 | clock_ | For example I have a wall and bolts so I define wall as bricks.c - bolts.r |
| 08:54.08 | clock_ | I mean define wall.r as bricks.c - bolts.r |
| 08:54.13 | clock_ | like there are holes drilled for the bolts |
| 11:12.09 | louipc | IriX64: nope never used it |
| 13:07.12 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) | |
| 13:11.00 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/ (6 files in 6 dirs): TCL was moved to src/other/tcl: include path modified |
| 13:18.46 | CIA-7 | BRL-CAD: 03d_rossberg * 10brlcad/src/libbu/brlcad_path.c: bu_basename returns a const: variable type fixed (compiler warning) |
| 14:23.18 | brlcad | hello rossberg |
| 14:23.50 | brlcad | clock_: it can be frowned upon, but no -- it's fine to use a region negatively |
| 14:24.06 | brlcad | it'd be an error to use it positiviely below another region |
| 14:25.52 | *** join/#brlcad Elperion (n=Elperion@p5487747A.dip.t-dialin.net) | |
| 14:33.11 | brlcad | rossberg: interesting inclusion of strlcpy() .. without a doubt wasn't an old System V routine (but as good a place as any to put it), but a curious routine in itself |
| 14:33.35 | rossberg | brlcad: can you compile the current librt/g_brep.cpp? |
| 14:34.15 | rossberg | brlcad: strlcpy can be removed, right? |
| 14:34.33 | brlcad | hm, removed? |
| 14:35.13 | brlcad | rossberg: I can, depends on the platform -- currently know that g_brep fails on irix due to the -msse -msse2 flags but I've got a local fix for that |
| 14:35.40 | brlcad | but it does compile on linux and os x as far as I know at the moment |
| 14:35.55 | brlcad | i had problems compiling it under windows, but hadn't looked into the errors yet |
| 14:37.15 | brlcad | it was easy enough to disable by hand at the time, which was suitable at the time as it's still evolving code |
| 14:37.50 | brlcad | I don't really care if strlcpy stays or is removed.. but I thought you added it? |
| 14:39.51 | rossberg | yes I add it, thats why I'm asking |
| 14:42.09 | rossberg | vector.h, line 42 (the one with friend) looks strange |
| 14:44.50 | brlcad | rossberg: oh, I didn't comment implying to remove strlcpy -- it's fine .. it's just an 'interesting' function is all .. I hadn't seen it in a while |
| 14:45.35 | rossberg | brlcad: however, strlcpy isn't in use any more |
| 14:45.56 | brlcad | which would explain why I haven't seen it in a while :) |
| 14:46.20 | brlcad | iirc, openbsd folks wrote it as a strncpy replacement or somesuch |
| 14:46.34 | ``Erik | brlcad: the dmg of qemu I was talking about yesterday, http://www.kju-app.org/kju/ |
| 14:55.12 | brlcad | impressive |
| 14:55.18 | brlcad | iconic hell, but impressive |
| 14:55.48 | ``Erik | apple+, and fix the top display |
| 14:56.13 | brlcad | Be still fails to detect the cdrom to install.. but I see I have other hardware options to test too |
| 15:02.28 | brlcad | drat, the other PPC hardwares won't even boot from the CD |
| 15:04.32 | brlcad | pretty painless to use though, I like (aside from iconage) |
| 15:05.43 | ``Erik | I haven't figured out clean ways to interface its disk image format, though, I'm not sure if it's a raw disk image or if there's a header or what :/ |
| 15:06.23 | ``Erik | but I only looked for a second *shrug* :) |
| 15:07.30 | brlcad | i don't really care what they do so long as it's easy to get data in/out somehow |
| 15:07.48 | brlcad | the import from virtual pc is interesting |
| 15:08.04 | brlcad | i could use that to import my old images .. |
| 15:09.59 | ``Erik | <-- has script fu to generate raw disk images for his os, not terribly keen on rewriting all that |
| 16:14.47 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/conv/fast4-g.c: (log message trimmed) |
| 16:14.47 | CIA-7 | BRL-CAD: massive restructuring of the code. functions are defined in visibility order so |
| 16:14.47 | CIA-7 | BRL-CAD: declarations are unnecessary, functions are made static so they don't collide |
| 16:14.47 | CIA-7 | BRL-CAD: with librt's similar (but not identical) importFg4Section.c symbols |
| 16:14.47 | CIA-7 | BRL-CAD: (Add_bot_face, do_trid, do_quad, and do_tri functions; grid_pts variable), |
| 16:14.50 | CIA-7 | BRL-CAD: rename aforementioned and others with an f4_ prefix just to entirely avoid the |
| 16:14.52 | CIA-7 | BRL-CAD: naming confusion, reorder macros, defines, static vars, and functions into |
| 16:19.08 | brlcad | er always attempt to build g_brep.c |
| 16:57.07 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: have configure check for the -msee and -msse2 gcc options, provide them together as SSE to the makefiles |
| 17:37.28 | brlcad | IriX64: that was fixed in cvs .. and you should probably message me in here if you want me to notice |
| 17:37.35 | brlcad | unless it's a private matter |
| 17:39.11 | IriX64 | where in cvs brlcad? |
| 17:39.41 | brlcad | http://sf.net/projects/brlcad |
| 17:39.45 | IriX64 | im in rise observer i dont see it. |
| 17:39.48 | brlcad | select the 'code' tab |
| 17:40.11 | brlcad | yep, that's a known problem with the source release |
| 17:40.19 | brlcad | was fixed about six months ago |
| 17:40.32 | IriX64 | ty ill get it from rise slave. |
| 17:41.20 | brlcad | there isn't a splash.h in rise slave |
| 17:41.30 | IriX64 | then where? |
| 17:41.36 | brlcad | ... |
| 17:41.38 | brlcad | it's in cvs |
| 17:41.51 | brlcad | it's ONLY in cvs at the moment at least until the next release |
| 17:42.11 | brlcad | don't fear the cvs .. it's not that hard to work with |
| 17:42.15 | IriX64 | hah goof that i am im in the wrong place :) |
| 17:45.53 | IriX64 | btw any guesstimate as to how soon you'll release 7-10? |
| 17:50.22 | brlcad | hopefully within a few days |
| 17:51.57 | brlcad | when someone keeps asking questions about a header and posts urls to frivolous pastebins, that slows things down :P |
| 17:52.17 | IriX64 | heh ``Erik stop doing that ;) |
| 17:53.43 | IriX64 | wouldn't it be nice if this worked -- CFLAGS='-Wl,-Ai386,-OS=freebsd' ./configure ;) |
| 17:55.27 | IriX64 | it would produce messages such ass gcc -Ai386 linker file not used because linking not done. |
| 17:57.16 | IriX64 | err input file. |
| 17:58.04 | brlcad | yes, such ass |
| 18:02.07 | IriX64 | the whole project:) |
| 18:02.54 | brlcad | smells like teen spirit |
| 18:04.08 | IriX64 | rosewate and honey :) |
| 18:04.13 | IriX64 | rosewater too |
| 18:10.00 | IriX64 | http://www.pastebin.ca/385183 <--- im a slow typist but i envision something like this. |
| 18:10.30 | brlcad | I really don't see what the point of that is? |
| 18:10.41 | IriX64 | cross compiling. |
| 18:10.43 | brlcad | those are just error messages |
| 18:10.57 | IriX64 | warnings. |
| 18:11.31 | brlcad | right .. but still a "mistake" nonethelss |
| 18:11.34 | IriX64 | on the link pass there would be no such warning. |
| 18:11.43 | brlcad | you're specifying linker flags to the compiler |
| 18:11.51 | brlcad | when they should just be specified to the linker |
| 18:11.56 | IriX64 | passing them on to the linker. |
| 18:12.09 | brlcad | make them LDFLAGS instead |
| 18:12.18 | IriX64 | can use either. |
| 18:12.40 | brlcad | you "can", but one is erroneous.. hence all the 'warnings' |
| 18:12.50 | IriX64 | errr true. |
| 18:13.02 | IriX64 | but the point is gcc doen't crash. |
| 18:13.15 | IriX64 | have to support -Wl |
| 18:14.48 | brlcad | a lot of things don't crash gcc .. that was the point? |
| 18:15.04 | IriX64 | compatibility. |
| 18:15.20 | IriX64 | so you can take anybodys project and go. |
| 18:15.39 | brlcad | go where? |
| 18:16.16 | IriX64 | hopefully what you're trying to compile and link for :) |
| 18:16.46 | brlcad | why not just compile and link there? |
| 18:17.31 | IriX64 | its fraught ;) |
| 19:13.43 | IriX64 | fraught with danger... there's just no arguing with a word like fraught... go see the movie. :) |
| 19:14.05 | IriX64 | pooh's heffalump movie. |
| 19:17.11 | IriX64 | http://www.pastebin.ca/385269 issues remain sigh. |
| 19:19.53 | ``Erik | uhhhh, yeah, uh, that'd be expected |
| 19:20.11 | ``Erik | if you run "file.o", it'll tell you it's a PE file |
| 19:20.14 | ``Erik | er |
| 19:20.18 | ``Erik | "file pret.o" |
| 19:20.34 | ``Erik | just because you ASK it to compile another format does NOT make it a cross-compiler or cross-linker |
| 19:20.58 | IriX64 | man pret.o is an object file cannot run it. |
| 19:21.08 | ``Erik | uh huh... but it's a PE object file |
| 19:21.11 | ``Erik | not an ELF object file |
| 19:21.25 | ``Erik | you have the command "file.exe", right? seriously, use it... a lot... |
| 19:21.36 | IriX64 | ty |
| 19:23.27 | IriX64 | the entry point of any executable examines system you're running on and says " i am an OS/2 pm app" for instance. |
| 19:24.04 | IriX64 | but it will *always run on *my system. |
| 19:24.16 | IriX64 | because i like to test the code too. |
| 19:24.26 | IriX64 | meaning the project i compiled. |
| 19:24.40 | IriX64 | _main __main. |
| 19:24.56 | IriX64 | my pret.exe is 44k. |
| 19:25.13 | IriX64 | and its just a hello world program. |
| 19:25.36 | ``Erik | actually, the system examines the first couple of bytes of an application you ask to run (the "file magic", what file.exe shows you a human version), if it's something the kernel binfmt stuff groks, it'll extract the entry point. |
| 19:26.06 | IriX64 | so its doable? |
| 19:26.08 | ``Erik | "main" means nothing to PE, ELF, QMAGIC, MZ, ... it's actually a stub for libc to cope with |
| 19:26.09 | ``Erik | no |
| 19:26.33 | ``Erik | because the second you try to bind a library or make a system call, it'll be confused. |
| 19:27.08 | IriX64 | how there are effectivly 2 exe's in there. |
| 19:27.30 | ``Erik | take, for example, printing something at a kernel level... using the write(2) function (syscall)... on your machine, you'll move things into registers, then call interrupt 0x80 |
| 19:27.54 | IriX64 | interrupt 80? |
| 19:27.56 | ``Erik | sorry, interrupt 0x21... windows/dos uses int 0x21 |
| 19:28.06 | ``Erik | linux will move things into registers and call interrupt 0x80 |
| 19:28.19 | ``Erik | x86 bsd will move things onto the stack and call interrupt 0x80 |
| 19:28.26 | ``Erik | they all talk very differently |
| 19:28.27 | IriX64 | the linux code is part of the file ``Erik, itll be right. |
| 19:29.03 | IriX64 | windows+linux you run the one for *target system unless running on mine. |
| 19:29.19 | IriX64 | i screwed up and put my machine first. |
| 19:29.33 | IriX64 | should have put target first but ... |
| 19:30.20 | ``Erik | unless your kernel binary format reader understands the format your file is, it should just stop and say "I don't know this". If it DOES know what format it is, it can either ATTEMPT to work with it, or say it isn't doable. |
| 19:30.37 | IriX64 | agreed. |
| 19:30.39 | ``Erik | if I try to run a mac ELF binary on my x86 fbsd machine, it'll say "wrong ISA, go away" |
| 19:30.52 | ``Erik | if I try to run my fbsd ELF binary on my windows machinee, it'll say "uh? not even gonna try" |
| 19:30.55 | ``Erik | and visa versa |
| 19:31.43 | IriX64 | well if you get some of my stuff, let me know if it says cannot execute binary file :) |
| 19:31.49 | *** join/#brlcad Elperion (n=Elperion@p5487747A.dip.t-dialin.net) | |
| 19:32.14 | ``Erik | you can see it for yourself... use the "file.exe" program to tell you what your file is |
| 19:32.37 | IriX64 | but if systems play by the rules, I still maintain its doable |
| 19:32.49 | ``Erik | on my 'workhorse' machine, file tells me this: mged: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped |
| 19:33.12 | ``Erik | and my desktop says: mged: Mach-O executable ppc |
| 19:33.33 | IriX64 | the object file is a MS Windows COFF intel 80386 object file. |
| 19:35.17 | ``Erik | ok, so it's a COFF/PE x86 windows binary... the only systems I know of that will use those files are: windows, the "wine" abi translator, and uhhh, what's the name of it... skyos? |
| 19:35.38 | ``Erik | OS/2 used a COFF variant, but was 16b only, I think :/ |
| 19:36.03 | ``Erik | not skyos, reactos, my bad |
| 19:36.24 | ``Erik | http://www.reactos.org/en/index.html |
| 19:37.52 | IriX64 | gonna go hunt up *your file command, mine sucks... bbiab. |
| 19:40.52 | ``Erik | $ file.exe /bin/ls.exe |
| 19:40.54 | ``Erik | /bin/ls.exe: MS Windows PE 32-bit Intel 80386 console executable not relocatable |
| 19:51.26 | brlcad | you'd think after doing this for the third or fourth time over the years, woulda scripted something better by now |
| 19:53.12 | brlcad | 10 change libadd 20 change configure.ac 30 compile 40 change ldadd 50 observe error 60 goto 30 400 times |
| 19:53.44 | ``Erik | you'da thunk |
| 19:53.45 | ``Erik | t |
| 19:53.47 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/other/ (tcl/Makefile.am tk/Makefile.am): include makefile defs, for "depends" target |
| 19:55.18 | ``Erik | all praise buckethead!!! |
| 19:55.18 | brlcad | ack |
| 19:55.28 | brlcad | if you include makefile defs, it'll recurse into unix dir and fail build on a make fast |
| 19:55.49 | ``Erik | eck |
| 19:55.56 | brlcad | that's why those stub rules are there, to halt the recursion |
| 19:56.41 | *** join/#brlcad Elperion (n=Elperion@p5487747A.dip.t-dialin.net) | |
| 19:57.22 | ``Erik | bett4r? |
| 19:57.44 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/other/ (tcl/Makefile.am tk/Makefile.am): change depends to depend on all-am to avoid recursive issue |
| 19:58.22 | brlcad | should do the trick |
| 19:59.10 | brlcad | yay, finally on proc-db .. almost done |
| 20:02.18 | brlcad | what sucks nuts is that will probably want/need to do this all over again down the road.. the whole library listing woes stem from having some platforms needing libs to decl and others not wanting .. keeping track at link time that librt implies needing RT, BN, BU, and SYSV on the ldadd for example |
| 20:03.08 | brlcad | *always* .. so you either put that in the lib as a libadd (which now causes woes with static libs and tcl/tk since they're static) or you list during ldadd |
| 20:03.57 | brlcad | anyhow.. this will probably work just fine for now until we hit platform that requires the libs to be decl'd (aix I think) |
| 20:04.12 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libtclcad/Makefile.am: change dependancy to libfb, SHOULD snarf in tcl if necessary via libbu |
| 20:04.17 | ``Erik | hrmph |
| 20:07.00 | brlcad | with the new layout, that won't necessarily be true any longer -- basically condensing the libadd's down to nothing and pushing the decl's to the link line |
| 20:08.12 | brlcad | e.g. in my version here, libtclcad is only got tclstub left and that would have to be pushed down if anything needed to actually use the stubs interface in app code |
| 20:24.18 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/ (proc-db/apply-mdb.c lgt/apply-mdb.c): apply-mdb.c is not a procedural database, doesn't belong in proc_db. moved from src/proc_db to src/lgt/. |
| 20:24.54 | brlcad | going to be broken for a couple minutes for that last commit, the makefiles contain too many other changes |
| 20:38.37 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/lgt/apply-mdb.c: on second thought, just declare the code obsolete. mat_Open_Db() and friends are nowhere to be found, not worth the effort to find for this simple snippet. |
| 21:18.26 | CIA-7 | BRL-CAD: 03brlcad * 10brlcad/src/proc-db/nmgxplode.c: all the rukus about nmgxplode not compiling .. yet the program doesn't do a damn thing. looks like the start of something that was never even fully started. delete the damn turd. |
| 21:22.47 | ``Erik | heh |
| 21:47.42 | Maloeran | Ahah, neat |
| 22:02.49 | brlcad | cheese? |
| 22:02.58 | CIA-7 | BRL-CAD: 03erikgreenwald * 10brlcad/src/librt/g_metaball.c: reorder things in the record to keep like types together (breaks binary compatability with previous metaball primitives) |
| 22:03.17 | ``Erik | something like that |
| 22:13.33 | ``Erik | now that's interesting |
| 22:28.31 | *** join/#brlcad PrezKennedy (n=Matthew@c-69-138-68-160.hsd1.md.comcast.net) | |
| 22:29.53 | ``Erik | heh, I've never seen programs die from x=malloc(100);x[0]=0;free(x); (while working fine everywhere else) |
| 22:33.54 | ``Erik | ahhhhhh, suddenly a lot more makes sense. heh. edsol is one skeery beast |
| 22:34.56 | brlcad | ``Erik: fyi, bu_malloc and friends are guaranteed to never return NULL so you never have to error check the condition |
| 22:37.49 | Maloeran | ``Erik, under what circumstances? |
| 22:38.37 | Maloeran | The memory returned by malloc() will always be valid. If Linux really is out of memory, it will kill processes, perhaps yours, but the memory will still be valid |
| 22:42.40 | brlcad | Maloeran: that's a rather unrelated statement regarding malloc() .. and behavior specific to linux, not posix |
| 22:43.58 | Maloeran | Yes, it's highly specific to Linux. I'm guessing Erik's stabbing of Tux was related to his malloc() complain |
| 22:43.59 | brlcad | malloc() could just as readily return NULL (and readily will under plenty of situations) even under linux |
| 22:44.06 | brlcad | ahh |
| 22:45.18 | brlcad | he just makes up excuses to jab at stuff like that ;) |
| 22:46.22 | brlcad | my comment was regarding to the commit he made just a little bit ago.. had a bu_malloc() return value checking null.. which it will never be in brl-cad |
| 23:30.12 | ``Erik | I was grousing about an internal crash in free(), actually, int_free() I think? I believe I may've been a little loose around the boundries O:-) |
| 23:39.24 | IriX64 | anybody need a stock gcc for winblows? |
| 23:39.45 | IriX64 | needs cygwin1.dll tho and a couple of others. |
| 23:40.15 | Maloeran | Hrm, people can just download mingw or cygwin for that? |
| 23:40.31 | IriX64 | sure. |
| 23:41.03 | IriX64 | 4.12 neat. |
| 23:41.27 | Maloeran | And due to the nature of windows "security", you'll never find anyone accepting a binary executable for that platform |
| 23:47.09 | IriX64 | haha just playing around, not intented to be serious. |
| 23:47.29 | IriX64 | right now it compiles but i cant find the executable, go figure. |
| 23:56.15 | IriX64 | http://www.pastebin.ca/385641 <---- have a peek :) |