|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:45
vrurg_ joined
00:48
vrurg_ left,
vrurg left
00:49
vrurg joined
00:50
vrurg_ joined,
lucasb left
00:53
vrurg__ joined
00:54
vrurg left,
Altai-man_ joined
00:56
vrurg_ left,
sena_kun left
01:01
vrurg joined
01:04
vrurg__ left
01:07
MasterDuke left
02:55
sena_kun joined
02:56
Altai-man_ left
04:54
Altai-man_ joined
04:57
sena_kun left
06:46
leont joined
06:55
sena_kun joined
06:57
Altai-man_ left
07:55
zakharyas joined
08:54
Altai-man_ joined
08:56
sena_kun left
09:10
AlexDaniel left
|
|||
| nwc10 | good *, #moarvm | 09:28 | |
| lizmat | nwc10 o/ | 09:30 | |
| nwc10 | \o | 09:31 | |
| jnthn | o/ | 09:36 | |
| nwc10 | jnthn: in MVM_HASH_BIND_FREE and friends, there is a check for !MVM_is_null(...) && REPR(key)->ID == MVM_REPR_ID_MVMString && IS_CONCRETE(...) | 09:37 | |
| whereas MVM_string_check_arg is !s || !IS_CONCRETE(s) | 09:38 | ||
| this seems pretty close. Would the code in src/strings/ops.c actually "Work" if passed anything that isn't *exactly* a MVM_REPR_ID_MVMString? | |||
| or, alternatively, is the hash code being a bit too over protective? (I can see that it does cheat and introspect the string itself to get the hash value direct frmo the struct) | 09:39 | ||
| it sort of feels like the two are the same test | 09:40 | ||
| are we violating DRY? | |||
| (I had a dry day yesterday. The poor beer fridge must be feeling lonely) | |||
| jnthn | MVM_is_null(...) checks it's not tc->instance->VMNull | 09:43 | |
| It really depends on if you know the thing is an MVMString * or if it at least came form an `s` register | |||
| nwc10 | OK, so the hash one is doing more work (because it needs to deal with more potential mess) | ||
| jnthn | If so, then you needn't check for it being VMNull | ||
| nwc10 | ah OK | 09:44 | |
| jnthn | Well, in theory, yes, we wanted to support other kinds of keys | ||
| nwc10 | but not "this week"? | ||
| jnthn | Not for me ;) | 09:45 | |
| nwc10 | nor me. Even though this week had 5 days. | ||
| (as does next week, and all the weeks until October...) | 09:46 | ||
| jnthn | Hmm, I'm sure I've a 4-day one sometime before then | ||
| Well, next week I've got a 3.5 day one because I'm taking a long weekend trip :) | |||
| nwc10 | August 15th is a Sunday (at a guess about what might be a common holiday) | 09:47 | |
| woohoo! Going anywhere exciting? Or staying in the country | |||
| jnthn | Are you implying .cz is not exciting? :P | 09:49 | |
| nwc10 | mmm, yes, well, possibly, "exciting" might be a bit of a risk of "may you live in interesting times" | ||
| apparently hotels near lakes in Austria are now generally completly booked out for July and August. Folks are deciding that a holiday "at home" is safer. | 09:50 | ||
| jnthn | Yeah, we decided to just go about an hour away by train, and were surprised to find the town we picked also has heavily booked up | ||
| *was | 09:51 | ||
| Useful to know about Austria being busy, though. We've still got a (cancellable) booking for Switzerland in late July | 09:56 | ||
| And don't know if the night trains will be running again, and it's a long haul on the day train, so we'd probably break the trip somewhere in Austria. Though maybe if we should avoid anywhere with a lake... :P | |||
| nwc10 | we're not on the way, else you could stay here. | 10:06 | |
| jnthn | You could be on the way, in so far as the Wien -> Linz bit is quite short, and Praha -> Wien is not that different in time from Praha -> Linz (and a nicer train) | 10:11 | |
| nine | Doesn't REPR(key)->ID == MVM_REPR_ID_MVMString make sure the key is not VMNull? After all VMNull has the MVMNull REPR | 10:21 | |
| nwc10 | I'm glad someone is awake. :-) | ||
| I think that you're right. | |||
| jnthn | nine: This is true, yes. The only legal thing in an s register is an MVMString pointer or a NULL | 10:23 | |
| So in many places a REPR check may be a waste too | |||
| Or at least could drop to being an assert | |||
| nwc10 | OK, the implications of what cleanup is now safe, given these insights | 10:24 | |
| is now a bit too much for me to act upon it | |||
| nine | FWIW I often feel that we use MVM_exception_throw_adhoc too much and should use assert or MVM_panic instead. They are often in places where the exception really means that something went wrong majorly in the compiler or runtime and catching them would hide a serious issue in the best case | 10:25 | |
| nwc10 | yes. The limited knowledge I have is that there are a whole bunch in the bytecode loading that can't be that useful, as they fire off when a mutex is held. | 10:27 | |
| jnthn | nine: Don't forget MVM_oops, which is panic-y in that it terminates things, but doens't assume we're in such a mess that producing a stack trace of where we are is likely to in turn SEGV | 10:33 | |
| In general, panic is good for "our internal state is corrupt, we can't trust anything" and oops for "something that should be impossible happened, but the fallout is probably quite contained" | 10:34 | ||
| nine | Ah, then yes, MVM_oops should get much more of the fame :) | 10:36 | |
|
10:55
sena_kun joined
10:57
Altai-man_ left
11:23
zakharyas left
12:54
Altai-man_ joined
12:57
sena_kun left
14:55
sena_kun joined
14:57
Altai-man_ left
15:00
zakharyas joined
15:35
AlexDaniel` left
16:54
Altai-man_ joined
16:56
sena_kun left
16:59
ChanServ left
17:10
AlexDaniel` joined
17:36
ChanServ joined,
cherryh.freenode.net sets mode: +o ChanServ
18:55
sena_kun joined
18:56
Altai-man_ left
19:31
zakharyas left
19:33
MasterDuke joined
20:11
zakharyas joined
20:54
Altai-man_ joined
20:57
sena_kun left
21:52
zakharyas left
22:55
sena_kun joined
22:57
Altai-man_ left
|
|||