01:40 TimToady joined 01:47 ilbot3 joined 06:26 lizmat joined
lizmat waves from FRA 06:26
timotimo heyo liz
hope your flight will go well :)
lizmat too :-) 06:27
it's only an 11 hour flight :-)
but in the newest, largest passenger jet on the planet: the A380 06:28
timotimo i'm not good at long flights :|
oh
is that the one that has a mcdonalds restaurant built in? :D
lizmat somewhere: haven't found it yet
timotimo oh, i meant the airbus, not the airport ;) 06:30
lizmat yeah, I also meant the A380 06:32
timotimo so it *is* true!
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?
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
timotimo ah
lizmat only one staircase in the back
and I guess elevators for personnel in between 06:34
it *is* a massive plane
timotimo what's the destination airport? 06:35
lizmat IHA
eh, IAH :-) 06:36
timotimo ah, houston
hm, we don't yet have a way to store pod comments on enum values with just the enum syntax? 06:38
i've never tried, too distracted to actually look&try
lizmat further commuting& 06:53
nine m: use Test; say ::("Test"); 08:08
camelia rakudo-moar ad8265: OUTPUTĀ«(Test)ā¤Ā»
08:10 RabidGravy joined 08:20 Ven joined
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:27
Yep, there's no call to deserialize 08:37
The deserialization QAST is definitely part of the class file though. 09:06
So I wonder: whose job would it be to run the deserialization code? 09:08
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
I'm curreltly getting this output: gist.github.com/niner/4e96011348c2...d223f8f22c 09:37
With the deserializeQbid and desCodeRef related messages being from CompilationUnit.initializeCompilationUnit 09:38
psch World.load_module_early builds a deserialization ast 09:39
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?
psch i'd say load_setting is probably for the setting :)
that does a similar call though
well, "build a similar ast", i suppose 09:41
[Tux] This is Rakudo version 2016.04-200-gad82657 built on MoarVM version 2016.04-134-g9879233 09:44
test 20.196
test-t 13.125
csv-parser 34.794
nine Yes, load_module_early is _only_ for loading Perl6::Bootstrap 09:57
hence the "early"
What's so confusing is that everything points to the deserialization code being run, except for that it actually isn't run. 09:58
psch hm 10:00
nine: can you gist your diff? 10:01
10:08 pmurias joined
dalek p: 85ff6b7 | (Pawel Murias)++ | src/vm/js/nqp-runtime/deserialization.js:
[js] Fix serializing closures.

Mark the array of code refs passed to a serialization context properly.		 10:10
p: 729734c | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] Tweak the reprname for Captures.

Rakudo hardcodes it.
nine gist.github.com/niner/44ab8449ab5b...9e525a59f3 10:12
gist.github.com/niner/48daf2fef50e...1e4b3eef03
psch hm so the invokeArgless for the desCodeRef just does nothing, am i understanding that correctly? 10:17
'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:18
nine Yes, I would guess that desCodeRef should run the deserialization QAST, but somehow it doesn't. 10:23
psch ...huh 10:51
so, i'm running < perl6-jdb-server -e'use nqp; BEGIN nqp::debugnoop(1); use Test' > 10:52
and the bp in Ops.debugnoop gets hit *after* the last call to CompilationUnit.initializeCompilationUnit 10:53
...did i mix up the "when does what run" thingies again?
wait 11:00
doesn't that actually mean that we don't even initialize the Test CU?
nine: github.com/perl6/nqp/blob/master/s...r.java#L43 to line 49 is missing on the loadPrecompiled path 11:11
well, to line 52, actually
as in, we never do anything with the loaded class
not sure how we'd handle L52 when it comes from a buffer
well, except with handing the file name down from the nqp op invocation in Perl 6-land 11:12
nine oooh! 11:15
How could I be so blind?
[Tux] a new fail example in utf8-c8 vice versa: 11:16
# expected: Buf.new(61,147,135,8,82,78,208,66,205,164,204,162,140,97,175,37,108,194,27,192,119)
# got: Buf.new(61,147,135,8,82,78,208,66,204,162,205,164,140,97,175,37,108,194,27,192,119)
205-164 vs 204162
psch probably a mixture between "unfamiliar part of the code base", "non-habitual language" and "distracted" :)
[Tux] 205,164,204,162 => 204,162,205,164 11:17
11:19 [TuxCM] joined
RabidGravy odd 11:19
nine psch: yes that's it! And again we're one step further 11:46
Loading a precompiled Test works now
bartolin \o/ nine++ psch++ 11:47
nine Newest issue: setcodeobj can only be used with a CodeRef 12:02
dalek p: f6670c8 | niner++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ (2 files):
Working implementation of loadbytecodebuffer on JVM

