[Coke] ... and what's the license of somethign like 3rdparty/sha1 ? 00:01
jnthn [Coke]: From top of sha1.c: 00:02
SHA-1 in C
By Steve Reid <sreid@sea-to-sky.net>
100% Public Domain
[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
(as in, we have significant modifications to it)
[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:07
dalek arVM: 5eeb470 | Coke++ | ports/macports/Portfile:
Don't explicitly set the defaults
 00:08
[Coke] ugh. libtouv itself has multiple licenses. 00:15
I thinik? 00:16
dalek arVM: 8fd0835 | Coke++ | LICENSE:
List known licenses for 3rdparty/
 00:20
arVM: e24081d | Coke++ | ports/macports/Portfile:
Be explicit about sub-licenses for macports
 00:25
arVM: 5c69731 | Coke++ | ports/macports/Portfile:
fix case, per #macports
 00:31
00:44 travis-ci joined
travis-ci MoarVM build failed. Coke 'fix case, per #macports' 00:44
travis-ci.org/MoarVM/MoarVM/builds/52832202 github.com/MoarVM/MoarVM/compare/e...69731e9a25
00:44 travis-ci left
timotimo [Coke]: great, you broke it! :P 00:45
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!
this is libatomicops' configure script 00:48
in the MVMIODatagramy, would I supply the address (which i think we'll be modeling as a Buf) as a MVMArray * parameter? 00:52
it seems like that's what all the other ops do: take an MVMOSHandle * parameter for the "self", so to speak
but this isn't the self parameter
jnthn timotimo: See what the read/write Buf ops do 00:53
timotimo 'k 00:54
00:56 agentzh joined
timotimo um, not entirely sure which functions you're refering to right now 00:56
MVM_io_read_bytes?
that seems like a usable example 00:57
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:00
locking a UDP socket for reading/writing doesn't make much sense, right? 01:20
er for receiving/sending
hm. actually, it might 01:21
hm, a sync socket isn't locked? 01:22
jnthn timotimo: Probably, but note locking happens up in io.c iirc 01:29
timotimo ah, the mutex is in the MVMOSHandle's body 01:32
that explains why i got confused
i was looking for it in the data that's attached to the body
(and also explains why there's nothing like a "lockable" piece to the IOOps 01:36
jnthn sleep & 01:59
dalek arVM/udp_sockets: f72a592 | timotimo++ | src/ (11 files):
stub the first draft for datagram sockets (i.E. UDP)
 02:27
02:34 Peter_R joined 04:28 agentzh joined 05:40 agentzh joined 07:53 FROGGS joined 07:54 zakharyas joined 08:06 Ven joined 08:08 rurban joined 08:17 Ven joined 08:20 agentzh joined 09:30 kjs_ joined 11:20 agentzh joined 11:24 Ven joined 11:46 rurban joined 14:02 kjs_ joined 15:35 Ven joined 15:59 colomon joined 16:11 rurban joined 16:13 Ven joined 17:07 rurban joined 17:35 donaldh joined 17:40 donaldh joined 17:50 tgt joined 18:13 kjs_ joined 18:29 FROGGS joined 19:15 lizmat joined 19:32 colomon joined 19:36 agentzh joined 19:43 tgt joined 19:46 brrt joined
brrt timotimo++ for working on moarvm udp capability 20:15
udp is awesome
or: 'udp is sometimes a very nice tool for solving problems with networks'
timotimo can you tell if the design is sensible or problematic? 20:18
(apart from crashing all of the spec tests related to async stuff)
brrt not yet, i haven't really seen all you're trying to do 20:22
btw, we can remove the moar-jit branch, can't we? 20:23
ok, i think i can comment 20:24
timotimo sure, we can
brrt ok, first things first 20:26
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
in neither case is delivery guaranteed
i think synchronous mode just waits until the buffer is sent, but i'm not even sure of that
timotimo well, for receiving the API difference is the main point
brrt fair point 20:28
timotimo you may not want the round trip through the extra thread that has the event loop
brrt but personally i'd call that - excuse the bikeshedding :-) - blocking receiving vs nonblocking receiving
timotimo and at some point we'll possibly do our IO without libuv
that's ... exactly what we mean by async vs sync I/O ...
hm ... well, not completely
brrt fair enough :-)
anyway, it's bikeshedding and not important 20:29
my real question is
why is the message an MVMArray
rather than an MVMString
timotimo MVMStrings are encoded
do MVMStrings allow null bytes? 20:30
FROGGS brrt: a buffer in P6 is an MVMArray
a blob8 for example
timotimo aye
brrt ok, i see
timotimo the perl6-level api may allow Str to be passed and automatically encoded
brrt i was under the impression that MVMString was the underlying buffer type 20:31
FROGGS no
brrt looks sensible enough to me, really 20:32
timotimo now i have to actually implement it :( 20:33
FROGGS :P 20:34
jnthn Sucks when you actually have to turn nice ideas into working code, dammit. :) 20:41
FROGGS jnthn: I know this is not #jvm... but is the outer of a CU potentially the setting? 20:42
jnthn Outer of a...CU? 20:43
CUs don't have outers
The outer of the unit scope of a program or module is the setting
So yes, you reach the setting lexicals through .outer 20:44
FROGGS ahh yes, that's what I meant
so, for the jvm/uri bug the problematic callframe does not reach the setting 20:45
and the outers it has do not appear elsewhere in my dump
so, now I need to check how the outers are set up when DefaultPort.pm gets precompiled 20:46
(and how these are then deserialized)
jnthn Yeah...is the code in question in a role?
20:46 donaldh joined
FROGGS no 20:46
jnthn Hm, ok 20:47
FROGGS that's the code: gist.github.com/FROGGS/1401a5ed729089a6aa17 20:48
and that's the result:
Can not invoke object '&postcircumfix:<{ }>'
in sub scheme_port at lib/URI/DefaultPort.pm:30
in method default_port at lib/URI.pm:5
so, it is a quite short bit of code 20:49
I guess.... since it is a problem with precomp only there must be an issue while serializing or deserializing 20:53
ummm, how does that happen for the jvm? 20:55
jnthn Not too different from on moar 20:56
There's an implementation of serialization/deserialization, written in Java.
FROGGS ahh, I was looking at runtime/CallFrame.java, not repr/* 20:57
and curFrame.codeRef.name is quite helpful :o) 20:58
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:00
and for the case where it cant find &postcircumfix:<{ }>, it hits its <unit> but misses the symbol 21:01
timotimo well, i'm glad to hear the UDP code sounds like a good idea to you 21:04
lizmat and the idea is that an UDP listening socket is a Supply that can be tapped ? 21:06
jnthn lizmat: Presumably that's the async impl, yes 21:07
FROGGS ahh... when I load DefaultPort.pm directly it works and the symbol is found in the fourth outer 21:09
when I load it via URI.pm the outer chain breaks after the second outer
timotimo yup
21:12 donaldh_ joined
dalek arVM/udp_sockets: 140453b | timotimo++ | src/io/syncsocket.c:
fix recvfrom redeclaration, add necessary NULLs to op tables
 21:51
arVM/udp_sockets: 4a6c4b7 | timotimo++ | / (5 files):
introduce ops needed for udp sockets

resolvehostname - builds an address like we use for udp packets recvfrom - receives a message (and address) into two buffers sendto - sends a message to an address		 22:03
22:08 colomon joined 22:30 donaldh joined
timotimo jnthn: is this actually correct? 22:35
MVMArray *res_buf = (MVMArray *)MVM_repr_alloc_init(tc, buf_type);
res_buf->body.slots.i8 = (MVMint8 *)buf->base;
it would seem like alloc_init for MVMArray would have the body->slots already malloc'd to something?
timotimo gets a clue and actually looks at the code
oh, its allocate is just NULL 22:36
that's fine then 22:37
jnthn Yeah, it's NULL until you populate it
We kinda violate the REPR ehre
*here
Which is sort of OK but will mean we have to refactor the places we've been cheating.
If we change the REPR
Which we prolly will. 22:38
22:39 kjs_ joined
donaldh FROGGS: DC_CALL_C_ARM_ARMHF didn't fix NativeCall 22:39
FROGGS: I'll dig a bit deeper
FROGGS donaldh: there are more: MoarVM/3rdparty/dyncall/dyncall/dyncall.h:51 22:40
:o)
22:41 agentzh joined
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)
Can certainly try ARM_ARM
timotimo arf arf! 22:43
FROGGS hrmf 22:44
timotimo jnthn: would you suggest i stash a type object to use for message and addresses when calling udpsocket? 22:45
jnthn: or should i pass one (or two) type objects to recvfrom and sendto at all times?
oh, actually
recvfrom should receive an already existing buffer for the address (though not necessarily a filled one)
and sendto should either get passed an address or not get an address at all, as in VMNull 22:46
but a type object for the message that gets received would stlil be necessary, i believe
dalek arVM: 47871fa | jnthn++ | src/core/nativecall.c:
Fix missing rooting of callback object args.

Problem discovered by nine++. This hopefully fixes the occasional method call failures in Inline::Perl5 and Inline::Python.		 22:50
jnthn timotimo: The convention so far is to pass things to the op 22:53
timotimo: For IO stuff, at least
timotimo: This is mostly because there's sometimes more than one way to view it in these cases
dalek arVM/udp_sockets: 70e6070 | timotimo++ | / (5 files):
resolvehostname and recvfrom need a type object param
 22:55
arVM/udp_sockets: 0ba6ce6 | timotimo++ | src/ (2 files):
stub ops in interp and impl resolvehostname
timotimo ^- you could have a quick look at this and see if it's any good at all
dalek arVM/udp_sockets: c423138 | timotimo++ | src/core/interp.c:
correct operation sizes
 22:58
FROGGS jnthn: prioInvocation was meant to go away, right? 23:01
23:01 travis-ci joined
travis-ci MoarVM build passed. jnthn 'Fix missing rooting of callback object args. 23:01
travis-ci.org/MoarVM/MoarVM/builds/52970652 github.com/MoarVM/MoarVM/compare/5...871fabbd54
23:01 travis-ci left
dalek arVM: 1e80a56 | nicholas++ | src/spesh/optimize.c:
Fix big endian bug in if/unless optimization.

Writing to 16-bit int member of a union and reading it as a 64-bit int is a very bad idea on BE platforms. Unbreaks the NQP/Rakudo build on PowerPC big endian.		 23:05
jnthn FROGGS: Yes, but it's some...work :) 23:06
FROGGS nwc10++ 23:07
jnthn: is it possible that this is the root of my bug?
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
(Where plenty = most)
timotimo oh darn, that was me
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
calls*
jnthn FROGGS: Hmmm 23:11
FROGGS: I wonder if there's possibly some discrepancy in stash merging between Moar and JVM? 23:12
FROGGS jnthn: where does that happen?
do you know a keyword I could grep for?
jnthn FROGGS: mo 23:13
ModuleLoaderVMConfig.nqp
Under src/vm/moar/ and src/vm/jvm/
FROGGS in rakudo?
jnthn ah, wait 23:14
yeah, Rakudo
But the code in question appears to actually be shared
FROGGS: Search for resolve_repossession_conflicts
dalek arVM: 88b6e37 | jnthn++ | src/spesh/facts. (2 files):
Simplify facts known value handling.

If we know a value is an integer constant as a fact, it's really not important for optimization precisely what size register or constant operand we obtained it from. This patch tosses the sized variants and fixes the tiny number of places that used to store to them. This will hopefully avoid introducing BE bugs in the future.		 23:15
FROGGS hmmm, that does not explain why the .outers seems to end prematurely 23:16
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?
FROGGS it feels like as if the outer CallFrames were just not constructed...
timotimo utf8 segv's, Blob and Buf will tell me You cannot create an instance of this type
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
timotimo: Could try blob8
timotimo yeah
does blob8 exist? :o
FROGGS CallFrame 2059809544 has as its outer 839572655, but 839572655 is not created as a CallFrame
timotimo cannot create an instance of this type :(
FROGGS ohh, I also need to look at the other constructor 23:19
jnthn m: say blob8.REPR
camelia rakudo-moar 0f6116: OUTPUTĀ«Uninstantiableā¤Ā»
jnthn m: say blob8.^pun
camelia rakudo-moar 0f6116: OUTPUTĀ«No such method 'pun' for invocant of type 'Perl6::Metamodel::CurriedRoleHOW'ā¤ in block <unit> at /tmp/GSfxe13Itn:1ā¤ā¤Ā»
jnthn m: say blob8.^make_pun
FROGGS m: say blob8.^make_pun
camelia rakudo-moar 0f6116: OUTPUTĀ«(Blob[uint8])ā¤Ā»
jnthn m: say blob8.^make_pun.REPR
camelia rakudo-moar 0f6116: OUTPUTĀ«VMArrayā¤Ā»
jnthn Mebbe that should jsut be called pun though :) 23:20
timotimo but yeah, i probably made a wrong and should gdb or so
jnthn m: say utf8.REPR 23:23
camelia rakudo-moar 0f6116: OUTPUTĀ«VMArrayā¤Ā»
jnthn yeah, indeed
dalek arVM: 3d0404a | jnthn++ | src/spesh/ (3 files):
Remove mention of size from fact int/num value.

Hopefully avoiding temptation to end up with them again in the future.
23:26 colomon joined
timotimo m: say buf8.REPR 23:27
camelia rakudo-moar 0f6116: OUTPUTĀ«Uninstantiableā¤Ā»
timotimo m: say blob8.REPR
camelia rakudo-moar 0f6116: OUTPUTĀ«Uninstantiableā¤Ā»
timotimo m: say buf8.new.REPR
camelia rakudo-moar 0f6116: OUTPUTĀ«VMArrayā¤Ā»
timotimo that's how i can do it
(but why?)
jnthn timotimo: Showed you ahve to do buf8.^make_pun to do it :) 23:28
s/ahve//
oh, it was meant ot be above :)
timotimo ah 23:29
now i see it
hm 23:31
i don't have to set the slot type anywhere in my C, because that's part of the type object, yeah?
oh 23:32
i only had to "make" in order to make it work ...
jnthn timotimo: Well, part of the type, yes
timotimo timo@schmetterling ~/p/rakudo (nom)> perl6 -e 'say nqp::resolvehostname("perl6.org", 0x80, buf8.new)' 23:33
Buf[uint8]:0x<02 00 00 80 d5 5f 52 35 00 00 00 00 00 00 00 00>
timo@schmetterling ~/p/rakudo (nom)> perl6 -e 'say nqp::resolvehostname("google.com", 0x80, buf8.new)'
Buf[uint8]:0x<02 00 00 80 ad c2 71 82 00 00 00 00 00 00 00 00>
2 is the INET type, i believe
80 is the port, after that seems to just be the ip address (but why all the null bytes? who knows.)
FROGGS timotimo: you can store your sekrit password there :o) 23:35
timotimo :3
FROGGS the port number wont be a single byte fwiw
or are you talking about the trailing bytes? 23:36
timotimo jnthn: why do we free the host_cstr but not the port_cstr? 23:37
oh
because that's on the stack
FROGGS gnight 23:38
timotimo aaw
no more froggs today
dalek arVM/udp_sockets: 8d4a26a | timotimo++ | src/io/syncsocket.c:
a bit of cleanup
 23:44
jnthn is le tired 23:45
timotimo anything cool i can look forward to for tomorrow? :)
jnthn Dunno. I've a course to finish up writing. 23:46
So depends how well that goes tomorrow :)
timotimo OK 23:47
good luck!
and have a good rest :)
jnthn March is going to be a little busy. On the upside, I'll have significantly more Perl 6 time from April onwards. :)

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!