| 00:25.39 | brlcad | kanzure: actually, I assumed from your question that you created step files using SCL directly |
| 00:25.46 | brlcad | not script-generated |
| 00:50.42 | kanzure | oh, i had not- i was justt reading through their code and mentally testing certain things that i got snagged on |
| 00:51.12 | kanzure | *just |
| 01:00.33 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:50.17 | kanzure | while making libbu in 7.16.8 i get "grep: /usr/brlcad/rel-7.8.0/lib/libz.la: No such file or directory" i'm not using /usr/brlcad/ in the first place |
| 02:02.52 | brlcad | I believe that issue was fixed in .10 |
| 02:06.34 | kanzure | s |
| 02:06.37 | kanzure | updates |
| 02:09.37 | brlcad | --enable-all from a fresh checkout should also fix the problem |
| 02:10.00 | brlcad | even for .8 it might fix the problem -- iirc, it's mixing different configure flags and getting stale options |
| 02:16.23 | kanzure | i was making in the individual paths is that bad? |
| 02:16.26 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177878916.dsl.bell.ca) | |
| 02:52.51 | CIA-14 | BRL-CAD: 03starseeker * r40592 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Whoops, typo. |
| 03:42.41 | CIA-14 | BRL-CAD: 03starseeker * r40593 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Switch the flags to the new name... |
| 03:58.57 | CIA-14 | BRL-CAD: 03starseeker * r40594 10/brlcad/branches/cmake/misc/CMake/test_srcs/report_username.c.in: Gentoo needs stdlib.h for getenv |
| 04:24.35 | kanzure | libtool: install: error: cannot install `libstepcore.la' to a directory not ending in /usr/local/lib |
| 04:59.53 | CIA-14 | BRL-CAD: 03starseeker * r40595 10/brlcad/branches/cmake/misc/CMake/ThirdParty.cmake: (log message trimmed) |
| 04:59.53 | CIA-14 | BRL-CAD: Hopefully this will do it - there appears to be some (fairly legitimate) |
| 04:59.53 | CIA-14 | BRL-CAD: confusion from the build system when we don an enable-all build, have libpng, |
| 04:59.53 | CIA-14 | BRL-CAD: libz, etc. in the build lib directory, and then turn on the system versions of |
| 04:59.53 | CIA-14 | BRL-CAD: the libs on top of the built enable-all build. The answer appears to be to |
| 04:59.53 | CIA-14 | BRL-CAD: remove the built libraries when the third party options are switched - entails a |
| 04:59.54 | CIA-14 | BRL-CAD: fair bit of rebuilding, but with any luck the vast slew of error messages in |
| 05:00.55 | starseeker | kanzure: sounds like a stale build |
| 06:48.19 | *** join/#brlcad merzo (~merzo@smartbussiness.mobicom.net.ua) | |
| 08:04.18 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 08:15.54 | *** join/#brlcad mafm_ (~mafm@83.49.87.61) | |
| 08:50.21 | brlcad | good question for someone to investigate on the devel list |
| 08:50.56 | brlcad | kanzure: yeah, you've got a dirty build .. try with a fresh trunk checkout |
| 10:38.23 | d-lo | Mernin all |
| 11:17.47 | *** join/#brlcad mafm (~mafm@83.49.87.61) | |
| 11:35.38 | brlcad | howdy |
| 11:35.52 | d-lo | Mernin! |
| 12:36.24 | ``Erik | yargh |
| 13:07.07 | CIA-14 | BRL-CAD: 03davidloman * r40596 10/rt^3/trunk/ (3 files in 2 dirs): Exposed ControlledThread header file. Made user hooks non-virtual, implemented default stubs. Added multilayered run stack logic for ease of extensibility. |
| 13:32.19 | CIA-14 | BRL-CAD: 03davidloman * r40597 10/rt^3/trunk/ (include/ControlledThread.h src/utility/CMakeLists.txt): Made a few fields in ControlledThread protected (from private) to expose them to subclasses. Added ControlledThread into CMake config. |
| 14:07.30 | CIA-14 | BRL-CAD: 03davidloman * r40598 10/rt^3/trunk/src/libNet/CMakeLists.txt: Add brlcad include dirs into the libNetwork config. |
| 14:08.34 | CIA-14 | BRL-CAD: 03davidloman * r40599 10/rt^3/trunk/src/CMakeLists.txt: Drop admin control panel from build for now. Its a WIP anyways and is just causing problems. Will revisit the ACP when time allows. |
| 14:15.56 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 15:18.45 | CIA-14 | BRL-CAD: 03starseeker * r40600 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: OK, this should straighten out some of the compiler flag logic. |
| 15:34.17 | CIA-14 | BRL-CAD: 03davidloman * r40601 10/rt^3/trunk/src/libNet/CMakeLists.txt: libNet now depends on libPkgCpp |
| 15:38.51 | CIA-14 | BRL-CAD: 03davidloman * r40602 10/rt^3/trunk/src/GS/CMakeLists.txt: Remove unused libs for the geoserv executable linking. |
| 16:42.05 | *** join/#brlcad mafm (~mafm@83.49.87.61) | |
| 16:57.11 | *** join/#brlcad mafm (~mafm@83.49.87.61) | |
| 17:00.29 | *** join/#brlcad mafm_ (~mafm@83.49.87.61) | |
| 17:11.15 | *** join/#brlcad mafm (~mafm@83.49.87.61) | |
| 18:11.29 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 18:21.10 | *** join/#brlcad merzo (~merzo@97-69-133-95.pool.ukrtel.net) | |
| 19:23.07 | CIA-14 | BRL-CAD: 03starseeker * r40603 10/brlcad/branches/cmake/misc/CMake/ (5 files): Move some files, more compiler flag updates. |
| 20:06.10 | *** join/#brlcad R0b0t1 (~Enigma@64.126.35.185) | |
| 20:06.10 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:25.43 | kanzure | was step-g ever tested with .step files? |
| 20:25.50 | kanzure | and if so, where are those? |
| 20:26.42 | kanzure | i've tried it with a few files generated by lolcad and a few from opencascade (for instance, heekscad) and neither work (granted, lolcad was based off of OCC's understanding of STEP, but the errors according to step-g are different between lolcad/heekscad-generated-files) |
| 20:27.02 | kanzure | i'll do a full error/bug report once i figure out what's going on.. |
| 20:28.46 | kanzure | it's entirely possible that opencascade's understanding of STEP is completely, utterly flawed but it seems to be able to read in solidworks-generated .step files (although i forget whether or not solidworks can read in occ-generated .step files) |
| 20:30.12 | starseeker | kanzure: other possibilities - the step files don't contain solid geometry, our parser is missing something... |
| 20:33.13 | kanzure | both lolcad/heekscad .step files represent the same thing (a sphere) (although the ways they do it might be slightly different) and heekscad can load/render both |
| 20:33.32 | kanzure | the brlcad step parser is just NIST SCL so that's why i'm sorta surprised this doesn't work |
| 20:33.44 | kanzure | (and why i'm suspecting OCC's implementation of being at fault rather than NIST's) |
| 20:33.54 | starseeker | kanzure: add the two files when you file the bug report so we can try 'em out |
| 20:34.00 | kanzure | nods |
| 20:34.14 | starseeker | the NIST stuff is... quirky |
| 20:34.47 | starseeker | remember, it wasn't production code until we started working with it - it was the original NIST example tarball with some fixes from various folk |
| 20:35.02 | kanzure | for the heekscad/occ .step file: "ERROR: instance #32 'PRODUCT_TYPE': Unknown ENTITY type. / Data lost: (part,$,(#7))" and then it complains "ON_Brep has no edges. / m_object_table[0].m_object->IsValid() = false. / ON_Brep has no edges." |
| 20:35.10 | kanzure | the ON_Brep is openNURBS stuff, of course |
| 20:35.43 | kanzure | since it says "Data lost: " i am suspecting that SCL is just ignoring the PRODUCT_TYPE entity so maybe the only thing really failing is openNURBS |
| 20:37.02 | starseeker | from that error, my guess is the step NURBS entity probably doesn't have edges, or has implicit edges - for openNURBS (which is more finicky) we'd probably have to generate the edge |
| 20:37.35 | kanzure | heekscad/opencascade .step: http://diyhpl.us/~bryan/irc/sphere.heekscad.step |
| 20:37.47 | kanzure | lolcad .step: http://diyhpl.us/~bryan/irc/sphere.lolcad.step |
| 20:40.22 | kanzure | step-g output for heekscad/occ .step: http://diyhpl.us/~bryan/irc/sphere.heekscad.step.step-g.log |
| 20:40.32 | kanzure | step-g output for lolcad .step: http://diyhpl.us/~bryan/irc/sphere.lolcad.step.step-g.log |
| 20:41.35 | starseeker | kanzure: yeah, the heekscad one looks like an issue going from step NURBS to openNURBS - that'll take some digging |
| 20:41.52 | starseeker | it's not "in context" for me at the moment |
| 20:41.53 | kanzure | the errors for the lolcad one are a bit more involved of course.. but heekscad/occ loads the same file just fine |
| 20:42.02 | kanzure | what? not in context? |
| 20:42.11 | kanzure | oh you probably mean you haven't been working on the NURBS stuff |
| 20:42.18 | starseeker | right |
| 20:42.29 | starseeker | I'm pretty deep into CMake at the moment |
| 20:42.36 | kanzure | yeah totally not expecting that of anyone ;) |
| 20:42.40 | kanzure | i'm just doing some digging and seeing wtf is going on |
| 20:42.42 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1177878916.dsl.bell.ca) | |
| 20:43.11 | kanzure | i guess since it's openNURBS that is crapping out, my original question ("is this valid .step according to SCL") has been answered |
| 20:43.22 | kanzure | but "sphere.lolcad.step.step-g.log" suggests the answer is no |
| 20:43.37 | kanzure | (heekscad/occ loads the lolcad-generated .step file just fine) |
| 20:43.58 | starseeker | right - the top errors look like errors reading the step syntax, and the openNURBS errors are going from step NURBS to openNURBS formats |
| 20:44.32 | starseeker | however, notice that step-g DID get as far as trying to create the geometry, which suggests that errors or not it got something |
| 20:44.45 | starseeker | heekscad/occ may just be quietly ignoring the errors |
| 20:45.13 | kanzure | i have a --debug or whatever compiled opencascade although i can't vouch for the validity of the config option |
| 20:45.52 | kanzure | i think to resolve this question i need a third implementation of STEP? |
| 20:46.07 | kanzure | or should i just assume SCL is good enough to be a reference |
| 20:48.01 | starseeker | kanzure: my approach would be to check the source of the complaining step file and compare it against the SCL error reports, see if they look legit |
| 20:48.34 | starseeker | growls at ISO - doggone it, why do they have to keep the STEP spec behind a paywall... |
| 20:49.02 | kanzure | i have various files that define the spec if you want.. christopher said he had something too |
| 20:49.23 | kanzure | as it turns out, nist.gov hosted the ISO spec for a while and then took it down but not before the internet archive crawled it :D |
| 20:49.37 | kanzure | http://web.archive.org/web/20030216045110/www.nist.gov/sc4/step/parts/ |
| 20:58.11 | IriX64 | can i ask if the CMakelists.txt effort is complete when we see a CMakelists.txt file in the root of the brlcad source tree? |
| 20:59.29 | starseeker | IriX64: the work is going on in the cmake branch for now - it's got a ways to go before it's ready for prime time |
| 20:59.48 | IriX64 | thankyou |
| 21:00.00 | kanzure | in sphere.lolcad.step i think "GLOBAL_UNIT_ASSIGNED_CONTEXT" should have another layer of parenthesis around its parameters |
| 21:00.04 | kanzure | but i'm not sure why |
| 21:00.24 | kanzure | and 1997. should be 1997 |
| 21:09.18 | kanzure | ah and next to "GLOBAL_UNIT.." the "3." should be "3" apparently |
| 21:10.58 | kanzure | this suggests that SCL is simply more strict in its parsing, then |
| 21:11.08 | kanzure | so that's encouraging |
| 21:20.55 | CIA-14 | BRL-CAD: 03starseeker * r40604 10/brlcad/branches/cmake/ (6 files in 2 dirs): More compiler flag progress, reorg, etc. Lot more wiring to do plus possibly another testing method or two. |
| 22:06.42 | *** join/#brlcad WhiteCalf (Prez@96.31.84.96) | |
| 22:17.25 | *** join/#brlcad CIA-2 (~CIA@208.69.182.149) | |
| 22:28.04 | ``Erik | alrighty, then, family guy, heavy seas gold ale, ... now which game, wow or sbcl? O.o |
| 23:12.27 | *** join/#brlcad Nohla (~Nohla@201.255.241.91) | |
| 23:51.29 | *** join/#brlcad akafubu (~akafubu@unaffiliated/akafubu) | |