jnthn Earlier today, the machine hosting moarvm.org was victim of an attack that drew it into a botnet, and so was promptly taken offline. Typical that it happens while I'm on vacation. On the upside, it happened on an afternoon that was rainy and miserable enough that I was indoors anyway :) 13:52
nwc10 this is also why your IRC client went away? 13:53
jnthn Yup.
nwc10 suck.
jnthn Anyway, that + moarvm.org are now running off a nice new thingy.
nwc10 excellent 13:54
jnthn Modulo DNS migration.
nwc10 with a pony?
jnthn (Didn't actually have to change name servers, just records.)
brrt wow man, that sucks 13:56
jnthn just remembered there's a moarvm.com too, and re-poined that :) 13:59
uh, pointed
Other thing is that I'd had a "re-do all this infrastructure" plan figured out and waiting on free time. 14:04
Guess part of it happens early... 14:05
moritz jnthn: in the long run, IWBN if you weren't the only one who can upload moarvm releases 14:06
jnthn: bus factor and all that
jnthn moritz: Yeah...crossing the road here in .my is a little hair-raising... 14:07
;) 14:08
but yeah, I'll set something up "in the long run"
(Hopefully not so long.)
nwc10 jnthn: I thought it was bad enough in Salzburg when the trolleybus swooshed by 14:09
(just when I was thinking of crossing the road, and hadn't looked)
moritz has anybody tried the new github releases thingy?
(not so new anymore, I guess...)
[Coke] TROLL BUS 14:11
timotimo moritz: you mean the thing that constantly sends users our way with tarballs that don't work? :) 15:46
moritz timotimo: no, that's downloading tarballs for a tag 16:04
timotimo: releases are also tied to a tag, but allow uploading of other binaries, iirc
timotimo oh 16:06
that wouldn't be too bad
[Coke] lots of moar failures on today's run, differences between jit and not 16:44
timotimo updates his 8 months old local checkout of roast-data 16:46
hoelzro is there any possiblity of reverting that lazy deserialization stuff? 17:37
at least until it's determined what the problem is and it can be fixed?
timotimo it's probably possible 18:25
it might be easier to just put a "'lazily' deserialize everything right at the beginning" in, though 18:27
brrt :-o [Coke] that's worrisome
hoelzro timotimo: I, in my Moar ignorance, tried that, and made it segfault =/ 18:28
but someone moar experienced with the inner workings of Moar (and in particular serialization) may have better luck with that
timotimo oh, huh
timotimo brrt: ISTR you said something about potentially building a set-removal kind of thing based upon PHI? 20:36
that was quite some time ago, though
brrt let me think
timotimo that might really be worth something 20:38
especially if it just relies on what the phi ops do already 20:39
like, after a set, two registers are "merged", kind of like what a PHI signifies
but i'm not sure if spesh can already handle PHI that are not at the beginning of a BB 20:40
brrt phi's are always at the beginning of a bb :-)
timotimo at the moment, sure 20:42
but if we replace set instructions with phis, they may no longer be.
except if we just add more sources to the phi ops that belong to blocks we jump to from the block we're doing the set-removal in at that moment 20:43
brrt okay, the truth of it is, i don't know if we can do that yet :-) that problem seems hairier to me now than it did then 20:51
but that may just be an indication of my head being a bit removed from it
timotimo OK 20:57
hey
so now that we can enter jitted code easily on moarvm
...
Inline::ASM? :D
especially with NSA that could be cool 20:59
lizmat ah, the days I could just hex code into a buffer and have it execute by just doing "asmcall" on it 21:00
timotimo :D
[Coke] I remember the days when I'd key in a dozen pages of hex code from a magazine to get a crappy C64 game. 21:04
timotimo :D
brrt sleep well #moarvm 21:07

Powered by Cro and the Raku® Programming Language.

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

Thank you!