[00:05] *** squashable6 left [00:05] *** squashable6 joined [00:19] *** squashable6 left [00:24] *** sena_kun left [00:24] *** 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 [06:28] \o [06:30] o/ [06:30] (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) [06:31] but the real reason is that I've started liking working with arrays much more in C, than with 'objects' [06:36] *** harrow left [06:43] https://www.microsoft.com/en-us/research/wp-content/uploads/2017/03/kedia2017mem.pdf this is fascinating stuff, I think [06:44] 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 [09:59] 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 [10:00] 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: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 [13:48] it's funny (and somewhat annoying) how they refer to a 'strongly typed language' [13:48] as if strongly typed is well-defined [13:48] I expect better from microsoft research [13:48] (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 [15:09] *** 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 [17:00] *** TimToady joined [17:13] *** brrt left [17:15] *** robertle joined [17:44] *** zakharyas left [17:59] *** domidumont left [18:04] jnthn: you around? [18:05] have a question regarding the Proc:Async example here: https://docs.perl6.org/type/Proc::Async [18:07] 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] the process that's doing the .kill will not receive a signal [18:07] timotimo: who will receive it then? [18:07] if any [18:08] 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 [18:08] i'm not sure it's possible to "receive signals for another process" easily [18:09] aha [18:10] so the when '$proc.kill' is called, from the 'Promise in(5)' block we'll jump directly to the 'whenever $proc.start' block? [18:16] indirectly, but yes [18:18] 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 [18:20] timotimo++ I believe I get it (famous last words) [18:20] your insight could surely be translated into a helpful piece of prose in the docs? :) [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 [23:43] *** sena_kun left [23:43] *** MasterDuke left [23:43] *** MasterDuke joined