Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-04

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:39 carlin joined #moarvm
01:52 FROGGS_ joined #moarvm
04:50 carlin joined #moarvm
05:04 brrt joined #moarvm
05:21 brrt i'm looking for a way to trigger sp_guardconc directly
05:51 brrt ok, found a way
06:00 brrt oh.... i see
06:02 brrt do you know what one of the best feelings in the world is?
06:02 brrt when you've finally got something
06:03 brrt basically, whenever deopt is called, the JIT jumps right to the exit
06:04 brrt but the jit 'driver' doesn't communicate this information 'upwards
06:04 brrt to the interpeter
06:04 brrt i.e. the interpreter doesn't know that deopt already took care of restoring to the proper frame
06:04 brrt so it tries to return to it's caller frame, as it would in the case without deopt
06:08 brrt which means? that i should communicate the 'return status' of the jit frame upwards, and all will be well
06:47 FROGGS_ joined #moarvm
07:07 sergot morning o/
07:14 dalek MoarVM/moar-jit: 085e89c | (Bart Wiegmans)++ | foo.nqp:
07:14 dalek MoarVM/moar-jit: Add specific test for deopt
07:14 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/085e89ccf5
07:14 dalek MoarVM/moar-jit: 58ebecc | (Bart Wiegmans)++ | src/ (8 files):
07:14 dalek MoarVM/moar-jit: Don't return to upper frame when deopting from JIT
07:14 brrt morning sergot
07:14 dalek MoarVM/moar-jit:
07:14 dalek MoarVM/moar-jit: This fixes a puzzling issue in which deopt was called but
07:14 dalek MoarVM/moar-jit: the scripts failed anyway. The cause was that - up until now - the
07:14 dalek MoarVM/moar-jit: special 'jit enter' opcode assumed that return from the jit code
07:14 dalek MoarVM/moar-jit: is equal to return from the frame, which doesn't hold in deopt
07:14 dalek MoarVM/moar-jit: (because deopt restores the frame for you).
07:14 dalek MoarVM/moar-jit:
07:14 dalek MoarVM/moar-jit: This assumption also wouldn't have held once we had support for
07:14 dalek MoarVM/moar-jit: invocations, so good riddance for it :-)
07:15 FROGGS_ brrt++
07:15 brrt thanks :-)
07:15 brrt so.much.frustration this caused
07:15 FROGGS_ brrt: I love your commit messages :o)  good style!
07:15 brrt :-)
07:18 brrt another learned lesson - always test your assumptions directly
07:19 FROGGS_ troo, assumptions are worthless and should be considered wrong until you've tested them
07:20 zakharyas joined #moarvm
07:20 FROGGS_ "the correct value must be in there" - and after three hours the opposite proves slaps you in your face :o)
07:20 FROGGS_ s/proves/
07:20 lue joined #moarvm
07:21 brrt right :-)
07:22 brrt this was even worse in a way - an assumption that used to be correct and suddenly became incorrect
07:22 brrt and that is far-enough removed so that you don't check it immediately
07:24 FROGGS_ yes, you're working with a moving target :o)
07:25 FROGGS_ I can tell you, because my v5 suffered from changes like from every three days to a week
07:26 FROGGS_ 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:27 brrt :-) oh, that's bad
07:28 FROGGS_ yeah... but now the actions and grammar are no longer nqp, but pure Perl 6...
07:28 FROGGS_ its not in the shape as it was with nqp code, but it is way saner this way
07:29 brrt not in the shape = not as fast?
07:29 FROGGS_ no, it is failing simple tests
07:30 FROGGS_ I had to port the expression parser (EXPR), so first it was unable to parse subroutine calls and leading whitespace
07:32 brrt that.... is not so nice, too
07:32 brrt why was it changed from nqp to p6?
07:33 teodozjan joined #moarvm
07:33 FROGGS_ brrt: so I do not have to depend on nqp internal changes that extreemly
07:34 FROGGS_ and so it would be a module that can be installed using panda
07:34 brrt oh, fair enough :-)
07:34 brrt clever
07:34 FROGGS_ yeah, just needs a lot of work to get it straight again
07:36 brrt i really should get to grips with perl6 grammars
07:50 teodozjan hi again, how can i diagnose this error? https://gist.github.com/teodozjan/a51c3c47d20a9ad63e06
07:52 teodozjan it happens only on moar
07:53 teodozjan maybe jvm but not on parrot
07:54 brrt hmm, i can't exactly see why
07:54 brrt :-)
07:54 brrt you can try perl6-debug-m rather than perl6-m
07:57 FROGGS_ also, you can pass --ll-exception to perl6-m to have at least some sort of backtrace
07:57 FROGGS_ besides that, you would have to bisect your code, and comment out stuff until it does not explode anymore
07:58 FROGGS_ then you know the offending line
07:58 teodozjan actually this code never worked on moar that's why I used parrot
07:58 FROGGS_ ahh
08:00 teodozjan where shall I pass --ll-exception?
08:00 teodozjan i think I have something wrong compiled
08:00 teodozjan https://gist.github.com/teodozjan/935462ac0ca2565ef9ff
08:00 teodozjan to debug
08:04 brrt hmm
08:04 brrt .tell jnthn i can't actually find a case wherin sp_p6oget_vc is actually called
08:04 teodozjan oki typo in option i will paste ll-exception in seconds
08:05 teodozjan https://gist.github.com/teodozjan/a391c819f6a67c522e38
08:06 brrt looks speshbuggy to me
08:06 brrt or perhaps in nqp-m ?
08:08 teodozjan i'm not sure but problem is with JSON::RPC that I use
08:10 teodozjan if I delay import with require keyword it fails in next file beacause it use the previous class
08:14 brrt it seems unlikely, to be honest, that this issue is really with JSON::RPC
08:15 teodozjan I don't blame library
08:17 FROGGS_ the issue is with moar+JSON::RPC
08:19 teodozjan ok, I've commented out lib and no I'm not sure
08:21 teodozjan if I replace JSON::RPC::Client.new with "" got same exception
08:26 brrt which version of moar do you have?
08:26 FROGGS_ brrt: AFAIK it fails on HEAD also
08:26 brrt hmmm
08:27 teodozjan HEAD
08:30 brrt i wish i could help, but i'm sorry, i can't yet
08:31 teodozjan I think i isolated this
08:31 teodozjan https://gist.github.com/teodozjan/e8188ad37d454e16f493
08:34 teodozjan providing right login data do not change anything
08:39 teodozjan no network traffic at all
08:40 brrt your exception earlier really made me think it is an issue with regard to the nqp compiler
08:40 brrt or maybe spesh
08:40 brrt and that this is something JSON::RPC triggers
08:46 teodozjan is there any hack i can do in my code or I have to wait for fix?
08:49 teodozjan shall I send last gist to rakudobug email or anywhere else like github project of nqp?
09:00 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:16 masak getting this warning in an otherwise immaculate Moar compilation process: https://gist.github.com/masak/45c75a913faff269c728
09:20 FROGGS joined #moarvm
09:33 * masak fails in his own attempts to fix it, due to insuffecient fu in casting function pointers
09:35 masak but having looked at it, I think that's all it takes.
09:48 jnthn masak: Can you try this patch? https://gist.github.com/jnthn/f749275e8a9485bb835a
09:48 jnthn oh, wait...grr
09:48 nwc10 jnthn should be trying the patch first? :-)
09:49 FROGGS I have a patch that fixes the warning
09:49 jnthn masak: Updated gist
09:50 jnthn bah, now we have two :P
09:50 FROGGS see comment in the gist :o)
09:51 * masak looks
09:51 jnthn brrt: sp_p6oget_vc probably is not triggered anywhere in NQP
09:51 FROGGS better now two patches than two problems
09:51 jnthn brrt: It's used in Rakudo heavily, though.
09:52 masak I like FROGGS' solution better. it seems to work. building from scratch just to be sure.
09:54 dalek MoarVM: dacddef | masak++ | src/core/nativecall.c:
09:54 dalek MoarVM: [nativecall.c] add a cast to get rid of a warning
09:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dacddef6da
09:54 masak dang, forgot to credit FROGGS++, sorry.
09:54 FROGGS hehe, no problem :o)
09:55 FROGGS nice to be warning free....
09:55 FROGGS I always fear that I did silly mistakes and that I won't see them when compiling nqp-p
09:55 FROGGS because nobody can review that huge output
09:56 masak yeah, I never liked that.
09:56 masak <insert parable of the broken window here>
10:04 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:05 brrt basically, when invoking, i'll have to communicate 'this is my entry on reentry' - basically the return point - explicitly
10:06 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:07 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:08 brrt 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:09 brrt and leaving itself
10:10 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
10:12 jnthn That also seems like a feasible approach.
10:20 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 brrt and in that case, the return value becomes usable for the return value of try_return again
10:20 brrt anyway
10:20 brrt i'm lunching again :-)
10:21 brrt left #moarvm
10:49 nwc10 jnthn^
10:49 nwc10 (given that you have managed to forget once)
10:59 brrt joined #moarvm
10:59 brrt \o
10:59 nwc10 o/
11:12 brrt bye :-)
11:12 brrt left #moarvm
12:41 carlin joined #moarvm
13:15 cognominal joined #moarvm
13:32 tadzik Can't compile simple gcc probe, so something is badly wrong at build/probe.pm line 92 :}
13:34 jnthn ugh
13:34 jnthn Retry it?
13:34 jnthn Do you have gcc handy?
13:34 jnthn (like, in path...)
13:37 tadzik I think so. I have to investigate more, I was just amused by the message
13:37 tadzik I'm trying to build moar for sailfish OS, and I have little to no idea what this SDK is actually doing
13:37 jnthn ah, k :)
13:37 jnthn "some is badly wrong" :
13:37 nwc10 cross compiling?
13:37 jnthn grr...my ) key on this laptop is still badly wrong...
13:38 tadzik nwc10: yes
13:38 nwc10 does cross compiling work yet?
13:38 tadzik hmm, I hope so. Does it not
13:38 tadzik ?
13:38 nwc10 well, has anyone else done it before and made it work?
13:39 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 :)
14:26 tadzik jnthn, nwc10: ok, can confirm, cross-compiling works :) Tilt your head, it's worth it: http://i.imgur.com/TF3JcEx.jpg
14:27 tadzik it's running on my phone
14:27 tadzik now I should be able to compile rakudo in a specific way and then just put bytecode on my phone, aye?
14:28 jnthn Yeah...thing the paths matter, but that aside should work
14:28 jnthn Will need NQP too of course...
14:28 jnthn But if you build both and copy the install directory, should be ok
14:30 tadzik nah, it'll have /home/tadzik inside, I'm afraid :/
14:30 tadzik that's what happened when I was toying with including moarakudo with my games
14:38 btyler joined #moarvm
14:58 jnthn decommute &
15:12 FROGGS joined #moarvm
15:16 FROGGS joined #moarvm
15:17 tadzik aw, Bus Error on both nqp and perl6 :(
15:41 btyler joined #moarvm
15:45 [Coke] src/core/nativecall.c: In function ‘unmarshal_callback’:
15:45 [Coke] src/core/nativecall.c:383:9: warning: passing argument 2 of ‘dcbNewCallback’ from incompatible pointer type [enabled by default]
15:56 FROGGS [Coke]: this is meant to be fixed since last commit or so
15:59 [Coke] I just updated.
15:59 [Coke] HEAD detached at 6b458f7 (oh. was nqp/rakudo version bumps not done?)
15:59 FROGGS no, no bump
16:00 [Coke] that'd do it.
16:00 FROGGS yeah, you're missing two commits
16:04 dalek MoarVM/nativecast: 37263f6 | sergot++ | / (8 files):
16:04 dalek MoarVM/nativecast: MVM_nativecall_cast added
16:04 dalek MoarVM/nativecast:
16:04 dalek MoarVM/nativecast: MVM_nativecall_cast has been added which provides casting an
16:04 dalek MoarVM/nativecast: OpaquePointer to any type we want. It makes us able to unpack things
16:04 dalek MoarVM/nativecast: conditionally.
16:04 dalek MoarVM/nativecast: review: https://github.com/MoarVM/MoarVM/commit/37263f65d8
16:04 dalek MoarVM/nativecast: a386dd1 | (Tobias Leich)++ | / (8 files):
16:04 dalek MoarVM/nativecast: Merge branch 'master' of github.com:sergot/MoarVM into nativecast
16:04 dalek MoarVM/nativecast: review: https://github.com/MoarVM/MoarVM/commit/a386dd12f3
16:05 FROGGS hmmmm, why did I do this?
16:05 FROGGS does not make that much sense actually..
16:05 FROGGS (but will create a topic branch for nqp)
18:07 cognominal joined #moarvm
18:10 btyler joined #moarvm
19:32 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: https://github.com/baby-gnu/MoarVM/commits/feature/parameterized-target-directories
19:32 nebuchadnezzar time to eat
19:42 FROGGS nebuchadnezzar: the patches itself look good, but usually one describes the change in the commit title, not how it was before
19:43 FROGGS because when you skim the commit log, you want to know what a commit does
19:46 dalek MoarVM/moar-jit: effd534 | (Bart Wiegmans)++ | src/jit/ (4 files):
19:46 dalek MoarVM/moar-jit: Re-enable sp_p6ogetvt_o
19:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/effd534998
19:46 dalek MoarVM/moar-jit: 21dcee0 | (Bart Wiegmans)++ | src/jit/graph.c:
19:46 dalek MoarVM/moar-jit: Re-enable sp_p6ogetvc_o, doesn't seem to cause bugs
19:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/21dcee00bd
20:41 timotimo i wonder what brrt's next steps will be
20:43 FROGGS timotimo: I know your next step :o)
20:46 timotimo oh? what is it?
20:52 FROGGS muse about that --> https://github.com/jnthn/zavolaj/issues/43
20:52 FROGGS :o)
20:57 timotimo er ... i have no idea >_>
20:58 timotimo callbacks have been "nice and easy" so far because they could just be put into a signature
21:33 FROGGS yes, question is how we wanna have it...
21:34 timotimo i guess we can have it any way we like? %)
21:34 FROGGS because you usually do not stick methods between attributes
21:34 FROGGS I guess so, yes
21:34 timotimo my &foo is fpointer?
21:35 FROGGS the 'has &.foo' form should do it I think, because the order matters and it is a member of the struct
21:35 FROGGS a lexical?
21:35 timotimo er
21:35 timotimo has, yes
21:35 timotimo if you have a function pointer lying around, you'll have it as a lexical
21:36 timotimo 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
21:36 camelia rakudo-moar 44d535: OUTPUT«sub (Int) { #`(Sub|140468809477088) ... }␤»
21:36 FROGGS m: class Foo { has &.bar := sub (Int) { 42 } }; say Foo.new.bar
21:36 camelia rakudo-moar 44d535: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/EP0NHjjH6n␤Cannot use := to initialize an attribute␤at /tmp/EP0NHjjH6n:1␤------> [32mass Foo { has &.bar := sub (Int) { 42 } [33m⏏[31m}; say Foo.new.bar[0m␤    expecting any of:␤    …»
21:36 FROGGS m: class Foo { has &.bar = sub (Int) { 42 } }; say Foo.new.bar.(21) # I guess that is okay
21:36 camelia rakudo-moar 44d535: OUTPUT«42␤»
21:37 FROGGS timotimo: well, should be able to cast a pointer into a sub
21:37 timotimo aye.
21:38 timotimo 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)
21:38 timotimo sweet!
21:38 FROGGS (just took two hours)
21:39 FROGGS hmmmm, I'd have to think about how the P6 code could look like to answer that
21:40 FROGGS I mean, you could predeclare subs, and later attach the function pointer to it or so
21:59 jnthn Is there not a syntax like &foo:(sig here) ?
22:00 sergot good night!
22:00 jnthn S02 mentions &foo:(Int,Num)
22:01 timotimo oh, i didn't know about that
22:01 timotimo that's interesting
22:01 timotimo looking at #perl6, though, that doesn't seem implemented
22:01 timotimo and reacts quite strangely.
22:02 timotimo i can't even --target=ast that :)
22:02 timotimo i can't even --target=parse that!
22:06 jnthn I don't actually knwo how it parses
22:06 jnthn Would have to look at STD
22:06 jnthn But if we can make it work somehow it could help a lot.
22:06 timotimo i'm not quite sure what exactly it should do once it's parsed
22:07 timotimo shoud it set a Callable[...] type constraint?
22:07 timotimo do we even have that?
22:09 jnthn Callable[Foo] means a Callable that returns a Foo
22:09 timotimo do we have a role for "returns"?
22:09 timotimo er
22:09 jnthn We could introduce it as some other kind of type, mind...
22:09 timotimo for the signature
22:10 jnthn I don't know exaclty how to do it at the MOP level off hand.
22:10 jnthn Will ponder it.
22:10 jnthn It wants to be something you can nqp::istype against (and thus smart-match against), I guess.
22:10 jnthn And also introspect to get the signature, which is what NativeCall desires.
22:12 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
22:13 jnthn We already have classes, roles, enums, subsets... :)
22:13 timotimo well, yes, that's right
22:24 jnthn So I think we can have something like this :)
22:25 jnthn Prolly, anyway.

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary