github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:51 frost-lab joined 02:16 lucasb left 07:08 sena_kun joined 07:27 zakharyas joined
jnthn o/ 09:17
nwc10 \o 09:23
nine Is there a quick hack to make sort_plan a stable sort? 09:28
lizmat modules.raku.org/dist/Array::Sorted::Util ? :-) 09:30
seriously, it would be nice if there would be a finds_s/i/n nqp op
jnthn nine: If you need a secondary property to sort equal things on, then I think the static frame is in reach, and thus the cuid, although those aren't really globally unique. 09:32
But I think if bytecode production is stable, they will be too 09:33
MasterDuke where would you use a finds_s/i/n?
jnthn Probably good enough as a "quick hack"
If not then take some property of the cuid too 09:34
*of the CU
lizmat: What would the op do?
lizmat in the case of native int, would take a native int array and an int value, and tell you where it is in the list if it can be found 09:35
jnthn I guess this is the "make the sort stable by never having two things be really equal" appraoch :)
lizmat no
in the implementation of that finds sub in the module
jnthn I was talking about what I just suggested to nine++, not about your op suggestion :)
lizmat ah, ok 09:36
and if it cannot be found, tell you where it should be inserted
jnthn Oh, it's assuming the data is sorted? 09:37
lizmat the module also allows you to specify associated lists, so you can insert a "key" in one list, and a "value" in the other
jnthn I'm not sure that's worth an op
I was going to say that a find_i and find_n might be worth it because there are better ways than a loop to scan a bunch of things packed inot memory
*into 09:38
lizmat perhaps not... at the moment an object hash implementation using this module, is still about 5x as slow as the current object hash
jnthn With _s it's already not going to do much better because a string array has the LoI in the way
(Much better than a loop at the bytecode level, I mean) 09:39
lizmat yeah, I understand
anyways... the 5x slower is for a Str, with a very cheap .WHICH
otoh, if your cmp on the object depends on .WHICH, it's going to be slower still 09:40
anyways, I wanted to explore that way of implementing hashes, to see if it would make sense, from performance, or from memory use point of view 09:41
but yeah, having a find_i/n op would be nice :-) 10:13
10:47 zakharyas left 10:48 zakharyas joined 10:55 zakharyas left
MasterDuke timotimo: the coverage_log op is not defined in nqp. is it used by the debug server, or was that functionality just never fleshed out? 11:16
timotimo you can't create one of these yourself, they are put into bytecode by an instrumentation thingie if the MVM_COVERAGE_LOG env var is set 11:17
MasterDuke ah, ok
leont That moment you accidentally write moar instead of more in non-Raku context -_- 12:22
MasterDuke our azure CI pipelines currently use ubuntu 18.04. they have ubuntu 20.04 available (and 16.04). would it makes sense to switch our current pipelines to 20.04 and add one or two 18.04 and 16.04 (e.g., one gcc and one clang of each)? 12:32
12:39 zakharyas joined
jnthn MasterDuke: Sounds reasonable to me 12:54
MasterDuke k, will PR that in a bit 12:55
Geth MoarVM: MasterDuke17++ created pull request #1475:
Update Azure CI linux versions + add old versions		 13:14
14:02 frost-lab left 14:15 Kaiepi left, Kaiepi joined 14:38 Kaiepi left, Kaiepi joined 14:43 Kaiepi left 14:44 Kaiepi joined 17:59 zakharyas left, sena_kun left 18:00 sena_kun joined 19:13 MasterDuke left 19:50 lucasb joined 20:15 MasterDuke joined 20:31 MasterDuke left 20:32 MasterDuke joined 21:05 Ven_de_Thiel joined 21:43 Ven_de_Thiel left 21:54 dogbert11 joined 21:58 dogbert17 left 22:02 dogbert17 joined 22:07 dogbert11 left 22:34 dogbert11 joined 22:37 dogbert17 left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!