jnthn has had his image resize/upload script he went through in his YAPC::EU talk happily churning away much of the day :) 00:01
r-m concurrency stuff definitely has some work to go, but this thing is running very nicely :) 00:02
Time for sleep & 00:03
01:15 camelia joined 01:56 camelia joined 04:03 camelia joined 04:45 ggoebel11111112 joined 06:32 avuserow joined 06:48 FROGGS joined 06:56 avuserow joined 07:14 zakharyas joined 08:03 cognome joined 08:15 avuserow joined 08:20 kjs_ joined 08:38 zakharyas joined
timotimo HC Hammer, eh? 08:44
jnthn Hammer Controller 08:48
timotimo ah 08:56
10:00 camelia joined 10:31 flaviusb joined
carlin *MC Hammer 10:46
(typo correction ~12 hours later) 10:47
12:33 camelia joined
timotimo what was the reason we went for dynasm instead of llvm, btw? 13:29
moritz llvm is huge in comparison 13:36
and... uhm, I think brrt++ blogged about it
timotimo yeah, but it also gives us everything
lots of platforms, for example
moritz i think one pain point is integrating the LLVM JIT with our own runloop 13:38
timotimo i'd like to prototype a tiny quasi-register-allocator for our jit, but it'd have to know stuff about roots then :\ 13:49
except ... if just removing the load-from-memory operations if we still have a register around that holds the value is already a big help, that could Just Work™ 13:50
so if i keep the stores around, but kick the loads, maybe that'll be noticable 13:54
and in fact, it'd be doable before we get dynasm's fully realized register selection thingie magic 13:55
13:55 JimmyZ joined
JimmyZ good evening 13:55
timotimo hey JimmyZ :) 13:56
nwc10 good UGT heresy, JimmyZ
JimmyZ hello timotimo, nwc10 13:57
timotimo: looks like the post of brrt++ had said it
timotimo yes
JimmyZ another reason about llvm is that llvm is written in C++ :P 13:58
timotimo oh well.
JimmyZ about removing the jit code of loading and storeing result in Moarvm's regs, I wanted to ask brrt++ about it, but I didn't 14:00
:P
timotimo heh. 14:01
do you have a better idea than me?
nwc10 beer? :-) 14:02
(It is Friday, after all)
timotimo i was going to carry around a little struct that you'd tell the addresses (index of local) of things you want to get and then let it emit the proper mov operations
or something like that
and after an op is done, you set the new values of the registers or invalidate them if necessary (because you wrote over them in your code) 14:03
now that i spell it out, that sounds pretty terrible %)
JimmyZ how does luajit do it?
timotimo no clue
JimmyZ brrt-to-the-future.blogspot.com/201...ssons.html # I think there are some good roadmap for MoarVM :P 14:16
timotimo yeah
the iterator thing he mentions near the end is already implemented
JimmyZ oh, is it in the repo now? 14:17
timotimo i believe so. gimme a second
oh, hm. 14:18
indeed
github.com/MoarVM/MoarVM/blob/mast....dasc#L909 14:19
spesh/optimize.c emits these
JimmyZ I thought it didn't 14:22
:P
15:16 kjs_ joined 15:55 camelia joined 16:23 FROGGS joined 19:43 flussence joined
dalek MoarVM/sepsh: 0cfae6d | (Tobias Leich)++ | src/ (13 files): 20:07
MoarVM/sepsh: [WIP] implement multi-char input line separators
MoarVM/sepsh:
MoarVM/sepsh: This implemements line seps on a grapheme level that are not just one character long.
MoarVM/sepsh: These separators are used when cutting lines from an already filled buffer, but they
MoarVM/sepsh: are also used to fill a buffer by requesting more data from a stream until we find a
MoarVM/sepsh: separator.
MoarVM/sepsh: Parts of this code already handle multiple separators, others do not. Also, when we
MoarVM/sepsh: have more than one separator we usually want to prefer the longest matching separator.
MoarVM/sepsh: To achieve that we keep a list of possible remainders that need get chopped off the
MoarVM/sepsh: next line, in case we have separators that start with the same chars. Like \n would be
MoarVM/sepsh: a remainder for the separators [ \r\n | \r ], when we only hit \r yet.
MoarVM/sepsh: We also need an op that takes a list_s, since nqp::setinputlinesep() only takes one
MoarVM/sepsh: string.
hoelzro ahoy #moarvm 20:08
FROGGS MoarVM/sepsh: Note that this patch still leaks as hell, e.g. the list of input separators and
hoelzro aside from the source, are there any docs on how Moar handles serialization?
FROGGS MoarVM/sepsh: remainders. Though it spectests fine, which is always nice.
hi hoelzro
hoelzro o/ FROGGS
FROGGS hoelzro: unlike
unlikely* 20:09
hoelzro =(
I'm just wondering how if I have two definitions of a module in separate units, how they are stored in the .moarvm files such that Moar knows they should be the same object in memory
ex. module Example::A {} in A.pm, module Example::B {} in B.pm 20:10
how does Moar know that the Example in both compunits are supposed to be the same in memory?
FROGGS hoelzro: because it is just a placeholder
so it cannot conflict with another placeholder 20:11
like you can declare a stub several times and it will never complain about it
hoelzro my knowledge of how it works it pretty vague, but as far I understand, the format refers to an object with a 32-bit ID, right? 20:12
and there's a table of IDs -> contents in a compunit
[Coke] today's daily run will finally include java again.
ww
hoelzro but I'm wondering how the identifier in A.pm.moarvm and B.pm.moarvm end up pointing to the same object in memory 20:13
FROGGS hoelzro: when objects get serialized, they get a serialization context id, aye
they get merged when you load the two
hoelzro is the same ID used for Example in each .moarvm file, then? 20:14
FROGGS no 20:16
look at rakudo/src/Perl6/ModuleLoader.nqp:244
the Example will be merged when you import the two into *your* code
only then there will be an Example that has both an A and a B
hoelzro interesting 20:17
well, that code will provide for some interesting debugging insight when I look later =)
hoelzro would like to try and fix rt.perl.org/Public/Bug/Display.html?id=122773
timotimo FROGGS: and when we start speshing multi-char input line separators, that'll be MoarVM/spesh-sepsh? :)
hoelzro .oO( insepshtion? ) 20:18
FROGGS hoelzro: also read rakudo/src/Perl6/World.nqp:399
timotimo: *g*
timotimo: or spepsh
hoelzro thanks for the insight FROGGS 20:21
FROGGS hoelzro: you're welcome
(and when I finally see the RT page I tell if I can tackle it) 20:22
ahh, that one... 20:24
hoelzro: yes, I can try
hoelzro I spent some time on it last night, but my Moar knowledge is so limited it's hard to tell what exactly I'm looking at 20:25
the reason I suspect Moar is that I can undo 7a722dc4018ce1b99bbd4abea198e242d7da0157 and it works fine 20:31
(well, with the appropriate checkouts of Rakudo and NQP)
jnthn hoelzro: The package conflict resolution is implemented in src/Perl6/ModuleLoader.nqp iirc 20:34
hoelzro: It's got resolve in the name, iirc
timotimo jnthn: how do you feel about the my Num $foo = 1; thing? 20:35
hoelzro jnthn: that makes sense, but it's so weird that just changing Moar fixes/breaks it
timotimo should the assign op get made a bit slower to also try to unbox other types or something like that?
jnthn timotimo: my Num $foo = 1 is a straight type error
timotimo oh
well, in that case it's a bug that parrot allows it i suppose :)
jnthn You declared Num, but tried to assign an Int.
And Int isn't a Num
hoelzro: I'm wondering if that patch made something happen too lazily... 20:36
hoelzro that's what I'm thinking
jnthn hoelzro: Could instrument the resolution stuff with some logging 20:37
And then compare what happens with and without the patch
hoelzro I noticed that deserialize_object and deserialize_stable didn't change; I'm wondering if they needed to
jnthn Though this case may end up being just a case of merge_globals...
Those two are the "just one object/stable" iirc
Note that the whole repossession thing may play into this somewhere too 20:38
hoelzro this will be fun to fix =/
jnthn I *think* there's some notes on that stuff in the NQP course
timotimo JFTR: i'm positively surprised by our Complex type's performance :)
hoelzro I'm a moar newb
I think so, yes
20:56 cognome joined 21:57 cognome joined 22:33 camelia joined 22:39 kjs_ joined 23:10 flussenc1 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!