01:45 ggoebel joined
dalek arVM: e168617 | coke++ | build/mk-moar-pc.in:
autodie was introduced in 5.10.1

RT #125771 - make this dependency explicit.		 03:05
[Coke] why is build/mk-moar-pc.in copyright Daniel Dehennin ? 03:07
06:53 zakharyas joined 07:22 ely-se joined
ely-se hi 07:22
Does MoarVM offer stackful coroutines? A la Lua and Stackless Python 07:23
lizmat just saw this on HN: hal.inria.fr/hal-01100647/document 07:32
I assume brrt / jnthn are aware of this 07:33
ely-se: I assume most of the regulars here are still asleep :-)
ely-se :O
lizmat moarvm.org/features.html doesn't give that answer either :-( 07:36
ely-se maybe continuations can be used to implement them 07:37
TEttinger likely yes 07:39
continuations should be able to implement almost any control flow, if I understand correctly
ely-se is it hard to use MoarVM with a language other than Perl 6? 07:41
lizmat ely-se: you're going into uncharted territory there 07:42
ely-se :p 07:43
my language currently runs on Erlang but Erlang doesn't support mutable variables so I'm running into issues there
lizmat "MoarVM has no official assembly language, and at present no known unofficial assembler. Provided a compiler is written using the NQP compiler toolchain (which NQP and Rakudo Perl 6 are), then code can be generated by producing a MAST data structure."
ely-se is the bytecode format well-defined? 07:46
well I suppose generating MAST shouldn't be an issue 07:47
arnsholt ely-se: The continuations are used to implement Perl 6's gather/take, which is basically coroutines, so that should definitely be possible
ely-se arnsholt: it's important that I can yield from functions called from the coroutine (unlike ES6/Python generators) 07:48
07:48 FROGGS joined
arnsholt The coroutine being a, but the yield being in b (called by a), you mean? That's possible, yeah 07:49
ely-se yeah. nice!
I can't wait to implement this stuff. 08:05
08:20 ely-se left 08:32 ely-se joined
ely-se I wrote a VM in JavaScript to overcome the lack of green threads in browsers XD 08:32
TEttinger ely-se: wat? 08:34
was it the Wat VM?
shadowcat hangs around here too, I believe s/he implemented a wat variant too
ely-se TEttinger: one more level of indirection solves all problems, and VMs are indirection! 08:36
TEttinger heh
was it wat?
ely-se no
TEttinger damn
I like that one
ely-se The desktop/server VM is called Dexter from "desktop" and "server", and the web browser VM is called Horror because web development is a nightmare, and also Dexter is a horror-genre TV series. 08:37
TEttinger axisofeval.blogspot.com/2013/05/gre...es-of.html
it looks cleaner now 08:38
he got rid of the ["" ""] syntax and now it's plain lisp
ely-se here's mine: github.com/mill-lang/horror/blob/m.../thread.js (has nothing to do with Mill architecture; I didn't know that existsed when I chose the name) 08:39
TEttinger nice
ely-se I have a plan to JIT-compile functions that the VM can prove will never yield the thread 08:42
and for the desktop/server VM I want to use MoarVM 08:50
09:19 zakharyas joined 09:45 FROGGS_ joined
nebuchadnezzar [Coke]: hmm, I made that mk-moar.pc and my emacs automatically add a Copyright header 11:40
jnthn Does it have to use autodie, given it's apparently the only thing blocking MoarVM building properly on 5.10? 11:41
nebuchadnezzar no 11:43
I was just lazy at testing 11:44
lizmat jnthn: autodie is really just syntactic sugar 11:59
e.g. you don't have to do "or die" after an open() anymore to make sure you catch a failed open()
nebuchadnezzar lizmat: yes, but in fact there is only one open in the file 12:00
so we can stick to the same perl version as Configure.pl 12:01
lizmat :-)
dalek arVM: e075ba6 | (Daniel Dehennin)++ | build/mk-moar-pc.in:
mk-moar-pc.in: replace autodie with a plain die

