github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 06:59
nwc10 o/ 07:01
brrt ohai nwc10 07:46
nwc10 GC_DEBUG at 3 is slow 07:48
and Promises make my head hurt (that's $ork currently)
more, that the code is an aysnchronous tangle of things happening simultaneously, and it seems that it doesn't recover (well) from DB timeouts 07:49
and no, I did not create this architecture
of the various errors I have seen logged, this was my favourite "Failed fetch: Cannot resolve. Already resolved" 07:50
we also have "can't reject, alreay rejected" and at least 1, if not both of the remaing contradictions 07:51
it's partly because of limitations of DBD::Pg for a couple of things, which probbly are it, not libpq 07:52
like, it always attempts a (blocking) network round trip on a ping. When we'd like a timeout on *everything*
and this is soooooo off topic. :-)
brrt are you working with assync perl? 08:52
*async
nwc10 new $ork thing is
brrt blegh 08:56
nwc10 yes, I can see why it makes sense. 08:57
But it turns out to be complex to answer the question "what is it doing currently?" when all the state is hidden in closures
(Because promises)
and there are lots of little race conditions when your 3 data sources are all moving (you're getting updates on them) and then your actions are a bit slow, so you start to queue them up
and it turns out that sometimes when the slow action has finished (a download) the data that made it useful might have been deleted again. 08:58
I *think* that I have them all now.
We're only using Rakudo at work for the office time tracking system (the web frontend, and integration to the phone system and doors) 08:59
but I'm wondering if most of this would be easier with Channels and stuff
or if, again, it would be "all your data is held in a queue, and by the time it reaches the front of the queue it may no longer be relevant" 09:00
life is hard, etc,
but I've been told by a couple of people that sheep farming is harder. So that is not a good "get away from it all" plan.
nwc10 it all stills like "the 90s called and want their multitasking back" 09:01
I read things like "At this point, our async operation is running, but we have not yet given it anything to do when the callback is fired." and I think *no*, it's not actually running. It's queued to run, but nothing will happen until you return control to the event loop. 09:06
and also I'm very scared by "who actually owns which objects, so as to avoid reference loops, or things going away early"
the memory management seems to be regressing back to what one has to do with C
that isn't the future that I was hoping for 09:07
oh, he fell off 09:08
.tell brrt, also these folks seem to have 8Gb Raspberry PIs in stock, and what seems to be a very good price on 32Gb micro SD cards: www.welectron.com/Raspberry-Pi-4-M...ampaign=gh 09:09
tellable6 nwc10, I'll pass your message to brrt
nwc10 yes, I'm aware that there's a promo link there :-)
timotimo nwc10: this is perl5, correct? having something buggy and very asynchronous might be interesting to develop the moar debug bridge further 09:58
nwc10 it's perl 5
timotimo it currently knows nothing about rakudo builtins, so when you see a Promise, you'll have to traverse it manually to get to, for example, the closure's values
nwc10 at the moment I have enough other complex "fun" things to juggle 09:59
timotimo right 10:00
also, i've always wanted to build something that visualizes supplies and their chains 10:02
Geth_ MoarVM: Kaiepi++ created pull request #1327:
Improve serialization of C types		 11:23
nwc10 bah, after another 25 hours building rakudo 12:53
Stage start : 0.062
Method 'hash' not found for invocant of class 'Capture'
no GC errors
some *other* wierder problem then. Which doesn't show up in any NQP regression test
sena_kun nwc10, what CPU do you have? 12:55
nwc10 that's, um, some sort of x64_64 machine. But I'm testing local changes. 12:57
it builds from master just fine
sena_kun nwc10, not sure how helpful, I recently got 3900X with enough ram on board, which is kind of fast, so if it can be helpful, I can run stuff. 12:59
nwc10 whilst this thing is a VM, it's 24 cores, I think 128G (in the host) and I think most of the "load" is other VMs on it using lots if inotify handles to keep npm happy. 13:00
(thanks for the offer)
but 24 cores don't help you when the build goes serial
sena_kun Then never mind. :) 13:01
nwc10 anyway, now that I've ruled out "GC problem" I can go back to faster builds
sigh
and more head scratching.
I'm going to make some tea, and maybe retreat to the hammock (although that also has to be done serially, else me and the hammock get wet) 13:02
timotimo did i ever complain that we have no unified way to tell spesh "when you continue optimizing, please consider this op next" 13:06
when i turn an elems on a P6opaque into a "get attribute from slot, then elems that" i would like spesh to do this elems one next 13:07
timotimo right now i can turn the existing elems op into the p6oget_o and then put a new elems op after that, and spesh will pick that up as the "next" 13:08
but i'd much prefer keeping everything on the existing elems op, like define/use chain info and such
timotimo (the same goes for {bind,at}{key,pos} ops on p6opaque objects) 13:12
timotimo implementing constant-folding of unbox_n hits whenever the thread pool scheduler's manager thread starts up 13:52
because we use a Num to sleep for the interval with
so... worth it! ...? 13:54
Geth_ MoarVM: 32ce5f9738 | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c
constant-fold spesh-time-known unbox/decont_n/s
 14:03
