Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-15

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

All times shown according to UTC.

Time Nick Message
01:40 TimToady joined #p6dev
01:47 ilbot3 joined #p6dev
01:47 Topic for #p6dev is now Perl 6 language and compiler development
06:26 lizmat joined #p6dev
06:26 * lizmat waves from FRA
06:26 timotimo heyo liz
06:26 timotimo hope your flight will go well :)
06:27 * lizmat too  :-)
06:27 lizmat it's only an 11 hour flight  :-)
06:28 lizmat but in the newest, largest passenger jet on the planet: the A380
06:28 timotimo i'm not good at long flights :|
06:28 timotimo oh
06:28 timotimo is that the one that has a mcdonalds restaurant built in? :D
06:28 lizmat somewhere: haven't found it yet
06:30 timotimo oh, i meant the airbus, not the airport ;)
06:32 lizmat yeah, I also meant the A380
06:32 timotimo so it *is* true!
06:33 lizmat first time we flew it, we got on on the wrong floor...
06:33 timotimo you can't change floors once you're in the machine?
06:33 lizmat had to walk all the way to the back, go up the spiral staircase, and then walk all the way to the front again
06:33 timotimo ah
06:33 lizmat only one staircase in the back
06:34 lizmat and I guess elevators for personnel in between
06:34 lizmat it *is* a massive plane
06:35 timotimo what's the destination airport?
06:35 lizmat IHA
06:36 lizmat eh, IAH  :-)
06:36 timotimo ah, houston
06:38 timotimo hm, we don't yet have a way to store pod comments on enum values with just the enum syntax?
06:38 timotimo i've never tried, too distracted to actually look&try
06:53 lizmat further commuting&
08:08 nine m: use Test; say ::("Test");
08:08 camelia rakudo-moar ad8265: OUTPUT«(Test)␤»
08:10 RabidGravy joined #p6dev
08:20 Ven joined #p6dev
08:27 nine update on the JVM: I've got it as far as correctly picking apart the precomp file and the embedded JAR file and at least calling defineClass with the .class file's content. But the IgnoreNameClassLoader's getResourceAsStream then never gets called.
08:37 nine Yep, there's no call to deserialize
09:06 nine The deserialization QAST is definitely part of the class file though.
09:08 nine So I wonder: whose job would it be to run the deserialization code?
09:36 psch nine: afaict Ops.deserialize is the only bit that calls getResourceAsStream
09:36 nine psch: yep, and AFICT the deserialization QAST is the only bit that calls Ops.deserialize
09:37 nine I'm curreltly getting this output: https://gist.github.com/niner/4e96011348c2169f35e9b1d223f8f22c
09:38 nine With the deserializeQbid and desCodeRef related messages being from CompilationUnit.initializeCompilationUnit
09:39 psch World.load_module_early builds a deserialization ast
09:40 psch maybe there's a discrepency between what the r-j and r-m module loader return there?
09:40 nine Isn't load_module_early just for loading the setting?
09:40 psch i'd say load_setting is probably for the setting :)
09:40 psch that does a similar call though
09:41 psch well, "build a similar ast", i suppose
09:44 [Tux] This is Rakudo version 2016.04-200-gad82657 built on MoarVM version 2016.04-134-g9879233
09:44 [Tux] test            20.196
09:44 [Tux] test-t          13.125
09:44 [Tux] csv-parser      34.794
09:57 nine Yes, load_module_early is _only_ for loading Perl6::Bootstrap
09:57 nine hence the "early"
09:58 nine What's so confusing is that everything points to the deserialization code being run, except for that it actually isn't run.
10:00 psch hm
10:01 psch nine: can you gist your diff?
10:08 pmurias joined #p6dev
10:10 dalek nqp: 85ff6b7 | (Pawel Murias)++ | src/vm/js/nqp-runtime/deserialization.js:
10:10 dalek nqp: [js] Fix serializing closures.
10:10 dalek nqp:
10:10 dalek nqp: Mark the array of code refs passed to a serialization context properly.
10:10 dalek nqp: review: https://github.com/perl6/nqp/commit/85ff6b7fcb
10:10 dalek nqp: 729734c | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
10:10 dalek nqp: [js] Tweak the reprname for Captures.
10:10 dalek nqp:
10:10 dalek nqp: Rakudo hardcodes it.
10:10 dalek nqp: review: https://github.com/perl6/nqp/commit/729734cb51
10:12 nine https://gist.github.com/niner/44ab8449ab5b9d0837dca69e525a59f3
10:12 nine https://gist.github.com/niner/48daf2fef50e8453fd6dc71e4b3eef03
10:17 psch hm so the invokeArgless for the desCodeRef just does nothing, am i understanding that correctly?
10:18 psch 'cause the output you gave before states it survived that, and the desCodeRef probably should look into the serialization and do things with it..?
10:23 nine Yes, I would guess that desCodeRef should run the deserialization QAST, but somehow it doesn't.
10:51 psch ...huh
10:52 psch so, i'm running < perl6-jdb-server -e'use nqp; BEGIN nqp::debugnoop(1); use Test' >
10:53 psch and the bp in Ops.debugnoop gets hit *after* the last call to CompilationUnit.initializeCompilationUnit
10:53 psch ...did i mix up the "when does what run" thingies again?
11:00 psch wait
11:00 psch doesn't that actually mean that we don't even initialize the Test CU?
11:11 psch nine: https://github.com/perl6/nqp/blob/master/src/vm/jvm/runtime/org/perl6/nqp/runtime/LibraryLoader.java#L43 to line 49 is missing on the loadPrecompiled path
11:11 psch well, to line 52, actually
11:11 psch as in, we never do anything with the loaded class
11:11 psch not sure how we'd handle L52 when it comes from a buffer
11:12 psch well, except with handing the file name down from the nqp op invocation in Perl 6-land
11:15 nine oooh!
11:15 nine How could I be so blind?
11:16 [Tux] a new fail example in utf8-c8 vice versa:
11:16 [Tux] # expected: Buf.new(61,147,135,8,82,78,208,66,205,164,204,162,140,97,175,37,108,194,27,192,119)
11:16 [Tux] #      got: Buf.new(61,147,135,8,82,78,208,66,204,162,205,164,140,97,175,37,108,194,27,192,119)
11:16 [Tux] 205-164 vs 204162
11:16 psch probably a mixture between "unfamiliar part of the code base", "non-habitual language" and "distracted" :)
11:17 [Tux] 205,164,204,162 => 204,162,205,164
11:19 [TuxCM] joined #p6dev
11:19 RabidGravy odd
11:46 nine psch: yes that's it! And again we're one step further
11:46 nine Loading a precompiled Test works now
11:47 bartolin \o/ nine++ psch++
12:02 nine Newest issue: setcodeobj can only be used with a CodeRef
12:07 dalek nqp: f6670c8 | niner++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ (2 files):
12:07 dalek nqp: Working implementation of loadbytecodebuffer on JVM
12:07 dalek nqp:
12:07 dalek nqp: Nothing about the previous attempt was actually correct or working :(
12:07 dalek nqp: Instead of calling just loadNew, we need to unpack the JAR file embedded in
12:07 dalek nqp: precomp files and actually create a CompUnit for the loaded class.
12:07 dalek nqp: Also the buffer passed to loadbytecodebuffer is more likely an uint8 Buf
12:07 dalek nqp: review: https://github.com/perl6/nqp/commit/f6670c88e4
12:20 [Tux] joined #p6dev
12:23 nine Ok, I think what's now missing is my BEGIN time EVAL fix. I did that only for MoarVM.
12:23 nine Shouldn't be much work though
13:00 Ven joined #p6dev
13:02 nine Of course that's true only so long as the JVM implementation is quite similar to the one for moar...
13:47 mst joined #p6dev
13:47 mst please can we move this to #perl6-dev?
13:48 mst 'p6dev' is not a top level freenode accredited project, so we're currently (a) inconsistent with the naming of our other channels (b) violating freenode guidelines (c) making it impossible for me to fix this channel if it breaks
13:49 mst (and this was created in march, after I'd already got rights to fix channels, so PLEASE would people remember to talk to me before doing stuff)
13:54 mst (if you're intentionally trying to hide then we need to move to ##p6dev btw)
13:54 psch i'm fine with either, fwiw
13:54 psch although i don't think intentionally hiding is particularly fitting for the community
13:54 tadzik I vote for consistent naming :)
13:56 mst I vote for "you can be inconsistent if you must, but you're going to do it intentionally, and without breaking the freenode guidelines, and if not you can bloody well do it right in the first place" (*adjusts british army moustache, buffs monocle*)
14:42 stmuk_ is there a recommended JDK for rakudo (openjdk or oracle)?
14:50 psch stmuk_: i'm using openjdk, fwiw
14:55 nine same here
15:29 sortiz joined #p6dev
15:36 pmurias mst: I don't think we are trying to hide as perl6-dev points here
15:36 mst pmurias: that didn't exist when I asked
15:37 mst pmurias: so, er, that makes no sense at all :P
15:37 mst Channel #perl6-dev created Sun May 15 14:47:33 2016
15:37 pmurias ok
15:38 mst I mean, I didn't expect you to be trying to hide
15:39 mst but a channel created after the fact isn't really evidence, except that timotimo decided you probably weren't
15:52 bartolin psch: I tried to understand the weird behaviour of 'slurp-rest' after 'get' you found. it happens with nqp::readlinechompfh and nqp::readallfh on nqp-j too. I think the culprint is here: https://github.com/perl6/nqp/blob/master/src/vm/jvm/runtime/org/perl6/nqp/io/SyncHandle.java#L62
15:54 bartolin readBuffer seems to have the old content and we copy it along with the newly read content.
15:55 bartolin could you take a look, whether this patch makes sense? https://gist.github.com/usev6/a721447b09781a1e32622676ecffd38f
15:57 psch bartolin: does it fix anything?  'cause from the docs for the two .wrap candidates it looks like you're doing the same after the patch as before..?
15:58 bartolin yep, it fixes the issue.
15:59 psch oh, yeah, you're copying
15:59 psch that's probably it
15:59 psch hm, unless readBuffer.array() also returns a copy :/
15:59 psch bartolin: well, if it works it works... :)
16:00 psch yeah, .array() returns the actual array behind the ByteBuffer
16:01 bartolin I assumed that readBuffer.get starts to take values from current position
16:01 bartolin but I'm not sure if the patch breaks something else :-(
16:03 bartolin ah, I updated the gist with an addition test for t/nqp/19-file-ops.t
16:03 psch huh, the javadoc says .get(byte[]) is eqv to .get(byte[], 0, a.length)
16:03 psch so it's "get everything, from start to finish", not "get from .position to end"
16:03 bartolin oh.
16:04 psch which just makes it more confusing, honestly... :)
16:04 psch i think the original issue is that .array() gets you the reference to the original array backing the ByteBuffer
16:04 psch and wrapping a different ByteBuffer around that gets somewhat racey, because now you have to ByteBuffers that clobber over the same array
16:05 psch well, except not really racey (as in "race condition", of course :P ) 'cause it's not async or parallel
16:08 cognominal joined #p6dev
16:09 bartolin however, the problem you found seems to be caused by that code block. if you could come up with a clean solution, that would be great :-)
16:10 psch yeah, i'll look a bit closer later on
16:11 bartolin ++psch
16:17 bartolin psch: I understood from the docs that offset and length in .get(byte[], offset, lenght) are about the destination array. since the problem went away it looks like the bytes where indeed read from the current position of the source.
16:19 psch bartolin: oh, you're right!  the offset is for the destination
16:35 psch bartolin: i think the easier patch is just replacing "readBuffer.position()" with 0
16:35 psch bartolin: 'cause afaict you're still shoving the whole buffer into newBytes
16:40 * bartolin tries that
16:50 bartolin yes, seems to work. (though I don't understand why)
16:50 bartolin oh, no, it does not work! (still get the first line twice)
16:54 * bartolin is confused and tries again
16:55 nine A SiXModelObject with a null st?
16:56 nine How is that possible? And is there any other way of finding out what kind of object it actually is?
16:56 psch nine: i think it shouldn't be possible..? o.o
17:06 nine It's the object that gets passed to setcodeobj when trying to run the EVAL during precompilation
17:08 nine Oh, another odd thing is that it happens during the actual EVAL, not during serialization or even loading of the precompiled file. So it may be a side effect of my BEGIN time EVAL fix a couple of weeks ago
17:08 psch bartolin: fwiw, the only alternative to your patch i can think of is using java.util.Arrays, which just pulls in an additional dependency...
17:10 bartolin btw, it only helps with the .slurp-rest() call. with .slurp-rest(:bin) the data is still missing
17:11 bartolin I'll open a PR then ...
17:24 psch hrm, SyncHandle is quite a thing :/
17:24 psch i mean, i don't get all the flip()ing we do, but i have a feeling it has something to do with getting reset to the start of the FH
17:24 psch cause that's part of what .flip() does
17:25 psch ohh.  but we don't flip the channel (if that even works...)
17:42 psch hmm, now how do i get a VMArrayInstance_i8 (or _u8) in nqp code :/
17:44 psch nine: i forgot where debugname hangs, but i don't think it's the STable
17:44 psch nine: i wanna say REPR, but...
17:45 nine public String debugName; is in runtime/org/perl6/nqp/sixmodel/STable.java
17:45 psch ah shucks :<
17:45 psch typeName also needs the st :/
17:46 psch ...wait, the REPR and REPRData also hang on the st, don't they
17:46 nine I guess, I'm just gonna spend some time again with my good old friend, finish_code_object.
17:46 nine Everything of interest seems to do
17:46 psch d'you have a jdb dump of the object?
18:11 psch hm, i think the problem with readlinechompfh followed by readfh (that's the .get, .slurp-rest :bin case) might be that the ByteChannel we have isn't seekable?
18:13 psch as in, a ByteChannel doesn't seem to care what's been read before, maybe? :/
18:13 psch i probably should test that...
19:45 dalek joined #p6dev
19:46 dalek joined #p6dev
19:47 dalek joined #p6dev
19:48 dalek joined #p6dev
19:50 timotimo moritz: i consider you dalek's maintainer, so: i removed #november-wiki and #perl6-lwp-gsoc from the list of channels to auto-join on freenode. if that's not okay, feel free to ping me and i'll remove them
19:51 timotimo moritz: on top of that, could you make ilbot3 join #perl6-dev ? mst and me are moving stuff from here to there to adhere to freenode's naming policies and such
19:52 moritz timotimo: wait what? it's not in here yet?
19:53 timotimo moritz: note the difference between #perl6-dev and #p6dev
19:53 timotimo #p6dev being here, #perl6-dev being over there :)
19:53 moritz oh noez
19:53 moritz this is starting to get confusing
19:54 timotimo well, we're kicking out #p6dev
19:54 timotimo so it's not increasing the number of channels, but the channels get more systematically named
19:55 ilbot3 joined #p6dev
19:55 Topic for #p6dev is now Perl 6 language and compiler development
19:55 mst once we get a bit further along I can setup a forward so anybody trying to join here ends up over there
19:55 mst should make things at least differently confusing
19:57 timotimo oh, forwards, neat.
20:04 timotimo left #p6dev
20:11 bartolin left #p6dev
20:24 psch left #p6dev
20:38 cognominal joined #p6dev

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