Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-01-19

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

All times shown according to UTC.

Time Nick Message
00:01 jnap joined #moarvm
00:20 FROGGS diakopter++ # that looks promising!
00:21 diakopter FROGGS: well, it passes 4 more
00:21 diakopter but.. bleh.
00:21 diakopter I expected it to pass more
00:21 jnthn diakopter++ # moar hacking
00:22 diakopter FROGGS: I couldn't tell which of your changes you wanted merged
00:22 diakopter :S
00:42 colomon joined #moarvm
01:02 jnap joined #moarvm
01:13 jnap joined #moarvm
04:13 jnap joined #moarvm
05:14 jnap joined #moarvm
06:14 jnap joined #moarvm
07:15 jnap joined #moarvm
07:26 lizmat joined #moarvm
07:26 lue joined #moarvm
07:52 JimmyZ E:\OpenSource\nqp>..\Moarvm\install\bin\moar.exe --version
07:52 JimmyZ This is MoarVM version 2013.10-386-g1a93bf0
07:52 JimmyZ E:\OpenSource\MoarVM\install\bin\moar --libpath=src\vm\moar\stage0 src\v
07:52 JimmyZ m\moar\stage0\nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc
07:52 JimmyZ --output=gen\moar\stage1\nqpmo.moarvm gen\moar\stage1\nqpmo.nqp
07:52 JimmyZ MAST::Local index out of range
07:52 JimmyZ jnthn: ^^
07:53 diakopter JimmyZ: almost certainly need to start from fresh, unfortunately
07:53 JimmyZ yes, it's fresh
08:01 moritz I get the same error on my raspberry pi (ARM processor)
08:16 jnap joined #moarvm
08:27 FROGGS gah, I should reads comments
08:27 FROGGS #?niecza 3 todo "Tests are wrong by latest Unicode standard"
08:27 FROGGS I was trying to make these work >.<
08:27 diakopter oops
08:27 moritz fix the tests then :-)
08:28 FROGGS I will
08:29 timotimo i'm not actually sure, hint_for is implemented correctly
08:29 timotimo isn't the point of hint_for to pass a compile-time known type object and get a hint back?
08:29 timotimo oh, yes, and that's also how it's implemented %)
08:29 FROGGS diakopter: there are a lot of these comments in properties-general.t
08:30 diakopter oh :)
08:30 FROGGS no wonder we don't pass 'em :o)
08:30 diakopter I'm currently trying to figure out why this:
08:30 diakopter m: say "\c[FULLWIDTH RIGHT PARENTHESIS]"
08:30 camelia rakudo-moar 912342: OUTPUT«3␤»
08:31 diakopter WRONG
08:31 diakopter m: say "\c[FULLWIDTH LEFT PARENTHESIS]"
08:31 camelia rakudo-moar 912342: OUTPUT«2␤»
08:32 moritz offby20
08:32 diakopter m: say "\c[FULLWIDTH EXCLAMATION MARK]"
08:32 camelia rakudo-moar 912342: OUTPUT«+␤»
08:33 diakopter m: say "\c[FULLWIDTH RIGHT WHITE PARENTHESIS]"
08:33 camelia rakudo-moar 912342: OUTPUT«ェ␤»
08:34 diakopter m: say "\c[REPLACEMENT CHARACTER]"
08:34 camelia rakudo-moar 912342: OUTPUT«????␤»
08:34 FROGGS diakopter: there must be something skipped in that names list, no?
08:34 diakopter something like that, yeah
08:35 diakopter it gets FFFD right
08:35 diakopter binary searching backwards
08:35 * timotimo left an isconcrete(obj) in the op implementation for hintfor m)
08:35 diakopter m: say "\c[FULLWIDTH TILDE]"
08:35 camelia rakudo-moar 912342: OUTPUT«ィ␤»
08:36 diakopter gah
08:36 FROGGS mp: say "\c[FULLWIDTH TILDE]".ord
08:36 FROGGS pm: say "\c[FULLWIDTH TILDE]".ord
08:36 FROGGS r: say "\c[FULLWIDTH TILDE]".ord
08:36 camelia rakudo-parrot 912342, rakudo-jvm 912342: OUTPUT«65374␤»
08:36 camelia ..rakudo-moar 912342: OUTPUT«65384␤»
08:37 FROGGS r: say "\c[FULLWIDTH RIGHT PARENTHESIS]".ord
08:37 camelia rakudo-moar 912342: OUTPUT«65299␤»
08:37 camelia ..rakudo-parrot 912342, rakudo-jvm 912342: OUTPUT«65289␤»
08:37 FROGGS k, no hole between those two
08:37 moritz holey shit :-)
08:37 diakopter oh, I bet I know what it is
08:37 diakopter I hardcoded some boundary; checking
08:41 FROGGS btw, when we fix the test to comply with latest unicode, that will mean that perl6-p drops to like 98%
08:42 FROGGS and even more when the names list is fixed
08:42 diakopter :/
08:42 FROGGS this could mean that moar passes moar tests by then
08:42 timotimo can we get the error message "Cannot invoke this object (REPR: P6opaque, cs = 0)" to try to figure out the name of the class if it's a p6opaque repr'd object?
08:43 diakopter sure
08:43 moritz well, if fixing tests causes the perl-p numbers to drop, then the current numbers are bogus anyway
08:43 diakopter right, but the change obscures the remaining amount
08:44 moritz then compare to perl-j instead :-)
08:46 timotimo how do i pass an int16 to a mast op when i'm compiling a QAST::Op that is mapped to that mast op?
08:47 timotimo i get "Error while compiling op bindattr_h: unhandled reg kind 2", which i can only guess means i didn't supply the hint in the last argument correctly
08:48 timotimo i tried passing a QAST::IVal.new( :value($hint) ) where $hint is declared as my $hint
08:48 timotimo er, my int $hint
08:48 diakopter IVal takes a bit width param I think
08:49 timotimo ah, let me have a look
08:49 timotimo maybe it does on moar?
08:49 timotimo yeah, it does
08:49 timotimo tanks
08:50 timotimo ah, MAST::IVal takes that, but QAST::IVal doesn't
08:50 diakopter yeah
08:50 * timotimo tries to plop the MAST::IVal directly into the QAST
08:51 diakopter funny thing is it might work
08:51 timotimo it better work! :)
08:51 timotimo nope, still get the "unhandled reg kind"
08:51 timotimo but isn't 2 string?
08:51 diakopter nopaste your diff?
08:52 timotimo it contains a bootstrap update :P
08:52 diakopter gah
08:53 timotimo https://gist.github.com/timo/e45ca59d78a0165560cf
08:53 timotimo perhaps i have to switch out the string register for a string constant somehow? but it's already an SVal in the QAST
08:55 diakopter you didn't push the attrname to oplist
08:56 timotimo i ... didn't have to?
08:56 diakopter oh
08:57 diakopter why does $op[1] need to be a WVal
08:57 timotimo the class could be supplied dynamically
08:58 diakopter why did you use str_from_want_or_sval
08:58 timotimo because i wasn't sure if i would encounter a want or a SVal
09:00 diakopter but if you're unwrapping the want you need to coerce it
09:00 timotimo right. i've done that now (by splicing a SVal.new into the oplist)
09:01 diakopter but it may not be a string yet
09:01 timotimo ... huh?
09:01 diakopter it may be a qast expression
09:01 diakopter right?
09:01 timotimo hm, doesn't the "S" slot of a Want contain a literal string in all cases?
09:02 diakopter oh, I didn't know
09:03 diakopter do you have an updated diff?
09:03 timotimo nqp::splice(@oplist, [QAST::SVal.new( :value($attrname) )], 2, 1);
09:03 timotimo this is the line i added to the if $hint != -1 section
09:04 diakopter why splice
09:04 diakopter @oplist[2] =
09:09 timotimo oh
09:09 timotimo haha :)
09:16 timotimo well, it doesn't fix it anyway :(
09:17 jnap joined #moarvm
09:31 dalek MoarVM: b3a845d | jimmy++ | src/6model/reprs.c:
09:31 dalek MoarVM: removed needless header file
09:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b3a845de5f
09:42 FROGGS r: say "MUSICAL SYMBOL BEGIN BEAM"
09:42 camelia rakudo-parrot 912342, rakudo-jvm 912342, rakudo-moar 912342: OUTPUT«MUSICAL SYMBOL BEGIN BEAM␤»
09:42 FROGGS r: say "\c[MUSICAL SYMBOL BEGIN BEAM]"
09:42 camelia rakudo-parrot 912342: OUTPUT«????␤»
09:42 camelia ..rakudo-jvm 912342: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/OwRAhscyyh␤Unrecognized character name MUSICAL SYMBOL BEGIN BEAM␤at /tmp/OwRAhscyyh:1␤------> [32msay "\c[MUSICAL SYMBOL BEGIN BEAM[33m⏏[31m]"[0m␤»
09:42 camelia ..rakudo-moar 912342: OUTPUT«????␤»
09:43 FROGGS r: say "\c[KAITHI NUMBER SIGN]"
09:43 camelia rakudo-parrot 912342: OUTPUT«????␤»
09:43 camelia ..rakudo-moar 912342: OUTPUT«????␤»
09:43 camelia ..rakudo-jvm 912342: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/96Ky0BYHbs␤Unrecognized character name KAITHI NUMBER SIGN␤at /tmp/96Ky0BYHbs:1␤------> [32msay "\c[KAITHI NUMBER SIGN[33m⏏[31m]"[0m␤»
09:43 diakopter sigh
09:43 FROGGS r: say "\c[SYRIAC ABBREVIATION MARK]"
09:43 camelia rakudo-parrot 912342, rakudo-jvm 912342, rakudo-moar 912342: OUTPUT«܏␤»
10:08 FROGGS diakopter: about <:Format> see https://github.com/perl6/roast/commit/0791cdfd50
10:08 FROGGS perl6-m matches everything for <:Format>
10:09 FROGGS because its property value code is 0
10:11 FROGGS r: say "ohh?" ~~ /<:Format>+/
10:11 camelia rakudo-moar 912342: OUTPUT«「ohh?」␤␤»
10:11 camelia ..rakudo-parrot 912342, rakudo-jvm 912342: OUTPUT«Nil␤»
10:18 jnap joined #moarvm
10:23 FROGGS ohh well, HEAD does it correct
10:24 diakopter ?
10:26 FROGGS locally <:Format> does not everything
10:27 FROGGS and it passes the (fixed) tests
10:45 jnthn JimmyZ: Well, I can't do much about it with just that error...
10:47 jnthn JimmyZ: Is it a 32-bit build?
10:56 odc joined #moarvm
11:18 jnap joined #moarvm
11:54 JimmyZ jnthn: win7 32bit
11:55 jnthn JimmyZ: OK, I suspect the 32-bit...
11:57 JimmyZ missing MVMROOT somewhere? ;)
11:58 jnthn Unlikely given the error
12:32 FROGGS should the 32bit issue we have since MVM's announcement
12:34 jnthn 32-bit Windows, but not 32-bit Linux, iirc?
12:38 moritz oh, maybe the build fails on the RPi because it's 32 bit
12:38 moritz not because it's ARM
12:39 jnthn Maybe it's that, yeah...
12:40 jnthn FROGGS: Did you say there was an "unlink sometiems fails" bug?
13:10 FROGGS jnthn: must be, because files created during spectest are not deleted
13:11 FROGGS I can't remember though what was wrong
13:20 jnap joined #moarvm
13:22 jnthn Well, I'd screwed something else up, so... :)
13:22 jnthn Been investigating the performance issues that grondilu++ reported.
13:22 jnthn And the profile it led to
13:22 jnthn Found some messed up closure handling.
13:23 jnthn And fixing the code-gen.
13:23 jnthn So we can turn on caching any autoclose we do.
13:27 woolfy joined #moarvm
13:35 dalek MoarVM: 02585d1 | jnthn++ | src/core/frame.c:
13:35 dalek MoarVM: Cache auto-close result.
13:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/02585d18a1
13:45 jnthn Oh...we were doing re-use of callsites by *frame* when it should be by compunit.
13:51 jnthn 29KB saving on CORE.setting.moarvm
13:52 dalek MoarVM: 343c623 | jnthn++ | src/mast/compiler.c:
13:52 dalek MoarVM: Callsites should be per compunit, not frame.
13:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/343c6231b6
13:56 JimmyZ jnthn++
14:04 dalek MoarVM: cc82df7 | jnthn++ | src/io/fileops.c:
14:04 dalek MoarVM: Don't stat non-file handles.
14:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cc82df761b
14:10 jnthn oh, argh, that won't help...
14:20 jnap joined #moarvm
14:27 masak why not?
14:32 jnthn Well, for one 'cus I misread the code and look at junk memory...
14:34 jnthn Well, may have a hack now that gets us at least a basically working repl
14:34 jnthn Which is much better than segv
14:35 jnthn At some point I need to give the IO stuff a serious look over, though.
14:44 jnap joined #moarvm
14:50 dalek MoarVM: aa79dda | jnthn++ | src/io/fileops.c:
14:50 dalek MoarVM: Some hacks to unbust the REPL.
14:50 dalek MoarVM:
14:50 dalek MoarVM: Need to revisit both of these, and IO in general, but this gives a
14:50 dalek MoarVM: much better user experience than SEGV...
14:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/aa79ddad5a
15:10 timotimo jnthn: was the callsite caching thing what caused coroutines to inflate the stack? or is that fix still coming up? :)
15:12 jnthn timotimo: No, the callsite caching was just a small inefficiency
15:12 jnthn timotimo: Though I plan to more fully intern them at some point in the future, so it kinda helps towards that.
15:13 jnthn timotimo: The coroutine stack inflation thing is same problem on JVM and Moar.
15:13 timotimo right. but you probably can't fix it once for both backends? :)
15:13 jnthn Well...it'd be nice to if possible
15:13 * jnthn is still trying to fully understand where things go bad
15:14 timotimo i'll let you get to it then :)
15:15 jnthn ah, I think I may see...
15:16 jnthn yeah...
15:34 jnthn I don't see a way of fixing it without doing at least something on each backend.
15:35 timotimo well, at least you now know what's up :)
15:38 jnthn Yeah. Now to see which of the two candidate fixes is easiest...
15:40 timotimo that will be a nice changelog entry.
15:48 timotimo jnthn: when you've finished with that task, would you be interested in looking at my "compile-time generate hints for get/bindattr calls" stuff that's currently blowing up?
15:50 jnthn timotimo: I've done that twice before, so yeah, can do :)
15:51 timotimo \o/
15:51 timotimo in trying to compile a bindattr into a bindattr_h ("plus hint"), i get Error while compiling op bindattr_h: unhandled reg kind 2, which i don't really understand
15:52 timotimo what i'm doing is i check for a constant string in the attribute name slot and a WVal in the class slot, then i turn the string (if it's a Want) into an SVal and push a hint at the end
15:55 dalek MoarVM: 7a9e60f | timo++ | README.markdown:
15:55 dalek MoarVM: removed "moar-support" from README.
15:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7a9e60f533
15:58 jnthn timotimo: Did you do the typical case with optimizing QAST::Var attribute access yet?
15:58 timotimo i don't know about that
15:58 * jnthn didn't realize we had a bindattr_h...
15:59 jnthn timotimo: We don't optimize nqp::getattr/nqp::bindattr on any platform yet...
15:59 timotimo i split the getattr_o and getattrs_o into bindattr_h and bindattr_nh and built a compiler
15:59 timotimo are you sure? i thought i implemented that for parrot
15:59 timotimo let me check
15:59 jnthn Oh, maybe...
15:59 jnthn I don't think registering a getattr_h or so is really the way to go, though.
15:59 timotimo yeah, i did that
16:00 timotimo well, i didn't want to write the mapping for those ops myself, so i thought i could rely on the already created handlers
16:01 timotimo oh wait, there's something wrong
16:02 timotimo i add a core_pirop_mapping for bindattr_s and then add_core_op for the same thing
16:42 lue joined #moarvm
17:02 lue joined #moarvm
17:03 dalek MoarVM: c417239 | jnthn++ | src/core/continuation.c:
17:03 dalek MoarVM: Allow continuationreset to be given a continuation
17:03 dalek MoarVM:
17:03 dalek MoarVM: It then invokes it, rather than invoking a code ref. This is ideal for
17:03 dalek MoarVM: Rakudo's needs when implementing gather/take as it avoids adding an
17:03 dalek MoarVM: extra stack frame every time we take.
17:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c4172392a9
17:40 jnthn bah, we had a major memory leak
17:40 diakopter oh?
17:42 dalek MoarVM: 27d285c | jnthn++ | src/6model/reprs/P6bigint.c:
17:42 dalek MoarVM: Free memory associated with bigints.
17:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/27d285c9a6
17:43 jnap joined #moarvm
17:44 jnthn Funny thing is our max memory in spectest *while leaking all the Ints* was lower than the Parrot max...
17:44 moritz lol
17:45 diakopter well how many Ints was it using
17:45 diakopter I doubt a ton, right?
17:45 jnthn A ton 'cus the sink code is being code-gen'd in a way that boxes an int on every single sink...d'oh.
17:46 moritz that was my doing, I'm sure :(
17:47 diakopter no probably mine
17:55 jnthn Well, I found it 'cus I've been looking at memory usage a bit
17:55 jnthn I'm doing some GC tuning.
17:55 jnthn (Nursery size and gen 2 collection interval)
17:55 jnthn Anyway, in the run I just did, I didn't see any test go above 250MB or so.
17:56 jnthn That was one of the hefty S05 ones.
17:56 jnthn Most are barely over 100MB.
18:02 timotimo this is all excellent news
18:02 jnthn I may have some more excellent news coming up in a moment.
18:06 timotimo i think i should push my bindattr/getattr work into a branch
18:06 timotimo also, i think access to private vars is handled through the getattr and bindattr ops already behind the scenes
18:06 timotimo i *think*
18:06 benabik joined #moarvm
18:09 dalek MoarVM: e83e725 | (Timo Paulssen)++ | / (6 files):
18:09 dalek MoarVM: expose the hintfor op
18:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e83e7257b0
18:10 jnthn OK, so...
18:10 jnthn I jsut did some analysis/tweaking of GC nursery size and how often we do full collections
18:10 jnthn We're die-young heavy
18:10 timotimo jnthn: would you be okay with me making a new bootstrap for moarvm to get hintfor in the compiler? or should i wait for some more coolness down the road?
18:11 diakopter jnthn: you gonna make objects live 3 nursery collections?
18:11 jnthn diakopter: No
18:11 jnthn Just tweaking nursery size and full collection rate
18:11 jnthn I got our stage parse down to about 4-5 seconds longer than JVM.
18:11 jnthn And spectest down to 362s
18:11 diakopter which is what % faster than before
18:12 tadzik { my $good } # only the good die young
18:12 jnthn It's 49s now compared to 70s before
18:12 timotimo that sounds crazy good!
18:13 timotimo how many more cheap wins are there to be had in the near future? :D
18:13 jnthn 362s spectest vs 451s before
18:13 timotimo \o/
18:13 jnthn I watched memory use and it was very little difference between these options.
18:14 jnthn CORE.setting is still well under 900MB here, highest I see in spectest is a bit over 250MB
18:14 tadzik sweet
18:16 dalek MoarVM: dc71ae4 | jnthn++ | src/gc/collect.h:
18:16 dalek MoarVM: Tweak GC nursery size and full collection rate.
18:16 dalek MoarVM:
18:16 dalek MoarVM: Based on considering Rakudo spectest and setting build time/memory.
18:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dc71ae47c3
18:19 jnthn Sanity test is now always consistently coming within 3s. I just got it to report 2s. o.O
18:20 timotimo that's Cray.
18:20 tadzik :>
18:20 tadzik jnthn++
18:23 FROGGS yeah! it is soo much fun to read backlog here!
18:23 FROGGS (and in the channel nearby)
18:24 timotimo :D
18:30 jnthn m: say "I spectest in {100*362/1662}% of the time I did 48 hours ago"
18:30 camelia rakudo-moar 8c054a: OUTPUT«I spectest in 21.780987% of the time I did 48 hours ago␤»
18:31 timotimo that's absolutely lovely
18:32 * tadzik changes rakudobrew to --gen-moar=master
18:32 FROGGS see^^ I mean news like these :o)
18:32 * FROGGS is happy, verry happy
18:32 FROGGS -r
18:33 tadzik "Your move, Parrot"
18:33 tadzik Moar is a dream come true
18:33 FROGGS tadzik: they are going to release 6.0.0 in a few days
18:33 tadzik FROGGS: oh, have there been commits?
18:33 tadzik indeed
18:33 FROGGS rurban++ did some, yes
18:34 timotimo what's cool & new?
18:34 tadzik test and docs fixes, as I see
18:34 tadzik and some fixes for tests :)
18:34 timotimo oh well.
18:36 FROGGS like for the unicode vowel thingy that libicu did to us :o)
18:37 timotimo that sounds good
18:39 tadzik uh
18:39 tadzik r-m: say $*VM<name>
18:39 camelia rakudo-moar 8c054a: OUTPUT«moar␤»
18:39 tadzik oh
18:41 dalek MoarVM: 865d077 | (Tobias Leich)++ | tools/ucd2c.pl:
18:41 dalek MoarVM: fix swapped params of register_gc_alias
18:41 dalek MoarVM:
18:41 dalek MoarVM: This actually sets properties like 'L' if the codepoint is a Lu|Ll|...
18:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/865d0771ea
18:44 jnap joined #moarvm
18:44 _sri haha, i was about to ask if there's a perl6brew yet... and of course tadzik mentions rakudobrew in the backlog \o/
18:44 tadzik :)
18:44 tadzik please try it out :)
18:44 tadzik hell, I'll even open it for bug reports
19:41 [Coke] today's run will have 11 more passing spec tests than yesterday.
19:44 jnap joined #moarvm
19:46 [Coke] ... but apparently run muuuuch faster. :)
19:52 Guest1338 joined #moarvm
20:20 dalek MoarVM: 839dafe | (Tobias Leich)++ | / (3 files):
20:20 dalek MoarVM: add lookup for property value codes of unions
20:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/839dafe80b
20:23 jnthn FROGGS: oooh...is that what I think it is? :)
20:24 FROGGS jnthn: a few test more :o)
20:24 jnthn Does it make <:L> work?
20:24 FROGGS 21 to be exact
20:24 FROGGS yes
20:25 FROGGS <:L> does work, but the alias <:Letter> does look in the wrong direction atm
20:25 FROGGS going to fix that now
20:25 jnthn Right, but <:L> working means wordcase will now work.
20:25 FROGGS true
20:25 jnthn Which will unbust capitalize.t and substr.t, I think.
20:25 * jnthn pulls and sees
20:25 FROGGS $ perl6-m -e 'say "Right, but <:L> working means wordcase will now work.".wordcase'
20:25 FROGGS Right, But <:L> Working Means Wordcase Will Now Work.
20:25 FROGGS \o/
20:26 jnthn \o/
20:28 jnthn FROGGS: Yup, wordcase and substr fails gone \o/
20:28 jnthn FROGGS++
20:29 FROGGS cool!!
20:29 jnthn So 10 more passes from there too
20:38 timotimo i'm back, what did i miss? :)
20:38 jnthn <:L>
20:39 timotimo cool!
20:44 dalek MoarVM: b1d5b51 | benabik++ | build/ (2 files):
20:44 dalek MoarVM: Split out Moar-specific ld flags
20:44 dalek MoarVM:
20:44 dalek MoarVM: Specifically splits @ldshared@ into @ldshared@ and @moarshared@.
20:44 dalek MoarVM:
20:44 dalek MoarVM: The difference is that @ldshared@ includes flags that should be used
20:44 dalek MoarVM: to create shared libraries by users of Moar, but @moarshared@ includes
20:44 dalek MoarVM: flags that should only be used when building Moar itself.
20:44 dalek MoarVM:
20:44 dalek MoarVM: This includes the -install_name flag on OS X and the /implib flag on
20:44 dalek MoarVM: Windows.
20:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b1d5b518a9
20:45 jnap joined #moarvm
20:45 benabik There's a --out-implib flag on MinGW that looks like a candidate for moarshared, but I didn't want to move it without specific knowledge.
20:45 benabik I moved the /implib flag because it got filtered out by Rakudo.
20:49 timotimo benabik: does that fix moarvm building on osx?
20:49 benabik timotimo: It's half of it.
20:50 timotimo fair enough :)
20:50 timotimo thank you
21:05 benabik timotimo: Rakudo PR#238 is the other half, BTW.
21:29 colomon joined #moarvm
21:32 * timotimo bisects the optimizers that kill moarvm
21:46 jnap joined #moarvm
22:00 diakopter joined #moarvm
22:01 timotimo no actual bisecting has happened yet
22:13 * jnthn is doing some changes in hope of a win
22:13 benabik So nice to see perl6-m go by in my compilation window.
22:14 * FROGGS .oO( and over and over again :o)
22:23 timotimo -falign-jumps may be the offender here
22:24 timotimo it plays together with some other flag to cause the error
22:25 * timotimo bisects
22:35 timotimo something is causing the REPR to have bogus function pointers in it
22:36 dalek MoarVM: bec8322 | (Tobias Leich)++ | / (3 files):
22:36 dalek MoarVM: consistently emit aliases but not duplicates
22:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bec8322d39
22:41 jnthn bah, no win.
22:42 jnthn Can't win 'em all...
22:42 FROGGS :(
22:43 FROGGS looks like we won enough for today :o)
22:43 jnthn Yeah
22:43 jnthn Was looking into killing off or changing the role of the refs_frames thing.
22:44 jnthn But the simple non-solution I came up with causes epic leaks.
22:44 FROGGS :/
22:44 jnthn (yes, it's clear enough to me why)
22:45 jnthn (but means the real solution is gonna be more involved)
22:47 jnap joined #moarvm
22:48 timotimo it would appear that casting the MVMCollectable * to a MVMSTable * causes b0rkage because gcc pads/layouts the structs differently or something
22:48 * FROGGS kicks off a m-summary to see if his fixes did more good than bad
22:49 timotimo so is there a keyword for gcc and other compilers to prevent "optimizing" the structs?
22:50 * FROGGS has no idea
22:51 jnthn Is that not likely to be about the strict aliasing thing?
22:53 timotimo i passed -fno-strict-aliasing and it didn't help
22:53 timotimo the successor to moarvm (if there'll ever be one) should be named MoireeVM
22:55 FROGGS *g*
22:56 FROGGS I'd call the successor SuccVM perhaps
22:56 timotimo may be a bit too punny
22:56 jnthn That names succs...
22:57 jnthn *name
22:57 timotimo jnthn: did you have a chance to look at my nqp diff for moar_precalc_hint?
22:57 jnthn timotimo: Not yet, been looking at the refs_frames thingy...
22:57 jnthn Though giving up on that today. It's kinda hard.
22:58 timotimo i don't know what that is, but okay :)
22:58 jnthn But really needs a good solution.
22:58 jnthn Well, it's the thing that's making GC runs a load more constly than they should be.
22:58 timotimo oh
22:58 timotimo that sounds like a good candidate for fixing then :)
22:58 jnthn Yeah, it is, it's just hard. :)
22:59 timotimo i'm thinking of writing a python script/"plugin" for gdb to enable things like reverse pointer lookups
22:59 timotimo ("what keeps this MVMCollectable alive?")
22:59 timotimo anything in particular you'd like to see?
22:59 jnthn Hm...itneresting idea.
23:00 jnthn *interesting
23:00 jnthn Well, I'd like to see you write it without re-writing half of the Moar GC I guess ;)
23:00 jnthn Re-implementing, I mean. :)
23:00 jnthn You can probably re-use all the gc_mark stuff but just treat the worklist entries differently than the GC does I guess. :)
23:01 timotimo that was my first thought, aye
23:01 jnthn It should be do-able.
23:01 jnthn But question is how you'll represent the result
23:01 timotimo but when i looked briefly at that, it seemed like there's some kind of generation counter or sequence i need to ++ when i want to do a faux marking step
23:01 jnthn Yeah...
23:01 jnthn There's a gc_seq_number
23:01 timotimo that's the one
23:01 jnthn You can increment the one in instance
23:01 timotimo and i was afraid it could make the rest of moarvm confused
23:02 jnthn So long as you don't do it while a GC run is taking place, you're probably OK.
23:02 timotimo that sounds doable
23:02 timotimo but not right now :P
23:02 jnthn :P
23:04 jnthn +    if nqp::istype($node, QAST::Want) && $node[1] eq 'S' {
23:04 jnthn I think that it actually shows up as Ss
23:05 jnthn Hmm...I don't think I'd do it by the nh and h variants
23:06 timotimo if you find out how to do it simpler, i'm all ears
23:06 jnthn Instead I'd just create the MAST right off.
23:06 timotimo yeah, but that's not easy
23:06 jnthn It's not so hard either
23:06 timotimo i have to sometimes decont, sometimes not, i have to return the third argument or not
23:06 jnthn It's a lot simpler than many of the other ops we do.
23:07 timotimo fwiw, that check did pass a bunch of times and i did get strings out of it
23:07 timotimo so either they were all SVal or i was doing it right
23:07 timotimo did you see the error message it generates?
23:07 jnthn Well, if you want simple, then the easier thing to do is to transform them into QAST::Var attribute nodes and just call .as_mast
23:07 jnthn And a QAST::Op bind with ah QAST::Var attribute node within it for the other way around.
23:08 timotimo while compiling op bindattr something something register type 2 something something
23:08 jnthn *an
23:08 jnthn I suspect that's a reference to #define MVM_reg_int16           2
23:08 timotimo 09:47 < timotimo> i get "Error while compiling op bindattr_h: unhandled reg kind 2", which i can only  guess means i didn't supply the hint in the last argument correctly
23:09 timotimo ah, ok
23:09 timotimo that's what i tried to use IVal.new( :size(16), :value(...) ) for
23:09 jnthn Yeah, but that's a MAST::IVal and I don't think it knows what to do withthat...
23:09 jnthn At least, the auto-mapper probably doesn't.
23:10 timotimo hmm
23:10 timotimo so i may actually have to do the mast generation :\
23:11 jnthn No
23:11 jnthn Just map to QAST::Var with scope attribute
23:11 timotimo any code i could cargo-cult?
23:11 jnthn And then tweak the code in "elsif $scope eq 'attribute' { ..." to do the hint lookup
23:12 timotimo oh, i think i kind of understand now what you mean
23:12 jnthn Not right off...
23:12 timotimo but i don't know where the binds would belong
23:12 jnthn Though various things do $qastcomp.as_mast...
23:13 jnthn Oh, $!foo = 42 normally becomes like QAST::Op.new( :op('bind'), QAST::Var.new( :scope('attribute'), ... ), ...AST for 42... )
23:13 jnthn Rather than an nqp::bindattr
23:14 jnthn Thus why I was suggesting updating the QAST::Var case first. 'cus you'll cover a bunch of the cases.
23:14 timotimo ah
23:14 timotimo and then i can transform bindattr to the $! form as well
23:14 timotimo yeah, that makes sense
23:15 timotimo i'll still need the hintfor op in the stage0, though
23:15 timotimo mind if i commit a stage0 update? or is there something i should wait for?
23:15 jnthn Yeah, you need a stage0 update for that...
23:15 jnthn No objections.
23:16 timotimo if you want some other op crammed in there, go ahead :P
23:16 timotimo because stage0 updates are always so big :(
23:19 jnthn Yeah, though they're getting smaller... :)
23:20 jnthn Except when we make NQP bigger :)
23:20 timotimo still i have to commit all the stage0 files if i just want one little added op
23:21 jnthn true
23:47 jnap joined #moarvm

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