| 01:37.14 | brlcad | minal_bh: depends what scope you're considering, yes and no |
| 01:39.50 | brlcad | the benchmark itself exists (and has for 20+ years), log files already exist, we already have a web server set up, just no website for visualizing and managing the database of benchmark runs |
| 01:40.33 | *** join/#brlcad abhi512 (7ab0e04d@gateway/web/freenode/ip.122.176.224.77) | |
| 01:52.45 | *** join/#brlcad abhi512 (~abhi@122.176.150.101) | |
| 01:54.32 | brlcad | bhinesley: you could have finagled an AI project using BRL-CAD underneath! |
| 02:12.12 | *** join/#brlcad thiago_ (~thiago@201.82.137.119) | |
| 02:32.10 | brlcad | hello thiago_ |
| 02:34.54 | thiago_ | brlcad: hello |
| 02:36.34 | thiago_ | brlcad: I am a student interested in GSoC |
| 02:40.39 | abhi512 | hey, i am abhishek |
| 02:41.51 | abhi512 | i am interested in gsoc12 |
| 02:44.50 | thiago_ | Eu tenho muita experiÊncia em C/C++, algoritmos e estruturas de dados mas tenho pouca experiência com geometria computacional. |
| 02:44.52 | thiago_ | Eu gostaria de saber se é necessário ter muito conhecimento em geometria computacional para participar em um projeto do BRL-CAD para o GSoC. |
| 02:45.17 | thiago_ | error |
| 02:45.21 | thiago_ | correct now |
| 02:45.24 | thiago_ | I have much experience in C / C + +, algorithms and data structures but have little experience with computational geometry. |
| 02:45.25 | thiago_ | I wonder if it is necessary to have much knowledge in computational geometry to participate in a project for BRL-CAD GSoC. |
| 02:54.49 | brlcad | computational geometry is not required |
| 02:55.37 | brlcad | there are a very wide variety of project areas one can work on including graphics, general programming, GUI development, web development, networking, simulation, and much much more |
| 03:01.46 | minal_bh | hi brlcad : I would like to present my understanding about "Benchmark Performance Database " |
| 03:02.11 | brlcad | minal_bh: sure |
| 03:02.27 | minal_bh | 1]The website should offer multiple mechanisms for adding new performance run data: i] Import from log files : Extract log files and insert data into Database. |
| 03:02.35 | minal_bh | <PROTECTED> |
| 03:03.12 | minal_bh | iii] If time permits we can use export from Excel file .. |
| 03:03.24 | minal_bh | 2]It should offer different visualization of performance data |
| 03:03.32 | minal_bh | <PROTECTED> |
| 03:03.55 | brlcad | little to no interest in 1iii |
| 03:04.16 | minal_bh | <PROTECTED> |
| 03:04.18 | minal_bh | ok |
| 03:04.53 | minal_bh | I am assuming that data extracted from log files is suitable for RDBMS representation.. |
| 03:04.56 | brlcad | even after items are imported from log files (1i), there will also need to be some way to manually enter additional details (like #cpus, #cores, memory, etc) |
| 03:05.22 | brlcad | some can be pulled from the logs, but other pieces of information are often not available |
| 03:06.05 | brlcad | if you run the "benchmark" tool from a distribution of BRL-CAD, you can see what the log file actually looks like |
| 03:06.54 | minal_bh | after importing log file we can ask user to enter respective information.. |
| 03:08.44 | minal_bh | How much desing details are expected in the proposal ? |
| 03:33.50 | brlcad | minal_bh: the more the better usually |
| 03:34.13 | brlcad | at a minimum, should be more than 500 words, but that really is a bare minimum |
| 03:34.29 | brlcad | it should not just reiterate our project idea detail page |
| 03:35.49 | brlcad | for example, it'd be good to identify at least the basic architecture being proposed, something like this: http://cia.vc/doc/development/ |
| 03:36.50 | brlcad | specific graphic visualizations, interface mock-ups, details on tasks required, timeline, etc |
| 03:38.46 | brlcad | better to have something brief and complete with a good patch that demonstrates your ability than to have a 20 page proposal that is all talk |
| 03:47.35 | bhinesley | brlcad: hmm, not a bad idea. There's still advanced AI. |
| 03:49.16 | brlcad | an AI-related geometry project we had a student working on a few years ago involved using a GA to evolve CSG expressions that match a non-CSG input |
| 03:50.36 | brlcad | actually worked (though didn't make enough progress to turn it into production-viable) |
| 03:53.00 | brlcad | some other ideas that have come up involve using AI techniques to solve 3D knapsack packing problems (fit objects into a defined container optimally) |
| 03:53.32 | brlcad | using search & optimization for 3d route planning |
| 03:55.12 | brlcad | using shape analysis and classifiers for determining what a given 3d object looks like it might be |
| 03:55.48 | brlcad | and so on .. ;) |
| 04:18.10 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 04:37.52 | bhinesley | brlcad: doing something like that is a possibility in Adv. AI (not offered until next winter) |
| 04:38.20 | bhinesley | glad you mentioned those things though, I woudln't have thought to ask |
| 04:40.20 | bhinesley | I'm kind of an AI noob, but I'm quite interested in it. I might also propose something to you when my senior project comes around. |
| 04:41.24 | bhinesley | it would be great to actually contribute to something, rather than some pet project that gets left in a binder. |
| 05:29.39 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 06:47.38 | *** join/#brlcad andrei_ (~andrei@188.25.158.250) | |
| 07:03.56 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:33.15 | Neil___ | brlcad: hi. I wasn't able to cmake the source in ubuntu. i'm getting this error - "Code to determine current date and time failed!" |
| 09:00.44 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 09:20.12 | *** join/#brlcad witness123 (~witness@14.139.228.210) | |
| 09:26.49 | CIA-128 | BRL-CAD: 03jordisayol * r49812 10/brlcad/trunk/ (misc/debian/rules sh/make_rpm.sh): update cmake optimization argument for deb/rpm building |
| 10:25.33 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@027e71f6.bb.sky.com) | |
| 10:29.19 | *** join/#brlcad witness123 (~witness@14.139.228.210) | |
| 10:40.53 | *** join/#brlcad tuxilina (~tuxilina@141.85.252.190) | |
| 10:41.07 | *** part/#brlcad tuxilina (~tuxilina@141.85.252.190) | |
| 10:41.47 | *** join/#brlcad andrei_ (~tuxilina@141.85.252.190) | |
| 10:44.22 | andrei_ | brlcad: please let me know when you have time to look over my proposal draft. I need to ask you several questions regarding it. |
| 10:58.59 | *** join/#brlcad abhi512 (~abhi@122.176.150.101) | |
| 11:04.58 | *** join/#brlcad witness123 (~witness@14.139.228.210) | |
| 11:42.24 | *** join/#brlcad abhi512 (~abhi@122.176.220.200) | |
| 11:45.45 | *** join/#brlcad andrei_ (~tuxilina@141.85.252.190) | |
| 12:11.56 | CIA-128 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3352 10/wiki/User:Phoenix: /* Interest */ |
| 12:51.17 | *** join/#brlcad phoenix_ (7319d80b@gateway/web/freenode/ip.115.25.216.11) | |
| 12:52.39 | *** join/#brlcad thiago_ (~thiago@187.106.51.49) | |
| 13:00.21 | *** join/#brlcad cristina (~cristina@188.24.80.56) | |
| 13:00.24 | cristina | hello |
| 13:03.35 | *** join/#brlcad Neil___ (~chatzilla@117.229.47.242) | |
| 13:13.49 | *** join/#brlcad abhi2011 (~chatzilla@119.226.184.246) | |
| 13:14.59 | Neil___ | brlcad: hi. I wasn't able to cmake the source in ubuntu. i'm getting this error - "Code to determine current date and time failed!" |
| 13:16.10 | jordisayol | Neil___: witch ubuntu? |
| 13:16.33 | brlcad | Neil___: have you tried the VM image? |
| 13:18.46 | *** join/#brlcad Neil___ (~chatzilla@117.229.47.242) | |
| 13:19.27 | Neil___ | brlcad: oh no. i was trying the Linux source |
| 13:20.38 | jordisayol | brlcad: hello. should I do something else about debug symbols? |
| 13:24.10 | brlcad | Neil___: I'd suggest trying either an svn checkout or using the VM image (for now) |
| 13:24.29 | brlcad | otherwise there are too many variables in play that you'd need to investigate |
| 13:24.41 | Neil___ | brlcad: right. i'll do that. thanks |
| 13:24.42 | brlcad | jordisayol: you mean like not strip them? :) |
| 13:24.50 | *** join/#brlcad andrei_ (~tuxilina@141.85.252.190) | |
| 13:24.57 | jordisayol | brlcad: yes, sorry :-/ |
| 13:24.59 | brlcad | thinks debug symbols should be installed :) |
| 13:25.18 | brlcad | otherwise crash logs become worthless |
| 13:25.20 | jordisayol | brlcad: even in deb/rpm packages? |
| 13:25.28 | brlcad | yep |
| 13:25.42 | brlcad | andrei_: minor point of advice (as I'm happy to look over anyone's proposal draft), but I'd recommend posing questions such that you're not waiting on a specific person to reply |
| 13:26.00 | brlcad | the whole point is debuggability, and the cost is merely a little disk space |
| 13:26.17 | brlcad | our install is not that big |
| 13:27.06 | brlcad | notes his latest software purchase was 11 GB installed .. and it's a game .. |
| 13:28.02 | jordisayol | brlcad: this will at least duplicate the deb/rpm size |
| 13:28.25 | brlcad | so? |
| 13:28.31 | brlcad | it's still insignificant size |
| 13:28.46 | jordisayol | no, just this |
| 13:30.12 | jordisayol | brlcad: this is up to you |
| 13:30.44 | brlcad | basically, is it more valuable to save the user a few mb's of disk space and be unable to help them if something goes wrong, or use a little more disk and get useful reports |
| 13:31.20 | brlcad | if we had a space constraint like fitting on a CD, then it might matter |
| 13:31.30 | brlcad | but we don't .. AND it does fit on a CD regardless ;) |
| 13:32.17 | brlcad | that said, we should figure out why disabling debug doesn't turn the flag off |
| 13:32.18 | jordisayol | brlcad: IMHO, this is not a disk space problem, but band wide one. If we create deb/rpm bigger than 100 MB. many people will think twisebefore download it |
| 13:33.01 | brlcad | so be it -- if they're already that much on the fence, then BRL-CAD will probably be too hard for them to use anyways |
| 13:33.25 | brlcad | disk space ain't got nothing on the learning curve ;) |
| 13:34.11 | *** join/#brlcad abhi_512 (~abhi@122.176.255.178) | |
| 13:43.48 | brlcad | if we had all of our platforms covered so diligently like you do for linux, it might be an option to pull together a "streamlined" release |
| 13:44.45 | brlcad | where we only include core tools/docs/data in a stripped down form.. probably less than 25MB or maybe even less |
| 13:46.02 | jordisayol | well, now I have a problem with deb building package. the debian tools automatically strips its binaries/libraries :-/ |
| 13:46.20 | brlcad | a benchmark release is on my todo, might be such an environment for doing that |
| 13:48.49 | jordisayol | sorry, last comment is incorrect. I forced to do it in the building (i forget this) sorry. |
| 13:49.43 | *** join/#brlcad Neil___ (~chatzilla@117.229.47.242) | |
| 14:08.42 | *** join/#brlcad andrei_ (~tuxilina@141.85.252.190) | |
| 14:14.14 | Al_Da_Best | brlcad try Shogun 2 for space, ~29Gb currently :) |
| 14:22.06 | CIA-128 | BRL-CAD: 03mendesr * r49813 10/jbrlcad/trunk/ (12 files in 8 dirs): Fix MUVES3 issues: MUVES-1472, MUVES-1645, MUVES-1597, MUVES-1646; Updated JScience version in the pom.xml to use the Current MUVES3-Kahona version '4.3.4'. |
| 14:24.47 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@027e71f6.bb.sky.com) | |
| 14:37.49 | cristina | brlcad: I have already had graphviz installed on ubuntu. I can't seem to find any g-dot tool. There's just the dot tool but it won't accept some of the arguments from your example |
| 14:38.04 | cristina | I've also found a dot command in mged |
| 14:39.54 | cristina | I assume that the idea of this "g-dot -o file.dot file.g top" is to output a dot file for a geometry considering the root the "top" node? |
| 14:44.12 | ``Erik | hm, my WoW dir is only 23g |
| 14:45.43 | ``Erik | (and just for fun, "git clone http://crit.brlcad.org/brlcad.git" (read only, updated hourly) :D ) |
| 15:23.26 | brlcad | cristina: g-dot should be in the same directory as mged and a slew of other g-* tools |
| 15:23.47 | brlcad | it wasn't added until 7.20.4, iirc |
| 15:24.08 | brlcad | the vm image should have it installed in /usr/brlcad |
| 15:24.25 | brlcad | /usr/brlcad/dev-7.21.0/bin/g-dot |
| 15:29.20 | cristina | oh, brlcad, it's there, sorry. |
| 15:35.05 | *** join/#brlcad Neil___ (~chatzilla@117.229.47.242) | |
| 15:42.03 | *** join/#brlcad Al_Da_Best (Al_Da_Best@027e71f6.bb.sky.com) | |
| 15:48.19 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@027e71f6.bb.sky.com) | |
| 16:02.10 | Neil___ | how should I run benchmark on windows? |
| 16:04.19 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 16:04.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:22.33 | brlcad | jordisayol: hoping to get back on schedule at the end of this month, but it entirely depends on whether I can get through about 1k commits in that timeframe |
| 16:22.47 | brlcad | end-of-april at the latest |
| 16:22.55 | brlcad | aiming for march, though |
| 16:23.03 | brlcad | rather, first week of april |
| 16:23.40 | *** join/#brlcad Neil___ (~chatzilla@117.229.117.244) | |
| 16:24.56 | jordisayol | brlcad: many thanks |
| 16:43.13 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 16:43.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:46.33 | CIA-128 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3353 10/wiki/User:Stattrav: Preliminary draft |
| 16:46.43 | Stattrav | oops :) |
| 16:47.02 | Stattrav | I shouldnt do that often then, it might spam the hell out people |
| 16:47.30 | Stattrav | brlcad: I have a diagram drawn on a board and have an image of that |
| 16:48.40 | Al_Da_Best | Yeah that was my thoughts yesterday :P |
| 16:48.48 | Al_Da_Best | Not sure if it mentions minor edits |
| 16:49.05 | Stattrav | true |
| 16:50.10 | Stattrav | brlcad: http://i.imgur.com/a7e4x.jpg I think I can even add an edge between Dev and ftp. |
| 17:11.10 | *** join/#brlcad abhi2011 (~chatzilla@119.226.184.246) | |
| 17:20.14 | *** join/#brlcad atneik_ (~atneik@59.178.60.131) | |
| 17:24.30 | CIA-128 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3354 10/wiki/User:Stattrav: |
| 17:39.55 | *** join/#brlcad andrei_ (~andrei@188.25.26.150) | |
| 17:47.33 | brlcad | Stattrav: you can do that as often as you like |
| 17:47.40 | CIA-128 | BRL-CAD: 03Stattrav 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Stattrav process diagram.jpg]]" |
| 17:48.01 | brlcad | it's not spam in the least -- it's actual activity ;) |
| 17:48.52 | brlcad | Stattrav: if only for simplicity, I'd leave ftp out of the picture for now |
| 17:49.11 | brlcad | providing secure ftp upload is a somewhat non-trivial task |
| 17:49.37 | andrei_ | hello |
| 17:49.52 | brlcad | it's doable and fine if you want to tackle that aspect (and a good feature to support), but it will be a little tricky |
| 17:50.27 | brlcad | probably need a cron job to move from an anon ftp folder that would validate it's a log, sanitize, and copy to real queue folder |
| 17:50.40 | brlcad | though I suppose http uploads are just as untrusted |
| 17:50.49 | brlcad | howdy andrei_ |
| 17:53.16 | andrei_ | here is the proposal draft I have been speaking about: https://docs.google.com/file/d/0BzrcTnxrBIMvbmVUUVlqTG5SQ3FOZHU2VFV3cnJYZw/edit |
| 17:53.35 | andrei_ | It only contains rather personal data , there's much to be added |
| 17:55.31 | andrei_ | reading the whole code and planing the proposal on it is probably not viable. bhinesley sugested that I should test various comands from mged in archer |
| 17:56.18 | andrei_ | it there any specific library or part of the code I should look closely. I find dificult to set my starting point |
| 17:56.21 | CIA-128 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3356 10/wiki/User:Stattrav: Added more content |
| 17:56.29 | *** join/#brlcad tuxilina (~tuxilina@p6.eregie.pub.ro) | |
| 17:56.38 | Stattrav | brlcad: I think I can do it |
| 17:56.56 | Stattrav | brlcad: I've done something such when I was working so that shouldnt be a problem |
| 17:57.44 | Stattrav | brlcad: yeah the most important part is to avoid spam, so that process of authentication has to be built into the binary which pushes the data |
| 17:58.34 | Stattrav | brlcad: btw this is a preliminary crude draft |
| 17:59.17 | Stattrav | http://brlcad.org/wiki/User:Stattrav |
| 17:59.52 | Stattrav | btw should I send a mail to the ml ? |
| 18:01.05 | Stattrav | so that you or the other devs can qualitatively comment |
| 18:07.46 | brlcad | if you'd like other devs to read it before submissions open, that would be ideal ;) |
| 18:07.52 | brlcad | they're not all on IRC |
| 18:07.57 | Stattrav | exactly |
| 18:08.49 | Stattrav | I shall make it a bit more elaborate and send it in the morning IST. Got some school work to catch up to. :) thanks |
| 18:10.42 | andrei_ | another question , I tried to list only relevant skills in my proposal, but I do have some basic knowledge of matlab/octave and complex analysis ( for example Fast Fourier Transformation , Frequence sampling etc) should I list those too? |
| 18:16.14 | andrei_ | brlcad: sorry, I thought I set it to accesible by anyone |
| 18:16.17 | andrei_ | I ll fix it now |
| 18:18.49 | andrei_ | fixed it, I'm sorry for that |
| 18:28.04 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 18:30.09 | brlcad | andrei_: no problem |
| 18:30.23 | brlcad | that looks like a really fantastic start, can't wait to read the rest |
| 18:30.38 | DarkCalf | howdy brlcad |
| 18:30.48 | andrei_ | funny , first time I wrote, I put all " my heart" in it. Now I disagree with some parts |
| 18:30.48 | brlcad | howdy |
| 18:33.12 | brlcad | andrei_: well you still haven't gotten to the detailed description, which is arguably one of the most important parts, so don't spend too much time on the personal parts.. ;) |
| 18:33.24 | andrei_ | indeed |
| 18:33.39 | andrei_ | this night I have to finish a project with a hard deadline |
| 18:34.22 | andrei_ | from tomorrow I ll dedicate all the time available to complete it with what really matters |
| 18:36.42 | brlcad | great! |
| 19:02.56 | *** join/#brlcad stas (~stas@188.24.36.145) | |
| 19:04.07 | *** join/#brlcad Neil__ (~chatzilla@117.229.117.244) | |
| 19:14.47 | starseek1r | cristina: sorry I didn't respond earlier - been sick the last few days, not active in channel |
| 19:17.11 | starseeker | Those people seeing the -g flag appear with debug flags off - is that the latest trunk svn checkout? |
| 19:21.15 | cristina | starseeker, don't need to apologize. Everybody has their things to take care of |
| 19:22.23 | jordisayol | starseeker: yes, it is |
| 19:22.44 | starseeker | jordisayol: interesting... I'm not able to reproduce it here - what platform are you on? |
| 19:22.58 | jordisayol | linux 64-bit |
| 19:23.11 | starseeker | huh |
| 19:23.31 | starseeker | jordisayol: can you try clearing your CMakeCache.txt file? |
| 19:24.42 | starseeker | cristina: let's see if we can get brlcad to weigh in on what he things of feeding BRL-CAD's CSG geometry into Netgen :-) |
| 19:24.49 | starseeker | s/things/thinks |
| 19:25.00 | starseeker | come on brain, communicate with the fingers please... |
| 19:28.10 | cristina | starseeker: :) if I can contribute somehow, let me know |
| 19:28.40 | jordisayol | starseeker: there is not a CMakeCache.txt file |
| 19:29.34 | starseeker | O.o |
| 19:29.34 | starseeker | jordisayol: in your build directory? |
| 19:30.06 | jordisayol | starseeker: it exist after cmake command |
| 19:30.10 | starseeker | right |
| 19:30.37 | starseeker | so you've cleared your build directory? |
| 19:31.04 | jordisayol | yes, is a clean build directory |
| 19:31.34 | jordisayol | in fact is an svn export from brlcad trunk |
| 19:33.01 | starseeker | weird |
| 19:33.11 | starseeker | can you post your full configure log somewhere? |
| 19:33.59 | jordisayol | stdou? yes |
| 19:34.13 | jordisayol | s/stdou/stdout |
| 19:54.03 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:54.03 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.22.0 is forthcoming (eta: end of March) || BRL-CAD has applied to participate in GSoC 2012! | |
| 19:54.07 | starseeker | in fact, one of our quickie tasks was to separate out libnmg: http://brlcad.org/wiki/Contributor_Quickies#MEDIUM:_Separate_out_LIBNMG_from_LIBRT |
| 19:54.19 | starseeker | that would make one doozy of a patch to go with an application :-) |
| 19:54.22 | brlcad | surprisingly still separate given how many years they've been intermingled |
| 19:56.29 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@027e71f6.bb.sky.com) | |
| 19:59.05 | andrei_ | I ve read the Simian description |
| 19:59.49 | andrei_ | but I m still not sure of something, does it only detect copy pasted code ( or very similar code) , or uses Somethins miliar to Moss? ( Semantic tree ) |
| 19:59.59 | andrei_ | something * |
| 20:00.55 | andrei_ | from what I read so far it mostly detects copy-paste ' s |
| 20:05.34 | starseeker | cristina: bty - if we have incorrect impressions of Netgen's capabilities, feel free to correct us :-) |
| 20:07.09 | CIA-128 | BRL-CAD: 03starseeker * r49816 10/brlcad/trunk/src/other/CMakeLists.txt: Ah hah! SCL interfering by CACHE FORCE of the build type - dodge the issue by telling SCL to use whatever build type we've set, but still - need to fix the SCL approach |
| 20:07.17 | starseeker | jordisayol: ok, got it |
| 20:07.36 | jordisayol | starseeker: ok, many thanks! :-) |
| 20:08.34 | starseeker | let me know if anything else like that pops up - we're in the process of syncing with the github SCL tree, and they've got some crud left-over from my original attempt at an SCL CMake build system. |
| 20:09.23 | brlcad | andrei_: it has options for collapsing names of variables and ignoring formatting |
| 20:10.23 | brlcad | you can use any tool you like, though, that's just an easy free one |
| 20:10.43 | brlcad | and there are plenty of places in brl-cad that are nearly exact copy-paste anyways that should be refactored |
| 20:11.11 | andrei_ | I will try to run Simian tomorrow in the morning anyway |
| 20:11.43 | andrei_ | Moss is used to check our homeworks and it does have some pretty advanced detection options |
| 20:12.04 | andrei_ | but the major disadvantage is it compares only sources that are bound to do the same thing |
| 20:12.07 | andrei_ | or something similar |
| 20:14.20 | andrei_ | also , it s not necessarly related to refactoring , but I would like to know your opinion over this |
| 20:15.33 | andrei_ | I believe that some macro's like checking ones( at least in some places) are difficult to understand |
| 20:16.36 | andrei_ | how about converting them to functions for the respective data structure |
| 20:18.28 | cristina | starseeker: I'll keep in mind that quickie task you were talking about. |
| 20:18.59 | starseeker | cristina: does Netgen rely on OpenCASCADE for boolean eval? |
| 20:20.09 | starseeker | only paper I could scare up quickly: www.asc.tuwien.ac.at/~schoeberl/wiki/publications/netgen_org.pdf |
| 20:20.18 | starseeker | doesn't say one way or the other, at a quick glance |
| 20:23.03 | cristina | starseeker: it doesn't in the CSG 3d case. I used OpenCASCADE for CSG 2d but my extension is not yet integrated into Netgen |
| 20:23.03 | *** join/#brlcad atneik_ (~atneik@59.178.51.195) | |
| 20:25.24 | starseeker | hmm. So, in principle, we could take individual meshes generated by facetizing individual primitives in BRL-CAD (spheres, ellipsoids, etc.) and feed those meshes and boolean expressions Netgen to generate an evaluated mesh? |
| 20:25.25 | brlcad | starseeker: is there a reason for cachingvariables that the user provides? |
| 20:25.43 | starseeker | brlcad: um. in what context? |
| 20:25.55 | brlcad | in a general context :) |
| 20:26.20 | starseeker | generally, that's how CMake remembers what was passed to it when it is re-invoked... |
| 20:26.21 | brlcad | like your mail to scl-dev, wouldn't have expected CMAKE_BUILD_TYPE to be something we'd even want to cache |
| 20:26.27 | starseeker | we don't |
| 20:26.32 | starseeker | they're doing it it in their logic |
| 20:26.47 | starseeker | I'm saying they don't want to :-) |
| 20:26.55 | andrei_ | I actually looked again over the check macro's, I was wrong. Don t think you could change those and see an improvement |
| 20:26.55 | brlcad | ah, okay |
| 20:27.19 | *** join/#brlcad npcdoom (~npcdoom@190.39.142.150) | |
| 20:27.19 | *** join/#brlcad npcdoom (~npcdoom@gugve/developer/npcdoom) | |
| 20:27.58 | starseeker | the reason jordisayol was seeing -g in the Release build was the SCL build forcing things back to Debug when I forgot to tell SCL to use the same build type as everything else (that's what commit 49816 does) |
| 20:28.12 | brlcad | starseeker: in principle, that's exactly what libnmg does now so by default I wouldn't expect another implementation to be any better (i.e., they'd have to *prove* it's actually better) |
| 20:28.26 | brlcad | good thing we have a testing framework for that now |
| 20:28.44 | starseeker | so the final "assembly" of C flags was using the default Debug flags, instead of the Release flags, since SCL buggered up the build type |
| 20:28.53 | brlcad | got it |
| 20:29.17 | brlcad | how'd that sneak in? one of nick's merges? |
| 20:29.24 | starseeker | my fault |
| 20:29.52 | starseeker | Was syncing with the github SCL CMake logic, and the implications of their forcing CMAKE_BUILD_TYPE didn't register right away |
| 20:30.08 | brlcad | gotcha |
| 20:31.22 | cristina | starseeker: I think it should work. However, as brlcad says, one needs to know if this is a better way to generate mesh |
| 20:31.30 | jordisayol | starseeker: aha. built a new deb, and now it properly works. thanks! :-) |
| 20:32.00 | starseeker | cristina: I guess the question then becomes how hard it woudl be to feed BRL-CAD test cases into Netgen :-) |
| 20:32.06 | cristina | Is there a particular situation that doesn't have the expected output? |
| 20:32.18 | starseeker | jordisayol: awesome! |
| 20:32.33 | starseeker | cristina: oh, sure lots of them |
| 20:33.15 | starseeker | not so much individual primitives (although we do have a few issues at that level) but combining lots of meshes to make larger meshes |
| 20:34.03 | *** join/#brlcad atneik_ (~atneik@59.178.51.195) | |
| 20:34.07 | cristina | yes, the overlapping of primitives at different levels I think |
| 20:34.09 | starseeker | the script conversion.sh in the sh directory is the tool of choice, IIRC |
| 20:35.04 | cristina | and the "side by side" shapes. I recall this was something that took me a while to figure out how to make it generate a correct mesh |
| 20:35.17 | cristina | so that's why you want to feed independent primitives |
| 20:35.25 | CIA-128 | BRL-CAD: 03jordisayol * r49817 10/brlcad/trunk/misc/debian/rules: disable strip on deb package building |
| 20:35.56 | starseeker | right - BRL-CAD can facetize individual primitives (mostly) and the problems come when we start to try merging more complex evaluated meshes on our way up the tree |
| 20:36.27 | cristina | starseeker: the question of how to feed the BRL-CAD test cases into Netgen is a tough one |
| 20:36.40 | starseeker | we could generate a bunch of stl output files... |
| 20:37.38 | brlcad | that alone is "cause for concern" if it has trouble with side-by-side shapes |
| 20:38.05 | starseeker | I think she's referring to the 2D case? |
| 20:38.33 | cristina | yes, I was referring to the 2D case |
| 20:39.21 | cristina | I was just pointing out that I've been told to be careful with these cases because they are tricky |
| 20:39.51 | starseeker | nods. The question is whether Netgen is capabile of handling large, complex merges cleanly |
| 20:39.56 | starseeker | (in the 3D case) |
| 20:40.12 | brlcad | they are very tricky, which is why I've yet to know of a single library that is actually robust for all cases (I believe it's np-complete for floating point) |
| 20:40.30 | brlcad | or at least np-hard |
| 20:40.51 | brlcad | moreover, the underlying approach while appealing in its simplicity, is fundamentally flawed from an evaluation perspective |
| 20:41.05 | brlcad | for implicit geometry |
| 20:42.43 | brlcad | it's like trying to construct a line segmenet from a jpeg that was rendered from an svg |
| 20:43.23 | brlcad | the order is wrong, you get your line segments from the svg then render jpeg as needed |
| 20:43.47 | starseeker | cristina: from the standpoint of a viable BRL-CAD GSoC project, probably better to explore the graph layout for CSG and libnmg projects - demonstraing Netgen's viability would probably be requisit for a viable GSoC project and that's likely too much effort for one application |
| 20:44.30 | brlcad | it's doable, but man would that be one hell of a lot of information to take in for one summer |
| 20:44.40 | cristina | :-)) |
| 20:44.54 | brlcad | understanding nmg structure alone so you could even think of hooking in another lib would probably take a month |
| 20:45.58 | brlcad | another month to evaluate netgen's api for how it can be hooked, another to actually DO the integration ... and however long to test them and document and debug all getting left in the cold :) |
| 20:46.34 | cristina | I imagine, I didn't work on the mesh generation part either (just on the construction of shapes) so that would be another task to go into details of how the meshing is exactly done |
| 20:46.49 | brlcad | would be more viable is someone already spent a summer doing libnmg refactoring or developing a new converter so they're familiar with some parts of the code and api |
| 20:47.27 | brlcad | cristina: so refresh me -- what were you project interests again? |
| 20:47.45 | cristina | for GSoC 2012? |
| 20:47.47 | brlcad | and more importantly, what have you started writeups for ;) |
| 20:47.48 | brlcad | yes |
| 20:48.14 | cristina | Visualizing Constructive Solid Geometry, this is the project that I am interested in |
| 20:48.35 | brlcad | right, g-dot |
| 20:48.44 | brlcad | is that the only interest? |
| 20:48.49 | brlcad | (nothing wrong if it is) |
| 20:49.27 | cristina | well, I considered that I'm best fit for this one but if there are any suggestions, I'm willing to take them into account |
| 20:52.27 | brlcad | hard to say without knowing your interests and experience |
| 20:55.30 | starseeker | cristina: you want to apply to work on things you would enjoy working on |
| 20:57.00 | cristina | ok then, I'll stick to the project. I'd like to work on it, and I liked working on the previous one. This is why I chose the same 'topic'. |
| 20:57.12 | starseeker | very good :-) |
| 20:57.25 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3357 10/wiki/Google_Summer_of_Code/Project_Ideas: stub in mesh library cleanup |
| 20:57.42 | brlcad | cristina: keep in mind that they're mostly only similar in concept -- the codes involved are worlds apart ;) |
| 20:58.40 | Neil__ | brlcad: Hi. For the Materials Database Website, I saw this link: http://cia.vc/doc/development/ and I was wondering how I should modify it to suit the project. Should I make a similar flow diagram for frontend and backend? |
| 20:59.07 | cristina | brlcad: I am aware of that, that is why I used 'topic'. The task and approach of the project are indeed different ;-) |
| 21:01.13 | cristina | I need to go now. bye everyone |
| 21:01.25 | starseeker | later |
| 21:01.42 | brlcad | cya |
| 21:01.46 | brlcad | very good |
| 21:02.18 | starseeker | should probably fish out that old build of goblin he had going with CMake... |
| 21:09.37 | starseeker | ah, actually predated CMake |
| 21:09.41 | starseeker | hmm... |
| 21:11.43 | starseeker | no, not quite - just no toplevel |
| 21:11.57 | starseeker | digs a bit more... |
| 21:15.29 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3358 10/wiki/Mesh_library_cleanup: mesh library cleanup! |
| 21:15.51 | brlcad | starseeker: feel free to embellish if I missed anything: http://brlcad.org/wiki/Mesh_library_cleanup |
| 21:17.02 | starseeker | which is the paper that spells out the NMG structures? Is that the Butler/Muuss CSG paper? |
| 21:17.18 | brlcad | I don't have it handy |
| 21:17.28 | starseeker | goes fishing... |
| 21:17.41 | brlcad | Muuss91c |
| 21:17.54 | brlcad | and Weiler87a |
| 21:18.03 | starseeker | http://ftp.arl.army.mil/mike/papers/90nmg/ |
| 21:18.26 | brlcad | yeah, that'd be good to add |
| 21:18.34 | starseeker | need a pdf version... |
| 21:18.41 | brlcad | mac will convert |
| 21:19.12 | brlcad | that'd be a good one to convert the original tek sources to docbook |
| 21:21.33 | starseeker | hmm - TeX will need some updating even to process as TeX these days, from the looks of it... |
| 21:23.12 | CIA-128 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3359 10/wiki/Mesh_library_cleanup: Add link to 90nmg paper |
| 21:29.20 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3360 10/wiki/Google_Summer_of_Code/Project_Ideas: stub in nurbs optimization and cleanup |
| 21:31.56 | *** part/#brlcad atneik_ (~atneik@59.178.51.195) | |
| 21:43.55 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3361 10/wiki/NURBS_Optimization_and_Cleanup: fill in details of nurbs cleanup |
| 21:43.59 | brlcad | starseeker: there's another |
| 21:45.15 | starseeker | cool |
| 21:57.30 | CIA-128 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3362 10/wiki/User:Stattrav: |
| 21:58.12 | brlcad | is forgetting another great idea that came up recently |
| 22:00.02 | brlcad | so we got the go ahead from google to include SCL under us an umbrella this year, but they thusfar seem to be uninterested .. |
| 22:00.09 | brlcad | I don't think we've heard anyone express SCL interest yet, but something to keep in mind |
| 22:01.08 | starseeker | nods |
| 22:12.13 | CIA-128 | BRL-CAD: 03starseeker * r49818 10/brlcad/branches/goblin/: remove obsolete goblin branch - glpk toolkit is GPL, and in any case build logic not in a functional state. |
| 22:19.13 | brlcad | any more ideas come to mind based on recent discussions? |
| 22:19.40 | brlcad | ah, networking |
| 22:26.19 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3363 10/wiki/Google_Summer_of_Code/Project_Ideas: add a section for networking and stub in a libpkg enhancement task |
| 22:28.57 | starseeker | there we go: http://bzflag.bz/~starseeker/goblin-2.8b30-cmake.tar.gz |
| 22:29.41 | starseeker | quick and dirty compared to BRL-CAD's, but hopefully enough to get up and running on most setups with Tcl/Tk installed |
| 22:35.02 | CIA-128 | BRL-CAD: 03Sean 07http://brlcad.org * r3364 10/wiki/Package_Library_Extensions: fill out libpkg enhancements |
| 22:41.41 | brlcad | starseeker: you have seen http://www.graphviz.org/pdf/libguide.pdf yes? |
| 22:42.29 | starseeker | not sure if I've see that one, but have seen similar ones |
| 22:42.43 | starseeker | last I checked though, graphviz licensing wasn't compatible with BRL-CAD |
| 22:43.07 | brlcad | it's eclipse license iirc, which I haven't read in full |
| 22:43.55 | starseeker | looks again - haven't checked in a while |
| 22:44.22 | starseeker | ah - that's new |
| 22:44.32 | brlcad | gnuplot is another, they have a lib |
| 22:44.38 | starseeker | was thinking of the AT&T Source Code agreement |
| 22:44.43 | brlcad | but might be a little too manual |
| 22:44.47 | starseeker | gnuplot's license has always been... funky |
| 22:44.51 | starseeker | unless that's changed too |
| 22:45.13 | brlcad | graphiz would be ideal, they're one of the better free ones at this |
| 22:45.53 | starseeker | sure - at the time of my listing adaptagrams and goblin, graphviz was using the old AT&T agreement (IIRC) |
| 22:46.21 | starseeker | http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER |
| 22:48.05 | brlcad | that's basically saying it cannot be relicensed because the terms aren't the same |
| 22:48.31 | brlcad | the last faq question is more to the point but answers gpl-compatibility, not lgpl |
| 22:48.38 | starseeker | Qt seems to think they aren't compatible: http://qt.nokia.com/about/licensing/frequently-asked-questions |
| 22:48.47 | starseeker | (last question) |
| 22:49.34 | brlcad | nods, was just reading that too |
| 22:49.58 | brlcad | so there's some new clause it adds |
| 22:50.12 | brlcad | s/clause/requirement/ |
| 22:51.14 | brlcad | so that sucks |
| 22:51.54 | starseeker | was hoping one or both of gobin/adaptagrams might have what we need... |
| 22:52.25 | brlcad | maybe |
| 22:52.45 | brlcad | frankly our situation may be even (considerably) easier than is handled by a general graph library |
| 22:53.25 | brlcad | given it's a directed graph with a singular head node, the levels are very well-defined |
| 22:54.53 | starseeker | nods - could be |
| 22:55.15 | starseeker | Goblin was particularly interesting in that it already has some Tcl/Tk hooks |
| 22:55.22 | brlcad | if you assume each model node is postage-sized, say 32x32 -- it's pretty straightforward to just draw your top-level node, then count up children, center, draw connecting lines, recurse |
| 22:56.05 | brlcad | i mean you might end up with 1k lines of code to do that instead of 30-60k for a library with potentially other dependencies and maintenance costs (build system integration at a minimum) |
| 22:56.18 | brlcad | really depends what all the library does for us |
| 22:56.25 | starseeker | nods |
| 22:56.46 | starseeker | also depends on what sorts of layouts we want to support |
| 22:57.02 | brlcad | yeah |
| 22:57.05 | starseeker | the "neato" style circular layouts are kind of nice in some ways |
| 22:58.11 | brlcad | tree view is probably the expected norm -- they're going to want to treat it like a graphical filesystem browser |
| 22:58.32 | brlcad | we just have to make sure that the "graph" aspect is represented when nodes are instanced |
| 22:59.02 | brlcad | so it's clear when you split/duplicate a single node and when you clone a subtree for example |
| 22:59.14 | starseeker | ah - so that's a little less radical than I was thinking |
| 22:59.48 | starseeker | maybe just layer something on top of tktreectrl then |
| 23:00.10 | starseeker | http://tktreectrl.sourceforge.net |
| 23:00.53 | starseeker | brlcad: probably need to re-work the description of that task on the project ideas page |
| 23:05.17 | starseeker | if we go that route, maybe roll in the "geometry browser as pluggable Tcl/Tk widget" aspect |
| 23:08.23 | starseeker | brlcad: in some ways we already do track multiple node references with the graphical highlighting in Archer's current widget |
| 23:08.35 | starseeker | did you have something else in mind? |
