| 02:38.38 | *** join/#stepcode hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) |
| 02:46.36 | *** join/#stepcode hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) |
| 06:30.33 | *** join/#stepcode hoiji (671b082a@gateway/web/freenode/ip.103.27.8.42) |
| 14:08.42 | *** join/#stepcode hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) |
| 17:49.29 | hoiji | hi all, I have been trying to run my version of stepcode through step-g for the full day, and still I am not reaching anywhere |
| 17:50.53 | hoiji | It seems that the stepcode version in brlcad has many non-trivial changes as compared to the stepcode version upon which I have built a thread safe module |
| 17:52.16 | hoiji | I am curious about one thing, is the stepcode version in brlcad, being independently worked upon? |
| 17:55.25 | hoiji | Like in one brlcad stepcode version the sortedMaster pointer variable of class InstMgr is declared as std::map<int, MgrNode *> *sortedMaster |
| 17:56.22 | hoiji | While in the stepcode version I have been working upon the same is declared as MgrNodeArraySorted * sortedMaster (where MgrNodeArraySorted is class declared in the stepcore library) |
| 18:08.26 | starseeker | hoiji: that change in particular was made to improve performance |
| 18:08.47 | starseeker | I was planning to merge it back into the upstream version but I guess hadn't done so yet |
| 18:09.08 | hoiji | oh |
| 18:09.09 | starseeker | does that change have impliciations from the tread-safe perspective? |
| 18:10.32 | hoiji | Nope, but changes like those are making running step-g (with my stepcode version) tough |
| 18:10.56 | starseeker | hoiji: I thought that change was "under-the-hood" from the point of view of step-g |
| 18:12.05 | starseeker | hoiji: what's the git line to check out the stepcode version you are testing? |
| 18:12.10 | starseeker | will give it a quick try |
| 18:13.18 | hoiji | git checkout origin hj/thread-safety |
| 18:15.10 | hoiji | Oh it seems that u r right about under-the-hood thing (in this particular case), the problem seems to lying elsewhere. |
| 18:17.44 | hoiji | Currently I am stuck with getting an malloc assertion error at this line https://github.com/stepcode/stepcode/blob/hj/thread-safety/src/clutils/dirobj.cc#L72 |
| 18:18.47 | starseeker | fileList is part of the DirObj class? |
| 18:20.28 | starseeker | hoiji: how far are you from the stepcode trunk? |
| 18:20.45 | starseeker | do you have the recent changes made for OpenVSP merged into your branch? |
| 18:22.05 | hoiji | Well I am 102 commits ahead and 14 commits behind |
| 18:22.42 | starseeker | hoiji: could you merge those 14 commits into the thread-safety branch? I'm seeing at least one issue here that might be helped by a couple of those commits |
| 18:23.16 | starseeker | ah, nevermind, I think I was able to do it locally |
| 18:25.27 | hoiji | thnx, In-fact according to my plan after I could get step-g to run, I would merge those 14 commits into my thread-safety branch. Seems I should have merged it before tryiing step-g |
| 18:28.07 | starseeker | hoiji: in src/cllazyfile/CMakeLists.txt line 48, add -DNO_REGISTRY to the target properties string |
| 18:29.03 | starseeker | usually, barring major reworking, it's a good idea to keep branches up to date with trunk |
| 18:30.53 | starseeker | hoiji: then it looks like we need to make lazy_thread_safety_test.cc do the same thing as lazy_test.cc for NO_REGISTRY |
| 18:31.17 | hoiji | starseeker: lazy_thread_safey_test is schema dependent |
| 18:31.32 | hoiji | u can comment out lines 47-49 |
| 18:31.41 | starseeker | ok |
| 18:32.31 | starseeker | at some point that test will need to depend on that schema though, or turn off if the building of that schema isn't enabled |
| 18:32.42 | starseeker | BRL-CAD turns off the schema building |
| 18:34.48 | hoiji | ok, to be more precise, that test consists of many checks, out of which one check is schema dependent. I will enable-disable that with NO_REGISTRY macro |
| 18:35.10 | starseeker | hoiji: thanks :-) |
| 18:35.34 | starseeker | the next issue looks to be the step-g build needing the c++0x support enabled |
| 18:35.39 | hoiji | Well I shud be the one saying thanks |
| 18:35.41 | starseeker | hacks that in... |
| 18:36.11 | hoiji | I believe that clastepcore/STEPattribute.cc will also give you trouble |
| 18:36.57 | hoiji | (If u have just copied my libraries into src/other/stepcode/src) |
| 18:37.27 | starseeker | no, into src/other/stepcode |
| 18:38.31 | hoiji | Well that, I also tried that I lead me into more troubles |
| 18:38.36 | hoiji | :( |
| 18:38.57 | hoiji | ^I lead == It lead |
| 18:39.33 | starseeker | hoiji: if we can't use std::mutex (or more specifically if the decision is that it's too early to rely on c++0x support) are there any other options short of relying on Boost? |
| 18:40.29 | hoiji | I think yes, If it provides a facility similar to std::mutex |
| 18:40.59 | hoiji | U just have to change the wrapper of std::mutex I defined in clutils/sc_mutex.h |
| 18:43.27 | hoiji | However cllazyfile doesn't use that wrapper (I hadn't though of using wrapper till then). In the coming days I will modify the cllazyfile to omit std::mutex and take dependency on sc_mutex |
| 18:44.00 | hoiji | cldai, clstepcore, cleditor and clutils take dependency on sc_mutex |
| 18:44.03 | hoiji | only |
| 18:44.29 | starseeker | hoiji: OK, to get step-g to try building, I temporarily edited the flags in build/src/conv/step/step-g/CMakeFiles/step-g.dir/flags.make and changed the std from gnu++98 to c++0X |
| 18:45.16 | starseeker | I get to here: |
| 18:45.22 | starseeker | src/clstepcore/STEPattribute.h:106: error: âSTEPattribute::attrUnion STEPattribute::ptrâ is protected |
| 18:45.27 | hoiji | Did u run it yet? |
| 18:45.40 | starseeker | got the above build failure |
| 18:45.52 | hoiji | ok so u have declare that thing as public |
| 18:46.12 | hoiji | It is one of the changes which made my life tough |
| 18:46.41 | hoiji | Then most prob. u will encounter the asStr error |
| 18:46.47 | starseeker | hoiji: does that being public cause a problem? |
| 18:47.56 | hoiji | No, it was already public in brlcad stepcode, but protected in stepcode (upon which I worked upon) |
| 18:47.59 | starseeker | hmm. OK, so the question is whether std::string support was removed from asStr and we need to update BRL-CAD, or whether we added std::string support and that needs to be merged |
| 18:49.07 | hoiji | For that issue I corrected the callers inside STEPWrapper.cc |
| 18:49.31 | hoiji | i.e instead of using asStr used c_str() |
| 18:49.51 | starseeker | nods |
| 18:49.58 | starseeker | that should work short term |
| 18:50.38 | hoiji | yes, after doing that, the build will most probably compile. |
| 18:50.57 | starseeker | hoiji: resolving these sorts of things are a normal part of syncing between BRL-CAD and stepcode |
| 18:51.26 | starseeker | we've been doing some very heavy duty work on step-g, so we couldn't afford to have the ground shift under us from the stepcode side |
| 18:52.03 | hoiji | i do understand |
| 18:52.15 | starseeker | If I have time this evening, I'll try to go through our changes and merge as many as I can into stepcode |
| 18:52.23 | starseeker | that should help some |
| 18:53.44 | hoiji | Yes that would definately help |
| 18:54.07 | starseeker | hoiji: if you really want some fun, look at the work that went in to the original merge between the first stepcode and BRL-CAD |
| 18:54.12 | hoiji | Is the build compiled yet? |
| 18:54.22 | starseeker | hoiji: not quite - one second |
| 18:54.29 | starseeker | had to back up and rework something |
| 18:54.34 | hoiji | oh |
| 18:55.06 | hoiji | Actually when it does and I ran it, i got a seg fault here https://github.com/stepcode/stepcode/blob/hj/thread-safety/src/clstepcore/Registry.inline.cc#L70 |
| 18:55.52 | hoiji | starseeker: where can I look into the work that went in the original merge? |
| 18:55.52 | starseeker | hrm |
| 18:56.24 | starseeker | http://stepcode.org/mw/index.php/BRL-CAD_patches |
| 19:04.08 | starseeker | huh - the asStr thing is a little puzzling - I don't see a change removing support for std::string offhand |
| 19:04.58 | hoiji | I am sorry I didn't get you |
| 19:05.51 | starseeker | oh, nevermind |
| 19:05.58 | starseeker | https://github.com/stepcode/stepcode/commit/55f79cb9e6e9b69b48dfd95942363db2461e663a |
| 19:11.07 | starseeker | hoiji: yeah, we may have to do some digging into whether the asStr changes indicate there are broader implications to deal with |
| 19:12.50 | hoiji | yes, In fact I fear that asStr might not be the only change |
| 19:13.55 | hoiji | The Registry constructor which gave me a seg fault was called in STEPWrapper::load |
| 19:14.19 | starseeker | hoiji: does the stepcode history indicate there were changes made there recently? |
| 19:14.26 | starseeker | (in the constructor) |
| 19:14.44 | hoiji | I will go search that |
| 19:15.06 | hoiji | However I believe its something to do with Schema dependency |
| 19:15.47 | hoiji | Inside STEPWrapper::load there a parameter 'SchemaInit' was passed to the constructor of Registry |
| 19:16.12 | starseeker | urk |
| 19:16.36 | starseeker | I get a linking failure - with undefined references to config_control_design::e_document_usage_constraint and a whole bunch more |
| 19:17.51 | hoiji | ouch, now I remember that I ran into some problems in CONFIG_CONTROL_DESIGN also |
| 19:17.53 | starseeker | I suspect my macro logic for the generated schema sources needs a major update |
| 19:18.13 | hoiji | that might be true |
| 19:18.42 | hoiji | Since inside the Registry constructor the line which is symbolically equal to SchemaInit( *this ) gives the seg fault |
| 19:19.14 | starseeker | hoiji: I'm out of time for this today - it sounds like maybe the better bet for testing is to hack the BRL-CAD step-g build to use a system install after all |
| 19:19.49 | starseeker | to do that, you can just hardcode whatever libraries and headers you need in src/conv/step/step-g/CMakeLists.txt |
| 19:20.34 | hoiji | ok I will try it, thanks for helping me out |
| 19:20.43 | starseeker | (FindSTEPCODE.cmake needs to be written, but doing that write will take more time.) |
| 19:20.54 | starseeker | hoiji: sorry I wasn't of more use |
| 19:21.52 | hoiji | On the contrary u really helped me out in more ways then one |
| 19:22.16 | starseeker | hoiji: a while back mpictor and I had discussed tinythread - that seems to have a mutex, would that work in place of std::mutex? |
| 19:22.25 | starseeker | http://tinythreadpp.bitsnbites.eu/ |
| 19:22.46 | starseeker | is fairly sure C++11 as a requirement will be a problem in some situations |
| 19:23.02 | hoiji | Actually there is one more limitation: Along with std::mutex, I am also using std::recursive_mutex |
| 19:23.13 | mpictor | reads chat history |
| 19:23.20 | starseeker | http://tinythreadpp.bitsnbites.eu/doc/classtthread_1_1mutex.html |
| 19:23.21 | mpictor | hi guys! :) |
| 19:23.27 | starseeker | http://tinythreadpp.bitsnbites.eu/doc/classtthread_1_1recursive__mutex.html |
| 19:23.39 | starseeker | mpictor: howdy :-) |
| 19:23.40 | hoiji | thats cool |
| 19:23.50 | hoiji | hi mpictor |
| 19:24.05 | mpictor | looks like we' |
| 19:24.17 | mpictor | * looks like we're getting closer! :D |
| 19:24.38 | mpictor | wonders why they put the enter key right next to ' |
| 19:24.43 | starseeker | nods - I've got some work ahead of me with the new generated file layout from exp2cxx |
| 19:24.58 | mpictor | yeah |
| 19:25.04 | hoiji | we will just have to change the clutils/sc_mutex.h file |
| 19:25.07 | hoiji | hah |
| 19:25.16 | starseeker | is the old single-file output an option until then? |
| 19:25.44 | mpictor | hmmm |
| 19:26.02 | starseeker | it's cool if it isn't, just looking for a fast way to let hoiji test |
| 19:26.03 | mpictor | I don't think it's possible to switch back :/ |
| 19:26.10 | starseeker | that's fine :-) |
| 19:27.25 | starseeker | mpictor: I want to do things the "right way" - will just be a bit more work to sort out the right macro voodo |
| 19:27.34 | mpictor | sure |
| 19:28.01 | starseeker | mpictor: hows the new job going? |
| 19:28.36 | mpictor | I love it, but it's keeping me quite busy! |
| 19:28.41 | starseeker | heh |
| 19:28.45 | starseeker | I'll bet |
| 19:28.56 | starseeker | big code bases do that |
| 19:29.36 | mpictor | for a long time, it felt like I was working 3-4 hours a day when in reality I was working 9-10 |
| 19:29.51 | mpictor | waaaaaaaaaaay better than my old job / old boss |
| 19:29.59 | starseeker | sweet! |
| 19:31.35 | starseeker | are you the main/only guy on the code, or do you have a team? |
| 19:32.34 | mpictor | a couple other people are putting some time into linux stuff |
| 19:32.58 | starseeker | nods |
| 19:32.59 | mpictor | I'm about 85% linux, 15% misc other stuff |
| 19:33.10 | starseeker | you lucky devil |
| 19:33.24 | *** join/#stepcode hoiji_ (73f046de@gateway/web/freenode/ip.115.240.70.222) |
| 19:33.48 | mpictor | like working on some crypto stuff to ensure that nobody can modify the boxes that the customer will use |
| 19:34.11 | mpictor | both to keep big brother(s) out, and so the customer won't try to clone the device |
| 19:34.14 | starseeker | yeah, that sounds like a *very* good job for a nerd to land :-) |
| 19:35.14 | mpictor | also sort of a headache, since the hardware fingerprint can differ depending on the OS that's booted |
| 19:35.23 | starseeker | mpictor: with all that going on, what do the prospects look like for a stepcode release in the next few months? |
| 19:35.33 | mpictor | serial numbers won't change, but reported features sometimes do |
| 19:35.42 | mpictor | I hope so |
| 19:36.31 | mpictor | I wish I could give a more concrete answer than that :/ |
| 19:36.39 | starseeker | with hoiji's work and OpenVSP becoming user #2, this looks like it might be a good point to start looking for people who could integrate stepcode into distros |
| 19:36.51 | mpictor | oh, yea |
| 19:38.12 | starseeker | wonder if I'll hear more from the FreeCAD/opencascade folks |
| 19:38.18 | starseeker | s/I'll/we'll |
| 19:38.31 | mpictor | on the inverse attr stuff I've been working on for ages, I think I'll have to store the ia data in a map so they can be accessed early or late bound (i.e. with or without the member functions) |
| 19:38.34 | starseeker | I remember them showing up early on, but they seemed to drop off |
| 19:38.45 | mpictor | yea |
| 19:38.58 | starseeker | mpictor: yeah, that sounds like a map situation |
| 19:39.51 | mpictor | didn't think I'd have to, but it seems to be the only way to access them with complex instances, even when early bound |
| 19:40.16 | starseeker | nods - complex instances may be a nifity general construct, but... ugh. |
| 19:40.57 | mpictor | wishes the compiler could see into the future, and read my mind... oh, and read the spec while it's at it |
| 19:41.24 | starseeker | proposes all specs henceforth be written as BNF grammars |
| 19:42.20 | mpictor | until recently, I thought complex instances were composed of objects belonging to the various SDAI classes |
| 19:42.48 | starseeker | blinks - I was under that impression myself |
| 19:42.59 | mpictor | however, they aren't - the main instance heads a linked list of more complex instances |
| 19:43.30 | starseeker | ah! |
| 19:43.46 | starseeker | no wonder access is so weird |
| 19:43.50 | mpictor | each of those represents one of the instances, but since it's a complex instance itself it cannot inherit the generated class and its member functions |
| 19:44.28 | mpictor | thinks we need to ram either/or inheritance into the c++ standard ;) |
| 19:45.35 | starseeker | <snort> well, everything else is in there - why not? |
| 19:46.15 | starseeker | reluctantly concludes he has to dig into the problem he was supposed to be working on before... |
| 19:46.53 | mpictor | hehe |
| 19:46.54 | starseeker | mpictor: I'll probably be merging in some fixes to stepcode later this evening |
| 19:47.04 | mpictor | cool |
| 19:47.30 | starseeker | that std::map replacement is critical - without it, some large step files with... suboptimal numbered entity ordering take hours just to do a first stage read |
| 19:47.49 | starseeker | classic case of code being developed with only toy examples for testing |
| 19:48.07 | starseeker | alrightie - bbl |
| 19:48.13 | starseeker | hoiji_: nice work! |
| 19:49.58 | hoiji_ | for what? |
| 19:50.00 | hoiji_ | :P |