00:01 jnap joined
FROGGS diakopter++ # that looks promising! 00:20
diakopter FROGGS: well, it passes 4 more 00:21
but.. bleh.
I expected it to pass more
jnthn diakopter++ # moar hacking
diakopter FROGGS: I couldn't tell which of your changes you wanted merged 00:22
:S
00:42 colomon joined 01:02 jnap joined 01:13 jnap joined 04:13 jnap joined 05:14 jnap joined 06:14 jnap joined 07:15 jnap joined 07:26 lizmat joined, lue joined
JimmyZ E:\OpenSource\nqp>..\Moarvm\install\bin\moar.exe --version 07:52
This is MoarVM version 2013.10-386-g1a93bf0
E:\OpenSource\MoarVM\install\bin\moar --libpath=src\vm\moar\stage0 src\v
m\moar\stage0\nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc
--output=gen\moar\stage1\nqpmo.moarvm gen\moar\stage1\nqpmo.nqp
MAST::Local index out of range
jnthn: ^^
diakopter JimmyZ: almost certainly need to start from fresh, unfortunately 07:53
JimmyZ yes, it's fresh
moritz I get the same error on my raspberry pi (ARM processor) 08:01
08:16 jnap joined
FROGGS gah, I should reads comments 08:27
#?niecza 3 todo "Tests are wrong by latest Unicode standard"
I was trying to make these work >.<
diakopter oops
moritz fix the tests then :-)
FROGGS I will 08:28
timotimo i'm not actually sure, hint_for is implemented correctly 08:29
isn't the point of hint_for to pass a compile-time known type object and get a hint back?
oh, yes, and that's also how it's implemented %)
FROGGS diakopter: there are a lot of these comments in properties-general.t
diakopter oh :) 08:30
FROGGS no wonder we don't pass 'em :o)
diakopter I'm currently trying to figure out why this:
m: say "\c[FULLWIDTH RIGHT PARENTHESIS]"
camelia rakudo-moar 912342: OUTPUTĀ«ļ¼“ā¤Ā»
diakopter WRONG 08:31
m: say "\c[FULLWIDTH LEFT PARENTHESIS]"
camelia rakudo-moar 912342: OUTPUTĀ«ļ¼’ā¤Ā»
moritz offby20 08:32
diakopter m: say "\c[FULLWIDTH EXCLAMATION MARK]"
camelia rakudo-moar 912342: OUTPUTĀ«ļ¼‹ā¤Ā»
diakopter m: say "\c[FULLWIDTH RIGHT WHITE PARENTHESIS]" 08:33
camelia rakudo-moar 912342: OUTPUTĀ«ļ½Ŗā¤Ā»
diakopter m: say "\c[REPLACEMENT CHARACTER]" 08:34
camelia rakudo-moar 912342: OUTPUTĀ«š€‡ā¤Ā»
FROGGS diakopter: there must be something skipped in that names list, no?
diakopter something like that, yeah
it gets FFFD right 08:35
binary searching backwards
timotimo left an isconcrete(obj) in the op implementation for hintfor m)
diakopter m: say "\c[FULLWIDTH TILDE]"
camelia rakudo-moar 912342: OUTPUTĀ«ļ½Øā¤Ā»
diakopter gah 08:36
FROGGS mp: say "\c[FULLWIDTH TILDE]".ord
pm: say "\c[FULLWIDTH TILDE]".ord
r: say "\c[FULLWIDTH TILDE]".ord
camelia rakudo-parrot 912342, rakudo-jvm 912342: OUTPUTĀ«65374ā¤Ā»
..rakudo-moar 912342: OUTPUTĀ«65384ā¤Ā»
FROGGS r: say "\c[FULLWIDTH RIGHT PARENTHESIS]".ord 08:37
camelia rakudo-moar 912342: OUTPUTĀ«65299ā¤Ā»
..rakudo-parrot 912342, rakudo-jvm 912342: OUTPUTĀ«65289ā¤Ā»
FROGGS k, no hole between those two
moritz holey shit :-)
diakopter oh, I bet I know what it is
I hardcoded some boundary; checking
FROGGS btw, when we fix the test to comply with latest unicode, that will mean that perl6-p drops to like 98% 08:41
and even more when the names list is fixed 08:42
diakopter :/
FROGGS this could mean that moar passes moar tests by then
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?
diakopter sure 08:43
moritz well, if fixing tests causes the perl-p numbers to drop, then the current numbers are bogus anyway
diakopter right, but the change obscures the remaining amount
moritz then compare to perl-j instead :-) 08:44
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:46
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:47
i tried passing a QAST::IVal.new( :value($hint) ) where $hint is declared as my $hint 08:48
er, my int $hint
diakopter IVal takes a bit width param I think
timotimo ah, let me have a look 08:49
maybe it does on moar?
yeah, it does
tanks
ah, MAST::IVal takes that, but QAST::IVal doesn't 08:50
diakopter yeah
timotimo tries to plop the MAST::IVal directly into the QAST
diakopter funny thing is it might work 08:51
timotimo it better work! :)
nope, still get the "unhandled reg kind"
but isn't 2 string?
diakopter nopaste your diff?
timotimo it contains a bootstrap update :P 08:52
diakopter gah
timotimo gist.github.com/timo/e45ca59d78a0165560cf 08:53
perhaps i have to switch out the string register for a string constant somehow? but it's already an SVal in the QAST
diakopter you didn't push the attrname to oplist 08:55
timotimo i ... didn't have to? 08:56
diakopter oh
why does $op[1] need to be a WVal 08:57
timotimo the class could be supplied dynamically
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
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)
diakopter but it may not be a string yet 09:01
timotimo ... huh?
diakopter it may be a qast expression
right?
timotimo hm, doesn't the "S" slot of a Want contain a literal string in all cases?
diakopter oh, I didn't know 09:02
do you have an updated diff? 09:03
timotimo nqp::splice(@oplist, [QAST::SVal.new( :value($attrname) )], 2, 1);
this is the line i added to the if $hint != -1 section
diakopter why splice 09:04
@oplist[2] =
timotimo oh 09:09
haha :)
well, it doesn't fix it anyway :( 09:16
09:17 jnap joined
dalek arVM: b3a845d | jimmy++ | src/6model/reprs.c:
removed needless header file
 09:31