MoarVM: a4cb0c5167 | (Timo Paulssen)++ | 2 files
give io loop thread and spesh thread a name

continuous integration shall help me figure out how to make this not explode on non-gnu systems		 14:10
MoarVM: 2a3290df9a | (Timo Paulssen)++ | 2 files
let's see if this code taken from stackoverflow is right
timotimo i wonder how properly to get rid of the undefined warning for the setname_np functions 14:13
if the same glibc vars are set at the point before we include pthread (probably indirectly via uv.h) we define GNU_SOURCE? 14:14
even when i directly include <pthread.h> just after #define _GNU_SOURCE it complains 14:25
Geth_ MoarVM/give-threads-names: 183becd24e | (Timo Paulssen)++ | src/moar.h
ensure _GNU_SOURCE is defined when including pthread

so we can have pthread_setname_np. hopefully.		 14:36
Geth_ MoarVM/give-threads-names: 0a0a9ba961 | (Timo Paulssen)++ | 6 files
use Configure.pl to find out if pthread_setname_np exists
 17:37
timotimo setting a thread's name will get its own nqp:: op i guess *shrug* 17:38
Geth_ MoarVM/give-threads-names: 44504309e9 | (Timo Paulssen)++ | 9 files
introduce the setthreadname op

sets the current thread's name (at least on linux)		 18:01
timotimo imgur.com/4lWsQUY 18:09
imgur.com/a/eMCXI7d 18:14
Geth_ MoarVM/master: 4 commits pushed by (Timo Paulssen)++ 18:25
timotimo so, um 18:59
is MVM_string_utf8_encode_substr not supposed to stop encoding after the length you pass in gets reached? 19:00
because, um 19:02
it kind of gives you until the end of the string? 19:03
am i holding it wrong? 19:09
[Coke] timotimo: hoi 19:16
ww.
Geth_ MoarVM: 8e75378f1e | (Timo Paulssen)++ | src/core/threads.c
go through some pains to cut string length to 15 bytes

cutting apart graphemes would be quite the bad look.		 19:25
timotimo timo@schmand ~/p/moarvm (master)> xxd /proc/962066/task/962072/comm 19:33
00000000: 0102 0304 0506 0708 090a 0b0c 0d0e 0f0a ................
^- by using utf8-c8 you can even put arbitrary buffer data in there
htop just displays this as "???????????????"
Geth_ MoarVM: 1d52655e25 | (Timo Paulssen)++ | src/core/threads.c
decode threadname with utf8-c8

so that arbitrary buffer data as well as non-normalized strings can be used if necessary for whatever terrible reason		 19:34
timotimo this can also be supported by the deb server 19:50
Geth_ MoarVM: 707f6ce704 | (Timo Paulssen)++ | 2 files
Debugserver Protocol 1.2: add thread "name" field

  (in Thread List Response)		 20:22
MoarVM: 1278032475 | (Timo Paulssen)++ | src/debug/debugserver.c
set debugserver's thread name
patrickb timotimo: Did you notice the comments in github.com/MoarVM/MoarVM/commit/8e...f55283090b 21:40
timotimo i did not! 21:54
sorry :)
used to be a return in there
Geth_ MoarVM: d564695f6d | (Timo Paulssen)++ | src/core/threads.c
fix the most obvious use-after-free in history

thx @MasterDuke17		 21:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!