00:39 carlin joined 01:52 FROGGS_ joined 04:50 carlin joined 05:04 brrt joined
brrt i'm looking for a way to trigger sp_guardconc directly 05:21
ok, found a way 05:51
oh.... i see 06:00
do you know what one of the best feelings in the world is? 06:02
when you've finally got something
basically, whenever deopt is called, the JIT jumps right to the exit 06:03
but the jit 'driver' doesn't communicate this information 'upwards 06:04
to the interpeter
i.e. the interpreter doesn't know that deopt already took care of restoring to the proper frame
so it tries to return to it's caller frame, as it would in the case without deopt
which means? that i should communicate the 'return status' of the jit frame upwards, and all will be well 06:08
06:47 FROGGS_ joined
sergot morning o/ 07:07
dalek arVM/moar-jit: 085e89c | (Bart Wiegmans)++ | foo.nqp:
Add specific test for deopt
 07:14
MoarVM/moar-jit: 58ebecc | (Bart Wiegmans)++ | src/ (8 files):
MoarVM/moar-jit: Don't return to upper frame when deopting from JIT
brrt morning sergot
dalek MoarVM/moar-jit:
MoarVM/moar-jit: This fixes a puzzling issue in which deopt was called but
MoarVM/moar-jit: the scripts failed anyway. The cause was that - up until now - the
MoarVM/moar-jit: special 'jit enter' opcode assumed that return from the jit code
MoarVM/moar-jit: is equal to return from the frame, which doesn't hold in deopt
MoarVM/moar-jit: (because deopt restores the frame for you).
MoarVM/moar-jit:
MoarVM/moar-jit: This assumption also wouldn't have held once we had support for
MoarVM/moar-jit: invocations, so good riddance for it :-)
FROGGS_ brrt++ 07:15
brrt thanks :-)
so.much.frustration this caused
FROGGS_ brrt: I love your commit messages :o) good style!
brrt :-)
another learned lesson - always test your assumptions directly 07:18
FROGGS_ troo, assumptions are worthless and should be considered wrong until you've tested them 07:19
07:20 zakharyas joined
FROGGS_ "the correct value must be in there" - and after three hours the opposite proves slaps you in your face :o) 07:20
s/proves/
07:20 lue joined
brrt right :-) 07:21
this was even worse in a way - an assumption that used to be correct and suddenly became incorrect 07:22
and that is far-enough removed so that you don't check it immediately
FROGGS_ yes, you're working with a moving target :o) 07:24
I can tell you, because my v5 suffered from changes like from every three days to a week 07:25
so if I let it rest for a month, it was pain to get it working again... which meant that I have to review like a hundred commits to nqp and reakudo 07:26
brrt :-) oh, that's bad 07:27
FROGGS_ yeah... but now the actions and grammar are no longer nqp, but pure Perl 6... 07:28
its not in the shape as it was with nqp code, but it is way saner this way
brrt not in the shape = not as fast? 07:29
FROGGS_ no, it is failing simple tests
I had to port the expression parser (EXPR), so first it was unable to parse subroutine calls and leading whitespace 07:30
brrt that.... is not so nice, too 07:32
why was it changed from nqp to p6?
07:33 teodozjan joined
FROGGS_ brrt: so I do not have to depend on nqp internal changes that extreemly 07:33
and so it would be a module that can be installed using panda 07:34
brrt oh, fair enough :-)
clever
FROGGS_ yeah, just needs a lot of work to get it straight again
brrt i really should get to grips with perl6 grammars 07:36
teodozjan hi again, how can i diagnose this error? gist.github.com/teodozjan/a51c3c47d20a9ad63e06 07:50
it happens only on moar 07:52
maybe jvm but not on parrot 07:53
brrt hmm, i can't exactly see why 07:54
:-)
you can try perl6-debug-m rather than perl6-m
FROGGS_ also, you can pass --ll-exception to perl6-m to have at least some sort of backtrace 07:57
besides that, you would have to bisect your code, and comment out stuff until it does not explode anymore
then you know the offending line 07:58
teodozjan actually this code never worked on moar that's why I used parrot
FROGGS_ ahh
teodozjan where shall I pass --ll-exception? 08:00
i think I have something wrong compiled
gist.github.com/teodozjan/935462ac0ca2565ef9ff
to debug
brrt hmm 08:04
.tell jnthn i can't actually find a case wherin sp_p6oget_vc is actually called
teodozjan oki typo in option i will paste ll-exception in seconds
gist.github.com/teodozjan/a391c819f6a67c522e38 08:05
brrt looks speshbuggy to me 08:06
or perhaps in nqp-m ?
teodozjan i'm not sure but problem is with JSON::RPC that I use 08:08
if I delay import with require keyword it fails in next file beacause it use the previous class 08:10
brrt it seems unlikely, to be honest, that this issue is really with JSON::RPC 08:14
teodozjan I don't blame library 08:15
FROGGS_ the issue is with moar+JSON::RPC 08:17
teodozjan ok, I've commented out lib and no I'm not sure 08:19
if I replace JSON::RPC::Client.new with "" got same exception 08:21
brrt which version of moar do you have? 08:26
FROGGS_ brrt: AFAIK it fails on HEAD also
brrt hmmm
teodozjan HEAD 08:27
brrt i wish i could help, but i'm sorry, i can't yet 08:30
teodozjan I think i isolated this 08:31
gist.github.com/teodozjan/e8188ad37d454e16f493
providing right login data do not change anything 08:34
no network traffic at all 08:39
brrt your exception earlier really made me think it is an issue with regard to the nqp compiler 08:40
or maybe spesh
and that this is something JSON::RPC triggers
teodozjan is there any hack i can do in my code or I have to wait for fix? 08:46
shall I send last gist to rakudobug email or anywhere else like github project of nqp? 08:49
jnthn brrt: I'd have thought we'd call MVM_frame_try_return from inside the JITted code, and bypass calling it in the deopt case, fwiw... 09:00
masak getting this warning in an otherwise immaculate Moar compilation process: gist.github.com/masak/45c75a913faff269c728 09:16
09:20 FROGGS joined
masak fails in his own attempts to fix it, due to insuffecient fu in casting function pointers 09:33
but having looked at it, I think that's all it takes. 09:35
jnthn masak: Can you try this patch? gist.github.com/jnthn/f749275e8a9485bb835a 09:48
oh, wait...grr
nwc10 jnthn should be trying the patch first? :-)
FROGGS I have a patch that fixes the warning 09:49
jnthn masak: Updated gist
bah, now we have two :P 09:50
FROGGS see comment in the gist :o)
masak looks 09:51
jnthn brrt: sp_p6oget_vc probably is not triggered anywhere in NQP
FROGGS better now two patches than two problems
jnthn brrt: It's used in Rakudo heavily, though.
masak I like FROGGS' solution better. it seems to work. building from scratch just to be sure. 09:52
dalek arVM: dacddef | masak++ | src/core/nativecall.c:
[nativecall.c] add a cast to get rid of a warning
 09:54
