00:08 colomon joined 00:16 tokuhirom joined 01:00 tokuhirom_h joined 03:22 tokuhirom joined
nwc10 good *, #moarvm 07:44
07:56 colomon joined 08:09 kjs_ joined 08:35 zakharyas joined
timotimo nwc10: i only looked at the very newest commit in there, so i didn't notice all the other savings 09:28
nwc10: do you have a before-everything vs now comparison for that branch? of the core setting, i mean
retupmoca: that's a known jitbug ;(
it's about miscompiling statements that start with "return" and have named parameters somewhere in them 09:29
nwc10 about 11M down to 10.5M 09:30
timotimo and ... damn, gitlab is slow right now :o
oh, that's not bad
it seems like you've gone through the whole serialization systematically, so i assume no more easy savings are to be had? 09:31
nwc10 There's one thing I asked jnthn about privately
and the frame section might have some win still to have 09:32
and serialisation contexts are still a big proportion of what's written
but, basically, nothing easy I can spot
timotimo "serialization contexts"?
nwc10 SC id, and SC index 09:33
timotimo ah
yeah, i'd like our SC ids to not contain a complete timestamp
or perhaps we could just encode the timestamp as hexadecimal instead of decimal and get a little win from that
cuuids, i mean
... or why not refer to the SC ids by index into a SC id table or the string heap ... 09:34
i see here that making string references half as big if they fit into the packed loc area makes the core setting 0.5 MB smaller already; does that mean all the other commits make almost no difference to the core setting? 09:37
nwc10 in which case, my numbers might be out - I thought I was comparing completely before with completely after 10:04
timotimo perhaps
nwc10 I can't think *too* hard on this - we have a current hard problem to solve (or bodge round) at work
timotimo understood
nwc10 I *thought* that it >100K from the stable changes 10:05
timotimo did you find any indication of the lazy deserialization logic not being used currently? or was everything all right before your work started?
nwc10 I can't answer either question usefully. 10:16
I know that the lazy logic is being used at times
timotimo right, fair enough :)
nwc10 and that if I mess things up, it's used less than before
I can't tell you if it's used everywhere it should be 10:17
timotimo we don't have any tool or metric to figure out if things are all right, then?
nwc10 none that I'm aware of
timotimo maybe i'll think about that at some point; not in the right headspace at the moment 10:19
jnthn nwc10: ooh, that "don't store things with \r in as Latin-1, but UTF-8" is a lovely solution :) 10:35
nwc10 jnthn: good. it's sort of a hack, but probably a "hack" in the good sense 10:41
it avoids any more flags or runtime complexity 10:43
("compile time" is not "run time" in my head)
timotimo compiler-run-time, eh? 10:46
jnthn Before I worked on Perl 6, I thought I knew what compile time and runtime were :P
jnthn figures he'll take on the #moarvm backlog first :) 10:49
nwc10 you have enough coffee ready? 10:51
jnthn Just made a fresh one :) 10:52
10:55 leont joined
dalek arVM: a8898a7 | nicholas++ | src/6model/serialization.c:
Note that deserialize_method_cache_lazy() is cruel and unforgiving.

As the comment said, deserialize_method_cache_lazy() stashes what we need to eserialize the method cache lazily later, and then skips over it.
As the comment now adds: ee70ddc | jnthn++ | src/mast/compiler.c: Force \r-containing strings to be UTF-8 stored.
Retaining the "already in NFG" invariant for the Latin-1 optimization.
  nwc10++ for suggesting this simple solution.		 11:06
jnthn nwc10++
11,532,280 CORE.setting.moarvm # Before 11:07
10,950,714 CORE.setting.moarvm # After
nwc10 "OMG I killed dalek."
11:07 dalek joined
jnthn m: say 10.95 / 11.53 11:07
camelia rakudo-moar 7c5390: OUTPUTĀ«0.949696ā¤Ā»
nwc10 thanks for checking it over and applying it
problem is that other folks keep implemetning stuff, and making the setting bigger
I think we should also just use these: en.wikipedia.org/wiki/One_instruct...t_computer 11:08
although maybe that would need an even bigger "setting" to be useful
jnthn: I think that the changes only make the (new) NQP bootstrap code about 9K smaller. 11:09
(but that wasn't really the point)
timotimo nwc10: how big is a bootstrap right before your changes? 11:10
nwc10 my generated nqp.moarvm is currently 852287 11:11
whilst stage0 is 845178, that's not a proper comparison, because it's not the same source code compiled
anywa, about 852287 + 9K before. IIRC :-) 11:12
jnthn Indeed, I think the bootstrap will be a little bigger this time
'cus NQP has gotten a little bigger in terms of amount of code
Phew, while 20 new tickets landed in RT over the weekend, most of them are JVM one 11:16
*ones
timotimo i didn't expect the glr to explode the jvm backend this much :( 11:19
... is an easy thing to say for someone who did next to nothing %) 11:20
jnthn It woulda been worse if it had added more VM-specific code rather than removing a good amount of VM-specific code
timotimo that's true 11:24
11:46 tokuhirom_h joined
dalek arVM: 789fd4e | jnthn++ | / (6 files):
Stub a couple of line-based reading ops.

