Geth | MoarVM/master: 7 commits pushed by (Timo Paulssen)++ | 00:04 | |
timotimo | next up: stuff to explore frames with? | 00:33 | |
i don't think i want to write bytecode-dumping in python | 00:34 | ||
good thing we already have that for --dump | |||
let's see if i can hook that up somehow | 00:36 | ||
MasterDuke | timotimo: is this script loaded automatically if you use perl6-gdb? | 00:43 | |
timotimo | yes, but multiple caveats | 00:44 | |
1) you have to copy or link it into the same folder as the "moar" binary | |||
2) you have to whitelist it | |||
i think that's all | |||
MasterDuke | how do you whitelist it? | ||
timotimo | gdb tells you how to do it | 00:45 | |
add-auto-load-safe-path /home/timo/perl6/moarvm/tools/moar-gdb.py | |||
add-auto-load-safe-path /home/timo/perl6/install/bin/moar-gdb.py | |||
this goes into ~/.gdbinit | |||
in theory we can put the python script into the binary with a piece of linker script or something | 00:46 | ||
i don't want to bother factoring out the stuff in bytecodedump so i can call it for individual frames | 00:50 | ||
maybe later | |||
what else ... | |||
cat on lap | 00:52 | ||
cannot continue working | |||
okay, cat released me | 01:02 | ||
i guess moar-gdb could teach gdb how to find fields in a P6opaque | 01:03 | ||
and others | |||
like CStruct and CPPStruct | |||
MasterDuke | bigints? | 01:05 | |
timotimo | good point | 01:06 | |
Geth | MoarVM: 1870340d84 | (Timo Paulssen)++ | tools/moar-gdb.py todo entries for pretty printing some of our REPRs |
01:11 | |
timotimo | i don't see a way to provide a display hint of "no hint" | 01:42 | |
though mabe i can invent a value for "no hint" and just shrug it off | 01:44 | ||
MasterDuke | what are display hints? | 01:50 | |
timotimo | sourceware.org/gdb/onlinedocs/gdb/...g-API.html | ||
for some reason recompiling my moar made rakudo instacrash when starting | 02:21 | ||
i just turned debugging down :\ | |||
i've made a bit of progress with an mvmobject pretty printer | 02:33 | ||
MasterDuke | nice. i've made a bit of progress fixing int-uint tests, getting the fudging correct for both moar and jvm was annoying | 02:34 | |
timotimo | pointer to None (IterationBuffer) of repr VMArray<error reading variable: Cannot access memory at address 0x18> | 02:35 | |
doesn't that sound like a whole lot of fun? | |||
MasterDuke | address 0x18? not much lower to go | 02:36 | |
timotimo | clearly an offset from a null pointer :\ | ||
i'll go to bed now, continue this tomorrow | 02:39 | ||
MasterDuke | later... | ||
timotimo | laters! | 02:40 | |
goo dluck with the tests :) | |||
MasterDuke | thanks, think they're done, just created PR so some more eyes look them over | 02:46 | |
02:48
ilbot3 joined
04:13
brrt joined
04:16
vendethiel joined
04:59
vendethiel joined
06:19
stmuk_ joined
06:52
domidumont joined
07:38
brrt joined
07:42
lizmat joined
|
|||
brrt | good * #moarvm | 07:52 | |
so. | |||
I was wrong about a rather central assumption, haha | |||
but | 07:53 | ||
the good bit is | |||
it's really simple to change | |||
butā¦. i recently talked about having ARGLIST and CALL as sepeate or joined tiles | 07:58 | ||
so now it turns out they've already been joined | |||
question is, do i want to keep it that way | |||
hmmm | 08:24 | ||
no | |||
i do want to distinguish between refs to ARGLIST and refs to CALL | |||
08:30
zakharyas joined
08:44
brrt joined
|
|||
jnthn | moarning o/ | 09:50 | |
dogbert17_ | o/ | 09:52 | |
dogbert17_ debugging an ENOCOFFEE problem | |||
brrt | moarning jnthn, dogbert17_ | 09:53 | |
dogbert17_ | o/ brrt | ||
10:02
brrt joined
|
|||
dogbert17_ | so what's on the agenda today, SEGV's, memory leaks or CONC? | 10:05 | |
brrt | CALL/ARGLIST worries | 10:06 | |
jnthn | Having got spectest6 now running reliably, I'm breaking off the SEGV/leak fixing for a bit and giving some attention, at long last, to the plight of .hyper and .race | 10:09 | |
dogbert17_ | are they totally broken or only partially so? | 10:11 | |
jnthn | Pretty broken | 10:12 | |
Essentially, my prototype to figure out API made it into Rakudo proper :) | 10:13 | ||
nwc10 | when is the Rakudo release? | ||
jnthn | Saturday | 10:17 | |
nwc10 | excellent | 10:19 | |
and then Dogfood? :-) | |||
jnthn | Make spectest6 the default? Can certainly look in to that | 10:21 | |
nwc10 | I think that that would be cool, but after the release | 10:24 | |
jnthn | Yup | ||
I should try it on Windows before that too, to be sure it's OK there | 10:25 | ||
In theory it'll be faster than spectest5 there :) | |||
nine | timotimo: in Python you have to str(foo) all the time... | 10:26 | |
yoleaux2 | 14 Mar 2017 14:41Z <IOninja> nine: does 6.c-errata need any updates for require? t/spec/S11-modules/require.t is failing | ||
15 Mar 2017 12:00Z <brrt> nine: if he had any plans on going to polyconf | |||
15 Mar 2017 12:32Z <IOninja> nine: all the comments in this file say "return blah *type object* if none..." but all the codes return Nil. Is the code wrong or are the comments wrong? github.com/rakudo/rakudo/blob/nom/.../Handle.pm | |||
15 Mar 2017 14:10Z <IOninja> nine: never mind. ugexe++ found the answer in github.com/rakudo/rakudo/commit/ā8...1d673ae5a4 and I updated the comments | |||
IOninja | hah | ||
nine | woah | ||
IOninja | nevermind mine, it's no longer relevant | ||
nwc10 | jnthn: yes, as long as you have >1 core :-) | ||
jnthn | 4 real, 8 virtual | ||
IOninja | FWIW, spectest6 was slower on my 24-core VM. AND it still has the issue that its test count is off from stectest5, so I'd be cautious with making it the default just yet. | ||
nine has at a 17 hour workday yesterday and is not entriely recovered yet | 10:27 | ||
jnthn | o.O | ||
Ouch | |||
IOninja: Slower on Linux isn't entirely surprising | |||
IOninja | nine: oh wait, one of mine is still relevant. There are 6.c-errata failures in t/spec/S11-modules/require.t | ||
jnthn: but supposed to be faster on Windows? | 10:28 | ||
nine | IOninja: yeah, I need to look at those | ||
jnthn | IOninja: It's liable to be faster on Windows because spectest5 sets off tests in batches of TEST_JOBS, waits for those to complete, and then sets off the next batch, so if there's a slow test anywhere then it blocks progress on everything | ||
IOninja | Ah | 10:29 | |
10:46
geekosaur joined
|
|||
samcv | jnthn, but it only does that on windows? it's different on linux? | 10:58 | |
timotimo | yeah, it's different | ||
also good morn' | 10:59 | ||
i think i want to build a "mvmbreak" command for moar-gdb.py; you'd "mvmbreak push_o" and it'd create a breakpoint inside interp.c at the right place | |||
samcv | that seems silly. there must be a reason i guess | ||
timotimo | hm. google also accepts "microsoft" when you search for "windows" | 11:02 | |
jnthn | samcv: I think it's because it's hard, without having real async support, to do better on Windows | 11:04 | |
11:20
brrt joined
11:32
geekosaur joined
11:35
geekosaur joined
|
|||
nwc10 | reason - MS failed to implement socketpair() the way Berkley did | 12:05 | |
or more, close | 12:06 | ||
er, implicit close | |||
implicit close at process exit (on any other platform I think) will cause pending socket data not yet sent to be sent | |||
Win32 drops it on the floor | 12:07 | ||
this behaviour is not orthogonal. | |||
this behaviour is not the way the de-facto spec (BSD) did it | |||
this behaviour is very annoying | |||
timotimo | yoloooooo~ | 12:08 | |
nwc10 | oh, and on Win32 perl *can* use select on sockets (and hence the product of socketpair) | ||
but not on the IPC mechanism (pipes, I think) that doesn't have this "drop it on the floor" feature. | |||
geekosaur | welcome to the utter hack that is winsock | 12:09 | |
BSD sockets are kernel space | |||
nwc10 | aha, I can see where this is going | ||
and I didn't this | |||
but it explains a lot | |||
geekosaur | winsock is user space, the windows process termination functions do not in general permit a process to block termination or perform cleanup | ||
nwc10 | didn't $verb this where $verb was roughly "Realise" | ||
aha. yes | 12:10 | ||
because on *nix (and I think VMS, MVS, and therefore onwards RISC OS, AmigaOS ...) | |||
the sockets are in the kernel | |||
geekosaur | yep | ||
nwc10 | so the user process exits | ||
geekosaur | Windows had to be different :/ | ||
nwc10 | and the kernel "deals" with it | ||
(sure, your data might never actually arrive - you quit, your fault you don't get to see any error message) | |||
geekosaur | heck, until NT4.0 killing a process could cause it to permanently leak memory | 12:11 | |
(that's right, the kernel did not automatically clean up process memory, the process had to clean up itself --- and this again failed if forcibly terminated...) | |||
ilmari | wut | 12:12 | |
timotimo | huh, that's ... interesting | 12:13 | |
we have to make sure moar on pre-nt4 will --full-cleanup by default! | 12:14 | ||
geekosaur | that was understandable in old-style windows. NT3.1 and 3.5? waaaat? | ||
(not that anyone cares about those any more. I dearly hope at least. I have heard there's still some win2000 deployed in various places, but that was at least mostly sane....) | 12:15 | ||
ilmari | perl5 supports win2k and later | 12:16 | |
timotimo | i was quite amused recently when i read about the "three_finger_flag" | ||
"If you are running under DOS this is the three finger salute, ctrl+alt+del. Most multitasking OS's will trap this combination before it reaches the Allegro handler, in which case you can use the alternative ctrl+alt+end." | 12:17 | ||
dogbert17_ | also note that harness6 is broken (leaks sockets) if you run it with TEST_JOBS=1 (the default) | 12:29 | |
m: say [+] (1..100).race # RT #130576 | 12:31 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130576 | ||
camelia | 0 | ||
dogbert17_ | m: say [+] (1..100) | 12:32 | |
camelia | 5050 | ||
geekosaur | mm, actually i think the NT situation was a bit more complex. like you could register a cleanup handler, but if TerminateProcess got invoked while in the cleanup handler, cleanup aborted and that was what leaked | ||
and some ways of terminating a process didn't let the cleanup handler run before NT4 | |||
nwc10 | and the poor machine would eventually die from memory starvationg? ... | 12:34 | |
gah, bad fingers | |||
anyway, | |||
nwc10 reboots ilmari to prevent starvation | |||
ilmari | nwc10: typo of the day: perldoc -> perldog. clearly a sign I should go to brewdog for lunch | ||
nwc10 | :-) | ||
ilmari | they unfortunately don't have my favourite burger, the melted ego, any more :( | 12:35 | |
but they have a new one I want to try | |||
15:58
MasterDuke_ joined
|
|||
MasterDuke_ | jnthn: not to distract from hyper/race, but have you had a chance to look at github.com/MoarVM/MoarVM/pull/551 ? | 16:03 | |
yoleaux2 | 3 Mar 2017 15:29Z <brrt> MasterDuke_: it's a one day job | ||
[Coke] misread that as a "day one job" | |||
MasterDuke_ | heh. and i need to go back to the logs to see what the question was | 16:04 | |
timotimo | the good thing about GC is that the more objects are already dead when we GC, the faster it is | 16:05 | |
MasterDuke_ | ah right, about getting his JIT bisect tool to work with the current JIT | 16:07 | |
timotimo | oh? | ||
MasterDuke_ | i asked it was a 5min or 5day job | 16:08 | |
this was when we were still trying to figure out that div_i bug | |||
timotimo | it really depends on what we want to achieve with it | 16:09 | |
jnthn | MasterDuke_: Yeah, it looked better. I need to look more closely again though. Also I'm a bit worried about merging it before the weekend release, just in case it has any unintended consequences. | ||
timotimo | if we're fine with per-frame granularity, it'd be possible in like 30 minutes | ||
if we want per-instruction granularity ... good luck! | |||
MasterDuke_ | jnthn: cool, just wanted to make sure it didn't slip through the cracks | 16:12 | |
jnthn, timotimo: while on the subject of reviewing things. i think github.com/perl6/roast/pull/254 makes the (int|uint)(8|16|32|64) tests better (and i think i have a fix for one or two of the todos in the works), but a second opinion would be appreciated | 16:14 | ||
timotimo | jnthn: do you think it'd be cleverer to write some code for "we don't use a normalizer at all" or to write "a normalizer that does nothing"? | 16:37 | |
i'm in a bit over my head, it feels like | 16:42 | ||
jnthn | Probably the "normalizer that does nothing" will require a lot less special cases :) | 16:43 | |
timotimo | thought so, too | 16:45 | |
is decoderconfigure the right place to put the choice of normalization form? | |||
jnthn | Uh...hmm | 16:47 | |
Where are you doing to use it? | |||
Thing is, at the moment Uni is a VMArray | |||
timotimo | i wasn't finding ops i could use to go from blob to vmarray | 16:48 | |
decodetocodes and encodefromcodes are marked NYI | 16:49 | ||
jnthn | ah, right | ||
timotimo | maybe that's where i should be looking instead for the null normalization bit? | ||
jnthn | yeah, those want to be I'd :) | ||
timotimo | "IRN" :) | ||
jnthn | Yeah, though the decoders still want a normalizer iirc | ||
timotimo | OK | ||
we already have ops to go from a decoder ot a vmarray? | |||
for decodestreams i mean | 16:50 | ||
"decodertakebytes"? | |||
jnthn | Yeah, but that's just going to give you back bytes | 16:51 | |
timotimo | huh? bytes from the input buffer? | 16:52 | |
jnthn | I think the big question we really need to figure out is whether MVMString wants to be able to support codepoint level things | ||
timotimo | because after that there are no "bytes" any more :P | ||
jnthn | Yes, it's there to support mixed-mode text/byte I/O when we re-work IO::Handle to use the Decoder REPR | ||
timotimo | oh | ||
allowing MVMString to do stuff that's not it NFG sounds like a "too many things on the same peg" situation | 16:53 | ||
i.e. every string op would start off with "okay do we have to emulate grapheme semantics ourselves now?" | |||
except if they already work with a grapheme iterator | |||
hm. we probably already have a grapheme iterator path for almost all ops because of ropes | 16:54 | ||
jnthn | Yeah, we need to try and make sure we can lift out those kinds of checks | ||
At specialization time | |||
(the level ones) | |||
I've been pondering how we're ever going to get the regex engine to accept Uni for example | 16:55 | ||
And...if it's a VMArray that's gonna be a small nightmare | |||
timotimo | oh, yeah, that's true | 16:58 | |
oh, if the string itself has to be normalized from the start, we won't be able to match subsections of a regex in a different normalization mode? | |||
or do we re-normalize the whole haystack and move to the right offset with an iterator? | 16:59 | ||
jnthn | All of these questions are why we kicked the Uni can down the road some ;-) | 17:00 | |
timotimo | i can imagine :| | ||
jnthn | I think various operations are going to have to be OK with needle and haystack being NFG when the needle is Uni or NFC or whatever though | ||
There's stuff in S05 for saying what level you want to work at | 17:01 | ||
timotimo | mhm | ||
jnthn | so (example) /:nfd \c[COMBINING ACUTE]/ | 17:02 | |
timotimo | okay so a possible way forward from here is: i implement a do-nothing-normalizer, it'll turn the Decoder into a mode where instead of Str it'll create Uni objects | ||
jnthn | We can try a path like that for now, yeah | ||
timotimo | and once we figure out if MVMString gets a non-nfg mode-of-operation, we'll be able to implement :norm(NF-anything-but-G) to create Str, too | ||
jnthn | I suspect we'll need to experiment a bit before we hit upon the right design | ||
Well, it won't create Str | 17:03 | ||
It's rather than Uni will become something with repr VMString or some such | |||
Or a wrapper around one like Str is | |||
timotimo | oh | ||
jnthn | But I think I'd like to then encode the level at REPR-data level | 17:04 | |
So we can spesh on it | |||
timotimo | right | ||
jnthn | Well, normalization more than level | ||
So yeah, if we want to really Do This Right then that might be a logical first step | |||
timotimo | what would you consider a sane enum value for NULL normalization? | ||
0 is already NFD | 17:05 | ||
(because of the bitmask-backed design) | |||
jnthn | Hm, we can always shift them right one or something | 17:06 | |
timotimo | so 1 would be null normalization and it'd mask all other bits in comparisons and all others would have a 0 LSB? | 17:08 | |
jnthn | #define MVM_NORMALIZE_COMPAT_DECOMP(form) (form & 1) | 17:09 | |
#define MVM_NORMALIZE_COMPOSE(form) (form & 2) | |||
#define MVM_NORMALIZE_GRAPHEME(form) (form & 4) | |||
So those would become 2, 4, 8 | |||
And then the LSB can be a normalize bit | |||
So NFG would be 8 + 4 + 1 | |||
timotimo | ah, so more like only normalize if LSB is set | 17:10 | |
jnthn | Yeah | ||
Righty, I should go rest a bit then make kebabs :) | 17:13 | ||
timotimo | mhhh kebabs | 17:14 | |
17:15
domidumont joined
17:20
domidumont joined
17:27
zakharyas joined
17:30
domidumont joined
17:31
lizmat joined
|
|||
timotimo | so, MVM_string_decodestream_create isn't public API, right? because it's not MVM_PUBLIC? so it'll be fine to put a normalization number parameter in | 18:00 | |
how come we don't have an "outside-world normalization form code" for NFG? | 18:03 | ||
NFC, NFD, NFKC, and NFKD in that order. i'll put NULL at the front (where it can have 0) | |||
i wonder what the NYI "encodenorm" op will do | 18:05 | ||
19:03
agentzh joined
21:40
ggoebel joined
|
|||
samcv | oh so we're coming up with more normalization things. fun! | 21:49 | |
21:56
MasterDuke joined
|
|||
jnthn | samcv: Well, mostly figuring out how we can properly support codepoint-level strings | 22:13 | |
(Uni and the various subclasses) | |||
For those with use-cases taht need 'em | |||
22:18
TimToady joined
|
|||
Geth | MoarVM/null-normalization: 922d709f3c | (Timo Paulssen)++ | 11 files WIP on adding a normalization that does nothing |
22:57 | |
timotimo | samcv: are you interested in picking up my WIP? i have no previous experience inside the whole encoding/decoding business | ||
MasterDuke | heh. like the red queen, so much work to do nothing | 23:00 | |
timotimo | in what card game is the red queen supposed to do nothing? :P | ||
MasterDuke | off with your head! | 23:01 | |
23:54
Geth joined
|