Geth MoarVM: 8a1de2c29f | (Samantha McVey)++ | docs/ChangeLog
Update ChangeLog to prepare for release
01:22
samcv if others can give a check over the Changelog that would be great 01:23
the just commited version
MasterDuke looks pretty good to me 01:31
AlexDaniel yeah, I've read through it also, looks good 01:32
AlexDaniel samcv: please ping me once the release is out :) 03:52
Geth MoarVM: a7d3f709c6 | (Samantha McVey)++ | VERSION
Release version 2018.02
04:15
samcv MoarVM site has been updated now 04:23
AlexDaniel yay 04:23
ok will get to rakudo soon :)
Geth MoarVM: 258684f032 | (Samantha McVey)++ | 3 files
Move moarvm.org tool into proper folder. More release guide info

Make sure to say how many lines on the homepage need to be changed, to make sure you alter all of them.
04:32
Geth MoarVM: 8de11a8189 | (Jonathan Worthington)++ | src/spesh/log.h
Use cur_frame, not tc->cur_frame access again

Oversight spotted by japhb++.
11:05
Geth MoarVM: b39fa0ec41 | (Jonathan Worthington)++ | 10 files
Add an nqp::tryfindmethod

Which evaluates to nqp::null in the event that the method cannot be found. This will allow things that do nqp::can + nqp::findmethod to avoid the double-resolution. While sometimes spesh can do that, this can give better baseline performance before optimization and avoid a double-lookup in the unoptimizable mega-morphic case.
12:14
jnthn Seems that just using that in !reduce gets 3% off a JSON::Tiny benchmark 12:18
dogbert17 jnthn: back to optimizing ? 12:20
timotimo my next opt may be to make all atkey on getenvhash constant-folded at spesh time, so we can put debug code guarded by getenvhash()<foo> everywhere with what i'm hoping would be a very minor performance impact 12:22
dogbert17 moar speed is never a bad thing :-) 12:25
jnthn dogbert17: Yeah, figured I'd do a little bit on regex-y stuff 13:09
dogbert17 I guess that there are a few opportunities there 13:17
m: use nqp; ((" " x 5000) ~ "end") ~~ / \s+$ /; say now - INIT now # are you after stuff like this ? 13:20
camelia 2.7869513
jnthn Potentially, yes :) 13:25
dogbert17 cool 13:26
timotimo m: use nqp; say (" " x 5000).chars; say now - INIT now
camelia 5000
0.0019839
timotimo m: use nqp; say (" " x 5000 ~ "end").chars; say now - INIT now
camelia 5003
0.00195658
timotimo ok
dogbert17 [14:11] <timotimo> our regex optimizer is dumb as bricks ;) # quote taken from RT #128693 :-) 13:27
synopsebot RT#128693 [new]: rt.perl.org/Ticket/Display.html?id=128693 [PERF] Regex optimizer on \s+$ is "dumb as bricks"
timotimo m)
maybe it should have been "as sharp as a brick"? or maybe "as sharp as a wet sponge" 13:28
lizmat
.oO( brought to sleep by hypnosis? )
timotimo hey lizmat, i hope your sickness subsides soon :)
lizmat getting a little better every day 13:29
feeling up to doing stupid commits now :-)
dogbert17 :-)
timotimo awesome!
we just had the release, so there's like 4 weeks for others to find problems in what we commit now :D
jnthn Yeah, that's why I started committing again today :P 13:31
AlexDaniel thanks :) 19:48
Geth MoarVM: 314c523fe5 | (Samantha McVey)++ | 10 files
Add ops for strict decoding of windows-1251/1252

We have new versions of `encode`, `decode`, and `encoderep` that allow a new config flag. These ops differ from the previous encode/decode ops in that by default they decode using strict rather than permissive methods. They throw on encountering a codepoint that is not mapped in the standard and optionally will decode permissively. ... (22 more lines)
22:21
samcv jnthn: can you look at github.com/MoarVM/MoarVM/pull/799 i'm thinking of merging it 22:25
should make it much easier to maintain libatomic_ops because it started with the actual libatomic_ops repo, checked out the newest version that we had bumped to (years ago). then merged in our libatomic ops (separated only that folder as its own repo and merged into libatomic's repo at that version) 22:26
then once that merged, i think merged it again at libatomic_ops's latest release with our current version 22:27
which was a pain but will avoid pains in the future I am hoping
jnthn samcv: Hm, that sounds very good in principle :) 22:44
Ah, the diff is huge 'cus it's got the whole removal of libatomicops :)
samcv yeah
i know we had issues before where we removed a submodule? right? and turned it ito our own directory? 22:45
i tested though and you can pull and it will remove libatomicops dir and put the submodule there instead
only issues seems to be going backwards
so shouldn't have issues with things that pull and autobuild
jnthn Yeah, there was some problem along those lines 22:46
Well, one sure-fire way to avoid it is to put the submodule into a differently named directory :)
samcv heh 22:47