03:16 TimToady joined 06:24 oetiker joined 06:25 rurban_ joined 07:07 FROGGS joined 08:29 brrt joined
dalek arVM/even-moar-jit: 9692830 | brrt++ | src/jit/ (5 files):
Move pseudocompiler to it's own file

Nice to know, but outlived it's time.		 09:36
brrt lunch & 09:39
10:00 brrt joined 10:48 nwc10_ joined 10:49 nwc10 joined, brrt joined, FROGGS joined, rurban_ joined, oetiker joined, TimToady joined, TEttinger joined, colomon joined, leedo joined, itz joined, harrow joined, mtj_ joined, lizmat joined, japhb joined, Util joined, [Coke] joined, camelia joined, synbot6 joined, diakopter joined, ggoebel joined, tadzik joined, dagurval joined, rudi_s joined, psch joined, masak joined, flussence joined, sergot joined, prammer joined, hoelzro joined, timotimo joined, nebuchadnezzar joined, JimmyZ joined, dalek joined, retupmoca joined, bonsaikitten joined, sivoais joined, moritz joined, jnthn joined, danaj joined, arnsholt joined, btyler_ joined, BinGOs joined, nine joined, ashleyde1 joined, avar joined, ChanServ joined 11:05 danaj joined
brrt wonders whether we can't build a more reliable chat thing than irc 12:08
hmm... i've a bit of an issue with types 12:14
jnthn: would it hurt significantly to declare the int sizes *before* we load types.h 12:17
it would solve my problem so well 12:18
tadzik brrt: have you see matrix.org? 12:19
it's quite promising
brrt i have not
oh, cool 12:20
tadzik a bit lacking on the client side of things, but there's a weechat plugin for it that works 12:21
jnthn brrt: Is there any notable downside? 12:27
brrt not that i know of
jnthn brrt: irssi in a screen session = reliable IRC ;)
brrt hmm yeah
but then i have to badger moritz about an ssh connection :-)
jnthn I think other people on that channel can give you one also 12:28
12:28 timo joined
jnthn If declaring the int sizes before the composite types solves you problems, I've no particular objections 12:28
brrt :-) 12:30
then i probably will
although i can get away with not doing it
timotimo o/
brrt oh hai timotimo 12:31
hoelzro good morning #moarvm! I tried to build MoarVM on Windows last night, but I got a C1026 error (something about unicode.c being too complex). I'm using VS 2015; is the only solution to go down to VS 2013? 12:43
jnthn Yes :/ 12:44
Or see if there's a patch VS 2015 available
nwc10 so, VS 2013 is an upgrade from 2015, much like 7 is an upgrade from 8?
what is it with MS?
jnthn It's decidedly a compiler bug, nothing we're doing wrong.
nwc10 any iea what it's choking over? A very big switch statement?
jnthn I think a deeply nested literal
hoelzro would it make sense to check for VS2015 and warn the user until this is fixed, so they know that they have a solution? 12:47
13:11 zakharyas joined
brrt yeah, it would 13:25
#ifdef BORKEN_MSVC #error "Your MSVC is broken. OOPS" #endif
or something like that :-)
weird 13:32
dalek arVM/even-moar-jit: 206b77e | brrt++ | 3rdparty/dynasm:
Update to bugfixed dynasm
 13:43
brrt be back in a bit 13:50
14:17 brrt joined 15:07 rurban_ joined
dalek arVM/even-moar-jit: ca4db0d | brrt++ | src/ (7 files):
Implement a few tiles, for real this time
 15:24
brrt so... many.. tiles
jnthn
.oO( Es ist Mein Tile - Nein )
 15:25