setinputlineseps_fh will allow for setting mutliple separators, so we can look for both \r\n (which will be 1 grapheme) and \n. readlinechomp_fh will allow us to just construct a string without the line separator at VM level, to avoid having to then chomp it off at Perl 6 level.		 11:50
jnthn Ah, duh, looks like my breaking line number reporting in the \r\n -> 1 graph thing was just a silly thinko 11:52
ilmari is tools/windows1252_cp_gen.p6 supposed to be kept in sync with src/strings/windows1252.c? 11:57
or should it be rewritten to only modify the parts that are actually autogenerated?
it's currently a year out of sync 11:58
timotimo how often does that codepage change?
jnthn ilmari: I'd just toss the script tbh
Because...what timotimo said :)
timotimo oh, the code changes, not the source
jnthn The script was probably more fun for whoever did it than wrting out a translation table by hand 11:59
ilmari it generates the whole file, not just the tables and binary search code
jnthn Right
But I mean, the tables and binary search code won't change
ilmari true 12:00
jnthn 'cus the definition of windows-1252 ain't going to change
nwc10 "are you sure?" :-/
ilmari ignores it for now
jnthn I'd just delete the script
nwc10 I thought that MS did add some things to windows-1252
jnthn To avoid the confusion
nwc10 a decade ago
ilmari is looking at adding optional replacement character support to the various encode functions
nwc10 indeed they did: en.wikipedia.org/wiki/Windows-1252#History 12:01
until 18 years ago
any excuse to avoid lunch! 12:02
sorry, slow. just realised what time it is
dalek arVM: d7150f9 | jnthn++ | tools/windows1252_cp_gen.p6:
Toss windows 1252 code-gen script.

