|
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
|
|||