00:15 vendethiel joined 01:06 vendethiel joined 01:52 vendethiel joined 02:24 jimmy_ joined
jimmy_ timotimo: I think it's not a small project, since it maybe needs ssa form to do better static optimization, maybe I'm wrong :) 02:28
timotimo no clue 02:59
jimmy_ timotimo: btw, did you see the esc paper? 03:02
timotimo: I think you may be interested with it :P
timotimo i shall have a look
after bedtime :)
jimmy_ the link is in #perl6 03:03
timotimo i recall :)
jimmy_ good night :)
timotimo i think you overestimated the scope of what i was suggesting above
jimmy_ maybe ...
timotimo all i meant was to look at the code-gen in the QASTCompilerMAST to see why it emits a set after every wval, many getlex-like operations etc etc 03:04
you could moar --dump CORE.setting.moarvm | grep -B 1 'set '
jimmy_ oh, I will give it try, but with no guarantee 03:05
timotimo OK
do you know of the "result_reg" mechanism the InstructionList class uses?
jimmy_ yeah, I have tried it a bit long long ago, but I can't find where are they from :( 03:06
and it can't reuse the reg , IIRC 03:07
timotimo each piece of as_mast will usually allocate a result_reg or get one passed from its caller
not 100% sure
jimmy_ and we maybe needs vanilla reg allcation
timotimo also, there's more uses of InstructionList in rakudo's moar/Perl6/Ops.nqp 03:08
i'm off now for reals :) 03:10
06:27 jimmy_ joined 07:21 FROGGS joined 07:31 oetiker joined 07:46 zakharyas joined 08:11 zakharyas1 joined 08:49 vendethiel joined
dalek arVM: 650333f | TimToady++ | src/6model/reprs/NFA.c:
trap epsilons to 0

The NFA construction code could accidentally introduce a state with no edges, which under epsilon removal produced an epsilon that forwarded to state 0, which doesn't work so well. This bug is now fixed, but until we rebootstrap, we rely on moar's NFA to ignore null epsilons for later stages optimizing earlier stages' NFAs.		 09:12
09:21 woolfy left 09:45 vendethiel joined 10:21 vendethiel joined 11:11 vendethiel joined
nwc10 ug, I seem to be able to get NQP test hangs on Ubunut 13:28
(this is not "my" machine, which is Centos, but my work desktop)
hang is zombie sh process, MoarVM stting in
epoll_wait(5,
and I really don't have time to debug this
but just reporting it, in case folks know why
jnthn Not seen that, but do yuou know which teste? 13:44
nwc10 t/nqp/19-file-ops.t t/nqp/78-shell.t t/nqp/86-pipes.t 13:46
jnthn EIOIO
14:14 vendethiel joined 14:42 dalek joined
timotimo jnthn: what MAST op (or alternatively QAST op) do i use to pre-size an array before pushing a known number of items into it? 15:12
jnthn setelems iirc
timotimo thanks
the code that emits the string heap in bootstrarray form could probably benefit from pre-sizing 15:13
the code that calls getcode on a whole bunch of things and pushes them into a list could probably benefit, too
jnthn: can you explain what $newer is supposed to do here? github.com/perl6/nqp/blob/master/s...T.nqp#L514 15:16
oh
it's probably there to assure that the return value of the generated instruction list is the list 15:17
15:17 JimmyZ_ joined
jnthn timotimo: yes, exactly that 15:19
Not a great name
timotimo i may touch it up
15:37 vendethiel joined
nwc10 oooh, Racy :-( 15:57
in static MVMint64 eof
if (data->filename) {
...
bad idea. Really always fstat the filehandle.
16:11 dalek joined 16:22 vendethiel joined 19:07 FROGGS joined 19:28 lizmat joined 19:38 dalek joined 19:42 dalek joined
dalek arVM/6pe: 62387b8 | jonathan++ | docs/6model-parametric-extensions.markdown:
Start documenting the parametric 6model design.
 20:02
arVM/6pe: 4b59fbc | jonathan++ | / (6 files):
Stub parametricity-related ops.
arVM/6pe: 4ea8e4c | jonathan++ | src/6model/6model.h:
STable extensions for parametricity.
arVM/6pe: 8a433dd | jonathan++ | src/gc/collect.c:
GC marking for STable parametricity bits.
arVM/6pe: 31cf163 | jonathan++ | / (5 files):
Basic implementation of parameterization ops.

Start interning parameterizations.
jnthn Don't get excited, was just a rebase so I have it on top of something recent :) 20:03
FROGGS *g* 20:04
[Coke] awwwwww 20:07
20:08 dalek joined
jnthn did just write a couple more failing tests to try and make pass, though :) 20:08
FROGGS my goal for today is to do something for Perl 6 today... 20:09
did nothing for two weeks or so... at least it feels like it has been two week 20:10
s
jnthn I'd say "same", but I distinctly remember a train journey last Friday involving lldb and the OSX guardmalloc.. :P 20:11
TimToady hopes natives are still percolating in the hindbrane
nwc10 FROGGS: you helped me. That was doing something 20:12
jnthn Well, that's a bit part of what 6pe is working towards.
*big
FROGGS nwc10: yeah, but I feel the urge to git commit something:o)
jnthn I'd really like to do the native arrays on a better base than current types arrays are on (and clean up typed arrays in the process) 20:13
TimToady: Any further thoughts on the array (non-lazy, native) vs Array line of thinking?
TimToady doesn't object at all :)
jnthn We know native arrays need to have a different representation. 20:14
TimToady still seems like a reasonable distinction to me
jnthn OK
Will something like, "if the type you specify in my type @foo is a native one, then the default is array, not Array" rule be sane enough?
uh, so grammar... 20:15
TimToady we might be able to specialize some Array to array if we know thigns
jnthn I think it was understandable :)
TimToady uh, so spelling
yes, I'd expect native arrays to be native :)
and non-native arrays to be restless 20:16
jnthn OK 20:17
I'll head in that kinda direction and see where we end up :)
Still pondering a bit what the answer to @native-array.HOW.WHAT should be... 20:18
Though "ClassHOW" was a fine enough answer for the buf stuff.
nebuchadnezzar hello 20:24
maybe someone could update the homepage moarvm.org/ ?
jnthn Uh, maybe, yes... It's *two* releases behind... 20:26
D'oh.
20:36 dalek joined
FROGGS jnthn: we have a global symbol merger that runs when we deserialize, right? 21:18
TimToady
.oO(we just used to call that a "linker")
 21:31
