| 00:00.10 | brlcad | in trunk, just undetected |
| 00:19.08 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 00:19.32 | louipc | oh? so the currently hosted 7.14.2 is no good? |
| 00:37.37 | brlcad | depends what you need it for |
| 00:37.42 | brlcad | mged has a variety of problems |
| 00:38.06 | louipc | ah I think you mentioned mged -c works ok though? |
| 00:38.21 | brlcad | yep |
| 00:38.28 | louipc | cool ;) |
| 00:56.43 | Dr_Phreakenstein | do you guys want build testing on 33740? |
| 01:00.36 | mafm | night |
| 01:07.04 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 01:14.07 | brlcad | Dr_Phreakenstein: 33740 is what? |
| 01:15.33 | brlcad | otherwise, sure .. build testing on varied platforms is always good .. especially if you can help fix problems and not just report them ;) |
| 01:31.39 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) | |
| 01:51.24 | Dr_Phreakenstein | well, I do what I can... |
| 01:52.59 | Dr_Phreakenstein | that is the subversion revision |
| 01:54.19 | Dr_Phreakenstein | build and test ok on gentoo, amd64, kernel 2.6.28, gcc 4.3.3 |
| 02:28.28 | brlcad | cool |
| 02:29.16 | Dr_Phreakenstein | benchmark is good, too |
| 02:30.08 | Dr_Phreakenstein | tries to figure out how to cram more processors into box. wants to ace benchmark |
| 03:04.44 | starseeker | loves bugs that make his X11 session go wonky |
| 03:05.55 | Dr_Phreakenstein | that is the advantage of having another machine that I can use to ssh in and restart X |
| 03:06.04 | Dr_Phreakenstein | too bad that machine broke |
| 03:06.31 | starseeker | brlcad: I lost input when running mged in gdb, but the error reported had to do with string comparison immediately after I selected a .g file in the dialog |
| 03:08.01 | starseeker | happens with or without a db open |
| 03:09.41 | Dr_Phreakenstein | starseeker: are you running recent X? |
| 03:09.44 | Dr_Phreakenstein | kde? |
| 03:20.29 | Dr_Phreakenstein | I have the same problem, I believe it is either new X input evdev/keyboard, and/or their interaction with kde. I did some upgrades of xorg, gcc, glibc, binutils, and kde 4.2 about the same time. for some reason, certain bugs in other programs cause this, but the same bugs caused no such instability before. Also, I seem to have lost keyboard for no apparent reason a few times, and regained it once. iow, may not be an mged thing |
| 03:21.15 | Dr_Phreakenstein | where was the string comparison happening? |
| 03:28.22 | Dr_Phreakenstein | starseeker: I would like to help if I could, gotta restart (bad nvidia driver ...grr) |
| 03:46.27 | starseeker | Dr_Phreakenstein: No, no kde |
| 03:46.34 | starseeker | this is very probably mged |
| 03:47.40 | starseeker | oh |
| 03:48.32 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) | |
| 03:48.37 | starseeker | Dr_Phreakenstein: No, no kde |
| 03:48.46 | starseeker | it's almost certainly an mged issue |
| 03:49.52 | Dr_Phreakenstein | perhaps so, but like I said, I started having the same problems right around upgrade time, I believe before kde upgrade, but after xorg, glibc/gcc |
| 03:56.36 | *** join/#brlcad Axman6_ (n=Axman6@pdpc/supporter/student/Axman6) | |
| 04:00.41 | starseeker | grrrrr |
| 04:08.47 | starseeker | man - how do I debug something like this? |
| 04:09.38 | Dr_Phreakenstein | tell me how you got there, and I will try to help in whatever way i can |
| 04:09.57 | brlcad | Dr_Phreakenstein: you'll have a hard time getting an "ace" benchmark ... :) |
| 04:10.14 | starseeker | open mged 7.14.2 or latest svn, File->Open and select a file |
| 04:10.16 | Dr_Phreakenstein | :) |
| 04:10.46 | brlcad | I think current leader is somewhere on the order of 42 million VGRs (projected) iirc |
| 04:10.59 | starseeker | wow |
| 04:11.15 | brlcad | or 12 million, there was a two and it was more than 10 :) |
| 04:11.38 | brlcad | and that was about 2 years ago |
| 04:12.42 | Dr_Phreakenstein | well, i can dream, no? |
| 04:12.54 | brlcad | it is impressive that a deskside workstation SMP is about to eclipse the previous SMP leader (512 CPU Origin 2000) |
| 04:13.22 | brlcad | probably in two years |
| 04:14.13 | Dr_Phreakenstein | well, my machine is 2 years old, and I have 2.4 gHz proc, could put 3 gHz in |
| 04:14.29 | Dr_Phreakenstein | att, price dictated 2.4 |
| 04:14.59 | Dr_Phreakenstein | starseeker: I crash before I can load anything |
| 04:15.32 | Dr_Phreakenstein | however, I can open it with a db (have not tried actually using said db... standby) |
| 04:15.47 | brlcad | Dr_Phreakenstein: what's your vgr count? |
| 04:20.04 | brlcad | starseeker: best bet is either putting a break in the main event loop in mged (in mged.c iirc) or resorting to old-skool print statements |
| 04:20.26 | brlcad | if you run mged in gdb via a remote session, you should be able to control it without killing X |
| 04:21.48 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) | |
| 04:27.23 | Dr_Phreakenstein | ok, I can start with open db, then go to open another, get segfault. investigating. did not lose X, although (unrelated) transparency is missing. 3d window was flakey. gotta look at my end |
| 04:27.57 | brlcad | open db via menu or via opendb command? |
| 04:31.38 | Dr_Phreakenstein | menu |
| 04:33.38 | Dr_Phreakenstein | vgr 13884 |
| 04:33.46 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) | |
| 04:37.21 | Dr_Phreakenstein | considering only 4 cores, not too bad |
| 04:37.31 | Dr_Phreakenstein | as opposed to 512 |
| 04:37.42 | brlcad | yep, not too shabby |
| 04:39.15 | Dr_Phreakenstein | not braggin, just proud, considering i am poor |
| 04:39.47 | Dr_Phreakenstein | that having been said, i am happy to donate cpu time and shell access to deserving persons |
| 04:40.55 | brlcad | 13k vaxen is pretty substantial ;) |
| 04:41.04 | Dr_Phreakenstein | true |
| 04:41.27 | Dr_Phreakenstein | offer still stands |
| 04:41.59 | brlcad | i'm good for now, but thanks :) |
| 04:42.31 | Dr_Phreakenstein | will advise of beowolf completion |
| 04:42.33 | Dr_Phreakenstein | ;) |
| 04:47.09 | yukonbob | evening, cadheads |
| 04:47.51 | Dr_Phreakenstein | evening, yukonbob |
| 04:53.13 | *** join/#brlcad madant (n=madant@117.196.138.246) | |
| 04:58.46 | Dr_Phreakenstein | is restarting X. again |
| 05:04.09 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) | |
| 05:04.54 | Dr_Phreakenstein | looks like i fixed opengl, trying mged again |
| 05:07.31 | *** join/#brlcad PrezKennedyJR (i=Matthew@whitecalf.net) | |
| 05:09.19 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) [NETSPLIT VICTIM] | |
| 05:18.43 | Dr_Phreakenstein | ok, starseeker, |
| 05:19.07 | Dr_Phreakenstein | I may have something more helpful |
| 05:20.23 | Dr_Phreakenstein | i now have opengl working right, so when i get the above crash, my screen blanks (like going from fullscreen gl) |
| 05:20.50 | Dr_Phreakenstein | i then return to konsole, which reports segfault |
| 05:21.28 | Dr_Phreakenstein | which tells me that crash is mged, |
| 05:22.12 | Dr_Phreakenstein | but locking X is opengl, video driver, or other opengl apps fighting over it |
| 05:22.32 | Dr_Phreakenstein | looking at crash now to find it |
| 05:23.21 | *** join/#brlcad madant (n=madant@117.196.138.246) [NETSPLIT VICTIM] | |
| 05:23.21 | *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron) [NETSPLIT VICTIM] | |
| 05:23.21 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT VICTIM] | |
| 05:33.35 | Dr_Phreakenstein | d-lo, hello |
| 05:35.20 | Dr_Phreakenstein | 4 starseeker: have you found the bug yet? |
| 05:35.28 | louipc | whoazers |
| 05:35.45 | Dr_Phreakenstein | hey, just learning from <brlcad> |
| 05:36.08 | Dr_Phreakenstein | kinda grabs ya |
| 05:37.52 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 05:38.40 | Dr_Phreakenstein | if not, it seems to be line 249 of vls.c |
| 05:41.21 | Dr_Phreakenstein | wait, that is where it complained, however, the bad pointer seems to be bu_vls |
| 05:41.43 | Dr_Phreakenstein | said it was "Zero_Magic_Number" |
| 05:42.23 | Dr_Phreakenstein | whatever that means |
| 05:45.46 | Dr_Phreakenstein | if you send me an email addr, or send mail to phreak@110mail.com, I will send strace outputs |
| 05:53.46 | starseeker | Dr_Phreakenstein: just use pastebin: http://pastebin.bzflag.bz/ |
| 05:54.34 | starseeker | a complaint at the vls level is almost always due to problems with string handling further up the chain |
| 05:56.22 | brlcad | Dr_Phreakenstein: Zero_Magic_Number means it's a string that hasn't been initialized |
| 05:56.41 | brlcad | sounds exactly like the other bug I fixed earlier today too |
| 05:56.54 | brlcad | something missing a bu_vls_init() |
| 05:57.23 | starseeker | it seems to be before f_opendb... hmmm... |
| 05:57.40 | starseeker | looks at db_Open in tcl land... |
| 05:59.10 | brlcad | if you have a trace, you'll at least have the place where the vls is being called |
| 05:59.15 | brlcad | it's usually obvious from there |
| 05:59.24 | starseeker | wants the trace :-) |
| 05:59.28 | starseeker | I can't generate one here |
| 05:59.41 | brlcad | starseeker: if we do gsoc again, you interested in mentoring? |
| 05:59.47 | starseeker | brlcad: sure |
| 05:59.53 | brlcad | k |
| 05:59.57 | brlcad | all still tbd |
| 06:00.01 | starseeker | np |
| 06:00.51 | brlcad | last years didn't get as much attention as it deserved so probably would only accept a couple students at most IFF even accepted |
| 06:01.07 | starseeker | right |
| 06:01.08 | brlcad | you have a link to your panoramas? |
| 06:01.31 | starseeker | I don't think they're online - I can put one up on bz |
| 06:01.33 | starseeker | one sec |
| 06:01.41 | starseeker | (cat, shut up!) |
| 06:02.11 | starseeker | ah, it is up |
| 06:02.31 | brlcad | you had a couple iirc |
| 06:02.35 | brlcad | the interior and the exterior |
| 06:02.54 | starseeker | interior was a panorama |
| 06:03.00 | starseeker | exterior just a side shot |
| 06:03.11 | brlcad | still stitched using panotools, though, right? |
| 06:03.21 | starseeker | no, that was a full shot |
| 06:03.39 | brlcad | ah, okay |
| 06:03.40 | starseeker | I did some flat scans with panotools, but the side shots aren't practical |
| 06:04.29 | starseeker | well, this is one but it's 25 megs: http://bzflag.bz/~starseeker/pano_1.jpg |
| 06:05.05 | Dr_Phreakenstein | working on it... |
| 06:05.16 | Dr_Phreakenstein | too big to select and put into paste bin |
| 06:05.25 | Dr_Phreakenstein | can i get an email? |
| 06:05.45 | brlcad | too big for paste bin? |
| 06:05.54 | brlcad | the limit on that is like 25 MB |
| 06:06.50 | brlcad | stack trace shouldn't be more than a few dozen lines |
| 06:08.52 | Dr_Phreakenstein | 3971 lines for one |
| 06:08.58 | Dr_Phreakenstein | otu of 3 |
| 06:09.04 | Dr_Phreakenstein | out |
| 06:10.28 | starseeker | brlcad: here's one with managable size: http://bzflag.bz/~starseeker/tank_interior.jpg |
| 06:11.52 | Ralith | starseeker: you call that manageable? |
| 06:11.59 | Ralith | :P |
| 06:13.19 | Dr_Phreakenstein | perhaps by comparison... |
| 06:15.56 | starseeker | Ralith: well, there's the 25 meg version... |
| 06:16.10 | Ralith | fine, fine |
| 06:16.12 | starseeker | Dr_Phreakenstein: It looks like it was trying to read your .mgedrc |
| 06:16.17 | Ralith | how's that model doing, anyway? |
| 06:16.30 | starseeker | haven't had time to work on it yet |
| 06:17.06 | Ralith | aw. |
| 06:17.33 | Dr_Phreakenstein | I have .mgedrc |
| 06:18.45 | starseeker | brlcad: I'm going to paste a subset of this to pastebin |
| 06:19.21 | Dr_Phreakenstein | want to see .mgedrc, too? |
| 06:19.37 | starseeker | maybe - let's see what brlcad makes of this |
| 06:19.41 | Dr_Phreakenstein | (only 507 lines) |
| 06:20.08 | Dr_Phreakenstein | hope that info dump helps at all |
| 06:20.20 | starseeker | http://pastebin.bzflag.bz/m67aab374 |
| 06:20.42 | brlcad | starseeker: and to clarify .. you used the panotools and not hugin, yes? |
| 06:20.47 | brlcad | hugin being http://hugin.sourceforge.net/ |
| 06:20.53 | starseeker | I used hugin |
| 06:21.02 | starseeker | thought it was built on panotools? |
| 06:21.09 | brlcad | ah, okay -- glad I asked then |
| 06:21.16 | starseeker | is that bad? |
| 06:21.37 | brlcad | it's based on them and somewhat built on them, but a slightly different approach |
| 06:21.41 | brlcad | no, not bad |
| 06:21.46 | brlcad | even better |
| 06:22.46 | Dr_Phreakenstein | emerges hugin |
| 06:23.07 | starseeker | Dr_Phreakenstein: what's the last line in your mgedrc file? |
| 06:25.36 | starseeker | hmm - that trace contains the complete mgedrc file, then something goes bad on a write |
| 06:26.00 | starseeker | what the heck... |
| 06:26.17 | starseeker | MUST sleep - got meeting tomorrow |
| 06:26.27 | starseeker | will sleep on it - thanks Dr_Phreakenstein |
| 06:26.27 | Dr_Phreakenstein | the strace command cut off everything after 4096 bytes |
| 06:26.45 | Dr_Phreakenstein | i can rerun with larger cutoff, if desired |
| 06:27.21 | Dr_Phreakenstein | let me know if i can be of any further assistance. during day, send me mail, as i do not always read full backlog |
| 06:27.28 | starseeker | not sure if that will help - can you get it to run inside gdb and then do bt? |
| 06:27.46 | starseeker | k - thanks! |
| 06:27.46 | Dr_Phreakenstein | bt? |
| 06:27.51 | starseeker | backtrace |
| 06:28.06 | starseeker | it's what I would have done had I not lost all X11 input |
| 06:28.20 | Dr_Phreakenstein | will try, and email to you... do not wait up, but i should have by morning |
| 06:28.28 | Dr_Phreakenstein | sorry about that |
| 06:28.31 | starseeker | np |
| 06:28.33 | starseeker | thank you! |
| 06:28.39 | starseeker | zzzzz |
| 06:28.43 | Dr_Phreakenstein | later |
| 07:07.19 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-230-146.dclient.hispeed.ch) | |
| 07:15.03 | CIA-40 | BRL-CAD: 03brlcad * r33741 10/brlcad/trunk/NEWS: bob did this for 7.14.2, but it didn't make the notes. he filled out the nearly empty usage message and added a specific help message if you don't have a material file set up. |
| 07:20.46 | CIA-40 | BRL-CAD: 03brlcad * r33742 10/brlcad/trunk/NEWS: |
| 07:20.46 | CIA-40 | BRL-CAD: typo in 7.14.2 notes that didn't get caught. original message was (added a |
| 07:20.46 | CIA-40 | BRL-CAD: rough cut at an evolutionary capability to g_diff. This attempts to guess if a |
| 07:20.46 | CIA-40 | BRL-CAD: change to a region was a natural evolution or if the region was reworked in some |
| 07:20.46 | CIA-40 | BRL-CAD: significant fashion. Requested by lbutler.) |
| 07:24.59 | CIA-40 | BRL-CAD: 03brlcad * r33743 10/brlcad/trunk/NEWS: |
| 07:25.00 | CIA-40 | BRL-CAD: another 7.14.2 fix that wasn't documented (blasted e-mail backlog), bob fixed |
| 07:25.00 | CIA-40 | BRL-CAD: mged's font preferences panel/window that was preventing the menu from |
| 07:25.00 | CIA-40 | BRL-CAD: displaying if there was a .mgedrc file present. init wasn't getting called |
| 07:25.00 | CIA-40 | BRL-CAD: causing badness. |
| 07:40.32 | CIA-40 | BRL-CAD: 03brlcad * r33744 10/brlcad/trunk/NEWS: minor but user-visible, john fixed a bug in the oed command documentation to note that the path must be drawn in order to be edited. fixes sf bug 2533174 (problems with oed command) reported by lbutler on 2009-01-24. |
| 07:41.05 | brlcad | at least that one was consciously left out |
| 07:41.16 | brlcad | just better to put it in hindsight to be consistent |
| 07:54.12 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 08:07.55 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 08:25.47 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) | |
| 08:34.03 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 08:45.09 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) | |
| 08:51.33 | *** part/#brlcad piksi (n=piksi@pi-xi.net) | |
| 09:15.11 | *** join/#brlcad mafm (n=mafm@65.Red-81-34-125.dynamicIP.rima-tde.net) | |
| 09:51.06 | *** join/#brlcad brlquestions (n=user@167.Red-79-145-179.dynamicIP.rima-tde.net) | |
| 09:51.25 | brlquestions | Hi everybody ! |
| 11:16.24 | *** join/#brlcad mafm (n=mafm@28.Red-81-34-125.dynamicIP.rima-tde.net) | |
| 11:31.06 | *** join/#brlcad andrecastelo (n=chatzill@189.71.4.20) | |
| 11:49.53 | d-lo | Morning all! |
| 12:11.03 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 12:21.57 | brlcad | grumble |
| 12:22.14 | d-lo | grumble? Not enough sleep? |
| 12:23.06 | Axman6 | not enough love |
| 12:23.09 | Axman6 | hugs brlcad |
| 12:23.33 | brlcad | always too much and it's just that unproductive sinkholecesspool part of the day |
| 12:24.00 | brlcad | yawns and rubs and scratches |
| 12:25.13 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 12:45.57 | d-lo | brlcad: so is it more server work today? |
| 12:51.13 | brlcad | actually, in meeting till after lunch |
| 12:51.23 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 12:52.17 | brlcad | yesterday was a great day, though, particularly the afternoon progress |
| 12:52.45 | d-lo | I think I overheard you say the Raid array was back up? |
| 13:03.09 | *** join/#brlcad madant (n=madant@117.196.134.51) | |
| 13:43.06 | d-lo | brlcad: in libpkg, does one have to utilize the callback table for the recv() and 'pkg_type' for the send()? |
| 14:15.56 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) | |
| 14:18.10 | brlcad | d-lo: I'll have to take another look in depth later today but my recollection is vaguely that it does need the callback table to switch on events |
| 14:18.39 | brlcad | quite possible that it doesn't though, that's really vague and biased by use |
| 14:19.33 | brlcad | that said, it's possible to mod libpkg as well so long as the underlying transport and parceling isn't changed (it's massively tested/robust) |
| 14:19.53 | brlcad | there is one mod that the API does need that's been on the todo, to add callback parameters |
| 14:20.14 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) | |
| 14:20.15 | d-lo | brlcad: Been in the code for a while now, and it looks like its needed. I am finding difficult to wire it in to an OO setting :/ |
| 14:20.45 | brlcad | right now it relies on a global or static data containers |
| 14:22.45 | brlcad | being OO doesn't change anything, at least doesn't make for a limiting constraint |
| 14:23.04 | brlcad | any OO design is deconstructable to a fully procedural one |
| 14:23.26 | brlcad | not that we want to, but just saying that shouldn't be the issue |
| 14:24.25 | d-lo | heh, shouldn't" ...nice :P |
| 14:25.11 | brlcad | okay, I could say that isn't the issue, but trying not to be too blunt :) |
| 14:26.38 | brlcad | being "OO" isn't a problem, being async maybe or being multithreaded maybe or wanting multiplexing maybe or wanting non-global data containers maybe, etc. |
| 14:27.27 | brlcad | it's a very simple (yet *very* robust) parcel transport layer |
| 14:28.06 | brlcad | it's been hooked into OO before though, too, related to the java OO wrapping I sent you last year |
| 14:30.44 | d-lo | Hrm, I don't remember that java wrapping stuff.... only jbrlcad. |
| 14:36.26 | d-lo | needs an easychair @ work.... |
| 14:38.52 | brlcad | yeah, it was one of the very first code chunks when you started on the project |
| 14:39.11 | d-lo | Hrm, can't find that email. Where does it live elsewhere? |
| 14:39.31 | brlcad | i'd have to dig around for it again |
| 14:40.11 | d-lo | No worries. Gonna work up a test. I *think* libpkg should work without callbacks. |
| 14:40.41 | brlcad | it's simple enough because it leaves you with the raw socket |
| 14:41.02 | brlcad | so i'm sure you could make something callbackless |
| 14:41.38 | brlcad | it's just whether you can do that and still go through the bit of code in pkg that has the various state recoveries and error handling |
| 14:41.52 | d-lo | Well, I am going to try to rework the network api since libpkg already has 2/3 similar header elements... no need for redundant redundancy. |
| 14:42.14 | brlcad | simple is better |
| 14:43.27 | d-lo | I am thinking that pkg_process() won't be a problem. It calls pkg_dispatch() which just so happens to preform a null check on the callback table and returns gracefully. |
| 14:46.03 | d-lo | heh, damn. pkg_dispatch() wipes the pkg_conn's buffer before returning... there goes that idea lol. |
| 14:47.46 | d-lo | lack of experience question: Fundimentally, is there any difference between feeding a pkg_switch a C routine and a function of an object instance? |
| 14:48.59 | d-lo | apologizes for his horrid speling. |
| 14:49.21 | starseeker | spelng 's overrrrratd |
| 14:49.32 | d-lo | wurd! |
| 14:49.39 | brlcad | there are some differences but most can be overcome |
| 14:49.47 | brlcad | a static member is identical |
| 14:49.49 | starseeker | after reading slashdot for years, it takes a lot of bad spelling before I'll notice |
| 14:51.44 | d-lo | so: If I have a pkg_conn as a member of an object, and I feed object->pkg_conn a pkg_switch that maps a 'pkg_type' to a function of this object... shouldn't that work? |
| 14:54.39 | d-lo | heh, that could have been worded a bit better. :) |
| 15:00.56 | brlcad | it depends on the access settings and function signature, but yeah, something like that is possible (the syntax is funky) |
| 15:01.06 | brlcad | runs |
| 15:05.45 | brlcad | last note before I really run off, really should make the function static so that it's an opaque caller |
| 15:06.04 | brlcad | you can make the object to be called on a data member used by the static callback |
| 15:06.38 | brlcad | which gets into the whole issue that the callback registration needs to also support a client data pointer (simple mod) |
| 15:13.03 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 15:24.05 | CIA-40 | BRL-CAD: 03starseeker * r33745 10/brlcad/trunk/regress/mged/ (9 files): Add arced, copymat, putmat, push, xpush, accept, reject, and tra |
| 15:59.50 | Dr_Phreakenstein | greetings, party people! |
| 16:01.52 | Dr_Phreakenstein | working people? |
| 16:02.58 | d-lo | "work work work work... HELLO BOYS!" - Mel Brooks |
| 16:04.58 | Dr_Phreakenstein | won't admit to seing that movie. so many times |
| 16:09.21 | Dr_Phreakenstein | d-lo: not to rehash, for backing up on CF, i meant only system and config files, as in only things handled by package installer. full drive backup, another story |
| 16:09.39 | Dr_Phreakenstein | still owe you those part numbers, have not forgotten |
| 16:09.55 | d-lo | Dr_Phreakenstein: yeah, got your email. Its understood now ;) |
| 16:10.04 | Dr_Phreakenstein | cool |
| 16:10.50 | Dr_Phreakenstein | yeah, gentoo is amazing, but i cannot claim things like that. will leave such claims for vista |
| 16:13.55 | d-lo | read an article somewhere that MS is pushing windows 7 *really* hard to get it out ASAP. Looks like they are in phear of MS Windows ME - round 2. lol Consumer reports are starting to slam Vista pretty hard :) tee hee. |
| 16:14.35 | Dr_Phreakenstein | ahhh.... warms the heart to hear stuff like that... |
| 16:15.08 | Dr_Phreakenstein | 4 <starseeker>: need anything before I split for class? |
| 16:20.11 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 16:31.48 | Dr_Phreakenstein | off to fun times! |
| 16:42.53 | *** join/#brlcad prado_ (n=prado_@tri59-1-82-233-202-167.fbx.proxad.net) | |
| 16:49.55 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) | |
| 17:09.44 | *** join/#brlcad Elrohir (n=kvirc@p5B14D38F.dip.t-dialin.net) | |
| 17:37.39 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 17:42.45 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 19:15.23 | d-lo | http://xkcd.com/528/ LOL |
| 19:57.12 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) | |
| 20:38.01 | Dr_Phreakenstein | nice |
| 20:43.37 | starseeker | auugh - now 7.14.3 works on my mac |
| 20:44.10 | starseeker | sort of - it opens the file without hanging but does not load .mgedrc |
| 20:47.58 | Dr_Phreakenstein | on lunch break now, will hop on tonight to try and help |
| 20:52.41 | starseeker | oh, lovely - now it just crashes |
| 20:52.48 | starseeker | must not have installed lastest |
| 21:26.51 | *** join/#brlcad Elrohir (n=kvirc@p5B14D38F.dip.t-dialin.net) | |
| 22:26.43 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 22:30.53 | starseeker | tracks instant mged start crash - workin gthrouh to mged.c:2464 |
| 22:32.59 | brlcad | starseeker: is it a bu_bomb? |
| 22:33.14 | brlcad | or coredump/segfault? |
| 22:33.29 | starseeker | bu_bomb |
| 22:33.45 | brlcad | vls zero or bad magic? |
| 22:34.05 | starseeker | Zero_magic_number |
| 22:34.30 | starseeker | trying to figure out why - str contains an mgedrc reference at that point |
| 22:35.30 | brlcad | if you break on 2464 *before* calling Tcl_EvalFile, what is str |
| 22:36.37 | starseeker | <PROTECTED> |
| 22:36.37 | starseeker | <PROTECTED> |
| 22:36.37 | starseeker | <PROTECTED> |
| 22:36.37 | starseeker | <PROTECTED> |
| 22:36.37 | starseeker | <PROTECTED> |
| 22:36.52 | starseeker | looks like a valid vls |
| 22:37.11 | brlcad | yep |
| 22:37.17 | brlcad | so that vls is actually fine |
| 22:37.37 | brlcad | it's the .mgedrc command processing |
| 22:39.06 | starseeker | fears following it down those roads |
| 22:39.06 | starseeker | but does anyway... |
| 22:39.06 | brlcad | :) |
| 22:39.06 | brlcad | yeah, you have to |
| 22:39.12 | starseeker | hi ho, hi ho, it's off to tclIOUtil we go... |
| 22:41.24 | starseeker | ok, hello Tcl_FSEvalFileEx... |
| 22:41.47 | brlcad | it's going to end up being a Tcl_EvalEx |
| 22:41.57 | brlcad | running the whole file as one command |
| 22:42.05 | starseeker | ah, thanks |
| 22:45.19 | brlcad | b tclBasic.c:4294 |
| 22:45.36 | brlcad | run with that, should then break for every commmand in the .mgedrc |
| 22:45.44 | brlcad | set that after you get to the 2464 breakpoint |
| 22:45.59 | starseeker | Tcl_ParseCommand (interp=0x780b200, start=0x74ee1ec "\n", '#' <repeats 22 times>, " Query Ray Settings ", '#' <repeats 22 times>, "\n# Set the basename of the fake solids generated by nirt\nqray basename query_ray\n\n# Specifies the kind of output generated by nirt.\n# g"..., numBytes=2902, nested=0, parsePtr=0x74f5024) at /Users/cyapp/brlcad/src/other/tcl/unix/../generic/tclParse.c:271 |
| 22:46.05 | starseeker | 271 if ((start == NULL) && (numBytes != 0)) { |
| 22:46.06 | starseeker | that's the poison |
| 22:46.51 | brlcad | o.O |
| 22:47.14 | starseeker | last parse command before death |
| 22:48.06 | brlcad | doesn't see anything there |
| 22:48.20 | brlcad | and that doesn't make sense too.. that's not in my .mgedrc at least |
| 22:48.48 | starseeker | can wipe/redo my .mgedrc - maybe the old one is killing it |
| 22:48.49 | starseeker | one sec |
| 22:49.00 | brlcad | keep it |
| 22:49.03 | brlcad | just move it |
| 22:49.06 | starseeker | k |
| 22:49.16 | brlcad | there's no reason an old mgedrc should cause a crash |
| 22:49.58 | brlcad | if we mess up and it does, we should fix the mess up; not give "delete your .mgedrc" as a 'fix' :) |
| 22:50.13 | starseeker | aw ;-) |
| 22:51.02 | brlcad | ah, I see the Query Ray Settings section in mgedrc.tcl -- mine is just apparently older |
| 22:51.30 | brlcad | ah, I wonder if that's it |
| 22:51.44 | brlcad | is "qray" a valid command now that libged is hooked in |
| 22:51.53 | starseeker | hrm |
| 22:51.57 | starseeker | good question |
| 22:53.13 | brlcad | or if one of the args to qray changed when you were working on nirt |
| 22:53.29 | brlcad | as unlikely as that seems .. should have come up much earlier if that was the case |
| 22:53.46 | starseeker | still crashes without an mgedrc |
| 22:54.35 | brlcad | nothing new was added to .mgedrc output recently, so that shouldn't be it |
| 22:54.47 | starseeker | crashing in a different place without mgedrc |
| 22:54.49 | starseeker | hang on... |
| 22:55.56 | starseeker | now it's mged.c:709 |
| 22:56.21 | starseeker | hmm - valid vls, contains "gui" |
| 22:58.50 | brlcad | :) |
| 22:58.55 | brlcad | that's kinda useless :) |
| 22:59.04 | brlcad | gui is the command that kicks off the entire gui |
| 22:59.16 | starseeker | I'm digging deeper |
| 22:59.21 | brlcad | basically means "something went wrong" ;) |
| 23:02.38 | starseeker | Breakpoint 2, Tcl_ParseCommand (interp=0x780b200, start=0x81e3504 "press left}\n", numBytes=10, nested=0, parsePtr=0x74f59b0) at /Users/cyapp/brlcad/src/other/tcl/unix/../generic/tclParse.c:271 |
| 23:02.42 | starseeker | 271 if ((start == NULL) && (numBytes != 0)) { |
| 23:02.45 | starseeker | (gdb) |
| 23:02.50 | starseeker | continuing after that triggers it |
| 23:03.33 | CIA-40 | BRL-CAD: 03brlcad * r33746 10/brlcad/trunk/src/libged/keep.c: fix another cosmetic issue lee found today, if you run keep on a file that already exists, it wasn't printing the file name due to amissing vararg |
| 23:04.56 | starseeker | hmm - looks like ged_autoview in one of these logs... |
| 23:06.18 | starseeker | ah HAH |
| 23:07.15 | starseeker | that's it |
| 23:07.50 | starseeker | GED_CHECK_DATABASE_OPEN is calling BU_CK_VLS, which is getting passed an empty vls |
| 23:08.05 | starseeker | the gedp pointer isn't null, but its contents are |
| 23:08.29 | starseeker | or rather - the vls structures in it are unitialized |
| 23:09.02 | starseeker | checks chgview |
| 23:13.19 | brlcad | aha, right |
| 23:13.29 | starseeker | I think it's that blasted gedp from main |
| 23:13.37 | brlcad | exactly why I didn't think my hack fix was sufficient |
| 23:13.38 | starseeker | size_reset doesn't take any params |
| 23:13.56 | starseeker | and bv_reset doesn't take a ged struct |
| 23:14.01 | starseeker | it's gotta be the main one |
| 23:14.53 | brlcad | hm, the logic to GED_CHECK_DATABASE_OPEN is rather weak |
| 23:15.04 | brlcad | if it's not a null gedp, it tries to bu_vls_trunc.. |
| 23:15.13 | brlcad | actually, hrm |
| 23:15.18 | starseeker | it looks like the GED_INIT function needs to accept NULL and still initialize the vls stuff |
| 23:15.26 | brlcad | yep |
| 23:15.31 | brlcad | exactly what I was thinking |
| 23:15.37 | starseeker | hunts for GED_INIT |
| 23:16.16 | brlcad | I left the GED_INIT in ged_dbopen(), but it also/still has to be on BU_GETSTRUCT |
| 23:16.22 | brlcad | has to be in both places |
| 23:16.39 | brlcad | though now there may be a memory leak if the gedp isn't wiped out |
| 23:17.39 | starseeker | heh - there's a ged_init_qray |
| 23:17.46 | brlcad | I think that may belong better in the wrapper instead of during init |
| 23:17.48 | starseeker | wonders if that's why the mgedrc was crapping out |
| 23:17.58 | brlcad | probably |
| 23:18.13 | starseeker | BINGO |
| 23:18.19 | brlcad | I bet a lot of commands would fail because of the non-null gedp and null dbip |
| 23:18.24 | starseeker | ged_init is just returning if gedp is NULL |
| 23:18.52 | brlcad | hrm? that sounds right |
| 23:19.02 | brlcad | nothing to init if you don't have a gedp |
| 23:19.14 | starseeker | maybe, but that's why the vls structures are in an invalid state |
| 23:19.26 | brlcad | it's never initialized |
| 23:19.28 | starseeker | "Zero_Magic" |
| 23:19.39 | brlcad | look for the getstruct |
| 23:19.56 | brlcad | the one I added yesterday, needs a GED_INIT() immediately after |
| 23:20.02 | brlcad | just with a null wdbp |
| 23:21.04 | starseeker | in setup.c? |
| 23:21.44 | brlcad | sounds about right |
| 23:23.09 | starseeker | well, that's progress - now it says "A database is not open! MGED unable to initialize gui, reverting to classic mode." |
| 23:24.21 | CIA-40 | BRL-CAD: 03starseeker * r33747 10/brlcad/trunk/src/mged/setup.c: Initialize gedp so we don't have invalid vls structures when checks are run. |
| 23:24.34 | starseeker | er, sorry Sean, should have credited you with the suggestion there |
| 23:25.18 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-158.sbndin.btas.verizon.net) | |
| 23:25.50 | starseeker | now that's weird - it cant initialize, offers classic, and then pops up the full GUI anyway |
| 23:28.36 | starseeker | erm - it says No symbol "TCL_OK" in current context. |
| 23:28.46 | starseeker | well no wonder status doesn't equal it |
| 23:28.59 | starseeker | brlcad: where do we get TCL_OK from? |
| 23:37.34 | starseeker | oh, OK - tcl.h, and it's 0 |
| 23:38.34 | starseeker | hmm - we're getting 1 as a return from the 709 mged Tcl_Eval |
| 23:42.07 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 23:45.50 | brlcad | starseeker: I don't need to be credited for any and every suggestion |
| 23:45.54 | brlcad | especially for one-liners :) |
| 23:46.21 | starseeker | well, going from crashing to non-crashing on the startup of the main gui is nice |
| 23:46.33 | starseeker | now if I can just figure out why its returning status 1... |
| 23:47.14 | brlcad | because of the "A database is not open!" message |
| 23:47.20 | brlcad | from there, the rest just cascades |
| 23:47.45 | starseeker | is that a consequence of ged wanting a database then? |
| 23:54.45 | starseeker | looks for where the messages are called and feels a sinking feeling |
| 23:58.42 | starseeker | I'm guessing the fix is to have the various commands that can run without an open database check for an open database only when the wdbp pointer is non-NULL? |
