Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:01 kjp joined 00:02 reportable6 left 01:05 reportable6 joined 03:33 unicodable6 left, greppable6 left, sourceable6 left, squashable6 left, coverable6 left, quotable6 left, nativecallable6 left, benchable6 left, committable6 left, notable6 left, reportable6 left, bisectable6 left, shareable6 left, linkable6 left, statisfiable6 left, releasable6 left, bloatable6 left, tellable6 left, evalable6 left, unicodable6 joined, releasable6 joined, greppable6 joined 03:34 notable6 joined 03:35 bloatable6 joined, committable6 joined 03:36 quotable6 joined, coverable6 joined, benchable6 joined 04:35 squashable6 joined, statisfiable6 joined, linkable6 joined 04:36 evalable6 joined 04:48 frost joined 05:33 bisectable6 joined 05:34 tellable6 joined 06:28 Colt left 06:34 shareable6 joined 06:36 sourceable6 joined
Nicholas good *, * 07:01
07:03 reportable6 joined 07:34 nativecallable6 joined 08:09 Geth left, Geth joined 10:01 squashable6 left, squashable6 joined 11:01 benchable6 left, evalable6 left, nativecallable6 left, reportable6 left, releasable6 left, notable6 left, coverable6 left, bloatable6 left, tellable6 left, squashable6 left, linkable6 left, statisfiable6 left, unicodable6 left, committable6 left, bisectable6 left, sourceable6 left, greppable6 left, quotable6 left, shareable6 left 11:02 benchable6 joined, nativecallable6 joined 11:03 committable6 joined, releasable6 joined, shareable6 joined, squashable6 joined, greppable6 joined 11:04 bloatable6 joined, coverable6 joined 11:30 TempIRCLogger left 11:31 TempIRCLogger joined 11:35 dogbert11 left 11:38 TempIRCLogger left, TempIRCLogger joined 11:41 Altai-man joined 11:44 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined 11:45 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left 11:47 dogbert17 joined 12:02 reportable6 joined, notable6 joined, evalable6 joined 12:03 linkable6 joined, sourceable6 joined, tellable6 joined 12:04 statisfiable6 joined, quotable6 joined, bisectable6 joined 12:07 TempIRCLogger joined 12:12 TempIRCLogger left, TempIRCLogger joined 12:16 TempIRCLogger left, TempIRCLogger joined 12:22 TempIRCLogger left, TempIRCLogger joined 12:54 squashable6 left, squashable6 joined 13:00 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left, TempIRCLogger joined 13:25 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left 13:26 TempIRCLogger joined 13:27 TempIRCLogger left, TempIRCLogger joined, TempIRCLogger left 13:28 TempIRCLogger joined 13:37 TempIRCLogger left, TempIRCLogger joined 13:44 TempIRCLogger left 13:45 TempIRCLogger joined 13:52 TempIRCLogger left, TempIRCLogger joined 13:58 TempIRCLogger left, TempIRCLogger joined 14:02 unicodable6 joined 14:11 TempIRCLogger left, TempIRCLogger joined 14:12 TempIRCLogger left, TempIRCLogger joined 14:14 frost left 14:26 Geth left, Geth joined
dogbert17 hmm, what's the difference between TempIRCLogger and RakuIRCLogger? 15:26
lizmat dogbert17: RakuIRCLogger is the "production" logger that is used for the logs.liz.nl website and the github.com/Raku/IRC-logs repo 15:34
TempIRCLogger is my test version of that
that feeds my logs test server 15:35
in any case, after this last update, we shouldn't see Geth flapping anymore after it reported a commit
dogbert17 lizmat: thx for the explanation 15:54
lizmat fwiw, I think we can now upgrade the other bots to the most recent IRC::Client, and get rid of the re-connect hack that they currently have 15:55
IRC::Client now checks for PINGs from the server, and will automatically reconnect if a PING is not received within ~ 10 seconds of its expected arrival time 15:56
expected arrival time calculated from the difference in the first two PINGs seen, and set to 5 minutes if no enough PINGs seen yet 15:57
normally, PINGs are sent every 2.5 minutes or so by Libera chat servers
vrurg jnthnwrthngtn: Lang design question: why pairs only smartmatch against their values and ignore keys? It feels so counter-intuitive. 16:17
It is especially confusing when $file ~~ :d and $file ~~ :f are different things, but :d ~~ :f is true. 16:20
16:22 squashable6 left
lizmat m: %(a => 42) ~~ %(b => 42) # hashes check both keys and values 16:24
camelia ( no output )
lizmat m: say %(a => 42) ~~ %(b => 42) # hashes check both keys and values 16:25
camelia False
lizmat and in other situations, Pairs are considered 1-element hashes... so there *is* an inconsistency indeed :-)
16:25 squashable6 joined
lizmat m: say (a => 42).keys 16:26
camelia (a)
lizmat m: say (a => 42).elems
camelia 1
lizmat m: say (a => 42).kv
camelia (a 42)
jnthnwrthngtn vrurg: See in design.raku.org/S03.html#Smart_matching
The line of note being: 16:27
Any Pair test object attribute ?."{X.key}" === ?X.value (e.g. filetests)
I think the origin was a regularized replacement for the Perl `-d $file` or some such 16:28
So `$file ~~ :d` is really like `$file.d === True`
16:29 squashable6 left
jnthnwrthngtn In the same document look for "The filetest operators are gone. We now use a Pair as a pattern that calls an object's method" 16:29
16:30 squashable6 joined
jnthnwrthngtn Ah, but maybe you're asking about Pair ~~ Pair 16:31
m: say :a ~~ :!a
camelia False
jnthnwrthngtn m: say :a ~~ :a
camelia True
jnthnwrthngtn m: say :b ~~ :a
camelia True
jnthnwrthngtn Hm, that's unexpected and I think wrong 16:32
Associative Pair test hash mapping $_{X.key} ~~ X.value
By that definition it's clearly meant to care about the key
So it's Rakudo that's wrong, the design intent was for the key to matter
m: say { a => 1, b => 2 } ~~ :a(1) 16:33
camelia True
jnthnwrthngtn m: say { a => 1, b => 2 } ~~ :a(2)
camelia False
jnthnwrthngtn It gets it right there, I note, so it really is just Pair ~~ Pair that is wrong
lizmat that's been wrong for ~ 6 years then : d8f7e8b8d6ea25b 16:38
16:39 linkable6 left
vrurg It is even specced. But, luckily, it's only a single test which fails when I tested it. So, I'll try to commit the change and see if there be Blin fallout. 16:41
But only after the upcoming release.
vrurg is afk
lizmat stops patching and will wait for vrurg 16:42
vrurg lizmat: Have you started patching the Pair?
lizmat yes
but I did a git reset --hard now :-)
vrurg Do it then. It's just +1 line to method ACCEPTS and one test in t/spec/S02-types/pair.rakudo.moar 16:43
I'm currently finalizing smartmatch PR and started with optimizations for ~~ Pair cases. Apparently, it depends on the behavior of ACCEPTS. 16:44
afk again...
lizmat github.com/rakudo/rakudo/pull/4671 # vrurg 17:08
17:58 Colt joined 18:02 reportable6 left 18:30 Altai-man left
vrurg lizmat++ 19:10
19:49 TempIRCLogger left 19:50 TempIRCLogger joined
nine Running LibXML's tests: 19:50
t/00ast.t ..................... rakudo-m: src/core/str_hash_table_funcs.h:28: MVM_str_hash_kompromat: Assertion `!(control->cur_items == 0 && control->max_items == 0)' failed.
Nicholas presuambly that's not reliably repeatable beacuse it depends on hash randomisation 19:58
nine Actually it seems to kill precompilation of LibXML-raku/lib/LibXML/Raw.rakumod quite reliably 19:59
(gdb) p retval
$1 = {pos = 33239752, serial = 0, owner = 13241355059095914077}
*control is {salt = 13241355059095914077, ht_id = 13241355059095914077, serial = 0, last_delete_at = 0, cur_items = 0, max_items = 0, official_size_log2 = 0 '\000', key_right_shift = 0 '\000', entry_size = 16 '\020', max_probe_distance = 0 '\000', max_probe_distance_limit = 0 '\000', metadata_hash_bits = 0 '\000', stale = 0 '\000'} 20:00
Nicholas OK, hangon, that looks like an empty hash 20:01
(I don't have the source yet)w
what's the backtrace? what called MVM_str_hash_kompromat?
nine gist.github.com/niner/473f15dc5b61...9fdad6a8b2 20:02
Nicholas OK, I don't know how that hasn't been hit before 20:04
and also, it's maybe 12 months since I looked at this code
The fix, I think, is that MVM_str_hash_start() 20:05
should have this:
if (MVM_UNLIKELY(!control)) {
be
if (MVM_str_hash_is_empty(tc, hashtable)) { 20:06
(not sure how many MVM_UNLIKELYs that needs...
what created that hash? 20:07
nine Match.new(#`(from Capture) @!list, %!hash, #`(from Match) $!from=0, $!pos=1, $!to=-1, $!shared=ParseShared.new(#`(from ParseShared) $!CUR_CLASS=(Match), $!orig=Str.new(#`(from Str) $!value='$!doc'), $!target='$!doc', $!highwater=0, @!highexpect, %!marks, $!fail_cursor=Match.new(#`(from Capture) @!list, %!hash, #`(from Match) $!from=0, $!pos=-3, $!to=-1, $!shared=<already seen>, $!braid=Braid.new(#`(from 20:08
Braid) $!grammar=<already seen>, $!actions=(NQPMu), $!package=<already seen>, $!slangs), $!bstack, $!cstack, $!regexsub=NQPRoutine.new(#`(from NQPRoutine) $!do=0x492f978 !cursor_init (!cursor_init/cuuid 80), $!signature, $!dispatchees, $!dispatch_cache, $!dispatch_order, $!clone_callback, $!onlystar=0), $!restart, $!made, $!match, $!name='<null>'), $!target_flipped='<null>'), $!braid=<already seen>,
$!bstack, $!cstack=<already seen>, $!regexsub=Regex.new(#`(from Code) $!do=0x79fdf80 (/cuuid 185), $!signature=Signature.new(#`(from Signature) @!params, $!returns, $!arity=0, $!count=Int.new(#`(from Int) $!value[8]=bigint), $!code=<already seen>, $!readonly=0), @!compstuff, #`(from Block) $!phasers, $!why, #`(from Routine) @!dispatchees, $!dispatcher, $!flags=0, $!inline_info, $!package=<already seen>,
@!dispatch_order, #`(from Regex) $!caps=RegexCaptures.new(#`(from RegexCaptures) @!pos-capture-counts, @!named-capture-names, @!named-capture-counts), $!nfa, %!alt_nfas, $!source='<null>', $!topic, $!slash), $!restart=<already seen>, $!made, $!match=(NQPdidMATCH), $!name='0')
This is the P6opaque that's holding that hash
Nicholas as in, what called MVM_str_hash_build()? Is it in src/6model/reprs/MVMHash.c ?
basically, IIRC (this is 12 months, and a lot has happened), the default "build" from MVMHash.c was an MVMObject which has a NULL pointer (so no hash control allocated) 20:09
whereas your *control 20:10
is an allocated control structure with nothing else
nine Since the hash is an attribute of a P6opaque, reprs/MVMHash.c seems like the safe bet
Nicholas (which is how we used to do it, then lizmat observed that there were a lot of empty hashes created, so the "NULL pointer is even smaller" optimisation happened
)
nine The suggested change fixes the issue 20:24
Nicholas good.
I don't think that it's wrong. It might not be the only way to fix the problem
but I'm wondering 20:25
1) how to write a regression test that hits the problem
2) why we didn't hit it before?
3) are there other ways to hit similar assertions?
and I'm too tired to confidently answer any of that tonight
21:03 reportable6 joined 21:05 sena_kun left 21:06 sena_kun joined 22:40 linkable6 joined
MasterDuke is there a way to know if an op is 'iffy'? e.g., `&infix:<eq>` is, but `&infix:<+>` isn't 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!