github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:05 squashable6 left, squashable6 joined 00:19 squashable6 left 00:24 sena_kun left, squashable6 joined 00:48 squashable6 left 00:51 squashable6 joined 01:36 AlexDani` joined 01:40 AlexDaniel left 02:00 AlexDani` left 04:42 squashable6 left 04:47 squashable6 joined 04:57 robertle left 05:36 scovit left 05:55 scovit joined 06:04 Geth left 06:05 Geth joined 06:10 domidumont joined 06:12 brrt joined
brrt \o 06:28
nwc10 o/ 06:30
brrt (and something more complex than add_i would have significantly more nodes, and as such have a much later overhead from a double-linked-list structure)
but the real reason is that I've started liking working with arrays much more in C, than with 'objects' 06:31
06:36 harrow left
brrt www.microsoft.com/en-us/research/w...017mem.pdf this is fascinating stuff, I think 06:43
they claim to have a 'safe' implementation of free() 06:44
and I believe them
06:47 harrow joined 07:20 patrickb joined 07:34 zakharyas joined 09:10 sena_kun joined 09:31 brrt left 09:32 brrt joined 09:41 Geth left 09:42 Geth joined 09:49 Geth left 09:50 Geth joined 09:53 brrt left
timotimo from just reading a little bit, it seems like it's kind-of-sort-of stochastically ensuring proper exceptions be thrown when deletes aren't correct, and also requires knowledge of what is or isn't pointers on the heap, much like a GC would do 09:59
i wonder how much faster it'd be to have a "shadow map" of memory that has 1s where the "real" memory has gc-managed pointers 10:00
10:38 domidumont left 10:42 brrt joined 10:58 zakharyas left 12:03 zakharyas joined 12:14 domidumont joined 12:52 robertle joined 13:20 domidumont1 joined 13:23 domidumont left 13:26 domidumont joined 13:28 domidumont1 left
brrt it's funny (and somewhat annoying) how they refer to a 'strongly typed language' 13:48
as if strongly typed is well-defined
I expect better from microsoft research
(what they mean, in this case, is a dynamically typed language, in that the runtime maintains the type of the values)
13:52 zakharyas left 14:29 patrickb left 14:50 zakharyas joined 14:54 lucasb joined 15:09 robertle left, brrt left 15:49 domidumont1 joined 15:51 domidumont left 15:52 brrt joined 15:54 domidumont joined 15:56 domidumont1 left 17:00 TimToady left, TimToady joined 17:13 brrt left 17:15 robertle joined 17:44 zakharyas left 17:59 domidumont left
dogbert17 jnthn: you around? 18:04
have a question regarding the Proc:Async example here: docs.perl6.org/type/Proc::Async 18:05
is the handling of processes which take too long correct, i.e. what will happen after the 'Promise in(5)' block calls '$proc.kill'. Will the block in 'whenever signal(SIGTERM).merge: signal(SIGINT)' ever be called? 18:07
timotimo the process that's doing the .kill will not receive a signal
dogbert17 timotimo: who will receive it then?
if any
timotimo the process you've spawned receives what you do with proc.kill 18:08
the whenever signal(...) will receive signals you send to the perl6 process, for example by pressing ctrl-c or killing it from a process manager
i'm not sure it's possible to "receive signals for another process" easily
dogbert17 aha 18:09
so the when '$proc.kill' is called, from the 'Promise in(5)' block we'll jump directly to the 'whenever $proc.start' block? 18:10
timotimo indirectly, but yes 18:16
i mean, the process can ignore SIGHUP or react to it by doing stuff other than terminate 18:18
SIGKILL on the other hand doesn't give the process a chance to react at all
dogbert17 timotimo++ I believe I get it (famous last words) 18:20
timotimo your insight could surely be translated into a helpful piece of prose in the docs? :)
dogbert17 :) 18:21
18:44 domidumont joined 18:56 brrt joined 19:02 domidumont left 20:53 brrt left 22:43 lucasb left 23:22 MasterDuke left 23:43 MasterDuke joined, sena_kun left, MasterDuke left, MasterDuke joined