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

Fix release_guide.md step 5
23:35 tomyan joined
dalek arVM: d4d0d86 | (Gerd Pokorra)++ | Configure.pl:
Add --has-libtommath extension.

Enables use of a system libtommath, which is helpful for packagers.		 23:36

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!