FROGGS r: say "MUSICAL SYMBOL BEGIN BEAM" 09:42
camelia rakudo-parrot 912342, rakudo-jvm 912342, rakudo-moar 912342: OUTPUTĀ«MUSICAL SYMBOL BEGIN BEAMā¤Ā»
FROGGS r: say "\c[MUSICAL SYMBOL BEGIN BEAM]"
camelia rakudo-parrot 912342: OUTPUTĀ«š…³ā¤Ā»
..rakudo-jvm 912342: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/OwRAhscyyhā¤Unrecognized character name MUSICAL SYMBOL BEGIN BEAMā¤at /tmp/OwRAhscyyh:1ā¤------> say "\c[MUSICAL SYMBOL BEGIN BEAMā]"ā¤Ā»
..rakudo-moar 912342: OUTPUTĀ«ō€Øµā¤Ā»
FROGGS r: say "\c[KAITHI NUMBER SIGN]" 09:43
camelia rakudo-parrot 912342: OUTPUTĀ«š‘‚½ā¤Ā»
..rakudo-moar 912342: OUTPUTĀ«š‘ƒ‡ā¤Ā»
..rakudo-jvm 912342: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/96Ky0BYHbsā¤Unrecognized character name KAITHI NUMBER SIGNā¤at /tmp/96Ky0BYHbs:1ā¤------> say "\c[KAITHI NUMBER SIGNā]"ā¤Ā»
diakopter sigh
FROGGS r: say "\c[SYRIAC ABBREVIATION MARK]"
camelia rakudo-parrot 912342, rakudo-jvm 912342, rakudo-moar 912342: OUTPUTĀ«Üā¤Ā»
FROGGS diakopter: about <:Format> see github.com/perl6/roast/commit/0791cdfd50 10:08
perl6-m matches everything for <:Format>
because its property value code is 0 10:09
r: say "ohh?" ~~ /<:Format>+/ 10:11
camelia rakudo-moar 912342: OUTPUTĀ«ļ½¢ohh?ļ½£ā¤ā¤Ā»
..rakudo-parrot 912342, rakudo-jvm 912342: OUTPUTĀ«Nilā¤Ā»
10:18 jnap joined
FROGGS ohh well, HEAD does it correct 10:23
diakopter ? 10:24
FROGGS locally <:Format> does not everything 10:26
and it passes the (fixed) tests 10:27
jnthn JimmyZ: Well, I can't do much about it with just that error... 10:45
JimmyZ: Is it a 32-bit build? 10:47
10:56 odc joined 11:18 jnap joined
JimmyZ jnthn: win7 32bit 11:54
jnthn JimmyZ: OK, I suspect the 32-bit... 11:55
JimmyZ missing MVMROOT somewhere? ;) 11:57
jnthn Unlikely given the error 11:58
FROGGS should the 32bit issue we have since MVM's announcement 12:32
jnthn 32-bit Windows, but not 32-bit Linux, iirc? 12:34
moritz oh, maybe the build fails on the RPi because it's 32 bit 12:38
not because it's ARM
jnthn Maybe it's that, yeah... 12:39
FROGGS: Did you say there was an "unlink sometiems fails" bug? 12:40
FROGGS jnthn: must be, because files created during spectest are not deleted 13:10
I can't remember though what was wrong 13:11
13:20 jnap joined
jnthn Well, I'd screwed something else up, so... :) 13:22
Been investigating the performance issues that grondilu++ reported.
And the profile it led to
Found some messed up closure handling.
And fixing the code-gen. 13:23
So we can turn on caching any autoclose we do.
13:27 woolfy joined
dalek arVM: 02585d1 | jnthn++ | src/core/frame.c:
Cache auto-close result.
 13:35
