01:47 ilbot3 joined 01:59 diakopter______ joined 02:28 colomon joined 03:17 cognominal joined 03:18 synopsebot6 joined 04:19 zostay joined, geekosaur joined 05:40 domidumont joined 05:42 domidumont joined 05:45 domidumont joined 06:10 domidumont joined 07:04 zakharyas joined 07:46 domidumont joined 07:58 dalek joined 07:59 retup__ joined, hoelzro joined, zostay joined 08:00 harrow joined 08:01 geekosaur joined 08:13 khagan joined
psch i've got this gist.github.com/peschwa/32ef0f291c...bb82b06b65 from running the first example here github.com/Perl6-Noise-Gang/perl6-...-MIDI-Note 09:21
is that sufficient for any kind of hint re: specific diagnostics? :)
jnthn psch: Well, there's the usual "did you try it under valgrind" hint :-) 09:28
psch okay, i'll do that 09:29
jnthn psch: But it looks like a SEGV inside of the native code called from Perl 6, which almost always means it's mis-use of NativeCall rather than a bug in MoarVM/NativeCall itself.
psch jnthn: well, i don't really know C, but "mem move" sounds like something that could interfere with moars allocations, from here... :) 09:30
jnthn (Passing an undersized buffer, or the wrong struct, or something)
psch but yeah, if that's not something it does...
also, did valgrind gets miraculously faster..? 'cause running the script with perl6-valgrind-m didn't take noticeably longer than with perl6-m... 09:34
i've added the output to a second file in the gist 09:35
jnthn Lots of C libraries use memcpy/memmove internally, but they also generally play nice with with things the outside world gave them :) 09:36
psch another thing of note might be that Audio::MIDI::Note uses Audio::PortMIDI with (potentially) a lot of 'start { }'s 09:37
using Audio::PortMIDI without any async works fine for long times (like, an hour or so maybe), but using Audio::MIDI::Note often SEGVs in less than a minute or so 09:38
jnthn Those are some incredibly confused stack traces, probably partly things to non-debug builds :) 09:40
The second problem is probably a good clue though
A buffer allocated by Pm_Initialize is overrun by Pm_WriteShort
As in, the latter tries to read past the end 09:41
psch ...not sure how i'd get debug builds for all the libs involved. well, or if that's really necessary even 09:43
probably would have to build them manually i guess
or is a debug enabled moar good enough? that i can do quickly :)
jnthn psch: IMO I'd start by taking a careful audit of how you're calling Pm_Initialize and Pm_WriteShort 09:45
Before looking more more elaborate ways to hunt the problem
Since it looks like a classic "putting too much into a buffer" problem 09:46
psch Pm_Initialize takes no args 09:47
and it gets called exactly once in both applications that use the lib
jnthn Hm 09:49
Is the library threadsafe? 09:50
If you're using it from multiple?
psch ah, no, it isn't :)
jnthn Ah
psch that's probably it then i assume?
jnthn Then it's maybe something like, threads competing to fill a buffer creates a data race on updating the amount of the buffer that's been used or some such. 09:51
Could well be. Do you structure things carefully so you only ever have a single thread interacting with the library?
psch i didn't make an effort to, no 09:52
jnthn Ah, so they you may well have multiple threads trampling on each other's use of the library
psch yeah, i'd assume so. the example usage has the equivalent of < start { Pm_WriteShort(...) }; Pm_WriteShort > all over itself 09:53
well, plus omitted arg list for the second call too :) 09:54
that'd also easily explain different failure modes i guess
'cause multiple threads using a non-thread safe library doesn't always fail the same time 09:55
jnthn Right
Yeah, threading failures are horrible that way
Does Pm_WriteShort do a lot of work, ooc? 09:56
jnthn has no idea about the library :)
I'm guessing so if you put it in a start...
I can think of a couple of design options that'd work for this
One is to use a channel, and have one thread that calls Pm_WriteShort whenever it receives something to write. 09:57
And the others just send what to write in the channel.
The other is to use a supplier, and emit into that, and have something reacting to it that calls Pm_WriteShort 09:58
psch Pm_WriteShort calls Pm_Write: portmedia.sourceforge.net/portmidi/...c0ab478ae6
high-level i understand it as "shove the buffer over the midi port"
+plus a bit of parsing what kind of midi message it is
jnthn Ah, so it's doing I/O 10:00
Does the sender then await the start?
Does anything? :)
psch nope :S
that'd also break the intended interface 10:01
jnthn Then you probably want the channel approach
Since send on a channel won't block 10:02
So you can get rid of the whole un-awaited start
psch well, every time the user wants to send an event we have to send a corresponding off-event later
that is, playing a note always plays it for a given amount of time
jnthn Where "later" is scheduled using something like Promise.in?
psch no, the start { } calls wraps a sub that calls Pm_WriteShort(on-event); sleep $duration; Pm_WriteShort(off-event) 10:03
jnthn ah
sleep inside a start is a little less than ideal, 'cus sleep is a real call down to sleep, and so blocks a real thread in the pool up 10:04
With my channel suggestion, and avoiding the sleep, you'd do something like: $chan.send($on-event); Promise.in($duration).then({ $chan.send($off-event) }); 10:05
psch so that should turn into Promise.in($dur).then({ $chan.send(off-event) }) i guess?
jnthn heh, you got it :)
psch alright, thanks for the help :)
jnthn :) 10:06
10:32 zakharyas joined 11:27 TimToady joined 12:39 domidumont joined 12:41 domidumont1 joined 14:03 domidumont joined 17:05 domidumont joined 17:06 lizmat joined 19:15 zakharyas joined 19:34 hoelzro joined
nine_ In oplist, what are those two arguments? loadbytecode w(str) r(str) 19:36
nqp::loadbytecode only takes a file name?
jnthn urgh 19:38
I'd not replicate that
I suspect it just evaluates to the name of the loaded file
Which is done for most void ops that might evaluate to something in the QAST -> MAST phase, but a few got mis-ported from the JVM implementation a while back and I apparently missed changing that one. :( 19:39
nine_ It's been that way since it was added apparently 19:40
Ah, now I see it: GET_REG(cur_op, 0).s = filename; 19:41
jnthn Yeah. Just have no w registers in your op :) 19:42
Oh...
There is one downside to all of this :(
Which is pretty bad.
We currently mmap bytecode files, meaning they're shared between VM instances. 19:43
Which is a really nice memory win for precompiled files.
nine_ but?
Oh you mean, we'll lose that memory win 19:44
jnthn But if you slurp the file into memory in a buffer and then pass part of it off to something to decode it, then we've got it privately.
Yes :(
Which would be quite a pity
nine_ Do we mmap files open()ed by Perl 6 code? 19:45
jnthn Doesn't stop us having an op that No
oops
No
Doesn't stop us having an op that takes an offset to start looking for bytecode in
nine_ That's what I was aiming at 19:46
jnthn That is, filename + offset
Though
nine_ Then we'd have the race condition again :/ The file could have been replaced between reading the dependency info and the mbc data
jnthn Yeah
Hmm
nwc10 My understanding (and I am not a security expert here) is that if you want to be secure, you need to be using file handles (or file descriptirs) 19:47
jnthn Wonder if we can expose mmap itself
nwc10 descriptors
nine_ Would have been cool if all files were mmaped and I could have just passed a pointer to the byte code loader
nwc10 never file names
because what the name points to can change
jnthn So we map it once in Perl 6 space into a file handle 19:48
And then pass that file handle off to the op, having read what we want.
And it can figure out what to do from there.
timotimo the good thing is that basically everything can be a file descriptor these days
jnthn nwc10: Yeah, which means not opening by name twice :)
nine_: If you're up fro the moderate yak shave then you could add an nqp::mmap :) 19:49
nine_ Looks like I'm already shaving away anyway...
jnthn (And a loadbytecodefh or so that takes a file handle...)
nine_ What would nqp::mmap return? I.e. how could I then access the file's contents? 19:50
19:51 cognominal joined, Brock joined, mtj_ joined, lizmat joined, colomon joined, Unavowed_ joined, JimmyZ joined, masak joined, vendethiel joined, psch joined
jnthn nine_: A file handle 19:52
Like nqp::open
nine_ Ok...I'll try to implement loadbytecodebuffer first to get warmed up 19:53
jnthn :-)
Sure
walk; bbl
nine_ Should I be concerned about perl6 now segfaulting? 20:13
timotimo just mildly 20:19
nine_ I guess I'm missing a step after adding my op? 20:20
jnthn nine_: Where'd you add it?
Before spesh ops?
nine_ yep
jnthn Also did you rebuild perl6_ops.c ?
(In Rakudo) 20:21
nine_ no
jnthn Ah, then it'd be that.
We've a github issue already for fixing the thing that makes that step necesary.
nine_ I was misled by oplist claiming backwards compatibility :) 20:22
jnthn It's actually 'cus perl6_ops.c references spesh ops directly
Which are VM internal
It really needs to resolve them by name or some such 20:23
nine_ So MoarVM tries, but rakudo cheats
jnthn Yeah. NQP suffers no such issues.
And Rakudo only cheats 'cus we didn't get around to providing a non-cheating way.
nine_ Ok, first test run 20:27
Meh...forgot to map the op 20:30
And it even sort of works. Except for the occasional Serialization Error: Unimplemented case of read_ref 20:36
Well I'll just claim this to be a nice start and continue another day. Good night :) 20:43
jnthn 'night, nine_++
timotimo gnite nine :) 21:03
21:34 patrickz joined 21:38 brrt joined
brrt good *, #moarvm 21:40
timotimo yo brrt 21:41
how are you tonight?
brrt \o timotimo
sort of tired, long day
timotimo i'm also quite tired, as i've got a mild case of the flu
brrt have enough brain space left to gather hypotheses for why reframe-jit breaks in pretty much all perl6 code 21:42
timotimo cool! :)
brrt ok, so, bring ''m on
what typically happens in perl6 code that doesn't happen in nqp code
(GC if you're not torturing things) 21:43
i've... not really proven that extops are the thing, but it is unlikely, since i did write a fix
timotimo taking continuations doesn't happen in nqp at all, does it?
brrt eh, oh 21:44
hmmm
that is a point
damnit, emacs not working with gnome zoom functionality 21:45
timotimo hum
there's some zooming feature in xfce that's really just zooming into a portion of the screen 21:46
brrt yeah, and these things are supposed to follow the cursor 21:48
which they do
but not in emacs
timotimo oh, but not a typing cursor
fair enough; the one xfce has only follows the mouse cursor i believe
brrt oh well 21:49
timotimo accessibility is such a slow-moving, hardly-advanced topic :\ 21:50
brrt aye
oh, some signatures changed 21:53
will check that out tomorrow
22:42 Unavowed joined 23:38 Unavowed_ joined 23:58 flaviusb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!