00:13 FROGGS[mobile] joined 00:50 jnap joined 01:25 ozmq joined 01:51 jnap joined 02:05 krunen joined 02:09 ozmq joined 02:20 ozmq joined 03:53 jnap joined 04:28 d4l3k_ joined 04:43 japhb_ joined 04:47 crab2313 joined 04:54 jnap joined 05:54 jnap joined 06:09 krunen joined 06:55 jnap joined 07:56 jnap joined 08:57 jnap joined
FROGGS o/ 09:18
timotimo o/ 09:24
dalek arVM/varint: 1eb0650 | (Timo Paulssen)++ | src/6model/serialization.c:
an implementation of varint reading/writing
 09:38
09:57 jnap joined
nwc10 japhb_: first thought - "don't know" 10:44
second thought, if "don't know" isn't good - write benchmarks in Moose. But make sure that everyone is happy that it's ideomatic efficient Moose
because Moose vs Rakudo is the first comparison to be made
(and perl6-m is getting close to Moose on *startup* time) 10:45
third thought: once Moose is done, or if someone else wants to do it, also writing the code as "native" Perl 5 OO would be interesting too. (Not ugly hack micro-optimised code)
but that's as much for a benchmark comparison of Moose to "native" as from Moose to Perl 6 10:46
but longer term, it's going to be interesting to see how perl6-m converges first on Moose startup performance, then on Moose runtime performance, and finally on "native" Perl 5
it may never get there, but I hope that that isn't the case
FROGGS I would be happy (very happy) if it would get close 10:47
nwc10 but to make sure that perl6-m wins, ensure enough benchmarks use Unicode code points > 256 :-)
FROGGS because I am more efficient in P6 than P5 nowadays 10:48
timotimo more efficient? as in lines of working code written or something? 10:49
FROGGS timotimo: no, there are less P6 lines in the end usually :o) 10:51
but time span is shorter to solve a problem in P6 compared to P5
(when I don't need non-existent modules, that is)
nwc10 jnthn: slow thing update (Should have been yesterday) 10:55
Stage optimize : 201539.280
been at least a day in the next stage
10:58 jnap joined
nwc10 also, will Moose and Perl 6 code look reasonably simlar? 11:06
er, similar
11:12 woolfy joined
tadzik a bit; mop code is a lot closer 11:14
(stevan's p5mop)
timotimo yo tadzik :) 11:16
is the pod table replacement code still on the agenda? :)
jnthn nwc10: slow indeed! 11:18
nwc10: But no crash yet :)
tadzik timotimo: I guess :) I'll look through it today 11:19
timotimo since it garbage collects so often, the memory usage is probably really low! :P 11:20
okay gotta run catch a train
jnthn also goes to the station to go to the airport to go to the land of the fjords... 11:22
&
tadzik _another_ land of the fjords? :P 11:37
nwc10 well, I guess that southern Sweden considers northern Sweden to be the same country
11:38 tgt joined 11:48 vmspb joined 11:59 jnap joined
timotimo is working on varint support in the serializer 12:27
FROGGS is fixing a segfault in v5@moar
12:31 cognominal joined
timotimo oh? have you gotten past the repo conflict code already? 12:40
FROGGS timotimo: yes, was pretty easy actually 12:41
was just about six or seven lines of nqp-p code that wanted translating
and the currect segfault is just about moar being moar strict about stringifying than parrot 12:42
timotimo cool :)
FROGGS and moar segfaults when calling existskey on a null object, where parrot does not 12:43
timotimo i need to find more spots to put varint instead of int64/int32
FROGGS so, whatever I do to make it work under moar will alos be needed for jvm
nwc10 A further thought I had over lunch - I suspect that a "native" Perl 5 OO version of benchmarks would be very useful if it also runs under v5
FROGGS what does that varint actually do?
timotimo i wonder if i need to consider aligning for serialization? probably not. 12:44
FROGGS nwc10: to spot unreasonable slowdowns?
arnsholt timotimo: Yeah, serialization shouldn't need alignment
timotimo great
nwc10 FROGGS: not what I was thinking. Just would be curious to benchmark the exact same code running under v5 on MoarVM and the JVM as on the classic hairball. 12:45
timotimo unfortunately i don't know enough about the data structures to have a good idea where a varint is better than an int32 or regular int
like, the static sc id? 12:46
13:00 jnap joined
timotimo meh. so many things are calculating nonvariable entry sizes :/ 13:00
13:02 krunen joined
timotimo a few times i get "using varints saved us 0 bytes!" and then a segfault %) 13:07
FROGGS hehe 13:08
nice :o)
JimmyZ :-)
timotimo it asplodes in assert_can_read_varint 13:10
r: print 0x80.base(2)
camelia rakudo-parrot e51b6c, rakudo-jvm e51b6c, rakudo-moar e51b6c: OUTPUTĀ«10000000Ā»
timotimo aha. i never get "writing a varint array", but it does try to read a varint array 13:16
that doesn't s^Huqite make sense
Attempt to read past end of string heap (index 5632) 13:25
:(
14:09 jnap joined 14:15 odc joined 14:31 woolfy left 14:33 woolfy joined
timotimo success! 14:33
14:34 woolfy left
timotimo after spending the whole train ride fixing several off by ones and zeros 14:34
one file during the rakudo compilation said: using varints saved us 1317935 bytes in serialization
none of them give me a negative savings :))
using varints saved us 493557 bytes in serialization
that's the biggest winning file from nqp 14:35
14:35 woolfy joined
tadzik that's a full megabyte, nice :) 14:36
timotimo++ 14:37
dalek arVM/varint: e51cf28 | (Timo Paulssen)++ | src/6model/serialization. (2 files):
first step towards using varint in serialization.

