| 01:09.31 | mpictor | starseeker: I've merged your changes |
| 02:02.06 | starseeker | awesome - thanks! |
| 14:41.35 | starseeker | mpictor: I added a little more information to one of the STEPcode error messages - it tends to come up a lot, and in its old form it was pretty useless for diagnostic work. The change is here: http://sourceforge.net/p/brlcad/code/59583/ |
| 14:41.59 | starseeker | could we incorporate that back into the main STEPcode? |
| 16:21.15 | mpictor | I don't see why not. If I don't do anything about ut this afternoon, remind me. |
| 16:24.57 | mpictor | starseeker: I made some changes to STEPAttribute a month or two ago. Have you pulled those changes in? |
| 16:26.27 | mpictor | oh crap, the change I'm thinking of is in a branch of mine that's in limbo until builds with many small files are working. |
| 16:27.34 | mpictor | something to do with creating objects in getters, if the requested pointer is null |
| 19:50.58 | starseeker | We tend to bump stepcode when a release comes out - if I know you're about to do a release I'll tend to try and test to make sure it works within the BRL-CAD framework |
| 19:52.01 | starseeker | once we get a proper testing framework set up with jenkins or buildbot, one of the more complex tests I'd like to set up would be to build our stuff nightly with the latest github pull of stepcode |
| 19:52.57 | starseeker | has been meaning to look into buildbot, but it's another case of too many tasks, too little time... |
| 22:43.38 | mpictor | with the slower build time, I suspect that travis-ci will time out before compiling everything :/ |
| 22:44.47 | mpictor | doesn't seem like 10 months since the last release, but I think it's been about that long |
| 22:45.52 | mpictor | plans to do a release when all of our tests pass |
| 22:46.08 | mpictor | the mp/inverse_attr branch should do that |
| 22:52.09 | mpictor | starseeker: regarding your error message, it looks like I beat you to it by about 4 months ;) |
| 22:52.13 | mpictor | https://github.com/stepcode/stepcode/commit/d0f4beb992ee0cd85c55d6aa5108bf3b7246c4c6 |
| 22:57.15 | mpictor | unless you impersonated me while logging in to github - I really don't remember making that change |
| 23:22.48 | starseeker | mpictor: cool :-) |
| 23:24.13 | starseeker | now if I could only figure out why I can't access everything in CARTESIAN_TRANSFORM_OPERATOR_3D that needs to be set... |
| 23:31.13 | starseeker | I set both name_ and description_, but for whatever reason description_ doesn't work and other things remain unset |
| 23:36.03 | mpictor | it wouldn't surprise me if the pointer was ignored, overwritten, etc |
| 23:39.02 | mpictor | there are a number of commits in mp/inverse_attr related to pointers in generated code |
| 23:40.38 | mpictor | sometimes they weren't initialized to zero; some times, ptr->ShallowCopy() was called when ptr didn't point to an obj |
| 23:40.52 | mpictor | and so on |
| 23:42.01 | starseeker | nods |
| 23:42.11 | starseeker | I think I worked around it by iterating through all the attributes |
| 23:42.18 | mpictor | research quality code :( |
| 23:42.28 | starseeker | there are *two* attributes with the same label (name) |
| 23:42.31 | starseeker | blegh |
| 23:42.49 | mpictor | maybe a redefined attribute? |
| 23:43.01 | mpictor | if so, it ought to be handled better |
| 23:43.40 | starseeker | not sure - all I know is both of them are supposed to have *something* assigned to them according to our step-g importer, and I can't seem to get at both of them in C++ land without iterating over the attribute list |
| 23:44.17 | mpictor | I know there are some entities where an attr is inherited but its type is too generic, and it is redefined to restrict what it can represent |
| 23:44.22 | mpictor | bleh |
| 23:44.36 | starseeker | more frustrating yet, I can't seem to sub a CARTESIAN_TRANSFORM_OPERATOR_3D in for an AXIS2_PLACEMENT_3D and have it work as expected |
| 23:44.55 | starseeker | not completely sure that's my fault yet, but we'll see... |