Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-03-18

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 tadzik all of them, at once :)
00:11 jnap joined #moarvm
00:18 timotimo joined #moarvm
00:44 harrow joined #moarvm
00:50 japhb__ http://en.wikipedia.org/wiki/Gustafson%27s_law   # Not scaling?  Just add more work!
00:54 timotimo japhb__: are you okay with my changes to extract common stuff from bench?
01:00 japhb__ timotimo: I chewed on that a bit, wondering if it was a net win.  Then I realized 1) We might want to make more than one Perl 6 tool in that repo, and 2) We can precompile the common stuff module, making for faster load time.  So yeah, I'm fine with it.
01:00 japhb__ Except I thought 'our' and 'is export' were redundant?
01:01 japhb__ At least for the way you're using them.
01:01 timotimo i *thought* it was, too
01:01 timotimo then i tried to make it work without it and failed
01:02 timotimo also, i'm hacking up a tool that i want to have the common code shared in it
01:02 timotimo but i'm thinking before i actually tackle that tool, i want to make multi-part versions work
01:03 japhb__ If the our/is export pair are *both* needed, we should figure out why ... because that's probably a bug somewhere.
01:03 japhb__ What will your new tool do?
01:04 timotimo be a menu/dialog driven interface to the benchmarker
01:05 timotimo oh, by the way
01:05 timotimo i'd really like to have a feature that'll let me give aliases to the pieces that make up a benchmark output
01:05 timotimo so that instead of rakudo-moarvm/12345, rakudo-moarvm/54321 we'll have "/before" and "/after" or something like that
01:05 japhb__ Menu as in prompt(), or as in curses?
01:06 timotimo closer to the first
01:06 japhb__ Aliases would be nice, yes.  I would think they wouldn't be all *that* hard -- all the work should be in bench, not in timeall.
01:07 timotimo good
01:07 japhb__ Heck, there's at least a 10% chance that just putting symlinks in the right places will magically work.  :-)
01:07 timotimo i'm wondering wether to introduce a class to identify a particular "version" of something
01:08 japhb__ Why do you need that?
01:08 timotimo so that for-components or for-checkouts may be a bit more structured
01:08 timotimo maybe it's just to clear my mind WRT how sub-component-versions should work
01:08 japhb__ I don't want to add accidental complexity -- I've tried pretty hard to keep bench down to the intrinsic complexity of the problem space, translated directly to Perl 6.
01:09 timotimo mhm
01:09 japhb__ (The Perl 5 scripts -- well, they give up some of that in places.  Such is the nature of the beast.)
01:09 timotimo do you think sub-component-versioning is a bad idea all in all?
01:10 timotimo i've really been missing it a couple of times
01:10 japhb__ Give me an example for concreteness ...
01:10 timotimo i've implemented a fastpath for string concatenation in moarvm
01:11 timotimo now i want to compare rakudo-moar/1234 vs rakudo-moar/1234
01:11 japhb__ And your solution would be?
01:11 timotimo as you can see, rakudo-moar/1234 and rakudo-moar/1234 are "the same"
01:12 timotimo i'd tell bench to time rakudo-moar/1234;;abcd and rakudo-moar/1234;;ffff
01:12 timotimo ; is not a good choice, i think i decided to use : instead?
01:12 japhb__ Yeah, but how do the actual checkouts differ?
01:13 timotimo they check out a different version of moarvm when building their dependencies
01:13 timotimo and they have a different name to reflect that fact
01:13 japhb__ Oh, that's right, I remember now.
01:14 japhb__ Yup, gotcha.  What about: rakudo-moar/1234:moarvm=abcd
01:14 japhb__ To be general about component references
01:15 timotimo i don't really like it all that much, but i'm not 100% sold on forcing them to be positional
01:17 japhb__ timotimo: Or maybe we piggyback on your alias concept -- Our aliases can include not just a checkout of the top component, but additional settings (such as subcomponent versions, compiler flags, environment vars to set, etc.)
01:18 japhb__ Which means that if you want all the power, you have to shift from pure argument expansion to configuring real aliases first.
01:18 timotimo oof
01:19 japhb__ (Unless we want to specify a packed command line form for said aliases, sorta like I mentioned above)
01:19 japhb__ I'm basically wondering if we've reached a tipping point between "lots of little sugars" to "we need a unifying concept here"
01:22 woosley joined #moarvm
01:45 jnap joined #moarvm
02:08 jnap joined #moarvm
04:11 jnap joined #moarvm
04:45 jnap joined #moarvm
05:45 JimmyZ I updated dyncall to newest version to fix the license issue.
05:46 jnap joined #moarvm
06:03 TimToady JimmyZ++
06:06 woosley1 joined #moarvm
06:47 jnap joined #moarvm
07:28 ggoebel11116 joined #moarvm
07:48 jnap joined #moarvm
07:51 jnthn JimmyZ: Great, thanks! :)
08:06 FROGGS joined #moarvm
08:10 zakharyas joined #moarvm
08:49 jnap joined #moarvm
08:56 JimmyZ bonsaikitten: ^^
09:27 dalek MoarVM: 20c20b5 | jimmy++ | src/io/syncfile.c:
09:27 dalek MoarVM: Make lock/unlock function static
09:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/20c20b549f
09:49 jnap joined #moarvm
10:51 tomyan joined #moarvm
10:53 tomyan I'm trying to try out rakudo with moarvm with "perl Configure.pl --gen-moar --gen-nqp --backends=moar" in a rakudo clone, and getting the error "Unable to checkout 'a9e6eec70785f43f63ef17189fc2733d4ceb8446' in submodule path '3rdparty/dyncall'"
10:53 tomyan anyone know how to fix it?
10:55 tomyan has "git error: fatal: reference is not a tree: a9e6eec70785f43f63ef17189fc2733d4ceb8446" before the error
11:51 jnap joined #moarvm
11:52 tomyan joined #moarvm
12:08 TimToady joined #moarvm
12:16 JimmyZ tomyan: rm 3rdparty/dyncall and git reset HEAD --hard
12:21 FROGGS joined #moarvm
12:31 tomyan JimmyZ: just tried, but have same error
12:31 timotimo "git submodule update" perhaps?
12:31 timotimo in moarvm/ ?
12:32 * timotimo waves hands
12:32 tomyan don't really understand as I can see the submodule here https://github.com/MoarVM/dyncall/tree/a9e6eec70785f43f63ef17189fc2733d4ceb8446, but even if I cd 3rdparty/dyncall and do "git checkout a9e6eec70785f43f63ef17189fc2733d4ceb8446" I get "fatal: reference is not a tree: a9e6eec70785f43f63ef17189fc2733d4ceb8446"
12:33 tomyan same with git submodule update
12:33 tomyan have tried in a separate MoarVM checkout (with
12:34 tomyan s/\(with)//
12:34 tomyan slightly beyond my knowledge of git :-(
12:37 moritz maybe the submodule references a wrong repo?
12:38 moritz .gitmodule should say    url = https://github.com/MoarVM/dyncall.git
12:40 tomyan it does
12:40 timotimo how about git pull? will that help?
12:40 moritz git fetch (in the submodule)
12:40 timotimo or that
12:40 moritz pull won't work, 'cause submodules usually are in detached HEAD state
12:40 timotimo right
12:40 tomyan is a fresh clone
12:40 timotimo moarvm/dyncall says the latest commit is 5c4e85
12:41 timotimo that's not the same as what tomyan is getting an error for
12:41 timotimo in fact
12:41 timotimo i cannot find that commit in the recent logs
12:42 tomyan to reproduce: git clone git@github.com:MoarVM/MoarVM.git && cd MoarVM && perl Configure.pl --optimize --prefix=/some/path --make-install
12:42 moritz it's from 2013-08-27
12:44 timotimo hm
12:44 timotimo i don't get the error fwiw
12:44 tomyan oh
12:44 * moritz also tries
12:44 tomyan what version of git, perl?
12:44 timotimo even after rm -rf 3rdparty/dyncall
12:44 tomyan git version 1.7.5.2
12:44 timotimo git version 1.8.1.2
12:45 moritz I use 1.7.9.2, and now I got the same error
12:45 tomyan will try upgrading and see if it goes away
12:46 timotimo moritz: how can i reproduce that error? o_O
12:47 * timotimo freshly clones moarvm
12:47 timotimo ah
12:47 timotimo with a fresh clone it *does* fail
12:48 timotimo perhaps there was a rebase or something?
12:49 timotimo yup, the commit we're looking for has disappeared
12:50 tomyan ah, not git version related - will stop doing battle with macports :-)
12:51 timotimo i'll make a quickfix.
12:52 jnap joined #moarvm
12:52 timotimo try now.
12:53 moritz timotimo: what did you do?
12:53 timotimo i pushed the referenced commit up to the dyncall repo under a new branch named "safety_branch"
12:55 tomyan cool, thanks
12:55 moritz ah, now I understand
12:55 moritz it wasn't referenced from anywhere
12:56 timotimo yes
12:56 moritz and exisitng checkouts still had the commit, so a simple pull wouldn't exhibit the problem
12:56 timotimo we should keep this branch around, or bisecting and such in the future will be very painful
12:56 timotimo yes
12:57 dalek joined #moarvm
13:13 JimmyZ I just have a fresh clone moarvm, I didn't see the issue
13:14 timotimo yes, i just fixed it :)
13:14 JimmyZ No,  before you fix it
13:20 timotimo oh?
13:28 dalek MoarVM: 79973cf | jimmy++ | 3rdparty/dyncall:
13:28 dalek MoarVM: Bump dyncall to latest version
13:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/79973cf586
13:28 JimmyZ ^^ should fix the real problem
13:29 JimmyZ tomyan: ^^
13:45 dalek MoarVM: 20931e6 | jimmy++ | build/setup.pm:
13:45 dalek MoarVM: fixed posix build
13:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/20931e6e8a
13:46 FROGGS JimmyZ++ # good catch
14:08 jnap joined #moarvm
15:01 FROGGS joined #moarvm
15:51 jnap1 joined #moarvm
16:47 cognominal joined #moarvm
17:46 timotimo gc_mark is a pretty bad spot for updating the forwarder.
17:46 timotimo but i'm not sure where to place this :|
17:47 timotimo perhaps before copy_to would get called?
17:48 timotimo since i'm now only doing debug output instead of changing the forwarderd, i expect the ratio of "put a new string into the hash" to "used an existing string" would get pretty lobsided, as it'll put the same string into the hash again and again in the next collection
17:48 timotimo potentially
18:03 timotimo hm. the forwarder of the "earlier" string may not be initialized at all during the gc_mark of MVMString
18:04 timotimo hm. actually. i can solve this totally differently
18:24 timotimo hm.
18:33 timotimo how come copy_to of MVMString seems to never be called?
18:36 timotimo so, what i'm doing is if i reach an MVMString in gc_mark, I add the object to the coalescing hash using the string it represents as a key
18:37 timotimo at the beginning of a gc run, i clear out the hash (which hangs off of the threadcontext) and when the gc run finishes, i go through the hash and try to follow all the forwarders
18:37 timotimo except none of these has a forwarder set
18:40 timotimo apparently i don't need to follow the forwarder at that point o_O
18:40 timotimo so is gc_mark called after the object is copied over? O_o
18:43 timotimo 605908maxresidentk with coalescer
18:45 timotimo 607684maxresidentk without
18:45 timotimo hum.
18:47 timotimo well, i may just be doing it completely wrong. but if not, this isn't particularly helping.
18:49 * timotimo took the coalescer for gen2 out)
18:50 timotimo so many smilies
18:50 timotimo but still 604m :\
18:57 FROGGS btw, I can't help you there but I just want to tell that I am with you :o)
18:57 timotimo heh
18:58 timotimo something must be keeping the objects i've intended to throw out around after the fact
18:58 timotimo the strings still clump up by the thousands in the old generation
18:59 timotimo Could not locate compile-time value for symbol &infix:<,> [=======                                            6
18:59 timotimo m)
19:02 timotimo now i kind of wish there was a "how many objects point to this" analysis
19:02 timotimo but doing that in python would be absurdly slow
19:02 timotimo i may have to re-implement parts of the GC memory analysis in C anyway
19:04 tomyan joined #moarvm
19:05 * timotimo feels rather useless now
19:10 yawnt you're not useless timotimo!
19:10 * yawnt goes back to sleep
19:21 TimToady timotimo: you should do it in Perl 6--I hear it's designed to be heavily optimized :)
19:31 timotimo i'm designed to be heavily optimized
19:47 raiph joined #moarvm
20:11 jnap joined #moarvm
21:18 colomon joined #moarvm
22:08 jnthn timotimo: GC mark has to be called after copying/marking an object.
22:08 jnthn timotimo: Since it happens once it's in its new location.
22:08 timotimo ah!
22:08 timotimo that's why i didn't have to follow the forwarders
22:09 jnthn I still worry a lot about getting the GC to do this.
22:09 jnthn There's a reason it's relatively quick at what it does: it's *simple*.
22:09 timotimo right; what i've done now is different
22:10 timotimo i put the coalescing into repr_get_str and repr_set_str
22:10 timotimo and only let the gc clear out the coalescing hash
22:10 timotimo which may have been a bad idea after all.
22:14 timotimo ah well. i'll let that code rot^Wrest until further notice
22:33 dalek MoarVM: 0566111 | jonathan++ | docs/ChangeLog:
22:33 dalek MoarVM: Mostly complete 2014.03 ChangeLog.
22:33 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0566111123
22:33 dalek MoarVM: 09c66c0 | jonathan++ | README.markdown:
22:33 dalek MoarVM: Some README tweaks.
22:33 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/09c66c0f75
22:36 dalek MoarVM: 362ce65 | timo++ | docs/ChangeLog:
22:36 dalek MoarVM: tiny typo fix
22:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/362ce65bb8
22:36 jnthn It may be missing some of the last commits
22:37 jnthn I did it on the plane with a not-exactly-up-to-date checkout
22:37 timotimo ah
22:37 jnthn And coudlnt' pull in the sky :)
22:37 timotimo there were no big changes
22:37 timotimo hm
22:37 timotimo a dyncall update, though
22:40 dalek MoarVM: 8da2d17 | (Timo Paulssen)++ | docs/release_guide.md:
22:40 dalek MoarVM: try to fix release guide shell code.
22:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8da2d17895
22:41 timotimo why does github render it to be just one line? >_>
22:41 dalek MoarVM: 9333f87 | (Timo Paulssen)++ | docs/release_guide.md:
22:41 dalek MoarVM: try to fix release guide shell code.
22:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9333f876a4
22:41 timotimo aaw COME ON!
22:50 timotimo jnthn: interestingly it seems like i didn't get any performance penalty from my coalescing fails at all
22:56 jnthn bah, chrome translates the DKK to £ o.O
22:56 jnthn uh, ww
22:56 retupmoca jnthn: did you see my moarvm nativecall issue with precompilation? https://gist.github.com/retupmoca/9606605
22:57 jnthn retupmoca: The one I fixed, or another one?
22:58 timotimo this is from a day ago, so i would think it's another one
22:58 retupmoca jnthn: another one I think - nativecall compiles fine, but anything that 'is native(...)' doesn't seem to precompile right
22:58 jnthn ah
22:58 jnthn yeah, it's a new one
22:58 jnthn *sigh*
22:58 retupmoca sorry :)
22:58 jnthn Not sure why it doesn't work.
22:58 jnthn I didn't try that yet. I was kinda expecting to get the Star modules to point such things out.
23:09 dalek MoarVM: 1fc0e35 | (Andrew Egeler)++ | docs/release_guide.md:
23:09 dalek MoarVM: Fix release_guide.md step 5
23:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1fc0e356aa
23:09 dalek MoarVM: acaa6c2 | timo++ | docs/release_guide.md:
23:09 dalek MoarVM: Merge pull request #83 from retupmoca/master
23:09 dalek MoarVM:
23:09 dalek MoarVM: Fix release_guide.md step 5
23:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/acaa6c252c
23:35 tomyan joined #moarvm
23:36 dalek MoarVM: d4d0d86 | (Gerd Pokorra)++ | Configure.pl:
23:36 dalek MoarVM: Add --has-libtommath extension.
23:36 dalek MoarVM:
23:36 dalek MoarVM: Enables use of a system libtommath, which is helpful for packagers.
23:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d4d0d86b35

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary