| 01:30.47 | *** join/#stepcode hoiji (671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
| 04:09.44 | hoiji | should I send a pull request https://github.com/hoiji09/stepcode/compare/stepcode:master...master |
| 04:13.37 | *** join/#stepcode travis-ci (~travis-ci@ec2-54-224-94-88.compute-1.amazonaws.com) |
| 04:13.37 | travis-ci | [travis-ci] hoiji09/stepcode#3 (master - 3403ea3 : hoiji09): The build is still failing. |
| 04:13.37 | travis-ci | [travis-ci] Change view : https://github.com/hoiji09/stepcode/compare/35b76941bd64...3403ea3c5fbc |
| 04:13.37 | travis-ci | [travis-ci] Build details : http://travis-ci.org/hoiji09/stepcode/builds/21858096 |
| 04:13.37 | *** part/#stepcode travis-ci (~travis-ci@ec2-54-224-94-88.compute-1.amazonaws.com) |
| 04:17.03 | hoiji | mpictor: out of curiosity.. where is test test_inverse_attr3 located? |
| 10:44.56 | *** join/#stepcode hoiji (671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
| 11:39.19 | mpictor | hoiji: https://github.com/stepcode/stepcode/blob/master/test/cpp/schema_specific/inverse_attr3.cc |
| 11:40.24 | mpictor | actually fixing the problem is non-trivial, and I've been working on it off and on since last october IIRC |
| 11:40.27 | mpictor | https://github.com/stepcode/stepcode/tree/mp/inverse-attr-rebase |
| 11:40.52 | mpictor | with that branch, I think I'm getting pretty close to fixing it |
| 11:41.32 | mpictor | I'll still need to clean the code up, though |
| 11:46.45 | hoiji | oh! thats a pretty long time :O |
| 12:10.27 | mpictor | I had to make some big changes to the build system so that the generated code was in relatively small files |
| 12:11.10 | mpictor | before, the files were so big that I was having a very hard time seeing what the problem was |
| 12:11.42 | mpictor | fixing the build system took quite a while, and now I'm back to working on that problem |
| 12:12.19 | mpictor | actually "I had to make some big changes" is incorrect - starseeker and Davy Wouters helped a lot |
| 12:15.33 | mpictor | hoiji: maybe create 1-2 clones, and use mutexes or something similar to ensure that those aren't accessed concurrently |
| 12:16.51 | mpictor | we could have a cleanup() function that would free them if the user needs more memory, and otherwise they get freed when the lazyInstMgr destructor is called |
| 12:33.23 | hoiji | thanks, the cleanup() seems to be an interesting idea. Also we could use the fact, that all the clones will be automatically destroyed once the parent is closed, in the destructor. |
| 12:34.34 | mpictor | I'm thinking that having just a few clones will make a big difference; any thread that is waiting won't be waiting nearly as long |
| 12:39.44 | mpictor | hoiji: your code looks good, go ahead and create a pull request |
| 12:41.28 | mpictor | also, I just gave you commit rights to stepcode |
| 12:41.42 | mpictor | so you can work on your own branches in the main repo now |
| 12:42.03 | *** join/#stepcode github-notify (~github-no@192.30.252.38) |
| 12:42.03 | github-notify | [stepcode] hoiji09 opened pull request #294: Added a function to lazyInstMgr for recursively getting Instance Dependencies. (master...master) https://github.com/stepcode/stepcode/pull/294 |
| 12:42.03 | *** part/#stepcode github-notify (~github-no@192.30.252.38) |
| 12:42.49 | hoiji | great!! (seems like github notify is faster then me) |
| 12:43.30 | mpictor | when you work in the stepcode repo, three main rules: |
| 12:43.55 | mpictor | always work on a branch, never master - create pull requests when you're happy |
| 12:44.24 | mpictor | code formatting can be a pain, but it makes code easy to read |
| 12:45.07 | mpictor | branch names are your initials, followed by a slash and a topic |
| 12:45.18 | mpictor | that way, others know who's working on it |
| 12:48.55 | hoiji | I do empathesize with your second point. As for the 1st and 3rd, seems like I will have to brush up my skills about git terminology in the immediate future :) |
| 12:49.25 | hoiji | As for now does that mean that I will no longer have to work on the forked repository of stepcode on my handle? |
| 12:49.47 | mpictor | create a new branch: git checkout -b mp/topic-here |
| 12:49.48 | mpictor | yes |
| 12:50.01 | mpictor | change branches: git checkout mp/another-topic |
| 12:50.54 | mpictor | you can create a new branch when you have uncommitted changes, but you can't switch to a different branch if changes would be overwritten |
| 12:52.10 | mpictor | I usually use the command line for creating commits, and often for switching branches |
| 12:52.21 | mpictor | the rest of the time, I use gitk for switching branches |
| 12:52.34 | mpictor | it's also handy for deleting branches |
| 12:53.48 | hoiji | thanks.. I will keep that in mind. |
| 12:54.44 | mpictor | two handy but potentially dangerous commands you might want to read up on: |
| 12:54.50 | mpictor | git rebase -i |
| 12:55.01 | mpictor | git reset --hard HEAD |
| 12:55.38 | mpictor | the former lets you reorder commits, merge them together, and delete them |
| 12:55.55 | mpictor | the latter wipes out any changes you've made since last committing |
| 13:06.12 | hoiji | mpictor: one more thing will it make sense to allow the user to determine how many maximum clones does he want? |
| 13:06.58 | mpictor | good idea |
| 13:07.20 | mpictor | I'd have a default, and allow the user to override it |
| 13:11.45 | hoiji | oh! thats nice, I think, to keep things simple, I will have only one variable to denote the maximum number of clones for different judy objects present in one class |
| 13:22.41 | mpictor | I'd ether make them specify a number while creating the lazyInstMgr, or refuse to set the number smaller than the current number |
| 13:23.05 | mpictor | otherwise you'll have to deal with deleting clones, but first checking if they are in use |
| 13:23.22 | mpictor | hmmm. guess you'll have to do that anyway for cleanup()\ |
| 13:23.32 | mpictor | *cleanup() |
| 13:27.38 | hoiji | yes, I get that. I was refering to something different: Since we have many judy objects (such as _fwdInstanceRefs, _revInstanceRefs etc) in lazyInstrMgr, will they have the same maximum clone count, or can they different maximum clone counts? |
| 13:27.54 | mpictor | oh, I see |
| 13:28.13 | mpictor | I'd start with them all having the same maximum |
| 13:28.34 | hoiji | yes, that would make sense :) |
| 13:28.52 | mpictor | if you run out of other things to do, you can do benchmarks and see what the performance tradeoffs are |
| 13:30.11 | hoiji | I do hope, i run out of things to do ;) |
| 13:30.20 | mpictor | hah |
| 13:53.49 | *** join/#stepcode hoiji (671b082c@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.44) |
| 14:50.41 | mpictor | starseeker: did you know you can do "make test ARGS=-j12"? |
| 14:51.07 | mpictor | I thought it wasn't possible to run test in parallel with make test |
| 16:38.14 | *** join/#stepcode github-notify (~github-no@192.30.252.39) |
| 16:38.15 | github-notify | [stepcode] mpictor pushed 5 new commits to master: https://github.com/stepcode/stepcode/compare/5abaebb04b9d...c3094242c81c |
| 16:38.15 | github-notify | stepcode/master 35b7694 hoiji09: Added instanceDependencies function in lazyInstMgr... |
| 16:38.15 | github-notify | stepcode/master a285652 hoiji09: Removed extra whitespace... |
| 16:38.15 | github-notify | stepcode/master 3e4af5a hoiji09: Changes in printDeps test module... |
| 16:38.15 | *** part/#stepcode github-notify (~github-no@192.30.252.39) |
| 16:44.37 | starseeker | mpictor: I didn't, actually - that's cool! |
| 16:44.40 | starseeker | thanks! |
| 16:51.57 | *** join/#stepcode travis-ci (~travis-ci@ec2-54-81-173-89.compute-1.amazonaws.com) |
| 16:51.57 | travis-ci | [travis-ci] stepcode/stepcode#121 (master - c309424 : Mark): The build is still failing. |
| 16:51.57 | travis-ci | [travis-ci] Change view : https://github.com/stepcode/stepcode/compare/5abaebb04b9d...c3094242c81c |
| 16:51.57 | travis-ci | [travis-ci] Build details : http://travis-ci.org/stepcode/stepcode/builds/21881672 |
| 16:51.57 | *** part/#stepcode travis-ci (~travis-ci@ec2-54-81-173-89.compute-1.amazonaws.com) |