| 12:44.47 | *** join/#stepcode hoiji (~hoiji@115.242.81.20) |
| 13:01.36 | *** join/#stepcode hoiji (~hoiji@115.242.81.20) |
| 13:17.15 | *** join/#stepcode hoiji (~hoiji@115.242.81.20) |
| 14:40.25 | *** join/#stepcode github-notify (~github-no@192.30.252.46) |
| 14:40.25 | github-notify | [stepcode] TRThurman opened issue #290: exppp is modifying the case of ENTITY names and SCHEMA name. https://github.com/stepcode/stepcode/issues/290 |
| 14:40.25 | *** part/#stepcode github-notify (~github-no@192.30.252.46) |
| 14:42.52 | *** join/#stepcode github-notify (~github-no@192.30.252.47) |
| 14:42.52 | github-notify | [stepcode] TRThurman opened issue #291: exppp is converting REAL literals to INTEGER literals https://github.com/stepcode/stepcode/issues/291 |
| 14:42.52 | *** part/#stepcode github-notify (~github-no@192.30.252.47) |
| 15:32.07 | mpictor | hi hoiji |
| 15:32.16 | mpictor | you had an idea on getting rid of the bottleneck? |
| 15:35.07 | hoiji | I was thinking of a heuristic based approach to fasten things up in lazy loading. Basically I want to do something like (suppose say) the 'i'th instance has been accessed for the first time (and hence created) then and if their is a high probabilty that 'j'th instance will also be accessed, then would it better to create the 'j' instance in the background(by some another thread) before it is accessed. Could it lead to some improvements? |
| 15:36.21 | mpictor | interesting, but I'm not sure how you'd predict what would be accessed vs what wouldn't |
| 15:37.02 | hoiji | Thats a very good point |
| 15:37.38 | hoiji | For that I would need to see some of the workloads |
| 15:37.55 | hoiji | Could you point me to them |
| 15:38.30 | mpictor | I wish I could |
| 15:38.39 | hoiji | In the above explanation just replace 'j' by 'i+1' |
| 15:39.14 | mpictor | the only open one I know of is brl-cad's import/export, step-g and g-step |
| 15:39.22 | mpictor | I think they are still experimental |
| 15:40.08 | mpictor | what instances are accessed will depend heavily on the application and on the file contents |
| 15:42.00 | hoiji | yes that is true.. but what I proposed was that some general access patterns may be recognized and in the worst case we are just creating one not needed object in the background. |
| 15:43.44 | mpictor | loading them will consume some memory though, and with large files this could mean a lot of bad guesses and wasted memory |
| 15:44.13 | mpictor | I'm not opposed to it, but I think it could be pretty complicated to do it right |
| 15:44.57 | mpictor | I'd prefer to have thread safety first, then look at taking advantage of threads |
| 15:45.13 | hoiji | yes u have a point :) |
| 15:46.37 | hoiji | So do we specific targets which would be needed to be thread safe? |
| 15:47.11 | hoiji | ^So do we have specific .... ? |
| 15:47.49 | mpictor | I have not looked into it at all myself |
| 15:52.15 | hoiji | what I meant was that should my thread safety goal be limited to lazy loading? or should I Include more stepcode features in it? |
| 15:52.58 | mpictor | oh, I see |
| 15:54.26 | mpictor | I think that most of src/cl* will need some sort of changes so cllazyfile is safe |
| 15:54.43 | mpictor | hopefully small changes |
| 16:07.16 | hoiji | mpictor, according to you how much % of my gsoc proposal timeline should I devote to thread safty? |
| 16:11.56 | mpictor | to be honest, I do not know |
| 16:12.07 | hoiji | oh |
| 16:12.53 | mpictor | it might be a lot, or might just be a few mutexes in a couple places |
| 16:12.54 | mpictor | sorry |
| 16:14.25 | mpictor | I suspect that it will take 70-80% of your time, but that is just a guess |
| 16:16.12 | mpictor | that's including fixing multiple file support with a single thread, implementing threading, and writing tests to try to break it with multiple threads |
| 16:19.47 | hoiji | Thanks... could you advise gimme some advise me on.. should I go through the remaining src/cl* files (before submitting the proposal) to determine how should I incorporate thread safety into stepcode, or should I just focus on lazy loading first? |
| 16:22.39 | mpictor | it would not hurt to look through them |
| 16:23.52 | mpictor | it would be nice to also make cleditor thread safe, but it will probably be harder |
| 16:31.38 | hoiji | One last doubt , can their be a situation where an application calls openFile() on the same file from multiple threads? |
| 16:32.08 | mpictor | I would consider that a bug in the application |
| 16:32.47 | mpictor | it would be good to check for it and print an error message |
| 16:32.49 | hoiji | ok thanks.... sorry for hogging lot of your time. |
| 16:32.57 | mpictor | heh no problem |
| 16:33.20 | mpictor | I'm glad you want to know a lot about it |
| 17:03.24 | mpictor | hoiji: by the way, there will be a few changes to cllazyfile soon, but I don't think they'll have much effect on threading |
| 17:04.04 | mpictor | I have a branch that has sat for a while, and now I'm trying to find one last bug before merging it |
| 17:05.59 | mpictor | just curious... have you used CMake and git much in the past? |
| 17:07.16 | hoiji | actually I have used makefiles a lot but this is the first time I am using CMake. |
| 17:07.31 | mpictor | I see |
| 17:07.57 | mpictor | better than autotools IMO, but still has shortcomings |
| 17:08.45 | hoiji | Also since I was living under the rock :), I have used svn and source depo a lot but am new to git |
| 17:09.04 | mpictor | heh |
| 17:09.42 | mpictor | I guess svn is a lot harder to break than it once was, but I remember messing it up pretty often |
| 17:10.44 | hoiji | :) |
| 19:27.51 | mpictor | starseeker: I remember you talking about a problem with parallel builds once |
| 19:28.37 | mpictor | do you remember if that was with 'make test'? |
| 20:09.49 | starseeker | mpictor: um. For me the major problem was with BRL-CAD's build trying to compile generated STEPcode files before they were done generating |
| 20:10.57 | starseeker | I finally ended up making the compile of the generated files dependent on the MD5 sum of the generated sources being stable for a full second before trying to build it (and also making sure the file wasn't empty) |
| 20:11.07 | starseeker | that seems to have delt with it |
| 20:11.14 | starseeker | at least in our build |
| 20:11.34 | mpictor | wow |
| 20:11.51 | starseeker | CMake insanity at its finest |
| 20:11.59 | mpictor | yea |
| 20:13.37 | starseeker | http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/misc/CMake/md5_compiletest.cmake.in |
| 20:14.49 | starseeker | used around line 69 here: http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/conv/step/CMakeLists.txt |
| 20:15.38 | starseeker | that may be overkill, but I'm reluctant to abandon it since it's hard to tell if it's really necessary or not - reproducing the problem is hard |
| 20:31.40 | mpictor | starseeker: have you had a chance to try that branch on osx? |
| 20:32.12 | starseeker | let me try that now |
| 20:32.21 | starseeker | switches machines... |
| 20:32.28 | starseeker | what's the checkout for the branch to test? |
| 20:32.30 | mpictor | I appreciate it |
| 20:32.35 | mpictor | one sec |
| 20:32.50 | mpictor | branch is mp/config-parse-rebase |
| 20:44.50 | *** join/#stepcode github-notify (~github-no@192.30.252.33) |
| 20:44.50 | github-notify | [stepcode] mpictor pushed 1 new commit to mp/config-parse-rebase: https://github.com/stepcode/stepcode/commit/2338dd11e1495eba4983797f03399908b9e04564 |
| 20:44.50 | github-notify | stepcode/mp/config-parse-rebase 2338dd1 Mark: increase schema scanner config/build timeouts... |
| 20:44.50 | *** part/#stepcode github-notify (~github-no@192.30.252.33) |
| 20:45.35 | starseeker | mpictor: I made the mistake of telling it to do an update - still a few minutes to go |
| 20:45.50 | mpictor | davyw had trouble with timeouts on windows - apparently it takes a while to find the compiler |
| 20:45.52 | mpictor | heh |
| 20:46.16 | mpictor | anyway, that's what that last change was about. shouldn't affect you |
| 20:46.57 | starseeker | looks like someone is having problems with reals and integers? |
| 20:47.06 | mpictor | yeah, the pretty printer is getting messed up sometimes |
| 20:47.12 | starseeker | OSX update, actually - haven't even got to stepcode yet :-P |
| 20:48.50 | mpictor | really wants to get these 2 big branches merged before making any other changes that will force another rebase |
| 20:49.15 | mpictor | still fighting a few bugs in the inverse attr stuff, though |
| 20:50.03 | mpictor | I rebased it on top of the config branch, and now I get different errors than before :/ |
| 20:51.05 | starseeker | winces |
| 20:51.14 | starseeker | arrrgh, no git installed |
| 20:51.18 | starseeker | grumble... |
| 20:51.35 | starseeker | mpictor: wonder what changed that could cause different erros?? |
| 20:51.35 | mpictor | you can probably get a tarball |
| 20:52.19 | mpictor | between the 2 branches, I think there are ~130 commits. I probably screwed something up somewhere |
| 20:52.23 | mpictor | when rebasing |
| 20:52.35 | starseeker | it claims it's downloading and installing git - I'll grab the tarball if that fails |
| 20:52.47 | starseeker | (sorry, this isn't a machine I normally develop on) |
| 20:52.47 | mpictor | tarball https://github.com/stepcode/stepcode/archive/mp/config-parse-rebase.zip |
| 20:52.51 | mpictor | no prob |
| 20:53.08 | mpictor | actually, that's a zip... think you can get a tarball if you change it to .tar.gz |
| 20:53.22 | mpictor | if you care |
| 20:57.35 | starseeker | either way :-) |
| 20:57.49 | mpictor | wishes I could select 2 blocks of text and get a diff of them |
| 20:58.04 | starseeker | ah, as opposed to the whole file? |
| 20:58.39 | mpictor | comparing blocks of code that look a lot alike but mustn't be quite the same |
| 20:58.54 | starseeker | could you extract the two blocks to their own files? |
| 20:59.22 | mpictor | I could, and I have in the past |
| 20:59.36 | mpictor | is lazy. didn't you know that already? ;) |
| 20:59.38 | starseeker | tends to use kompare, but I don't recall it allowing the specification of sub-blocks |
| 20:59.49 | starseeker | heh - all good programmers are, to some degree |
| 21:00.00 | starseeker | would be an excellent feature |
| 21:00.49 | mpictor | if implemented as "compare selection with code in clipboard", it probably wouldn't be too hard to do |
| 21:01.14 | mpictor | that would still be easier than copy/paste/save/copy/paste/save/diff |
| 21:13.06 | starseeker | hmm - it's reporting an error from SC_Run_exp2cxx.cmake line 14 |
| 21:13.23 | starseeker | I've got to run an errand - I'll try to dig into it when I get back tonight |
| 21:15.11 | mpictor | ok, thanks |
| 23:42.50 | starseeker | exp2cxx is quiting with "Abort trap 6" |
| 23:46.52 | starseeker | mpictor: emailed you backtrace |
| 23:59.35 | mpictor | yay |