| 00:29.06 | *** join/#brlcad n_reed_ (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 01:54.38 | *** join/#brlcad merzo (~merzo@86-98-133-95.pool.ukrtel.net) | |
| 02:00.18 | *** join/#brlcad cadman (~Adium@64.178.177.71) | |
| 02:08.37 | cadman | Is there somewhere I can read up on the current status of the java version of brlcad |
| 02:33.43 | *** join/#brlcad cadman_ (40b2b147@gateway/web/freenode/ip.64.178.177.71) | |
| 02:34.22 | cadman_ | Is there anywhere I can read about the current status of the jbrlcad? |
| 02:34.30 | cadman_ | Java brlcad |
| 02:36.03 | brlcad | cadman_: there is nothing happening with the java version at this time |
| 02:36.15 | brlcad | an no plans to restart that activity any time soon |
| 02:37.03 | brlcad | the sources are in svn and it implements a decent portion of our geometry format and some of our most simplistic primitives |
| 02:38.26 | brlcad | it was more an experiment and, while successful, mostly straight-up duplication of our existing code into an object-oriented form |
| 02:39.10 | brlcad | cadman_: answer your question? |
| 02:40.12 | cadman_ | Yes that did so if I wanted to continue working on it and implementing some of the other primitives is that something the group here would be interested in? |
| 02:40.20 | brlcad | my more near-term goal is to develop an object oriented API (our "Geometry Engine" project) that could be wrapped in java bindings, but implemented as C++ |
| 02:41.02 | brlcad | along with another network-centric protocol (our "Geometry Service" project) to be language agnostic (kind of like talking to mysql or apache, but for geometry) |
| 02:41.40 | cadman_ | Yeah I saw the beginnings of that in the source |
| 02:41.41 | brlcad | you're welcome to do that if you like, and I'd be happy to set up your commit access and such if that helps |
| 02:42.51 | cadman_ | Ok let me play with it some more but I'm thinking it would be fun |
| 02:43.18 | brlcad | but it's not something that we'd likely intend to maintain as it was all fun and games until it got to the harder primitives like torus and polygonal meshes where there they entail complex root solvers, spatial partitioning, accelleration structures, and more .. a crapload of code to transcode |
| 02:44.02 | cadman_ | right I would expect that to be the case |
| 02:44.22 | brlcad | i mean we have nearly half a million lines of code in just our core libraries -- even using some of the jdk, you'd probably end up needing to replicate at least 250k into OO form |
| 02:44.52 | brlcad | and it's probably be out of date, incompatible, or missing some feature long before you finish :) |
| 02:45.14 | cadman_ | Your so encouraging :) |
| 02:45.35 | brlcad | hey, I just want to set up realistic expectations |
| 02:45.46 | brlcad | maybe there's some other angle of interest? |
| 02:45.50 | cadman_ | Yeah I understand I'm just being funny |
| 02:46.23 | brlcad | like you could work on a thin client that talks through jni bindings or something similar |
| 02:46.46 | cadman_ | Yeah thought about that |
| 02:46.58 | cadman_ | that is pretty uphill as well |
| 02:47.09 | brlcad | having a portable "geometry viewer" application built on our C libraries would be pretty useful |
| 02:47.32 | brlcad | not nearly as uphill as transcoding 250k lines of complex and highly optimized C code ;) |
| 02:47.43 | cadman_ | Well as portable as the native libs but I realize the libs have been ported to a ton of platforms |
| 02:48.03 | cadman_ | You make a good point let me mull it over |
| 02:48.15 | brlcad | there are other ideas abound as well |
| 02:48.21 | brlcad | what's your interest? |
| 02:48.32 | brlcad | just looking for something to play with? |
| 02:48.42 | cadman_ | Yeah mostly |
| 02:50.18 | brlcad | interested much in servlet programming? |
| 02:51.10 | cadman_ | What did you have in mind |
| 02:52.19 | brlcad | well, pretty much any of the web dev tasks at http://brlcad.org/~sean/ideas.html could be a servlet |
| 02:53.46 | cadman_ | ok I will look it over |
| 02:57.55 | brlcad | basically three diferent web projects with lots of possible directions they could go in, but huge impact potential |
| 02:59.31 | brlcad | another long-term useful would be the starter implementation of a stand-alone thin-client application that can talk to our Geometry Service |
| 02:59.55 | brlcad | still, those are all rather big projects |
| 03:01.18 | brlcad | might make more sense to just start with something tiny to become a little familiarized with the code |
| 03:04.50 | brlcad | we break out 2+ hours tasks at http://www.google-melange.com/gci/org/google/gci2012/brlcad |
| 03:05.26 | brlcad | and 2+ month tasks at http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas |
| 03:12.58 | cadman_ | Thanks for the tips brlcad |
| 03:17.30 | cadman_ | Is there anything written up on Create a web-based interactive 3D geometry viewer |
| 03:18.12 | cadman_ | Is the Geometry Service functional at this point? |
| 03:18.20 | brlcad | do you need something written up? :) |
| 03:18.27 | cadman_ | No |
| 03:18.58 | cadman_ | Just seeing if someone had already done something |
| 03:19.43 | cadman_ | So the idea would be that the user would see a a tree structure of the geometry then select something to be viewed in the 3d view? |
| 03:21.19 | brlcad | docs could be arranged, but I'd just set up some useful goals -- nothing has happened on that front other than watching what some of the other companies have done |
| 03:22.01 | cadman_ | Na you don't have to do anything can you point me to some of the other sites you liked |
| 03:22.25 | cadman_ | Just one other site and I will go from there |
| 03:28.34 | cadman_ | Ok I think I know where to go from here thanks for the help and conversion |
| 03:34.43 | brlcad | well, one of the more complex ones: https://www.autocadws.com/ |
| 03:36.26 | cadman_ | The starting point would be a servlet (I think you already said that) |
| 03:36.51 | cadman_ | Then worry about all the other stuff after you have that |
| 03:37.40 | brlcad | yeah, the trick would probably be a servlet that talks to our tools or libraries |
| 03:38.34 | brlcad | so you could upload a geometry file, open the file using our functionality (e.g., to get a hierarchy), and provide some sort of visualization |
| 03:39.00 | brlcad | (ideally web gl) |
| 03:39.39 | cadman_ | right that is what was coming to mind |
| 03:40.21 | brlcad | could maybe extract a wireframe first, that's pretty simple |
| 03:40.22 | brlcad | and would work with pretty much any format geometry |
| 03:42.12 | brlcad | if you get a hankering to commit work into our repo, lemme know and I'll get a module set up to work under |
| 03:44.47 | cadman_ | If I get any worth anyone looking I will definitely commit it |
| 04:09.52 | brlcad | even if you want to commit while you learn and explore, nice to see the progression |
| 04:28.22 | cadman_ | ok if you want to create a module then I will commit to that |
| 04:56.20 | brlcad | cadman_: what would you like it to be called? |
| 04:56.57 | brlcad | and what's your sf.net username? |
| 04:59.21 | cadman_ | I already have commit status ddreeves70 |
| 05:02.24 | *** join/#brlcad cadman (~Adium@64.178.177.71) | |
| 05:03.12 | brlcad | oh, haha, didn't know that was you! |
| 05:03.48 | cadman | Sorry wasn't trying to be mysterious |
| 05:06.16 | cadman | I decided if I was going to be able to get anything done effective I am going to need to stick with something a little closer to what I do in my day job |
| 05:06.52 | cadman | This viewer definitely seems like something I can get into |
| 05:09.03 | *** join/#brlcad cadman_ (40b2b147@gateway/web/freenode/ip.64.178.177.71) | |
| 05:12.34 | *** part/#brlcad cadman (~Adium@64.178.177.71) | |
| 05:14.54 | *** join/#brlcad tofu1 (~morrison@c-68-34-100-50.hsd1.md.comcast.net) | |
| 05:15.18 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 05:15.57 | brlcad | apparently some ISP woes |
| 05:16.37 | brlcad | cadman_: I was about to say that you should be able to create the module yourself |
| 05:17.02 | cadman_ | ok wasn't sure if I could I will create it |
| 05:17.21 | brlcad | just create a directory (e.g., webcad) with trunk/tags/branches subdirs, then |
| 05:17.36 | brlcad | svn import webcad https://brlcad.svn.sourceforge.net/svnroot/brlcad/webcad |
| 05:18.35 | brlcad | modules are just convention in svn, just like the other common folders |
| 05:19.14 | brlcad | after the import, a checkout should work: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/webcad |
| 05:19.17 | brlcad | or whatever you call it |
| 05:19.41 | cadman_ | webcad sounds good |
| 05:21.59 | brlcad | oops, that'd be: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/webcad/trunk webcad |
| 05:29.30 | *** join/#brlcad cadman (~Adium@64.178.177.71) | |
| 06:34.35 | *** join/#brlcad caen23 (~cezar@92.83.161.244) | |
| 08:28.44 | *** join/#brlcad tofu_ (~sean@66-118-151-70.static.sagonet.net) | |
| 08:29.24 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) | |
| 08:29.39 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 08:29.50 | *** join/#brlcad maths22 (~gcimaths@66-118-151-70.static.sagonet.net) | |
| 08:44.22 | *** join/#brlcad cadman1 (~Adium@64.178.177.71) | |
| 08:44.29 | *** part/#brlcad cadman1 (~Adium@64.178.177.71) | |
| 08:45.33 | *** join/#brlcad cadman (~Adium@64.178.177.71) | |
| 09:56.09 | *** join/#brlcad merzo (~merzo@86-98-133-95.pool.ukrtel.net) | |
| 10:39.07 | *** join/#brlcad witness (uid10044@gateway/web/irccloud.com/x-omxoiodyajytlnad) | |
| 11:43.27 | ``Erik | if people want java on BRL-CAD, librtserver could also have the class named fixed and the java side implemented, then be extended |
| 11:45.53 | ``Erik | scheme->vhdl compiler http://scheme2006.cs.uchicago.edu/05-saint-mleux.pdf O.o |
| 11:49.08 | *** join/#brlcad caen23_ (~cezar@92.81.167.240) | |
| 11:50.05 | ``Erik | huh, looks like sago wasn't talking from 12:05am to 3:25am |
| 14:06.25 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) | |
| 14:06.29 | Notify | 03BRL-CAD:starseeker * 54560 brlcad/trunk/src/librt/primitives/bot/bot.c: Introduce bbox information into the adaptive plot logic. |
| 14:06.32 | brlcad | ``Erik: yeah, you probably missed the rest of our discussion in that timeframe |
| 14:07.09 | brlcad | he plans to create a webcad module to work in |
| 14:07.18 | ``Erik | yeah, saw that, I do irc from my home server :) |
| 14:07.24 | brlcad | ah, cool |
| 14:07.36 | Notify | 03BRL-CAD:ddreeves70 * 54561 jbrlcad/trunk/pom.xml: Testing commit status |
| 14:07.38 | Notify | 03BRL-CAD:brlcad * 54562 brlcad/trunk/include/bu.h: declare and document the new bu_heap_get() and bu_heap_put() functions. |
| 14:07.53 | *** part/#brlcad brlcad (~morrison@c-68-34-100-50.hsd1.md.comcast.net) | |
| 14:07.54 | Notify | 03BRL-CAD:ddreeves70 * 54563 NIL: Creating a module for building web based cad tools |
| 14:07.56 | Notify | 03BRL-CAD:ddreeves70 * 54564 NIL: creating basic project structure |
| 14:09.11 | Notify | 03BRL-CAD Wiki:Ancernalior * 0 /wiki/User:Ancernalior: |
| 14:09.13 | Notify | 03BRL-CAD Wiki:Sean * 4955 /wiki/TOC: |
| 14:25.30 | Notify | 03BRL-CAD:bob1961 * 54565 (brlcad/trunk/src/tclscripts/archer/Archer.tcl brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl): Added Copy/Paste/Kill/Killall/Rename functionality to Archer's tree menu. |
| 14:58.10 | Notify | 03BRL-CAD:bob1961 * 54566 (brlcad/trunk/src/archer/archer brlcad/trunk/src/libtclcad/tclcad_obj.c): Dynamically set the brlcad version in Archer's title bar. |
| 15:33.40 | Notify | 03BRL-CAD:brlcad * 54567 brlcad/trunk/src/libbu/heap.c: increase the range of supported allocations from 1-256 and 1MB-sized pages. minor overhead to support an even bigger range, but pagesize should probably not exceed 1MB. report additional stats on the number of hits (allocations in range) and misses (out of range size). |
| 15:38.51 | Notify | 03BRL-CAD:brlcad * 54568 (brlcad/trunk/include/nmg.h brlcad/trunk/src/librt/primitives/nmg/nmg_copy.c): undo the usage of richard's pooling memory interface underneath NMG. direct profiling of the implementation showed it to be an order of magnitude slower than bu_malloc/calloc, 50M allocations went from 5s to 70s-90s. |
| 15:44.24 | Notify | 03BRL-CAD:brlcad * 54569 brlcad/trunk/include/nmg.h: remove the bu_pool hooks now in dead #if 0 sections. also simplify NMG_FREESTRUCT() .. BU_PUT() already zero's the data and pointer. |
| 15:48.11 | Notify | 03BRL-CAD:brlcad * 54570 brlcad/trunk/include/bu.h: stub in calls to the new bu_heap get/put API underneath BU_GET/BU_PUT, but do not enable for the time being because all of the existing BU_GET calls need to be reviewed to be either paired with BU_PUT or converted to BU_ALLOC. |
| 15:52.02 | Notify | 03BRL-CAD:brlcad * 54571 (brlcad/trunk/include/bu.h brlcad/trunk/src/libbu/CMakeLists.txt brlcad/trunk/src/libbu/Makefile.am): undeclare and remove the bu_pool routines |
| 16:06.38 | Notify | 03BRL-CAD:brlcad * 54572 brlcad/trunk/NEWS: richard updated openNURBS from the 2010 sources to the newest 2012-10-24 release (still v5.0). |
| 16:16.55 | Notify | 03BRL-CAD:brlcad * 54573 brlcad/trunk/src/other/openNURBS.dist: revert r54203 from r_weiss on 2013-01-25 as that removes new files that were added to opennurbs instead of adding them to our build logic. fix to build and distcheck coming up next. |
| 16:26.37 | maths22 | brlcad: could pv (progress viewer) be added to the server? |
| 16:38.29 | brlcad | maths22: what is that? |
| 16:39.54 | n_reed | maybe he meant pipe viewer |
| 16:40.10 | brlcad | yeah, was just reading .. interesting tool |
| 16:41.29 | *** join/#brlcad caen23 (~cezar@92.81.184.173) | |
| 16:41.36 | brlcad | installing |
| 16:41.49 | brlcad | installed |
| 16:43.21 | starseeker | yipe - can anyone confirm a crash in MGED using the analyze command on a BoT? |
| 16:43.43 | starseeker | archer too, but looks like it may be a different crash there... |
| 16:48.07 | brlcad | looks like opennurbs isn't at all sync'd with the latest sources... what?? |
| 16:50.08 | brlcad | starseeker: I don't have a clean build, but do you get a bunch of BU_PUT errors? |
| 16:50.54 | starseeker | brlcad: no, it's something else - some kind of vls error in MGED, and a failure to free in archer |
| 16:51.15 | brlcad | analyze worked on a simple bot here |
| 16:51.22 | starseeker | hrm. |
| 16:51.30 | starseeker | OK, I'll scrap my build and try a clean one |
| 16:51.59 | n_reed | i was able to both run it and crash it on moss.g all.g/box.s |
| 16:52.14 | brlcad | all my changes have been screwing around with memory, so keep an eye out for anything that may be a partial commit |
| 16:52.45 | brlcad | I've got three build trees going in various stages of migration, trying to make sure the new heap stuff stays inactive |
| 17:03.45 | maths22 | sorry that I used the wrong name. I was going from memroy |
| 17:04.01 | Notify | 03BRL-CAD:brlcad * 54574 brlcad/trunk/include/bu.h: gah, need to wrap the multi-statement form of BU_PUT in curlies or unwrapped if(null) tests will still run the free |
| 17:04.02 | brlcad | starseeker: try again on update |
| 17:04.30 | brlcad | that might have been it, was missing curlies so might have been free'ing memory prematurely |
| 17:05.10 | brlcad | soon as this rebuild finishes, I'll try again with the moss case |
| 17:08.32 | maths22 | what is eniac_1946.pdf doing in the web direcotry? |
| 17:08.38 | maths22 | it's nearly 300 MB |
| 17:10.35 | n_reed | brlcad: works for me, I can't get it to crash anymore |
| 17:20.35 | Notify | 03BRL-CAD:bob1961 * 54575 (brlcad/trunk/src/tclscripts/archer/Archer.tcl brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl): Added "Save as png ..." menu items to the display menus. |
| 17:24.19 | brlcad | n_reed: okay, cool |
| 17:25.15 | brlcad | starseeker: have you seen opennurbs_basic.cpp ? |
| 18:03.26 | Notify | 03BRL-CAD:brlcad * 54576 (brlcad/trunk/src/other/openNURBS/build_opennurbs_vs2010.sln =================================================================== and 481 others): turns out r54203 was removing files that opennurbs removed, so I was wrong about them needing to be added to the build logic (something fishy, they were in my earlier version of 2012-10-24...). there were other unsyncd files to be added and |
| 18:03.28 | Notify | removed, though, and this gets them in sync. notably updates their msvc and xcode build files (which we do not use), removes example_dump and their massprop code. intentionally keeps the now-deleted opennurbs_x (surface surface intersection!), openurbs_brep_kinky (surface cleanup), opennurbs_brep_changesrf (surface conversion), and opennurbs_based (succinctly identifies RhinoSDK removals!). |
| 18:11.21 | Notify | 03BRL-CAD:brlcad * 54577 (brlcad/trunk/src/other/openNURBS/example_brep/example_brep.cpp brlcad/trunk/src/other/openNURBS/example_gl/example_gl.cpp and 5 others): update examples to their latest sources |
| 18:16.34 | ``Erik | another gimpy parse, hm |
| 18:22.20 | maths22 | I am now going to work on developing the new theme. |
| 18:22.37 | brlcad | maths22: awesome |
| 18:25.03 | maths22 | I am transfering the site to my computer, and then I will work with it. |
| 18:26.22 | maths22 | I will work with the new mockup |
| 18:27.30 | brlcad | cool, that really sounds great |
| 18:27.41 | brlcad | feel free to incorporate more awesomeness from the examples |
| 18:28.26 | brlcad | I really like the mozilla site, a simplified version would very much suite our needs |
| 18:29.18 | maths22 | should i use the graphical styling from n_reed's mockup? |
| 18:30.08 | brlcad | what do you mean? |
| 18:30.25 | *** join/#brlcad kmwho (0e8b6149@gateway/web/freenode/ip.14.139.97.73) | |
| 18:30.37 | maths22 | the content more like mozilla, the look more like n_reed's |
| 18:30.39 | brlcad | hi kmwho |
| 18:30.50 | brlcad | maths22: your call if you're designing it |
| 18:30.59 | maths22 | ok |
| 18:31.08 | brlcad | make it look awesome ;) |
| 18:31.12 | kmwho | Hello :D |
| 18:31.17 | maths22 | I like the look of n_reed's, but some will change as I good |
| 18:32.15 | ``Erik | if only 'look awesome' were quantifiable O.o (I suck at design type crap) |
| 18:33.06 | brlcad | maths22: the "In the *" sections on mozilla aren't my cup of tea, but the "Be a part of Mozilla" is just fantastic |
| 18:33.21 | brlcad | that's kind of the simple emphasis on participation that I was referring to |
| 18:33.43 | brlcad | and perhaps that's just a panel on the right side instead of having two sizes for news elements |
| 18:34.32 | brlcad | I like how http://mil-oss.org/ presents the last two news items at the bottom (last four probably better for our rate) |
| 18:34.54 | maths22 | ok |
| 18:35.46 | brlcad | and the mozilla subscription link is very handy too for building community, add folk easily to our brlcad-news list (the sf.net / mailman interface is just terrible) |
| 18:36.31 | ``Erik | if we want a 'latest 5 commits' or something, I could write to a dump file or something, or make an ajax dump url |
| 18:37.24 | kmwho | Hey, I was looking into your last year GSOC ideas and noticed that you had a few ideas related to scientific computing ( Bending Light / particle system ), are you still looking for it ? |
| 18:37.50 | ``Erik | kmwho: yes |
| 18:37.59 | maths22 | I like the ajax dump url/dump file idea. |
| 18:38.12 | brlcad | ``Erik: that'd be great, make it configurable for last N commits :) |
| 18:38.23 | brlcad | s/commits/notifications/ |
| 18:38.27 | ``Erik | all of those ideas are things we'd like, they just also happened to be in the same scope as gsoc |
| 18:39.25 | ``Erik | maths22: let me know what form of ipc would be best, I can do either pretty trivially, or we can figure out a better ipc :) |
| 18:40.34 | maths22 | once I have a spot for it, I will let you know |
| 18:41.05 | ``Erik | aight |
| 18:41.27 | kmwho | ooh cool :) , I was looking for something like that |
| 18:42.05 | maths22 | unforuntiately, I now have to clone the wiki: my login integration works too well :) |
| 18:44.01 | brlcad | using one of the existing drupal extensions (there are like a dozen feed pullers) would be good |
| 18:44.32 | brlcad | maths22: feel free to commit updates to the repo |
| 18:44.43 | brlcad | there's a web module already, but it's not been updated in ages |
| 18:45.31 | maths22 | what repo |
| 18:45.54 | brlcad | starseeker: GetNormalizedArcLengthPoints() is another really interesting function declaration that was removed from opennurbs, related to keiths work and surface splitting |
| 18:46.56 | brlcad | ``Erik: denyhosts seems to be configured WAY too slowly .. where's the config for that? |
| 18:47.30 | brlcad | I get a page full of failures before it kicks in, and sometimes it doesn't even kick in |
| 18:47.48 | ``Erik | um, probably /usr/local/etc/ ? |
| 18:47.58 | ``Erik | it's a stock config iirc |
| 18:48.21 | brlcad | okay, I see it |
| 18:48.27 | brlcad | that's one huge config file.. |
| 18:49.28 | ``Erik | cat file | sed 's/#.*//;s/[ \t]*$//' | grep -v '^$' |
| 18:50.05 | brlcad | yeah, all docs |
| 18:51.52 | starseeker | brlcad: lovely. Is there a theoretical point at which we fork opennurbs and merge in their changes to our lib as they release them? |
| 18:54.28 | kmwho | Is there somewhere i can go, to get started? |
| 19:04.35 | n_reed | build fail - opennurbs_massprop.h is missing |
| 19:17.02 | brlcad | starseeker: they didnt remove tthe full impl, just the decl .. but the decl hints at how they implement it |
| 19:17.19 | brlcad | (and probably how we should) |
| 19:17.40 | brlcad | kmwho: with what? |
| 19:17.53 | brlcad | n_reed: yeah still fixing |
| 19:18.13 | brlcad | build and distcheck |
| 19:25.34 | Notify | 03BRL-CAD:brlcad * 54578 (brlcad/trunk/src/other/openNURBS/CMakeLists.txt brlcad/trunk/src/other/openNURBS/Makefile.am): massprop went away |
| 19:29.14 | brlcad | ``Erik: talk about just in time .. .bz just experienced a critical hard drive failure with the service outage last night |
| 19:30.20 | ``Erik | heh, so the glitcheness of the hdd wasn't all in my imagination O.o |
| 19:30.21 | brlcad | he's dead, jim! |
| 19:31.15 | brlcad | I suspected hard drive wonk a year ago when we had a failure |
| 19:32.21 | Notify | 03BRL-CAD:n_reed * 54579 brlcad/trunk/src/libged/draw.c: pull view calculations into separate functions |
| 19:33.01 | ``Erik | might be a good time to set up the second disk as a backup either using software raid mirroring or an rsync cronjob, just in case |
| 19:34.49 | ``Erik | http://news.ycombinator.com/item?id=5332317 interesting ios game O.o topology puzzle |
| 19:36.10 | *** join/#brlcad cadman (4af2b5ed@gateway/web/freenode/ip.74.242.181.237) | |
| 19:36.14 | starseeker | brlcad: ok, but they never did bring back the V2 convertor you thought might be converting trimmed to untrimmed |
| 19:37.40 | starseeker | unless I missed something |
| 19:59.27 | Notify | 03BRL-CAD:brlcad * 54580 (brlcad/trunk/src/other/openNURBS/CMakeLists.txt brlcad/trunk/src/other/openNURBS/Makefile.am): document the files that we intentionally retained for reference but do not compile (along with others) |
| 20:00.16 | brlcad | starseeker: that's opennurbs_brep_changesrf.cpp |
| 20:00.42 | brlcad | the statement was that it'd be readded in the NEXT release |
| 20:00.54 | brlcad | not that much time has gone by :) |
| 20:03.21 | brlcad | starseeker: how do the *.dist files work? |
| 20:04.16 | brlcad | see many that list lots of source and header files .. are those files that aren't compiled? does that mean all header files have to be listed whether used or not? |
| 20:13.51 | starseeker | brlcad: yeah, if it's not used in one of the build targets it needs to be listed (IIRC) |
| 20:13.57 | starseeker | hang on, I'll fix it |
| 20:14.32 | n_reed | my understanding is that distcheck needs all source files to appear in either one of the standard target macros or the CMAKEFILES macro |
| 20:15.05 | n_reed | and CMakeLists.txt automatically adds the files in the .dist files with CMAKEFILES |
| 20:15.22 | n_reed | that is src/other/CMakeLists.txt |
| 20:15.25 | brlcad | why keep that as a separate file and not list it in cmakefiles though? |
| 20:15.39 | brlcad | i'm seeing files listed in both places |
| 20:15.58 | starseeker | brlcad: that may be accidental |
| 20:16.20 | starseeker | there's no harm if a file is also in the dist file |
| 20:16.31 | brlcad | is there a problem with generated files being listed in build rules and CMAKEFILES? |
| 20:17.08 | brlcad | there's harm in the sense that it dilutes my ability to discern what's in the distfile being ignored :) |
| 20:17.41 | brlcad | can't trust the distfile, have to check cmakelists and vice-versa |
| 20:18.45 | starseeker | make distcheck-repo_verify will tell you if there are any files aren't listed, and cmake will fail if there are any files being listed as ignore that don't exist |
| 20:20.04 | brlcad | maybe a more concrete example |
| 20:20.24 | brlcad | why would openNURBS.dist list all of the headers? that intentional/needed? |
| 20:21.05 | starseeker | yes - because nothing in the openNURBS build logic itself triggers CMAKEFILES on those files |
| 20:21.32 | starseeker | src/other subbuilds don't know about our distcheck rules, so what they list may or may not end up in our CMAKEFILES maintained lists |
| 20:22.08 | brlcad | because there's no install() rule for the headers or something? |
| 20:23.05 | starseeker | basically |
| 20:23.16 | brlcad | hm |
| 20:23.25 | starseeker | I can override some commands to make sure things get listed in CMAKEFILES, but not all |
| 20:23.37 | starseeker | I've almost got it fixed - one sec... |
| 20:24.07 | brlcad | couldn't the dist files just be a big CMAKEFILES() block at the end of their respective files? |
| 20:24.31 | brlcad | it'd be easier to not get out of sync since you can scan the file for repeat refs |
| 20:24.34 | starseeker | yes, but that eliminates any possibility of having "pristine" build systems in src/other |
| 20:24.57 | brlcad | ah, for which ones? |
| 20:25.09 | brlcad | I thought you added most of them |
| 20:25.54 | starseeker | zlib and libpng are pretty much pristine |
| 20:26.04 | starseeker | I had to tweak libpng but they accepted my patches |
| 20:26.08 | brlcad | a couple .dist files for those cases would make sense |
| 20:26.40 | starseeker | once we get the utahrle project up and running, that'll be another case |
| 20:26.50 | starseeker | stepcode has it's own build |
| 20:26.53 | brlcad | still, that's a case where we can fix the build, right? |
| 20:27.11 | starseeker | yeah, but we can't have a CMAKEFILES macro call - it won't make sense |
| 20:27.16 | starseeker | not in a stand-alone build |
| 20:27.26 | brlcad | both really -- it'd be a case like tcl IF they adopted a cmake build and weren't willing to change it for a clean distcheck |
| 20:27.53 | brlcad | how so? |
| 20:28.22 | brlcad | does CMAKEFILES mean something other than "ignore this file"? |
| 20:28.40 | starseeker | it doesn't mean anything at all outside of BRL-CAD - it's our own macro |
| 20:28.51 | brlcad | ooooh |
| 20:29.03 | starseeker | we go far above and beyond most CMake builds with file tracking |
| 20:29.16 | brlcad | now it's starting to make sense |
| 20:29.25 | brlcad | I knew that bit, just not the how mechanism |
| 20:29.36 | starseeker | it's some of our most sophisticated CMake logic - I could probably write it up, at some point (should, just to make sense of it) |
| 20:30.42 | Notify | 03BRL-CAD:starseeker * 54581 (brlcad/trunk/src/other/libvds.dist brlcad/trunk/src/other/openNURBS.dist brlcad/trunk/src/other/poly2tri.dist): Update dist files for src/other archives. |
| 20:30.52 | starseeker | that should do it, based on what I'm seeing here |
| 20:32.01 | starseeker | for dist anyway, seeing other failures in build |
| 20:33.03 | starseeker | opennurbs.h:79:64: error: opennurbs_massprop.h: No such file or directory |
| 20:33.26 | brlcad | yeah, there's a few source edits that richard missed |
| 20:33.44 | brlcad | i'm tracking them down |
| 20:36.03 | Notify | 03BRL-CAD:brlcad * 54582 brlcad/trunk/src/other/openNURBS/opennurbs.h: massprop was removed |
| 20:37.17 | starseeker | hmm, charming: http://news2.mcneel.com/scripts/dnewsweb.exe?cmd=article&group=openNURBS&item=2711 |
| 20:46.44 | Notify | 03BRL-CAD:brlcad * 54583 brlcad/trunk/src/other/openNURBS/opennurbs.h: opennurbs_x.h was also removed |
| 20:48.53 | brlcad | for a second, I thought that might be abhijit nandy |
| 20:49.33 | starseeker | Dale's answer is not encouraging |
| 20:49.48 | brlcad | but that also probably explains my confusion .. i saw v5 in 2012 09 14 |
| 20:49.56 | brlcad | they reposted a month later with a bunch changed |
| 20:50.07 | starseeker | nods |
| 20:50.18 | starseeker | I hope all these various versions are archived somewhere |
| 20:50.36 | brlcad | I think you patch files were on 2012 09 14 but richard tried to merge the newer |
| 20:50.44 | brlcad | still curious that he missed a bunch of edits |
| 20:51.02 | brlcad | looks like they outright removed all of the intersection function declarations |
| 20:51.11 | starseeker | winces |
| 20:51.16 | brlcad | so you don't even get to unimplemented |
| 20:51.29 | brlcad | no biggie, they went from not working to not existing |
| 20:51.48 | starseeker | yeah, but ON_Curve::GetLength is something else again |
| 20:52.03 | brlcad | do we use it? apparently not if it's been working :) |
| 20:52.48 | starseeker | <snort> I doubt we use a fraction of what we eventually *should* be using in openNURBS |
| 20:53.54 | starseeker | we're at the very beginning of our NURBS manipulation capabilities |
| 20:55.06 | starseeker | no matter - if I get *too* annoyed I can always rename libnurbs in src and try to do something different on the libnurbs sf project |
| 20:55.35 | starseeker | would vote for libbrep, BRL-CAD being a solid modeler |
| 21:01.59 | starseeker | hrm... |
| 21:02.28 | starseeker | notes with some embarassment that it looks like he should have stuck the nurbs.h contents in brep.h to begin with... |
| 21:20.44 | maths22 | ./lastlog maths22 |
| 21:25.32 | *** join/#brlcad cadman (40b2b147@gateway/web/freenode/ip.64.178.177.71) | |
| 21:35.41 | brlcad | how is it possible that we're already using nearly double the disk capacity of the old .bz |
| 21:35.55 | brlcad | ``Erik: can /usr/ports.old be deleted? |
| 21:36.01 | Notify | 03BRL-CAD:n_reed * 54584 brlcad/trunk/src/libged/draw.c: simplify ged_redraw by forgoing unnecessary non-wireframe replotting which was implemented for semantic as opposed to practical reasons |
| 21:46.28 | Notify | 03BRL-CAD:starseeker * 54585 brlcad/trunk/include/dvec.h: dvec.h doesn't need all of raytrace.h - include just what it need and make a note. |
| 21:51.10 | Notify | 03BRL-CAD:starseeker * 54586 (brlcad/trunk/include/brep.h brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp and 6 others): Consolidate nurbs.h into brep.h - better not to put another toplevel nurbs related header file in when there is already an obvious candidate. |
| 21:52.25 | brlcad | starseeker: except that some of the data in brep.h belongs to librt |
| 21:52.46 | Notify | 03BRL-CAD:starseeker * 54587 brlcad/trunk/include/CMakeLists.txt: Sync CMakeLists.txt file |
| 21:52.48 | starseeker | shouldn't that go in something like raytrace.h then? |
| 21:52.55 | Notify | 03BRL-CAD:carlmoore * 54588 brlcad/trunk/src/util/bw3-pix.c: shorten the code in filename check, and clarify the Usage message |
| 21:53.24 | brlcad | not necessarily that one, but sure |
| 21:53.57 | brlcad | probably belongs up in src/librt/primitives/brep |
| 21:54.26 | brlcad | i'm specifically looking at brep_specific .. it has no business in libnurbs |
| 21:54.37 | starseeker | ah |
| 21:54.40 | starseeker | where's it used? |
| 21:54.42 | brlcad | it's not even supposed to be a public struct |
| 21:55.04 | brlcad | someone probably followed bot.h |
| 21:55.14 | starseeker | which also gets it wrong? |
| 21:55.35 | brlcad | probably |
| 21:55.46 | brlcad | i just see it has one too and shouldn't |
| 21:56.08 | brlcad | anything named _specific was probably an implementation detail and doesn't belong in include/ |
| 21:57.14 | starseeker | ok, let me revert opennurbs back a bit and I'll move it out of brep.h |
| 21:57.25 | starseeker | (locally, not in the repo) |
| 21:58.50 | brlcad | you mean libnurbs? |
| 21:58.59 | starseeker | no, opennurbs (so I can build) |
| 21:59.11 | brlcad | oh, I'm almost done with the merges |
| 21:59.14 | brlcad | literally 2 min I think |
| 21:59.17 | starseeker | cool |
| 22:03.12 | Notify | 03BRL-CAD:brlcad * 54589 brlcad/trunk/src/other/openNURBS/Makefile.am: example_dump is no more |
| 22:04.48 | brlcad | okay, not two minutes .. but almost there .. |
| 22:06.17 | Notify | 03BRL-CAD:brlcad * 54590 (brlcad/trunk/src/other/openNURBS/CMakeLists.txt brlcad/trunk/src/other/openNURBS/Makefile.am): opennurbs_basic.cpp isn't supposed to be compiled any more, just for reference |
| 22:06.42 | brlcad | they really did rip out everything related to intersection |
| 22:07.09 | brlcad | probably what they should have done all along, but then if they had we might never have adopted them |
| 22:07.40 | starseeker | so from their point of view, *definitely* what they should have done all along ;-) |
| 22:08.48 | brlcad | might have picked them up at some point for 3dm read/write support |
| 22:09.13 | starseeker | the uv pt -> 3d pt evaluation is nothing to sneeze at though |
| 22:09.39 | starseeker | erm |
| 22:09.47 | starseeker | libged/brep.c is using brep_specific |
| 22:10.31 | starseeker | probably an indication some logic needs to move down the library hierarchy |
| 22:12.10 | starseeker | wonders if there is something similar driving the inclusion of bot_specific in the header |
| 22:12.47 | brlcad | of course, it's easier to expose implementation detail and break encapsulation than call through API cleanly |
| 22:13.02 | brlcad | make it all public access it from anywhere |
| 22:14.29 | brlcad | ``Erik: so we're running 9.1-STABLE and are current? |
| 22:19.40 | Notify | 03BRL-CAD:starseeker * 54591 (brlcad/trunk/include/brep.h brlcad/trunk/src/libged/brep.c and 2 others): Move brep_specific down into librt - not part of the public api. Will need to look into the libged brep command and see what needs encapsulating |
| 22:20.04 | starseeker | Works with opennurbs 54557 |
| 22:20.06 | ``Erik | yes and reasonably, there may be a few minor patches for -stable that aren't in 9-1-STABLE yet |
| 22:20.47 | ``Erik | http://www.freebsd.org/releng/ |
| 22:21.00 | Notify | 03BRL-CAD:n_reed * 54592 (brlcad/trunk/include/solid.h brlcad/trunk/src/libged/draw.c): if we stash the tsp mat in the solids we create, we can draw/redraw them later without doing a tree walk |
| 22:21.22 | ``Erik | ooh, ssl issues cropped up |
| 22:21.37 | brlcad | ``Erik: I'm looking into a hardware upgrade :) |
| 22:21.48 | brlcad | but this time, asking them to just move the disks |
| 22:22.09 | ``Erik | oh, that was a year ago, yeah, we're good, last sync was feb 27, 2013 |
| 22:22.12 | ``Erik | http://www.freebsd.org/releases/9.1R/errata.html |
| 22:22.25 | brlcad | any hardware-specific compilation? |
| 22:22.28 | ``Erik | another hw upgrade? o.O |
| 22:22.33 | ``Erik | nope, generic kernel |
| 22:22.47 | brlcad | it'd be moving from p4 to xeon |
| 22:23.23 | ``Erik | um, 32b i386, I'm not sure if there're any 486 or 586 specific stuff, but that disk should boot on anything later than p1-66 |
| 22:23.45 | brlcad | k |
| 22:24.30 | ``Erik | rc.conf probably needs adjusts if the nic changes chipset |
| 22:24.54 | ``Erik | current hw uses a bge (broadcom gig-e iirc) |
| 22:25.01 | brlcad | it will either double or quadruple our cpu and double the ram |
| 22:26.46 | ``Erik | hm, 2->4g ram? 'k, it's a 32b kernel right now, but if there's only 4g ram, probably no good reason to switch to a 64b kernel |
| 22:27.12 | Notify | 03BRL-CAD:brlcad * 54593 brlcad/trunk/src/other/openNURBS/CMakeLists.txt: last two, the opennurbs_x files are no longer compiled either, yet kept for reference |
| 22:27.58 | brlcad | haha ... |
| 22:27.58 | brlcad | /Users/morrison/brlcad.trunk/src/libnurbs/opennurbs_ext.cpp: In function ?ON_Curve* brlcad::pullback_curve(ON_BrepFace*, const ON_Curve*, brlcad::SurfaceTree*, double, double)?: |
| 22:28.01 | brlcad | /Users/morrison/brlcad.trunk/src/libnurbs/opennurbs_ext.cpp:2938: error: ?const class ON_Curve? has no member named ?GetLength? |
| 22:28.08 | brlcad | looks like we relied on it too |
| 22:28.51 | brlcad | ``Erik: couldn't that be on the next emerge world though? |
| 22:29.06 | brlcad | or portupgrade or whatever the frack it's called now :) |
| 22:32.23 | ``Erik | kernel and base system are seperate from the port system |
| 22:33.06 | ``Erik | (ports should almost exclusively be in /usr/local, with a few symlinks in /usr/bin for things that replace base system stuff, like updated perl) |
| 22:33.53 | ``Erik | going 64b would essentially be starting from scratch, with a full "make world", reboot, then rebuild all the ports |
| 22:34.17 | ``Erik | (and portmaster is the latest fad) :) |
| 22:37.24 | ``Erik | if the only reason to switch to 64b is because it's 64b, I'd recommend staying 32b *shrug* |
| 22:40.10 | Notify | 03BRL-CAD:starseeker * 54594 (brlcad/trunk/src/CMakeLists.txt brlcad/trunk/src/conv/step/CMakeLists.txt and 2 others): Make the library name match the header (all except the mv, which is done separately to avoid upsetting subversion) |
| 22:40.29 | brlcad | wonders if the full 4gb will be addressable |
| 22:40.54 | brlcad | having twice the ram and only using half of it would kinda suck |
| 22:42.28 | ``Erik | should be addressable, it's not like windows where 4g means 3g |
| 22:42.30 | Notify | 03BRL-CAD:starseeker * 54595 NIL: Now move the directory |
| 22:42.41 | ``Erik | and that's per process |
| 22:43.12 | brlcad | except the kernel is one of those processes ;) |
| 22:43.23 | brlcad | yeah, looks like it's okay from what I"m reading |
| 22:43.33 | brlcad | COMPAT_IA32 may help down the road if we do try to go up |
| 22:43.45 | ``Erik | hehehe, here's someone whining about having 4g on fbsd7 and only seeing 3.94g available, then having shm reserved memory explained to them |
| 22:46.05 | ``Erik | looks like a 64b kernel with compat_ia32 could be rebooted with a 32b system, but I'd want to test that on a local machine before doing it on a remote server |
| 22:47.04 | brlcad | ahh, looks like default denyhosts config is set up for linux |
| 22:47.18 | brlcad | it's "adding" deny host rules to a file that isn't read |
| 22:48.28 | ``Erik | ipfw is very bsd, could just be how rc.conf is set up? where's the written file? |
| 22:49.08 | ``Erik | /etc/hosts.deniedssh seems to be its own format |
| 22:55.33 | brlcad | only noticed because it blocked an IP for a real user that tried bad username too many times, got added, then they remembered their real username, logged in successfull :) |
| 23:00.04 | ``Erik | ipfw has over 6k rules |
| 23:02.33 | brlcad | that's tiny |
| 23:02.47 | brlcad | those are just the most recent ones that migrated from .bz |
| 23:04.35 | brlcad | whew, looks like I finally got it all |
| 23:05.13 | brlcad | or not, damnits |
| 23:05.43 | brlcad | looks like we also use ON_Surface::Pushup() and ON_Curve::GetClosestPoint() |
| 23:19.53 | brlcad | aw, I was rather fond of the libnurbs name you had there :) |
| 23:21.07 | brlcad | starseeker: note that there's more to change if you keep that name |
| 23:21.39 | brlcad | would probably need to do a tree grep, but it's mentioned by name in a few places |