brrt but, we're getting there 15:28
jnthn :)
brrt++ # persistence
I think I've finally figured out a reasonable API for the hyper/race stuff. 15:29
brrt \o/ 15:30
(i've finally figured out a reasonable API for tiles :-)) 15:31
japhb Congrats to both of you. :-)
jnthn Means I can get the hard stuff involving concurrency control all in one place. 15:36
And also get chains of maps etc. to process the whole chain on one thread for a particular batch of work 15:37
timotimo \o/
are some tiles defined as C code directly and some are built from the .tiles file? 15:38
brrt all tiles are defined as c code 15:52
the tiling state machine is built from the .tiles file 15:53
jnthn Hmm...one condvar or two...
timotimo oh 15:54
the tiling state machine is what decides what tiles to apply when
and the tiles themselves are then C code
makes sense
brrt :-) 15:55
keeps dasm in its place 15:56
JimmyZ the new JIT looks like promising
timotimo i must admit i'ven't compiled a moarvm with the new jit yet :|
does it actually kick in for some cases yet? 15:57
TimToady jnthn: will it be easy to do a slow-start, where the batch size increases as we go along? or is that a bad idea for some reason, like speshing?
jnthn TimToady: It's not immediately a bad idea.
TimToady: I'll probably end up with something along those lines eventually. For now just going to pick default batch size and degree of parallelism. 15:58
TimToady: And then when it's working will get clever :)
TimToady cleverer, I suspect
jnthn ;) 15:59
Yeah, well, I figured we want an escape hatch too
So .hyper() is the "try and work out the best thing for me"
But you can do .hyper(:batch(100)) to say "work 100 items at a time"
.hyper(:batch(100), :degree(2)) # work in batches of 100 and over 2 threads 16:00
JimmyZ :batch(10, 20, 30 .. *) ;) 16:01
jnthn And for now our clever is limited to method hyper(:$batch = 64, :$degree = 4) { }
JimmyZ: That's probably overkill.
timotimo you'd only need "10, 20 ... *", too 16:03
(but 3 dots rather than 2)
TimToady well, and slow-start would be more like :batch(1, 1, *+* ... *) 16:08
jnthn What, fib has a real world use??? Mind = blown!
timotimo hah
TimToady well, I doubt that's how TCP does slow-start 16:09
but you want something that grows at a reasonable rate
timotimo m: .say for (1, 1, 1, * + 0 * * + *, ... *)
camelia rakudo-moar 262352: OUTPUT«===SORRY!=== Error while compiling /tmp/JUOx4NwaZM␤Comma found before apparent series operator; please remove comma (or put parens␤ around the ... listop, or use 'fail' instead of ...)␤at /tmp/JUOx4NwaZM:1␤------> .say for (1, 1, 1, * + …»
timotimo m: .say for (1, 1, 1, * + 0 * * + * ... *)
TimToady why the parens?
timotimo superstitions
brrt fib has plenty real world uses!
camelia rakudo-moar 262352: OUTPUT«(timeout)1␤1␤1␤2␤3␤4␤6␤9␤13␤19␤28␤41␤60␤88␤129␤189␤277␤406␤595␤872␤1278␤1873␤2745␤4023␤5896␤8641␤12664␤18560␤27201␤39865␤58425␤85626␤125491␤183916␤269542␤395033␤578949␤848491␤12435…»
timotimo that sequence seems cute 16:10
brrt ehm, something something about huffman coding dictionairy sizes
timotimo: no, doesn't compile things yet. working on that :-)
we're getting their
TimToady timotimo: 0 * * isn't worth much 16:11
timotimo supposed to skip an argument
that's all
TimToady ah 16:12
m: say 1, 1, 1, -> $a,$,$c { $a + $c } ... * 16:13
camelia rakudo-moar 262352: OUTPUT«1 1 1 2 3 4 6 9 13 19 28 41 60 88 129 189 277 406 595 872 1278 1873 2745 4023 5896 8641 12664 18560 27201 39865 58425 85626 125491 183916 269542 395033 578949 848491 1243524 1822473 2670964 3914488 5736961 8407925 12322413 18059374 26467299 38789712 568490…»
TimToady would write it more like that
timotimo mhm 16:21
less hacky, that's for sure
hoelzro is there a reason that unicode.c hasn't been fixed for VS2015, like performance or something? I'm wondering if I should try my hand at fixing it after work 16:26
jnthn hoelzro: Nothing more than "everybody had more critical things to do" 16:30
hoelzro jnthn: ok, good to know. I don't have anything more critical to do, so I'll give it a shot =)
jnthn hoelzro: If there's a reasonable workaround to the bug that doesn't cause other issues, I've no problem with it.
timotimo i might be unable to do much development during the coming week, because it's Chaos Communication Camp 16:33
lots of things still to do, though :| 16:34
TimToady jnthn: reordering hyperbatches sounds like a good place for a heap sort 16:35
for cleverness one might think about increasing the size of later batches so that the earlier batches tend to complete first 16:38
and fibonacci might show up again in this way: suppose you have two threads, and want to do 16 things, but you don't want the latency of 8 16:40
so you give one thread a 3 batch and a 5 batch, and the other thread an 8 batch
then your initial latency is 3, but overall time is 8
16:41 brrt joined
japhb As soon as you said heap sort and fibonacci, I thought of en.wikipedia.org/wiki/Fibonacci_heap 16:42
timotimo oh yeah
TimToady "Fibonacci heaps have a reputation for being slow in practice[11] due to large memory consumption per node and high constant factors on all operations." 16:46
brrt hmmmmmmm.... another *challenge*; how to upwards-propagate terminals 16:57
can i automate that at all, i wonder 17:01
of course i :-) should i? 17:02
i can
japhb TimToady: I saw that ... it wasn't a serious suggestion, just noting the path my brain followed.
22:05 TEttinger joined 22:41 TimToady_ 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!