| 03:17.17 | *** part/#brlcad niels_horn (~niels@187.14.62.166) | |
| 03:26.00 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 03:26.08 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 03:26.31 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 03:26.36 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 03:33.57 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 03:42.08 | brlcad | starseeker: thanks for the sync to stable, can hopefully test tomorrow |
| 03:45.06 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 03:45.44 | brlcad | bhinesley: welcome |
| 03:47.08 | bhinesley | brlcad: thank you, hello |
| 03:50.06 | brlcad | bhinesley: so I read the backlog, have you had a chance to look around at things in BRL-CAD yet? |
| 03:50.40 | brlcad | there really are nearly a limitless range of areas where valuable projects can be worked |
| 03:51.44 | bhinesley | I actually just got back from class. Before I left, I was working on getting BRL-CAD compiled; still a couple errors, but close. |
| 03:51.49 | brlcad | from a project-perspective, I can share that this year there is a strong emphasis on projects that are tightly integrated and part of BRL-CAD, refacting and improvements being more interesting than new code that could be developed in isolation |
| 03:52.03 | brlcad | errors? pastebin? |
| 03:52.11 | brlcad | should be a clean checkout/build from latest svn |
| 03:53.00 | bhinesley | I didn't save it, but I'm re-"make"ing right now |
| 03:58.08 | bhinesley | I will hopefully have more to say about the projects that were presented to me, soon. I feel that I should do a bit more research before I understand. |
| 03:58.28 | bhinesley | *will need to to a bit more research |
| 04:05.37 | bhinesley | I am certainly interested in contributing to BRL-CAD, though. Now that I know more about it, I will try to help where I can, GSoC or no. |
| 04:05.54 | bhinesley | here we go: http://pastebin.com/8SgPkDtK |
| 04:07.51 | brlcad | huh, interesting -- that's from svn trunk? |
| 04:07.58 | brlcad | what version of gcc is that? |
| 04:08.15 | bhinesley | 4.5.1 |
| 04:08.33 | brlcad | mm, nice 'n fresh |
| 04:08.35 | bhinesley | it's from here: https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 04:08.38 | brlcad | k |
| 04:10.10 | bhinesley | that is the version that came with the stable brach of Fedora. Should I try a newer version? |
| 04:14.12 | CIA-52 | BRL-CAD: 03brlcad * r43928 10/brlcad/trunk/src/proc-db/clutter.c: |
| 04:14.12 | CIA-52 | BRL-CAD: clear a strict compilation warning from gcc 4.5.1 (reported by bhinesley via |
| 04:14.12 | CIA-52 | BRL-CAD: irc) where a warning about an operation within the random number generator may |
| 04:14.12 | CIA-52 | BRL-CAD: be undefined. it's undoubtedly due to multiple increment calls being passed as |
| 04:14.12 | CIA-52 | BRL-CAD: function args, so evaluation order might not be what one would expect. simple |
| 04:14.13 | CIA-52 | BRL-CAD: enough to get the random number prior to the function. |
| 04:14.15 | brlcad | so that's just a compilation warning, halting because we specify "cc1: warnings being treated as errors" |
| 04:14.22 | brlcad | fixes are usually trivial |
| 04:16.39 | bhinesley | that's what I thought, but I figured the "warnings being treated as errors" was there for a valid reason |
| 04:18.04 | bhinesley | oh, I see now. I'll remove it. |
| 04:18.39 | brlcad | the --disable-strict configure flag will get you past those warnings, though there really shouldnt be many/any .. it's almost complete in your build to have gotten as far as it did only halting in proc-db (one of the last dirs) |
| 04:19.20 | brlcad | it's there to weed those issues out by default, instead of ignoring and/or allowing to accumulate |
| 04:19.30 | bhinesley | makes sense |
| 04:21.13 | brlcad | took several months to bring the code base into full compliance |
| 04:22.06 | brlcad | but in the end, having rigid conformance to all warnings across multiple configurations, platforms, and compilation environments really helps maintainability |
| 04:22.25 | brlcad | and pushes back against lazy coding habits |
| 04:24.22 | bhinesley | hard to argue against paying attention to warnings |
| 04:26.29 | brlcad | bhinesley: so in addition to the project ideas page, there is also http://brlcad.org/~sean/ideas.html |
| 04:27.13 | bhinesley | wow, great |
| 04:27.17 | brlcad | of everything in that list and the project ideas page, priority is generally given to topics that fall into one of our four major focus areas (described in detail at http://brlcad.org/BRL-CAD_Priorities.png ) |
| 04:29.09 | brlcad | our main interest isn't so much in getting code, but towards getting you actively developing (long after gsoc is over) |
| 04:32.01 | bhinesley | assisting in active development is precisely what I am interested in |
| 04:32.04 | brlcad | if that interest is mutual, then the project is really just a catalyst excuse to keep you fed while you code and becaome a proper new dev and we can make a lot more headway on a successful gsoc submission |
| 04:38.50 | bhinesley | to be honest, though, with all the hype surrounding the competitive nature of the GSoC, I feel like I am competing with a bunch of guys polishing up the last 6 months of their PhD's |
| 04:39.21 | bhinesley | not to say that I am not going to put forth the maximum effort. |
| 04:39.40 | brlcad | it's a really wide range of talent and experience |
| 04:39.45 | bhinesley | has used a double negative |
| 04:40.57 | brlcad | having worked with a couple students in previous years whose projects loosely related to their dissertation, I can say that is definitely not something very interesting to entertain again this year unless it was just an outright stellar proposal |
| 04:41.27 | brlcad | those students tend to work on their project and disappear |
| 04:41.55 | bhinesley | expensive, then |
| 04:48.17 | brlcad | feel free to probe any questions on what you might be interested in working on, whether it's something on the list or not -- keeping in mind the "prefer to fix/improve/integrate existing code over writing new code" inclination as a general guideline |
| 04:50.02 | bhinesley | will do; when are you usually here? |
| 04:50.06 | brlcad | and of course, ask all the questions that come to mind - several of us read backlog and comment when time is available |
| 04:50.14 | brlcad | usually all the time ;) |
| 04:50.18 | bhinesley | :) |
| 04:50.25 | brlcad | just sometimes too busy to talk |
| 04:51.09 | brlcad | UTC-4 at the moment |
| 04:52.02 | bhinesley | good to know, I'm -8 |
| 04:54.42 | brlcad | really?? that's alaska |
| 04:55.09 | brlcad | maybe +8? |
| 04:55.49 | bhinesley | california http://upload.wikimedia.org/wikipedia/commons/3/39/Timezones2008_UTC-8.png |
| 04:59.24 | bhinesley | compile successful :) |
| 05:01.57 | brlcad | ah right, so actually UTC-7 then .. (daylight savings) |
| 05:02.51 | bhinesley | huh, I didn't realize the UTC code changed for daylight savings |
| 05:03.05 | bhinesley | makes sense |
| 05:29.10 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 08:14.52 | brlcad | finishes our gsoc flyer: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf |
| 08:15.13 | brlcad | feedback welcome, holding off sending it in to google until after morning |
| 08:16.47 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:24.41 | bhinesley | looks good/professional. Maybe change the color of "GET PAID". Goodnight. |
| 10:46.53 | starseeker | brlcad: nice, I like it |
| 10:47.19 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 10:55.31 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 11:06.27 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:17.26 | dloman | mernin |
| 11:47.54 | starseeker | morning |
| 12:55.54 | yiyus | I'm thinking about applying for the gsoc project "GED Transactions" |
| 12:56.08 | yiyus | looking at libged source it looks like a lot of work |
| 12:57.47 | yiyus | I think most of the transactions would be trivial, but there will probably be some difficult ones... |
| 12:58.04 | yiyus | any idea of where i should be looking at to figure out the dimension of the project? |
| 12:59.53 | brlcad | yiyus: hello! |
| 13:00.05 | yiyus | hi |
| 13:02.39 | brlcad | yiyus: the general idea is to incrementally unroll how each of the commands so they no longer modify geometry |
| 13:02.51 | brlcad | it's a LOT of refactoring, but not hard code fortunately |
| 13:03.47 | brlcad | so, for example, there is a 'kill' command for deleting geometry .. |
| 13:04.26 | brlcad | presently, that command will search for the specified object(s) and it deletes them from the geometry file if it finds them |
| 13:05.30 | brlcad | tranactionally, that would change to having the kill command still search for the specified object(s) like it was doing before, but when it finds them, it records a "delete OBJECT" action |
| 13:06.46 | yiyus | i have worked in text editors with infinite undo before, we made something similar (though a bit simpler): apply the modification and push the inverse function to an undo stack |
| 13:07.08 | yiyus | iiuc your idea is the same, but having also a "done" stack |
| 13:07.51 | brlcad | a wrapper function kill would have been called through gets a resulting action list back from every command, which would then revalidate that all actions can be performed, perform them on a copy, then make the copy replace the original |
| 13:08.50 | yiyus | ah, ok, i think i got it |
| 13:08.57 | brlcad | it's similar to infinite undo (and the wrapper function would also need to record the action and the inverse action to a log) |
| 13:09.21 | yiyus | validating that the operations can be performed would be refactored or would i have to write it from scratch? |
| 13:09.23 | brlcad | the only complexity is that the transactions are nestable |
| 13:10.25 | yiyus | nestable, in the same sense that solidworks transformations are nestable, for example? |
| 13:10.35 | brlcad | I might call one command, which might call another, which might call another, etc.. each of them potentially pushing actions of delete, create, or modify of geometry and views |
| 13:10.49 | brlcad | yes |
| 13:11.25 | yiyus | well, everything sounds quite well, i will have a deeper look to get some familiarity with brlcad and the libged code |
| 13:11.33 | yiyus | one last thing |
| 13:11.56 | yiyus | I also saw the "Geometry Selection Functionality" project |
| 13:12.25 | yiyus | which of them would be preferable? ged transactions or geometry selection? |
| 13:13.03 | brlcad | yes :) |
| 13:13.07 | brlcad | both are high priority |
| 13:13.56 | brlcad | geometry selection is a lot more tangible for gsoc in terms of complexity |
| 13:14.06 | brlcad | so what's your background? |
| 13:14.52 | yiyus | i'm industrial engineer. programming all my real experience is in C |
| 13:15.05 | yiyus | though i also know some other languages |
| 13:15.26 | yiyus | i participated in gsoc 2010, with Plan 9 from Bell Labs, writing a virtual machine |
| 13:15.38 | yiyus | but I don't think that can be applied here |
| 13:15.52 | yiyus | i also know many other languages, but not c++ |
| 13:15.57 | brlcad | how did you like working with the plan 9 guys? |
| 13:16.20 | yiyus | it was great. actually, i have been quite involved in plan9 related projects for some years |
| 13:16.32 | brlcad | are you still working on plan9 too? |
| 13:17.08 | yiyus | yes |
| 13:17.25 | yiyus | i still maintain what i wrote last year, and we have some plans to improve it |
| 13:17.47 | yiyus | as a matter of fact, i'm considering applying there again too |
| 13:18.29 | dli | plan9 still alive? I thought they have stopped it |
| 13:20.17 | yiyus | it is alive, but the team working on it at the labs is very small |
| 13:20.17 | brlcad | dli: oh yeah, their core devs are quite committed .. |
| 13:21.09 | yiyus | there is not any interest in turning it into a mainstream os (which i think is fine) |
| 13:21.27 | brlcad | i've wanted to attempt of port of brl-cad to plan9 |
| 13:21.43 | brlcad | we'd probably compile right out of the box with 80% functionality |
| 13:21.59 | brlcad | tk would be the one tough part |
| 13:22.16 | brlcad | so probably no gui services, but all command-line commands |
| 13:22.32 | brlcad | or at least most, the non-curses ones |
| 13:22.47 | yiyus | there is a tk port for inferno, which runs on top of plan9 |
| 13:22.54 | yiyus | but it is not tcl/tk, it is in limbo |
| 13:24.15 | brlcad | yiyus: so for gsoc submission, both sound like great ideas -- if you were going to tackle the libged one, I'd want to see a lot of up-front planning and testing on just one command before hitting up the 399+ other commands, maybe even having an initial refactoring plan spelled out in the application |
| 13:24.35 | brlcad | that's an important one to "get right" so there's not a lot of time wasted refactoring over and over and over |
| 13:24.53 | brlcad | libged refactoring is another project all in itself (and also high priority) :) |
| 13:26.12 | brlcad | that's also a project that would extend beyond gsoc so it'd be good to hear what dev plans would look like for beyond gsoc timeframe |
| 13:26.40 | yiyus | i will have to get familiar with libged before i can say too much, but will definitively have a look |
| 13:27.05 | brlcad | if that sounds like a lot of work (and it frankly IS, but would rather both of us be honest about it) .. then select may be a much better proposal or a library refactoring proposal since they're much more incremental |
| 13:31.59 | yiyus | may i ask what is your approximate student proposals/gsoc slots ratio? |
| 13:33.41 | brlcad | never know exactly, it really depends on the quality of the proposals more than the count |
| 13:34.00 | brlcad | we do a quick culling to the quality proposals |
| 13:35.05 | brlcad | one year that knocked 50 applications down to about 10 where we selected 4, another year that knocked 35 down to about 15 and we selected 5 |
| 13:35.37 | yiyus | thanks, that's all i wanted to know |
| 13:36.02 | yiyus | some projects cooperate with university departments and such, and have hundreds of applications per slot |
| 13:36.05 | brlcad | if it's a high quality application from a student we've been interacting with and we think is willing to be committed beyond gsoc, will instantly be in that final running |
| 13:36.37 | brlcad | ah yeah, no .. we're way more niche |
| 13:37.19 | brlcad | those sorts of applications rarely result in students that hang around after the summer is up .. interesting for getting academic code, but not so hot for growing the dev team |
| 13:37.44 | yiyus | i would like to stick on the project after gsoc |
| 13:38.07 | brlcad | we would like that as well :) |
| 13:38.08 | yiyus | i work at a department in the university (phd student) and would like to convince my collegues to use free software |
| 13:38.27 | yiyus | that's why i'd prefer brlcad over plan9 |
| 13:40.11 | brlcad | brl-cad's in production use today, but our usability is really tough especially compared to commercial cad systems, very steep learning curve |
| 13:40.27 | brlcad | something actively being worked on, but that's a lot of work that's going to take several years to address |
| 13:42.21 | yiyus | well, i don't expect to substitue autocad this year, but i'm sure it is good enough for easy tasks like test samples |
| 13:42.27 | brlcad | http://brlcad.org/BRL-CAD_Priorities.png is a useful read to know how the various gsoc projects fit into our "big picture" overarching priorities |
| 13:42.39 | brlcad | libged fits in under geometry services |
| 13:50.20 | starseeker | brlcad: so for an undo system, the delete OBJECT action would also record the inverse action (e.g. create OBJNAME OBJTYPE [params...]) in a log somewhere? |
| 14:00.10 | brlcad | right |
| 14:25.59 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:30.38 | brlcad | howdy PrezKennedy |
| 14:30.54 | PrezKennedy | howdy! how's life treating you brlcad? |
| 14:31.02 | brlcad | pretty fantastic |
| 14:31.28 | PrezKennedy | great! |
| 14:31.39 | brlcad | hows work? |
| 14:32.06 | PrezKennedy | meh, we're wrapping up at the 5 sided building come august |
| 14:32.34 | PrezKennedy | we're at the beginning of a dev cycle so it's not hectic at the moment |
| 14:32.40 | brlcad | nods |
| 14:32.57 | brlcad | hopefully employment is not reduced after the 5side is completed ;) |
| 14:33.25 | PrezKennedy | hopefully, but ive been looking at things up there |
| 14:33.37 | PrezKennedy | im not opposed to moving back, not much keeping me down here |
| 14:33.45 | brlcad | bhinesley: good suggestion, added a little color |
| 14:34.13 | brlcad | PrezKennedy: your brother might appreciate this: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf |
| 14:35.09 | starseeker | brlcad: how'd you do the blue halo? |
| 14:36.02 | PrezKennedy | brlcad, something he worked on? |
| 14:56.13 | brlcad | PrezKennedy: yeah, he made that model and rendered the image from scratch |
| 14:57.37 | brlcad | went to the ordnance museum, took measurements, modeled it, set up all the rendering infrastructure, did several massive distributed renderings -- this one being one of the more awesome lighting setups |
| 14:58.10 | brlcad | starseeker: I used the blue pill |
| 14:58.17 | starseeker | heh |
| 14:58.26 | brlcad | i mean, blue 'part'icles |
| 14:59.39 | brlcad | it's actually several composite effects -- a 0-offset shadow, a 2px antialiased stroke, and a light underglow effect |
| 15:00.18 | starseeker | cool |
| 15:02.50 | starseeker | hmm... it looks like I may have been using svn_add very very badly... |
| 15:03.10 | brlcad | heh |
| 15:03.17 | starseeker | or was I... hmm... |
| 15:03.30 | brlcad | wondered that .. an order of magnitude overhead is pretty substantial :) |
| 15:10.51 | starseeker | commit is still an IO hog |
| 15:12.18 | brlcad | one commit or N commits? |
| 15:12.27 | brlcad | hopefully just one |
| 15:12.44 | starseeker | well, I added the full breakout of havoc recursively, and am committing the whole thing |
| 15:12.47 | CIA-52 | BRL-CAD: 03davidloman * r43929 10/geomcore/trunk/ (include/ByteArray.h src/utility/ByteArray.cxx): Add a printHexString(...) method. Helps a tons during t-shooting. |
| 15:15.12 | CIA-52 | BRL-CAD: 03davidloman * r43930 10/geomcore/trunk/src/libNet/Portal.cxx: Add in some commented out ByteArray printHex calls. There's some issue with c++ and java not liking eachother byte orders. T-Shooting continues... |
| 15:16.24 | starseeker | so yeah, just doing one commit ;-) |
| 15:17.58 | CIA-52 | BRL-CAD: 03starseeker * r43931 10/geomcore/trunk/tests/svntest/main.c: Let's not individually add everything - use the svn_depth_infinity parameter setting, and go back to a full breakout - still expensive, but add is a lot quicker |
| 15:19.25 | dloman | so, realistically, are we viewing full model commits as a common occurance? |
| 15:19.42 | dloman | I always invisioned them as part of the 'upfront' cost for using the svn backend. |
| 15:21.08 | dloman | starseeker: if i wanted to 'steal' a root level CMakeList.txt for reworkign the cmake system in rt3, which would be a better fit? the CMakeLists.txt from geomcore or brlcad? |
| 15:21.25 | starseeker | geomcore |
| 15:21.54 | starseeker | dloman: full model commits are only a common occurance if you do things like frequent xpushing :-P |
| 15:22.29 | brlcad | starseeker: it'd be interesting to see what the cost difference is after an xpush, how long commit takes |
| 15:22.51 | brlcad | whether the cost is in the book-keeping to add new nodal entries or whether it's the commit book-keeping itself |
| 15:23.14 | starseeker | once I get the point where I can do something with the broken out .g I can try - my guess is it'll be murder |
| 15:23.45 | starseeker | I edited one primitive and committed it, and it took a while (less than a minute, but still) |
| 15:25.01 | starseeker | maybe 10-12 seconds |
| 15:53.26 | CIA-52 | BRL-CAD: 03davidloman * r43932 10/rt^3/trunk/ (6 files in 4 dirs): Steal Starseeker's geomcore cmake work and apply it to RT3. This is the first step in making RT3 into 'the GeometryEngine' module. |
| 15:53.53 | starseeker | dloman: were you planning to move the ogre/Qt work elsewhere? |
| 15:55.44 | dloman | Dunno.... |
| 15:55.56 | dloman | its currently disabled from any build system.... so.... |
| 15:56.13 | dloman | i think it would warrent discussion at some point :) |
| 15:56.48 | starseeker | liked the idea of having a toplevel geomengine module, that is svn:external included in geomcore |
| 15:57.35 | starseeker | or failing that, scrap geomcore and have two toplevels - geomengine and geomservice |
| 15:58.17 | starseeker | as I understand it, the idea is to reduce temptation to mingle GE and GS code and libraries? |
| 15:59.41 | dloman | nods |
| 15:59.55 | dloman | and singe coreInterface calls rt3 home.... |
| 15:59.58 | dloman | wow |
| 16:00.04 | dloman | s/singe/since/ |
| 16:00.34 | starseeker | I like leaving rt3 as the "repository for random ideas"... geometry engine and geometry service are starting to firm up |
| 16:01.31 | starseeker | conceptual neatness aside, I prefer to have the GE and GS build logic stay fully clean and not be polluted with "other" stuff that may be commented out |
| 16:02.00 | starseeker | but brlcad may have a different take |
| 16:03.28 | dloman | to be fair, the rt3 module was not intended to be the 'sandbox' that it has become. so why not make a 'sandbox' repo? |
| 16:03.47 | starseeker | that's fine too |
| 16:03.48 | dloman | err not repo, but module |
| 16:04.16 | starseeker | would still prefer calling it geomengine or GE instead of rt^3, but I suppose that's a bikeshed issue |
| 16:04.41 | dloman | agreed |
| 16:04.51 | dloman | 'ge' is nice and short :) |
| 16:05.01 | starseeker | dloman: want me to set it up that way? |
| 16:05.09 | starseeker | ge, gs and sandbox? |
| 16:05.34 | dloman | lets get some buy in from brlcad and perhaps Ed et al. |
| 16:05.42 | starseeker | nods - fair enough |
| 16:05.45 | dloman | renaming rt3 effects more than just us :) |
| 16:06.15 | dloman | ...although we could pull a nice prank on Dr Daniel by removing RT3 :) |
| 16:06.24 | starseeker | winces |
| 16:06.46 | starseeker | point - we should probably get GE at least up to parity with his existing rt3 functionality first |
| 16:16.05 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:BRL-CAD GSoC2011 flyer.png]]": This flyer was designed by Christopher Sean Morrison with Google logo and Goliath rendering provided with permission by Google Inc and Stephen Kennedy respectively. |
| 16:16.39 | dloman | currently, all i plan on doing is copying the GeometryEngine class files over (which are stubs) and then make a libge that is nothing but coreInterface files. |
| 16:16.59 | dloman | so, in essence, libge == coreInterface |
| 16:17.05 | dloman | ..initially |
| 16:17.13 | dloman | we will/can grow libge from there. |
| 16:17.38 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2614 10/wiki/Google_Summer_of_Code/2011: add a link to this year's flyer with details on acceptance |
| 16:17.58 | starseeker | nods |
| 16:18.18 | dloman | almost got rt3 to that point. |
| 16:21.00 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2615 10/wiki/Google_Summer_of_Code: link to 2011 flyer, scaled appropriately for landscape |
| 16:21.14 | *** join/#brlcad phani (7ab32f27@gateway/web/freenode/ip.122.179.47.39) | |
| 16:22.27 | starseeker | dloman: go ahead and do what you need to - we can always sort it out later |
| 16:22.32 | phani | i am student interested in participating in Google Summer of Code ... are there any admins around ? |
| 16:22.56 | starseeker | the fundamental cleanup was handled in rt3->geomcore, so subsequent refactoring should be fairly simple |
| 16:22.59 | starseeker | phani: howdy! |
| 16:23.29 | phani | Hi ! I am good . I am a masters student from india. |
| 16:23.33 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2616 10/wiki/Google_Summer_of_Code: /* [[Google_Summer_of_Code/2011|GSoC 2011]] */ |
| 16:23.44 | phani | My area of spcialization in image processing |
| 16:23.46 | dloman | starseeker: nice assertion that I'm going to screw it up :P |
| 16:23.55 | starseeker | dloman: hehe - I didn't mean it like that |
| 16:24.06 | starseeker | phani: have you looked over our projects page? |
| 16:24.14 | phani | yes .. |
| 16:24.21 | starseeker | what do you find interesting? |
| 16:24.24 | phani | http://brlcad.org/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it |
| 16:24.26 | dloman | ..although, with the run of luck i've been having lately, its probably not a bad assertion to make :) |
| 16:24.30 | phani | i am interested in this |
| 16:24.45 | starseeker | dloman: I just ment sorting out directory organization and whatnot |
| 16:25.02 | starseeker | phani: ah - ``Erik knows the most about that subject |
| 16:25.08 | dloman | heh, i added a libge/ dir to src/ .....thats about it! |
| 16:25.26 | starseeker | dloman: cool, that should be fine for now |
| 16:26.04 | phani | ok... will contact eric then |
| 16:26.07 | starseeker | phani: did you have any particular questions? |
| 16:27.01 | starseeker | phani: another image related task would be openexr support |
| 16:27.07 | phani | i wanted to ask more about the project |
| 16:27.33 | starseeker | phani: go ahead - ``Erik and brlcad both read backlogs |
| 16:28.02 | phani | i could not find any other project on image processing there |
| 16:28.05 | starseeker | IRC isn't always real-time communication - you generally stay logged in, post a question, and sometimes get a response later |
| 16:28.07 | phani | can you give me the link to it ? |
| 16:28.36 | starseeker | http://brlcad.org/wiki/High_Dynamic_Range_Support |
| 16:29.17 | phani | thanks |
| 16:30.05 | starseeker | phani: one of the first things to do for any project is to make sure you can compile and run BRL-CAD |
| 16:30.53 | starseeker | the work that has been done so far for the libbu image task is in src/libbu and src/libicv, if I recall correctly |
| 16:30.54 | phani | ok. Will do that now. |
| 16:31.40 | starseeker | phani: since any project will involve a lot of work in the codebase, you want to make sure it's something you feel like you can work in/with |
| 16:32.34 | phani | i like image processing very much and i have considerable command over it. I would like to get some experience on open source coding on that subject |
| 16:32.46 | starseeker | phani: when you check out the subversion source, be sure to get just trunk: |
| 16:32.57 | starseeker | svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad |
| 16:33.27 | starseeker | phani: note that BRL-CAD is a solid modeler, not primarily an image related system |
| 16:34.01 | phani | yes, of course ... |
| 16:34.10 | CIA-52 | BRL-CAD: 03davidloman * r43933 10/rt^3/trunk/src/ (5 files in 3 dirs): Okay, I think i have libGE piggybacking ontop of coreInterface correctly now. Changes to build system have been made. Daniel, please let me know if I broke anything for ya! |
| 16:34.44 | dloman | okay, so how does one setup an svn external? |
| 16:35.19 | starseeker | phani: not to drive you away, but in the interests of covering your options you've also looked at the OpenCV project? |
| 16:37.02 | starseeker | you can submit multiple applications |
| 16:37.54 | CIA-52 | BRL-CAD: 03davidloman * r43934 10/geomcore/trunk/src/ (13 files in 10 dirs): Move some older dev files into an appropriate directory for now. |
| 16:38.35 | phani | yes ... opencv and astronomy.net are the other organizations i am interested in ... |
| 16:47.01 | CIA-52 | BRL-CAD: 03davidloman * r43935 10/geomcore/trunk/src/ (CMakeLists.txt GE/ libNet/CMakeLists.txt): Remove GE from Geomcore. Its going to be its own module.... eventually. |
| 16:47.53 | dloman | Okay, there. GE should be completely in rt3 now, and is piggy backed off of coreInterface. |
| 16:48.32 | dloman | Now on to wiring up geomcore to find libGE and start working the DataManager/DataSource stuff..... |
| 16:48.44 | starseeker | nods |
| 16:53.09 | brlcad | how about simply ge, gs, and gui? |
| 16:53.42 | starseeker | works for me |
| 16:53.43 | brlcad | not really fond of the word sandbox as it implies there are few/no rules and that shouldn't really be the case for any code committed to the repository |
| 16:53.56 | brlcad | relaxed, sure, but sandbox implies more free-for-all to me |
| 16:54.41 | brlcad | hello phani |
| 16:55.14 | starseeker | ge/gs/gui works for me |
| 16:56.54 | brlcad | phani: there are lots of potential image processing related projects in BRL-CAD |
| 16:57.42 | brlcad | there are a few other orgs that are interested in image processing, fwiw, but we definitely have at least two of high interest -- the two mentioned already |
| 16:59.43 | phani | i am looking at the links given by starseeker ... I am also compiling BRL-CAD now. |
| 16:59.51 | brlcad | phani: if you're looking through our source tree, also of interest will be src/util where there are more than 100 image processing tools from image converters, wavelet transforms, filters, scalers, and much more |
| 17:00.31 | brlcad | most of them have man pages and are simply one file per binary |
| 17:00.43 | brlcad | so you can just scan through the *.c or *.1 files |
| 17:00.54 | phani | ok... |
| 17:01.24 | starseeker | brlcad: I chimed in in the Qt discussion on the list, so you may need to smack me down ;-) |
| 17:01.31 | brlcad | there's also src/sig for more general "signal processing" which generally applies to 1D data stremas, but sometimes to 2D streams as well |
| 17:02.58 | phani | I will look at these things now and will contact you back as soon as possible. Its already late night here. |
| 17:02.58 | brlcad | phani: as you're probably already finding out, BRL-CAD is a *very* large system -- we know that and don't expect you to know what's there or how to find things easily, so please do ask questions if you have them |
| 17:03.02 | CIA-52 | BRL-CAD: 03Willdye 07http://brlcad.org * r2617 10/wiki/Building_from_SVN: Give an example for Ubuntu users who don't have autoconf installed |
| 17:03.36 | phani | Thanks for letting me know where to start. I got a very good intro. Will look at it in detail |
| 17:03.47 | phani | and will ask you doubts soon |
| 17:03.51 | brlcad | starseeker: comments sounded spot on to me |
| 17:03.59 | brlcad | matched up with what I was saying in not so many words |
| 17:04.04 | starseeker | brlcad: heh |
| 17:04.40 | starseeker | had viewed the Qt approach as replacing the X11 dm, in the same way that OGRE "replaces" dm-ogl/wgl |
| 17:05.41 | starseeker | growls at subversion... come on, how do I get a list of files... |
| 17:05.48 | brlcad | phani: if you're really into image processing, you have the potential to turn BRL-CAD into your playground (regardless of GSoC) implementing ideas, research, new tools, etc |
| 17:06.46 | brlcad | so while libicv might be something we're interested in from an architecture standpoint, we're more interested getting new long term developers -- so if you have a long term interest there -- then cater your project proposal around that long term interest so you can and will want to keep working on it long after GSoC is over |
| 17:07.05 | brlcad | we want devs more than we want their code ;) |
| 17:08.02 | brlcad | gsoc participants that can convince us of that are an easy shoe-in |
| 17:17.53 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011 participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 17:33.42 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2618 10/wiki/Google_Summer_of_Code: /* Overview */ |
| 17:44.02 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2619 10/wiki/Google_Summer_of_Code: don't repeat ourselves, we list the application guidelines on the checklist. link to the 2011 page. |
| 17:48.32 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2620 10/wiki/Google_Summer_of_Code/2011: link back to main page |
| 18:16.51 | *** join/#brlcad crazy_imp (~mj@a89-182-15-254.net-htp.de) | |
| 18:16.53 | crazy_imp | heyho |
| 18:17.08 | crazy_imp | is it possible to export everything from a .g file with g-stl ? |
| 18:31.17 | CIA-52 | BRL-CAD: 03starseeker * r43936 10/geomcore/trunk/tests/svntest/main.c: Switch back to ktank, make some initial progress on listing out directory contents. |
| 18:32.37 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2621 10/wiki/Google_Summer_of_Code: mention 2010 |
| 18:34.12 | brlcad | crazy_imp: sure, assuming there are no geometry errors and you don't hit a problematic conversion case |
| 18:34.38 | brlcad | you need to know the names of the top-level objects, which can be obtained with: mged -c file.g tops |
| 18:37.15 | crazy_imp | brlcad: i thought of something like this: g-stl .. -o foo.stl foo.g `mged -c foo.g tops` but it doesn't work |
| 18:37.46 | crazy_imp | (i really want something like "g-stl .... foo.g \*" :) |
| 19:12.22 | brlcad | crazy_imp: mged's output by default goes to stderr, so you'd have to run mged -c foo.g tops 2>&1 for that to work |
| 19:13.45 | brlcad | a problem and one of the reasons why you have to specify which geometry objects is because the .g container supports multiple models (multiple hierarchies of models at that) whereas STL only supports a single model |
| 19:15.07 | crazy_imp | brlcad: so i should simply design everything inside one file (at least if it's logical to do so) inside one group for easier converting? |
| 19:17.34 | brlcad | IFF you convert your model to BoT (mesh) format, you might have better luck with something like: mged -c foo.g bot_dump -t stl -o foo.stl |
| 19:17.42 | brlcad | that will dump all BoT objects to files |
| 19:18.13 | brlcad | converting objects to BoT beforehand is done with the facetize command or during import from a polygonal converter |
| 19:19.10 | brlcad | and yes, you very likely will design everything in one file and construct objects together based on their material compositions that need to be differentiated |
| 19:19.31 | brlcad | the principles of effective modeling go into proper modeling best practices in more detail |
| 19:20.34 | *** join/#brlcad Ralith (~ralith@d142-058-175-170.wireless.sfu.ca) | |
| 19:20.42 | crazy_imp | right now i just want to use it for 2.5D modeling ;) |
| 19:44.37 | CIA-52 | BRL-CAD: 03starseeker * r43937 10/geomcore/trunk/tests/svntest/main.c: Re-assemble ktank.g into a staging area. |
| 20:17.10 | PrezKennedy | brlcad, i sent my brother a link to that picture you showed me |
| 21:03.18 | *** join/#brlcad dli (~dli@dyn-216-087.wireless.concordia.ca) | |
| 21:14.03 | CIA-52 | BRL-CAD: 03bob1961 * r43938 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Minor mod to Ged::handle_data_move to not load data for _pane. |
| 21:22.10 | CIA-52 | BRL-CAD: 03brlcad * r43939 10/brlcad/trunk/HACKING: add CADCAM insider to our distribution list |
| 21:24.38 | CIA-52 | BRL-CAD: 03starseeker * r43940 10/geomcore/trunk/tests/svntest/main.c: |
| 21:24.38 | CIA-52 | BRL-CAD: Handle naming (very) slightly better. Maybe need UUID to ensure each connection |
| 21:24.38 | CIA-52 | BRL-CAD: can get its own workspace for assembling geometry from checkouts for return |
| 21:24.38 | CIA-52 | BRL-CAD: shipment down the socket? Or do I need recursive checkout and dbconcat based on |
| 21:24.39 | CIA-52 | BRL-CAD: comb contents for sub-checkouts? (or both?) |
| 21:33.12 | CIA-52 | BRL-CAD: 03starseeker * r43941 10/geomcore/trunk/tests/svntest/main.c: Supply the .g file as an argument, so we can try multiple files without recompiling |
| 22:16.49 | brlcad | starseeker: where do all of the palloc() allocations in src/librt/search.c get freed? |
| 22:20.51 | CIA-52 | BRL-CAD: 03brlcad * r43942 10/brlcad/trunk/NEWS: per r43399, bob fixed a bug in the wgl display manager where it was broken when drawing strings with line breaks in them. now skips no pixels or rows. |
| 22:23.47 | CIA-52 | BRL-CAD: 03brlcad * r43943 10/brlcad/trunk/src/burst/grid.c: VINIT_ZERO instead of constant init. |
| 22:24.40 | starseeker | brlcad: hmm - I think it's up to the function that called db_search_formplan to free it |
| 22:25.02 | brlcad | starseeker: also plan on submitting the iwidgets ttk change upstream, any reason not to? |
| 22:26.04 | brlcad | hm, so search.c has a leak then? it doesn't free the dbplan that it received |
| 22:26.12 | brlcad | looks like it's some sort of nested allocation structure? |
| 22:26.45 | starseeker | brlcad: urm, yeah it's possible search has a leak (may have always had it, for that matter) |
| 22:27.06 | starseeker | brlcad: I can try - don't know what the iwidgets take is on ttk |
| 22:27.15 | brlcad | if you have a valgrind handy, that'd probably be a good one to slip in sometime |
| 22:27.40 | brlcad | don't know how much allocation that is, or if it's just a matter of free'ing the main pointer |
| 22:28.45 | brlcad | it can't introspect it at the libged level because it's a void*, all callers can do is free that |
| 22:30.53 | starseeker | nods - I'm knee deep in subversion at the moment, but I'll try to take a look) |
| 22:31.05 | brlcad | np |
| 22:35.11 | brlcad | yeah, looks like the db_plan_t is a linked list |
| 22:45.07 | brlcad | starseeker: huh, the find implementation that you used apparently never bothers to free any memory |
| 22:45.22 | starseeker | oops |
| 22:45.23 | brlcad | undoubtedly because the application quickly exits |
| 22:45.31 | starseeker | sorry about that |
| 22:45.34 | brlcad | which is fine, bad form but fine, for a binary |
| 22:45.45 | brlcad | problem for a library, since the leak will accumulate |
| 22:45.52 | brlcad | not your fault |
| 22:45.57 | starseeker | should have checked that <puts on programmer dunce cap> |
| 22:55.33 | CIA-52 | BRL-CAD: 03starseeker * r43944 10/geomcore/trunk/tests/svntest/main.c: Add some timing code in. Also try to get cute and call g_diff on the reassembled file, but that's not perfect yet. |
| 22:58.03 | CIA-52 | BRL-CAD: 03brlcad * r43945 10/brlcad/trunk/ (include/raytrace.h src/librt/search.c): |
| 22:58.03 | CIA-52 | BRL-CAD: implement a db_search_freeplan() to go with the db_search_formplan() function. |
| 22:58.03 | CIA-52 | BRL-CAD: releases the allocated db_plan_t linked list structures acquired during a given |
| 22:58.03 | CIA-52 | BRL-CAD: plan formulation. looks like the original source code for find never bothered |
| 22:58.03 | CIA-52 | BRL-CAD: to release any memory, but we have to be more careful since we're in a library. |
| 22:58.36 | starseeker | brlcad: awesome, thanks for swatting that |
| 23:00.14 | CIA-52 | BRL-CAD: 03brlcad * r43946 10/brlcad/trunk/src/libged/search.c: call db_search_free() to release our dbplan allocations. this should prevent/reduce memory leakness across subsequent calls. untested but testing now. |
| 23:00.38 | brlcad | nods |
| 23:03.49 | CIA-52 | BRL-CAD: 03brlcad * r43947 10/brlcad/trunk/NEWS: bob added pix2fb and corresponding fb2pix commands to archer as a means to capture the contents of the framebuffer to a pix image file. useful for screenshots and image overlaying |
| 23:03.54 | brlcad | all commits now reviewed, testing release |
| 23:05.46 | starseeker | brlcad: this should be up your alley: http://pastebin.mozilla.org/1190541 |
| 23:07.16 | brlcad | starseeker: what was the benefit for the ttk scrollbar change? |
| 23:07.36 | brlcad | looks |
| 23:08.17 | brlcad | hm, odd |
| 23:08.25 | brlcad | shouldn't take 38 seconds to reassemble |
| 23:09.24 | brlcad | cat **/*.g only took 0.05 seconds or something from the shell, that's the base time to scan all dirs, open all files, read/write all file data |
| 23:09.38 | brlcad | (for havoc) |
| 23:10.29 | starseeker | I'm using the svn list function, which may introduce some overhead |
| 23:10.43 | starseeker | I don't think I'm going to keep doing it with that function, it's not well suited to this use |
| 23:11.09 | starseeker | is cat faster than db_concat? |
| 23:11.21 | brlcad | not much difference |
| 23:11.27 | starseeker | brlcad: uniformity of appearance in archer |
| 23:11.46 | starseeker | we had switched all our other scrollbars to ttk - the iwidget window was the odd man out |
| 23:11.53 | brlcad | don't want to just cat them, that's more to understand that it's not in the file I/O at least |
| 23:12.02 | brlcad | dbconcat makes sure there aren't name collisions |
| 23:12.15 | brlcad | that might take a sec or two, but definitely not 38s |
| 23:12.18 | starseeker | nods |
| 23:12.31 | brlcad | okay, cool wrt iwidgets |
| 23:12.37 | brlcad | was just wondering what I should write them :) |
| 23:12.43 | starseeker | heh |
| 23:12.49 | brlcad | you make the edits or bob or both? |
| 23:13.08 | starseeker | thinks back... that was me, but Bob told me where to look |
| 23:13.18 | starseeker | and what to remove to avoid some errors |
| 23:13.55 | brlcad | k |
| 23:14.12 | starseeker | has yet to integrate itcl into his working knowledge base |
| 23:15.30 | brlcad | https://sourceforge.net/tracker/?func=detail&aid=3238914&group_id=13244&atid=383689 |
| 23:15.32 | starseeker | I was trying to use svn's list command as a convenient way to get a list of the files I needed to work with, but it's optimized to print out results to the command line |
| 23:16.15 | starseeker | brlcad: cool, thanks! |
| 23:16.44 | brlcad | http://www.devmaster.net/news/index.php?storyid=2663 |
| 23:16.46 | starseeker | bets they're surprised to see anyone still using it |
| 23:17.21 | brlcad | bets they're not |
| 23:17.26 | brlcad | have you met any of the tcl guys? :) |
| 23:17.31 | starseeker | hehe - point |
| 23:18.16 | starseeker | had kind of gotten the impression that tcllib and tklib were gaining more of a following |
| 23:18.27 | starseeker | http://www.tcl.tk/software/tcllib/ |
| 23:21.41 | starseeker | 'course, bwidget still gets used too... oh, well |
| 23:21.48 | starseeker | if it works it works |
| 23:24.09 | brlcad | cool, looks like I didn't bust search |
| 23:47.24 | CIA-52 | BRL-CAD: 03starseeker * r43948 10/geomcore/trunk/tests/svntest/main.c: Add a note on what to do about replacing svn_client_list2 |