serialize arrays of integers with varints as well as regular integers
timotimo i could already merge this, actually. but i'd prefer other people testing it a little bit first
total 4.8M ā† bootstrap files before rebuilding 14:39
total 4.2M ā† after 14:40
not absolutely stunning, but i wouldn't want to miss it :) 14:42
tadzik 13%-ish better, I'll take it :) 14:44
timotimo aye 14:49
moritz probably doesn't warrant a rebootstrap yet
timotimo 98680maxresident ā† say 1 right now 14:53
that's a tiny bit less i think
AFK for now 14:54
15:26 tgt joined 16:07 tgt joined
jnthn waves from Oslo 16:13
First weather this winter that's been cold enough to justify wearing my winter hat \o/
FROGGS \o/ 16:14
JimmyZ timotimo: there may be some s/int/varint/ in repr serialization/de-serialization too?
timotimo JimmyZ: maybe, yes. i'll have to make extra sure not to change them in places where the whole system expects a fixed length 16:15
or maybe change that together with the serialization/deserialization 16:16
jnthn timotimo: As a rule, anything in a segment described as data is a good candidate to apply varint to, and anything in tables is not.
timotimo: And I think all writes of data are done through the writer->function mechanism. 16:17
16:17 raiph joined
nwc10 jnthn: it's -8 here and snowing 16:18
jnthn nwc10: ooh
nwc10 and I think that this is the first day this winter that it's got that cold
jnthn nwc10: That'd qualify
nwc10: Exactly the same here, fwiw :)
It's not been this cold down in south Sweden...
16:18 jnap joined
FROGGS -11 and sunshine (in theory) 16:19
STable conflict detected during deserialization. 16:23
aww
jnthn FROGGS: If you're getting that on one backend but not another, then it's something wrong elsewhere 16:26
FROGGS jnthn: yeah, like twenty lines below the other one :o)
jnthn: the other bit is working, but I won't commit unless you had the chance to review the patch 16:27
until*
jnthn FROGGS: gist it, I had a good idea of what I expected to write...
FROGGS: It's one of those things where if things work it's probably right, and if it's wrong things probably SEGV... 16:28
FROGGS gist.github.com/FROGGS/cc7e4db40bd18c1aec66
JimmyZ good night 16:29
FROGGS gnight JimmyZ
jnthn FROGGS: copy_to is allowed to allocate, so you'll likely want to root backup too 16:30
FROGGS: And the type object thing matters.
FROGGS jnthn: yeah, I was not sure if it would allocate or not
ahh, k 16:31
jnthn FROGGS: I'd handle it by doing the current allocate/copy_to thing you do right now if it's not a type object
timotimo jnthn: i already added a write_varint function (as to not mess up tabular structures)
FROGGS jnthn: you can commit it if you want to btw
timotimo so i can 1) use it in reprs directly and 2) just set write_varint to write_int if the version number is too low
FROGGS (Justin Case) 16:32
jnthn FROGGS: If it is one then MVM_gc_allocate_type_object can be used
FROGGS: Hm, and should we be allocating the reposession conflict list... 16:34
I had thought that got passed in...
FROGGS jnthn: the last chunk of the patch allocates the list 16:35
jnthn yes, I know, I'm asking if it should 16:36
FROGGS: no, it souldn't
void MVM_serialization_deserialize(MVMThreadContext *tc, MVMSerializationContext *sc, MVMObject *string_heap, MVMObject *codes_static, MVMObject *repo_conflicts, MVMString *data) {
It should use the conflicts list that is passed in there
Otherwise it just drops the conflicts on the floor, rather than actually passing them off for resolution... 16:37
FROGGS ohh 16:39
timotimo ah. i just switched the NFAs over to varints 16:41
that ought to make a very big difference.
jnthn timotimo: oh, yes...very much so 16:43
timotimo i made many changes :) 16:47
also many in p6opaque
FROGGS jnthn: gist updated
timotimo things like storing a "0 or 1" in an int16 will now save yet another byte.
ah, i need fallback pointers for 32 and 16 bit integers that are to be read from a previous version 16:49
FROGGS damn, v5 forces me to implement openpipe 16:52
timotimo heh :) 16:53
17:14 tgt joined 17:15 krunen joined
FROGGS I am unable to provide a code without v5 that show the STable conflict 17:18
:o(
jnthn FROGGS: Well, the only way it should ever happen is if you do something like trying to load two modules that both augment a class in different ways 17:37
timotimo i've added varints throughout the reprs, but i seem to have missed something; i'm getting a segfault :\ 17:39
arnsholt jnthn: I had a thought about the way P6opaque lays out things in memory
D'you think it would make sense to order attributes so that they're in order of descending ALIGNOF? 17:40
IIRC we just do them in order of declaration ATM
It doesn't look like NQP or Rakudo use much in the way of int{8,16,32} or num32 ATM, but that'd cut some bytes off each instance in classes where they do get used 17:41
timotimo i think i found the issue and fixed it 17:42
we'll see :)
oh no :( 17:44
jnthn arnsholt: Well, at the moment we depend in some places on it laying things out in order 17:58
arnsholt Ah, right. What places depend on it? 17:59
jnthn arnsholt: There's two cases really. One is that in some C / Java code we hard-code some structs or hints to get at stuff. 18:01
arnsholt: Even if we fixed that, the hint mechanism means you would have to do it within a given class, not over all the fields of the object, otherwise the hints won't be single-inheritance stable...
arnsholt: One other consideration, mind, is that sometimes people who are thinking of performance will lay things out in a certain way deliberately, to put commonly accessed things together. 18:02
arnsholt: Many MoarVM structs are this way.
arnsholt jnthn: Right, so probably not worth it, at least not at the moment 18:18
18:21 V_S_C joined
V_S_C gist.github.com/VSChawathe/7c0c7f9f69e4b50e8b79 18:22
@jnthn this is with updated rakudo 18:23
18:23 tgt joined, V_S_C left 18:31 V_S_C joined
V_S_C The errors same as parrot 18:32
Only difference is with parrot backend it traced caller 18:34
FROGGS jnthn: I only augment classes in one module, this one indeed gets loaded, maybe even twice 18:36
timotimo i'm not exactly sure how to look for this error :/ 18:49
gist.github.com/timo/a711c8450a80683c94e6 ā† does this look busted? 18:50
FROGGS jnthn: the problem seems to be a custom postcircumfix declaration O.o
18:52 tgt joined
timotimo i think i'll push my changes to the branch and note that it segfaults 18:53
dalek arVM/varint: ce705b0 | (Timo Paulssen)++ | src/6model/reprs/ (5 files):
teach the 6model reprs about varints

this currently segfaults upon deserialization while building nqp.		 18:57
timotimo it seemed like i have replaced every write_int* with a write_varint and every read_int through a read_varint and every read_int* with an if/else to do the proper sized read or a varint read 18:58
but i must have missed something 18:59
maybe i wrote something variable-sized into a table somehow? 19:00
jnthn: maybe you'll see the probably obvious mistake i made when you come back from dinner :) 19:05
diakopter hi 19:07
diakopter updated vs2013
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64 19:08
19:09 jnap joined
timotimo diakopter: would you like to look at the varint branch? 19:16
diakopter well I finally realized how to do the profiler efficiently so let me finish that first
(yes I know I'm slow at design/problem solving) 19:17
timotimo cool :)
no, it's fine
19:23 tgt joined
timotimo i see nothing obvious, but maybe i'll find out what's wrong by putting lots and lots of ints through the serialization and back 19:50
diakopter :) 19:54
.oO( if only we had a way to deserialize stuff )
timotimo i wanted to do it inside gdb, but it doesn't seem to work properly
d'oh 19:55
i can just put a read directly after the write
oh, yeah 19:59
i did mess up
a whole lot.
jnthn Where does it segv? 20:03
timotimo it seems like i fail at writing out -1 20:04
diakopter jnthn: trying to decide where to put the profiling timestamp hooks - into MVM_args_setup_thunk or every ->invoke repr function 20:07
timotimo i might be messing up my negation mask
diakopter can't really put it in the frame creation/allocation
(I was assuming anyway) 20:08
jnthn diakopter: Why can't it go in MVM_frame_invoke? 20:09
timotimo wait a minute
where did my negation mask code go?
diakopter jnthn: well, sometimes the determination of which frame...
oh, I guess we'll just have to imagine that always as included in the parent.
jnthn timotimo: It met with negation unmask code and was anhiliated
diakopter or mask mask 20:10
moritz negation masak?
timotimo hehe 20:13
no, the negation mask code was on the read side
i was looking at the write side
turns out the write side wasn't the right side
diakopter you leftist 20:14
timotimo it's not so easy to get a bitwise print-out of a piece of memory it seems >_< 20:15
diakopter keep shifting by one and anding with 1
moritz timotimo: (s)printf %b ? 20:16
timotimo what, that exists!?!
okay. it turns out i had been looking at the *address* of the value i read, not the value itself
diakopter :)
timotimo m)
but 127 is still not -1 20:17
moritz timotimo: uhm, at least perl's sprintf understands %b :-)
timotimo yeah, it turns out the line of code i put in there at one point and then commented out was correct in the end 20:18
diakopter timotimo: of course, the fastest way is a lookup table of 65536 string representations of 16 bits 20:22
timotimo :D
sounds like a good idea
diakopter well, maybe 20:23
timotimo learns about git reset --patch and is quite happy
okay, the bootstrap files are now down to 4.0 mb instead of 4.8 with the varint stuff 20:26
and now i'll have a look at annotations
the stuff that gets read in dissect_bytecode, is it suspected to be of fixed length? doesn't seem so to me. it's probably one-per-file at the very start 20:29
huh, where does that stuff get written? 20:31
ah, i see, in serialization.c of course 20:34
er ... 20:35
"concatenate_outputs", eh?
jnthn timotimo: What are you looking for? 20:38
The stuff read in bytecode.c is written by mast/compiler.c
timotimo ... oh? 20:39
jnthn It's nothing to do with object serialization.
timotimo well, i was looking at concatenate_outputs and the dissect_bytecode function
which seem to be the two parts of the same piece of data
jnthn Which concatenate_outputs? 20:40
20:40 arnsholt joined
timotimo serialization.c 20:40
diakopter jnthn: should the continuations do anything to th etimings?
jnthn I suspect the code for emitting bytecode and serializing look superficially quite similar, probably 'cus they were primarily (at least originally) written by the same person.
timotimo but now i understand why it is the way it is
jnthn diakopter: Hmm... :) 20:41
diakopter: Distort them terribly, I should think :P
timotimo well, it's probably not too helpful to have varints there
at least compared to the amount of trouble it is :P
jnthn timotimo: No, I think the serialization stuff is most helpful 20:42
diakopter jnthn: well, I can make those pause 20:43
jnthn diakopter: That may be best.
timotimo jnthn: and annotations, yeah? 20:44
jnthn timotimo: Well, maybe annotations too...
timotimo: Thing is that if we make them more compact, we make them slower to access
I dunno what that means for diakopter++'s current work on profiling.
timotimo oh, annotations don't get deserialized?
they get mmapped, too?
jnthn timotimo: Yeah, mmap'd and only read on demand.
timotimo in that case i won't touch them
does a full rakudo compile suffice as a test if my serialization stuff is right? 20:45
does a spectest add anything of value at all?
diakopter yeah the annotations are, like highly optimally architected
jnthn timotimo: Please spectest too
timotimo will do
should i leave diagnostic code ifdef'd in the code? 20:46
jnthn timotimo: If you think we're likely to need it.
timotimo: Could leave if ifdef'd there for a while and leave a ticket to remove it in a month or two once we don't run into any issues with it :) 20:47
timotimo right 20:52
first i'm fixing my statistics
ah, haha 20:58
buckets 0 to 9, that's 9 bockets, no? :P
diakopter jnthn: I'm asserting that microsecond resolution is plenty :)
jnthn demands nanos! 20:59
:P
diakopter will there be invocations less than a microsecond?
jnthn At the moment? I rather doubt it :)
Was kidding about the nanos, in case it wasn't clear :) 21:00
diakopter hmm well I'll leave it nanos for now, even though many unices and windows don't even have nanos resolution
we'll see how fast the gigs grow
timotimo the vast majority of varints are 2 bytes or 1, a whole bunch are 3, some are 4 21:01
i've not seen any 8 or 9 byte sized varints during nqp compilation 21:02
diakopter 2 **32 nanoseconds should be enough for any invocation. oh wait.
well certainly 2**36 anyway
bah. 21:03
moritz 2**64-1 should be enough :-)
timotimo a few 5 byte big varints showed up just now during stage optimize 21:04
jnthn timotimo: I guess you mean the stage after optimize, when it actually serializes... :) 21:07
diakopter jnthn: what do I do with callsites that don't actually have callsites (the thunk things) 21:15
[where to mark that callsite as from]
jnthn diakopter: There's still always a callsite object...
diakopter yeah but
doesn't help the output data trace it back to anything
jnthn diakopter: Whenever we do one of those we set the return_address in the current frame before doing so. 21:16
Or am I missing the point?
The thunks don't really work too differently from any other invoke, though.
diakopter yes I'm just wondering how to represent it in the cachegrind visualization
jnthn Does it add value to, especially? 21:17
timotimo jnthn: er, of course
diakopter well I just need something other than [someplace on line 44 of xxx.nqp]
timotimo so, how do i interpret the output of rakudo's spectest now? >_> 21:18
jnthn timotimo: "is it different to before"? :) Or "is it different to daily roast" is a good approximation
timotimo i should try the latter
jnthn timotimo: If something fails that didn't in daily roast, you most likley busted something
diakopter jnthn: I just need some way to describe the callsite 21:19
jnthn diakopter: Would the kind of op that did it be any use?
diakopter: There's only so many ops that cause thunks...
diakopter bah, I'll just use current annotation 21:20
timotimo the output of daily roast has a different format from mine, so it isn't a straight diff
jnthn "From smrt_strngfy thunk" or so
timotimo: true
timotimo i'll just do a second run with master moar
diakopter yeah maybe
but we don't preserve the current op
well it could be re-derived. boo. 21:21
jnthn True 21:22
timotimo a full spectest run in 400 seconds is soooo nice 21:26
even on my laptop
diakopter when it gets to 100 seconds it'll be even nicer 21:28
timotimo not a single new failure in S01-S10 21:29
jnthn timotimo: Any chance you could time startup with and without the changes too? 21:31
timotimo well, spectests took 9 seconds less 21:32
but i listened to music during the second run
jnthn timotimo: with them?
timotimo one second. 21:33
dalek arVM/varint: eb8dc90 | (Timo Paulssen)++ | src/6model/serialization.c:
turns out this is actually needed
timotimo without varints, it's about 0.20 seconds, so it's hardly measurable :) 21:34
well, almost exactly 0.23s elapsed
jnthn: there is no measurable difference in startup time, but the maxresidentk for -e "say 1" went from always above 100_000k to never above 100_000k 21:41
jnthn \o/
Win, then.
timotimo more precisely: from never below 100_200k to never above 98_000k 21:42
jnthn A 2.2MB saving. Nice.
timotimo do i have the captain's permission to perform the merging maneuver?
except i called them varint128, which is wrong 21:45
hm, actually
jnthn timotimo: Are you confident there's no way to feed crafted input to the varint decoder that will cause a buffer overrun?> 21:46
timotimo p: say 7 * 9
camelia rakudo-parrot c2982d: OUTPUTĀ«63ā¤Ā»
timotimo i think i need to give it special treatment for "there have already been 8 bytes"
because then the 8th bit of the last byte must be used as number data rather than a flag wether or not to continue
p: say 7 * 8 + 8
camelia rakudo-parrot c2982d: OUTPUTĀ«64ā¤Ā»
timotimo then it checks out again
tadzik timotimo: where is the tables patch? 21:48
timotimo tadzik: you did look at my pod stuff!
i gave it to you and deleted all my copies forever!!!!!k
tadzik timotimo: I did
noooo
timotimo nah, it's still somewhere
tadzik I hope you're kidding :P
timotimo let me dig.
tadzik gah, rong channel again :) 21:49
timotimo tadzik: gist.github.com/timo/6132249 22:00
tadzik *whew*, saved :) 22:02
diakopter jnthn: gah, all the various ways of leaving a frame 22:03
timotimo jnthn: i don't think we've got a sufficiently big number to test the serialization "in the wild", so i'll write a module with big numbers in it :) 22:04
22:06 krunen joined 22:11 jnap joined
diakopter jnthn: what to do with multi-shot 22:12
dalek arVM/varint: 6bb4d26 | (Timo Paulssen)++ | src/6model/serialization.c:
special treatment for the last byte

