00:19 ggoebel joined 00:30 btyler joined
MasterDuke Attempt to divide 1 by zero using div 01:08
in method floor at src/core/Rational.pm line 53
rest of the output here: gist.github.com/MasterDuke17/329ef...68cd55b285
timotimo you're saying it shouldn't blow up when stringified via gist? 01:09
MasterDuke ? no, i'm just showing a backtrace with the source file+line number, instead of m-CORE.setting 01:11
timotimo oh! 01:13
MasterDuke however, it's a complete hack, completely unusable
timotimo sorry, i'm kind of tired
i didn't realize that. i even used the filename to get at the right core :D
MasterDuke ha! but that is the point!
timotimo i meant: i read the file names and clearly used one of them, but still didn't realize that's what changed 01:16
MasterDuke yep, exactly why i think it's a good thing to implement 01:17
timotimo yes
do we want to make this accessible to user scripts, too? probably. for things like FatPack? 01:18
but if the actual pre-packed source isn't available, that could become annoying
perhaps an env var that turns translations off would be necessary
MasterDuke there was some discussion about this a week or two ago 01:19
timotimo also, i wonder if this could be an attack/obfuscation vector. giving your code a different filename that it claims to have to hide evil code from investigators
MasterDuke in #perl6-dev i think
there seemed to be consensus for making the change
timotimo mhm 01:20
it's not easy to get spesh post-inline optimization to not explode :\ 01:21
MasterDuke the problem of not having the source was explained away since the end user doesn't necessarily have the core settings either
so it's not like its name+line number is any more useful
timotimo mhm
MasterDuke but like i mentioned, the way it's currently implemented is completely wrong 01:23
in that it only works if you run perl6 from the directory where you've checked out+built the source 01:24
timotimo oh, whoops :)
don't say it actually opens the files to look for the annotationl ines?
MasterDuke i'd be lying if i said no
timotimo right
what we can do is this: have a data structure built up during compilation, put it into the serialized blob and "turn it on" for a given compilation unit with a nqp::op that gets put into the dependencies+deserialize part of the comp unit 01:26
how does that sound?
MasterDuke way over my head
but yeah, it obviously has to happen at compilation time 01:27
timotimo there could either be an op that gets that registered datastructure at the time we create the backtrace
or the resolution of lines/filenames would happen in C code, in which case it'd not have to go through an op to fetch the data 01:28
you were working on this in C code? or in p6/nqp land?
MasterDuke c
timotimo OK
MasterDuke src/core/exceptions.c
timotimo so imagine you could just frame->staticframe->line_annotations 01:29
and get something where you could iterate or binary-search or something
MasterDuke yeah, i've been trying to file where line_number gets set for an annotation, but haven't found it yet 01:31
timotimo oh
that one's easy
it grabs it off a QAST node's "node" attribute 01:32
which is the match object that created it
MasterDuke oh, that happens in nqp? 01:33
timotimo the code that does it lives in the QASTCompilerMAST.nqp i expect 01:34
MasterDuke hm, git grep line_number in nqp shows nothing 01:38
timotimo one sec.
src/vm/moar/QAST/QASTOperationsMAST.nqp: nqp::bindattr_i($obj, MAST::InstructionList, '$!lineno', $lineno); 01:39
MasterDuke ah, thanks 01:40
02:48 ilbot3 joined 06:51 geekosaur joined 08:10 zakharyas joined 08:24 domidumont joined 08:26 vendethiel joined 08:29 domidumont joined 08:34 domidumont joined 09:16 FROGGS joined
FROGGS o/ 09:17
nwc10 \o
jnthn o/ 09:20
09:44 kjs_ joined
FROGGS just opened github.com/ivmai/libatomic_ops/issues/19 10:14
10:18 kjs_ joined
dalek arVM: 0ae47f3 | FROGGS++ | src/moar.h:
workaround missing libatomic_ops prototype on s390x

  See github.com/ivmai/libatomic_ops/issues/19		 10:21
FROGGS .tell nebuchadnezzar Is there anything else I can do for you? otherwise I'd leave it in this state: gist.github.com/FROGGS/9c06ac23b49...aa1687a43c 10:23
yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.
FROGGS .tell domidumont Is there anything else I can do for you? otherwise I'd leave it in this state: gist.github.com/FROGGS/9c06ac23b49...aa1687a43c
yoleaux2 FROGGS: I'll pass your message to domidumont.
11:18 FROGGS[mobile] joined 12:17 FROGGS[mobile]2 joined 14:15 dalek joined 14:32 kjs_ joined 15:14 kjs_ joined 15:27 domidumont joined 15:29 domidumont1 joined
dalek arVM: 0625555 | jnthn++ | src/6model/reprs/ReentrantMutex.c:
Panic when trying to GC a locked mutex.

Otherwise, we will end up with a SIGABRT with no explanation on some platforms, which will be harder to debug.		 15:46
arVM: d87061f | jnthn++ | src/core/exceptions.c:
When we panic, note that's what we're doing.
jnthn So, an interesting nugget 15:47
I got curious how the JVM handles these cases without exploding 15:48
Thankfully, hotspot is open-source so you can find out easily these days ;)
Turns out that they keep a condvar per thread
They define two operations on a thread: park and unpark
When they park a thread, they have it block on a condvar 15:49
The unpark operation on a thread simply signals said condvar
They then implemnet things like ReentrantLock in higher-level code.
Keeping a queue of waiters, which are parked until they reach the head of the queue 15:50
Since the only "real" OS-level mutexes around are just the ones per thread for the condvar, the GC-able things are thus higher level data structures 15:51
So "no problem"
We could at some point consider doing similar :) 15:55
(Of course, real world code that locks, then lets the lock get GC'd, is busted anyway) 15:56
(So that's the real bug I need to now hunt down.)
16:05 kjs_ joined 16:52 domidumont joined
domidumont FROGGS[mobile]2: I'm going to use your s390x patches as well. Thanks a bunch for the work ! :-) 17:29
yoleaux2 10:23Z <FROGGS> domidumont: Is there anything else I can do for you? otherwise I'd leave it in this state: gist.github.com/FROGGS/9c06ac23b49...aa1687a43c
domidumont FROGGS[mobile]2: I think we're fine. Let me upload the package and check what's going on on real hardware. 17:31
FROGGS[mobile]2 \o/ 17:52
19:26 vendethiel- joined 19:53 leedo joined 20:32 FROGGS joined
FROGGS o/ 20:33
t/04-nativecall/02-simple-args.t ......... ok 20:38
Build killed with signal TERM after 150 minutes of inactivity
:o(
ohh, my bad
that was from an old log!!
phew :o)
FROGGS watches buildd.debian.org/status/package.php?p=moarvm and buildd.debian.org/status/package.php?p=rakudo 20:41
21:15 FROGGS joined 21:29 MasterDuke 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!