| 00:09.03 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) |
| 00:11.28 | CIA-49 | BRL-CAD: 03bhinesley * r44922 10/brlcad/trunk/src/librt/db_open.c: Reverted code changes introduced by r44903. It introduced a bug, where raytracing .g files outside of the CWD would fail due to an invalid path. |
| 00:11.44 | bhinesley | starseeker: ^^^ |
| 00:27.46 | *** join/#brlcad crazy_imp (~mj@a89-182-248-44.net-htp.de) |
| 00:28.12 | starseeker | bhinesley++ |
| 00:28.13 | starseeker | nice find |
| 00:28.59 | bhinesley | shoulda found it earlier, but I didn't realize that the sf commit archives show OLDEST commits on top |
| 00:29.20 | bhinesley | db_open, duh |
| 00:30.35 | starseeker | good job - I shoulda checked that first, but since it was archer-only behavior on my machine the first thing that lept to mind was tcl/tk changes |
| 00:31.01 | starseeker | obviously not :-O |
| 01:03.34 | brlcad | hm, that implies some other bug because those are supposed to be search paths |
| 01:22.25 | bhinesley | Ah okay. I'll take another look tomorrow. |
| 04:06.32 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 04:23.47 | CIA-49 | BRL-CAD: 03brlcad * r44923 10/brlcad/trunk/TODO: eliminate dbi_filepath. shouldn't need to search for resources. the user specified where the database is at, paths are merely relative to our pwd at the time the db was opened or absolute. |
| 04:30.21 | CIA-49 | BRL-CAD: 03brlcad * r44924 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: |
| 04:30.22 | CIA-49 | BRL-CAD: rename RT_CK_DISKMAGIC to NMG_CK_DISKMAGIC since it's not librt api and is |
| 04:30.22 | CIA-49 | BRL-CAD: internal to just nmg.c; probably doesn't even warrant NMG_ prefix, but might |
| 04:30.22 | CIA-49 | BRL-CAD: need to get moved to nmg.h when separated out in a diff lib so leave it be for |
| 04:30.22 | CIA-49 | BRL-CAD: now. |
| 04:40.27 | CIA-49 | BRL-CAD: 03brlcad * r44925 10/brlcad/trunk/src/librt/ (8 files in 7 dirs): some ws indent changes in here got skipped. commit. |
| 04:42.06 | CIA-49 | BRL-CAD: 03brlcad * r44926 10/brlcad/trunk/src/librt/db_open.c: premature, dbip ftw |
| 04:43.38 | CIA-49 | BRL-CAD: 03brlcad * r44927 10/brlcad/trunk/include/raytrace.h: dbi_filename paths are not const if we have to free them! |
| 05:00.14 | CIA-49 | BRL-CAD: 03brlcad * r44928 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: rename rt_nmg_reindex() to just reindex() since it's not librt public api. looks like it's even private nmg api so we can drop the nmg_ prefix. |
| 05:03.23 | CIA-49 | BRL-CAD: 03brlcad * r44929 10/brlcad/trunk/src/ (15 files in 12 dirs): ws indent cleanup after BU_EXTERN removal |
| 05:13.09 | CIA-49 | BRL-CAD: 03brlcad * r44930 10/brlcad/trunk/src/librt/librt.3: document the LIBRT_BOT_MINTIE option in the librt manual page, just so it's written down somewhere user-visible. |
| 06:37.15 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 09:31.13 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) |
| 09:31.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 10:16.36 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) |
| 10:46.02 | kunigami | brlcad: the way I was thinking (string identifying shader), you could define a new shader "foo.osl", compile it to "foo.oso" and them load it passing as parameter to sh_osl "foo" |
| 10:46.56 | kunigami | today, what we have is that I have a hard-coded osl shader name "yellow", but "yellow.oso" was compiled independently of brlcad or osl |
| 10:48.16 | kunigami | "what we have is that I have" ... lol |
| 10:55.00 | dloman | yawns |
| 10:55.51 | dloman | mernin all! |
| 11:00.29 | kunigami | morning :) |
| 11:02.49 | dloman | hows gsoc goin for ya? |
| 11:27.23 | *** join/#brlcad crazy_imp (~mj@a89-182-248-44.net-htp.de) |
| 12:15.58 | CIA-49 | BRL-CAD: 03brlcad * r44931 10/brlcad/trunk/ (9 files in 8 dirs): |
| 12:15.58 | CIA-49 | BRL-CAD: make bu_vls use size_t/off_t internally for tracking the buffer size. |
| 12:15.58 | CIA-49 | BRL-CAD: accordingly, make bu_vls_setlen() and bu_vls_strlen() take a size_t parameter |
| 12:15.58 | CIA-49 | BRL-CAD: and propagate changes down to callers as well so we don't have signed/unsigned |
| 12:15.59 | CIA-49 | BRL-CAD: mismatching. |
| 12:19.54 | CIA-49 | BRL-CAD: 03davidloman * r44932 10/geomcore/trunk/src/GS/FileDataSource.cxx: Comments fix. No longer use BRLCAD::MinimalObject. Uses ExtObjects instead. |
| 12:21.46 | CIA-49 | BRL-CAD: 03davidloman * r44933 10/geomcore/trunk/src/clients/ (. java/): Add a dir for client work. Need to reduce confusion by separating the 'interface' work from the 'clients' that use said interface. |
| 12:25.53 | CIA-49 | BRL-CAD: 03davidloman * r44934 10/geomcore/trunk/src/clients/java/ (src/ test/): Add /src and /test to client dirs for GS Java Client project setup. |
| 12:29.26 | CIA-49 | BRL-CAD: 03davidloman * r44935 10/geomcore/trunk/src/clients/java/: More Project setup. Ignore .* files from eclipse. |
| 12:32.18 | CIA-49 | BRL-CAD: 03davidloman * r44936 10/geomcore/trunk/src/clients/java/src/org/ (4 files in 4 dirs): Add initial source package tree to client /src for GS Java Client project setup. |
| 12:34.09 | CIA-49 | BRL-CAD: 03davidloman * r44937 10/geomcore/trunk/src/ (19 files in 4 dirs): Move client files from interface project to client project |
| 12:35.00 | CIA-49 | BRL-CAD: 03davidloman * r44938 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/: Drop client dirs from interface project |
| 12:53.51 | CIA-49 | BRL-CAD: 03brlcad * r44939 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c): vls_offset isn't supposed to go negative since it's a positive index from the front, so make it a size_t too. remove unnecessary casts now that internal bu_vls members are size_t. |
| 13:15.19 | CIA-49 | BRL-CAD: 03brlcad * r44940 10/brlcad/trunk/src/mged/animedit.c: linux size_t quellage |
| 13:24.56 | CIA-49 | BRL-CAD: 03brlcad * r44941 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: got some unreliable asc2g crashes with the new tclcad handling. thrown in some asserts where unexpected NULLs were showing up in gdb. |
| 13:37.10 | CIA-49 | BRL-CAD: 03brlcad * r44942 10/brlcad/trunk/src/conv/iges/ (convtree.c iges_struct.h): MEMCHECK is only used in convtree.c so move from iges_struct.h; also simplify conditional so we can require a semicolon on use so formatting stays sane. cleanup. |
| 14:01.35 | CIA-49 | BRL-CAD: 03Waters 07http://brlcad.org * r2919 10/wiki/User:Waters: New page: [http://www.speedmycomputer.net/ how can i speed up my computer] |
| 14:23.50 | CIA-49 | BRL-CAD: 03brlcad * r44943 10/brlcad/trunk/include/raytrace.h: |
| 14:23.50 | CIA-49 | BRL-CAD: add a new RT_INIT_COMB_INTERNAL initialization macro for initializing |
| 14:23.50 | CIA-49 | BRL-CAD: rt_comb_internal structs. add a corresponding RT_FREE_COMB_INTERNAL() macro |
| 14:23.50 | CIA-49 | BRL-CAD: since we do initialize the vls strings potentially allocating memory (might want |
| 14:23.50 | CIA-49 | BRL-CAD: a bu_vls_init_empty() or vls INIT macro). |
| 14:24.37 | CIA-49 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Waters]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 14:24.57 | CIA-49 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:Waters]]": content was: '[http://www.....net/ how can i speed up my computer]' (and the only contributor was '[[Special:Contributions/Waters|Waters]]') |
| 14:27.57 | CIA-49 | BRL-CAD: 03brlcad * r44944 10/brlcad/trunk/src/ (12 files in 4 dirs): use the new RT_INIT_COMB_INTERNAL macro allowing us to make comb initialization consistent and consolidated into one place. |
| 14:30.33 | brlcad | bhinesley: any luck with the dbi_filepath issue? I'm actually not seeing how that even comes into play during database open (supposed to be used to find resources like height field files, bitmaps, shader files, etc) |
| 14:37.54 | CIA-49 | BRL-CAD: 03brlcad * r44945 10/brlcad/trunk/misc/Makefile.am: sort & sync. remove FindCocoa.cmake and FindCorbon.cmake, add util_macros.cmake. |
| 14:59.32 | CIA-49 | BRL-CAD: 03davidloman * r44946 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/ (CmdConsolePanel.java JTextFieldWithHistory.java): Break out JTextField into custom subclass. Add cmd history. |
| 15:10.34 | CIA-49 | BRL-CAD: 03starseeker * r44947 10/brlcad/trunk/src/other/iwidgets/generic/ (panedwindow.itk tclIndex): Stick in iwidgets panedwindow method and option that seem to be needed for RamDebugger... |
| 15:11.24 | CIA-49 | BRL-CAD: 03davidloman * r44948 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java msg/AbstractNetMsg.java): Make the java implementation AbstractNetMsg.java match NetMsg.cxx |
| 15:11.47 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) |
| 15:11.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 15:15.08 | CIA-49 | BRL-CAD: 03davidloman * r44949 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgTypes.java: Update NetMsgTypes from C++ code. |
| 15:42.02 | CIA-49 | BRL-CAD: 03davidloman * r44950 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java: Comment cleanup |
| 15:42.38 | CIA-49 | BRL-CAD: 03davidloman * r44951 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (5 files): Implement a few more NetMsg types in java. More on the way. |
| 15:47.09 | CIA-49 | BRL-CAD: 03starseeker * r44952 10/brlcad/trunk/src/other/tktreectrl/ (246 files in 21 dirs): |
| 15:47.10 | CIA-49 | BRL-CAD: Early cut at a CMakeified tktreectrl widget. This and the next few commits are |
| 15:47.11 | CIA-49 | BRL-CAD: only for the purposes of 'checkpointing' what I have managed to get working as |
| 15:47.12 | CIA-49 | BRL-CAD: far as RamDebugger goes - not really functional as yet (the basic RamDebugger |
| 15:47.17 | CIA-49 | BRL-CAD: window comes up, but that's about it), so I'll promptly remove it again - the |
| 15:47.17 | CIA-49 | BRL-CAD: goal is to have what I did get in svn history if I can devote more resources to |
| 15:47.17 | CIA-49 | BRL-CAD: it later. |
| 15:53.12 | kunigami | dloman: going well. By now I'm studying how to deal with recursive rays (reflection and refraction/transmission). will make some experiments here |
| 16:02.33 | CIA-49 | BRL-CAD: 03starseeker * r44953 10/brlcad/trunk/src/other/ (672 files in 38 dirs): |
| 16:02.33 | CIA-49 | BRL-CAD: Tweaked version of RamDebugger - diff with vanilla version 7.8 to see |
| 16:02.33 | CIA-49 | BRL-CAD: differences. Removed a few extensions and there is more to remove, if this were |
| 16:02.33 | CIA-49 | BRL-CAD: ever to be properly set up for what BRL-CAD needs - many features like cvs |
| 16:02.33 | CIA-49 | BRL-CAD: aren't particularly important to us, for example... Changes here were done |
| 16:02.34 | CIA-49 | BRL-CAD: using the enable-all-local-libs build options. |
| 16:04.19 | kunigami | by the way, is there any variable that stores how many times a given ray hit an object (or its depth)? |
| 16:04.31 | CIA-49 | BRL-CAD: 03starseeker * r44954 10/brlcad/trunk/src/other/ (CMakeLists.txt RamDebugger/ tktreectrl/): Checkpoint complete, restore previous src/other CMakeLists.txt logic and remove RamDebugger related directories. |
| 16:05.36 | brlcad | kunigami: you set up callbacks when you fire a ray for hit/miss that can perform that book-keeping, or you can make sure a_onehit is unset and you'll get back a partition list of all objects along that ray |
| 16:08.45 | brlcad | kunigami: http://brlcad.org/wiki/Example_Application shows the latter where it iterates over the partition list |
| 16:12.51 | CIA-49 | BRL-CAD: 03davidloman * r44955 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (GeometryChunkMsg.java GeometryManifestMsg.java): Add GeometryManifest and GeometryChunk msgs to java |
| 16:13.13 | CIA-49 | BRL-CAD: 03davidloman * r44956 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (PingMsg.java PongMsg.java): Add Ping and Pong to java |
| 16:16.11 | CIA-49 | BRL-CAD: 03davidloman * r44957 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (DirListReqMsg.java DirListResMsg.java): Add DirectoryList request and response NetMsgs to java. |
| 16:16.49 | CIA-49 | BRL-CAD: 03davidloman * r44958 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Update NetMsgfactory with all the recently implemented NetMsg subclasses. |
| 16:17.11 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) |
| 16:18.11 | kunigami | brlcad: thanks! this example also shows how to setup the callback |
| 16:20.03 | CIA-49 | BRL-CAD: 03bob1961 * r44959 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added the ability to create instances of ArcherCore with/without the treeview or the toolbar. |
| 16:20.50 | CIA-49 | BRL-CAD: 03davidloman * r44960 10/geomcore/trunk/src/libNet/netMsg/NewNodeOnNetMsg.cxx: Update NetMsg type to correct one for this class. |
| 16:21.47 | kunigami | if I understood it right, whenever it hits an object that function will be called. If, for example, a ray first hits an object A, the callback will be called with only object A. If this ray further hits an object B, them both A and B will be in that partition list? |
| 16:21.51 | CIA-49 | BRL-CAD: 03davidloman * r44961 10/geomcore/trunk/src/utility/StringUtils.cxx: Fix incorrect type and cast. |
| 16:26.03 | brlcad | kunigami: it depends if onehit is set, but if unset then yes |
| 16:26.32 | yukonbob | hello, #brlcad |
| 16:26.41 | brlcad | howdy yukonbob |
| 16:26.53 | yukonbob | how're things? |
| 16:28.46 | CIA-49 | BRL-CAD: 03bob1961 * r44962 10/brlcad/trunk/src/tclscripts/rtwizard/ (RaytraceWizard.tcl lib/MGEDpage.itk): Updates to use ArcherCore instead of Mged which has been deprecated. |
| 16:29.20 | brlcad | busy |
| 16:29.34 | brlcad | dloman: how was the type incorrect? |
| 16:29.36 | yukonbob | excellent! |
| 16:29.57 | yukonbob | hits website to see if there're published stories about recent(ish) goings-on... |
| 16:30.39 | brlcad | maybe a complaint that bu_free() wasn't being passed a genptr_t (i.e., a void*), but making it const isn't technically correct |
| 16:32.32 | brlcad | starseeker: hmmm |
| 16:32.46 | brlcad | adding RamDebugger is akin to adding gdb ... kinda odd |
| 16:33.11 | brlcad | maybe a separate branch for 3rd party tools? |
| 16:36.37 | yukonbob | what's the RamDebugger for ? |
| 16:41.00 | brlcad | presumably debugging tcl code |
| 16:41.10 | brlcad | it's a gui ide for tcl debugging |
| 16:43.14 | starseeker | brlcad: I removed it - just wanted to stash it in history somewhere |
| 16:43.47 | brlcad | heh, okay |
| 16:44.33 | starseeker | brlcad: ultimately it might be interesting to be able to debug tcl scripts "in MGED" or some such, but for the moment I can't even get the darn thing to debug ANYTHING |
| 16:46.04 | starseeker | I'm sure it'll do something once I finish widing through the "oh, this doesn't work either with this version" fun but even then I'm not sure how well it would do with incrTcl/iwidgets |
| 16:46.46 | starseeker | my annoyance threshold with debugging Tcl/Tk just hit a momentary peak - it'll fade back to normal background annoyance levels soon :-P |
| 16:46.55 | yukonbob | notes theres also -DTCL_MEM_DEBUG, and the [mem] commands it presents... |
| 16:47.57 | yukonbob | starseeker: Tcl loves you :) |
| 16:48.34 | starseeker | yukonbob: what I miss most is the ability to step through a tcl file line by line in an editor DDD style, examining variables and such and easily seeing which Tcl line ultimately triggered the latest framebuffer/display manager problem |
| 16:49.25 | starseeker | feeding bwish into gdb does OK if the problem is in our C libraries, but if it's actually in the Tcl code... |
| 16:49.31 | dloman | brlcad: was supposed to be const char* instead of just char* |
| 16:49.32 | yukonbob | nods... a bit more involved than just memory consumption, ckalloc() guarding... |
| 16:49.41 | dloman | brlcad: and i missed a cast to void* |
| 16:49.54 | yukonbob | TclPro has what you're looking for, I think, but I haven't played w/ that part of Tcl dev... |
| 16:50.02 | yukonbob | is sure starseeker is on the case, though. |
| 16:50.30 | starseeker | <snort> the problem is Tcl/Tk problems of that nature are just rare enough that we can usually ignore them or have bob1961 track 'em down |
| 16:51.04 | starseeker | TclPro... isn't that the commerical one? Or wasn't there some free version that hasn't been updated in a long long time? |
| 16:54.55 | brlcad | dloman: it's not supposed to be const char |
| 16:55.08 | brlcad | at least not if you're going to bu_free it (which the signature requires) |
| 16:55.33 | dloman | okie |
| 16:56.02 | brlcad | the cast to void* (i.e., genptr_t) is the only thing that might have provoked a warning, but the types should have been golden |
| 16:57.03 | brlcad | the constness is broken by casting to void* anyways |
| 16:57.49 | starseeker | hah, cool: http://labs.qt.nokia.com/2011/06/03/threaded-opengl-in-4-8/ |
| 16:58.27 | bhinesley | brlcad: not yet, I'm just starting for today. To answer your question: I don't think that it has anything to do with opening the database. It has to do with the CWD, which is apparently being used somewhere. |
| 16:58.27 | bhinesley | When attempting to raytrace, we see the path "/CWD//full_path_to_.g/" being used (two absolute paths concatenated). |
| 17:00.17 | brlcad | yeah, i get the end-effect, and that the full-path cwd is presumably coming from dbi_fullpath .. but not how the order of search dirs [0] vs [1] would result in that |
| 17:00.40 | bhinesley | that, I will have to figure out |
| 17:01.01 | bhinesley | gets to work |
| 17:01.05 | brlcad | I did a full search for dbi_fullpath and ... if it's the cause, I haven't quite seen how yet :) |
| 17:01.29 | CIA-49 | BRL-CAD: 03davidloman * r44963 10/geomcore/trunk/src/utility/StringUtils.cxx: Cast the data from bu_basename to (char*) rather than passing around a (const char*) |
| 17:02.25 | brlcad | hmmm |
| 17:02.41 | brlcad | I think your header files are out of date, don't need a cast either :) |
| 17:02.46 | brlcad | (dloman) |
| 17:03.15 | brlcad | that's probably the original problem |
| 17:03.26 | dloman | kk |
| 17:04.07 | dloman | updates |
| 17:11.00 | starseeker | O.o another one: https://github.com/advancingu/Cutexture |
| 17:12.55 | brlcad | http://www.youtube.com/watch?v=b_3xfFuwGOQ |
| 17:14.45 | starseeker | brlcad: yeah, saw that - quite promising |
| 17:14.57 | starseeker | that's the experimental Qt5 apparently |
| 17:15.12 | brlcad | same problem from a couple years ago though |
| 17:15.17 | brlcad | still seems "backwards" |
| 17:15.57 | starseeker | you mean ogre-in-Qt not Qt-in-Ogre? |
| 17:16.05 | brlcad | yeah |
| 17:16.20 | brlcad | or both really since you still want qt widgets in the ogre context too |
| 17:16.38 | brlcad | but that your main window is a qt window, not something ogre establishes |
| 17:16.58 | starseeker | maybe cutexture is set up more along those lines - I'll have to check |
| 17:17.17 | starseeker | usually the problem I have testing these suckers is getting Ogre working on my home box... |
| 17:34.07 | yukonbob | Trolltech ogre? Isn't there a rule against cross-fairytale creature misappropriation? |
| 17:38.22 | bhinesley | brlcad: which argument is used for what seems to be explicit: if (argv[1][0] != '/') |
| 17:39.19 | bhinesley | it tests to see if the second argument is an absolute path, but not the first |
| 17:39.39 | bhinesley | sorry, this is in db_open.c |
| 17:53.32 | CIA-49 | BRL-CAD: 03starseeker * r44964 10/brlcad/trunk/ (5 files in 4 dirs): Downcase the openNURBS directory to just opennurbs - 'cause macros are easier when you don't have mixed case in the way. |
| 17:55.39 | brlcad | ah, heh .. I was hunting down dbi_fullpath in other files and it hadn't even gotten out of db_open()! I see now, it's trying to expand the full path for dbi_filename() |
| 17:55.51 | brlcad | will rewrite that function, no worries -- thanks! |
| 17:56.07 | bhinesley | oh alright! no problem. |
| 17:56.40 | brlcad | it was actually next in my queue to add a cwd routine to libbu anyways |
| 18:02.40 | bhinesley | brlcad: should I keep working on migrating commands and fixing bugs for now, or should I start on the libged command registry? I'm not really sure where to start on the registry, so we might need to talk about it for a bit before I do. |
| 18:03.13 | bhinesley | either is fine for me |
| 18:11.16 | *** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118) |
| 18:11.43 | bhinesley_ | brlcad: my machine locked up, so if you said anything i missed it |
| 18:17.26 | starseeker | bhinesley: he didn't yet |
| 18:17.39 | bhinesley | thanks :) |
| 18:24.07 | brlcad | bhinesley: I'd keep with the original plan for now, command migration, refactoring, and fixing |
| 18:24.25 | bhinesley | ok |
| 18:25.30 | brlcad | I've got something started for the registry, but am just a bit overtasked at the moment to dive down that path just yet |
| 18:26.11 | brlcad | nothing fancy to say the least, but the command work will be more immediately useful anyways |
| 18:26.23 | bhinesley | Oh, don't worry about it, I know you have a lot on your plate. |
| 18:31.31 | CIA-49 | BRL-CAD: 03davidloman * r44965 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Comment clean up. Also added two methods that will need to be rolled into jBRLCAD's GemetryService Interface |
| 18:32.48 | CIA-49 | BRL-CAD: 03davidloman * r44966 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Remove libPKG remnants |
| 18:33.43 | CIA-49 | BRL-CAD: 03brlcad * r44967 10/brlcad/trunk/ (TODO src/libged/typein.c): we allocate the idb_ptr so we know the vls is not initialized. call bu_vls_init() instead of bu_vls_init_if_uninit(). still warrants a quick test before the next release, though. |
| 18:34.15 | CIA-49 | BRL-CAD: 03davidloman * r44968 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: Was incorrectly serializing using the old GSNetProto header. Removed the two MAGIC values and fixed the msgLen calculation. |
| 18:35.36 | CIA-49 | BRL-CAD: 03brlcad * r44969 10/brlcad/trunk/src/ (conv/dxf/dxf-g.c mged/vrlink.c): make the vls a pointer so it can sometimes be NULL and we can test that for determining whether to initialize or not. call bu_vls_init() instead of the unreliable bu_vls_init_if_uninit(). |
| 18:36.21 | CIA-49 | BRL-CAD: 03brlcad * r44970 10/brlcad/trunk/src/mged/utility1.c: the tmp_vls isn't used outside the nested scope so pull it down to where it's used. there we know it's not initialized, so we can just call bu_vls_init(). |
| 18:37.15 | CIA-49 | BRL-CAD: 03brlcad * r44971 10/brlcad/trunk/src/ (libbu/parse.c librt/parse.c): if they're not initialized, it's an error in the caller's code. don't try to accommodate the error by initializing. |
| 18:41.51 | CIA-49 | BRL-CAD: 03brlcad * r44972 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h src/libbu/vls.c): |
| 18:41.52 | CIA-49 | BRL-CAD: and with that, mark the silly inconsistent error-prone unreliable |
| 18:41.52 | CIA-49 | BRL-CAD: bu_vls_init_if_uninit() function as deprecated. there needs to be an INIT macro |
| 18:41.52 | CIA-49 | BRL-CAD: for bu_vls structs but bu_vls_init() is the better way to go. the problem stems |
| 18:41.52 | CIA-49 | BRL-CAD: from memory not getting consistently initialized and/or reset to zero so that |
| 18:41.52 | CIA-49 | BRL-CAD: the magic check would actually work. using a NULL pointer or caller-based init |
| 18:41.53 | CIA-49 | BRL-CAD: flag are safer methods. |
| 18:42.04 | CIA-49 | BRL-CAD: 03davidloman * r44973 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: |
| 18:42.04 | CIA-49 | BRL-CAD: Added a thread sleep in the GSConnection run loop to keep from hogging a CPU. |
| 18:42.04 | CIA-49 | BRL-CAD: Fixed buffer size checking in tryMakeNetMsg(), it was incorrectly thinking there |
| 18:42.04 | CIA-49 | BRL-CAD: was insufficient data to deserialize and bailing out. Also fixed waitForMsg() |
| 18:42.05 | CIA-49 | BRL-CAD: as the totalRead parameter was not being reset after the loop was finished. |
| 18:46.10 | CIA-49 | BRL-CAD: 03davidloman * r44974 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/CmdConsolePanel.java: Removed unused var from doCmd(). Was leftover from debugging. |
| 18:47.00 | CIA-49 | BRL-CAD: 03davidloman * r44975 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Print the remote nodename to the GUI console upon successful connection. |
| 18:51.05 | CIA-49 | BRL-CAD: 03davidloman * r44976 10/geomcore/trunk/ (include/PortalManager.h src/libNet/PortalManager.cxx): Make a difference between 'LocalNodeName' and the PortalManager object's name. LocalNodeName is the name of this PortalManager on the network while the other is simply the object's name used in Logging. |
| 18:54.19 | CIA-49 | BRL-CAD: 03davidloman * r44977 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Eliminate duplicate fn. |
| 19:04.07 | CIA-49 | BRL-CAD: 03starseeker * r44978 10/brlcad/trunk/src/other/opennurbs/CMakeLists.txt: bye bye mixed case |
| 19:07.12 | CIA-49 | BRL-CAD: 03davidloman * r44979 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSNetMsgFutureResponse.java: Add a response handler for NetMsg that should envoke a response from server. |
| 19:08.53 | brlcad | starseeker: if I recall correctly, mixed case on the product is what was in their original build files, so there is some value in preserving that trait |
| 19:10.35 | brlcad | further deviation from their source (with any benefit?) making it more complicated to swap in a system opennurbs down the road |
| 19:12.34 | brlcad | the dir name is irrelevant, but the product name does have meaning (e.g., mixed case is highly indicative of C++ libs vs C libs .. a quick scan of any lib dir and the C++ ones are generally (conventionally) the ones with upper-case) |
| 19:19.04 | CIA-49 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2920 10/wiki/User:Bhinesley: /* Log */ Friday - Monday, plan today |
| 19:24.36 | CIA-49 | BRL-CAD: 03brlcad * r44980 10/brlcad/trunk/include/bu.h: |
| 19:24.36 | CIA-49 | BRL-CAD: implement BU_INIT_VLS() and BU_INIT_VLB() macros to initialize a vls/vlb struct |
| 19:24.36 | CIA-49 | BRL-CAD: without allocating any memory. also, similar to the convention in vmath, |
| 19:24.36 | CIA-49 | BRL-CAD: provide BU_VLS_INIT_ZERO/BU_VLB_INIT_ZERO macros suitable for declaration |
| 19:24.36 | CIA-49 | BRL-CAD: statement initialization. |
| 19:25.45 | brlcad | bhinesley: tell me about ls |
| 19:41.21 | *** join/#brlcad yiyus (2383vince@je.je.je) |
| 19:55.11 | CIA-49 | BRL-CAD: 03davidloman * r44981 10/geomcore/trunk/src/libNet/ (Portal.cxx PortalManager.cxx): Make Portal/PortalManager respond to a RemNodeNameSet message rather than automatically sending its localNodeName. |
| 19:55.28 | CIA-49 | BRL-CAD: 03brlcad * r44982 10/brlcad/trunk/include/bu.h: add BU_LIST_INIT_ZERO, BU_BITV_INIT_ZERO, and BU_INIT_BITV macros for api consistency (lots more to go) |
| 19:55.51 | bhinesley | brlcad: I noticed that when you enter "ls not-an-obj" it would print "not-an-obj", which is misleading. I checked ArcherCore.tcl, and saw that it simply does "return \$expandedArgs" if you don't pass any options. |
| 19:55.51 | bhinesley | I was trying to get the behavior that MGED has: if you do an 'ls is-an-obj not-an-obj', it returns something like "is-an-obj (\n ...) not-an-obj doesn't exist". This doesn't seem possible the way it works now, since we're not letting libged's ls command print it's error directly to the command line. If we want ::ls to print the error, it has to be all or nothing (failure or success), since a partial match in libged's ls simply returns GED_OK. |
| 19:56.23 | CIA-49 | BRL-CAD: 03brlcad * r44983 10/brlcad/trunk/src/libbu/ (list.c malloc.c mappedfile.c temp.c): no longer need to manually init the bu_list or ignore init, call BU_LIST_INIT_ZERO instead. |
| 19:57.11 | bhinesley | hopefully that made sense |
| 20:08.43 | CIA-49 | BRL-CAD: 03brlcad * r44984 10/brlcad/trunk/include/bu.h: fix BU_INIT_BITV(). we need pointers to pass to BU_INIT_LIST(). group the bu_list init macros together better and add BU_INIT_LIST (which calls the existing BU__LIST_INIT that will soon go away). |
| 20:09.00 | CIA-49 | BRL-CAD: 03brlcad * r44985 10/brlcad/trunk/src/libbu/bitv.c: initialize the BU_BITV properly instead of setting the magic manually. |
| 20:41.42 | brlcad | bhinesley: yes, that does make sense |
| 20:42.18 | brlcad | that actually sounds like a prime example for consolidation so that they are identical |
| 20:43.09 | brlcad | so there's no expansion in mged or archer, that ged_ls() does all the work with the necessary information returned in the struct ged in some form that both can display suitably |
| 20:44.06 | brlcad | and of course sorting out what it means to have a partial failure from an api perspective |
| 20:44.48 | brlcad | I'd think partial failure is still a failure, not GED_OK for starters |
| 20:44.53 | bhinesley | agreed |
| 20:47.05 | brlcad | the issue then just becomes how to have ged_ls() add listings and failures to the results |
| 20:47.33 | brlcad | could be time to sort out a proper result set instead of the dumb ged_result_str |
| 20:48.21 | kunigami | can I set the hit callback on the shader setup? |
| 20:50.07 | brlcad | e.g., an array of types and values so that "ls valid invalid valid2" might return the set { {GED_OBJECT, "valid"}, {GED_ERROR, "ls: invalid: No such object"}, {GED_OBJECT, "valid2"} } |
| 20:50.35 | brlcad | kunigami: you can set the hit callback any time before rt_shootray() is called |
| 20:51.56 | brlcad | if you're in the shader, though, then that probably implies that a ray was already fired, hit callback was made, determined ther shader, and shader callback was made .. so you'd be firing another ray you set up |
| 20:54.58 | kunigami | true |
| 20:55.24 | bhinesley | brlcad: does ::ls even need to know that much? Couldn't just the results be passed back from ged_ls? |
| 20:55.47 | kunigami | it seems that the variable 'a_level' from application struct counts the depth of recursion. let me give it a try |
| 20:57.43 | bhinesley | and by that, I mean one long string that is printed |
| 20:58.25 | bhinesley | n/m... then we'd lose the ability to identify which part of it is an error |
| 20:58.35 | bhinesley | for logging and whatnot |
| 20:58.36 | brlcad | bhinesley: bingo |
| 20:58.44 | brlcad | I mean for now, that'd be an improvement |
| 20:59.16 | brlcad | but the goal is to make the return from the ged_*() functions be programmatic |
| 21:00.12 | brlcad | so I could write a program that uses ged_ls() to lookup objects, iterate over them and call other functions etc |
| 21:00.57 | brlcad | or in the case of mged/arhcer, maybe I want to return the list of objects as a proper list and print the error (interleaved and color-coded) to stderr |
| 21:02.42 | bhinesley | I understand; I was thinking about it from the perspective of tcl code duplication. It'd be nice if there was a mechanism for using the same call to ged_ls for both programs... like how I kinda forced that with ManBrowser. |
| 21:02.54 | bhinesley | that would prevent problems like this from occurring in the first place |
| 21:04.25 | CIA-49 | BRL-CAD: 03brlcad * r44986 10/brlcad/trunk/ (21 files in 12 dirs): |
| 21:04.25 | CIA-49 | BRL-CAD: replace BU_LIST_UNINITIALIZED() with !BU_LIST_IS_INITIALIZED() as a minimally |
| 21:04.25 | CIA-49 | BRL-CAD: impacting API change. BU_LIST_UNINITIALIZED() is unnecessary with the other and |
| 21:04.26 | CIA-49 | BRL-CAD: inconsistent with the API (the only *_uninitialized macro of its kind). reduce, |
| 21:04.26 | CIA-49 | BRL-CAD: reuse. |
| 21:05.07 | bhinesley | shrugs |
| 21:21.06 | starseeker | brlcad: uh... we're writing our own build logic for opennurbs anyway... |
| 21:22.33 | starseeker | brlcad: at this point I'm very doubtful we'll ever be able to use a system opennurbs |
| 21:23.01 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca) |
| 21:23.19 | starseeker | I'll revert it if you want and try to find another way to do what I had in mind... |
| 21:27.08 | CIA-49 | BRL-CAD: 03bhinesley * r44987 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Temporary fix for ::ls to stop echoing nonexistant objects. |
| 21:29.23 | brlcad | starseeker: it should probably still be our goal, not intentionally move away with a fork |
| 21:29.32 | brlcad | if only to minimize differences the next time we sync |
| 21:29.56 | brlcad | that one in particular, though, gets at the convention issue and the "name" of the library |
| 21:31.28 | starseeker | brlcad: I'm not sure I agree about forking, but I'll revert the name downcasing (working on it now) |
| 21:33.50 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca) |
| 21:35.16 | *** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118) |
| 21:35.43 | *** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118) |
| 21:36.31 | CIA-49 | BRL-CAD: 03starseeker * r44988 10/brlcad/trunk/ (501 files in 11 dirs): Revert r44964 |
| 21:46.50 | brlcad | starseeker: I still think it's entirely possible to get a pristine openNURBS working, to move back towards the original goal of having a proper layer on *top* of opennurbs for our added functionality |
| 21:47.09 | brlcad | maybe that overlay is your libnurbs project |
| 21:47.44 | brlcad | anything else is going to have an ongoing maintenance cost that, well, will suck more and more over time |
| 21:48.47 | brlcad | curious though -- what prompted that onto your radar to change it? |
| 21:49.16 | starseeker | I'm playing games with CMake macros to get the distcheck filelists out of src/other/CMakeLists.txt |
| 21:49.51 | starseeker | I was using some toupper and tolower logic in macros - it may not be strictly necessary though, so I'm going to revisit those macros |