| 00:07.18 | CIA-85 | BRL-CAD: 03brlcad * r37823 10/brlcad/trunk/src/libcursor/cursor.c: dead comment |
| 00:22.05 | brlcad | starseeker: another idea that came to mind is to determine if the problem is merely limited to event management happening in threads |
| 00:23.15 | brlcad | which is basically still doing the Tk_PhotoPutBlock() in tk_write() like you were doing, and still keep the fork() .. but just have the child send back a single byte, which causes the parent to call Tcl_DoOneEvent() |
| 00:23.45 | brlcad | if that works, it'd be world's better/faster than sending all the image data over the pipe |
| 00:26.28 | brlcad | the next step you could take that would be even better than fork() and libpkg would probably be to use TclThread's and TclPipes ... should translate nearly 1-1 |
| 00:30.54 | ``Erik | libpkg needs a good solid working over anways |
| 03:14.13 | starseeker | brlcad: TclThreads would mean enabling threaded tcl/tk in the build, correct? |
| 03:16.08 | starseeker | wonders how that does on Windows... hmm... |
| 03:17.01 | starseeker | bets it is event management in threads, personally |
| 03:20.52 | starseeker | hmm... http://www.defense.gov/NEWS/DTM 09-026.pdf |
| 05:35.52 | brlcad | starseeker: beats me if it requires it, but nothing too tricky |
| 05:36.15 | brlcad | big diff by going through their threading mechanisms, though .. |
| 05:36.22 | brlcad | if anything should work, that should |
| 05:36.25 | brlcad | and would be portable |
| 05:37.16 | brlcad | tcl doesn't know anything about the pthreads that were calling into it -- if you used tcl threads instead of fork(), it would know about them and any protections they've made should stay valid |
| 06:26.12 | CIA-85 | BRL-CAD: 03brlcad * r37824 10/brlcad/trunk/src/librt/ (Makefile.am comb.c prcomb.c): rename comb.c to prcomb.c along with the binary respectively. alas, the name is way too generic, but the app is still an interesting (noinst) comparison binary tree printer. |
| 06:26.34 | CIA-85 | BRL-CAD: 03brlcad * r37825 10/brlcad/trunk/src/librt/prcomb.c: rename contents to prcomb.c |
| 06:32.37 | CIA-85 | BRL-CAD: 03brlcad * r37826 10/brlcad/trunk/src/librt/ (9 files in 2 dirs): move most of the comb-specific routines into their own subdirectory (the idea being for consistency, to have each non-primitive object have it's own subdir) |
| 06:35.17 | CIA-85 | BRL-CAD: 03brlcad * r37827 10/brlcad/trunk/src/librt/Makefile.am: missed saving file for commit. moved combs into subdir |
| 06:38.21 | CIA-85 | BRL-CAD: 03brlcad * r37828 10/brlcad/trunk/src/librt/ (7 files in 2 dirs): moving binunif code into binunif subdir too |
| 06:41.44 | CIA-85 | BRL-CAD: 03brlcad * r37829 10/brlcad/trunk/src/librt/Makefile.am: comb was renamed to prcomb, fix it. |
| 11:51.31 | CIA-85 | BRL-CAD: 03davidloman * r37830 10/rt^3/trunk/src/GS/CMakeLists.txt: Forgot to change the CMakeLists.txt to reflect the removal of JobScheduler.cxx/.h |
| 11:51.48 | brlcad | mornin' |
| 11:51.56 | d-lo | hai! |
| 11:52.03 | d-lo | up late or up early? |
| 11:53.56 | CIA-85 | BRL-CAD: 03davidloman * r37831 10/rt^3/trunk/include/GS/Jobs/JobScheduler.h: Drop header for JobScheduler. |
| 11:56.27 | brlcad | lil both |
| 11:58.48 | d-lo | you a crazy man! |
| 11:59.13 | d-lo | Is it still 'regatta' season? (Pardon my ignorance in spelling and in the sport) |
| 12:04.03 | CIA-85 | BRL-CAD: 03davidloman * r37832 10/rt^3/trunk/src/adminpanel/ (7 files): Stub in ConnectJob, DisconnectJob, BuildNetMsgJob |
| 12:19.58 | CIA-85 | BRL-CAD: 03davidloman * r37833 10/rt^3/trunk/ (6 files in 2 dirs): Refactor NetSockPortal* to NetPortal* |
| 12:22.03 | CIA-85 | BRL-CAD: 03davidloman * r37834 10/rt^3/trunk/src/GS/ (3 files): Stragglers from refactor NetSockPortal* to NetPortal* |
| 12:23.29 | ``Erik | O.o |
| 12:23.56 | ``Erik | starts turning up to volume to see who bitches first, indianlarry or d-lo :D |
| 12:24.23 | d-lo | I'm used to hearing crap music from over there. *shrug* *ducks* |
| 12:24.31 | ``Erik | heh, what, ya don't like cinder? O.o |
| 12:25.00 | ``Erik | or jimmy buffet, doors, narvarna, loa, ... |
| 12:25.26 | d-lo | Can't really hear it. Listening to *ounce ounce ounce ounce ounce ounce ounce ounce* :P |
| 12:25.32 | ``Erik | hahaha |
| 12:25.48 | d-lo | wow Jimmy Buffet and Nirvana in the same sentence.... nice. |
| 12:39.24 | CIA-85 | BRL-CAD: 03davidloman * r37835 10/rt^3/trunk/include/GS/Jobs/AbstractJob.h: Change visibility for _doJob() from private to protected. |
| 12:40.10 | CIA-85 | BRL-CAD: 03davidloman * r37836 10/rt^3/trunk/ (5 files in 2 dirs): Mods to netPortalManagerTest |
| 13:32.56 | brlcad | d-lo: not yet season, just up coding |
| 13:33.21 | d-lo | kewl. |
| 13:34.18 | brlcad | your commit messages should say what the diff does not say, which is usually why or what if it's not obvious |
| 13:34.36 | d-lo | kk |
| 13:34.46 | brlcad | saying private to protected is just noise :) |
| 13:34.57 | d-lo | but THATS IMPORTANT! :P |
| 13:35.07 | brlcad | sure is |
| 13:35.11 | brlcad | and the diff said it |
| 13:35.52 | brlcad | can still say that, but should hint at why if possible |
| 13:36.04 | brlcad | not just that specific commit :) |
| 13:36.06 | d-lo | kk |
| 13:36.20 | d-lo | too many rules :P |
| 13:36.25 | brlcad | moreso the "Mods" :) |
| 13:36.43 | brlcad | they're not rules |
| 13:37.15 | d-lo | oh good, so I cam ignore them then muwahaha' |
| 13:37.15 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 13:37.55 | brlcad | as someone simply trying to follow what you're doing, I should be able to have a basic idea of what you're doing and the motivation from the commits and messages |
| 13:38.14 | d-lo | I know what you're saying, I'm just messing with ya |
| 13:40.16 | brlcad | I know :) |
| 13:42.14 | brlcad | and it's probably not fun "being watched" but then without it we wouldn't improve, get stuck in bad habits, etc |
| 13:42.24 | d-lo | so if you knew I knew, but didn't know you knew I knew...*nose bleeds* |
| 13:42.26 | brlcad | like when erik calls out my mistakes *cough* |
| 13:42.41 | brlcad | as rare as they are *cough* |
| 13:42.48 | brlcad | I should get that cough checked out |
| 13:43.32 | d-lo | getting kinda cramped in this channel, what with the egos and all. *Badoom ching!* I'll be here all week.... |
| 13:44.03 | brlcad | actually was implying the opposite :) |
| 13:45.26 | d-lo | so ``Erik already has people calling him about lunch. lol |
| 13:45.28 | brlcad | I usually have to get reigned in on making too many commits without compiling |
| 13:46.49 | d-lo | ``Erik: does your computer make a noise when i use your screen name in irc? |
| 13:48.46 | d-lo | brlcad: when doing code design, do you do all the function sequencing in your head or on paper, or is there some simple software tools you like to use? |
| 13:48.52 | brlcad | I think you haven't heard his text-to-speach avatar yet? he named it after you |
| 13:48.57 | brlcad | "I'm sorry Dave, I can't do that" |
| 13:49.05 | d-lo | lol |
| 13:49.28 | d-lo | scary part is, I like to play chess :) |
| 13:49.51 | brlcad | probably know the answer, but what do you mean by function sequencing? |
| 13:50.43 | brlcad | i.e., I rarely ever use softare to help with design -- most just make it more complicated to work with others and limit the design process |
| 13:51.09 | d-lo | like when looking at a particular problem. there are usually a few ways of going about accomplishing the solution, but there is more than likely one that is better than the rest. |
| 13:51.17 | louipc | haha I just noticed that circles are ovals on my display |
| 13:51.43 | d-lo | I.e i Have tried the 'just sit down and start coding' approach, but it causes a lot of rework. |
| 13:51.48 | brlcad | ahh |
| 13:52.13 | d-lo | and I am not a big fan or rework. |
| 13:52.22 | brlcad | I usually see it all in my head these days, but if it's too complicated I'm a tactile person so I'll write it down |
| 13:53.03 | brlcad | you're not going to easily see what is better or worse until you code it regardless |
| 13:53.03 | d-lo | as for the writing, do you use Brlcad's personal notation, or things like UML, or a sequence diagram, etc. |
| 13:53.30 | brlcad | rework is going to happen, the best you can do is make rework fast and relatively easy |
| 13:54.14 | brlcad | with agile methodology, you achieve that by NOT implementing more than you need, so each rework is the very minimum necessary |
| 13:54.21 | d-lo | as much as I know effiecient rework comes from experience and skill, there has to be some merit to 'a bit of forethought minimizes rework' ...? |
| 13:54.52 | brlcad | with waterfall, you try to plan for everything, design everything out, stub in functionality all over the place in preparation for expected requirements, ... |
| 13:54.56 | d-lo | heh, well staying focused on the 'bare minimum needed' is a issue of mine. :) |
| 13:55.26 | brlcad | then see most of it thrown away either when you finally get to coding, or months later when the code is revisited |
| 13:55.44 | d-lo | Hrm, don't think I would like waterfall too much :) |
| 13:56.11 | brlcad | the complexity of reading code once it is *outside* of context (how it'll look to someone else or to you months later) is usually what is most important |
| 13:57.15 | brlcad | which is why agile has taken hold in general, by only coding for the "now", the design is never more complex than what it is currently capable of doing, so the code is entropically balanced |
| 13:57.39 | d-lo | ...idealisticly though, right? |
| 13:57.41 | brlcad | i.e. it's easy to understand, at least as easy as the algorithms that were employed |
| 13:59.15 | brlcad | where agile has problems is often on the macroeconomics side of code design -- knowing how to architect things well on a large scale is often not directly realizable on the small scale that agile focuses on |
| 13:59.24 | brlcad | but that awareness is mostly experience |
| 13:59.45 | d-lo | heh, so it all boils down to exp, lol. feck. lol |
| 13:59.48 | brlcad | you *won't* see those problems through design usually, but can till iterate towards them with agile |
| 14:00.23 | brlcad | public/published interface design is probably the exception |
| 14:01.01 | brlcad | you can design your public interfaces up front usually, based on expected features and requirements, then iterate implementation towards making that public interface work |
| 14:01.11 | brlcad | which is basically a form of test-driven development |
| 14:02.02 | d-lo | well that makes sense. :/ |
| 14:02.03 | brlcad | but it is a little harder for most to write a public interface first, to see the impact of how things 'should' be when it's done without making taking short-cuts |
| 14:02.33 | brlcad | it's a great approach, a little more rigorous |
| 14:02.33 | d-lo | what kinda short cuts are you referring to? |
| 14:03.52 | brlcad | hard to stay self-disciplined, particularly when you get to implementation and realize how hard a given interface is going to be or how much grunt work time it's going to take, and to not then change the interface for something else because it was easier to code |
| 14:04.13 | d-lo | ah i c. Yeah I can see that. |
| 14:05.54 | brlcad | e.g., "well, I designed this GS to hide the UUID everywhere in the public API, but .. .. if I just return that uuid to them when they look up geometry and make this getGeometry() call just take a uuid, it'd be really easy to implement..." |
| 14:06.43 | brlcad | more concrete example where hiding the uuid is a "good thing" and was designed to be purely an implementation detail, but then when faced with the complexity of url/path/whatever parsing, you "cave in" and expose it because it's easy |
| 14:06.59 | brlcad | just an example out of an unlimited supply of course |
| 14:07.21 | d-lo | understood. |
| 14:07.36 | brlcad | it's hard to stick to the test :) |
| 14:07.50 | brlcad | especially because the test itself will have limitations |
| 14:09.46 | brlcad | have you had a chance to look over the test interface I wrote up a few weeks back? that might get the mind rolling on top-down design, instead of struggling with trying to prevent rework during bottom-up design |
| 14:10.11 | d-lo | its on the todo list. where didja put it? |
| 14:10.31 | brlcad | there's a class stubbed in there that should hook into whatever public API you provide, either the API or the protocol directly |
| 14:10.38 | brlcad | mm.. think I put it with your other tests |
| 14:10.46 | starseeker | hmm - I'm probably doing it wrong, but as a first cut the PhotoPutBlock needs to be in the parent |
| 14:10.48 | d-lo | kk |
| 14:11.03 | brlcad | starseeker: huh, you sure? |
| 14:11.29 | brlcad | I thought for sure that would work, as it's the events on the window from parent that seemed to be the problem |
| 14:11.32 | ``Erik | reads some backlog O.o |
| 14:11.35 | starseeker | brlcad: no, not really - Just uncommented the PhotoPutBlock in tk_write and commented out the one in the parent... |
| 14:11.56 | ``Erik | d-lo: if it does, I don't notice it... I run irc on a machine in my basement and screen is set up to hide ^G stuff |
| 14:12.35 | d-lo | ``Erik: that's too bad. Was thinking about making a bot that could play you some beep techno. :) |
| 14:12.56 | brlcad | starseeker: does the child still send the bytes, and parent still read then check for events? |
| 14:13.15 | starseeker | yep |
| 14:13.29 | brlcad | ahh, okay |
| 14:13.43 | brlcad | so then it is more what we were talking about yesterday |
| 14:14.04 | brlcad | something about those threads writing to an interp in a thread then updating events from another |
| 14:14.14 | starseeker | ah, wait - hang on. |
| 14:14.26 | brlcad | that's not just thread safety, if true |
| 14:14.38 | starseeker | brlcad: you mind if I commit it from the point where you had it last night, so I can revert if I screw up? |
| 14:14.53 | brlcad | why would i mind? :) |
| 14:15.20 | starseeker | you weren't committing last night :-P |
| 14:15.32 | brlcad | it wasn't working until the end there |
| 14:15.34 | starseeker | such a shocking change of commit behavior must have a reason :-P |
| 14:15.45 | starseeker | ah, point. |
| 14:15.57 | starseeker | <snort> 'course, it's not like it was doing so well before-hand either... |
| 14:16.18 | brlcad | probably should have check-pointed once the out-of-sequent lines were working |
| 14:16.25 | brlcad | but minor diff |
| 14:17.17 | starseeker | aaaaaaah, crap |
| 14:17.20 | starseeker | what'd I break |
| 14:17.25 | starseeker | one sec... |
| 14:17.27 | brlcad | heh |
| 14:17.49 | brlcad | well if you get stuck, you know where the stevens book is now.. :) |
| 14:18.05 | ``Erik | heh, yeh, the commit message is all about communicating what's going on, don't need commit messages that give ya the same feeling that "i++; // increment the value in i and store the result back in i" :) |
| 14:20.19 | brlcad | d-lo: the test should compile outright right now, probably more insightful to see the output it gives |
| 14:20.26 | brlcad | g++ ~/rt^3/src/tests/GeometryServiceTest.cxx |
| 14:20.28 | brlcad | ./a.out |
| 14:21.04 | d-lo | kk reading through it now. |
| 14:21.10 | brlcad | as pieces are implemented, those FAILURE lines will turn into SUCCESS lines |
| 14:21.27 | brlcad | it compiles without any headers/paths/etc as it's not hooked into anything yet |
| 14:21.53 | starseeker | blinks |
| 14:22.04 | starseeker | now it's drawing upside down |
| 14:22.13 | starseeker | that's hilarous, once I figure out what I did wrong... |
| 14:22.32 | brlcad | the classes it stubs are just testing harness -- they're not "the" GS server or client but the _tests_ bridge to one where the glue gets added |
| 14:22.50 | d-lo | right on |
| 14:23.16 | brlcad | starseeker: PhotoPutBlock was position-line# |
| 14:23.37 | brlcad | you probably just made it line# on the move |
| 14:24.14 | starseeker | ah |
| 14:29.52 | CIA-85 | BRL-CAD: 03starseeker * r37837 10/brlcad/trunk/src/libfb/if_tk.c: |
| 14:29.52 | CIA-85 | BRL-CAD: Commit Sean's initial experiments with fork() as an approach to avoiding the |
| 14:29.52 | CIA-85 | BRL-CAD: issues TkAqua is apparently having with incremental refresh. This is NOT any |
| 14:29.52 | CIA-85 | BRL-CAD: kind of final solution, but it does serve as a proof-of-concept that the idea |
| 14:29.52 | CIA-85 | BRL-CAD: does work. |
| 14:30.19 | starseeker | OK, NOW let me see what moving PhotoPutBlock has... |
| 14:30.57 | brlcad | gets movin' |
| 14:31.55 | starseeker | huh |
| 14:32.17 | starseeker | yeah, all I did was comment out the PutBlock in the parent and uncomment the original one in tk_write - nothing |
| 14:48.15 | ``Erik | neat: /System/Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:72:3: error: #error Tk 8.4 must be compiled with tcl.h from Tcl 8.4 |
| 15:26.25 | CIA-85 | BRL-CAD: 03starseeker * r37838 10/brlcad/trunk/configure.ac: Add in the logic to configure that supports enabling threads in tcl/tk builds. |
| 15:45.05 | CIA-85 | BRL-CAD: 03davidloman * r37839 10/rt^3/trunk/src/iBME/CMakeLists.txt: Add GeometryServiceTest to cmake for ease of compiling. |
| 16:26.15 | starseeker | eyes rt - with the fork thing, it looks like from the standpoint of the main application, all the work is done before fb_open is done... |
| 16:38.42 | brlcad | ? |
| 16:48.47 | CIA-85 | BRL-CAD: 03davidloman * r37840 10/rt^3/trunk/ (7 files in 4 dirs): Reworked the connectToHost methodology to facilitate easier, more logical use. |
| 16:50.22 | CIA-85 | BRL-CAD: 03davidloman * r37841 10/rt^3/trunk/src/iBME/: Modify svn:ignore. Now ignore 'GeometryServiceTest' |
| 16:51.59 | CIA-85 | BRL-CAD: 03davidloman * r37842 10/rt^3/trunk/src/tests/GeometryServiceTest.cxx: Formatting change: Indentations and WS. |
| 17:23.10 | CIA-85 | BRL-CAD: 03davidloman * r37843 10/rt^3/trunk/src/ (GS/libNetwork/ GS/libNetwork/CMakeLists.txt libNetwork/): Reorg: Moving libNetwork into gs/libNetwork. |
| 17:34.08 | CIA-85 | BRL-CAD: 03davidloman * r37844 10/rt^3/trunk/include/GS/libNetwork/: Reorg: Creating new dir: include/gs/libNetwork in prep for header moves. |
| 17:53.59 | *** join/#brlcad Elrohir (~kvirc@p5B149B55.dip.t-dialin.net) | |
| 17:54.00 | CIA-85 | BRL-CAD: 03davidloman * r37845 10/rt^3/trunk/ (76 files in 8 dirs): Reorg: Moved libNetwork headers and source files. Updated CMakeLists.txt accordingly. |
| 17:56.40 | CIA-85 | BRL-CAD: 03brlcad * r37846 10/brlcad/trunk/src/librt/ (7 files in 3 dirs): renamed binary_obj.c->binunif.c and db5_comb.c->comb.c to move towards making them more consistent with the layout of other db objects. |
| 18:19.55 | CIA-85 | BRL-CAD: 03brlcad * r37847 10/brlcad/trunk/src/librt/ (CMakeLists.txt Makefile.am attributes.c db5_io.c): separate out the attribute routines from db5_io.c into their own file, attributes.c, so their logic can be better grouped (this should includes _GLOBAL management) |
| 18:20.38 | CIA-85 | BRL-CAD: 03brlcad * r37848 10/brlcad/trunk/src/librt/ (5 files in 3 dirs): ws indent style consistency cleanup |
| 18:21.55 | CIA-85 | BRL-CAD: 03brlcad * r37849 10/brlcad/trunk/src/librt/CMakeLists.txt: ignore prcomb.c |
| 18:26.52 | CIA-85 | BRL-CAD: 03brlcad * r37850 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add attributes.c, rename/move binary_obj.c and db5_comb.c |
| 18:31.22 | CIA-85 | BRL-CAD: 03starseeker * r37851 10/brlcad/trunk/src/libfb/if_tk.c: This allows the Tk framebuffer window to close - not entirely sure if this is correct but it at least lets things function. |
| 18:37.26 | CIA-85 | BRL-CAD: 03starseeker * r37852 10/brlcad/trunk/src/libfb/if_tk.c: Don't need the specific logic for children vs parent - if it's a child it needs it and if its the parent it should never get to it. |
| 18:41.10 | CIA-85 | BRL-CAD: 03davidloman * r37853 10/rt^3/trunk/ (4 files in 2 dirs): Upon handshake completion, NetPortal now updates mappings in NetPortalManager. |
| 18:45.27 | CIA-85 | BRL-CAD: 03erikgreenwald * r37854 10/brlcad/trunk/src/librt/Makefile.am: comb/db5_comb.c is now comb/comb.c |
| 18:56.01 | CIA-85 | BRL-CAD: 03davidloman * r37855 10/rt^3/trunk/ (3 files in 2 dirs): Cleaned up incoming connection handling. |
| 19:05.00 | CIA-85 | BRL-CAD: 03starseeker * r37856 10/brlcad/trunk/src/libfb/if_tk.c: comment update. |
| 20:19.28 | CIA-85 | BRL-CAD: 03davidloman * r37857 10/rt^3/trunk/ (4 files in 2 dirs): Enhancements to Portal disconnect() logic. PortalManager now unregisters/unmaps Portals and RemoteHostname mappings. |
| 21:08.19 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 21:09.50 | CIA-85 | BRL-CAD: 03brlcad * r37858 10/brlcad/trunk/src/librt/ (Makefile.am roots.c): oops, revert back to r37654 .. didn't intend to commit the roots change until next minor release. |
| 21:36.23 | CIA-85 | BRL-CAD: 03bob1961 * r37859 10/brlcad/trunk/misc/win32-msvc8/mged/mged.vcproj: Removed a few references to files that no longer exist. |
| 21:48.19 | CIA-85 | BRL-CAD: 03starseeker * r37860 10/brlcad/trunk/src/libfb/if_tk.c: Trying to have the child send a message to the parent, but so far net result is to wipe out the whole show - no lingering window. |
| 22:28.57 | CIA-85 | BRL-CAD: 03starseeker * r37861 10/brlcad/trunk/src/libfb/if_tk.c: OK, the child still returns, but the destroy event for the window still only works from the parent - so wrap the bu_exit call in the window destroy logic, and have the child process continue on its way with return 0. |
| 22:33.02 | ``Erik | cracks open the new flightgear and ponders finding h is joystick |
| 22:33.20 | ``Erik | waits for the barrage of crude jokes for that one O.o |
| 22:55.21 | CIA-85 | BRL-CAD: 03bob1961 * r37862 10/brlcad/trunk/ (28 files in 12 dirs): More 64-bit windows compatibility mods. |
| 23:33.16 | CIA-85 | BRL-CAD: 03bob1961 * r37863 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Updates to reflect new and newly located files. |