02:38 colomon joined 02:48 ilbot3 joined
orbus anybody feel like taking a look at a sparc stack trace? 03:02
paste.scsys.co.uk/505729
I've coaxed it into building, but it dumps core as soon as I try to Configure nqp
seems to be an alignment problem 03:03
03:48 colomon joined
orbus that's built on gcc by the way 04:07
07:32 FROGGS joined
FROGGS orbus: nwc10 might be able to give some pointers... I understand too little to help here 07:35
07:53 nebuchadnezzar joined 08:55 zakharyas joined 09:17 kjs_ joined 09:19 kjs_ joined 10:47 donaldh joined 11:55 kjs_ joined 12:03 kjs_ joined 12:53 donaldh joined
orbus .tell FROGGS thanks - I'll wait until nwc10 is around 14:00
oops, no tell bot - oh well, I'll tell him later
14:04 kjs_ joined 14:55 kjs_ joined 16:14 kjs_ joined 16:34 zakharyas joined
timotimo hm. it seems like in order to speed up my current thing, i'd be implementing the extend_i32 op for the jit. and then probably also the others, because why stop at one? 18:18
i got around needing extend_i32, so ... slacking off again :P 18:27
18:33 zakharyas joined
timotimo i.imgur.com/R2aM7fD.png 18:39
nooooo, what are you doing spesh?!? 18:40
whhhhyyyyyyyyyyy
i don't think i've seen code-gen crap out something so bad before 18:41
oh 18:43
that's before inserting the logging
thank god
nwc10 orbus: I apologise - I have rather too much $work and $other to be able to really give you the time that you deserve 19:26
your backtrace doesn't seem to have line numbers. I'm not familiar enough with Solaris tools to know - is this because the thing you used to generate the backtrace doesn't do line numbers? (and gdb would?) 19:27
or because the binary wasn't built with debugging information?
it's pretty much impossible to figure out why it breaks without line numbers
and it might be possible to have a good guess from just a backtrace with linenumbers (and no further information) 19:28
implied - if the binary isn't built with line numbers, I'm not totally sure how to fix that. It might be as simple as needing to re-run Configure.pl for MoarVM adding --debug 19:29
19:51 patrickz joined 19:53 FROGGS joined
FROGGS o/ 19:53
20:07 cognominal_ joined 20:10 FROGGS_ joined 20:12 nine joined 20:14 camelia joined
FROGGS_ wow 20:26
$ perl6 -Ilib -MBox2D::PolygonShape -MNativeCall -e 'my $p = Box2D::PolygonShape.new(:m_type(42)); say nativecast(Box2D::Shape, $p)'
b2Shape.new(vmt => NativeCall::Types::Pointer, m_type => 42, m_radius => 0e0)
I did not even know we can let one CStruct inherit from another
jnthn :)
FROGGS_ do we have that since a long time? 20:27
jnthn I thought so
FROGGS_ nice :o)
jnthn Maybe since the start
Since the repr compose protocol for attrs would almost need you to opt out of handling this case... 20:28
Or put better, it's probably as hard to not support it as it is to support it :)
FROGGS_ hehe 20:29
I like it :o)
arnsholt Yeah, I think it falls out naturally from how classes work 20:32
FROGGS_ yeah
we probably have the best ffi... 20:33
jnthn repr poly really helps 20:40
Still, we've room for further improvement :)
I suspect our push on leaks will show up some FFI bits to address
20:41 Ven joined
arnsholt I know it will 20:45
I think I know how I'd implement a feature to handle freeing of NativeCall objects, but it's those dang tuits =( 20:46
FROGGS_ hmmm, how do I "refresh" a CPPStruct? 20:49
I've got a method that calls into the C++ lib and these method sets some fields
but Perl 6 does not seem to know, and the attributes stay unchanged 20:50
FROGGS_ tries to call refresh
hmmm, no luck 20:56
refresh() is a noop for int/num attributes
that's it for today... 20:58
gnight
timotimo huh, if the structs change but perl6 doesn't see that, that'd really be a problem 21:00
of the "your cpp lib is writing to a copy rather than the original" sort
21:01 Ven joined 21:08 Ven joined 21:36 Ven joined 21:38 Coke__ joined 22:04 Ven joined 23:59 brrt 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!