dalek kudo/nom: 5cee2ee | leont++ | src/core/Proc/Async.pm:
Call :done/:quit on Supplies from Proc::Async
 01:14
kudo/nom: c4f04dc | timo++ | src/core/Proc/Async.pm:
Merge pull request #745 from Leont/async-done

Call :done/:quit on Supplies from Proc::Async
03:34 hankache joined 04:07 bros joined 05:02 geekosaur joined 07:55 MadcapJake_ joined 07:57 b2gills joined 08:06 masak_ joined 08:07 lucs_ joined, perlpilot joined 08:08 nine_ joined 08:14 Woodi joined 08:20 b2gills joined 08:33 vendethiel joined 10:30 RabidGravy joined
psch i find myself trying to get R-J at least compiling, if not passing roast, for the release 11:18
that's not particularly misguided, is it..? :)
11:19 jnthn joined
timotimo depends; the release notes will probably still recommend against using r-j 11:19
psch right, but having it at least work would be nice, i'd think 11:20
'cause right now it seems to NPE somewhere during install-core-dist.pl
timotimo i think it really depends on what you'd otherwise do with the time until the release :) 11:21
psch well, and when nqp::create()ing CompilerServices, but that's caught and probably fine
general bug triage, probably
which, mostly, means poking at things a little and putting into RT what little i find out... 11:22
timotimo and it depends on what you feel like doing :)
psch "Stage parse : 798.985" heh 11:24
timotimo build r-m on a raspberry pi 1? :D 11:25
psch no, hit a break point somewhere underlying Perl6::World 11:26
timotimo ah
psch the CompilerServices thing mentioned above
not sure how exactly that works out as an NPE, though
apparently st.RERPData.instance is null 11:27
timotimo ".instance" doesn't ring a bell to me; must be something -j specific
psch well, nqp::create() calls Ops.create, which calls obj.st.REPR.allocate(tc, obj.st) 11:30
and allocate calls st.REPRData.instance.instClone()
so i'd guess .instance is where we stash an instance of every object..?
timotimo REPRData is repr-specific, at least, so it'd depend strongly on what that is implemented like 11:31
so, looking at the p6opaque repr in java-land is interesting? 11:32
it's been so long since i last looked at the jvm implementation
psch the only thing that stands out is that Rakudo::Internals::CompilerServices is our-scoped 11:33
timotimo :\ 11:35
psch well, and the REPRData is full of meaningless data 11:37
every object field is null, all the slot hints are -1, the multiple inheritance hint is false 11:38
...the last one probably isn't "meaningless", but...
timotimo meaningless, perhaps even corrupted?
psch but yeah, it's not a build-stopper in any case
hm, no idea how that could've happened... 11:39
i mean, corruption
timotimo right, it'd be unlikely 11:40
the slot hints being -1 seems unproblematic 11:41
psch yeah
timotimo dunno what the other fields are about without looking closely
psch but we should definitely have a jvmClass in the REPRData
timotimo perhaps some of them being null is bad?
but the compilation of CompilerServices is long done, right? 11:42
i mean, you can get by without having the compiler services; it's mostly an optimization and if it's unset, it'll just not be used
psch yeah, i get that
hm, might be that it doesn't get composed in time 11:43
that's one of the things that sets .instance
the others are .changeType and .deserialize_repr_data
well, not composed in time seems unlikely, except if r-j parses and compiles in a different order
timotimo right, that could be strange 11:45
psch in any case, we don't have CompilerServices for r-j, so it just tries to instantiate, fails, and carries on without them 11:46
which is probably the right call for now anyway
timotimo oh, right, you said that that gets caught properly
psch yeah. it's definitely weird, but it's not what i was looking for :)
RabidGravy Something that I can't seem to work out and is quite annoying, if I have something like: 11:51
role Foo[::Bap = Int] { my class Bop { has Bap $.bap; } has Bop $.bop; }; my $c = class :: does Foo[Str] { }; 11:52
then the "Bap" on the inner class doesn't get "de-genericized" in the same way that it would if it was in the main role 11:53
psch m: role Foo[::Bap = Int] { my class Bop { has Bap $.bap; } has Bop $.bop; }; my $c = class :: does Foo[Str] { }; $c.bop.WHAT.say
camelia rakudo-moar c4f04d: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/Q1vhK41h2kā¤Strange text after block (missing semicolon or comma?)ā¤at /tmp/Q1vhK41h2k:1ā¤------> = Int] { my class Bop { has Bap $.bap; }ā has Bop $.bop; }; my $c = class :: doesā¤ expecting anā€¦Ā»
psch m: role Foo[::Bap = Int] { my class Bop { has Bap $.bap; }; has Bop $.bop; }; my $c = class :: does Foo[Str] { }; $c.bop.WHAT.say
camelia rakudo-moar c4f04d: OUTPUTĀ«Cannot look up attributes in a type objectā¤ in block <unit> at /tmp/pmhf7Hhq8a line 1ā¤ā¤Ā»
psch m: role Foo[::Bap = Int] { my class Bop { has Bap $.bap; }; has Bop $.bop; }; my $c = class :: does Foo[Str] { }; $c.new.bop.WHAT.say 11:54
camelia rakudo-moar c4f04d: OUTPUTĀ«(Bop)ā¤Ā»
psch m: role Foo[::Bap = Int] { my class Bop { has Bap $.bap; }; has Bop $.bop; }; my $c = class :: does Foo[Str] { }; $c.new.bop.bap.WHAT.say
camelia rakudo-moar c4f04d: OUTPUTĀ«Cannot look up attributes in a type objectā¤ in block <unit> at /tmp/8vJgiQ6mJ7 line 1ā¤ā¤Ā»
psch m: role Foo[::Bap = Int] { my class Bop { has Bap $.bap; }; has Bop $.bop; }; my $c = class :: does Foo[Str] { }; $c.new.bop.new.bap.WHAT.say
camelia rakudo-moar c4f04d: OUTPUTĀ«Method 'say' not found for invocant of class 'Bap'ā¤ in block <unit> at /tmp/fDZqfOmKAw line 1ā¤ā¤Ā»
psch confirms :P
RabidGravy yeah, this because it is still a GenericHOW 11:55
it's quite upsetting as I can't see a way round it without creating the type completely on the fly 11:58
psch hrm, install-core-dist.pl under jdb is *really* slow... 12:05
...actually, that's not really true i suppose 12:06
as in, it clocks in at 0.0% cpu in top..?
timotimo install-core-dist.pl also takes a while on rakudo itself ... but yours seems like it's deadlocked or something? 12:07
psch i guess 12:09
psch times it without jdb
it did get somewhere before, that's why i found the NPE there after all... :) 12:10
timotimo hack.p6c.org/~timo/ - the "current path" thing has been soooo flat over the last days :( 12:11
psch hmm, 33 seconds until the NPE when ran without jdb 12:13
well, real 12:14
12:19 pmurias joined
dalek p: d953b19 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Improve NativeRef stub.
 12:21
p: a09685d | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
[js] Make some NIY error temporarly less deadly.
p: 26bf331 | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Add a prefix when mangling names to avoid collision with say a builtin Array
p: af84c5e | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp:
[js] Implement the fail regex anchor.
psch liberally sprinkles CUR::Installation.install with 'say $line'
timotimo i've been known to do that kind of thing, too 12:23
psch well, with jdb somehow locking up i have no idea what else to do... 12:24
gist.github.com/peschwa/8d0409b114...b3074bc5a7 this is the --ll-exception 12:25
i can't really make sense of that, fwiw vOv
timotimo hm, it dies inside precompile? 12:27
psch i'm not sure. i don't think i ever saw two backtraces from --ll-exception 12:28
timotimo right. dunno what's up with that 12:29
13:05 pmurias joined
psch ah, apparently boils down to NativeCall being broken on r-j 13:06
which is a bit unfortunate, as i already looked at that for quite a while and didn't get anywhere... 13:07
"binding of the $!call attribute for role Native" is apparently what doesn't work, if i dug around correctly about 3 weeks ago 13:11
it's a bit weird though how the normal NC failure is about native/ref attr mismatch, while precomp dies with an NPE... 13:15
13:25 awwaiid joined
awwaiid watches over [Coke]'s shoulder IRL 13:27
dalek kudo/nom: 617bb41 | coke++ | docs/announce/2016.04.md:
Add provisional 2016.04 release announcement
 13:43
psch well, the NC code is beyond me vOv 13:52
[Coke] guesses he'll hack on RT stuff instead.
RabidGravy [Coke]++ 13:56
psch ...okay what 13:58
get_attribute_boxed for field_16 is what calls badReference 13:59
badReference is a convenience function in P6Opaque to throw "Cannot access native attribute as reference attribute"
but, field_16 is a reprs.NativeCallBody
now i'm no jvm expert, just dabbling, really 14:00
but i *think* that that's not a native attribute
so either it's wrongfully assumed to be inlineable, or it doesn't properly declare how it wants to be inline and as what kind of native 14:04
oh. but in the end it comes down to nqp::getattr supporting *only* ref attrs, and nqp::getattr_{i,n,s} supporting *only* natives on nqp-j 14:14
[Coke] failing test on roast/master: t/spec/S03-operators/assign.rakudo.moar 14:17
stmuk aren't releases tested against 6.c roast? 14:31
[Coke] they still have to pass all the master tests. 14:42
releases are tested against both.
stmuk ah 14:44
dalek ast: 3ba8006 | coke++ | S03-operators/arith.t:
fix typo in test desc.
 14:48
stmuk grrr I should try make -j n for spectests 14:53
oh actually there was an env var
[Coke] TEST_JOBS=<num cores> make stresstest 14:54
stmuk on linux I see t/spec/S03-operators/assign.rakudo.moar and t/spec/S32-num/power.rakudo.moar fail 14:57
psch hrm, do we have anything in REPR or REPRData that might clue me in what kind of attribute any given attribute is..? 15:00
15:26 Skarsnik joined 15:35 timotimo joined 16:55 jnthn_ joined 17:07 pmurias joined 17:13 geekosaur joined
nine_ psch: on MoarVM there's obj->st->debug_name 17:18
dalek nqp: cbdf5bb | (Stefan Seifert)++ | src/ (4 files): 17:21
nqp: Support for nested compilation
nqp:
nqp: EVALed code is considered an independent compilation unit that gets compiled
nqp: using a new World which contains an independent serialization context. It also
nqp: gets its own QAST compiler.
nqp:
nqp: When a BEGIN time EVAL is run during precompilation of a module, the
nqp: independent SC would not be written into any file but would still be referenced
nqp: from the outer compilation unit. We therefor use the outer world's SC. We also
nqp: need to share a couple of other attributes that keep track of the compilation's
nqp: state.
nine_ [Coke]: oh, I hope the nqp release is already done?
awwaiid I think [Coke] is now traveling 17:23
I got the impression that he paused on all releases 17:24
stmuk I think the test failures are probably blockers 17:26
psch nine_: how does obj.st.debug_name tell me (at runtime) which attributes of obj are native or ref? 17:47
nine_: for context, i'm trying to teach nqp-j to emulate the "autoboxing" behavior for retrieving native attrs with nqp::getattr that nqp-m does
add: debug_name is around on nqp-j, but it just tells me which class (plus mixins) the STable belongs to, which doesn't help me decide which of getattr_{i,s,n} to call 17:48
psch thought [Coke] blocked on the release for the moar release 17:50
cf irclog.perlgeek.de/moarvm/2016-04-17#i_12350674K 17:51
err, irclog.perlgeek.de/moarvm/2016-04-17#i_12350674
oh, hmm, the previous angle with "decide which of getattr_{i,n,s} to call" might be moot anyway 17:52
i just noticed my last debug thingy ran to conclusion with non of getattr{,_i,_n,_s} working for Native[...]!call 17:53
19:11 geekosaur joined 19:20 hankache joined 19:35 geekosaur joined 21:43 timotimo joined 22:00 geekosaur joined 22:09 RabidGravy joined
[Coke] yes, there was no moar release, so nothing else happened. 23:07
[Coke] is done commuting.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!