Nothing about the previous attempt was actually correct or working :( Instead of calling just loadNew, we need to unpack the JAR file embedded in precomp files and actually create a CompUnit for the loaded class. Also the buffer passed to loadbytecodebuffer is more likely an uint8 Buf		 12:07
12:20 [Tux] joined
nine Ok, I think what's now missing is my BEGIN time EVAL fix. I did that only for MoarVM. 12:23
Shouldn't be much work though
13:00 Ven joined
nine Of course that's true only so long as the JVM implementation is quite similar to the one for moar... 13:02
13:47 mst joined
mst please can we move this to #perl6-dev? 13:47
'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:48
(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:49
(if you're intentionally trying to hide then we need to move to ##p6dev btw) 13:54
psch i'm fine with either, fwiw
although i don't think intentionally hiding is particularly fitting for the community
tadzik I vote for consistent naming :)
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*) 13:56
stmuk_ is there a recommended JDK for rakudo (openjdk or oracle)? 14:42
psch stmuk_: i'm using openjdk, fwiw 14:50
nine same here 14:55
15:29 sortiz joined
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
pmurias: so, er, that makes no sense at all :P 15:37
Channel #perl6-dev created Sun May 15 14:47:33 2016
pmurias ok
mst I mean, I didn't expect you to be trying to hide 15:38
but a channel created after the fact isn't really evidence, except that timotimo decided you probably weren't 15:39
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: github.com/perl6/nqp/blob/master/s...e.java#L62 15:52
readBuffer seems to have the old content and we copy it along with the newly read content. 15:54
could you take a look, whether this patch makes sense? gist.github.com/usev6/a721447b0978...76ecffd38f 15:55
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:57
bartolin yep, it fixes the issue. 15:58
psch oh, yeah, you're copying 15:59
that's probably it
hm, unless readBuffer.array() also returns a copy :/
bartolin: well, if it works it works... :)
yeah, .array() returns the actual array behind the ByteBuffer 16:00
bartolin I assumed that readBuffer.get starts to take values from current position 16:01
but I'm not sure if the patch breaks something else :-(
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)
so it's "get everything, from start to finish", not "get from .position to end"
bartolin oh.
psch which just makes it more confusing, honestly... :) 16:04
i think the original issue is that .array() gets you the reference to the original array backing the ByteBuffer
and wrapping a different ByteBuffer around that gets somewhat racey, because now you have to ByteBuffers that clobber over the same array
well, except not really racey (as in "race condition", of course :P ) 'cause it's not async or parallel 16:05
16:08 cognominal joined
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:09
psch yeah, i'll look a bit closer later on 16:10
bartolin ++psch 16:11
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:17
psch bartolin: oh, you're right! the offset is for the destination 16:19
bartolin: i think the easier patch is just replacing "readBuffer.position()" with 0 16:35
bartolin: 'cause afaict you're still shoving the whole buffer into newBytes
bartolin tries that 16:40
yes, seems to work. (though I don't understand why) 16:50
oh, no, it does not work! (still get the first line twice)
bartolin is confused and tries again 16:54
nine A SiXModelObject with a null st? 16:55
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
nine It's the object that gets passed to setcodeobj when trying to run the EVAL during precompilation 17:06
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...
bartolin btw, it only helps with the .slurp-rest() call. with .slurp-rest(:bin) the data is still missing 17:10
I'll open a PR then ... 17:11
psch hrm, SyncHandle is quite a thing :/ 17:24
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
cause that's part of what .flip() does
ohh. but we don't flip the channel (if that even works...) 17:25
hmm, now how do i get a VMArrayInstance_i8 (or _u8) in nqp code :/ 17:42
nine: i forgot where debugname hangs, but i don't think it's the STable 17:44
nine: i wanna say REPR, but...
nine public String debugName; is in runtime/org/perl6/nqp/sixmodel/STable.java 17:45
psch ah shucks :<
typeName also needs the st :/
...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.
Everything of interest seems to do
psch d'you have a jdb dump of the object?
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:11
as in, a ByteChannel doesn't seem to care what's been read before, maybe? :/ 18:13
i probably should test that...
19:45 dalek joined 19:46 dalek joined 19:47 dalek joined 19:48 dalek joined
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:50
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:51
moritz timotimo: wait what? it's not in here yet? 19:52
timotimo moritz: note the difference between #perl6-dev and #p6dev 19:53
#p6dev being here, #perl6-dev being over there :)
moritz oh noez
this is starting to get confusing
timotimo well, we're kicking out #p6dev 19:54
so it's not increasing the number of channels, but the channels get more systematically named
19:55 ilbot3 joined
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
should make things at least differently confusing
timotimo oh, forwards, neat. 19:57
20:04 timotimo left 20:11 bartolin left 20:24 psch left 20:38 cognominal joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!