github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
ugexe fwiw here is the previous reviewed pr -- github.com/MoarVM/MoarVM/pull/1037 00:04
libuv 1.27 (released today) has 'udp: add support for UDP connected sockets' 00:21
00:45 brrt left
ugexe github.com/MoarVM/MoarVM/pull/1050 <-- this can be merged now 02:05
timotimo i just merged 1050 and 1049 (the uname op change) 02:23
ugexe cool 02:39
if anyone can think of an alternative way to get $*KERNEL.bits than calling out to `bin/uname -p` then we can totally get rid of shelling out to uname altogether 02:40
however it seems like different platforms/distros patch uname -p to give some meaningful result 02:41
osx for instance always returns 'i386' for uname -p 02:42
even though uname -m will say x86_64
so we basically need an alternative way to get at whatever $*KERNEL.arch is suppsoed to represent 02:44
not $*KERNEL.bits like i mistakeningly said earlier 02:45
how does one bump MOAR_REVISION? for instance it currently says 2019.03-31-g6c7810c -- do I just manually type [year].[month]-[two random digits?]-[one random letter?][git rev-parse --short HEAD] 03:03
timotimo no, "git describe --tags" is what gives you the right data 03:06
ugexe: i think in the PR that changes MVM_thread_new you didn't push a change to the .h file that has MVM_thread_new in it 03:08
ugexe sure enough... missed it when updating the ops 03:15
timotimo travis was quite loud about it :)
ugexe i didn't check travis since the nqp travis will use wont be able to test it (i think)
timotimo yeah, i had it open for something else, and it showed moar's latest build 03:16
i checked the log before i read the PR description
ugexe fixed 03:20
m: use nqp; my $uname := nqp::uname(); say nqp::atpos_s($uname, nqp::const::UNAME_MACHINE); 03:52
camelia x86_64
09:06 domidumont joined 10:00 zakharyas joined 10:31 lucasb joined 11:40 zakharyas left, domidumont left 12:56 domidumont joined, brrt joined
brrt ohai 12:56
.ask ugexe why not just compile $*KERNEL.bits in?
yoleaux brrt: I'll pass your message to ugexe.
brrt as in, we know that value at compile time, don't we?
I'd rather see a hash of type sizes even 12:57
timotimo we do not 12:59
you can run a 32bit application on a 64bit kernel
brrt well, that is true 13:03
but I'm wondering in which case that would be true (we'd run a 32 bit moarvm) where you'd nevertheless care about the 64-bitness of the processor
timotimo i haven't the slightest 13:06
brrt I don't really know in what cases you'd even use the $*KERNEL.bits parameter 13:10
but probably ugexe does :-)
lizmat brrt: some applications using NativeCall might want to know ? 13:22
brrt brrt-to-the-future.blogspot.com/20...ation.html 13:23
lizmat: a): the system linker (resolving dlsym) would want to know, no reason why the application would too; b): if MoarVM was built as 32 bits, it had better link to 32 bit code, otherwise it wouldn't work (different ABIs etc) 13:24
so I don't think the actual-cpu-architecture (as opposed to the ISA the VM was built for) is very relevant unless one is in fact writing a compiler 13:25
in which case, I think shelling out to uname is perfectly acceptable. But I don't know if that's the common thing to optimize for 13:26
timotimo i feel like some graphics could be useful for posts involving the exprjit 13:37
brrt me too.... but I don't have dot on this laptop
timotimo i can install dot on hack :)
brrt I'll get my regular working laptop out :-)
timotimo then we'll have .hack 13:38
brrt I don't have an ccount at hack
timotimo then i can .hack//sign you up for one
brrt :-) 13:39
(then I need to install PuTTy)
I might as well just pick my other laptop
timotimo googles graphviz emscripten
viz-js.com/ has something more like a gui, www.webgraphviz.com/ is more or less the simplest thing you can come up with 13:40
outputs svg i think?
the latter, i mean. the former can output differen formats and even lets you choose engines
brrt hehe 13:41
ok, you win
timotimo: better now? 13:58
13:59 brrt` joined 14:02 brrt left
timotimo not bad :) 14:03
brrt` any other places that would benefit? 14:04
timotimo the post doesn't really have much asm in it or tiles or something like that 14:05
that may be the place that might most benefit from a graphical representation
brrt` right 14:06
I tried to keep asm to a minum
but nevertheless it's a bit of a mumble
oh well. that's what I've been thinking about, anyway 14:08
timotimo i do think i kind of understand it better now, though
brrt` :-)
timotimo not that i could really help :|
brrt` idk. ideas may come from anywhere
anyway, i'm offline for a couple of hours 14:13
14:13 brrt` left 14:34 AlexDaniel left
ugexe I meant KERNEL.arch, not KERNEL.bits 14:34
yoleaux 12:56Z <brrt> ugexe: why not just compile $*KERNEL.bits in?
14:53 AlexDaniel joined 14:56 squashable6 left, quotable6 left, benchable6 left, shareable6 left 14:57 quotable6 joined, squashable6 joined 15:00 shareable6 joined, benchable6 joined
dogbert17 m: await (^1000).map({ start { EVAL '/0|1|2/' } }); say 'ok' 15:08
camelia ===SORRY!===
Decoder may not be used concurrently
15:10 lucasb left 15:17 Elronnd left
ugexe i got this the *first* time, and the decoder error every time after: 15:29
===SORRY!===
Iteration past end of iterator
.tell brrt i imagine that is/was what $?KERNEL was for ( github.com/perl6/roast/blob/108058...ERNEL.t#L9 ) 15:31
yoleaux ugexe: I'll pass your message to brrt.
dogbert17 ugexe: the example is from RT#125978 15:32
now that the Decoder message comes up almost every time perhaps that might make it possible to figure out what's really happening 15:33
17:36 Geth left, Geth joined
AlexDaniel dogbert17: oh that freaking eval 17:54
19:52 domidumont left

Powered by Cro and the Raku® Programming Language.

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

Thank you!