| IRC logs at
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, 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