The source file it generated has gotten way ahead of the script, and it's quite unlikely we'll need to regenerate the boring mapping part in the future (and certainly not regularly). ilmari++ for spotting the outdated script.		 12:03
12:23 itz_stmuk joined
JimmyZ jnthn: could you review github.com/MoarVM/MoarVM/pull/286 ? :) 12:25
jnthn JimmyZ: Will do it later this week, when I'm looking more closely at I/O things (including dealing with the using sync handles between threads stuff) 12:27
JimmyZ jnthn: thanks :) 12:29
timotimo jnthn: is our solution for "using sync handles between threads" going to be "stop using libuv for synchronous stuff"? 12:30
dalek arVM: 8b806b1 | jnthn++ | src/ (7 files):
Refactor I/O API for multiple separator support.
jnthn timotimo: Yeah
At least, that's the most expedient solution I have :) 12:31
JimmyZ +1 :) 12:32
timotimo if i want to get a little head-start on it ... is socket stuff on windows the same api as on linux?
i seem to recall having to use SDL_net way back when to get bsd socket like API on windows 12:33
jnthn It's not miles off, but not the same
timotimo but using that API is the right way to go? bsd sockets on all platforms except windows, where we'll be using winsock? 12:34
jnthn timotimo: Aye, believe so
timotimo m: start { say $*IN.get }
camelia ( no output )
jnthn I wanted to take a look at UDP along the way
timotimo m: await start { say $*IN.get }
camelia rakudo-moar c5c19a: OUTPUTĀ«CĆ©ad slĆ”n ag slĆ©ibhte maorga Chontae DhĆŗn na nGallā¤Ā»
timotimo that'd be lovely
jnthn I don't think that one works out on Windows fwiw 12:35
timotimo but i'd rather get some work done at #work
i recall at some point moar was complaining when using $*IN from a different thread
jnthn Tried to read() on a socket from outside its originating thread in block <unit> at -e:1
Does on Windows
timotimo that's the one
i don't think it should have that error in there 12:36
it seems to work for all syncstreams
jnthn RT thinks not :) 12:37
timotimo urgh.
jnthn Somebody over the weekend was noting problems dealing with sync sockets over threads 12:38
timotimo yeah, sockets, sure
but stdin?
nwc10 windows doesn't implement one subtle part of the BSD socket API correctly. For socketpair()s (or any sockets between processes for that matter), implicit process exit discards data if the reader hasn't read it yet
this is bloody annoyingh 12:39
12:39 kjs_ joined
jnthn Ouch 12:39
nwc10 because it breaks one subtle but elegant part of the *nix API - the program doesn't need to care what STDOUT is.
and doesn't need to take special measures to be run from inetd (or similar) as a network daemon
it's why Perl 5 Test::Harness can't (easily) do parallel tests on Win32 12:40
at least, not "easily" the way it works on *nix
timotimo ugh, i didn't know that at all
nwc10 I've never experienced it directly, because I rarely have cause to use Win32 machines 12:41
but I've seen it break "portability" assumptions
jnthn It's probably why spectset on Windows has to set tests off in "batches"
nwc10 one hack is to have multiple threads. The thread has a Win32 pipe (forget the exact correct API term) from the "child" 12:42
the pipe doesn't drop data on the floor
but doesn't work with the select() emulation
each thread reads from the pipe (preserving data) and writes to a socket
and knows to flush its socket before exiting itself
and the two ends (child, and select loop) don't know any different 12:43
there's a Perl 5 IPC module that does this
I suspect this all comes from sockets originally being Winsock, and not part of the C Run Time
timotimo is winsock no longer a thing? 12:44
i don't really know what winsock "used to be"
nwc10 I don't know enough to answer that correctly
3.1 era third party library, IIRC
timotimo it'd be very much like windows to still have that 12:45
nwc10 or, was it an API, that one or more libraries provided an implementation of?
timotimo "Initially, all the participating developers resisted the shortening of the name to Winsock for a long time, since there was much confusion among users between the API and the DLL library file (winsock.dll) which only exposed the common WSA interfaces to applications above it." 12:49
apparently winsock is still a thing? 12:50
arnsholt Probably, given MS's zealous approach to backwards compat. The question is whether it's still something you're *supposed* to use, rather than something that still works, I suspect =) 12:52
timotimo no clue
13:08 tokuhirom_h joined
dalek arVM: 9c53ac7 | jnthn++ | src/ (3 files):
Implement setinputlineseps_fh op.

Can now set multiple separators.		 13:12
timotimo wow, we can have that many different input seps? 13:14
13:16 leont joined
jnthn timotimo: I hope not :P 13:17
It's enough to prevent various overflows
lunch &
(and after lunch I'll impl the readlinechomp op, and multi-grapheme separators)
lizmat jnthn: in newio I specced something like :nl-reading and :nl-saying to seperate input from output 13:45
would it make sense to put nl-saying also in Moar, and then include an nqp::say op ?
timotimo FWIW, reading from and writing to the same file is kind of icky as soon as you have something like a variable-length encoding 13:46
lizmat it would certainly make life a lot easier on the Perl 6 side, and potentially large output effiiciency consequences
timotimo how do you mean?
oh
i missed that second line
lizmat my $out := $*OUT; 13:47
my str $str = nqp::concat(nqp::unbox_s(x),$out.nl);
$out.print($str);
says it all, really
nqp::say(nqp::unbox_s(x))
would be *much* simpler and faster I would think
timotimo ah 13:48
well, concat ought to be somewhat efficient due to our ropes implementation getting that without doing a copy, but still ...
lizmat it's a lot HLL stuff that's really low level 13:51
the only thing missing is an :nl-saying attribute on VMIO
jnthn I suspect nl-in/nl-out would be better 14:01
ilmari do any of the regular moarvm hackers use emacs? if so, what c-mode settings do you use?
and could you stick them in a .dir-locals.el? 14:02
jnthn doesn't, but would be fine with such a file
lizmat: Will consider it, anyways 14:03
timotimo same
jnthn lizmat: For now I'm pondering API for multiple separators
lizmat that will make [Tux] very happy :-)
jnthn What does he want, ooc? 14:04
Just to be able to set multiple seps?
lizmat being able to split on multiple different line endings :-)
yup
jnthn OK, that I already have just written a test for, though they're all single char so far
timotimo hm. so did we have vm-level line splitting so far? i think we did, but we didn't have chomping in VM, right? 14:05
jnthn Correct, and it could only split on a single splitter 14:06
timotimo right. having chomp in vm sounds worthwhile
jnthn And my \r\n -> 1 grapheme blocked on that
Which is why this issue ended up leap-frogging finishing up that.
dalek arVM: b2c7ecc | jnthn++ | src/ (8 files):
Refactor readline I/O to pass down a chomp flag.