masak dang, forgot to credit FROGGS++, sorry.
FROGGS hehe, no problem :o)
nice to be warning free.... 09:55
I always fear that I did silly mistakes and that I won't see them when compiling nqp-p
because nobody can review that huge output
masak yeah, I never liked that. 09:56
<insert parable of the broken window here>
brrt jnthn; wrt to calling MVM_frame_try_return ehm..... no, because i want to use the return value to determine the offset of my next jump in when invoking stuff, and if i call MVM_try_return from the JIT, that return value has to be propagated to the interpreter instead, because otherwise the interpreter doesn't know if it should jump out of the loop or not 10:04
basically, when invoking, i'll have to communicate 'this is my entry on reentry' - basically the return point - explicitly 10:05
jnthn brrt: Yeah, of course you can't call exactly that; I more meant that removing the frame maybe wanted to be done in something called from the JITted code... 10:06
brrt my plan was to use the following properties - invocations are always end-of-basic-blocks, basic blocks always have labels assigned, so the continuation of of an invocation is simply the (address of the) label of the next block 10:07
well, i'm ambivalent to it :-) calling from jit certainly is simple enough, and a 'normal' frame is also responsible for entering 'itself' as it were 10:08
and leaving itself 10:09
jnthn *nod* 10:10
brrt on the other hand, there's the propagation-of-information issue that i just mentioned ; i.e. i'd /like/ to use the return value to hold the label of the next continuation (or 0 if at the end, or -1 if at deopt), so that any complicated pointer wiring to store the continuation could be done in c code
jnthn That also seems like a feasible approach. 10:12
brrt the other argument is that storing the continuation would be the job of the (whateever) special jit-to-moar invoke function i'd write 10:20
and in that case, the return value becomes usable for the return value of try_return again
anyway
i'm lunching again :-)
10:21 brrt left
nwc10 jnthn^ 10:49
(given that you have managed to forget once)
10:59 brrt joined
brrt \o 10:59
nwc10 o/
brrt bye :-) 11:12
11:12 brrt left 12:41 carlin joined 13:15 cognominal joined
tadzik Can't compile simple gcc probe, so something is badly wrong at build/probe.pm line 92 :} 13:32
jnthn ugh 13:34
Retry it?
Do you have gcc handy?
(like, in path...)
tadzik I think so. I have to investigate more, I was just amused by the message 13:37
I'm trying to build moar for sailfish OS, and I have little to no idea what this SDK is actually doing
jnthn ah, k :)
"some is badly wrong" :
nwc10 cross compiling?
jnthn grr...my ) key on this laptop is still badly wrong...
tadzik nwc10: yes 13:38
nwc10 does cross compiling work yet?
tadzik hmm, I hope so. Does it not
?
nwc10 well, has anyone else done it before and made it work?
tadzik I mean, I knew you were building stuff on raspi, but I didn't think that's because you can't do it any other way 13:39
jnthn Not that I know of, but I don't know everything :)
tadzik jnthn, nwc10: ok, can confirm, cross-compiling works :) Tilt your head, it's worth it: i.imgur.com/TF3JcEx.jpg 14:26
it's running on my phone 14:27
now I should be able to compile rakudo in a specific way and then just put bytecode on my phone, aye?
jnthn Yeah...thing the paths matter, but that aside should work 14:28
Will need NQP too of course...
But if you build both and copy the install directory, should be ok
tadzik nah, it'll have /home/tadzik inside, I'm afraid :/ 14:30
that's what happened when I was toying with including moarakudo with my games
14:38 btyler joined
jnthn decommute & 14:58
15:12 FROGGS joined 15:16 FROGGS joined
tadzik aw, Bus Error on both nqp and perl6 :( 15:17
15:41 btyler joined
[Coke] src/core/nativecall.c: In function ā€˜unmarshal_callbackā€™: 15:45
src/core/nativecall.c:383:9: warning: passing argument 2 of ā€˜dcbNewCallbackā€™ from incompatible pointer type [enabled by default]
FROGGS [Coke]: this is meant to be fixed since last commit or so 15:56
[Coke] I just updated. 15:59
HEAD detached at 6b458f7 (oh. was nqp/rakudo version bumps not done?)
FROGGS no, no bump
[Coke] that'd do it. 16:00
FROGGS yeah, you're missing two commits
dalek arVM/nativecast: 37263f6 | sergot++ | / (8 files):
MVM_nativecall_cast added

MVM_nativecall_cast has been added which provides casting an OpaquePointer to any type we want. It makes us able to unpack things conditionally.		 16:04
arVM/nativecast: a386dd1 | (Tobias Leich)++ | / (8 files):
Merge branch 'master' of github.com:sergot/MoarVM into nativecast
FROGGS hmmmm, why did I do this? 16:05
does not make that much sense actually..
(but will create a topic branch for nqp)
18:07 cognominal joined 18:10 btyler joined
nebuchadnezzar can someone review my patches and tell me if it looks good for pull request? NB: It will require some changes in NQP and rakudo: github.com/baby-gnu/MoarVM/commits...irectories 19:32
time to eat
FROGGS nebuchadnezzar: the patches itself look good, but usually one describes the change in the commit title, not how it was before 19:42
because when you skim the commit log, you want to know what a commit does 19:43
dalek arVM/moar-jit: effd534 | (Bart Wiegmans)++ | src/jit/ (4 files):
Re-enable sp_p6ogetvt_o
 19:46
arVM/moar-jit: 21dcee0 | (Bart Wiegmans)++ | src/jit/graph.c:
Re-enable sp_p6ogetvc_o, doesn't seem to cause bugs
timotimo i wonder what brrt's next steps will be 20:41
FROGGS timotimo: I know your next step :o) 20:43
timotimo oh? what is it? 20:46
FROGGS muse about that --> github.com/jnthn/zavolaj/issues/43 20:52
:o)
timotimo er ... i have no idea >_> 20:57
callbacks have been "nice and easy" so far because they could just be put into a signature 20:58
FROGGS yes, question is how we wanna have it... 21:33
timotimo i guess we can have it any way we like? %) 21:34
FROGGS because you usually do not stick methods between attributes
I guess so, yes
timotimo my &foo is fpointer?
FROGGS the 'has &.foo' form should do it I think, because the order matters and it is a member of the struct 21:35
a lexical?
timotimo er
has, yes
if you have a function pointer lying around, you'll have it as a lexical
it'll be more interesting how to handle functions returning function pointers 21:36
FROGGS m: class Foo { has &.bar = sub (Int) { 42 } }; say Foo.new.bar
camelia rakudo-moar 44d535: OUTPUTĀ«sub (Int) { #`(Sub|140468809477088) ... }ā¤Ā»
FROGGS m: class Foo { has &.bar := sub (Int) { 42 } }; say Foo.new.bar
camelia rakudo-moar 44d535: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/EP0NHjjH6nā¤Cannot use := to initialize an attributeā¤at /tmp/EP0NHjjH6n:1ā¤------> ass Foo { has &.bar := sub (Int) { 42 } ā}; say Foo.new.barā¤ expecting any of:ā¤ ā€¦Ā»
FROGGS m: class Foo { has &.bar = sub (Int) { 42 } }; say Foo.new.bar.(21) # I guess that is okay
camelia rakudo-moar 44d535: OUTPUTĀ«42ā¤Ā»
FROGGS timotimo: well, should be able to cast a pointer into a sub 21:37
timotimo aye.
but it shouldn't become a piece of boilerplate you'll have to repeat over and over to implement function-pointer-heavy apis like opengl's extensions? 21:38
FROGGS ha! right now I ported nativecast to jvm successfully :o)
timotimo sweet!
FROGGS (just took two hours)
hmmmm, I'd have to think about how the P6 code could look like to answer that 21:39
I mean, you could predeclare subs, and later attach the function pointer to it or so 21:40
jnthn Is there not a syntax like &foo:(sig here) ? 21:59
sergot good night! 22:00
jnthn S02 mentions &foo:(Int,Num)
timotimo oh, i didn't know about that 22:01
that's interesting
looking at #perl6, though, that doesn't seem implemented
and reacts quite strangely.
i can't even --target=ast that :) 22:02
i can't even --target=parse that!
jnthn I don't actually knwo how it parses 22:06
Would have to look at STD
But if we can make it work somehow it could help a lot.
timotimo i'm not quite sure what exactly it should do once it's parsed
shoud it set a Callable[...] type constraint? 22:07
do we even have that?
jnthn Callable[Foo] means a Callable that returns a Foo 22:09
timotimo do we have a role for "returns"?
er
jnthn We could introduce it as some other kind of type, mind...
timotimo for the signature
jnthn I don't know exaclty how to do it at the MOP level off hand. 22:10
Will ponder it.
It wants to be something you can nqp::istype against (and thus smart-match against), I guess.
And also introspect to get the signature, which is what NativeCall desires.
timotimo aye, it seems like a big problem with a bunch of implications all over 22:12
jnthn Well, having a MOP opens us to supporting different kinds of type
We already have classes, roles, enums, subsets... :) 22:13
timotimo well, yes, that's right
jnthn So I think we can have something like this :) 22:24
Prolly, anyway. 22:25

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!