|
00:02
colomon joined
00:50
dalek joined
01:25
ilbot3 joined
01:49
FROGGS joined
02:00
woosley joined
02:25
benabik joined
06:36
FROGGS joined
07:13
brrt joined
|
|||
| brrt | hi #moarvm | 07:29 | |
| nwc10 | hi brrt | ||
| FROGGS | morning brrt | ||
| <jnthn> .tell brrt I'm on target to have the initial code available on Tuesday | 07:30 | ||
| <jnthn> bah, no message bot here | |||
| <--- le message bot | |||
| brrt | i've seen it Froggs, thanks :-) | 07:31 | |
| hi nwc10 | |||
| FROGGS | :o) | ||
| brrt | i read backlogs too ;-) | ||
| FROGGS | okay, noted | 07:32 | |
| brrt | but thanks anyway | ||
| awesome, excited | |||
| FROGGS | me too | 07:33 | |
| quite a few nice thing are happening atm | 07:34 | ||
| things* | |||
| brrt | uhuh | ||
| i'd like to help out with the whole lock-placement things,but i'm a bit strapped for time right now | |||
|
07:45
cognominal joined
08:58
woolfy1 joined
|
|||
| cognominal | FROGGS prend son pied à fait le bot. | 10:02 | |
| FROGGS | cognominal: google translates it as "takes his foot made the bot", but somehow I doubt that this is correct :o) | 10:04 | |
| cognominal | that's a indirect pun about "pied bot" | 10:05 | |
| jnthn | mmm...pie bot | 10:06 | |
| brrt | :-) | 10:07 | |
| brrt lunches | |||
| cognominal | "il prend son pied" is translated litteraly by Google but really means to "he enjoys himself" | ||
| and pied bot is fr.wikipedia.org/wiki/Pied_bot | 10:08 | ||
| btw, s/fait/faire/ on my original sentence | |||
| masak | "FROGGS enjoys himself creating the bot"? | 10:45 | |
| jnthn | playing the bot, maybe | 10:46 | |
| or being | |||
| cognominal | yup | 10:50 | |
| polysemy makes google-translate a fool all the time. | 10:51 | ||
| masak | oh, "acting the bot". | 11:03 | |
|
11:04
colomon joined
|
|||
| masak | cognominal: polysemy is probably AI-complete ;) | 11:04 | |
| cognominal | nope "playing/being" the bot is/are correct | 11:06 | |
| masak | oki | 11:07 | |
| cognominal | il y du jeu dans les langages naturels. "Jeu" meaning either game or en.wikipedia.org/wiki/Backlash_(engineering) | 11:09 | |
| masak | marvellous. | 11:12 | |
|
11:40
zakharyas joined
12:09
colomon joined
12:35
JimmyZ joined
12:44
colomon joined
13:48
btyler joined
13:59
jnap joined
14:02
btyler joined
14:13
woolfy1 left
14:37
FROGGS[mobile] joined
14:51
zakharyas joined,
FROGGS joined
15:32
brrt left
15:47
benabik joined
16:13
FROGGS_ joined
16:44
jnap1 joined
|
|||
| dalek | arVM: 26e829f | gerd++ | Configure.pl: add the both flags 'has-libuv and 'has-libatomic_ops' |
17:17 | |
| jnthn | gerd also notes, "I think there will no other flags for the Fedora build needed." | 17:18 | |
| So looks like we're in decent shape for packagers. | |||
| FROGGS | cool! | 17:30 | |
| nwc10 | that sounds like a challenge :-) | 17:31 | |
| jnthn | well, gerd++ is working on it for fedora. :) | 17:42 | |
|
18:11
colomon joined
|
|||
| timotimo | is that gerd or not_gerd? | 18:13 | |
| FROGGS | gerd | ||
| timotimo | OK | ||
| i still wonder what not_gerd is up to these days | 18:14 | ||
| FROGGS | yeah, me too | 18:15 | |
| I really hope he is well | |||
|
18:29
brrt joined
18:35
jnap joined
|
|||
| dalek | arVM: 57f735a | (Tobias Leich)++ | src/math/bigintops.c: shortcut shr when we have a small lhs but rhs is >= 32 Otherwise we will run into issues where a >> 32 == a, at least on gcc. |
18:57 | |
| arVM: 02c7ece | jnthn++ | src/io/syncstream.c: Revert "First pass at locking for syncstream." This reverts commit 1261936ddb75e91c78a91d830dad3a575d17ffe3. We'll take a safer, more general, approach. |
19:15 | ||
| arVM: eceea4c | jnthn++ | src/core/ (3 files): Add infrastructure for mutex release on exception. |
|||
| MoarVM: 81d57d5 | jnthn++ | src/io/io.c: | |||
| MoarVM: Protect all I/O operations using handle mutex. | |||
| MoarVM: | |||
| timotimo | i like the sound of that | 19:22 | |
|
19:29
lue joined
19:36
jnap joined
19:37
colomon joined
|
|||
| brrt | if i understand it correctly, the thread context is now provided with a mutex especially for when an exception is thrown | 19:43 | |
| i'm not so sure that is a good idea | |||
| it maybe better - perhaps - to write macro's to create a try/catch/finally kind of idiom | 19:44 | ||
| but i'm not so sure about that, either | |||
| jnthn | brrt: This basically *is* one. | ||
| brrt | well, what happens when you forget to 'clear' the exception mutex? | ||
| jnthn | brrt: Note the code path its on: exceptions thrown inside VM internals. Not general user-land ones. | ||
| brrt | true | 19:45 | |
| jnthn | brrt: Same as happens if you forget to unlock one. | ||
| brrt | but in that case, why not keep the unlocking local | ||
| jnthn | Because exceptions are non-local. | ||
| We lngjmp back to the interpreter. | |||
| brrt | i agree, its just - there are now two paths in which the mutex can be cleared | ||
| jnthn | In the normal non-exceptional case, we never hit this. | ||
| brrt | 'normally' and 'via the exception' | 19:46 | |
| jnthn | Right, the happy path and the sad path. | ||
| *nod* | |||
| brrt | in other words, why don't we do the 'goto exception' cleanup dance that is typicall in c-land? | ||
| jnthn | I think I'd rather not try and invent a try/catch/finally mechanism in C when we already have lngjmp going on. | ||
| brrt | true | ||
| wouldn't work anyway, with what i'm imagining | 19:47 | ||
| jnthn | Thing is that exceptions can be thrown fairly "deep" in IO stuff (such as, in the decoder). | ||
| brrt | you could make an argument that the thread itself take a list of all mutexes that are held | 19:48 | |
| threadcontext object | |||
| jnthn | Well, if we ever get to a "taking multiple" situation we can make it a stack | ||
| But I really hope not. | |||
|
19:48
colomon joined
|
|||
| jnthn | Because as soon as you're taking multiple you're asking for deadlocks. | 19:49 | |
| brrt | it depends i guess | ||
| multiple locks are common in stuff like queues | |||
| jnthn | You don't take both though. | 19:50 | |
| brrt | i'm just saying, i guess, that stuffing a single mutex into the thread context for cleanup when an exception is thrown seems like something that will be broken | ||
| .. no i agree | |||
| jnthn | I agree it's fragile, but it was the second thing after the first thing was far more fragile. | ||
| C doesn't really provide us good ways to do this. | |||
| brrt | maybe we'll come up with a better solution | ||
| no indeed | 19:51 | ||
| c++ has the compiler fix it for you, i believe | |||
| jnthn | I'm fine with that, but whatever it is should be easy to reason about. | ||
| brrt | longjmp isn't easy to reason about :-) | 19:53 | |
| (for many other things, though, i think C is the knee's bees. not for exception handling, though) | 19:54 | ||
| jnthn | Right, that's why I only want *one* longjmp'ing thing in the VM if possible :) | 19:55 | |
|
19:57
jnap joined
|
|||
| brrt | as a manner of distraction, want to see mergesort-for-linked-lists-in-scheme? | 19:57 | |
| some blogger i read said 'don't sort linked lists on a whiteboard during an interview' and i thought it'd be a nice challenge | 19:58 | ||
| jnthn | People say "don't do live demos" but I always ignore that too :P | 19:59 | |
| brrt | and rightly so | ||
| jnthn could glance it :) | |||
| brrt | github.com/bdw/lab/blob/master/sch...gesort.scm with pride :-) | ||
| the point to notice is that i only spend n time to 'divide' the list once | 20:00 | ||
|
20:01
jnap1 joined
|
|||
| brrt | in a more naive implementation i'd spend n time for each 'division' which doesn't affect asymptotic runtime but is not very efficient anyway | 20:01 | |
| jnthn | Cute :) | 20:04 | |
| brrt | thanks :-) | 20:07 | |
| jnthn glances the rosettacode one out of curiosity | |||
| brrt | i'm a closet lisp / scheme fan | ||
| d'oh, rosettacode | |||
| jnthn | I didn't do enough of those, though I went to a "Build your own lisp for great justice" talk a few months ago and started hacking a lisp compiler in NQP in it :) | 20:10 | |
| brrt | nice | 20:11 | |
| jnthn | bbi10 | 20:15 | |
|
21:09
jnap joined
22:28
colomon joined
23:45
woolfy joined
23:55
lizmat joined
23:58
jnap joined
|
|||