| 01:32.16 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1177593360.dsl.bell.ca) | |
| 02:04.15 | ``Erik | O.O 3 sheriff cars out front |
| 05:37.43 | *** join/#brlcad akafubu (~akafubu@unaffiliated/akafubu) | |
| 09:23.40 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 11:46.50 | *** join/#brlcad merzo (~merzo@249-82-133-95.pool.ukrtel.net) | |
| 12:11.22 | *** join/#brlcad fiz (~fiz@212.116.78.137) | |
| 12:11.34 | fiz | hi |
| 12:14.32 | fiz | could someone please help me out? I need to open (only to view) a ddd file created in ExpertCAD. Have tried different kind of "Viewers" without any luck. |
| 12:14.40 | fiz | suggestions? |
| 12:17.06 | brlcad | fiz: not really familiar with ddd files .. what's in the file? |
| 12:18.24 | brlcad | ah, I see .. it seems to be their binary format for drawings, akin to .dwg |
| 12:20.39 | brlcad | that means you probably need expertcad, don't know of anyone that can import that format |
| 12:21.21 | fiz | yeah thats exactly my problem brlcad |
| 12:21.52 | fiz | aint there any "expertcad-viewr" ? :P |
| 12:26.38 | ``Erik | sure there is, it's called "expertcad" :D |
| 12:27.24 | fiz | not exactly a viewr now is it.. ;) |
| 12:27.37 | ``Erik | I'd imagine it has some other features built in, too |
| 12:27.51 | fiz | extras ? XD |
| 12:27.54 | ``Erik | do you have access to expertcad? maybe it has an 'export to' capability? |
| 12:28.55 | fiz | I no longer have expertcad, file was created like ~1990 or something |
| 12:29.11 | fiz | +20 years ago |
| 12:29.17 | ``Erik | sounds like you're suffering the 'vendor lockin' problem :/ (I'd never even heard of 'expertcad') |
| 12:29.33 | fiz | >>> http://www.softech.com/products/expertcad/ |
| 12:30.47 | ``Erik | not doubting it's existance, just noting that it's not exactly one of the big names :) |
| 12:31.00 | fiz | exactly |
| 12:31.21 | fiz | it's not like AutoCAD/Inventor/SolidWorks/Catia etc.. |
| 12:32.05 | fiz | if it was problem would b solved :) |
| 12:32.58 | fiz | it's a binary dinosaur :P |
| 12:33.57 | *** join/#brlcad fiz (~fiz@212.116.78.137) | |
| 12:34.07 | fiz | oops |
| 12:34.32 | *** join/#brlcad fiz (~fiz@212.116.78.137) | |
| 12:34.40 | ``Erik | sorry, dude, I have no quick fix for ya, sounds like brlcad doesn't, either... mebbe you can find something with a bit of googling, but ya might just be stuck *shrug* |
| 12:34.42 | fiz | löl |
| 12:36.14 | fiz | yeah i Googled for hours yesterday & tried all(probably) the free viewers/converters out there, no luck :/ |
| 12:37.11 | ``Erik | if you get the urge to bust out the hex editor and start reverse engineering the format, we can help you with putting the data into a modern container via BRL-CAD... but I htink that's about all we can offer ya :) |
| 12:37.28 | fiz | hmm.. |
| 12:37.50 | fiz | sounds interesting :) |
| 12:38.28 | ``Erik | heh, ddd-g, if you can do the ddd part, we can help with the g part, yo |
| 12:38.50 | fiz | great thanx :)) |
| 12:39.15 | fiz | ill give it a try |
| 13:13.26 | ``Erik | yargh, happy talk like a pirate day |
| 14:37.58 | CIA-2 | BRL-CAD: 03starseeker * r40607 10/brlcad/branches/cmake/CMakeLists.txt: Identify what needs to be done for AC_HEADER_* macros. |
| 14:39.53 | starseeker | ah, hex editor + binary file - a level of geekdom I have never attained |
| 15:09.34 | kanzure | are there unit tests in the svn repository? |
| 15:11.36 | CIA-2 | BRL-CAD: 03starseeker * r40608 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/BRLCAD_CheckFunctions.cmake): Reorganize some macro logic, move the basename and dirname test logic into the CheckFunctions macro file. |
| 15:11.59 | starseeker | kanzure: um. we have regression tests, does that help? |
| 15:14.02 | kanzure | maybe, is that in src/../regressions/ ? |
| 15:14.12 | kanzure | oops, regress/ |
| 15:23.36 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 15:33.31 | kanzure | ah, README says there's no testing suite quite yet of course |
| 15:33.46 | kanzure | i've never played with "Corredor Automation Test Suite" |
| 15:36.59 | kanzure | s/README/HACKING/ |
| 17:11.01 | ``Erik | w00t, tremesetter fitted |
| 17:30.20 | kanzure | whois terry ridder or terry hancock |
| 17:47.25 | brlcad | kanzure: if you have ideas or want to work on testing, go for it |
| 17:48.07 | brlcad | there's a fair bit of regression, black box, automated, and integration tests in that directory |
| 17:50.07 | brlcad | we don't do unit testing per-se in the strict sense, but only due to the time it'd take to retrofit comprehensive testing on such a large existing code base -- so most of the testing occurs at a more productive higher level |
| 17:50.19 | kanzure | i don't have any ideas but would be happy to read over anything people have jotted down before :) |
| 17:50.29 | brlcad | nothing to say that unit tests wouldn't be great to have, especially for certain core libraries |
| 17:50.32 | kanzure | honestly doing strict unit testing with brlcad would seem like a massive undertaking |
| 17:50.56 | kanzure | and i'm not even sure how to go about it in some cases :) |
| 17:50.58 | brlcad | comprehensive unit test code tends to match the size of the code it's testing |
| 17:51.01 | kanzure | always easiest to write tests as you write the code itself |
| 17:51.08 | brlcad | that'd be a 1M line body of test code :) |
| 17:51.38 | kanzure | right now i'm puttering about doing my own test framework for my python/STEP thing |
| 17:51.46 | brlcad | true, even better to write before you write the code itself if it's going to be public API too |
| 17:52.08 | kanzure | since i didn't use EXPRESS my generator is not necessarily 100% compliant, so i need to test against brlcad (and wrap a call to the shell and see what step-g says?) |
| 17:52.25 | kanzure | i guess this is "compliance testing" (which brlcad def. doesn't have) |
| 17:52.26 | brlcad | so long as it's not a rapidly changing API, otherwise unit tests double the amount of work and can slow development in half |
| 17:52.40 | brlcad | ahh |
| 17:52.55 | kanzure | i'm also uninterested in starting a "unit tests or bust!" flamewar (my opinion varies) |
| 17:53.12 | brlcad | testing for compliance would be either a black box test or an integration test |
| 17:53.24 | kanzure | do you have any examples of that |
| 17:53.25 | brlcad | unit tests are when you test specific API calls |
| 17:53.41 | brlcad | e.g., does printf() do what it's manual page says it does |
| 17:54.49 | kanzure | i might end up writing a stepchecker on top of src/conv/step/ |
| 17:54.57 | brlcad | forget about the different testing type labels, that's just symantic -- the idea is just to write tests that evaluate a body of code for some behavior, at some level |
| 17:55.05 | kanzure | right |
| 17:55.18 | brlcad | at the highest level (integration tests), you run your program(s) and test whether they do what you tell them to do |
| 17:55.40 | kanzure | i guess this is confusing for me because (1) i don't have tests written and (2) the architecture for testing in CAD frameworks hasn't been done yet (to my knowledge) |
| 17:55.49 | brlcad | at the lowest level (unit tests), you make API calls and test whether they do what their documentation says |
| 17:56.05 | brlcad | "the architecture"? |
| 17:56.07 | kanzure | how would you architect this? would you have shell scripts for testing |
| 17:56.17 | kanzure | like for integration tests |
| 17:56.29 | kanzure | unit tests can be additional files in a library usually |
| 17:56.51 | brlcad | there's no pre-existing "architecture" for any testing system -- it's just code that is written |
| 17:57.20 | kanzure | huh? sure there are- most testing frameworks have a defined way of going about writing the code |
| 17:57.22 | brlcad | you can use a testing framework to help you, but there's nothing specific about the CAD domain or CAD code |
| 17:57.39 | kanzure | "but there's nothing specific about CAD" are you sure? |
| 17:58.06 | brlcad | you could make something "CAD-specific", but it's not clear what that even means |
| 17:58.18 | kanzure | well in general testing for file format compliance (for instance) isn't common |
| 17:58.23 | kanzure | but it's definitely useful |
| 17:58.44 | kanzure | i haven't seen code that does integration tests for that yet.. it probably exists and maybe you can point me at it |
| 17:59.21 | kanzure | openoffice might |
| 17:59.23 | brlcad | well it'll depend how rigorous you want the test to be |
| 18:00.26 | brlcad | all of the various testing frameworks (that I'm aware of) have pretty much nothing to do with domain (such as CAD) or data (such as files) |
| 18:00.35 | brlcad | you tell them to do things, and then check the results |
| 18:01.04 | kanzure | i haven't seen anyone "telling them to do things" (like file format compliance at some level of rigor) yet |
| 18:01.12 | kanzure | this is due to my inexperience not implausibility |
| 18:01.16 | brlcad | so you can use a framework or roll something custom, but in the end something is going to generate a file (or piece of it) using your system and you're going to want to validate that data |
| 18:02.12 | kanzure | let's take a specific example- let's say we were testing NIST's SCL library :P |
| 18:02.27 | brlcad | maybe misunderstanding something about frameworks, but ALL testing frameworks are you (the tester) describing (in code) things you want to be done |
| 18:02.41 | kanzure | we'd test it against a set of EXPRESS schemas and see if it fails to parse them? is that it? |
| 18:03.15 | brlcad | you could certainly do that |
| 18:03.53 | kanzure | and just use regular expressions to check for error messages on the integration tests? |
| 18:03.58 | brlcad | that'd be just one piece of testing you'd need to test the SCL |
| 18:04.20 | brlcad | sure that's one perfectly acceptable approach |
| 18:04.34 | brlcad | how you test the result becomes a matter of testing sensitivity |
| 18:04.56 | brlcad | regex are only as good as the expressions you write |
| 18:05.00 | brlcad | (of course) |
| 18:05.01 | kanzure | yeah |
| 18:05.23 | brlcad | if you write something that is very strict, then you'll get lots of good test failures if something changes |
| 18:05.36 | brlcad | but then you might also get a lot of false positives, making the test practically useless |
| 18:06.18 | brlcad | for example, you could run the tool in a known "good" state and get an output -- then make a test that runs the tool and compares current output to that known "good" output |
| 18:06.19 | kanzure | and that sensitivity isn't CAD-specific? i mean it seems to be custom |
| 18:06.28 | kanzure | based on the problem domain that we're working under and the specific test we're writing.. |
| 18:06.51 | brlcad | sensitivity isn't CAD-specific -- it's the same problem no matter what domain we're talking about |
| 18:07.29 | brlcad | it's sensitive to how you compare good or expected results with the current results |
| 18:07.46 | kanzure | what would a "result" in this context look like anyway |
| 18:08.06 | brlcad | if you test _exact_ (like "diff fileA fileB"), then the test will fail for simple things like whitespace changes |
| 18:08.07 | kanzure | steptools.com has an ap203check tool that i was using yesterday |
| 18:08.08 | kanzure | http://diyhpl.us/~bryan/irc/ap203check-job3 |
| 18:08.19 | kanzure | so there's obvious output there "validating ..." that could be checked against i guess |
| 18:08.57 | kanzure | (that output was from a CGI script on steptools.com) |
| 18:09.25 | brlcad | yeah, STEP (as a format) has a whole collection of AP's that specify how to test input formats, container formats, representation types, and more .. it's pretty hairy |
| 18:09.41 | kanzure | oh there's an AP on testing? |
| 18:09.50 | brlcad | there's a suite of APs on testing and validation |
| 18:09.59 | brlcad | it's probably WAY more than you're expecting |
| 18:10.05 | brlcad | SCL implements some of it |
| 18:10.20 | kanzure | "An ATS is a formal description on how to test STEP implementations for conformance. They contain a test plan for postprocessors (exporting STEP data) and preprocessors (importing STEP data). The structure of an ATS is defined in part 34." |
| 18:10.25 | kanzure | "The original plan of STEP was to have for every AP 2xx a corresponding ATS 3xx, but only a few were finally realized till today. |
| 18:10.28 | kanzure | plan of" |
| 18:10.30 | kanzure | ^from http://en.wikipedia.org/wiki/List_of_STEP_%28ISO_10303%29_parts#Conformance_testing_methodology_and_framework |
| 18:11.04 | kanzure | huh, so ISO 10303-34 defines the structure of an ATS, and then there's (supposedly) an ATS for some given subset of APs |
| 18:11.27 | brlcad | yep |
| 18:11.30 | brlcad | that's the suite |
| 18:11.52 | kanzure | yeah this seems more legit than parsing random cgi script output from steptools.com :D |
| 18:13.36 | brlcad | what exactly are you trying to accomplish? verify that SCL works for reading schemas? for reading STEP files for a specific AP? for writing STEP files for a given AP? for all APs? that your output matches SCL's? something else? |
| 18:14.03 | brlcad | because there's multiple issues |
| 18:14.05 | kanzure | i want a simple way to generate STEP files, so i wrote a STEP exporter in python on my own (not generated) |
| 18:14.13 | brlcad | right |
| 18:14.22 | kanzure | now i want to test it, and test it against SCL/opencascade/whatever-else |
| 18:14.30 | kanzure | testing it via an ATS sounds good too though |
| 18:14.38 | kanzure | likewise, this applies to testing SCL itself |
| 18:14.57 | kanzure | however adding in tests for SCL is at this point secondary to my objectives |
| 18:15.19 | kanzure | (i'm sure the experience will be valuable in such an endeavor though) |
| 18:15.48 | brlcad | okay |
| 18:16.45 | brlcad | the difficulty (with ATS or a manual approach) is going to still be sensitivity |
| 18:17.04 | brlcad | you can validate that your generated STEP files are _structurally_ correct |
| 18:17.07 | brlcad | that's pretty easy |
| 18:17.10 | kanzure | i don't even know what ATS looks like.. |
| 18:17.26 | kanzure | oof that's right .. there are multiple levels of validation eh? |
| 18:17.29 | brlcad | you can even generate that they contain the data you expect them to contain without false sensitivity |
| 18:17.47 | brlcad | s/generate/test/ |
| 18:18.04 | kanzure | syntax, type-based (i.e. string or int in a certain parameter of a method), semantic/rules (i.e. the rules that the ap203check-job3 output was complaining about) |
| 18:18.16 | brlcad | but then whether something else can read your (perfectly "valid") STEP file depends on other factors |
| 18:18.34 | kanzure | i think the most important point is whether or not others can read the files |
| 18:18.42 | kanzure | i'm sure there are lots of different ways to test, but that's my number one priority |
| 18:18.59 | kanzure | this is completely useless if you can't get your CAD program to read in this geometry :) |
| 18:19.00 | brlcad | take a simple sphere, for example |
| 18:19.07 | kanzure | that's what my tests have been so far |
| 18:19.13 | kanzure | http://diyhpl.us/~bryan/irc/sphere.lolcad.step |
| 18:19.18 | brlcad | I can write a sphere out into a STEP file in about a half-dozen different ways |
| 18:19.30 | kanzure | yes :( |
| 18:19.50 | brlcad | all 6 are perfectly valid step files |
| 18:20.01 | brlcad | but CATIA might only support 2 of them |
| 18:20.12 | kanzure | huh? but don't they implement AP203? |
| 18:20.15 | brlcad | Unigraphics might only support another 2 |
| 18:20.19 | kanzure | i guess i shouldn't assume that.. they probably have partial implementations |
| 18:20.44 | brlcad | implementing AP203 doesn't mean you can represent or support every entity type |
| 18:20.53 | brlcad | 203 is huge |
| 18:21.01 | kanzure | the .exp file for 203 is only 600kb |
| 18:21.08 | brlcad | heh |
| 18:21.12 | kanzure | :P |
| 18:21.24 | kanzure | ok i see how ridiculous that sounds |
| 18:21.31 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879409.dsl.bell.ca) | |
| 18:22.56 | kanzure | i can see why others avoid testing their STEP implementations |
| 18:29.41 | kanzure | part 34 is AST and part 35 looks like a test suite for SDAI implementations |
| 19:38.59 | kanzure | ATS303 for AP203: http://filebin.ca/gdshta/ISO10303-part303.pdf |
| 19:40.07 | kanzure | a lot of this testing looks redundant |
| 19:40.27 | kanzure | i thought the point was that this is OOP-based |
| 21:49.33 | ``Erik | your mom is oop based |
| 22:11.45 | *** join/#brlcad Elrohir (~kvirc@p4FC5BF9F.dip.t-dialin.net) | |
| 22:27.02 | kanzure | ``Erik: it's true :( |
| 22:31.09 | ``Erik | at least she's real oop, a la smalltalk/objc... not slutty old c++ style |
| 22:52.15 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |