github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:01 sena_kun joined 00:03 Altai-man_ left 00:47 Kaiepi left 01:35 Kaiepi joined 01:48 vrurg left, vrurg joined 02:00 Altai-man_ joined 02:03 sena_kun left 03:05 lucasb left 04:02 sena_kun joined 04:04 Altai-man_ left 05:24 Kaiepi left 05:25 Kaiepi joined 06:01 Altai-man_ joined 06:03 sena_kun left 08:02 sena_kun joined 08:04 Altai-man_ left 10:01 Altai-man_ joined 10:03 sena_kun left 11:15 Kaiepi left 11:43 Kaiepi joined 12:02 sena_kun joined 12:04 Altai-man_ left 12:25 Kaiepi left, Kaiepi joined
Geth MoarVM/kosher-unicode-names-only: a34e9e4bae | (Nicholas Clark)++ | src/strings/unicode_ops.c
Don't add placeholders such as "<control>" to the Unicode names lookup hash.

Including these make no sense - the hash is for a 1->1 mapping of name to codepoint, but for each of these names we have multiple values.
The way our hashes are currently implemented (with "bind"), these duplicate keys are not ignored - we add hundreds of duplicate entries to the same ... (5 more lines)		 14:00
14:01 Altai-man_ joined 14:03 sena_kun left
Geth MoarVM: nwc10++ created pull request #1321:
Don't add placeholders such as "<control>" to the Unicode names lookup hash.		 14:05
timotimo that makes sense 14:12
but don't we call them <control-001> and such? 14:13
m: say uniname("\x03")
camelia <control-0003>
nwc10 there's (different) C code to implement that 14:17
the forwards map code point->name 14:18
timotimo ah
14:32 Geth left, Geth joined
nwc10 is worried that there is a stupid bug in that pull request 14:46
I have. 14:57
The bug is real. The fix is in the wrong place. Meaning also that it is untested. 14:58
16:02 sena_kun joined 16:04 Altai-man_ left
nwc10 jnthn: there's a stupid bug in that pull request 16:23
*And*
even fixing it in the place in the C code that I should have 16:24
is two places in the C code
is
...
what is it doing? WHat are all these span things, and FATE_*
and I think
jnthn Hm, I suspect trying to store the Unicode databsae compactly, if you mean the code I think you do :)
nwc10 actually that code is the remains of soemthing else, and if I have it right, the entire "extents" thing doesbn't matter any more - it's a linear scan of codepoint_names 16:25
jnthn: yes, it's storing the *properties* efficiently
but the names, they either "no longer need to be stored with this" or possibly "never needed to be stored with this"
so I think that the C code in generate_codepoints_by_name can be a lot simpler. 16:26
jnthn I seem to recall *something* about names changed along the way.
nwc10 :-)
jnthn This wouldn't surprise me.
nwc10 back in 2013?
16:26 zakharyas joined
nwc10 and then 16:26
I think my "revised fix" is wrong - it manages to get the code that ignores '<' into the correct place
in the C
but the correct place to ignore '<' is in ucd2c.pl 16:27
and never even put it into the C array
and I also really don't get why U-0081 is NULL in that array 16:28
Geth MoarVM/kosher-unicode-names-only: 09dfa207e1 | (Nicholas Clark)++ | 2 files
Don't add placeholders such as "<control>" to the Unicode names lookup hash.

Including these make no sense - the hash is for a 1->1 mapping of name to codepoint, but for each of these names we have multiple values.
The way our hashes are currently implemented (with "bind"), these duplicate keys are not ignored - we add hundreds of duplicate entries to the same ... (5 more lines)		 16:33
timotimo m: say uniparse(uniname("\x02")).raku 18:00
camelia "\x[2]"
18:01 Altai-man_ joined, zakharyas left 18:03 sena_kun left
Geth MoarVM: 67c8413f5b | (Nicholas Clark)++ | tools/ucd2c.pl
ucd2c.pl shells out to rakudo, without checking that it ran correctly.