we need that to reach full 64 bits, otherwise we are short exactly one bit.
and in the 9th bit we already know we're going to stop reading anyway.		 22:13
jnthn diakopter: All the ways of leaving a frame converge on remove_one_frame though :) 22:15
diakopter: We don't use multi-shot anywhere in Rakudo
timotimo dang, i segfault'd again :|
diakopter except continuation
jnthn diakopter: Our continuations are one-shot
diakopter: uh, sorry 22:16
diakopter doesn't go through remove_one_frame
timotimo i'll finish this up after sleep &
diakopter timotimo: 'n
jnthn diakopter: Our continuations in theory support multi-shot, but they are only used as one-shot
diakopter: Right, we don't leave the frame in any sense
it's just no longer in the current caller chain.
diakopter yeah but I need to pause the timers
ish 22:17
hm, can time it in the continuation object itselr
itself
jnthn We walk over all the frames we're suspending in continuations.c at some point, I think
So could stop them there maybe
timotimo for the record 22:21
writing a normal script to a .moarvm file with --target=mbc --output=foobar.moarvm and then replacing the last piece of the perl6-m runner with that foobar.moarvm should work, yeah? 22:22
huh. that doesn't even write a single varint128
jnthn timotimo: should 22:23
timotimo it also doesn't write out the summary of bytes saved and usages per bucket in serialization
... oh wait ...
i'm confused
huh 22:24
diakopter jnthn: but.. cloning frames...
jnthn diakopter: the continuationclone op?
diakopter: Pretend it ain't there. Again, never actually comes up in Rakudo.
diakopter why wouldn't cloning frames imply multi-shot
oh
jnthn diakopter: When sorear++ did the continuations stuff for JVM, he made rather more work that we actually needed for gather/take in Rakudo. 22:25
diakopter oh
timotimo i still kind of wish we could serialize away continuations :|
jnthn diakopter: I ported the stuff we really need carefully, and the rest is... <handwave>
:)
timotimo: In theory we could implement that in Moar. In practice, arrrghhh my brane. :) 22:26
timotimo jnthn: did i tell you how much i enjoyed using nagare in pythonland? they use stackless python's serializable continuations to freeze and thaw user sessions to an external database if they've been unused for a bit 22:27
jnthn timotimo: How does that interact with deploying an updated version of the application?
timotimo you restart it and wipe the sessions
jnthn Figured as much... :) 22:28
timotimo it's still a cool mechanism for that kind of idea
because now you can write your logic as a coroutine and have it persist between sessions without having to be kept in the process' ram
displaying two forms that ask for integers and showing one more page to display the result of the number's sum is just like show_result(ask_integer() + ask_integer()) 22:29
A-HA! 22:32
it segfaults even on moarvm master
so my code is not at fault!
jnthn: i think my branch is now ready to be merged. 22:33
jnthn timotimo: How did you segfault it,ooc?
timotimo: Can you file an issue on it? 22:34
timotimo: +1 to merge, it seems like an improvement without any real drawbacks
timotimo echo say "hello world"; >> othertest.pm
perl6-m --target=mbc --stagestats --output testlib.moarvm othertest.pm 22:35
/home/timo/perl6/rakudo/../install/bin/moar --libpath="/home/timo/perl6/rakudo/../install/languages/nqp/lib" --libpath="/home/timo/perl6/rakudo/../install/languages/perl6/lib" --libpath="/home/timo/perl6/rakudo/../install/languages/perl6/runtime" testlib.moarvm
jnthn ah, ok
Could be a null thing
timotimo gist.github.com/timo/b7ee0a68eb7d819e57e8
jnthn Loads of test failures seem to be to do with char lookup by name 22:36
FROGGS jnthn: yes, at a given point the name lookup start spitting out wrong codepoints (with a small but increasing offset) 22:39
dalek arVM/varint: cc57bd4 | (Timo Paulssen)++ | src/6model/serialization.c:
varint128 is a bogus name, since it's 9bytes max.
 22:40
arVM: 1eb0650 | (Timo Paulssen)++ | src/6model/serialization.c:
an implementation of varint reading/writing
 22:42
MoarVM: e51cf28 | (Timo Paulssen)++ | src/6model/serialization. (2 files):
MoarVM: first step towards using varint in serialization.
22:43 dalek joined
diakopter FROGGS: the problem is not just the name lookup; it's also property lookup of those same codepoints 22:49
jnthn OK. Fixing it will cut our failures about in half, anyways... :) 22:52
Time for some sleep here...teaching tomorrow
o/

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!