Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-03

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

All times shown according to UTC.

Time Nick Message
00:01 [Coke] ... and what's the license of somethign like 3rdparty/sha1 ?
00:02 jnthn [Coke]: From top of sha1.c:
00:02 jnthn SHA-1 in C
00:02 jnthn By Steve Reid <sreid@sea-to-sky.net>
00:02 jnthn 100% Public Domain
00:04 [Coke] ah, was looking for a separate file. danke.
00:04 jnthn On uthash.h - what we have now is very much a derivative work
00:04 jnthn (as in, we have significant modifications to it)
00:07 [Coke] I think all macports needs is a listing of the licenses involved. We can be more specific in our own license file if needs be.
00:08 dalek MoarVM: 5eeb470 | Coke++ | ports/macports/Portfile:
00:08 dalek MoarVM: Don't explicitly set the defaults
00:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5eeb470989
00:15 [Coke] ugh. libtouv itself has multiple licenses.
00:16 [Coke] I thinik?
00:20 dalek MoarVM: 8fd0835 | Coke++ | LICENSE:
00:20 dalek MoarVM: List known licenses for 3rdparty/
00:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8fd08351a4
00:25 dalek MoarVM: e24081d | Coke++ | ports/macports/Portfile:
00:25 dalek MoarVM: Be explicit about sub-licenses for macports
00:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e24081d0a1
00:31 dalek MoarVM: 5c69731 | Coke++ | ports/macports/Portfile:
00:31 dalek MoarVM: fix case, per #macports
00:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5c69731e9a
00:44 travis-ci joined #moarvm
00:44 travis-ci MoarVM build failed. Coke 'fix case, per #macports'
00:44 travis-ci http://travis-ci.org/MoarVM/MoarVM/builds/52832202 https://github.com/MoarVM/MoarVM/compare/e24081d0a1d8...5c69731e9a25
00:44 travis-ci left #moarvm
00:45 timotimo [Coke]: great, you broke it! :P
00:47 jnthn By...editing a Portfile? That's a bit Chuck Norris...
00:47 timotimo checking whether build environment is sane... configure: error: newly created file is older than distributed files!
00:48 timotimo this is libatomicops' configure script
00:52 timotimo in the MVMIODatagramy, would I supply the address (which i think we'll be modeling as a Buf) as a MVMArray * parameter?
00:52 timotimo it seems like that's what all the other ops do: take an MVMOSHandle * parameter for the "self", so to speak
00:52 timotimo but this isn't the self parameter
00:53 jnthn timotimo: See what the read/write Buf ops do
00:54 timotimo 'k
00:56 agentzh joined #moarvm
00:56 timotimo um, not entirely sure which functions you're refering to right now
00:56 timotimo MVM_io_read_bytes?
00:57 timotimo that seems like a usable example
01:00 timotimo recvfrom ought to allow for supplying an address to receive from, or not supplying an address and filling the buffer with the address that was actually received from, or to not set an address because the udp socket has been "connected"
01:20 timotimo locking a UDP socket for reading/writing doesn't make much sense, right?
01:20 timotimo er for receiving/sending
01:21 timotimo hm. actually, it might
01:22 timotimo hm, a sync socket isn't locked?
01:29 jnthn timotimo: Probably, but note locking happens up in io.c iirc
01:32 timotimo ah, the mutex is in the MVMOSHandle's body
01:32 timotimo that explains why i got confused
01:32 timotimo i was looking for it in the data that's attached to the body
01:36 timotimo (and also explains why there's nothing like a "lockable" piece to the IOOps
01:59 jnthn sleep &
02:27 dalek MoarVM/udp_sockets: f72a592 | timotimo++ | src/ (11 files):
02:27 dalek MoarVM/udp_sockets: stub the first draft for datagram sockets (i.E. UDP)
02:27 dalek MoarVM/udp_sockets: review: https://github.com/MoarVM/MoarVM/commit/f72a5922c5
02:34 Peter_R joined #moarvm
04:28 agentzh joined #moarvm
05:40 agentzh joined #moarvm
07:53 FROGGS joined #moarvm
07:54 zakharyas joined #moarvm
08:06 Ven joined #moarvm
08:08 rurban joined #moarvm
08:17 Ven joined #moarvm
08:20 agentzh joined #moarvm
09:30 kjs_ joined #moarvm
11:20 agentzh joined #moarvm
11:24 Ven joined #moarvm
11:46 rurban joined #moarvm
14:02 kjs_ joined #moarvm
15:35 Ven joined #moarvm
15:59 colomon joined #moarvm
16:11 rurban joined #moarvm
16:13 Ven joined #moarvm
17:07 rurban joined #moarvm
17:35 donaldh joined #moarvm
17:40 donaldh joined #moarvm
17:50 tgt joined #moarvm
18:13 kjs_ joined #moarvm
18:29 FROGGS joined #moarvm
19:15 lizmat joined #moarvm
19:32 colomon joined #moarvm
19:36 agentzh joined #moarvm
19:43 tgt joined #moarvm
19:46 brrt joined #moarvm
20:15 brrt timotimo++ for working on moarvm udp capability
20:15 brrt udp is awesome
20:15 brrt or: 'udp is sometimes a very nice tool for solving problems with networks'
20:18 timotimo can you tell if the design is sensible or problematic?
20:18 timotimo (apart from crashing all of the spec tests related to async stuff)
20:22 brrt not yet, i haven't really seen all you're trying to do
20:23 brrt btw, we can remove the moar-jit branch, can't we?
20:24 brrt ok, i think i can comment
20:24 timotimo sure, we can
20:26 brrt ok, first things first
20:27 brrt as i understand UDP, it doesn't make that much of a difference if you use it in synchronous mode versus asynchronous mode
20:27 brrt in neither case is delivery guaranteed
20:27 brrt i think synchronous mode just waits until the buffer is sent, but i'm not even sure of that
20:27 timotimo well, for receiving the API difference is the main point
20:28 brrt fair point
20:28 timotimo you may not want the round trip through the extra thread that has the event loop
20:28 brrt but personally i'd call that - excuse the bikeshedding :-) - blocking receiving vs nonblocking receiving
20:28 timotimo and at some point we'll possibly do our IO without libuv
20:28 timotimo that's ... exactly what we mean by async vs sync I/O ...
20:28 timotimo hm ... well, not completely
20:28 brrt fair enough :-)
20:29 brrt anyway, it's bikeshedding and not important
20:29 brrt my real question is
20:29 brrt why is the message an MVMArray
20:29 brrt rather than an MVMString
20:29 timotimo MVMStrings are encoded
20:30 timotimo do MVMStrings allow null bytes?
20:30 FROGGS brrt: a buffer in P6 is an MVMArray
20:30 FROGGS a blob8 for example
20:30 timotimo aye
20:30 brrt ok, i see
20:30 timotimo the perl6-level api may allow Str to be passed and automatically encoded
20:31 brrt i was under the impression that MVMString was  the underlying buffer type
20:31 FROGGS no
20:32 brrt looks sensible enough to me, really
20:33 timotimo now i have to actually implement it :(
20:34 FROGGS :P
20:41 jnthn Sucks when you actually have to turn nice ideas into working code, dammit. :)
20:42 FROGGS jnthn: I know this is not #jvm... but is the outer of a CU potentially the setting?
20:43 jnthn Outer of a...CU?
20:43 jnthn CUs don't have outers
20:43 jnthn The outer of the unit scope of a program or module is the setting
20:44 jnthn So yes, you reach the setting lexicals through .outer
20:44 FROGGS ahh yes, that's what I meant
20:45 FROGGS so, for the jvm/uri bug the problematic callframe does not reach the setting
20:45 FROGGS and the outers it has do not appear elsewhere in my dump
20:46 FROGGS so, now I need to check how the outers are set up when DefaultPort.pm gets precompiled
20:46 FROGGS (and how these are then deserialized)
20:46 jnthn Yeah...is the code in question in a role?
20:46 donaldh joined #moarvm
20:46 FROGGS no
20:47 jnthn Hm, ok
20:48 FROGGS that's the code: https://gist.github.com/FROGGS/1401a5ed729089a6aa17
20:48 FROGGS and that's the result:
20:48 FROGGS Can not invoke object '&postcircumfix:<{ }>'
20:48 FROGGS in sub scheme_port at lib/URI/DefaultPort.pm:30
20:48 FROGGS in method default_port at lib/URI.pm:5
20:49 FROGGS so, it is a quite short bit of code
20:53 FROGGS I guess.... since it is a problem with precomp only there must be an issue while serializing or deserializing
20:55 FROGGS ummm, how does that happen for the jvm?
20:56 jnthn Not too different from on moar
20:56 jnthn There's an implementation of serialization/deserialization, written in Java.
20:57 FROGGS ahh, I was looking at runtime/CallFrame.java, not repr/*
20:58 FROGGS and curFrame.codeRef.name is quite helpful :o)
21:00 FROGGS ohh wait... the other call frames here it can find &postcircumfix:<{ }> are called <unit>... and of course, it gets exported into our <unit> namespace, right?
21:01 FROGGS and for the case where it cant find &postcircumfix:<{ }>, it hits its <unit> but misses the symbol
21:04 timotimo well, i'm glad to hear the UDP code sounds like a good idea to you
21:06 lizmat and the idea is that an UDP listening socket is a Supply that can be tapped ?
21:07 jnthn lizmat: Presumably that's the async impl, yes
21:09 FROGGS ahh... when I load DefaultPort.pm directly it works and the symbol is found in the fourth outer
21:09 FROGGS when I load it via URI.pm the outer chain breaks after the second outer
21:09 timotimo yup
21:12 donaldh_ joined #moarvm
21:51 dalek MoarVM/udp_sockets: 140453b | timotimo++ | src/io/syncsocket.c:
21:51 dalek MoarVM/udp_sockets: fix recvfrom redeclaration, add necessary NULLs to op tables
21:51 dalek MoarVM/udp_sockets: review: https://github.com/MoarVM/MoarVM/commit/140453bc7b
22:03 dalek MoarVM/udp_sockets: 4a6c4b7 | timotimo++ | / (5 files):
22:03 dalek MoarVM/udp_sockets: introduce ops needed for udp sockets
22:03 dalek MoarVM/udp_sockets:
22:03 dalek MoarVM/udp_sockets: resolvehostname - builds an address like we use for udp packets
22:03 dalek MoarVM/udp_sockets: recvfrom - receives a message (and address) into two buffers
22:03 dalek MoarVM/udp_sockets: sendto - sends a message to an address
22:03 dalek MoarVM/udp_sockets: review: https://github.com/MoarVM/MoarVM/commit/4a6c4b7155
22:08 colomon joined #moarvm
22:30 donaldh joined #moarvm
22:35 timotimo jnthn: is this actually correct?
22:35 timotimo MVMArray  *res_buf     = (MVMArray *)MVM_repr_alloc_init(tc, buf_type);
22:35 timotimo res_buf->body.slots.i8 = (MVMint8 *)buf->base;
22:35 timotimo it would seem like alloc_init for MVMArray would have the body->slots already malloc'd to something?
22:35 * timotimo gets a clue and actually looks at the code
22:36 timotimo oh, its allocate is just NULL
22:37 timotimo that's fine then
22:37 jnthn Yeah, it's NULL until you populate it
22:37 jnthn We kinda violate the REPR ehre
22:37 jnthn *here
22:37 jnthn Which is sort of OK but will mean we have to refactor the places we've been cheating.
22:37 jnthn If we change the REPR
22:38 jnthn Which we prolly will.
22:39 kjs_ joined #moarvm
22:39 donaldh FROGGS: DC_CALL_C_ARM_ARMHF didn't fix NativeCall
22:39 donaldh FROGGS: I'll dig a bit deeper
22:40 FROGGS donaldh: there are more: MoarVM/3rdparty/dyncall/dyncall/dyncall.h:51
22:40 FROGGS :o)
22:41 agentzh joined #moarvm
22:42 timotimo jnthn: well, REPR contract is "repr ops never allocate", but malloc isn't the same as MVM_allocate :)
22:42 donaldh Yes, but from dyncall docs: DC_CALL_C_ARM_ARMHF C arm call (arm hardfloat - e.g. raspberry pi)
22:42 donaldh Can certainly try ARM_ARM
22:43 timotimo arf arf!
22:44 FROGGS hrmf
22:45 timotimo jnthn: would you suggest i stash a type object to use for message and addresses when calling udpsocket?
22:45 timotimo jnthn: or should i pass one (or two) type objects to recvfrom and sendto at all times?
22:45 timotimo oh, actually
22:45 timotimo recvfrom should receive an already existing buffer for the address (though not necessarily a filled one)
22:46 timotimo and sendto should either get passed an address or not get an address at all, as in VMNull
22:46 timotimo but a type object for the message that gets received would stlil be necessary, i believe
22:50 dalek MoarVM: 47871fa | jnthn++ | src/core/nativecall.c:
22:50 dalek MoarVM: Fix missing rooting of callback object args.
22:50 dalek MoarVM:
22:50 dalek MoarVM: Problem discovered by nine++. This hopefully fixes the occasional
22:50 dalek MoarVM: method call failures in Inline::Perl5 and Inline::Python.
22:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/47871fabbd
22:53 jnthn timotimo: The convention so far is to pass things to the op
22:53 jnthn timotimo: For IO stuff, at least
22:53 jnthn timotimo: This is mostly because there's sometimes more than one way to view it in these cases
22:55 dalek MoarVM/udp_sockets: 70e6070 | timotimo++ | / (5 files):
22:55 dalek MoarVM/udp_sockets: resolvehostname and recvfrom need a type object param
22:55 dalek MoarVM/udp_sockets: review: https://github.com/MoarVM/MoarVM/commit/70e60703ec
22:55 dalek MoarVM/udp_sockets: 0ba6ce6 | timotimo++ | src/ (2 files):
22:55 dalek MoarVM/udp_sockets: stub ops in interp and impl resolvehostname
22:55 dalek MoarVM/udp_sockets: review: https://github.com/MoarVM/MoarVM/commit/0ba6ce63bd
22:55 timotimo ^- you could have a quick look at this and see if it's any good at all
22:58 dalek MoarVM/udp_sockets: c423138 | timotimo++ | src/core/interp.c:
22:58 dalek MoarVM/udp_sockets: correct operation sizes
22:58 dalek MoarVM/udp_sockets: review: https://github.com/MoarVM/MoarVM/commit/c423138839
23:01 FROGGS jnthn: prioInvocation was meant to go away, right?
23:01 travis-ci joined #moarvm
23:01 travis-ci MoarVM build passed. jnthn 'Fix missing rooting of callback object args.
23:01 travis-ci http://travis-ci.org/MoarVM/MoarVM/builds/52970652 https://github.com/MoarVM/MoarVM/compare/5c69731e9a25...47871fabbd54
23:01 travis-ci left #moarvm
23:05 dalek MoarVM: 1e80a56 | nicholas++ | src/spesh/optimize.c:
23:05 dalek MoarVM: Fix big endian bug in if/unless optimization.
23:05 dalek MoarVM:
23:05 dalek MoarVM: Writing to 16-bit int member of a union and reading it as a 64-bit
23:05 dalek MoarVM: int is a very bad idea on BE platforms. Unbreaks the NQP/Rakudo
23:05 dalek MoarVM: build on PowerPC big endian.
23:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1e80a56939
23:06 jnthn FROGGS: Yes, but it's some...work :)
23:07 FROGGS nwc10++
23:07 FROGGS jnthn: is it possible that this is the root of my bug?
23:09 jnthn FROGGS: It's hard to say. It may be a discrepancy that shows the problem up on JVM. OTOH, we handle plenty of other things correctly on JVM wiht the current model, even if it's not ideal.
23:09 jnthn (Where plenty = most)
23:09 timotimo oh darn, that was me
23:09 FROGGS the bug appears when I call A::B::c after loading A and A::B... and it appears when I call A::c which call A::B::c
23:09 FROGGS calls*
23:11 jnthn FROGGS: Hmmm
23:12 jnthn FROGGS: I wonder if there's possibly some discrepancy in stash merging between Moar and JVM?
23:12 FROGGS jnthn: where does that happen?
23:12 FROGGS do you know a keyword I could grep for?
23:13 jnthn FROGGS: mo
23:13 jnthn ModuleLoaderVMConfig.nqp
23:13 jnthn Under src/vm/moar/ and src/vm/jvm/
23:13 FROGGS in rakudo?
23:14 jnthn ah, wait
23:14 jnthn yeah, Rakudo
23:14 jnthn But the code in question appears to actually be shared
23:14 jnthn FROGGS: Search for resolve_repossession_conflicts
23:15 dalek MoarVM: 88b6e37 | jnthn++ | src/spesh/facts. (2 files):
23:15 dalek MoarVM: Simplify facts known value handling.
23:15 dalek MoarVM:
23:15 dalek MoarVM: If we know a value is an integer constant as a fact, it's really not
23:15 dalek MoarVM: important for optimization precisely what size register or constant
23:15 dalek MoarVM: operand we obtained it from. This patch tosses the sized variants and
23:15 dalek MoarVM: fixes the tiny number of places that used to store to them. This will
23:15 dalek MoarVM: hopefully avoid introducing BE bugs in the future.
23:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/88b6e37dd6
23:16 FROGGS hmmm, that does not explain why the .outers seems to end prematurely
23:17 jnthn Hm, no...
23:17 timotimo jnthn: what perl6-level type do you suggest to provide for the VMArray repr'd type object argument to resolvehostname?
23:17 FROGGS it feels like as if the outer CallFrames were just not constructed...
23:17 timotimo utf8 segv's, Blob and Buf will tell me You cannot create an instance of this type
23:18 jnthn timotimo: Uh, if utf8 SEGVs, something is wrong...but that's likely a bad choice given it's not actually UTF-8 data, no? :)
23:18 jnthn timotimo: Could try blob8
23:18 timotimo yeah
23:18 timotimo does blob8 exist? :o
23:18 FROGGS CallFrame 2059809544 has as its outer 839572655, but 839572655 is not created as a CallFrame
23:18 timotimo cannot create an instance of this type :(
23:19 FROGGS ohh, I also need to look at the other constructor
23:19 jnthn m: say blob8.REPR
23:19 camelia rakudo-moar 0f6116: OUTPUT«Uninstantiable␤»
23:19 jnthn m: say blob8.^pun
23:19 camelia rakudo-moar 0f6116: OUTPUT«No such method 'pun' for invocant of type 'Perl6::Metamodel::CurriedRoleHOW'␤  in block <unit> at /tmp/GSfxe13Itn:1␤␤»
23:19 jnthn m: say blob8.^make_pun
23:19 FROGGS m: say blob8.^make_pun
23:19 camelia rakudo-moar 0f6116: OUTPUT«(Blob[uint8])␤»
23:19 camelia rakudo-moar 0f6116: OUTPUT«(Blob[uint8])␤»
23:19 jnthn m: say blob8.^make_pun.REPR
23:19 camelia rakudo-moar 0f6116: OUTPUT«VMArray␤»
23:20 jnthn Mebbe that should jsut be called pun though :)
23:20 timotimo but yeah, i probably made a wrong and should gdb or so
23:23 jnthn m: say utf8.REPR
23:23 camelia rakudo-moar 0f6116: OUTPUT«VMArray␤»
23:23 jnthn yeah, indeed
23:23 dalek MoarVM: 3d0404a | jnthn++ | src/spesh/ (3 files):
23:23 dalek MoarVM: Remove mention of size from fact int/num value.
23:23 dalek MoarVM:
23:23 dalek MoarVM: Hopefully avoiding temptation to end up with them again in the future.
23:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3d0404a11e
23:26 colomon joined #moarvm
23:27 timotimo m: say buf8.REPR
23:27 camelia rakudo-moar 0f6116: OUTPUT«Uninstantiable␤»
23:27 timotimo m: say blob8.REPR
23:27 camelia rakudo-moar 0f6116: OUTPUT«Uninstantiable␤»
23:27 timotimo m: say buf8.new.REPR
23:27 camelia rakudo-moar 0f6116: OUTPUT«VMArray␤»
23:27 timotimo that's how i can do it
23:27 timotimo (but why?)
23:28 jnthn timotimo: Showed you ahve to do buf8.^make_pun to do it :)
23:28 jnthn s/ahve//
23:28 jnthn oh, it was meant ot be above :)
23:29 timotimo ah
23:29 timotimo now i see it
23:31 timotimo hm
23:31 timotimo i don't have to set the slot type anywhere in my C, because that's part of the type object, yeah?
23:32 timotimo oh
23:32 timotimo i only had to "make" in order to make it work ...
23:32 jnthn timotimo: Well, part of the type, yes
23:33 timotimo timo@schmetterling ~/p/rakudo (nom)> perl6 -e 'say nqp::resolvehostname("perl6.org", 0x80, buf8.new)'
23:33 timotimo Buf[uint8]:0x<02 00 00 80 d5 5f 52 35 00 00 00 00 00 00 00 00>
23:33 timotimo timo@schmetterling ~/p/rakudo (nom)> perl6 -e 'say nqp::resolvehostname("google.com", 0x80, buf8.new)'
23:33 timotimo Buf[uint8]:0x<02 00 00 80 ad c2 71 82 00 00 00 00 00 00 00 00>
23:33 timotimo 2 is the INET type, i believe
23:33 timotimo 80 is the port, after that seems to just be the ip address (but why all the null bytes? who knows.)
23:35 FROGGS timotimo: you can store your sekrit password there :o)
23:35 timotimo :3
23:35 FROGGS the port number wont be a single byte fwiw
23:36 FROGGS or are you talking about the trailing bytes?
23:37 timotimo jnthn: why do we free the host_cstr but not the port_cstr?
23:37 timotimo oh
23:37 timotimo because that's on the stack
23:38 FROGGS gnight
23:38 timotimo aaw
23:38 timotimo no more froggs today
23:44 dalek MoarVM/udp_sockets: 8d4a26a | timotimo++ | src/io/syncsocket.c:
23:44 dalek MoarVM/udp_sockets: a bit of cleanup
23:44 dalek MoarVM/udp_sockets: review: https://github.com/MoarVM/MoarVM/commit/8d4a26a96e
23:45 * jnthn is le tired
23:45 timotimo anything cool i can look forward to for tomorrow? :)
23:46 jnthn Dunno. I've a course to finish up writing.
23:46 jnthn So depends how well that goes tomorrow :)
23:47 timotimo OK
23:47 timotimo good luck!
23:47 timotimo and have a good rest :)
23:47 jnthn March is going to be a little busy. On the upside, I'll have significantly more Perl 6 time from April onwards. :)

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