The error message gets lost in its garrulous output.		 18:37
nwc10 well, that was part of my problem.
OK, with that, Unicode UCD 12.1, Emoji 12 (ie 12.0, not 12.1) I can *almost* rebuild files byte-for-byte perfectly 18:39
but src/strings/unicode_db.c differs for uni_seq_722 to uni_seq_733
was Emoji_Combining_Sequence
now Emoji_Keycap_Sequence 18:40
and this makes little sense, as those things seem to be the same all the back to emoji-5.0
jnthn: yes, it's that code related to $usually 18:56
timotimo dispatch chains haven't been in any of jn's talks, right? 19:09
dogbert17 there's some strange code in src/strings/unicode_db.c 19:22
what's happening here for example: 19:23
75055 if (block) {
75056 return block ? Block_enums[num+1] : Block_enums[0];
75057 }
20:02 sena_kun joined 20:04 Altai-man_ left 20:14 zakharyas joined 20:19 zakharyas1 joined, zakharyas left
Geth MoarVM: cfe6ed8f56 | (Nicholas Clark)++ | 3 files
Consistent whitespace for the initialiser for codepoint_bitfield_indexes

Previously the code would vary the amount of whitespace in the comment depending upon whether the code point happened to have a name. This means that unrelated changes would cause this initialiser to dance, creating collateral damage in the git diffs.
... (8 more lines)		 20:52
21:29 hoelzro left, hoelzro joined 21:30 zakharyas1 left
timotimo jnthn: what do i have to get right to make the guards from the dispatch program deopt correctly? do i copy the "deopt one" annotation? i think that may be what i've had before; a synthetic deopt point only has to be made if there wasn't already a deopt point available for some reason? 21:39
22:01 Altai-man_ joined 22:04 sena_kun left 22:10 lucasb joined
timotimo has there been much exploration of how dispatch chains are like trace jitting, and what that means for systems including them? 22:21
jnthn Well, if we mean tracing the meta level, then yes, both imply something in the whole multi-level language or bind time analysis space 22:50
It's just that we don't really try to trace them, we just make explicit the operations that should end up in the dispatch program
Or seen another way, only the set of dispatch transform/guard related syscalls are traced 22:51
It's certainly no accident that I called that phase "record". :)
timotimo ah, yeah, meta-level tracing, not machine code instructions tracing; is that the correct difference? 22:52
jnthn Well, sorta...I mean, the meta-level tracing, so far as I understand how the terminology is used, is about knowing which things are the interpreter and which things are the program. 22:53
e.g. the program counter is not interesting to trace the increments of 22:54
If you don't have a meta level and are only tracing the executing bytecode then you don't care about this.
For dispatch programs, I figure all the language level and MOP knowledge is meta 22:55
timotimo OK 23:01
just need to get the deopt of the generated guards correct 23:02
23:03 evalable6 left
jnthn About the deopt question, though: I think you'll probably need synthetic deopt points; I think spesh plugins had the same situation, so I'd see how it was solved there. 23:03
timotimo i stole the functions it used i think :D
insert_arg_type_guard 23:04
23:04 committable6 left
timotimo MVM_spesh_plugin_rewrite_resolve is probably the right place to steal from 23:05
23:06 committable6 joined
timotimo that code can steal from the prepargs instruction that sits in front of the spesh plugin invoke 23:06
steal the deopt annotations, that is 23:07
jnthn I think dispatch probably needs to be both a pre and post deopt point 23:10
timotimo ah i can do that, it only needs an extra flag in the oplist? 23:11
jnthn Think so 23:14
I think it needs to be all pre/post/all
pre for guards ahead of it
post for return type guard 23:15
all for global deopt
timotimo not sure what "return type guard" means in this case 23:16
jnthn As with invoke: we log and can guard on the return type of a call, and dispatch is (often) a way of making a call 23:17
timotimo ah, ok, so there'll also want to be a guard for that that will come from the spesh log, not from the dispatch program or record 23:18
jnthn Yes 23:20
iirc that's set as part of the return instruction
Well, logged as part of...
timotimo via "is_caller_logging" right?
less via, more "involving"
23:24 evalable6 joined
jnthn yes 23:27
23:37 AlexDaniel 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!