| 00:51.01 | starseeker | huh - asymptote has the ability to plot a NURBS surface, apparently: http://asymptote.sourceforge.net/gallery/ |
| 01:10.22 | *** join/#brlcad crazy_imp (~mj@a89-182-15-178.net-htp.de) |
| 01:40.23 | brlcad | kunigami: you don't really need to worry about FAST_OBJECTS -- you can either list there or not, inconsequential |
| 01:44.45 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 01:56.59 | brlcad | how goes the application sachinjain |
| 02:08.18 | sachinjain | I just woke up |
| 02:08.34 | sachinjain | I have started to get familiar with the application |
| 02:08.58 | sachinjain | even the installation tool so much of my time |
| 03:14.29 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 03:14.29 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 03:18.16 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net) |
| 03:18.21 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 03:18.49 | *** join/#brlcad crazy_imp (~mj@a89-182-15-178.net-htp.de) |
| 03:18.49 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) |
| 03:18.49 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) |
| 03:18.49 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) |
| 03:18.49 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) |
| 03:19.14 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 03:19.15 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) |
| 03:19.15 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) |
| 03:19.15 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) |
| 03:19.16 | *** join/#brlcad hyarion_ (c05ben@peppar.cs.umu.se) |
| 03:19.16 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 03:19.16 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) |
| 03:19.35 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 03:19.35 | *** join/#brlcad siddharth (~siddharth@117.211.88.150) |
| 03:20.04 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) |
| 03:20.35 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 03:56.17 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 04:18.55 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) |
| 04:37.27 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 04:57.40 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 05:00.36 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 05:30.57 | CIA-52 | BRL-CAD: 03davidloman * r44001 10/geomcore/trunk/src/GS/FileDataSource.cxx: Remove the simplistic (likely poor) read/write locks in FileDataSource for now. |
| 05:44.18 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 05:47.52 | *** part/#brlcad siddharth (~siddharth@117.211.88.150) |
| 05:56.23 | dloman | Anyone still around? |
| 05:57.21 | bhinesley | probably not who you're looking for, but I am :) |
| 05:57.59 | dloman | Well now, you're correct, but nice to meet ya :) |
| 05:58.33 | bhinesley | you too |
| 05:59.30 | dloman | so, hang out here much? |
| 05:59.39 | bhinesley | pretty much constantly |
| 06:00.13 | dloman | quiet then? I don't see you chatting much. |
| 06:00.45 | bhinesley | I try not to interfere unless I have an important question, or significant contribution to the conversation. |
| 06:01.34 | bhinesley | I'm working on understanding the source, patches, and my GSoC proposal. |
| 06:01.53 | dloman | how long you been involved with brlcad? |
| 06:02.17 | bhinesley | just a week or two |
| 06:03.30 | bhinesley | probably closer to a week |
| 06:03.32 | bhinesley | how about you? |
| 06:04.06 | dloman | oh wow.... um. close to 3 years now, i think? |
| 06:04.11 | dloman | i lost track a long time ago |
| 06:04.14 | dloman | heh |
| 06:04.52 | bhinesley | that's cool. where are you? |
| 06:05.00 | bhinesley | (geographically) |
| 06:05.20 | dloman | 'south central' PA, usa. joo? |
| 06:05.34 | bhinesley | California |
| 06:06.24 | dloman | brlcad: I've narrowed that vls bad magic down to a bu_vls_free() call on lin 757 of Combination.cpp (coreInterface) |
| 06:06.57 | dloman | brlcad: I just don't know where to go from here (at this point), although Im gonna keep picking away at it. |
| 06:07.07 | dloman | bhinesley: first year at GSoC? |
| 06:07.46 | bhinesley | yeah |
| 06:08.33 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) |
| 06:08.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 06:09.23 | dloman | well enjoy it, its a blast. |
| 06:09.56 | dloman | we got a good crew here, so i hope you stick around |
| 06:10.08 | dloman | what caught your interest in brlcad anyways? |
| 06:10.16 | bhinesley | I plan to, and I hope I can help. |
| 06:11.16 | bhinesley | I have a fair amount of experience modeling 3D in AutoCAD, which I really loved doing. I like coding even more. |
| 06:12.07 | bhinesley | putting the two together sounds like a lot of fun |
| 06:12.44 | dloman | could be :) |
| 06:14.08 | dloman | where oh where is d_rossberg when ya need him! :) |
| 06:32.46 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 06:34.27 | dloman | hullo d_rossberg ! |
| 06:34.52 | dloman | if you got a few moment's, I'd like to chat a bit. |
| 06:35.02 | d_rossberg | dloman: ? it's half past two! |
| 06:35.23 | d_rossberg | about common.h? |
| 06:35.36 | dloman | actually its a bu_vls failure |
| 06:36.20 | d_rossberg | ok, where is the problem? |
| 06:37.36 | dloman | Combination.cpp:757 is seemingly causing a 'ERROR: bad pointer 0x1454eb10: s/b bu_vls(x89333bbb), was Zero_Magic_Number(x0)' failure |
| 06:38.30 | dloman | geomcore/trunk/tests/GS/FileDataSourceTest.cxx is the file I was using to perform a simple test |
| 06:38.47 | dloman | to open a .g, and iterate over the top items |
| 06:38.55 | dloman | err, 'top objects' |
| 06:39.01 | dloman | with a single object it works just fine |
| 06:39.34 | dloman | with two objects in the db, it bombs out with this backtrace: http://pastebin.mozilla.org/1193575 |
| 06:40.06 | dloman | I am admittedly not very familiar with the inner workings of the brlcad libraries. |
| 06:40.14 | dloman | all the C and Macros really really confuse me. |
| 06:41.24 | d_rossberg | i'm looking at it right now, may take some moments ... |
| 06:41.40 | dloman | I appriciate it! |
| 06:59.32 | CIA-52 | BRL-CAD: 03d_rossberg * r44002 10/rt^3/trunk/src/coreInterface/Combination.cpp: improved test for an only partly generated m_internalp (rt_comb_internal) after a long jump (C exception) |
| 06:59.49 | d_rossberg | this is not the entire solution, it only solves the error after the long jump |
| 07:00.41 | d_rossberg | i think, that db_dup_subtree fails if the database was removed (or something like this) |
| 07:03.52 | d_rossberg | i'll test it ... |
| 07:11.38 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 07:18.12 | dloman | thanks d_rossberg ! |
| 07:18.24 | dloman | i got a bit side tracked from the irc window, my apologies! |
| 07:41.56 | CIA-52 | BRL-CAD: 03d_rossberg * r44003 10/rt^3/trunk/src/coreInterface/Combination.cpp: initialize the VLS before first usage (in bu_vls_strcpy here) |
| 07:42.15 | d_rossberg | this should solve it, sorry ;} |
| 07:47.43 | dloman | Awesome thanks! |
| 07:48.07 | dloman | I'm gonna crash get some sleep, but I'll check it out later today. Thanks d_rossberg!! |
| 07:56.06 | d_rossberg | dloman: something for the notes: |
| 07:57.34 | d_rossberg | you should delete the object at the end with its Delete() method (not so important for your example, but if you have a real server ...) |
| 08:25.40 | d_rossberg | the common.hs: i've never installed the basic BRL-CAD's and and the C++ interface's headers into the same directory, i.e. there was always a distinction between common.h and brlcad/common.h |
| 08:42.38 | d_rossberg | see also the rt^3/include/brlcad/readme.txt file |
| 08:44.37 | d_rossberg | if there is a need to install both into the same directory i need to think over the C++ interface's naming conventions |
| 09:11.19 | d_rossberg | next: every Object has a static ClassName() and virtual Type() method (see Object.h) |
| 09:12.01 | d_rossberg | they can be compared by == (guess why ;) |
| 09:12.42 | d_rossberg | e.g.: if (obj->Type() == BRLCAD::Combination::ClassName()) then ... |
| 10:23.23 | dloman | d_rossberg: great stuff! You really did a bang up job on the coreInterface. |
| 10:50.48 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 11:23.35 | CIA-52 | BRL-CAD: 03davidloman * r44004 10/geomcore/trunk/src/GS/FileDataSource.cxx: Add iterator incr for proper iterating. |
| 12:07.50 | CIA-52 | BRL-CAD: 03davidloman * r44005 10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Expand test out to getting a single object and then getting a list of all objects at top. |
| 12:09.24 | dloman | so... who can pick me up a Mt Dew on the way to work? ;) |
| 12:09.46 | dloman | has the need... the need for caffene! |
| 12:11.19 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 12:19.56 | dloman | d_rossberg: still around? |
| 12:21.53 | d_rossberg | yes |
| 12:22.20 | dloman | okay, so I've moved on to Add() ing objects to a memorydatabase. |
| 12:22.27 | d_rossberg | and probable the next 3 hours |
| 12:22.30 | dloman | and, as usual, i broke things, lol |
| 12:23.00 | dloman | made an Arb8 using two vector3d objects, but failed to give the arb8 a name. |
| 12:23.18 | dloman | and attempting to add that is causing a segfault. |
| 12:24.16 | dloman | I can see why at Database.cpp:229 |
| 12:24.19 | d_rossberg | the name is a property of the Object |
| 12:24.36 | d_rossberg | see http://brlcad.org/wiki/CoreInterface_Hallo_World_Example for example |
| 12:24.38 | dloman | where the call to object.Name() is returning a null char* |
| 12:24.56 | dloman | okie. Is this expected behavior then? |
| 12:26.06 | dloman | btw, great wiki entries. They'ev been most helpful. |
| 12:27.10 | dloman | I am wondering, in the event that someone like me attempts to .Add() an Object before setting its name, should there be a check or default name? |
| 12:27.28 | d_rossberg | that Name() returns 0 is OK, but i should probable test for a valid name before calling wdb_export |
| 12:32.10 | CIA-52 | BRL-CAD: 03d_rossberg * r44006 10/rt^3/trunk/src/coreInterface/Database.cpp: test for the presence of a name before trying to add a new object to the database |
| 12:49.28 | d_rossberg | dloman: every Object has a virtual Valid() method to test if it's ok |
| 12:51.21 | dloman | alirghty, good to know |
| 12:51.28 | dloman | hehe, more questions: |
| 12:53.27 | dloman | it seems that if I try to add two Arb8's in a row, the second one clobbers the first. |
| 12:54.03 | CIA-52 | BRL-CAD: 03d_rossberg * r44007 10/rt^3/trunk/src/coreInterface/Database.cpp: |
| 12:54.03 | CIA-52 | BRL-CAD: corrected the test for a non empty object name |
| 12:54.03 | CIA-52 | BRL-CAD: not using object.Valid() here because it should be possible to add "broken" objects e.g. during copying a broken database |
| 12:54.30 | d_rossberg | it looks like you add the arb8s always to an empty database |
| 12:54.59 | dloman | so should I add, save, add ? |
| 12:56.14 | d_rossberg | BRLCAD::MemoryDatabase md; creates an empty database |
| 12:56.47 | dloman | lol, duh. Okay. Thanks, i see my mistake. |
| 12:57.35 | d_rossberg | if you want to save the database after every operation you should consider using FileDatabase instead |
| 12:58.05 | dloman | Righto, I have seen my mistake. Error with the wetware :) |
| 13:03.09 | CIA-52 | BRL-CAD: 03davidloman * r44008 10/rt^3/trunk/ (3 files in 2 dirs): Make the GeometryEngine header file installable since this will serve as an excellent search point for FindLibGE.cmake |
| 13:17.52 | CIA-52 | BRL-CAD: 03davidloman * r44009 10/geomcore/trunk/ (CMake/FindBRLCAD.cmake CMake/FindLIBGE.cmake CMakeLists.txt): Give libGE its own cmake FIND file. Un-hack the ge find routines out of FindBRLCAD.cmake |
| 13:17.55 | dloman | there we go ``Erik give it a shot now. Unless you installed rt3 in some silly place, it should be found. Also, you will need to update rt3 as i changed it a bit so it will install GeometryEngine.h |
| 13:20.00 | dloman | oh dayum: http://www.cnn.com/2011/WORLD/asiapcf/03/29/japan.nuclear.reactors/index.html |
| 13:20.22 | dloman | 100 R water in a tunnel. Oh yeah, that's a core containment breach.... |
| 13:27.49 | kunigami | hi, I've updated my patch to basename. Comments are welcome. thanks. |
| 13:40.51 | CIA-52 | BRL-CAD: 03erikgreenwald * r44010 10/geomcore/trunk/CMake/FindLIBGE.cmake: allow libge directory to be fed explicitely |
| 13:41.05 | dloman | didnt work eh? |
| 13:42.52 | ``Erik | not quite yet |
| 13:43.25 | CIA-52 | BRL-CAD: 03erikgreenwald * r44011 10/geomcore/trunk/src/GS/CMakeLists.txt: add LIBGE_INCLUDE_DIRS |
| 13:49.35 | CIA-52 | BRL-CAD: 03erikgreenwald * r44012 10/geomcore/trunk/CMake/FindLIBGE.cmake: we already refer to brlcad/header.h, so do not include the brlcad/ in the search path |
| 13:53.54 | CIA-52 | BRL-CAD: 03erikgreenwald * r44013 10/geomcore/trunk/ (CMake/FindLIBGE.cmake src/GS/CMakeLists.txt): adjust include dir name to be consistent |
| 13:56.26 | CIA-52 | BRL-CAD: 03erikgreenwald * r44014 10/geomcore/trunk/src/GS/CMakeLists.txt: link libraries from Find* variables |
| 13:56.43 | ``Erik | there we go |
| 13:56.58 | CIA-52 | BRL-CAD: 03erikgreenwald * r44015 10/geomcore/trunk/tests/GS/CMakeLists.txt: add new libge stuff |
| 13:59.10 | CIA-52 | BRL-CAD: 03erikgreenwald * r44016 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: fix type warning |
| 14:01.14 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 14:28.31 | CIA-52 | BRL-CAD: 03starseeker * r44017 10/geomcore/trunk/tests/svntest/main.c: Start figuring out repo level commits, as opposed to doing it manually - not working yet |
| 14:29.20 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) |
| 14:29.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 14:39.33 | brlcad | first couple applications are in! |
| 14:39.45 | brlcad | thinks this cold nonesense needs to stop |
| 14:40.59 | *** join/#brlcad Jesselnz (~jesse@ool-435573a5.dyn.optonline.net) |
| 14:41.10 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 14:41.23 | brlcad | hello Jesselnz |
| 14:41.28 | Jesselnz | Hi |
| 14:42.54 | Jesselnz | A summer of code application involves doing a small task and sending in a patch, correct? |
| 14:42.56 | brlcad | starseeker: so a refresher from yesterday now that my head has cleared up a little bit and the tiny little hammers have taken a lunch break |
| 14:43.12 | Jesselnz | Do you have any suggestions for a task to get started with? |
| 14:43.12 | brlcad | Jesselnz: not *strictly* required, but highly highly recommended |
| 14:43.29 | Jesselnz | Alright |
| 14:43.32 | brlcad | you should get your proposal in first and say you're working on a patch at a minimum |
| 14:44.06 | brlcad | otherwise, I'd suggest just picking something tangible from our BUGS list or TODO file |
| 14:44.29 | Jesselnz | Okay |
| 14:45.12 | Jesselnz | I'm still trying to familiarize myself with the codebase for my proposal. |
| 14:45.16 | brlcad | sure |
| 14:45.25 | CIA-52 | BRL-CAD: 03brlcad * r44018 10/brlcad/trunk/TODO: there is a pending patch from Guilherme Kunigami (kunigami-dev) that should fix this issue, so remove the todo on bu_basename() |
| 14:45.27 | brlcad | if you find some that sound easy and want confirmation, just speak up |
| 14:45.54 | Jesselnz | I was planning to work on the conversion library, but I noticed it involves C++ (which I have no experience with) |
| 14:46.29 | brlcad | the patch shouldn't take more than a couple hours -- we just want to make sure you can actually code, at it gives you the opportunity to shine above other applicants if everything else is equal |
| 14:46.42 | brlcad | Jesselnz: what languages do you have experience with? |
| 14:47.02 | brlcad | it doesn't have to involve C++, it could be pure C |
| 14:47.09 | Jesselnz | Aside from scripting languages (Javascript, Per, Tcl), only C |
| 14:47.16 | Jesselnz | * Perl |
| 14:47.30 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) |
| 14:47.42 | brlcad | at least one of our converters has an implementation in C++, so that's why C++ is also listed, not because the library has to be in C or C++ |
| 14:47.50 | brlcad | a good design can arise from either |
| 14:47.54 | Jesselnz | Alright |
| 14:49.59 | brlcad | so are you really from new zealand? :) |
| 14:50.25 | Jesselnz | Me? |
| 14:50.34 | brlcad | you |
| 14:50.44 | Jesselnz | No, I'm from New Jersey |
| 14:50.52 | brlcad | aha, k |
| 14:51.23 | *** join/#brlcad Elrohir (~kvirc@p5B14B1EA.dip.t-dialin.net) |
| 14:52.06 | brlcad | Jesselnz: how strong is your math? |
| 14:52.34 | Jesselnz | Well, first-year university level |
| 14:52.36 | Jesselnz | I'm a math major |
| 14:52.38 | brlcad | and do you have any computational geometry or computer graphics background? |
| 14:52.47 | brlcad | okay, cool |
| 14:53.14 | Jesselnz | Not really, but I've researched the basics |
| 14:54.06 | brlcad | instead of the geometry conversion library, you might want to consider proposing the image conversion library |
| 14:54.28 | brlcad | or the de-tcl project |
| 14:54.43 | Jesselnz | I'll look into those |
| 14:54.50 | brlcad | both don't involve any c++ |
| 14:55.30 | brlcad | what brought your interest to brl-cad? |
| 14:55.50 | Jesselnz | I just find CAD interesting |
| 14:56.00 | Jesselnz | Since I'm going into engineering, and I enjoy math |
| 14:56.40 | brlcad | how'd you come to learn Tcl as a first-year? |
| 14:56.55 | brlcad | covered in some first semester scripting class or something? |
| 14:57.30 | Jesselnz | I haven't taken any programming classes - just projects I've done on the side |
| 14:57.41 | brlcad | interesting |
| 14:58.30 | Jesselnz | I tried to write a 2d CAD program in high school using Tcl's C library |
| 14:58.47 | brlcad | then I'd definitely like to see some code or even work through some code with you, just to see exactly where you're at -- all skill levels are welcome if you have the passion, but need to make sure the project is scoped accordingly |
| 14:59.55 | Jesselnz | From the project I just mentioned? |
| 15:00.01 | brlcad | hah, then removing Tcl C api calls from our core library would essentially be the opposite :) |
| 15:00.25 | brlcad | no, I mean in terms of developing a patch to go with your proposal |
| 15:00.38 | brlcad | and scoping your proposal appropriately |
| 15:00.38 | Jesselnz | Alright |
| 15:01.18 | Jesselnz | Yeah, after looking through what exists of the gometry conversion library, it's a bit more algorithm-intensive than I was expecting |
| 15:03.16 | brlcad | and huge, that project entails wrangling up over 250k lines of code into an API |
| 15:03.33 | brlcad | the image processing library is less than half that |
| 15:18.01 | CIA-52 | BRL-CAD: 03davidloman * r44019 10/geomcore/trunk/ (4 files in 3 dirs): Implement FileDataSource's putObj() function. |
| 15:31.00 | CIA-52 | BRL-CAD: 03davidloman * r44020 10/geomcore/trunk/tests/GS/ (CMakeLists.txt SimpleCoreInterfaceTest.cxx): Implement a simple core interface test. |
| 15:36.39 | *** join/#brlcad |Elrohir| (~kvirc@p5B14B378.dip.t-dialin.net) |
| 16:08.50 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) |
| 16:37.33 | CIA-52 | BRL-CAD: 03davidloman * r44021 10/geomcore/trunk/ (3 files in 3 dirs): GeometryChunk needs to be aware of its path. Added a path field, modified associated test. |
| 16:42.54 | dloman | brlcad: i get a byte[] from a socket... whats the quickest way to turn it into a brlcad struct that i can write to disk as a .g ? |
| 16:45.31 | dloman | i just noticed that starseeker isn't around today. |
| 16:51.16 | CIA-52 | BRL-CAD: 03r_weiss * r44022 10/brlcad/trunk/src/conv/dem-g.c: Fixed two bugs in the dem-g converter which were introduced in recent edits. One was a correction to the parameters for 'bu_calloc/bu_malloc' and the other was several duplicate 'bu_free'. |
| 16:56.54 | starseeker | brlcad: I took a look at the red problems on OSX 10.6.7 - it's a bit scary |
| 16:57.12 | starseeker | it's not anything I can pin down - the gedp pointer itself seems to have corrupt information |
| 16:57.40 | starseeker | at least according to gdb, but if it were going to wipe out I would have expected it to do so sooner than what I saw |
| 16:57.57 | starseeker | do you have a 10.6 mac by any chance? |
| 17:02.06 | starseeker | dloman: I'm around, just getting yanked here, there and everywhere |
| 17:12.45 | brlcad | dloman: you've really not spent any time reading g_transfer.c have you? once again, the answer to your question is in there, server_geom() |
| 17:13.52 | brlcad | there are a few ways you can turn (presumably bu_exported bytes) back into an object |
| 17:14.04 | dloman | i'm very tired, i got no sleep last night and am having trouble concentraiting. thanks for the reminder where it was. |
| 17:14.25 | brlcad | sure :) |
| 17:14.58 | brlcad | transfer uses a low-level method, cliff's test program used a slightly higher level function call that should work too |
| 17:15.31 | brlcad | starseeker: I do, although I've not updated to .7 yet |
| 17:15.50 | brlcad | any specific reproduction steps to try? |
| 17:22.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 17:27.29 | CIA-52 | BRL-CAD: 03brlcad * r44023 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h): formally deprecate the GIFT field elements on rt_comb_internal objects: region_id, aircode, GIFTmater, and los. they are now stored as attributes. |
| 17:31.58 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.136.132) |
| 17:38.52 | brlcad | starseeker: what steps were you using to debug the keep issue? |
| 17:40.00 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.102) |
| 17:40.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 17:43.38 | brlcad | man, the comb5 export function is messed up |
| 17:43.58 | brlcad | forcibly deconsts, clobbers data |
| 17:44.04 | brlcad | hate to fix this before a release |
| 17:44.41 | brlcad | starseeker: all of that logic in comb.c doesn't even belong there |
| 18:04.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.139.178) |
| 18:04.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:09.29 | starseeker | brlcad: for red, just try to edit a combination - hard crashes mged |
| 18:09.47 | starseeker | for keep - tried a keep of computer in ktank.g |
| 18:10.17 | starseeker | was watching the status of the avs list |
| 18:10.38 | brlcad | okay |
| 18:11.17 | brlcad | I'm getting a handle on the import/export problem |
| 18:11.25 | starseeker | awesome |
| 18:11.41 | CIA-52 | BRL-CAD: 03brlcad * r44024 10/brlcad/trunk/TODO: two issues to resolve now |
| 18:11.41 | starseeker | sorry we kept pestering you yesterday when you felt like crap :-/ |
| 18:11.53 | brlcad | comb export sucks, but that's old code so I don't want to edit any more than I have to this release |
| 18:12.02 | starseeker | nods |
| 18:12.15 | starseeker | it's not any more broken than it ever was |
| 18:12.27 | starseeker | only shows up when region_id and the comb struct aren't in sync |
| 18:12.28 | brlcad | no way to verify that :) |
| 18:12.35 | brlcad | well, there is a way, but would take too much time |
| 18:12.51 | brlcad | so the question is exactly when/where they get out of sync |
| 18:13.01 | brlcad | because that export code is just fine assuming they are in sync |
| 18:13.11 | brlcad | still sucks, but it's not wrong with that assumption |
| 18:13.25 | brlcad | so the problem is either during import or elsewhere |
| 18:19.01 | starseeker | I suppose in principle you might have some asc2g type thing where you import a comb and then set the region_id to -1 after creating the comb itself |
| 18:20.36 | starseeker | iirc red was capable of doing things like that before I added all that sync logic... and the .g files ktank.g and havoc.g are the product of running asc2g |
| 18:22.09 | starseeker | interesting - getting a more useful backtrace |
| 18:24.25 | starseeker | http://pastebin.mozilla.org/1194067 |
| 18:26.15 | starseeker | wooot - it DOES crash on my 10.5 mac |
| 18:26.21 | starseeker | wonder when that happened? |
| 18:26.24 | starseeker | ok, phew |
| 18:26.30 | starseeker | starts binary search |
| 18:36.31 | brlcad | while you're progressing from that direction, i'll see if I can find where the two get out of sync |
| 18:37.40 | starseeker | k - it looks like (surprise) some of the recent regex tweaking for red broke something |
| 18:39.34 | starseeker | yep - r43832 |
| 18:41.01 | brlcad | hmmm, interesting |
| 18:43.04 | brlcad | so either freeing something that shouldn't be or not initializing something after free |
| 18:46.40 | CIA-52 | BRL-CAD: 03brlcad * r44025 10/brlcad/trunk/src/libged/red.c: revert r43832 since it reportedly is causing red to crash. needs more investigating since this should have been a safe refactoring change. |
| 18:48.09 | brlcad | waits for builds to recompile so he can debug appropriately |
| 18:51.09 | CIA-52 | BRL-CAD: 03starseeker * r44026 10/brlcad/branches/cmake/ (14 files in 10 dirs): MFC r44025 |
| 18:51.46 | brlcad | oh shizzle |
| 18:51.51 | brlcad | how'd that happen |
| 18:52.08 | brlcad | looks like an == 0 got turned into a != 0 in that commit |
| 18:52.58 | starseeker | ah, line 164? |
| 18:53.21 | brlcad | yeah |
| 18:53.50 | brlcad | if that's the culprit, then r44025 should still crash |
| 18:54.00 | brlcad | since it's still != |
| 18:54.21 | starseeker | it's not - at least not in my build here - 44025 works |
| 18:54.30 | starseeker | (well, 44026 in cmake0 |
| 18:54.36 | brlcad | huh |
| 18:55.09 | brlcad | per the logic, == 0 should be right == if regex is successful |
| 18:55.29 | brlcad | i think :) |
| 18:55.43 | starseeker | it may not handle a matrix right, but it doesn't crash and does apply the changes in the simple case |
| 18:56.58 | starseeker | Ohhhhh |
| 18:57.21 | starseeker | I think my logic on red.c around line 425 may be screwy |
| 18:57.46 | starseeker | you have ret=0, and I was counting on -1 or 1 |
| 18:58.23 | brlcad | it was ret 0 previously |
| 18:58.26 | brlcad | I see what i did |
| 18:58.36 | brlcad | I swapped the if/else so != become an == case |
| 18:58.47 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832 |
| 18:58.53 | starseeker | oh, ok |
| 18:59.22 | brlcad | so it's just back to being confusing as to why one works and the other doesn't |
| 18:59.47 | brlcad | functionally equivalent ... unless... |
| 19:01.04 | starseeker | matrix_substring is inited inside an if test... |
| 19:01.34 | starseeker | no, that doesn't look like it... |
| 19:04.22 | brlcad | smelling more like red herring |
| 19:10.03 | CIA-52 | BRL-CAD: 03starseeker * r44027 10/brlcad/trunk/src/libged/red.c: Take another stab at the refactor - this seems to work, but needs more testing |
| 19:13.35 | brlcad | hm, I just don't believe that to be the direct cause of any crash |
| 19:13.46 | brlcad | that's functionally equivalent |
| 19:14.10 | brlcad | init of the vls earlier was the only change, but that vls isn't accessed outside that one block |
| 19:14.18 | starseeker | nods |
| 19:14.27 | starseeker | can you confirm the crash prior to 44025? |
| 19:14.40 | brlcad | haven't tested |
| 19:14.46 | starseeker | k |
| 19:16.00 | brlcad | oh there's something different |
| 19:16.12 | brlcad | you made it always return 1 :) |
| 19:16.20 | brlcad | ignoring the ret var |
| 19:17.07 | brlcad | now that I'd believe .. that code elsewhere is at fault for not handling other return values correctly |
| 19:17.13 | starseeker | ah whooops |
| 19:18.28 | CIA-52 | BRL-CAD: 03brlcad * r44028 10/brlcad/trunk/src/libged/red.c: return the value that was set |
| 19:22.17 | starseeker | urm... still working here |
| 19:23.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:24.35 | starseeker | I take that back - it's not handling an example with a matrix right |
| 19:24.38 | starseeker | growl... |
| 19:31.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.184) |
| 19:31.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:36.10 | starseeker | blast it the full matrix regex isn't matching |
| 19:36.18 | starseeker | I could have sworn I tested all that |
| 19:36.30 | CIA-52 | BRL-CAD: 03brlcad * r44029 10/brlcad/trunk/src/librt/db5_io.c: init the external before trying to fill it. random stack memory is evil. |
| 19:36.43 | CIA-52 | BRL-CAD: 03brlcad * r44030 10/brlcad/trunk/src/librt/dir.c: save some time, don't init until we need to |
| 19:36.56 | brlcad | starseeker: maybe also related to the [:blank:] vs [:space:] change |
| 19:37.15 | brlcad | should be the same for any value that might continue to another line |
| 19:37.27 | brlcad | this begs for a proper regression |
| 19:37.35 | brlcad | bunch of input red files |
| 19:38.35 | CIA-52 | BRL-CAD: 03brlcad * r44031 10/brlcad/trunk/src/librt/db5_io.c: ws |
| 19:39.28 | CIA-52 | BRL-CAD: 03brlcad * r44032 10/brlcad/trunk/src/librt/dir.c: ws cleanup |
| 19:40.58 | starseeker | "[[:space:]]+([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?[[:space:]]+) {15}([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?)" |
| 19:42.02 | brlcad | for what it's worth, I get a rather different stack trace from yours |
| 19:42.41 | brlcad | same all the way up to rt_db_put_internal5(), mine never gets to rt_db_free_internal() |
| 19:43.10 | brlcad | so it's going wrong somewhere before there |
| 19:43.15 | starseeker | hmm |
| 19:45.35 | starseeker | hates regex |
| 19:48.23 | starseeker | it's not blank vs space |
| 19:49.15 | brlcad | we must gain deeper understanding as to what is failing and why, not just chase symptoms |
| 19:49.39 | starseeker | brlcad: I know - I'm after why it's not matching the matrix |
| 19:50.01 | starseeker | that has to be fixed toto |
| 19:50.03 | starseeker | to even |
| 19:50.06 | brlcad | nods |
| 19:50.24 | starseeker | I take it you're still crashing? |
| 19:50.37 | brlcad | i've been in the debugger on the same crash |
| 19:50.44 | starseeker | ah |
| 19:50.59 | brlcad | cleaning up code as I review up and down the stack |
| 19:50.59 | starseeker | jeez what a lousy time for this |
| 19:51.09 | starseeker | nods |
| 19:58.35 | CIA-52 | BRL-CAD: 03brlcad * r44033 10/brlcad/trunk/src/librt/db5_io.c: cleanup rt_db_cvt_to_external5(). make sure we check all inputs and initialize our bu_externals. |
| 20:09.09 | CIA-52 | BRL-CAD: 03starseeker * r44034 10/brlcad/trunk/src/libged/red.c: Ooops. one logical if statement error and a stray space in the full_matrix regex string |
| 20:13.28 | kunigami | brlcad: I'm taking a look at your comments of my patch. How do I enforce that callers of bu_basename release memory? Are there something like smart_pointers in c? |
| 20:14.03 | brlcad | kunigami: no way to enforce, just have to give them a quick sanity check |
| 20:14.14 | brlcad | s/way/need/ |
| 20:14.36 | brlcad | it's only because it's an api change (and deviation from basename()) that it even needs to occur |
| 20:14.49 | starseeker | bhinesley: did you get a chance to play with the Tcl/Tk code? |
| 20:15.56 | kunigami | hmm, what do you mean by "sanity check"? |
| 20:18.15 | brlcad | kunigami: a grep through the code to find all the callers, make sure the string is released or copied and released |
| 20:19.07 | brlcad | iirc, that routine is not called in more than a couple places -- if it's more than 15 min work, lemme know |
| 20:20.00 | kunigami | ok! |
| 20:20.00 | kunigami | One thing: if we're going to change interface, I'd suggest we also change the input to non-const (like basename). I think it would do less harm. Also, it would be compliant with basename (3), which may change the input string. |
| 20:20.49 | kunigami | then there's no need to allocate memory |
| 20:28.02 | CIA-52 | BRL-CAD: 03starseeker * r44035 10/brlcad/branches/cmake/src/ (libged/red.c librt/db5_io.c librt/dir.c): MFC r44034 |
| 20:31.30 | bhinesley | starseeker: Yes, I changed the export->ASCII to a tk_getSaveFile. It stands alone without the bug fix, so I'm submitting it in a few minutes. |
| 20:31.53 | bhinesley | I have gotten closer to finding the bug, but it is not in Tcl/Tk. |
| 20:32.04 | starseeker | brlcad: awesome :-) |
| 20:32.14 | starseeker | er bhinesley: awesome :-) |
| 20:32.41 | starseeker | note to self - read then post :-P |
| 20:33.12 | bhinesley | at least he wasn't talking about a family member dying or something |
| 20:33.48 | starseeker | heh |
| 20:36.36 | brlcad | kunigami: that's a good thought but then there are a couple issues |
| 20:36.41 | bhinesley | part of the problem, is that Windows 7 moves files into VirtualStore that are exported anywhere but the user profile. To the user, they're just not there. |
| 20:37.13 | brlcad | one being that dirname/basename suck .. they're the way they are because they were implemented that way a LONG time ago and it's painful to change API that old |
| 20:37.17 | bhinesley | the other problem is incorrect handling of windows paths, which is what I'm still tracking down |
| 20:37.24 | brlcad | they're not re-entrant or thread-safe, for example |
| 20:38.04 | starseeker | bhinesley: ah yes, Windows paths |
| 20:38.34 | starseeker | bhinesley: how are you building on Windows? |
| 20:38.40 | brlcad | kunigami: the other issue is consistency -- we have to be self-consistent so whatever is done for bu_basename() needs to be done for bu_dirname() too |
| 20:39.37 | brlcad | kunigami: so either both match dirname/basename or both match each other, provide thread safety, but require callers to bu_free() |
| 20:39.49 | bhinesley | starseeker: I started with Cygwin, but ran into build errors. Anyways, once I read that releases are built in Visual Studio, that's what I started using. I just finished building for the first time, and there are some errors. I have yet to see how bad. |
| 20:40.48 | kunigami | wow I didn't think of these issues! ok. I'll keep the interface and add a commentary at bu.h and also perform sanity checks. do we have any such automatic checker, where I could add these tests? |
| 20:42.04 | brlcad | kunigami: what sort of tests? |
| 20:42.05 | starseeker | bhinesley: the cmake branch may be a good bet for building on Windows with Visual C++ |
| 20:42.35 | brlcad | kunigami: bu_dirname() already takes const, returns nonconst, and documents the need for bu_free() so it would be a good example to follow |
| 20:42.59 | brlcad | the issue is just making sure bu_basename() callers are calling bu_free() like bu_dirname() callers are |
| 20:43.31 | bhinesley | starseeker: in the repo? |
| 20:44.32 | kunigami | brlac: hhm nevermind I don't think such sanity checkings could be automated. |
| 20:44.33 | bhinesley | I see it now |
| 20:44.47 | kunigami | brlcad: ok. I'll follow that example |
| 20:45.15 | starseeker | bhinesley: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/cmake brlcad-cmake |
| 20:46.47 | *** join/#brlcad siddharth_ (~siddharth@117.211.88.150) |
| 20:47.31 | siddharth_ | brlcad, How to apply for gsoc brlcad? |
| 20:48.17 | brlcad | siddharth_: see http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 20:49.25 | starseeker | bhinesley: you'll need cmake (2.8.4 is probably a good idea) and Visual C++ (or Visual Studio should work) |
| 20:49.37 | starseeker | If you want to build the installer you'll also need NSIS |
| 20:50.09 | CIA-52 | BRL-CAD: 03erikgreenwald * r44036 10/geomcore/trunk/src/interfaces/cl/ (. gsclient.asd gsclient.lisp): quick and dirty lithp client |
| 20:50.17 | bhinesley | starseeker: alright, thank you |
| 20:57.20 | *** join/#brlcad Marjo_ (~Marjo@71.141.133.50) |
| 20:57.46 | starseeker | ``Erik: that's pretty cool, actually |
| 21:04.08 | Marjo_ | Hello, everyone! |
| 21:05.51 | brlcad | hello Marjo_ |
| 21:23.21 | CIA-52 | BRL-CAD: 03brlcad * r44037 10/brlcad/trunk/src/librt/comb/comb.c: check in the order passed |
| 21:26.47 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2777 10/wiki/MGED_CMD_who: displayed objects |
| 21:38.25 | brlcad | there's a gsoc project I forgot to add .. syncronize wiki pages with doxygen pages ;) |
| 21:39.35 | brlcad | er, docbook |
| 21:40.04 | starseeker | yeah! that's a really good candidate for those interested in web stuff |
| 21:42.54 | Marjo_ | I'm very intersted in the code maintenance project. Filling out a proposal right now. |
| 21:44.04 | brlcad | Marjo_: fantastic, which one? |
| 21:44.30 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2778 10/wiki/Google_Summer_of_Code/Project_Ideas: sync docbook and wiki docs |
| 21:45.06 | Marjo_ | brlcad: I'm very interested with Code Reduction / General Tree Walker / Fixing Bugs under Code Refactoring Projects. |
| 21:45.46 | Marjo_ | I'm only a 2nd year Computer Engineering Undergrad so I'm still a novice. |
| 21:56.13 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2779 10/wiki/Synchronize_Wiki_with_Docbook: initial wikidocbook idea |
| 21:56.21 | brlcad | Marjo_: then code refactoring sounds like a great place to begin |
| 21:56.30 | brlcad | that said, you could have 10 years experience and still be a novice ;) |
| 21:57.33 | brlcad | if experience is limited, I wouldn't necessarily recommend starting with code reduction since that usually entails a lot of careful testing and API design |
| 21:57.36 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 21:57.45 | brlcad | the other two ideas, however, bug fixes and tree walking, are more tangible |
| 21:58.11 | Marjo_ | brlcad: Haha, agreed. I would love to get a small taste of what real-world programming looks like. |
| 21:59.11 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2780 10/wiki/Main_Page: there is no support, neat showing dead links in red erik |
| 22:00.36 | brlcad | Marjo_: it's mostly about taking things to completion -- proof-of-concept is never enough |
| 22:01.14 | brlcad | docs, testing, performance profiling, tweaking, more docs, more testing |
| 22:02.54 | Marjo_ | brlcad: To test this code, what kind of IDE would you recommend? Is either Microsoft Visual C++ 2010 or Eclipse on Ubuntu a proper IDE? |
| 22:03.17 | brlcad | whatever you're comfortable and productive with is fine |
| 22:03.28 | brlcad | it's worth investing the time and effort to learning how to use one of them well, though |
| 22:03.51 | brlcad | personally, I prefer emacs, eclipse, or vim (in probably that order) |
| 22:04.49 | brlcad | most graphical IDEs are just a crutch, and tend to get in the way more than they help -- learn the underlying concepts first and it won't matter |
| 22:07.56 | brlcad | if you end up not understanding build failures or avoiding looking into compilation failures, then you probably shouldn't be using an IDE yet |
| 22:11.16 | Marjo_ | How would students address code maintenance if they don't see the errors through an IDE? Throughout the duration of my 2 years we've only been using Eclipse and Visual Studio to write code and debug. |
| 22:19.01 | brlcad | Marjo_: your confusion is exactly what I'm referring to :) |
| 22:19.22 | brlcad | the IDE isn't a magical black box, it's making calls and performing operations under the hood |
| 22:20.06 | brlcad | as a young developer, it's critical to learn what those things are otherwise "when things go wrong", deciphering what's going wrong can seem impossible |
| 22:20.14 | brlcad | or worse, lead to cargo cult programming |
| 22:20.45 | Marjo_ | brlcad: OH! I see what you're talking about. Does it basically boil down to white box testing? |
| 22:21.25 | brlcad | you should be able to write and debug software with a simple text editor, a compiler, and a linker .. next learn a decent debugger and you'll be more experienced than most developers |
| 22:22.12 | brlcad | it's not related to white box testing -- it's knowing how your tools work |
| 22:23.53 | Marjo_ | Ahh, my current Data Structures and Algorithms professor touched upon this subject during the beginning of the semester, but she said that is probably too advanced for our class right now. |
| 22:23.54 | brlcad | car analogy: it's like being a car mechanic but not knowing how to use a wrench, avoiding wrenches or even anything with a bolt on it because you've never used a wrench before |
| 22:24.39 | Marjo_ | I wonder why we didn't start out our curriculum by "learning the insides" first... |
| 22:25.09 | brlcad | a power wrench might save time and effort, but damn .. it's just a wrench .. don't fear learning how to use a wrench first ;) |
| 22:26.18 | brlcad | Marjo_: that's because the average CS student is stupid (because the average person is stupid) and they try to not scare people away too quickly, ease them into core concepts |
| 22:26.46 | Marjo_ | Haha, I fully understand. :) |
| 22:26.48 | brlcad | decades of people before you learned the basic tools just fine, you'll do just fine too |
| 22:34.24 | CIA-52 | BRL-CAD: 03brlcad * r44038 10/brlcad/trunk/include/raytrace.h: (log message trimmed) |
| 22:34.24 | CIA-52 | BRL-CAD: yay understanding. document how RT_GET_TREE() and RT_FREE_TREE() are/were |
| 22:34.24 | CIA-52 | BRL-CAD: working. it's basically a linked list that reuses free'd tree items so we never |
| 22:34.24 | CIA-52 | BRL-CAD: allocate more than the largest amount in use at any one time. pretty nifty. |
| 22:34.24 | CIA-52 | BRL-CAD: (allocating in batches might be even better) add a new RT_INIT_TREE macro that |
| 22:34.25 | CIA-52 | BRL-CAD: will initialize a union tree to zero with the magic set, make RT_GET_TREE init |
| 22:34.26 | CIA-52 | BRL-CAD: every tree returned so callers never have to deal with the magic number |
| 22:35.13 | CIA-52 | BRL-CAD: 03brlcad * r44039 10/brlcad/trunk/src/librt/ (comb/db_comb.c db_tree.c tree.c): now that RT_GET_TREE initializes, we don't need to manually set RT_TREE_MAGIC any more. should also help guarantee that reused tree nodes have zero'd memory. |
| 22:37.39 | Marjo_ | Wow, thank you for the inspiration. I will still apply for the project so that I can learn of the different ways to program. |
| 22:45.58 | adityag | brlcad: is it cool if i have not submitted patches in BRL-CAD ? . i have submited a few patches in drupal. will that help ? |
| 22:49.51 | brlcad | Marjo_: great, look forward to seeing your application |
| 22:50.52 | brlcad | again, you can use whatever you like |
| 22:50.54 | brlcad | we'll only push you towards specific tools if you're taking too long |
| 22:51.08 | brlcad | the tool is just a tool, better to obsess over code than over the tools :) |
| 22:51.19 | brlcad | adityag: are you serious? :) |
| 22:53.25 | brlcad | "is it cool if I didn't do the assignment for your class ? . i did the assignment for another class. will that help ?" |
| 22:53.28 | brlcad | you tell me ;) |
| 22:55.04 | adityag | <PROTECTED> |
| 23:01.20 | brlcad | a patch isn't technically "required", so you should submit your application with or without it regardless (you can attach a link to the patch later) |
| 23:01.48 | brlcad | but trying to pawn off work for another org isn't cool or useful, the point is seeing how you deal with our code |
| 23:04.37 | CIA-52 | BRL-CAD: 03brlcad * r44040 10/brlcad/trunk/src/librt/ (4 files in 3 dirs): no longer need to set RT_TREE_MAGIC now that RT_GET_TREE() sets it. |
| 23:05.57 | CIA-52 | BRL-CAD: 03brlcad * r44041 10/brlcad/trunk/src/libged/ (8 files): no longer need to set RT_TREE_MAGIC in here too now that RT_GET_TREE() sets the magic. |
| 23:09.22 | adityag | brlcad: yeah cool. |
| 23:17.00 | CIA-52 | BRL-CAD: 03brlcad * r44042 10/brlcad/trunk/src/libged/red.c: functions that use zero for success result in reverse boolean expressions. less error-prone to explicitly test for zero. go a step further and document intent with matched/no match labels. |
| 23:21.10 | CIA-52 | BRL-CAD: 03brlcad * r44043 10/brlcad/trunk/src/libged/red.c: aha, source of the errant space. auto-formatting sees the ){ and wants to clean up the formatting. break up the string. |
| 23:57.09 | starseeker | brlcad: nice. I didn't realize you could feed two separate strings into the printf logic like that |
| 23:58.01 | adityag | brlcad: Im interested in these project ideas : Code Reduction, Fix Bugs, Benchmark Performance Database. Can i submit multiple applications ? |