There is only one open in the file, no need to enforce different perl version dependency than Configure.pl.
RT #125771		 12:08
arVM: fe416c5 | lizmat++ | build/mk-moar-pc.in:
Merge pull request #232 from baby-gnu/rt/125771-replace-autodie

mk-moar-pc.in: replace autodie with a plain die
nebuchadnezzar lizmat: erf, I made a typo 12:11
lizmat I guess another PR is in order then... :-) 12:12
it looked ok to me though
so what's the problem?
parens perhaps ? 12:13
nebuchadnezzar No I use $pcfile in the die message, but it's undefined at that time
12:13 FROGGS joined
nebuchadnezzar travis-ci.org/MoarVM/MoarVM/jobs/74903353#L623 12:14
lizmat ah, yes 12:15
nebuchadnezzar lizmat: erf, I updated my branch but as it was already merged I can not make a new pull request with it: github.com/baby-gnu/MoarVM/commit/...7d2ce47f19
lizmat one of the things P6 fixed :=)
shall I do it manually then? 12:16
nebuchadnezzar I do not find the github button, so I think yes
dalek arVM: f99d24c | lizmat++ | build/mk-moar-pc.in:
Fix thinko, nebuchadnezzar++
 12:19
nebuchadnezzar I should test my commits locally instead of relying on travis
I became too lazy
lizmat no problem, I should have waited for Travis to complete 12:21
but the code change seemed ok (through my P6 glasses)
12:27 travis-ci joined
travis-ci MoarVM build failed. lizmat 'Merge pull request #232 from baby-gnu/rt/125771-replace-autodie 12:27
travis-ci.org/MoarVM/MoarVM/builds/74903571 github.com/MoarVM/MoarVM/compare/e...416c5990cf
12:27 travis-ci left 12:39 ggoebel joined 12:46 colomon joined
[Coke] lizmat++ nebuchadnezzar++ I updated the RT with the new info. 13:08
15:34 brrt joined
dalek arVM/even-moar-jit: 78598d9 | brrt++ | src/jit/ (3 files):
Resolve tiler conflicts by adding new nodes

Tiler conflicts can arise because the expression 'tree' is a DAG, and consumers of a node may require different tilings. (E.g. one may require a node to yield a label and another may require a register).
To resolve these conflicts, we add a new node to the tree, with the same child nodes but assigned to the new tile. Because tiling is a bottom-up process, this will not generate a new conflict and the result must be a tiling without conflicts.		 15:35
MoarVM/even-moar-jit: 24e6abb | brrt++ | docs/jit/ir.md:
brrt :-o i killed dalek? 15:38
jnthn overflowed it, by the looks of it 15:39
I sometimes wonder why it doesn't just do a sleep(1) between each commit it reports... :P
Maybe 'cus it's an async thingy and in Perl 5 you can't just do it with await Promise.in(1); :) 15:40
brrt right 15:44
lizmat: i had not read that, no thanks :-)
ely-se: MoarVM is stackless in the C-stack sense 15:54
this is both a blessing and a curse 15:55
but mostly a blessing
anyway, the last commit was a boatload of expression template documentation, which is hopefully useful for other people 15:57
jnthn brrt++ # documenting 16:02
brrt was a useful distraction today. (i went to oldenburg to discuss thesis possibilities with a group there) 16:03
and the bus trip was a good opportunity for some writing :-)
*is
jnthn :-) 16:04
16:13 ely-se joined 17:04 ely-se joined 17:19 rurban_ joined 19:49 Peter_R joined 19:56 ely-se left
timotimo read through that documentation 21:45
22:19 TEttinger joined
hoelzro v8project.blogspot.com/2015/08/gett...-free.html 22:21
not entirely relevant to MoarVM's use cases, but still interesting

Powered by Cro and the Raku® Programming Language.

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

Thank you!