[00:12] *** skids joined [00:47] *** timotimo joined [00:58] i wondered if that comment was related [05:44] *** sno joined [06:43] *** pyrimidine joined [07:06] *** RabidGravy joined [07:06] *** DrForr joined [07:15] rakudo/nom: d13c39c | niner++ | src/core/CompUnit/RepositoryRegistry.pm: [07:15] rakudo/nom: Fix "Cannot call method 'prefix' on a null object" during JVM build [07:15] rakudo/nom: [07:15] rakudo/nom: tools/build/install-core-dist.pl works with a repo chain consisting only of the [07:15] rakudo/nom: 'perl' repository and missing 'vendor' and 'site'. This caused VMNull values in [07:15] rakudo/nom: the $custom-lib nqp hash over which name-for-repository stumbled later on. [07:15] rakudo/nom: [07:15] rakudo/nom: Fix by removing those keys from the hash (if we would just leave them as is, [07:15] rakudo/nom: they'd contain the path strings). [07:15] rakudo/nom: With this the JVM build finishes successfully. [07:15] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d13c39cc79 [07:17] psch: at least nom is in a better shape now :) [07:42] *** brrt joined [08:45] what to do about perl6-gdb-m detaching and waiting forever? [08:50] grrr. precomp interferes with debugging [08:58] It has not always been this way I think [08:59] Have you tried my $perl6 = $*EXECUTABLE.subst('perl6-debug', 'perl6').subst('perl6-gdb', 'perl6'); in src/core/CompUnit/PrecompilationRepository.pm? [08:59] method precompile [09:49] rakudo/nom: 1e5df41 | peschwa++ | .travis.yml: [09:49] rakudo/nom: Only allow R-J failures on OSX. [09:49] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1e5df4130e [09:49] ...because that apparently hangs, currently [09:50] at least that's the only idea i have. stage parse for r-j on osx is about the same as linux, but osx gets terminated because it runs too long [09:51] is there any reason we let travis only test nqp-m? [09:54] <|Tux|> This is Rakudo version 2016.04-158-gd13c39c built on MoarVM version 2016.04-26-g1088538 [09:54] <|Tux|> test 21.693 [09:54] <|Tux|> test-t 13.366 [09:54] <|Tux|> csv-parser 35.002 [09:55] ...it's "nobody wants constant reminders that nqp-j doesn't pass all tests", isn't it? :/ [09:56] nqp: 0af5b62 | (Pawel Murias)++ | tools/build/ (2 files): [09:56] nqp: [js] Build NQPP5Regex. [09:56] nqp: review: https://github.com/perl6/nqp/commit/0af5b625fc [09:56] nqp: 87a487c | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js: [09:56] nqp: [js] When unable to type check return 0. [09:56] nqp: [09:56] nqp: It's not very elegant but other backends to it this way and rakudo relies on it. [09:56] nqp: review: https://github.com/perl6/nqp/commit/87a487cf1d [10:02] psch: not to mention nqp-p [10:03] timotimo: well, in contrast to nqp-p there's at least one person with somewhat of an interest around to make nqp-j pass the nqp test suite... :P [10:04] that's right [10:04] but yeah, i'll put that off until we do actually pass the test suite [10:07] i appreciate your work in this matter in any case :) [10:08] Oh yes, absolutely! [10:14] ooc, what's with the macros MAX and P6OMAX in MoarVM/src/6model/reprs/P6opaque.c? [10:16] 'cause they look kind of identical to me [10:17] Well P6OMAX was added to avoid some compiler warning [10:17] And has been there since April 2013 [10:18] jnthn: ah. well, as i said, just curious :) [10:18] 24b38672 added MAX [10:18] Apparently for...something to do with libtommath bundling? o.O [10:19] And it seems totally unused in P6opaque.c [10:19] that does sound a bit weird from here [10:19] Yeah, to me too [10:20] well, since we concatenate all .c files before compiling into one big .c file, we can't easily know if it's used or not! [10:20] wait, something's not quite right about that ... [10:20] CORE.setting.c..? :) [10:20] totally don't see a problem with that [10:20] well, MOAR.setting.c i suppose :P [10:23] I wonder if there'd actually be a way to not concatenate setting file in rakudo and speed up compilation that way [10:24] I guess we would need a way to concatenate byte code files instead. [10:24] intuitively i'd guess we could only make it slower because of lots of GLOBALs merging and fixups [10:24] as CORE:: still is supposed to be one lexical scope [10:25] Compiling the whole setting would definitively be slower, but change/compile/test turnaround times could be much improved. [10:25] * timotimo BBL [10:25] nine: All the stubbing and later declarations would get in the way for one :) [10:26] jnthn: the closest nqp-j equivalent to {get,set}_obj_at_offset we have is {get,bind}attr with a hint, isn't it? [10:27] jnthn: not if we compile every file with a setting which is the concatenation of the previously compiled files. Or put differently: if we add a newly compiled file to the concatenated setting and use that as setting for the next file. [10:31] hm, i guess the closest thing i could do is introspecting for the corresponding .field_, but i don't really want to do that... :S [10:33] psch: The problem really is that in C you can easily implement taking and passing a reference into the middle of some other object [10:33] psch: And if Java there's no way to do that [10:33] psch: And the way it's implemented on Moar uses that feature [10:33] So a direct port isn't really possible [10:34] * psch considers throwing "Sorry, auto vivification of containers NYI" [10:35] i think i don't quite complete grasp the purpose of that branch in get_attribute yet, anyway [10:35] *if branch [10:36] the !attr_st case is for inlined natives? [10:37] *** brrt joined [10:37] No, the !attr_st case is for when we want an object and simply have one [10:38] We must implement the autoviv already I think, because otherwise a lot of other things woudln't work [10:38] It's the case we *do* have attr_st that is trickier on JVM [10:38] lunch; bbiab [10:57] hm, the problem i'm seeing now is that i don't know where on the allocated SMO i have to hang the attr that we are getting [10:57] i think that's what moar solves with "passing a reference into the middle of some other object"..? [11:00] psch: It's more that you'd need to .allocate an instance of the flattened-in type's REPR [11:01] And "copy" to that [11:01] jnthn: right, that's what i mean. the allocated SMO is the one that comes from flattenedSTables[slot] [11:08] but copying to that freshly allocated SMO is what's hard, because i can't just do pointer arithmetic but have to know the name of the field [11:10] Right [11:10] Which is why it was cheated around so far ;) [11:19] ugh [11:19] so i'm getting this right that the SMO could have an arbitrary amount of fields too right? [11:23] psch: Yes. Though if you know the position of the first field (if there's not already a table then it's probably easy enough to keep one) then you can just grab the field reflection object from that point and go over those from the target object assigning [11:24] jnthn: oh, right now i'm mostly trying really hard to not need to reflect... i don't think it's working, fwiw :) [11:32] * psch .oO( catch (IllegalAccessException iae! iae! cthulhu fhtagn!) ) [11:33] ;) [11:42] jnthn: what's a test for the !attr_st/autoviv case? [11:43] Well, any Scalar attribute access in a Perl 6 object pretty much [11:45] ah, okay [11:46] so i'll notice during the rakudo build if i broke that i suppose.. :) [12:10] well, building r-j with the getattr patch worked [12:10] now for the other two nqp make test failures... [12:10] 'cause maybe then we can also enable nqp-j on travis :) [12:18] one of the failures is the contvar test in qast/01-qast.t [12:19] and the other is "Missing serialize function for REPR P6bigint" in serialization/02-types.t (and potentailly more after that vOv) [12:19] *** MadcapJake joined [12:21] the latter is apparently just NYI [12:50] *** brrt joined [13:17] *** skids joined [13:47] *** dalek joined [13:57] <[Coke]> RT: 1289; CONC: 7; GLR: 6; JVM: 70; LHF: 2; LTA: 69; NYI: 26; OSX: 3; PERF: 15; POD: 3; PRECOMP: 3; RFC: 16; SEGV: 19; STAR: 1; TESTNEEDED: 23; TODO: 10; UNI: 5; WEIRD: 2 [14:07] * [Coke] wonders if "REGEX" would be a helpful tag [14:31] *** sortiz joined [15:05] <[Coke]> m: let $a = 3; [15:05] rakudo-moar 1e5df4: OUTPUT«===SORRY!=== Error while compiling /tmp/AGj4pywA_z␤Variable '$a' is not declared␤at /tmp/AGj4pywA_z:1␤------> let ⏏$a = 3;␤» [15:05] <[Coke]> m: my $a; {let $a = 3;} [15:05] rakudo-moar 1e5df4: ( no output ) [15:06] <[Coke]> m: BEGIN { say "a".subst(/a/, "b"); } [15:06] rakudo-moar 1e5df4: OUTPUT«===SORRY!=== Error while compiling /tmp/IqguIOqriY␤An exception occurred while evaluating a BEGIN␤at /tmp/IqguIOqriY:1␤Exception details:␤ Type check failed in binding cds; expected Any but got Mu (Mu)␤ in block at /tmp/IqguIOqriY line…» [15:07] <[Coke]> m: my $a="a";my $b="b"; ($a, $b) := ($b, $a); say $a; say $b; [15:07] rakudo-moar 1e5df4: OUTPUT«===SORRY!=== Error while compiling /tmp/cmHPsI_PQY␤Cannot use bind operator with this left-hand side␤at /tmp/cmHPsI_PQY:1␤------> y $a="a";my $b="b"; ($a, $b) := ($b, $a)⏏; say $a; say $b;␤» [15:29] Oh I hate this so much! Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Pod.nqp' [15:30] * psch too [15:30] i don't know how to fix it though :S [15:38] rm install/share/nqp/lib/Perl6/* ; make clean ; make install [15:38] make clean is not enough since it then uses the outdated installed files [15:40] nqp: 6aa109b | niner++ | src/vm/jvm/ (2 files): [15:40] nqp: Implement loadbytecodebuffer op for JVM [15:40] nqp: review: https://github.com/perl6/nqp/commit/6aa109b5c6 [15:41] I don't know why but it seems like my first implementation attempt actually works :) [15:41] Maybe you got it right? o.O ;) [15:41] nah....can't be it [15:42] Also there's very probably a difference between "right" and "just working" [15:47] Can "Cannot unbox a type object" appear because a type object was passed to an nqp sub expecting an int argument? [15:48] nine: yes [16:01] nqp master stopped building on windows yesterday in case anyone missed it: https://ci.appveyor.com/project/moritz/rakudo/build/1.0.174/job/fjyp9cevd8cuy3pc [16:02] (line 114) [16:03] nine: sure nuking the installed files make the builds "work" again, but ISTR someone telling me that's only hiding the problem... ;) [16:03] oops...it's actually nqp [16:03] s/nqp/MoarVM/ [16:04] i dont think the appveyor notices will show up on github unless its specifically under the rakudo name [16:08] Created a PR for Moar [16:19] *** sno joined [16:29] j: my sub parse-string(int $pos is rw) { loop { my int $ord = nqp::ordat('', $pos); } } [16:29] rakudo-jvm 40a953: OUTPUT«cannot connect to eval server: Connection refused␤» [16:29] meh [16:29] However that's the golfed code that gives the Cannot unbox a type object in src/vm/jvm/QAST/Compiler.nqp:4427 [16:29] Trying to pass NQPMu to sub result [16:36] nqp-m: nqp::ordat("", 0) [16:36] nqp-moarvm: ( no output ) [16:36] nqp-m: say(nqp::ordat("", 0)) [16:36] nqp-moarvm: OUTPUT«-1␤» [16:38] the ordat call itself throws StringIndexOutOfBounds locally..? [16:39] hm, maybe i'm not paying enough attention... :) [16:42] $cur_block.lexical_type($name) is NQPMu which ends up in $type and passed to result() [16:43] hm, lexref underimplemented? [16:44] i think native rw params are lexical refs... :S [16:45] Further golfed it down: my sub parse-string(int $pos is rw) { { my int $ord = $pos; } } [16:45] And yes the inner block is necessary to trigger it [16:47] nine: yeah, it's the combination of int and 'is rw', Int or no 'is rw' makes it work [16:48] which is one of those *ref_i thingies, i'm not sure if nativeref_i or lexicalref_i though [17:07] *** RabidGravy joined [18:00] Has anyone besides psch tested the precomp-store-redesign branch so far? [18:10] psch: the "java.lang.RuntimeException: This type does not support positional operations" occurs when slurp-rest()ing a file with a certain minimum length. It won't happen on short files... [18:20] *** brrt joined [18:20] nine: that sounds a bit weird... [18:21] nine: i don't see anything obvious in StandardReadHandle or SyncHandle that could cause that [18:21] nine: although maybe finding the actual boundary helps there... vOv [18:21] 32768 bytes is the limit [18:22] 2^15 [18:22] Intriguingly that's the file size. Seems to be independent of how much slurp-rest actually is reading (using .get() before) [18:23] Yep, 32768 is still ok, 32769 is too much [18:24] i'd guess that means that the "are we over the limit" code is faulty? [18:25] which limit? [18:26] curBuffer = ByteBuffer.allocate(32768); [18:26] Must be relevant [18:27] that should be fine, actually... [18:28] OTOH the error comes from nqp not the JVM [18:28] the while loop that allocates reads the ByteChannel, replacing the buffer it reads into every 32kib [18:29] well, slurp returns a String in any case [18:29] so i mostly wonder why it wants to do positional access in the first place [18:31] slurp-rest, not slurp [18:31] slurp-rest calls readallfh, which calls SyncHandle.slurp :) [18:32] slurp-rest(:bin) [18:32] Which uses readfh and pushes blocks into $res [18:32] oh, yeah i wondered about that, but forgot to ask [18:34] ...and then operated on the wrong assumption /o\ [18:35] nine: i'd try having SyncHandle.read() do a similar thing as SyncHandle.slurp does [18:36] nine: i.e. gather multiple buffers into an arraylist and decode that [18:36] no decoding necessary for :bin [18:37] no, i mean decode the ArrayList into a VMArrayInstance [18:37] But that seems to be essentially what slurp-rest(:bin) does, just at a higher level in nqp [18:42] Lowering the 0x100000 to 0x10000 in slurp-rest does not change the 32768 limit [18:44] that's really weird tbh :) [18:45] ugh, how does dd work again... >_> [18:46] ddrescue or dd_rescue or de-rescue however it's spelled has a much nicer interface [18:46] well, that doesn't seem to be on hack [18:47] ah, bs=1b was the bit i did wrong [18:48] bs=1 does what i mean [18:50] *** dalek joined [18:51] humm [18:51] my $fh = open "16384.bin"; $fh.slurp-rest :bin # gives me the same error [18:52] oh duh [18:52] forgot bs=1 there >_> [18:52] yeah, but still, 16kb file, with that p6 invocation throws the same error [18:55] ok, so i'm now running if=/dev/random instead of if=/dev/zero, and only writing 2 bytes [18:55] and that throws the same way too [18:55] nine: am i doing slurp-rest wrong..? [18:59] Maybe depends on the Java version/implementation? Using java-1_8_0-openjdk-headless-1.8.0.77-1.1.x86_64 [19:00] ah, hack is on java version "1.7.0_101" [19:00] anyway, i've subclassed RTE so i know which one to catch [19:00] 'cause we use them for... other things [19:01] like, CX i wanna say, but i'm not sure [19:17] m: my $b = Buf.new; $b.push(Buf.new([1, 2])) [19:17] rakudo-moar 1e5df4: ( no output ) [19:17] nine: ^^^ that's your golf [19:18] Wow...that's quite a bit shorter :) [19:18] i don't know about that [19:18] but it's less semantically dense at least :) [19:18] but yeah, that's what throws the "does not support positional" [19:18] I have to admit that I don't understand how this could go wrong [19:28] interestingly, passing an Int into $buf.push works [19:28] Sometimes I think this API redesigning will never end [19:34] rakudo/nom: 33ef5a9 | niner++ | / (2 files): [19:34] rakudo/nom: Implement CompUnit::Loader.load-precompilation [19:34] rakudo/nom: [19:34] rakudo/nom: Needs an NQP bump [19:34] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/33ef5a9545 [19:34] rakudo/nom: 2511398 | niner++ | src/core/CompUnit/PrecompilationRepository.pm: [19:35] *** dalek joined [19:36] that's a merge? [19:37] ugh [19:38] my hunch was correct :/ [19:38] - nqp::splice(self,$buf,nqp::elems(self),0) [19:38] + nqp::splice(self,nqp::decont($buf),nqp::elems(self),0) [19:38] and Buf.push(Buf) works [19:38] ah....forgot the --no-ff again [19:38] psch: what's with all those decont issues? [19:39] nine: i have no idea. the only hint i ever got was for #126493, my last comment links to jnthn++'s suggestion regarding that [19:39] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=126493 [19:39] otoh, jnthn did say recently that it's probably not because of that (i.e. signature compilation) [19:45] oh, there also was this bit about "don't ro-cont if it can't flatten" in the slow path binder [19:46] but i couldn't get that to work because i didn't figure out how i can put Iterable into GlobalExt [19:46] Seems to me like this comes up again and again :/ [19:46] Since the GLR anyway [19:49] yeah, sounds about right [20:27] *** perlpilot joined [20:49] *** travis-ci joined [20:49] Rakudo build failed. Stefan Seifert 'Work around JVM not having loadbytecodefh' [20:49] https://travis-ci.org/rakudo/rakudo/builds/129825917 https://github.com/rakudo/rakudo/compare/1e5df4130e68...366ddfd43420 [20:49] *** travis-ci left [20:59] *** Skarsnik joined [21:00] Those were JVM failures. [21:35] *** cognominal joined [21:47] rakudo/nom: 1dca2d8 | niner++ | src/core/ (7 files): [21:47] rakudo/nom: Store relative paths to dependency sources in precomp files if possible [21:47] rakudo/nom: [21:47] rakudo/nom: We need the path of a dependency's source file to check the .modified time. [21:47] rakudo/nom: We also want to be able to move repositories without invalidating all [21:47] rakudo/nom: precomp files. So we use the same trick as for the source-names that we [21:47] rakudo/nom: use for backtraces and use paths relative to well known repositories. [21:47] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1dca2d8f38 [21:47] Aaand this should be the final piece of the puzzle allowing for us to package modules :) [21:48] Will give it a try this weekend and see if I'm correct. But for now, good night! [21:49] awesomazing! [22:10] *** ZoffixWin joined [22:56] *** ZoffixWin joined