jnthn Oh...we were doing re-use of callsites by *frame* when it should be by compunit. 13:45
29KB saving on CORE.setting.moarvm 13:51
dalek arVM: 343c623 | jnthn++ | src/mast/compiler.c:
Callsites should be per compunit, not frame.
 13:52
JimmyZ jnthn++ 13:56
dalek arVM: cc82df7 | jnthn++ | src/io/fileops.c:
Don't stat non-file handles.
 14:04
jnthn oh, argh, that won't help... 14:10
14:20 jnap joined
masak why not? 14:27
jnthn Well, for one 'cus I misread the code and look at junk memory... 14:32
Well, may have a hack now that gets us at least a basically working repl 14:34
Which is much better than segv
At some point I need to give the IO stuff a serious look over, though. 14:35
14:44 jnap joined
dalek arVM: aa79dda | jnthn++ | src/io/fileops.c:
Some hacks to unbust the REPL.

Need to revisit both of these, and IO in general, but this gives a much better user experience than SEGV...		 14:50
timotimo jnthn: was the callsite caching thing what caused coroutines to inflate the stack? or is that fix still coming up? :) 15:10
jnthn timotimo: No, the callsite caching was just a small inefficiency 15:12
timotimo: Though I plan to more fully intern them at some point in the future, so it kinda helps towards that.
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? :)
jnthn Well...it'd be nice to if possible
jnthn is still trying to fully understand where things go bad
timotimo i'll let you get to it then :) 15:14
jnthn ah, I think I may see... 15:15
yeah... 15:16
I don't see a way of fixing it without doing at least something on each backend. 15:34
timotimo well, at least you now know what's up :) 15:35
jnthn Yeah. Now to see which of the two candidate fixes is easiest... 15:38
timotimo that will be a nice changelog entry. 15:40
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:48
jnthn timotimo: I've done that twice before, so yeah, can do :) 15:50
timotimo \o/ 15:51
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
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:52
dalek arVM: 7a9e60f | timo++ | README.markdown:
removed "moar-support" from README.
 15:55
