Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-12

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

All times shown according to UTC.

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

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