| 00:02.52 | brlcad | adityag: you sure can |
| 00:03.08 | brlcad | you can submit up to 20 apps total to any number of orgs |
| 00:03.22 | brlcad | I don't recommend submitting more than three |
| 00:03.32 | brlcad | focus on quality, not quantity |
| 00:03.53 | adityag | ok cool thanks |
| 00:03.55 | brlcad | better to have two really good applications with a strong patch than four crappy applications with a crappy patch ;) |
| 00:05.16 | brlcad | starseeker: *nod* all string literals are equivalent to the concatenation of them broken up like that |
| 00:05.48 | brlcad | so you can't use it to get over the 509 char limit in C90, but it is useful if you need to inject comments or assist with layout |
| 00:07.33 | CIA-52 | BRL-CAD: 03starseeker * r44044 10/brlcad/trunk/src/libged/red.c: Rename to avoid confusion - the point of that regex is to look for anything except whitespace, not whitespace. |
| 00:13.02 | starseeker | please please please let this be the last of the showstopper red bugs... |
| 00:15.31 | brlcad | i'm still chasing the logic through for how it was causing that crash in the first place |
| 00:15.59 | brlcad | for my trace, it was deep in libbn checking if a mat is identity .. so it was bogus memory |
| 00:16.06 | brlcad | hopefully the zero-init will make that not happen |
| 00:16.50 | starseeker | nods |
| 00:17.08 | starseeker | maybe that would explain why the different crash on 10.6 vs. 10.5? |
| 00:19.26 | brlcad | sure, it's just random memory |
| 00:19.38 | brlcad | something is wrong with the tree structure |
| 00:19.50 | brlcad | i'm guessing that the regex fails to parse a matrix, so it never sets the matrix |
| 00:19.58 | brlcad | then gets to code that attempts to validate the matrix |
| 00:20.10 | brlcad | and boom |
| 00:20.38 | brlcad | but you could also get a boom from any of the other fields too, or the tree structure might happen to be a valid previous tree node and you'd get further, etc |
| 00:22.18 | brlcad | so far, though, I don't see how we've actually fixed a bug yet other than you finding the space in the regex |
| 00:25.38 | starseeker | one if the if statements was backwards too |
| 00:25.57 | starseeker | but yeah, neither of those seem to relate directly to that weird issue |
| 00:28.40 | brlcad | it wasn't though, the return statements was swapped |
| 00:28.47 | brlcad | unless it was wrong before all of this too |
| 00:28.57 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832 flipped them |
| 00:34.18 | CIA-52 | BRL-CAD: 03brlcad * r44045 10/brlcad/trunk/src/ (30 files in 12 dirs): consistently call BU_GETUNION() to allocate a new union tree node and RT_INIT_TREE() to initialize that node instead of setting the magic value directly. |
| 00:36.20 | brlcad | okay, now to rebuild and see if that makes any difference whatsoever |
| 00:52.05 | starseeker | brlcad: oh, I was referring to a different one - I think it was wrong to start with |
| 00:54.46 | brlcad | starseeker: so recap, you can't change the name during red right? |
| 00:57.57 | brlcad | also, matrix edits during red are not working in my testing, they get ignored |
| 00:58.34 | brlcad | good/bad news, though .. can't get it to crash |
| 01:00.49 | CIA-52 | BRL-CAD: 03brlcad * r44046 10/brlcad/trunk/TODO: keep seems to be working, red is no longer crashing but isn't editing matrices either |
| 01:01.03 | brlcad | at least, keep tested clean on linux |
| 01:09.08 | *** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net) | |
| 01:09.18 | yukonbob | hello, #brlcad |
| 01:11.02 | *** join/#brlcad crazy_imp (~mj@a89-182-208-48.net-htp.de) | |
| 01:27.03 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 01:57.29 | brlcad | howdy yukonbob |
| 01:57.54 | brlcad | starseeker: just noticed that your crash report was on the same tree node member, the matrix |
| 01:58.10 | brlcad | so undoubtedly related to setting it during red |
| 02:09.48 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 02:26.28 | CIA-52 | BRL-CAD: 03brlcad * r44047 10/brlcad/trunk/src/libbu/stat.c: |
| 02:26.28 | CIA-52 | BRL-CAD: treat empty strings the same as null, i.e., a special case similar to NaN |
| 02:26.28 | CIA-52 | BRL-CAD: implying not a file so never will match true even if stat() might. similarly, |
| 02:26.28 | CIA-52 | BRL-CAD: for comparing to files, empty strings should never match. (two empty string |
| 02:26.29 | CIA-52 | BRL-CAD: filenames are not the same file, they are no file). |
| 02:29.38 | starseeker | brlcad: that's very odd - I was able to edit a matrix earlier today... |
| 02:30.17 | starseeker | yeah, logic for name change isn't present yet |
| 02:30.30 | CIA-52 | BRL-CAD: 03brlcad * r44048 10/brlcad/trunk/include/bu.h: document the behavior on empty strings |
| 02:31.25 | brlcad | k |
| 02:31.36 | CIA-52 | BRL-CAD: 03brlcad * r44049 10/brlcad/trunk/src/libged/red.c: |
| 02:31.38 | CIA-52 | BRL-CAD: another attempt at a logic cleanup, this time consolidating the memory cleanup |
| 02:31.38 | CIA-52 | BRL-CAD: and unlinking of the temp file to one place so that the file is consistently |
| 02:31.38 | CIA-52 | BRL-CAD: closed. some conditions weren't closing the file. this only modifies ged_red() |
| 02:31.38 | CIA-52 | BRL-CAD: and shouldn't be a change to flow logic. |
| 02:34.12 | starseeker | unfortunately, something about the ged string handling results in the error messages from ged_red getting squashed |
| 02:34.27 | starseeker | I recall Bob saying something about why that was once, but I don't recall |
| 02:34.59 | brlcad | all part of the refactoring suck |
| 02:35.10 | brlcad | some ged functions reset the result string, some don't |
| 02:35.23 | brlcad | so if you have a ged func that calls another ged func, it may or may not reset the result |
| 02:35.30 | starseeker | ah |
| 02:35.45 | brlcad | if the clean refactoring was complete, there'd be no need to reset the result in any func |
| 02:36.13 | brlcad | except the one top-level wrapper executing the main command |
| 02:36.32 | brlcad | if even then, could be a result array |
| 02:39.29 | CIA-52 | BRL-CAD: 03starseeker * r44050 10/brlcad/branches/cmake/ (46 files in 19 dirs): MFC r44049 |
| 02:39.42 | brlcad | starseeker: another curiosity, I edited a region with red and it listed rgb and color as an attribute |
| 02:39.55 | starseeker | both of them? |
| 02:39.57 | brlcad | looking at the logic in write_comb(), that shouldn't be possible since it's a standard attribute |
| 02:40.01 | brlcad | yep |
| 02:40.08 | starseeker | growl... |
| 02:40.34 | starseeker | it might be doing that if a pre-existing region has both... I don't recall |
| 02:41.02 | brlcad | fwiw, it was havoc, rt_r.pyl1 |
| 02:41.41 | brlcad | attr show only lists rgb |
| 02:42.25 | starseeker | if it's pulling color from the comb struct and rgb from attributes that MIGHT do it |
| 02:42.29 | starseeker | more likely I screwed up |
| 02:42.55 | brlcad | looks like write_comb() doesn't look at the struct members |
| 02:43.35 | starseeker | it's probably in the standardization routines then |
| 02:46.15 | brlcad | curious that you manually list the standard attributes just to get the max length for pretty printing |
| 02:47.38 | starseeker | brlcad: those routines are certainly candidates for improvement |
| 02:49.22 | brlcad | if I'm reading the correctly, it looks like it may even potentially update a read-only database |
| 02:49.44 | starseeker | winces |
| 02:50.02 | brlcad | ah, it'll try but then get bitched at lower-level by librt |
| 02:50.16 | brlcad | still.. the in-mem is modified |
| 03:01.40 | CIA-52 | BRL-CAD: 03brlcad * r44051 10/brlcad/trunk/TODO: note a few of the red issues remaining |
| 03:04.32 | CIA-52 | BRL-CAD: 03brlcad * r44052 10/brlcad/trunk/src/libged/ (ged_private.h put_comb.c): delims is only used in put_comb.c so it doesn't need to be an extern'd global. same for ged_tmpcomb. |
| 03:05.49 | CIA-52 | BRL-CAD: 03brlcad * r44053 10/brlcad/trunk/src/libged/red.c: |
| 03:05.49 | CIA-52 | BRL-CAD: delims was moved to put_comb, not used here. refactor the Combination Tree |
| 03:05.49 | CIA-52 | BRL-CAD: separator so it's only in one place. put the matching regexp up next to it so |
| 03:05.49 | CIA-52 | BRL-CAD: changes to one can be reflected in the other, otherwise will be brittle to |
| 03:05.49 | CIA-52 | BRL-CAD: future edits. |
| 03:07.12 | CIA-52 | BRL-CAD: 03brlcad * r44054 10/brlcad/trunk/src/libged/red.c: if the regex is going to have the newline, make the separator have it too |
| 03:30.12 | CIA-52 | BRL-CAD: 03brlcad * r44055 10/brlcad/trunk/src/libged/red.c: ouch. write_comb() needs a rewrite. it's modifying data it should not be modifying at this point in our processing. just asking for trouble. |
| 03:42.08 | CIA-52 | BRL-CAD: 03brlcad * r44056 10/brlcad/trunk/NEWS: with r44022, richard fixed two memory management issues introduced during a code audit that reduced the size of an allocation after a conversion from bu_malloc to bu_calloc as well as double-free on exit. |
| 03:47.24 | CIA-52 | BRL-CAD: 03brlcad * r44057 10/geomcore/trunk/src/GS/FileDataSource.cxx: if one iterator needs it, don't they both? |
| 04:00.46 | CIA-52 | BRL-CAD: 03brlcad * r44058 10/geomcore/trunk/src/GS/ (25 files in 2 dirs): attack of ws indent format consistency. remove useless header metadata. |
| 05:26.37 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 05:41.45 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 06:16.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:18.19 | *** join/#brlcad siddharth__ (~siddharth@117.211.88.150) | |
| 06:33.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:00.27 | *** join/#brlcad siddharth_ (~siddharth@117.211.88.150) | |
| 07:07.53 | *** join/#brlcad siddharth__ (~siddharth@117.211.88.150) | |
| 08:51.39 | *** join/#brlcad pawleeq (~pavel@pc119.iabrno.cz) | |
| 10:21.28 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 10:58.10 | dloman | Merin all |
| 11:10.05 | *** join/#brlcad siddharth__ (~siddharth@117.211.88.150) | |
| 11:21.04 | dloman | brlcad: Is there some 'good coding practice' that I am unaware of coming to play at FileDataSource.cxx:53 ? Why do we need to incr the iterator if its not going to be used again? |
| 11:28.10 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 11:34.37 | CIA-52 | BRL-CAD: 03davidloman * r44059 10/geomcore/trunk/ (include/Portal.h src/libNet/Portal.cxx): Add convenience method for sending a typeonly msg to client. |
| 11:38.14 | CIA-52 | BRL-CAD: 03davidloman * r44060 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): Stub in BRLCAD::Object <-> GeometryChunkMsg functions. Simplfy Msg handling by using new Portal::sendTypeOnly() method. |
| 12:23.17 | brlcad | dloman: not really, only if someone came to that block later and turned it into a loop |
| 12:27.43 | brlcad | I presume that function is incomplete in some fashion? |
| 12:27.43 | CIA-52 | BRL-CAD: 03brlcad * r44061 10/geomcore/trunk/src/GS/FileDataSource.cxx: not a loop, no need to increment. odd pulling first 'top' object though. |
| 12:27.58 | *** join/#brlcad Elrohir (~kvirc@p5B14A416.dip.t-dialin.net) | |
| 12:33.11 | dloman | brlcad: just the way the core interfaces are setup leads to the only real way to arbitrarily get top objects is via an iterator and the only way to get the iterator is to use the TopObjectIterator() |
| 12:33.39 | dloman | when i have the time, i plan on expanding the ConstDatabase/Database/MemoryDatabase functionality. |
| 12:34.40 | dloman | getObj() assumes you only want 1 object, and that's because in our design, many of the .g files in the repo are going to only have 1 object. |
| 12:37.10 | dloman | FFA question: If i want to use memcpy to copy to a char*, but start at the 5th char into the array, can i word it like: memcpy(dest+4,src,length) ? |
| 12:38.32 | brlcad | I saw getObj as give me any object from a .g, not necessarily a top object |
| 12:39.26 | brlcad | and yes re. memcpy |
| 12:41.08 | dloman | the coreInterface classes don't allow you to directly get an object with out knowing its (string) name, and there is no way to get that name unless you iterate, starting at the top. |
| 12:42.09 | dloman | tree walking to build an array of Objects hasn't been implemented yet, but thats ultimately what getObjs will do. |
| 12:42.17 | brlcad | sure, that's the same with librt too |
| 12:42.20 | dloman | likely get to that today. |
| 12:42.30 | brlcad | that getObj() routine sounds like a routine to get a specific named object |
| 12:43.40 | dloman | the fn documentation will come soon, no worries. |
| 12:43.43 | brlcad | so if it has the name, there should be no involvement of TopObjectIterator() |
| 12:44.43 | brlcad | heh, so fix the problem by changing the function definition? .. the name alone implied that (which is a good thing) |
| 12:46.29 | dloman | dude, its a name. can be changed at any time. small potatoes at this point, especially when everything isn't solidified quite yet. |
| 12:47.47 | brlcad | of course, that's expected |
| 12:47.53 | brlcad | just looking for clarification |
| 12:48.31 | brlcad | trying to work on the code too, and if that's not a function that gets an object by name, then that obviously changes things |
| 12:49.42 | brlcad | if it is supposed to get an object by name, which is what seemed the more plausible (and useful) .. then the implementation didn't seem right |
| 12:50.06 | dloman | getObj() gets the single object at the repo 'path' |
| 12:50.21 | dloman | getObjs() gets multiple object at the repo 'path' |
| 12:51.10 | dloman | after implementing things now, it seems the use of getObj is nearly nothing, since getObjs can perform the same funciton by returning a list with one element. |
| 12:51.22 | brlcad | nods |
| 12:51.29 | brlcad | okay, that makes more sense then |
| 12:51.34 | dloman | performance and memory wise i am sure they are different. |
| 12:51.38 | brlcad | meh |
| 12:51.44 | dloman | but im just going to leave them both for now |
| 12:52.15 | brlcad | seems error prone to allow a getObj when there may be more than one object to randomly be given "the first one" |
| 12:53.59 | dloman | exactly why im thinking its going to go away soon, provided some profound reason to keep it. |
| 12:54.58 | brlcad | now a general getObj() that returns a specific object by name would be more useful |
| 12:55.16 | brlcad | but that gets into what you've named a path there and how that differs from a geometry path |
| 12:55.51 | brlcad | something to talk about later perhaps |
| 13:22.15 | CIA-52 | BRL-CAD: 03brlcad * r44062 10/brlcad/trunk/src/librt/db5_types.c: |
| 13:22.15 | CIA-52 | BRL-CAD: add a new routine that will return a standard attribute name by an index number, |
| 13:22.15 | CIA-52 | BRL-CAD: so that we have a way to iterate over all the standard attribute names. this |
| 13:22.15 | CIA-52 | BRL-CAD: simplifies db5_is_standard_attribut() iteration and lets us reuse the iteration |
| 13:22.15 | CIA-52 | BRL-CAD: elsewhere. |
| 13:27.37 | CIA-52 | BRL-CAD: 03brlcad * r44063 10/brlcad/trunk/src/librt/db5_types.c: swap los and air so that the index coincidentally matches the ATTR_* returned from db5_standardize_attribute() |
| 13:31.49 | dloman | d_rossberg: are you around? |
| 13:34.42 | CIA-52 | BRL-CAD: 03brlcad * r44064 10/brlcad/trunk/src/librt/db5_types.c: even better, make the index-based lookup exactly match the ATTR_* index value. convert to an enum for proper numeric indexing. |
| 13:38.18 | CIA-52 | BRL-CAD: 03brlcad * r44065 10/brlcad/trunk/src/librt/db5_types.c: document the need for these needing to not have gaps in their value. only specify the starting point to make is less error prone. add null case so gcc thinks we're covering all our bases. |
| 13:50.36 | CIA-52 | BRL-CAD: 03brlcad * r44066 10/brlcad/trunk/src/librt/db5_types.c: simplify db5_standardize_attribute() by unrolling the loops. we have to perform all the comparisons anyways until we get a match, so just list them. |
| 13:54.48 | dloman | d_rossberg: I'm having an issue with a Database.Get() call. |
| 13:55.34 | dloman | whenever i get an Object using .Get(), the object's internal db_i* and diectory* are NULL. |
| 13:56.11 | CIA-52 | BRL-CAD: 03brlcad * r44067 10/brlcad/trunk/src/librt/db5_types.c: shorten to attr |
| 13:58.37 | dloman | ConstDatabase::Get(char*)->ConstDatabase::get(char* ObjectCallback)->ObjectCallbackIntern::operator()->Arb8::Clone()->Arb8::Arb8->Object::Object->Object::Copy() |
| 13:58.41 | dloman | thats the stack trace |
| 13:59.20 | dloman | I don't ever see the m_dbip, m_pDir, or m_ip get copied. |
| 13:59.24 | dloman | ...is that by design? |
| 14:01.18 | brlcad | starseeker: can you help? what is db5_standardize_avs() supposed to do? I don't understand the comment |
| 14:01.57 | starseeker | brlcad: one sec... |
| 14:03.47 | CIA-52 | BRL-CAD: 03starseeker * r44068 10/brlcad/branches/cmake/ (6 files in 3 dirs): MFC r44067 |
| 14:04.17 | starseeker | hrm... yeah, looks like brain backfired on that comment |
| 14:04.21 | starseeker | checks code... |
| 14:05.20 | starseeker | OK, I think this was the thinking... |
| 14:05.30 | brlcad | see if that says it |
| 14:05.34 | CIA-52 | BRL-CAD: 03brlcad * r44069 10/brlcad/trunk/src/librt/db5_types.c: update comment for db5_standardize_avs(). is my understanding correct? |
| 14:06.14 | starseeker | yeah, that's pretty much it |
| 14:06.41 | starseeker | I think it might remove the old attribute that it's replacing with the new one, but will leave additional matches alone |
| 14:06.45 | starseeker | let me check that though |
| 14:07.08 | brlcad | yeah, I was thinking it should remove all the matches |
| 14:07.25 | starseeker | the problem with that is if an existing comb has both color and rgb |
| 14:07.29 | starseeker | with different values |
| 14:07.41 | brlcad | sure, but what does that mean? |
| 14:08.06 | starseeker | who knows? but picking one means destroying one of the color settings, if we erase both of the old ones |
| 14:08.41 | starseeker | yesh, looks like that one isn't doing any erasing |
| 14:08.47 | starseeker | so your comment is right |
| 14:08.50 | brlcad | okay,that's cool |
| 14:09.05 | brlcad | i'd think we'd either wipe them all out with the new or leave them all intact and add new |
| 14:09.30 | brlcad | we don't know what that data is but technically "we own it" because it's in the reserved namespace |
| 14:09.37 | starseeker | nods - that MIGHT be why you were seeing multiple color settings on that havoc region... |
| 14:09.51 | brlcad | possibly |
| 14:10.12 | brlcad | though later in red, you go through the whole update/apply thing that should have consolidated |
| 14:10.17 | brlcad | maybe |
| 14:10.28 | brlcad | hello hyarion |
| 14:10.57 | hyarion | hi |
| 14:11.52 | d_rossberg | dloman: see the docu of Get() in ConstDatabase.h: this method returns a copy of the object |
| 14:12.09 | dloman | the copy is disconnected from any database then? |
| 14:12.15 | dloman | ...by design? |
| 14:12.18 | d_rossberg | this seams to be a good idea because you close the database after each operation ;) |
| 14:13.02 | dloman | righto, that part is sensible. |
| 14:13.26 | dloman | just want to make sure I'm understanding your code correctly. |
| 14:14.48 | d_rossberg | the deeper reason is the following: |
| 14:16.27 | d_rossberg | rt_db_get_internal() (as used in the Get()) always gives you a copy of the database object on a rt_db_internal structure |
| 14:17.39 | d_rossberg | therefore you have to carefully choose the moment when to write back rt_db_internal into the database |
| 14:17.49 | starseeker | brlcad: yeah, it looks like what's happening is db5_update_std_attributes is ensuring that all of the standard attributes correspond to the comb structure values - in the process, it's creating any that aren't already there (like color in the case of rt_r.pyl1) |
| 14:18.47 | d_rossberg | i'm doing it usually when the callback returns (see the callback version of Get()) |
| 14:19.21 | d_rossberg | i.e. the non-const Get() in Database.h |
| 14:19.32 | starseeker | but since I was trying to go with the "don't destroy information" policy, rgb got left |
| 14:20.46 | brlcad | that's great |
| 14:21.04 | brlcad | defaulting to don't destroy is always right :) |
| 14:21.20 | d_rossberg | another possibility is to take a copy of the Object explicitely (as you did) and leave it to the user to write it back to the database with Set() |
| 14:21.41 | starseeker | also, I don't think db5_apply_std_attributes will remove excess extra settings... |
| 14:21.48 | starseeker | so that part of the comment may need updating |
| 14:21.53 | brlcad | k |
| 14:22.17 | starseeker | we can make a function to do that, but I'd prefer it to be a separate call so the decision to possibly destroy data is isolated |
| 14:22.17 | brlcad | i'm simplifying standardize_avs() a bit now, given there's a function that will return the name by type |
| 14:22.23 | starseeker | cool |
| 14:22.35 | brlcad | reduces almost all of the cases to just add |
| 14:22.47 | d_rossberg | or for short: Object is the C++ form of rt_db_internal which contains a copy of an database element |
| 14:23.06 | starseeker | now remember why that took so long... lots of annoying little questions to sort out... |
| 14:23.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.60) | |
| 14:23.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:23.59 | dloman | d_rossberg: awesome, thanks man. I figured out that in order to properly extract a bu_external from an Object, i should use an ObjectCallback |
| 14:24.34 | starseeker | brlcad: probably the correct thing to do is if there is just one color attribute (e.g. rgb) it should get renamed |
| 14:24.40 | starseeker | so that may be a bug |
| 14:25.04 | brlcad | hm |
| 14:25.19 | starseeker | I thought I had some "first hit for type T" logic that would rename, but maybe I took it out as too complicated in the inital cut |
| 14:25.32 | brlcad | it's half in there :) |
| 14:25.37 | brlcad | some of the types don't use it |
| 14:25.50 | starseeker | ah, crud |
| 14:26.02 | d_rossberg | dloman: btw: Object has full attribute support including iteration |
| 14:26.44 | starseeker | we can get fancier by checking the value of subsequent hits of the same type against the stored standard type, and only keep them (and display them) if they're different |
| 14:27.05 | brlcad | still, I see this as an in-memory "upgrade my avs" routine .. so it can convert any it finds, consolidate any that are the same value, and otherwise rename the first to standard form |
| 14:27.06 | starseeker | that's probably the best case - preserve and display conflicting data if it actually conflicts, otherwise standardize |
| 14:27.22 | starseeker | er, yeah :-) |
| 14:33.24 | brlcad | had a memory leak in there bu_avs_add() already copies the value for you |
| 14:33.49 | starseeker | ah |
| 14:34.02 | CIA-52 | BRL-CAD: 03starseeker * r44070 10/brlcad/trunk/include/raytrace.h: Update db5_is_standard_attribute in raytrace.h |
| 14:39.13 | CIA-52 | BRL-CAD: 03starseeker * r44071 10/brlcad/trunk/src/libged/red.c: fix red.c extern too |
| 14:40.29 | d_rossberg | dloman: ps: this way you can copy an Object from one database to another: Get() from the first one and Add() to the other one |
| 14:40.53 | dloman | excellent |
| 14:41.14 | dloman | I am actually looking to properly create a bu_external, which requires a valid db_i* and directory* |
| 14:41.59 | brlcad | dloman: only that one routine required a db_i, there are other routines that work with data in other stages of the i/o process |
| 14:42.13 | brlcad | might be something else that can be used |
| 14:42.33 | brlcad | looks |
| 14:45.38 | brlcad | what data do you have now? |
| 14:45.47 | brlcad | an rt_db_internal *? |
| 14:47.08 | dloman | well, if hook into ab Object before it gets .Clone()-ed, then i will have everything (db_i, rt_db_internal*, resource* and directory*) |
| 14:47.16 | dloman | otherwise, i have none of those. |
| 14:47.46 | brlcad | none? if it made a copy, you ahve at least the rt_db_internal I'd think |
| 14:48.00 | d_rossberg | dloman: for low level operations you should consider to use the C API directly, the C++ interface is definitely not the place for such tasks |
| 14:49.10 | d_rossberg | no, he has nothing because the database will be closed after getting the object |
| 14:49.30 | brlcad | d_rossberg: we could still encapsulate serialization as something inherent to an Object, a Serialize() routine that returns a bu_external for example |
| 14:50.17 | brlcad | d_rossberg: then how'd it 'get' the object? extracts values into private member data from the db_intern? |
| 14:52.25 | d_rossberg | it has a private char* for the name, bu_attribute_value_set for the attributes and rt_~_internal for the element specific stuff |
| 14:53.10 | brlcad | ah, so it fully uncracks the rt_db_internal |
| 14:53.19 | d_rossberg | and serialization isn't trivial, it depends on the protocol used and purpose |
| 14:53.51 | d_rossberg | e.g. i would prefer a serialization in xml |
| 14:54.10 | brlcad | heh |
| 14:54.36 | d_rossberg | or with other words: this is something for the level above the core interface |
| 14:55.34 | brlcad | and/or below it |
| 14:56.24 | brlcad | i could still see it providing some default serialization capability that it could use for persistence and reconstruction |
| 14:56.26 | d_rossberg | for the network my first idea would be to use something like corba |
| 14:57.13 | brlcad | but that's so much overhead ... |
| 14:57.45 | brlcad | and nobody likes writing corba code :) |
| 14:58.00 | d_rossberg | this point is on you :) |
| 14:58.01 | brlcad | except businesses that are paid/forced to :) |
| 14:59.15 | *** join/#brlcad Elrohir (~kvirc@p5B14A416.dip.t-dialin.net) | |
| 15:01.27 | dloman | who knew the Dune soundtrack makes cood coding music..... |
| 15:02.18 | d_rossberg | however, the "default serialization" should >mainly< (whatever this will mean) be database independend because it is used in an abstraction layer |
| 15:03.21 | brlcad | yeah, I'd think you'd want it to be a black box serialization |
| 15:04.11 | brlcad | either to a generic form (like xml, shudder!) or to an opaque type that you aren't supposed to inspect beyond passing to a Deserialize() call |
| 15:04.47 | brlcad | I was thinking more the latter and just ganging up on the existing serialization routines used for disk since they're compact and really fast |
| 15:05.29 | starseeker | yeah... I thought the external disk format was a serialization - is there some situation where that's not appropriate? |
| 15:05.45 | starseeker | xml I can see only as an archival ascii format (maybe)\ |
| 15:05.54 | brlcad | starseeker: it's "not appropriate" if you don't want to deal with binary data :) |
| 15:06.06 | starseeker | ah heh |
| 15:06.20 | brlcad | or want to pass it through some other parsing engine |
| 15:06.49 | brlcad | converting to asc is technically a serialization too, just a not very interesting one |
| 15:07.42 | d_rossberg | it is the most interesting one: ican read it |
| 15:08.02 | brlcad | how about json then? even easier to read ;) |
| 15:08.14 | brlcad | and less verbose |
| 15:08.18 | d_rossberg | json who? |
| 15:08.20 | brlcad | runs and hides |
| 15:08.40 | dloman | should I call BU_INIT_EXTERNAL on a bu_external prior to passing the bu_external into db_get_external(..) ? |
| 15:09.16 | d_rossberg | wasn't there a windows ini-file format? |
| 15:09.53 | brlcad | dloman: not necessary |
| 15:10.11 | brlcad | d_rossberg: heh, now you're just talking crazy ;) |
| 15:10.50 | brlcad | that's about as bad as a self-unarchiving shell script |
| 15:12.44 | starseeker | d_rossberg: http://www.json.org/ |
| 15:13.33 | starseeker | http://oss.metaparadigm.com/json-c/ would probably be useful |
| 15:13.46 | brlcad | I think he was being facetious |
| 15:13.52 | starseeker | ah |
| 15:19.27 | starseeker | brlcad: fwiw, a comb with only one entry and a matrix on that entry DOES allow me to save the change |
| 15:19.44 | starseeker | it's where there are multiple entries in the comb tree with matricies that I can confirm the failure |
| 15:19.52 | brlcad | okay |
| 15:23.12 | dloman | anyone familiar with a Segfault dealing with _dl_fixup() in /lib64/ls-linux-x86-64.so.2 ? |
| 15:29.12 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:29.26 | brlcad | er... ld is trying to dynamically load something and it can't? |
| 15:29.39 | brlcad | shouldn't be any dynamic loading that I know if |
| 15:30.05 | dloman | i hate this crap :/ |
| 15:30.35 | brlcad | what'd you change that got you into that state? |
| 15:31.03 | brlcad | just back up to the previous commit, work forward in smaller steps |
| 15:31.13 | dloman | i literally copy/pasted a class, changed the guts of one function. |
| 15:32.59 | brlcad | are you using run-time type inference? |
| 15:33.06 | brlcad | in that class |
| 15:34.30 | dloman | i don't think i am |
| 15:34.57 | dloman | noob question: is subclassing considered type inferencing? |
| 15:35.30 | brlcad | then it "probably" was more than a simple copy/paste change, even if that's all you may have intended .. |
| 15:35.57 | brlcad | in general no, but subclassing a class that uses rtti might get you into trouble |
| 15:35.58 | dloman | heh, obviously something got messed up. :/ |
| 15:36.58 | brlcad | without sitting at a debug console, "back it up" is probably the easiest debug route to see where you went wrong |
| 15:37.33 | dloman | i've got it isolated down to a function call, but it doesnt make sense atm. still trying to figger it out. |
| 15:37.44 | brlcad | that error sounds like the dynamic linker saying "I can't find a class I'm told to use" |
| 15:39.45 | dloman | hrm, if I comment out the call to db_get_external(), everything works ..... |
| 15:40.13 | brlcad | are you linking librt? |
| 15:40.46 | brlcad | could be a bonefide crash due to bad data or bug and the _dl_fixup is just a red herring |
| 15:48.33 | brlcad | starseeker: I think I see how the attibute got double-listed |
| 15:48.55 | brlcad | rewriting db5_standarize_avs() is pretty tricky with all of the various cases |
| 16:05.25 | dloman | so its not a linker issue... i'm linking ALL of brlcad libraries. |
| 16:05.46 | dloman | but _dl_fixup is throwing the segfault, according to gdb |
| 16:11.41 | dloman | brlcad: you still around? |
| 16:14.35 | brlcad | yep |
| 16:15.00 | brlcad | where's it segfaulting, what's the rest of the stack? |
| 16:15.04 | dloman | Pro tip: Turns out that bu_malloc is handy for allocating memory for pointers. |
| 16:15.09 | dloman | just fyi |
| 16:15.14 | dloman | facepalms |
| 16:15.24 | brlcad | haha |
| 16:15.33 | brlcad | bu_calloc() is even better |
| 16:15.43 | dloman | yeah, whats the diffference? |
| 16:15.48 | brlcad | zeros the memory |
| 16:16.10 | dloman | costs a bit more cpu time? |
| 16:16.15 | brlcad | malloc will allocate you a memory buffer, but there could be any random garbage in that buffer |
| 16:16.28 | brlcad | insignificant |
| 16:16.49 | dloman | so there really is no reason to ever use anything other than calloc? |
| 16:16.53 | brlcad | the system call itself is two orders more expensive, so might as well spend one or two clock cycles and have fresh zero'd memory |
| 16:17.31 | brlcad | well, if the very first thing I was going to do with the memory was clear it or set it, then bu_malloc makes sense |
| 16:18.01 | brlcad | but talking full-allocation set, which doesn't happen very often |
| 16:19.30 | brlcad | basically, if you want to be a little more cautious and avoid some obscure bugs, use bu_calloc() until you know better :) |
| 16:20.00 | brlcad | it's never "wrong", it just might be unnecessary |
| 16:20.04 | dloman | bugs like me, thus i like calloc |
| 16:20.31 | brlcad | it's like initializing all your variables when you declare them |
| 16:20.38 | dloman | right on |
| 16:20.39 | brlcad | I tend to init to zero and/or NULL |
| 16:20.52 | brlcad | but if the very next thing I'm going to do with them is set their value, it was pointless |
| 16:21.19 | brlcad | if I don't set their value until later down in the function, it might actually save my butt some day to init them |
| 16:21.29 | brlcad | it might save me down the road anyways if I just init them |
| 16:22.15 | brlcad | starseeker: if you care to double-check my logic on this, I think I have it |
| 16:24.12 | CIA-52 | BRL-CAD: 03davidloman * r44072 10/rt^3/trunk/ (4 files in 2 dirs): Added the ability to get a bu_external* from a ConstDatabase and Object. Needed for serialization |
| 16:25.42 | CIA-52 | BRL-CAD: 03brlcad * r44073 10/brlcad/trunk/ (include/raytrace.h src/librt/db5_types.c): |
| 16:25.42 | CIA-52 | BRL-CAD: document the db5_standard* functions, pulling comments from source to header and |
| 16:25.42 | CIA-52 | BRL-CAD: expanding with a note that they're new/private. reimplement |
| 16:25.42 | CIA-52 | BRL-CAD: db5_standardize_avs() using simple two-pass logic so standard attributes take |
| 16:25.42 | CIA-52 | BRL-CAD: precedence. use db5_standard_attribute() in conjunction with |
| 16:25.42 | CIA-52 | BRL-CAD: db5_standardize_attribute() in leu of tables so we don't have to repeat any |
| 16:25.43 | CIA-52 | BRL-CAD: values or even be aware of what is standard or not. |
| 16:25.47 | brlcad | that should prevent the double-listing |
| 16:46.50 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.60) | |
| 16:46.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:15.22 | starseeker | brlcad: looks good |
| 17:25.02 | CIA-52 | BRL-CAD: 03davidloman * r44074 10/geomcore/trunk/ (7 files in 4 dirs): Clean up a few bugs in ByteArray. Added ByteArray copy cstr. Converted GenericMultibyteMsg and GeometryChunk to use ByteArray objects (since they are thin wrappers around bu_vls) |
| 17:26.32 | CIA-52 | BRL-CAD: 03starseeker * r44075 10/brlcad/trunk/src/libged/red.c: Looks like this might be the culprit - combtree_op_regex with blank seems to work for matricies |
| 17:27.04 | starseeker | brlcad: does that let you edit matricies? |
| 17:43.19 | CIA-52 | BRL-CAD: 03erikgreenwald * r44076 10/brlcad/trunk/src/libged/red.c: include raytrace.h for prototype. remove extern func decl |
| 17:52.42 | CIA-52 | BRL-CAD: 03davidloman * r44077 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): put in bu_external<->GeometryChunkMsg conversion functions. |
| 18:06.54 | CIA-52 | BRL-CAD: 03davidloman * r44078 10/geomcore/trunk/include/GeometryChunkMsg.h: Forgot a file in the ByteArray cleanup.... |
| 18:20.15 | brlcad | starseeker: testing |
| 18:24.26 | starseeker | brlcad: I see you listed red comb renaming as something to support for the next release? |
| 18:25.10 | brlcad | with all this attention needing to go towards red, might as well finish it while it's all in context |
| 18:25.33 | brlcad | otherwise it'll never get done unless there's another set of bugs |
| 18:25.36 | starseeker | so we should make write_comb work on copies as well? |
| 18:26.17 | brlcad | yeah, I was basically reviewing from top to bottom |
| 18:26.48 | brlcad | got to the attr stuff, and a bit more to finish up in there |
| 18:27.40 | brlcad | sorting out what this std avs api should look like now |
| 18:29.05 | brlcad | if you want to hit up write_comb in the meantime, you're welcome to but might be less conflict if you work either on recognizing the name change or making sure the read-in is robust |
| 18:29.28 | starseeker | is working on the rename |
| 18:30.04 | brlcad | basically just trying to get things to a no-hack "done" state without adding any new functionality/features |
| 18:30.48 | brlcad | nice work on the std avs stuff by the way -- the functions work pretty well together |
| 18:30.57 | brlcad | just that one missing so far, and maybe some name cleanup |
| 18:31.12 | starseeker | thanks :-) |
| 18:32.07 | CIA-52 | BRL-CAD: 03brlcad * r44079 10/brlcad/trunk/include/raytrace.h: add the other 'new' attr funcs that are needed for the symbols to get published. still a work-in-progress. |
| 18:32.49 | CIA-52 | BRL-CAD: 03brlcad * r44080 10/brlcad/trunk/include/raytrace.h: private funcs till names get changed |
| 18:32.59 | starseeker | is there a case-insenstivie version of the bu string comparison macro? |
| 18:33.54 | brlcad | we use something in a few other places, maybe strcasecmp |
| 18:35.48 | brlcad | yeah, we surprisingly don't do a lot of string-insensitive comparisons |
| 18:35.59 | brlcad | libfb options |
| 18:39.08 | brlcad | might be simple enough to add a BU_STRI_EQUAL and friends |
| 18:39.40 | brlcad | or BU_STRCASE_EQUAL |
| 18:45.16 | brlcad | starseeker: the other thing I wanted to change .. you have all that logic in write_comb for pretty-printing, but standard printf has options that do most of that built-in |
| 18:48.32 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 18:49.16 | AbhijitKane | brlcad: do you have any info on the old material database / website? |
| 18:52.12 | brlcad | AbhijitKane: yes, I do |
| 18:52.13 | CIA-52 | BRL-CAD: 03erikgreenwald * r44081 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: Flush output buffer at end of msg write. Implement implement ping, info, fail, ok, rualive and imalive. |
| 18:52.52 | AbhijitKane | brlcad: i've started with a draft proposal, and was wondering what i could add to it |
| 18:58.39 | kunigami | hi, which string should be passed to bu_malloc and bu_free? |
| 18:59.17 | ``Erik | anything that explains what the memory is for, it's to help in debugging |
| 19:00.34 | brlcad | AbhijitKane: the existing dev interface is at mater.brlcad.org |
| 19:00.56 | starseeker | brlcad: ah, figures |
| 19:01.16 | AbhijitKane | nods |
| 19:01.24 | starseeker | wades into the rename logic... |
| 19:01.31 | kunigami | ok. I'll pass the name of the first pointer for which the memory is being allocated |
| 19:01.36 | starseeker | let there be build failures! |
| 19:02.04 | brlcad | kunigami: just something short but descriptive "alloc foo", "free foo" |
| 19:02.35 | brlcad | the bu_calloc/bu_malloc string should pair up with the bu_free() string |
| 19:03.15 | brlcad | not necessarily the same string, but if you were reading a log file, some reasonable pairing so you could check the pairings if you needed to |
| 19:04.26 | kunigami | hmm what if I allocated in bu_basename as bu_malloc(..., "foo"), then I tell in the documentation that bu_free(..., "foo") should be called? |
| 19:05.09 | brlcad | not necessary |
| 19:05.39 | brlcad | maybe "bu_basename alloc" |
| 19:08.40 | kunigami | then bu_free(..., "bu_basename free")? |
| 19:10.39 | brlcad | well the free happens in userland code, not library code so you don't really have any control over that |
| 19:14.26 | kunigami | hmm, understood. so I'll just do bu_free(var, "var free"). sounds good? |
| 19:15.33 | brlcad | kunigami: but where are you calling bu_free? |
| 19:15.57 | AbhijitKane | brlcad: regarding the materials site, could there be google/openID integration as well? |
| 19:15.57 | AbhijitKane | <PROTECTED> |
| 19:16.27 | kunigami | right before the scope of the variable returned by bu_basename ends |
| 19:16.28 | CIA-52 | BRL-CAD: 03davidloman * r44082 10/geomcore/trunk/src/libNet/NetMsgRouter.cxx: Use the word 'routing' instead of 'forwarding' when talking about the routing of NetMsgs. Confused some people, this is better. |
| 19:16.32 | brlcad | AbhijitKane: the issue there is we presently have accounts in drupal and mediawiki ... there was an effort to integrate them into one ldap but that's incomplete |
| 19:17.35 | brlcad | adding in google/openID adds more account auth but doesn't integrate with the other two, so not much of a benefit integration-wise |
| 19:17.52 | brlcad | now if you also update our drupal/MW installs to use google/openID, then that'd be different |
| 19:18.07 | brlcad | could be a little subtask |
| 19:18.59 | AbhijitKane | ok |
| 19:19.00 | brlcad | otherwise, auth is a much lesser concern to getting add/edit/inherit/view/delete working cleanly |
| 19:20.14 | AbhijitKane | yes, getting the crud operations working properly will be the first priority |
| 19:20.57 | brlcad | crud? :) |
| 19:22.30 | AbhijitKane | create read update delete. but i'm not sure whether i'm using it in the right context, lol |
| 19:22.36 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2781 10/wiki/NetMsgTypes: add more info |
| 19:23.48 | kunigami | in brlcad_path.c there's a line: return bu_basename(bu_progname); --- where bu_progname is a global variable. how to proceed? |
| 19:24.27 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2782 10/wiki/GeometryReqMsg: New page: Message sent to the server to request data. Single GSString with a URI/URN style encoding of the geometry (path/to/file.g/top). (Should this be a multistring message?) |
| 19:26.27 | brlcad | kunigami: probably something similar to bu_argv0_full_path() where it has an internal static buffer, get the basename, copy into buffer, free the basename, return the buffer |
| 19:27.42 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2783 10/wiki/GeometryManifestMsg: New page: Sent after a geometry req is recv'd, but before the chunks are sent. uint32 number of objects/strings/chunks. List of GSStrings for returned objects. ReUUID is the same as the GeometryR... |
| 19:30.24 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2784 10/wiki/GeometryChunkMsg: New page: Actual raw binary V5 .g goodness. ReUUID is the same as the associated GeometryReqMsg's UUID. There will be the same number of these as there were entries in the GeometryManifest. NOT ... |
| 19:31.41 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2785 10/wiki/GeometryChunkMsg: mention length in stream |
| 19:33.24 | kunigami | brlcad: hmm good idea |
| 19:33.35 | CIA-52 | BRL-CAD: 03starseeker * r44083 10/brlcad/trunk/src/libged/red.c: Add the ability for changing name assignment in the red.c text file to rename the comb being edited. |
| 19:33.41 | starseeker | brlcad: there we go |
| 19:33.50 | brlcad | starseeker: awesome |
| 19:34.22 | brlcad | btw, just found (and hopefully fixed) a particularly egregious bu avs iterator bug |
| 19:34.23 | starseeker | needs another set of eyes, but it seems to work here |
| 19:34.39 | starseeker | in red or in libbu? |
| 19:34.45 | brlcad | libbu |
| 19:34.50 | starseeker | ow |
| 19:34.58 | brlcad | the BU_AVS_FOR() macro iterates from the end to the front, from count-1 |
| 19:35.08 | brlcad | so if count == 0 ... poof |
| 19:35.14 | starseeker | winces |
| 19:35.31 | starseeker | yeah, that's not good... |
| 19:38.04 | CIA-52 | BRL-CAD: 03starseeker * r44084 10/brlcad/trunk/TODO: r_weiss fixed dem-g crashes |
| 19:38.14 | CIA-52 | BRL-CAD: 03brlcad * r44085 10/brlcad/trunk/include/bu.h: |
| 19:38.14 | CIA-52 | BRL-CAD: bad AVS, no donut for you. BU_AVS_FOR() macro iterator starts from the end of |
| 19:38.14 | CIA-52 | BRL-CAD: the avs to the beginning. however, if the avs is empty, this would result in |
| 19:38.14 | CIA-52 | BRL-CAD: indexing into a -1 index and potentially cause a segfault. make the loop safe |
| 19:38.15 | CIA-52 | BRL-CAD: by setting it to null if count is zero, so it should kick right out of the loop. |
| 19:39.21 | brlcad | hm, that's insufficient |
| 19:43.47 | CIA-52 | BRL-CAD: 03davidloman * r44086 10/geomcore/trunk/ (include/SvnDataSource.h src/GS/SvnDataSource.cxx): Implement required functions for SvnDataSource as spelled out by IDataSource |
| 19:50.56 | CIA-52 | BRL-CAD: 03davidloman * r44087 10/geomcore/trunk/ (3 files in 2 dirs): Update data sources to pass back bu_externals instead of Objects. This isn't optimal, nor do i think it will be permanent, but its the best approach at the moment. |
| 19:52.40 | CIA-52 | BRL-CAD: 03erikgreenwald * r44088 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement geomreqmsg and geommanifestreq. stub geomchunkmsg. |
| 19:54.37 | CIA-52 | BRL-CAD: 03davidloman * r44089 10/geomcore/trunk/src/GS/DataManager.cxx: Make DataManager handle bu_externals rather than Objects |
| 19:56.46 | CIA-52 | BRL-CAD: 03brlcad * r44090 10/brlcad/trunk/include/bu.h: need to make sure we don't enter the loop with that NULL pointer. halt if iterator or target is NULL |
| 19:57.54 | brlcad | there, that should allow looping over empty avs |
| 19:57.58 | CIA-52 | BRL-CAD: 03davidloman * r44091 10/geomcore/trunk/tests/GS/ (CMakeLists.txt FileDataSourceTest.cxx): lots of cascading changes to FileDataSourceTest |
| 20:01.37 | CIA-52 | BRL-CAD: 03brlcad * r44092 10/brlcad/trunk/include/bu.h: go a step further and don't try to dereference the avs if we get handed a NULL pointer. one more example of the lengths we go to for you. because we care. |
| 20:04.34 | dloman | lol nice one. |
| 20:04.51 | dloman | that's a bumper sticker if i've ever seen one. |
| 20:06.29 | *** join/#brlcad volock (~chatzilla@174.46.225.138) | |
| 20:07.39 | CIA-52 | BRL-CAD: 03brlcad * r44093 10/brlcad/trunk/include/bu.h: document BU_AVS_FOR() macro with an example code snippet. |
| 20:10.59 | CIA-52 | BRL-CAD: 03brlcad * r44094 10/brlcad/trunk/include/bu.h: tweakage |
| 20:11.52 | kunigami | in nirt/if.c there's a external array, ValTab. There are at least two elements of ValTab that store the output of bu_basename. should I use the static buffer trick? |
| 20:13.37 | CIA-52 | BRL-CAD: 03brlcad * r44095 10/brlcad/trunk/src/librt/db5_types.c: use db5_standard_attribute() instead of hard-coding the standard attribute names in db5_apply_std_attributes(). also check our inputs in db5_standardize_avs(). |
| 20:16.17 | volock | <PROTECTED> |
| 20:16.18 | volock | ...though I've also used BSP and Oct Trees. I'm trying to think out how an API like is asked for should work. IE. What kind of data it'd be expecting, etc for crafting my proposal |
| 20:16.49 | brlcad | kunigami: at a glance, you can either wrap the output in bu_strdup() then free the memory at the end (see 'need_to_free' for similar issue) ... or you can reuse the existing regionPN buffer presuming ValTab is not used after that function |
| 20:16.54 | brlcad | hello volock |
| 20:17.44 | volock | hello brlcad. You're Chris right? |
| 20:18.03 | brlcad | some people call me that |
| 20:18.06 | brlcad | most call me Sean :) |
| 20:19.09 | volock | Ah. I was going from memory from reading the wiki you set up for us prospective GSoC people. You guys definitely have a lot of interesting coding to do, that looks like a lot of fun. Then again as an Applied Math and CS double major, my view may be a little skewed. |
| 20:20.58 | brlcad | thanks, most of us tend to think it's a lot of fun too |
| 20:21.24 | brlcad | as for the spatial partitioning project, the #1 difficulty there is going to be careful integration |
| 20:22.26 | brlcad | that gets at the very heart of our core library, which is highly optimized for our current purposes, customers, raytracing, etc |
| 20:23.22 | brlcad | ideally, you'd not only have pretty good familiarity with spatial partitioning but also with our LIBRT library and how it does what it does currently |
| 20:24.15 | brlcad | even something as simple as abstracting out what it currently does without affecting performance could be very tricky |
| 20:24.46 | brlcad | much harder to implement a completely different modular partitioning scheme that actually out-performs :) |
| 20:25.15 | brlcad | so that's not mean to scare or entice you, it's just the matter-of-facts surrounding that particular project |
| 20:26.39 | volock | Yeah. I have experience with Spatial Partitioning both from a raytracer and working for someone doing particle physics. Those were considerably simpler than this would be obviously. Not only because your problem contains performance constraints compared to what has probably been highly optimized code over years, but in the variety of data you'd want to easily send to the API |
| 20:32.07 | brlcad | the other kicker is that our spatial partitioning has to be at least partially aware of the construction hierarchy since we use constructive solid geometry (CSG) where there may be void regions or unknown overlap conditions |
| 20:32.15 | brlcad | we only rarely deal with polygons so all you really have for binning things together is a primitive's overall bounding box or bounding sphere |
| 20:32.17 | brlcad | so, what brought you to brl-cad's ideas list? |
| 20:32.21 | brlcad | or not |
| 20:32.41 | *** join/#brlcad volock (~chatzilla@174.46.225.138) | |
| 20:33.21 | kunigami | brlcad: is there any guarantee that after the 'need_to_free' region the memory allocated won't be used? |
| 20:33.45 | brlcad | didn't look through the code that closely, good question :) |
| 20:36.06 | kunigami | well, yesterday you said that if refactoring the code would take more than 15 minutes I should tell you :P I think I spent at least an hour on it :) |
| 20:38.06 | *** join/#brlcad volock (~chatzilla@174.46.225.215) | |
| 20:38.29 | volock | Sorry my internet connection decided to go out |
| 20:38.57 | brlcad | kunigami: yes, fair enough -- it's a task for someone, that doesn't necessarily need to be you right now |
| 20:39.25 | brlcad | if you're selected, maybe you can finish the job on your own patch if someone else hasn't by then :) |
| 20:41.05 | kunigami | hmm, ok. that's the only file that is not that trivial to change. All other ocurrences of bu_basename I've already changed. Should I re-submit the patch with this new changes for registration? |
| 20:42.35 | brlcad | absolutely |
| 20:43.04 | brlcad | helps to give them new name either on the file or the comment, so can tell which is the latest |
| 20:56.32 | CIA-52 | BRL-CAD: 03erikgreenwald * r44096 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement chunking protocol. Add "getgeom" conviencience function |
| 20:58.50 | kunigami | brlcad: ok, I'll append a version on it |
| 21:11.03 | kunigami | If I write more than one proposal and both are accepted, will you take into consideration the priority of my choices? |
| 21:13.50 | brlcad | both can't be accepted -- we'd narrow it down to one or the other |
| 21:14.15 | brlcad | but that said, your interest definitely matters too, so write down your priority in the proposal too |
| 21:15.54 | kunigami | hmm ok |
| 21:17.52 | brlcad | proposals often do get changed throughout the course of the summer too, so long as we're both in agreement on the goals and approach as things change |
| 21:18.43 | brlcad | again, we care more about integrating new developers than we do about getting a particular chunk of code written |
| 21:22.21 | CIA-52 | BRL-CAD: 03starseeker * r44097 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44096 |
| 21:25.33 | kunigami | perfect! |
| 21:27.31 | kunigami | hmm, does anyone know if melange allows editing the proposal? or if I want my proposal to be reviewed I should write it in other place (google docs for example) and send only the final revision to melange? |
| 21:28.57 | brlcad | yes, you can continue to edit up to the deadline |
| 21:29.09 | brlcad | we will write questions and comments there too |
| 21:29.28 | brlcad | if you want feedback beforehand, suggest wiki or google docs |
| 21:29.50 | brlcad | otherwise, not much difference when/where the comments occur -- other than the earlier the better |
| 21:30.01 | brlcad | gets really hectic in the last few days |
| 21:39.48 | *** join/#brlcad ``Erik (~erik@BRLCAD.ORG) | |
| 21:39.51 | CIA-52 | BRL-CAD: 03erikgreenwald * r44098 10/geomcore/trunk/src/interfaces/cl/ (gsclient.asd gsclient.lisp gsnet.lisp): break GS net ops into seperate package |
| 21:56.29 | CIA-52 | BRL-CAD: 03starseeker * r44099 10/geomcore/trunk/tests/svntest/ (CMakeLists.txt main.c): Get as far as deleting and adding files via the commit editor - still don't have the ability to apply diffs. |
| 22:01.28 | CIA-52 | BRL-CAD: 03brlcad * r44100 10/brlcad/trunk/src/librt/db5_types.c: check our inputs for sanity on all the avs standard attribute functions |
| 22:06.04 | volock | How many people can BRL-CAD hire through GSoC? And how many typically apply (out of curiosity)? |
| 22:17.26 | brlcad | volock: we don't consider them as "hires", it's not just a summer job |
| 22:17.47 | brlcad | if it's just a summer job to you, then GSoC (with any org) might not be right for you |
| 22:18.18 | brlcad | the intention is to get you involved in open source development as a long-term contributor |
| 22:20.12 | brlcad | otherwise, we talk about it some at http://brlcad.org/wiki/Google_Summer_of_Code and this year's slot count specifically at http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 22:25.16 | CIA-52 | BRL-CAD: 03starseeker * r44101 10/geomcore/trunk/tests/svntest/main.c: OK, this creates a new file and gets contents into it. Next step will be to change the contents of an existing file. |
| 22:41.25 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 23:01.09 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 23:01.09 | *** topic/#brlcad is 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 | |
| 23:14.33 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 23:25.13 | CIA-52 | BRL-CAD: 03starseeker * r44102 10/geomcore/trunk/tests/svntest/main.c: grr - need to figure out how to handle svn_txdelta_run, apparently... |
| 23:31.40 | brlcad | for anyone that missed our logo limelite: http://imagepaste.nullnetwork.net/viewimage.php?id=1980 |
| 23:32.33 | brlcad | to be repeated in a few hours :) |
| 23:33.28 | CIA-52 | BRL-CAD: 03starseeker * r44103 10/geomcore/trunk/tests/svntest/main.c: Hmm - doesn't look like reading file contents from the repo was the issue - maybe the md5 checksum is really necessary. |