jnthn timotimo: Did you do the typical case with optimizing QAST::Var attribute access yet? 15:58
timotimo i don't know about that
jnthn didn't realize we had a bindattr_h...
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
are you sure? i thought i implemented that for parrot
let me check
jnthn Oh, maybe...
I don't think registering a getattr_h or so is really the way to go, though.
timotimo yeah, i did that
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:00
oh wait, there's something wrong 16:01
i add a core_pirop_mapping for bindattr_s and then add_core_op for the same thing 16:02
16:42 lue joined 17:02 lue joined
dalek arVM: c417239 | jnthn++ | src/core/continuation.c:
Allow continuationreset to be given a continuation

It then invokes it, rather than invoking a code ref. This is ideal for Rakudo's needs when implementing gather/take as it avoids adding an extra stack frame every time we take.		 17:03
jnthn bah, we had a major memory leak 17:40
diakopter oh?
dalek arVM: 27d285c | jnthn++ | src/6model/reprs/P6bigint.c:
Free memory associated with bigints.
 17:42
17:43 jnap joined
jnthn Funny thing is our max memory in spectest *while leaking all the Ints* was lower than the Parrot max... 17:44
moritz lol
diakopter well how many Ints was it using 17:45
I doubt a ton, right?
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.
moritz that was my doing, I'm sure :( 17:46
diakopter no probably mine 17:47
jnthn Well, I found it 'cus I've been looking at memory usage a bit 17:55
I'm doing some GC tuning.
(Nursery size and gen 2 collection interval)
Anyway, in the run I just did, I didn't see any test go above 250MB or so.
That was one of the hefty S05 ones. 17:56
Most are barely over 100MB.
timotimo this is all excellent news 18:02
jnthn I may have some more excellent news coming up in a moment.
timotimo i think i should push my bindattr/getattr work into a branch 18:06
also, i think access to private vars is handled through the getattr and bindattr ops already behind the scenes
i *think*
18:06 benabik joined
dalek arVM: e83e725 | (Timo Paulssen)++ | / (6 files):
expose the hintfor op
 18:09
jnthn OK, so... 18:10
I jsut did some analysis/tweaking of GC nursery size and how often we do full collections
We're die-young heavy
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?
diakopter jnthn: you gonna make objects live 3 nursery collections? 18:11
jnthn diakopter: No
Just tweaking nursery size and full collection rate
I got our stage parse down to about 4-5 seconds longer than JVM.
And spectest down to 362s
diakopter which is what % faster than before
tadzik { my $good } # only the good die young 18:12
jnthn It's 49s now compared to 70s before
timotimo that sounds crazy good!
how many more cheap wins are there to be had in the near future? :D 18:13
jnthn 362s spectest vs 451s before
timotimo \o/
jnthn I watched memory use and it was very little difference between these options.
CORE.setting is still well under 900MB here, highest I see in spectest is a bit over 250MB 18:14
tadzik sweet
dalek arVM: dc71ae4 | jnthn++ | src/gc/collect.h:
Tweak GC nursery size and full collection rate.

Based on considering Rakudo spectest and setting build time/memory.		 18:16
jnthn Sanity test is now always consistently coming within 3s. I just got it to report 2s. o.O 18:19
timotimo that's Cray. 18:20
tadzik :>
jnthn++
FROGGS yeah! it is soo much fun to read backlog here! 18:23
(and in the channel nearby)
timotimo :D 18:24
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ā¤Ā»
timotimo that's absolutely lovely 18:31
tadzik changes rakudobrew to --gen-moar=master 18:32
FROGGS see^^ I mean news like these :o)
FROGGS is happy, verry happy
-r
tadzik "Your move, Parrot" 18:33
Moar is a dream come true
FROGGS tadzik: they are going to release 6.0.0 in a few days
tadzik FROGGS: oh, have there been commits?
indeed
FROGGS rurban++ did some, yes
timotimo what's cool & new? 18:34
tadzik test and docs fixes, as I see
and some fixes for tests :)
timotimo oh well.
FROGGS like for the unicode vowel thingy that libicu did to us :o) 18:36
timotimo that sounds good 18:37
tadzik uh 18:39
r-m: say $*VM<name>
camelia rakudo-moar 8c054a: OUTPUTĀ«moarā¤Ā»
tadzik oh
dalek arVM: 865d077 | (Tobias Leich)++ | tools/ucd2c.pl:
fix swapped params of register_gc_alias