Reaches the decode stream now, but it doesn't yet know what to do with it.		 14:20
arVM: bea376b | jnthn++ | src/core/interp.c:
Implement readlinechomp_fh op.

Doesn't work yet, due to missing decode stream functionality.
14:27 kjs_ joined
dalek arVM: 61795ad | jnthn++ | src/strings/decode_stream.c:
Support chomping separators when reading lines.

For now, assumes that all separartors are a single grapheme, since that is all the separator finding logic can handle so far. Instead of constructing a string and then chomping it, we just produce a readily chomped string.		 14:43
ilmari making moarvm's string encode functions throw exceptions on unencodeable characters breaks zero nqp tests... 14:44
nwc10 "write more tests"?
I'm not actually sure what the desired right answer is here. 14:45
ilmari currently they unconditionally throw, the plan is to allow specifying a replacement char (or string?) 14:46
rt.perl.org/Public/Bug/Display.html?id=123673
jnthn Well, we tend to ultimately rely on the Perl 6 spectests to give good coverage.
14:53 TimToady joined
dalek arVM: aef902f | jnthn++ | src/strings/decode_stream.c:
Refactor to prepare for multi-graph line seps.
 14:57
ilmari what's the incantation for running spectest suite? 15:01
the README only talks about fudging
jnthn "make spectest" inside the Rakudo build directory
(It does a checkout of the spectests under t/spec)
ilmari ah
in the ticket, moritz suggests specifying the replacement as a Buf, but I thought it migth be easier to sepcify it as a Str wihch will be encoded with the same encoding (throwing an exception if it's not encodable, of course) 15:05
jnthn A Buf does indeed carry the risk that we spit out something that ain't valid in the encoding, yeah. 15:14
arnsholt Sounds like a good idea. I guess the Buf is more reasonable when you're primed to think about ASCII, since any byte sequence is valid ASCII 15:19
itz_stmuk *cough* 15:21
github.com/MoarVM/MoarVM/pull/288
15:22 tokuhirom joined
[Coke] itz_stmuk: "The Travis CI build is in progress" :P 15:23
but yah, that looks pretty harmless.
itz_stmuk how long does it take? and it's not like moar has its own tests ;)
moritz arnsholt: any byte sequence with bytes <= 127 is valid ASCII :-) 15:24
15:28 timo joined
arnsholt moritz: Durr, yeah. ASCII with high bit set is of course any one of a bajillion extended ascii charsets 15:29
>.<
dalek arVM: fcb8f1a | jnthn++ | src/strings/decode_stream.c:
Handle multi-grapheme line separators.
15:30 itz_stmu1 joined
dalek arVM: e1f8e6c | (Steve Mynott)++ | build/setup.pm:
fix moar build on DragonFly BSD
 15:31
arVM: 73c0269 | jnthn++ | build/setup.pm:
Merge pull request #288 from stmuk/master

fix moar build on DragonFly BSD
15:47 hoelzro joined, travis-ci joined
travis-ci MoarVM build failed. jnthn 'Handle multi-grapheme line separators.' 15:47
travis-ci.org/MoarVM/MoarVM/builds/88809584 github.com/MoarVM/MoarVM/compare/a...b8f1a16f01
15:47 travis-ci left
jnthn orly? 15:48
hah, interesting race condition :) 15:50
(It started the Moar build, but then I merged something else and bumped MOAR_REVISION, and so when the build grabbed NQP it was a too old Moar already) 15:51
15:57 kjs_ joined 16:52 LLamaRider joined
diakopter jnthn: lolz 17:19
17:30 ggoebel2 joined 18:15 kjs_ joined 19:22 leont joined 19:39 tokuhirom_h joined 19:45 vendethiel joined 19:48 Ven_ joined 20:18 kjs_ joined 20:37 leont joined 21:12 Ven_ joined
dalek arVM: b2c18a3 | jnthn++ | build/setup.pm:
Disable logical-op-parentheses warning on clang.

Not all that is precedence is obvious, but surely this case is.		 21:21
21:31 Peter_R joined 21:33 Ven_ joined 21:45 Ven_ joined 21:50 harrow joined 21:57 Ven_ joined 22:16 tokuhiro_ joined 22:18 stmuk joined 22:20 kjs_ joined 23:12 Ven_ joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!