[02:52] *** vendethiel joined [03:39] *** lucs joined [04:05] *** sortiz joined [04:13] *** ugexe joined [04:18] *** ugexe joined [04:36] *** ugexe joined [05:11] *** skids joined [06:14] <[Tux]> This is Rakudo version 2016.03-131-gbd44009 built on MoarVM version 2016.03-108-gca1a21a [06:14] <[Tux]> test 22.047 [06:14] <[Tux]> test-t 12.635 [06:14] <[Tux]> csv-parser 25.626 [06:52] *** RabidGravy joined [07:43] *** lizmat joined [07:48] *** azawawi joined [07:48] hi [07:49] moritz: it seems that the recently added AppVeyor badge is not working for some reason https://github.com/rakudo/rakudo [07:50] moritz: https://ci.appveyor.com/project/rakudo/rakudo/branch/nom # Project not found or access denied [07:50] azawawi: probably because I only managed to enable it in the appveyor/moritz account [07:51] i see [07:51] https://ci.appveyor.com/project/moritz/rakudo [07:57] m: use nqp; my $b = Blob[uint64].new(42); nqp::rebless($b,Blob[uint8]); dd $b # was hoping this would be a cheap way for converting an int64 into its constituent bytes [07:57] rakudo-moar bd4400: OUTPUT«This REPR cannot change type␤ in block at /tmp/BJqG9pylgh line 1␤␤» [07:58] lizmat: possibly with nativecast? [07:59] * lizmat looks up nativecast [08:00] azawawi moritz: with my PR from yesterday AppVeyor started a build after more than one hour -- but at least the jvm builds timed out after 59 min 59 sec :-( [08:00] lizmat: won't this lead to problems with endianness? [08:00] *** TimToady joined [08:01] nine_: I'll pass that bridge when we get to that :-) [08:03] bartolin: it is fairly slower than travis ci given that it is one per build [08:03] moritz: i guess we can disable some builds for windows. Which do you recommend? [08:09] * lizmat looks at cranes passing by smoothly [08:17] azawawi: disable JVM builds [08:31] moritz: sure [09:29] *** brrt joined [09:32] would be cool if we have something like `rakudobrew build moar --stable' [09:38] fwiw, none of getattr{,_i,_n,_s} works for accessing the $!call Attribute of a Sub+{Native[...]} [09:39] i'm not exactly sure what that means, but i think it's probably codegen, plus maybe precomp [09:41] ahh [09:41] the mixin doesn't work right [09:42] the object that get passed to getattr has a REPRData that includes 4 nameToHintMaps, of which the last one is for role Native [09:42] the hints start at 15 for $!setup [09:43] oh, wait, delegates... [09:43] yeah, that was wrong. the delegate has enough fields, the obj itself doesn't, but that's what a mixin does :/ [10:06] *** pmurias joined [10:27] roast: 4d61fbd | usev6++ | integration/weird-errors.t: [10:27] roast: (Re-)fudge test for RT #127878 for JVM [10:27] roast: review: https://github.com/perl6/roast/commit/4d61fbd7ec [10:36] psch: forgetting some "REAL_DATA" like thing? moar has those all over the place to follow the delegate whenever something's gotten mixed-into [11:11] roast: 70af688 | usev6++ | S (6 files): [11:11] roast: Fudge for JVM to prevent UnwindExceptions [11:11] roast: review: https://github.com/perl6/roast/commit/70af688d2f [11:11] i expected liz would have already written that mail about floats and bufs, but it seemed not so [11:12] so i went ahead and shared that knowledge with the mailing list [11:45] timotimo: i don't think that's the problem. as mentioned, there's no way to getattr for $!call (which has repr('NativeCall')) that doesn't complain [11:45] timotimo: that makes me think that codegen doesn't work out, somehow [11:46] oh, it's repr nativecall! [11:46] have you looked at how the nativecall repr is implemented on the jvm to handle attribute access? [11:47] the nativecall repr is the attribute, fwiw [11:47] oh! [11:47] not the thing, OK [11:47] and that's where it gets extra complicated, kinda :P [11:47] one thing we do during code gen is try to get a hint to supply for the given attribute [11:47] like, nqp-m can use nqp::getattr for a native attribute [11:47] can you try making it non-obvious to the compiler/optimizer what the value is, or turn optimization off altogether? [11:48] then we wouldn't try to give it a hint for the attribute index [11:48] and we may hit a different code path [11:49] --optimize=off does the exact same [11:50] m: use nqp; class A { has int $.x }; say my int $x = nqp::getattr(A.new, A, '$!x') # this i think matters [11:50] rakudo-moar bd4400: OUTPUT«0␤» [11:50] 'cause r-j can't use nqp::getattr for a native attribute [11:50] and inlineBind codegen stuff that wants a native_j [11:52] anyway, i also tried with 'use lib ...' just now, that also dies the same way [11:53] timotimo: i think attr hinting isn't on nqp-j at all. getattr and friends are all hard-coded with STable.NO_HINT [11:54] the optimizer may supply the hint, though? [11:54] roast: c264eab | usev6++ | S0 (4 files): [11:54] roast: Fudge (skip) some tests for JVM [11:54] roast: [11:54] roast: all of those tests die with [11:54] roast: 'Cannot access a native attribute as a reference attribute' [11:54] roast: review: https://github.com/perl6/roast/commit/c264eab586 [11:56] i don't know how: https://github.com/perl6/nqp/blob/master/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java#L2716 [11:56] oh duh [11:56] half a page down... :) [11:56] a-ha! something java has that C doesn't! :) [11:57] ...half pages down? [11:57] i mean, there's a getattr candidate that takes a hint [11:57] yup, i saw those [11:59] hrm [11:59] i'm just getting more confused [11:59] that snippet above with getattr for a native int also works on r-j [11:59] oh wait, that's because i hacked that in there [12:00] it doesn't help for repr NativeCall, though [12:00] oh no we got hacked! [12:00] :( [12:00] yeah, i mean, i'm calling it "hacked" because it's terrible :P [12:00] i don't understand why the getattr without a _ wouldn't work for your case [12:00] https://gist.github.com/peschwa/386df8991a91852c31db9a9e664b379e [12:00] i am perfectly correct calling that a hack :P [12:00] :D [12:01] yup, seems legit [12:01] so, repr NativeCall says it has a 64 bit wide inlined storage spec [12:03] ...we don't have a getattr for tc.native_j [12:05] hm, i don't get it [12:06] *** b2gills joined [12:08] huh, i think that might be the actual problem [12:09] i .. don't even know what native_j is or why we'd have to have a getattr for that?!? [12:09] * psch .oO( that i don't get it ) [12:09] native_j is a java object in the TC [12:10] like, tc.native_i has the result of a obj.get_attribute_native [12:10] and tc.native_j is the same for java objects [12:12] still curious how that hasn't mattered before [12:13] but then it's probably like 4 or so months that it was somewhat broken [12:13] with lots of other breakage inbetween, which might make it hard to find out what caused it... :) [12:13] oh, huh [12:29] roast: dc23077 | usev6++ | S06-advanced/wrap.t: [12:29] roast: Skip another test on JVM [12:29] roast: review: https://github.com/perl6/roast/commit/dc23077272 [12:32] well then [12:32] how oh how do i instantiate a JavaWrap [12:32] 'cause i think that's what i have to do to return the nativecall body from getattr [12:32] roast: 5534e7e | usev6++ | S12-coercion/coercion-types.t: [12:32] roast: Skip test for RT #127841 on JVM [12:32] roast: review: https://github.com/perl6/roast/commit/5534e7e6da [12:34] hm, although that might be wrong. BOOTJava is involved with jvminterop only... [12:36] oh, i think i know what caused this [12:37] hm, no :P [12:50] *** skids joined [12:55] roast: ecf35bc | usev6++ | S32-str/pack.t: [12:55] roast: Skip tests for 'pack' for JVM [12:55] roast: review: https://github.com/perl6/roast/commit/ecf35bc75b [13:26] roast: 96409d3 | usev6++ | S32-io/socket-recv-vs-read.t: [13:26] roast: Skip two more tests on JVM [13:26] roast: review: https://github.com/perl6/roast/commit/96409d3789 [13:40] roast: da9be7b | usev6++ | S32-str/encode.t: [13:40] roast: Fudge utf-16 tests for JVM [13:40] roast: review: https://github.com/perl6/roast/commit/da9be7b53a [14:02] <[Coke]> p6 release should happen tonight. [14:07] roast: 14a9efd | usev6++ | S10-packages/precompilation.t: [14:07] roast: Fudge (todo) some precomp tests for JVM [14:07] roast: review: https://github.com/perl6/roast/commit/14a9efde5a [14:11] S02-types/resolved-in-setting.t does not run at all on rakudo-j. would it make sense to mark that file as 'moar only' in t/spectest.data? [14:12] bartolin: yes [14:20] *** lizmat joined [14:28] roast: b0bdd90 | usev6++ | S02-types/int-uint.t: [14:28] roast: Fudge tests for native int overflow/underflow for JVM [14:28] roast: review: https://github.com/perl6/roast/commit/b0bdd90ab7 [14:35] rakudo/nom: 75b8966 | azawawi++ | appveyor.yml: [14:35] rakudo/nom: Disable JVM CI builds on Windows (AppVeyor) for performance reasons [14:35] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/75b896690f [14:35] rakudo/nom: 1da9193 | lizmat++ | appveyor.yml: [14:35] rakudo/nom: Merge pull request #749 from azawawi/nom [14:35] rakudo/nom: [14:35] rakudo/nom: Disable JVM CI builds on Windows (AppVeyor) for performance reasons [14:35] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1da9193548 [14:36] rakudo/nom: 4bc967a | bartolin++ | t/spectest.data: [14:36] rakudo/nom: Run S02-types/resolved-in-setting.t on moar only [14:36] rakudo/nom: [14:36] rakudo/nom: This file produces an IllegalArgumentException on rakudo-j [14:36] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4bc967a1bf [14:36] rakudo/nom: baf8ac3 | lizmat++ | t/spectest.data: [14:36] rakudo/nom: Merge pull request #750 from usev6/patch-1 [14:36] rakudo/nom: [14:36] rakudo/nom: Run S02-types/resolved-in-setting.t on moar only [14:36] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/baf8ac3777 [14:44] *** lizmat joined [14:55] *** [Sno] joined [14:56] <[Sno]> ah - this channel was meant by lizmat [14:56] * [Sno] is so not-up-to-date :) [14:56] roast: 32110a6 | usev6++ | S17-supply/Channel.t: [14:56] roast: Skip test for RT #127629 on JVM [14:56] roast: [14:56] roast: ... because it often hangs in spectests [14:56] roast: review: https://github.com/perl6/roast/commit/32110a69b0 [14:56] <[Sno]> http://www.netbsd.org/~sno/talks/nrpm/Cross-Compiling-For-Perl-Hackers-Handout.pdf <-- jnthn, timotimo, nine_ ... :) [15:04] <[Sno]> perlpilot: as lizmat suggested, better here :) [15:04] *** lizmat joined [15:04] ah, good point [15:05] <[Sno]> perlpilot: 9/10 talks about host-files vs. build-sysroot vs. target-sysroot [15:06] [Sno]: Are you going to mention "cross compiling for Perl 6 hackers" too? :) [15:06] <[Sno]> given you take a "normal" debian-linux to cross-compile yourself a tiny system to run perl6 on it :D [15:07] <[Sno]> than you first have to make some choices: bootloader, kernel, toolchain (binutils, gcc, ...) [15:08] <[Sno]> for those toolchain, you first build yourself the toolchain using the host-toolchain but the version you're going to use to cross-compile (build-toolchain) [15:08] <[Sno]> this build-toolchain is used to compile yourself the cross-toolchain [15:09] <[Sno]> the build-toolchain is further used to compile build-tools (perl5: miniperl, perl6 - maybe the lua used in configure stage ...) [15:09] <[Sno]> in my example project I'm going to demonstrate a later niederrhein.pm, I cross-build p6 using a cross-build OpenJDK8 [15:10] <[Sno]> but the cross-openjdk8 is bootstrapped on build-host using jikes -> ecj -> java6 -> java7 -> java8 [15:11] <[Sno]> it got the "which stdlib.h"? from that long explanation? [15:13] nqp: 125eb32 | (Stefan Seifert)++ | src/HLL/World.nqp: [15:13] nqp: Allow for subclasses of HLL::World to use a subclass of CompilationContext [15:13] nqp: review: https://github.com/perl6/nqp/commit/125eb32eb1 [15:14] [Sno]: How long are they going to let you speak? Sounds like you've got a lot of ground to cover [15:14] <[Sno]> perlpilot: we have the entire evening :) [15:15] <[Sno]> I think, after dinner for around 90min-2hrs [15:16] neat. I hope you inspire some people to try their hand at cross-compiling. [15:16] <[Sno]> perlpilot: the motivation is finally to enlighten more people wrt. cross-building (or at least be aware of that) [15:17] <[Sno]> p6 is more important than p5 - but I have much more examples for p5, since I fight with lot's of details in cross-compiling perl6 [15:18] <[Sno]> perl6 build fails the "don't run from target build" rule [15:18] <[Sno]> and the configure stage doesn't clarify / log properly [15:19] <[Sno]> I wonder if a patch using https://metacpan.org/release/Config-AutoConf will be accepted for configuring MoarVM, NQP and Rakudo :D [15:25] [Sno]: Note that all the artefacts you build in NQP are platform-agnostic, and in Rakudo only one thing (written in C) is platform-specific. [15:26] <[Sno]> jnthn: that's true but wrong :) [15:26] Virtual machines are wrong? Wow! :P [15:27] <[Sno]> jnthn: slide 15 explains a little bit why the artifacts must not run in build-environment [15:29] <[Sno]> nine_: better here than there ;) [15:29] <[Sno]> nine_: was my fault - I didn't read lizmat's mail not carefully enough [15:30] <[Sno]> jnthn: did you read the slides and get the sysroot-fiasco? [15:31] <[Sno]> and read my explanation about host vs. build vs. target environment above? [15:35] * bartolin spectests rakudo-j and hopes for a clean run (after some heavy fudging and with his patches from PR 748 applied) [15:42] rakudo/fix_eval_in_precomp: efe73eb | (Stefan Seifert)++ | src/ (4 files): [15:42] rakudo/fix_eval_in_precomp: Fix EVAL during precompilation [15:42] rakudo/fix_eval_in_precomp: [15:42] rakudo/fix_eval_in_precomp: EVALed code is considered an independent compilation unit that gets compiled [15:42] rakudo/fix_eval_in_precomp: using a new World which contains an independent serialization context. It also [15:42] rakudo/fix_eval_in_precomp: gets its own QAST compiler. [15:42] rakudo/fix_eval_in_precomp: [15:42] rakudo/fix_eval_in_precomp: When a BEGIN time EVAL is run during precompilation of a module, the [15:42] rakudo/fix_eval_in_precomp: independent SC would not be written into any file but would still be referenced [15:42] rakudo/fix_eval_in_precomp: from the outer compilation unit. We therefor use the outer world's [15:42] rakudo/fix_eval_in_precomp: CompilationContext which contains the SC. We also need to share a couple of [15:42] rakudo/fix_eval_in_precomp: other attributes that keep track of the compilation's state. [15:42] rakudo/fix_eval_in_precomp: [15:42] rakudo/fix_eval_in_precomp: The QAST compiler's frames are shared by adding them to the hash that's used [15:43] for initializing the QAST compiler's frames lookup hash. [15:43] Fixes RT #124324 [15:43] commit 17523cecfbb2e4e6093cd5bd38c7a554063a1457 [15:43] Refactor sharing the compilation context [15:43] Put the shared attributes into a subclass of NQP's CompilationContext to get [15:43] rid of the fragile binding hack. [15:44] Please, please review: https://github.com/rakudo/rakudo/commit/efe73eb9decfec23b5447e2a379d799ede4aa8ab https://github.com/rakudo/rakudo/commit/17523cecfbb2e4e6093cd5bd38c7a554063a1457 [16:03] yes! t/04-nativecall/01-argless.t passes on r-j \o/ [16:03] still plus debug output, and fixed in a terribly clutchy way, but at least i found the spot to tweak [16:04] s/clutchy/kludgy/ # probably, according to the jargon file at least i think [16:05] psch++ [16:06] psch++ # enjoy that moment! [17:30] *** vendethiel joined [18:07] rakudo/nom: e1e1811 | (Salve J. Nilsen)++ | / (2 files): [18:07] rakudo/nom: Make usage text fit in 80 columns [18:07] rakudo/nom: [18:07] rakudo/nom: Also, update running.pod usage text example to match actual usage text. [18:07] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e1e18112aa [18:07] rakudo/nom: 2d6f5c8 | niner++ | / (2 files): [18:07] rakudo/nom: Merge pull request #751 from sjn/usage-text-1 [18:07] rakudo/nom: [18:07] rakudo/nom: Make usage text fit in 80 columns [18:07] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2d6f5c8137 [18:11] nqp: 6b71554 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js: [18:11] nqp: [js] Remove old TODO. [18:11] nqp: review: https://github.com/perl6/nqp/commit/6b71554a5a [18:11] nqp: f6b5db3 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js: [18:11] nqp: [js] Avoid setting the REPR names manually. [18:11] *** dalek joined [18:27] something tangentially related i found while hunting the jvm NC bug: [18:27] m: my $name = "foo"; say "$name.{1+1}" [18:27] rakudo-moar 2d6f5c: OUTPUT«Type Str does not support associative indexing.␤ in block at /tmp/_MiGDdfart line 1␤␤Actually thrown at:␤ in block at /tmp/_MiGDdfart line 1␤␤» [18:27] that apparently used to work, 'cause that's how $*VM.platform-library-name does it in the jvm path [18:38] in any case, i'm still kinda stuck how to make this a good solution [18:39] the problem as it exists is that $!call is codegen'd to be accessible with get_attribute_native, but we don't lead into that get_attribute_native anywhere [18:40] so either i hack around that in Ops.getattr somehow, which would either be able to learn the native type of the attribute (which we don't have a means of finding out, afaict) or would catch and throw up to 4 layers of exceptions [18:40] or there's a smart solution that gets closer to emulating the "chasing pointers" style of moar [18:40] ...at least that's what i understand moar is doing [18:42] :S [18:43] my hunch would something akin to P6OpaqueBaseInstance.resolveAttribute, a la resolveAttributeType maybe [18:43] which could be ref, int, str, num, obj [18:44] i don't know how well that fits into sixmodel, though [18:44] and, well, moar doesn't even need it so maybe it's a bad idea..? vOv [18:44] to be honest i'm still confused why native attributes are even a thing [18:45] timotimo: huh? like, int? [18:48] no, i mean java native [18:49] oh [18:49] the comments and commit messages seem to suggest inlining..? [18:50] hm, right [18:50] but how come we don't just box it into a proper object on the way out? [18:50] like, p6opaque can inline other things's REPRs and REPRData [18:50] that's enough to turn it into a normal object on the way out? [18:51] i must be missing something [18:51] well, it needs to have a StorageSpec.INLINED to be inlined i suppose [18:51] and nqp-j codegen says that that already means it gets accessed by REPR.get_attribute_native [18:51] huh [18:52] how would things change when we claim NativeCall *isn't* inlinable? [18:52] then my first idea for fixing it could probably work [18:52] 'cause that was to fix inlineGet and inlineBind to add/strip NativeCallInstance around the NativeCallBody [18:53] but then it probably also wouldn't get inlined... vOv [18:56] i do lean towards "just hack it together while relying on exceptions figuring out the type" [18:56] because it fixes two problems here, which is the NC bug as well as general access to native attrs via nqp::getattr [18:56] s/figuring/to figure/ [18:57] but that's only from a "it'll at least be solved" perspective, because it'd probably make native attr access via nqp::getattr completely not worth it at all because really slow [18:57] as mentioned, in the worst case that's throwing and catching 4 exceptions [19:04] oh duh [19:04] tc.native_type exists [19:05] which means there's only one catch involved [19:05] hooray [19:07] well, figuring out the boxing type for the NATIVE_JVM_OBJ case is kinda iffy, but otherwise it should be fine i think [19:15] i mean, assuming a general case where it's not known that it's a NativeCallBody and needs a NativeCallInstance [19:20] *** sortiz joined [19:47] https://gist.github.com/peschwa/1339399161679786bd91439bea6ca6ec [19:48] i think i'll take that for today [19:49] that's better than exclusively fails :) [19:49] which is what it was before, right? [19:50] yeah, previous was exclusively "No subtests run" iirc [19:50] excellent! [19:50] 'cause the BUILDPLAN for a Sub+{Native[...]} always failed [19:56] nqp: 49dfcad | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/P6OpaqueBaseInstance.java: [19:56] nqp: Throw meaningful things from badReference and badNative. [19:56] nqp: [19:56] nqp: We need to distinguish them for native-capable getattr, because catching all [19:56] nqp: RuntimeExceptions there muddles the ones we care about (which is badReference) [19:56] nqp: up with e.g. "No such attribute". [19:56] nqp: review: https://github.com/perl6/nqp/commit/49dfcad137 [19:56] nqp: 5981bf0 | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java: [19:56] nqp: Handle all kind of attribute access via getattr. [19:56] nqp: [19:56] nqp: The NATIVE_JVM_OBJ case is clearly a bit brittle like this, but I haven't come [19:56] nqp: across a case where that's not what we want. Of course this doesn't mean there [19:56] nqp: isn't one... [19:56] nqp: review: https://github.com/perl6/nqp/commit/5981bf0439 [19:56] rakudo/nom: abfb8da | peschwa++ | tools/build/NQP_REVISION: [19:56] rakudo/nom: Bump NQP_REVISION [19:56] rakudo/nom: [19:56] rakudo/nom: This gets us a more moar-like handling of nqp::getattr, which is transparent to [19:56] rakudo/nom: native attributes. [19:56] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/abfb8dadfd [19:57] huh, dalek didn't mention d6ed4c1 and didn't get floodkicked either..? [19:57] huh [19:58] 'cause there's another commit after the NQP_REVISION bump [20:00] well, it shows in the GH web interface, so there vOv [20:00] nine_: Really tired right now, but got all day for Perl 6 things tomorrow, so will review your two commits then :) [20:04] ok :) [20:33] roast: 68a55df | usev6++ | S0 (3 files): [20:33] roast: Unfudge tests for JVM [20:33] roast: [20:33] roast: fixed by nqp commit 5981bf0439, psch++ [20:33] roast: review: https://github.com/perl6/roast/commit/68a55dfce0 [21:19] *** geekosaur joined [21:21] *** hankache joined [21:40] *** lizmat joined [21:55] *** synopsebot6 joined [22:48] *** ugexe joined [23:03] intriguing: https://arxiv.org/abs/1604.03641 [23:13] <[Coke]> starting release. [23:16] nqp: 804fdec | coke++ | tools/build/MOAR_REVISION: [23:16] nqp: bump MOAR revision [23:16] nqp: review: https://github.com/perl6/nqp/commit/804fdecc28 [23:16] nqp: 4011515 | coke++ | VERSION: [23:16] nqp: bump VERSION [23:16] nqp: review: https://github.com/perl6/nqp/commit/40115150b7 [23:17] <[Coke]> is nqp-js good enough to run as part of the release now? [23:17] <[Coke]> (i'll find out soon enough...) [23:20] <[Coke]> guess not. [23:54] <[Coke]> nqp 2016.04 done, tagged, tarballed [23:56] <[Coke]> rant: instructions suggest "perl6 tools/contributes.pl6" but that will never work if you have an installed p6 and a fresh dev.