This actually sets properties like 'L' if the codepoint is a Lu|Ll|...		 18:41
18:44 jnap joined
_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 :)
please try it out :)
hell, I'll even open it for bug reports
[Coke] today's run will have 11 more passing spec tests than yesterday. 19:41
19:44 jnap joined
[Coke] ... but apparently run muuuuch faster. :) 19:46
19:52 Guest1338 joined
dalek arVM: 839dafe | (Tobias Leich)++ | / (3 files):
add lookup for property value codes of unions
 20:20
jnthn FROGGS: oooh...is that what I think it is? :) 20:23
FROGGS jnthn: a few test more :o) 20:24
jnthn Does it make <:L> work?
FROGGS 21 to be exact
yes
<:L> does work, but the alias <:Letter> does look in the wrong direction atm 20:25
going to fix that now
jnthn Right, but <:L> working means wordcase will now work.
FROGGS true
jnthn Which will unbust capitalize.t and substr.t, I think.
jnthn pulls and sees
FROGGS $ perl6-m -e 'say "Right, but <:L> working means wordcase will now work.".wordcase'
Right, But <:L> Working Means Wordcase Will Now Work.
\o/
jnthn \o/ 20:26
FROGGS: Yup, wordcase and substr fails gone \o/ 20:28
FROGGS++
FROGGS cool!! 20:29
jnthn So 10 more passes from there too
timotimo i'm back, what did i miss? :) 20:38
jnthn <:L>
timotimo cool! 20:39
dalek arVM: b1d5b51 | benabik++ | build/ (2 files):
Split out Moar-specific ld flags

Specifically splits @ldshared@ into @ldshared@ and @moarshared@.
The difference is that @ldshared@ includes flags that should be used to create shared libraries by users of Moar, but @moarshared@ includes flags that should only be used when building Moar itself.
This includes the -install_name flag on OS X and the /implib flag on Windows.		 20:44
20:45 jnap joined
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
I moved the /implib flag because it got filtered out by Rakudo.
timotimo benabik: does that fix moarvm building on osx? 20:49
benabik timotimo: It's half of it.
timotimo fair enough :) 20:50
thank you
benabik timotimo: Rakudo PR#238 is the other half, BTW. 21:05
21:29 colomon joined
timotimo bisects the optimizers that kill moarvm 21:32
21:46 jnap joined 22:00 diakopter joined
timotimo no actual bisecting has happened yet 22:01
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.
FROGGS .oO( and over and over again :o) 22:14
timotimo -falign-jumps may be the offender here 22:23
it plays together with some other flag to cause the error 22:24
timotimo bisects 22:25
something is causing the REPR to have bogus function pointers in it 22:35
dalek arVM: bec8322 | (Tobias Leich)++ | / (3 files):
consistently emit aliases but not duplicates
 22:36