FROGGS could have been called "rechter" too 21:33
jnthn: is that what I am looking for? MoarVM/src/6model/serialization.c:2418: work_loop(tc, reader); 21:55
timotimo isn't it repo_conf_res? 22:07
$repo_conf_res, FROGGS?
FROGGS timotimo: in MoarVM? 22:11
ahh, in nqp
have to sleep about that... gnight 22:13
22:30 vendethiel joined
jnthn .tell FROGGS no, we do the symbol merging in normal code, not inside of the VM, since the rules are down to the language. See merge_globals or so in the Perl 6 module loader, or NQPs one. Also, if there are deserialization conflicts, the language's module loader can resolve them too, which is the thingy timotimo pointed you at; that's separate. 22:34
timotimo OK 22:35
jnthn: when i talked about storing the serialized blob in "not base64" in the deserialize function you said something about utf8; how did you mean that? 22:36
jnthn Basically, a module puts the things it wants to contribute to the real GLOBAL into a lexical GLOBALish in UNIT
timotimo also: can our strings properly contain null bytes without stuff b0rking?
jnthn timotimo: There's a special section in the bytecode file for storing serialized data, so it doesn't matter what bytes it contains; it's not a string, it's just a load of bytes. 22:37
Our strings can contain null bytes just fine because they always carry length around with them.
timotimo well, that's not what i mean, though
jnthn I'm pretty sure in the string heap in the bytecode file the size is written, then the data, then some padding bytes 22:38
Also: phew, YAPC::EU and YAPC::Asia don't come way too close to each other this year. :) 22:40
timotimo deserialization_code starts out with my str $serialized := nqp::serialize($sc, $sh)
where $sh is apparently the string heap that's there "in code" 22:41
as in: the sh gets assembled as a nqp::list_s that gets every string push_s'd into it
jnthn Yes.
Those are taken from the bytecode file's own string heap 22:42
But yeah, it's a level of indirectin
It's not perfect
A declarative approach would be preferable
But it does keep two things at a distance from each other, which is a nice thing. 22:43
timotimo yeah, but what about the serialized blob that's put into the string heap as base64 coded serialization data?
jnthn I don't know why that's ever happening.
It shouldn't be.
Not ever on MoarVM or JVM.
timotimo maybe that comes from having another SC where we override stuff?
jnthn But it's about the currently compiling SC, or at least it should be. 22:44
If we're getting stuff in base64 in th estring heap on Moar, there's almost certainly a bug somewhere.
I can't easily imagine where, though...
timotimo if $comp_mode {
$block.push(self.deserialization_code($cu.sc(), $cu.code_ref_blocks(),
$cu.repo_conflict_resolver()));
} 22:45
that's the deciding factor whether or not to emit the code that does the base64 thing
jnthn No, it's not that simple.
timotimo the base64 decode is right at the beginning of dissect_and_somethingsomething_data
jnthn That's just "should we emit serialization stuff"
If it manages to store the serialization blob in a better way, it hands back a null string. 22:46
timotimo oh, i didn't know about that
jnthn Which in normal compilation it always should be.
timotimo i've seen a bunch of null_s where i would have expected the base64 blob to appear
jnthn Right, that's what should always happen.
timotimo looks closer
jnthn That is the "we stored it in the appropriate segment in the .moarvm file" indicator
So, the situations where we *don't* have that are the ones where something goes amiss. 22:47
timotimo i was expecting nqp::serialize to *always* hand back a base64 string if there's anything at all or otherwise a null_s
jnthn No, null_s means "look for it in the bytecode file segment"
timotimo i shall put some debug stuff everywhere
jnthn timotimo: Look around here for it. github.com/MoarVM/MoarVM/blob/mast...ion.c#L767 22:49
Sleep time... o/ 22:52
timotimo yes, found that exact spot by myself in the mean time :)
22:53 vendethiel joined
timotimo great. now i can't reproduce the base64 blobs any more 23:06
23:28 vendethiel joined 23:32 lizmat joined 23:33 ggoebel111111115 joined 23:53 vendethiel joined 23:57 woolfy 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!