jnthn bah, no win. 22:41
Can't win 'em all... 22:42
FROGGS :(
looks like we won enough for today :o) 22:43
jnthn Yeah
Was looking into killing off or changing the role of the refs_frames thing.
But the simple non-solution I came up with causes epic leaks. 22:44
FROGGS :/
jnthn (yes, it's clear enough to me why)
(but means the real solution is gonna be more involved) 22:45
22:47 jnap joined
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
timotimo so is there a keyword for gcc and other compilers to prevent "optimizing" the structs? 22:49
FROGGS has no idea 22:50
jnthn Is that not likely to be about the strict aliasing thing? 22:51
timotimo i passed -fno-strict-aliasing and it didn't help 22:53
the successor to moarvm (if there'll ever be one) should be named MoireeVM
FROGGS *g* 22:55
I'd call the successor SuccVM perhaps 22:56
timotimo may be a bit too punny
jnthn That names succs...
*name 22:57
timotimo jnthn: did you have a chance to look at my nqp diff for moar_precalc_hint?
jnthn timotimo: Not yet, been looking at the refs_frames thingy...
Though giving up on that today. It's kinda hard.
timotimo i don't know what that is, but okay :) 22:58
jnthn But really needs a good solution.
Well, it's the thing that's making GC runs a load more constly than they should be.
timotimo oh
that sounds like a good candidate for fixing then :)
jnthn Yeah, it is, it's just hard. :)
timotimo i'm thinking of writing a python script/"plugin" for gdb to enable things like reverse pointer lookups 22:59
("what keeps this MVMCollectable alive?")
anything in particular you'd like to see?
jnthn Hm...itneresting idea.
*interesting 23:00
Well, I'd like to see you write it without re-writing half of the Moar GC I guess ;)
Re-implementing, I mean. :)
You can probably re-use all the gc_mark stuff but just treat the worklist entries differently than the GC does I guess. :)
timotimo that was my first thought, aye 23:01
jnthn It should be do-able.
But question is how you'll represent the result
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
jnthn Yeah...
There's a gc_seq_number
timotimo that's the one
jnthn You can increment the one in instance
timotimo and i was afraid it could make the rest of moarvm confused
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
but not right now :P
jnthn :P
+ if nqp::istype($node, QAST::Want) && $node[1] eq 'S' { 23:04
I think that it actually shows up as Ss
Hmm...I don't think I'd do it by the nh and h variants 23:05
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.
timotimo yeah, but that's not easy
jnthn It's not so hard either
timotimo i have to sometimes decont, sometimes not, i have to return the third argument or not
jnthn It's a lot simpler than many of the other ops we do.
timotimo fwiw, that check did pass a bunch of times and i did get strings out of it 23:07
so either they were all SVal or i was doing it right
did you see the error message it generates?
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
And a QAST::Op bind with ah QAST::Var attribute node within it for the other way around.
timotimo while compiling op bindattr something something register type 2 something something 23:08
jnthn *an
I suspect that's a reference to #define MVM_reg_int16 2
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
ah, ok 23:09
that's what i tried to use IVal.new( :size(16), :value(...) ) for
jnthn Yeah, but that's a MAST::IVal and I don't think it knows what to do withthat...
At least, the auto-mapper probably doesn't.
timotimo hmm 23:10
so i may actually have to do the mast generation :\
jnthn No 23:11
Just map to QAST::Var with scope attribute
timotimo any code i could cargo-cult?
jnthn And then tweak the code in "elsif $scope eq 'attribute' { ..." to do the hint lookup
timotimo oh, i think i kind of understand now what you mean 23:12
jnthn Not right off...
timotimo but i don't know where the binds would belong
jnthn Though various things do $qastcomp.as_mast...
Oh, $!foo = 42 normally becomes like QAST::Op.new( :op('bind'), QAST::Var.new( :scope('attribute'), ... ), ...AST for 42... ) 23:13
Rather than an nqp::bindattr
Thus why I was suggesting updating the QAST::Var case first. 'cus you'll cover a bunch of the cases. 23:14
timotimo ah
and then i can transform bindattr to the $! form as well
yeah, that makes sense
i'll still need the hintfor op in the stage0, though 23:15
mind if i commit a stage0 update? or is there something i should wait for?
jnthn Yeah, you need a stage0 update for that...
No objections.
timotimo if you want some other op crammed in there, go ahead :P 23:16
because stage0 updates are always so big :(
jnthn Yeah, though they're getting smaller... :) 23:19
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
jnthn true 23:21
23:47 jnap joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!