Geth nqp: jstuder-gh++ created pull request #436:
Expose Moar 'slice' op in NQP		 01:07
[TuxCM] Rakudo version 2018.03-242-gb0cc35434 - MoarVM version 2018.03-124-gdeaffb2de
csv-ip5xs0.897 - 0.912
csv-ip5xs-208.738 - 8.832
csv-parser35.657 - 36.709
csv-test-xs-200.450 - 0.457
test9.375 - 9.416
test-t2.474 - 2.502
test-t --race1.020 - 1.057
test-t-2043.878 - 43.956
test-t-20 --race14.946 - 15.389
 06:02
nine, will you mail me the new(er) instructions? (if you did, I missed them)
lizmat Files=1239, Tests=76306, 321 wallclock secs (15.80 usr 5.65 sys + 2216.73 cusr 222.93 csys = 2461.11 CPU) 07:34
nine [TuxCM]: gist.github.com/niner/fc6d15e881c5...7d03175e6d 07:39
Geth rakudo: f6756bb4d9 | (Stefan Seifert)++ | lib/NativeCall.pm6
Replace manual dispatch with proper multis for guess_library_name
 08:29
samcv nine++ 08:39
[TuxCM] Rakudo version 2018.03-242-gb0cc35434 - MoarVM version 2018.03-124-gdeaffb2de
csv-ip5xs0.871 - 0.888
csv-ip5xs-208.673 - 8.713
csv-parser35.903 - 37.013
csv-test-xs-200.439 - 0.450
test8.892 - 9.400
test-t2.425 - 2.437
test-t --race1.016 - 1.024
test-t-2044.091 - 44.760
test-t-20 --race15.423 - 15.550
 08:59
First repor on direct built perl6. (leaving rakudobrew)
Geth nqp/nqpmake: 7c1a8b9906 | (Stefan Seifert)++ | 2 files
Fix build not noticing change in dependency
 10:17
nqp/nqpmake: be9a658768 | (Stefan Seifert)++ | 2 files
Notice changes in non-target source files (AKA the common case)
 10:42
lizmat after looking at metacpan.org/pod/List::UtilsBy#wei...shuffle_by , why don't we have a MixHash.grab again ? 11:52
MasterDuke lizmat: a little while ago i was running this: perl6 -Msnapper -e 'for ^1_000 { (^100).race(batch=>1).map({ $_ }).List }' 12:04
and the result didn't appear to be sorted by any of the columns. think it would make sense to sort by wallclock by default?
lizmat then you wouldn't know in which period the changes occurred ? 12:05
MasterDuke "in which period"? i don't understand 12:06
what changes?
lizmat the report shows the changes for each period 12:12
in the case of wallclock, it's the number of microseconds passed
in the case of max-rss it's the amount of memory extra allocated 12:13
MasterDuke ah, they're not running totals 12:14
lizmat util% is a bit weird in that case, I'll admit, but that's just basically CPU's used / wallclock
nope
the last line, those are totals (except util% again)
MasterDuke hm, any idea why /usr/bin/time give a rather bigger number for maxrss? 12:15
lizmat since when does /usr/bin/time give maxrss info ?
MasterDuke time (the shell builtin doesn't), but /usr/bin/time always has 12:16
s/doesn't\)/) doesn't/ 12:17
lizmat not on MacOS :-(
so I have no idea... perhaps the overhead of "time" itself? 12:18
MasterDuke heh, i doubt time has 80mb overhead 12:19
btw, looks like 'brew install gnu-time' will give you a 'gtime' binary
fwiw, running `/usr/bin/time /usr/bin/time echo 1` shows 2mb maxrss 12:21
`/usr/bin/time ./install/bin/perl6-m -Msnapper -e ''` shows 16756 total maxrss in the snapper report, but 91448 maxrss from time 12:28
looks like maybe snapper isn't picking up (or just needs to compensate for somehow) the initial startup ram cost 12:29
lizmat snapper only shows differences
check the Initial/Final Size: in the header
does that match your expectation ?
MasterDuke ah, that's a lot closer 12:31
lizmat has to go on another sad commute
will probably be offline quite a bit the coming days
&
MasterDuke that sucks, condolences 12:32
maybe i'll try to make the docs a little more explicit that the values in the columns are just differences 12:33
samcv .tell lizmat i think it was MixHash or one of the similar types i'd been wanting a .grab for a while 12:44
yoleaux samcv: I'll pass your message to lizmat.
dogbert2_ releasable:next 13:10
releasable6 dogbert2_, Next release in ā‰ˆ1 day and ā‰ˆ5 hours. 3 blockers. 224 out of 243 commits logged
dogbert2_, Details: gist.github.com/65af7fd7517a0adcc9...b9ff879967
dogbert2_ releasable: uptime
releasable6 dogbert2_, 14 hours, 16 minutes, and 2 seconds, 305.304688MiB maxrss. This is Rakudo version 2018.03-242-gb0cc35434 built on MoarVM version 2018.03-124-gdeaffb2de implementing Perl 6.c.
AlexDaniel shareable6: uptime 13:15
shareable6 AlexDaniel, 14 hours, 20 minutes, and 37 seconds, 376.820313MiB maxrss. This is Rakudo version 2018.03-242-gb0cc35434 built on MoarVM version 2018.03-124-gdeaffb2de implementing Perl 6.c.
[Coke] so, I don't have a native windows box, but I had a virtual box setup where I could build rakudo a few months ago. If I dust that off, is there something in particular that needs testing on the windows side? 13:33
. o O ( building on windows now ) 13:41
makefile is borked; I have to explicitly type "nmake all" now instead of just "nmake" 13:45
timotimo [Coke]: it's about time for nqpmake! 13:48
Zoffix [Coke]: FWIW, I built without trouble on Win10 with Strawberry Perl toolkit a week or two ago 14:00
huggable: rakudo win
huggable Zoffix, perl Configure.pl --gen-moar --gen-nqp --backends=moar & gmake & gmake test & gmake install
Zoffix ^ using that set of commands
[Coke] I'm using MS Visual Studio 14:18
timotimo MV Sisual Studio 14:20
St V Sisual Mudio 14:21
stmuk_ maybe something gnu make specific has sneaked in? 14:48
timotimo AlexDaniel: you think a patch to switch $$/^^, $/^, Ā«/Ā» inside a <?after> around ought to make it into this release? given it's the LP6 release and all? 17:42
AlexDaniel timotimo: I think it can go in if you feel good about patch itself 17:44
I'm going to run toaster again tonight, so if something is wrong I hope we'll catch it
timotimo let me make sure that spectests are on my side here
Zoffix timotimo: is it LP6 release tho? How do you figure? 17:49
timotimo i thought LP6 is going to come out Real Soon Now?
you think we'll release an Emergency Star when the book hits shelves? 17:50
Zoffix huggable: star 17:52
huggable Zoffix, Estimated Rakudo Star releases for 2017: .01, .04, .07 & .10
timotimo anyway, stresstest is happy with the patch it seems like
Zoffix I think there'll be time for another release.
timotimo OK, it'll go into a post-release branch, then
Zoffix It's Real Soon, but Real Soon compared to the 2+ years it took
AlexDaniel ok
Zoffix In the last LP6 supporter update, it says "Things are going well. I've gone through the entire book and there are only some minor to do items left. My editor at O'Reilly has started reading through it and I'm hoping to be done in a matter of weeks. There are still many things to polish at this point. Once I turn it in I'll take some time to explain the roughly three month process that happens after that. "
So looks like there's still 3m after polishing. 17:53
This was sent on Apr 2nd
timotimo ooh
that's good
t/spec/S05-mass/rx.rakudo.moar (Wstat: 0 Tests: 755 Failed: 0) 17:54
TODO passed: 157
t/spec/S05-metasyntax/lookaround.rakudo.moar (Wstat: 0 Tests: 14 Failed: 0)
TODO passed: 11-14
Zoffix m: say Date.new('2018-07-28') - Date.today
camelia 99
Zoffix roughly 100 days until next-next Star
timotimo ok 157 - lookbehind <after> # TODO anchors and after RT #124898 17:55
synopsebot RT#124898 [new]: rt.perl.org/Ticket/Display.html?id=124898 [REGEX] S05-mass/rx.t line:503 reason: 'anchors and after'
timotimo that title ...
ok 11 - ^^ in <?after ...> # TODO RT #131964
synopsebot RT#131964 [new]: rt.perl.org/Ticket/Display.html?id=131964 [REGEX] Anchors ^, ^^, $, $$, Ā«, Ā» confused in <?after> 17:56
timotimo so yeah, we already have tickets for this behaviour, and todo'd spectests. i'll say this patch is a good patch.
Geth nqp/fix_anchors_in_after_regex_assertion: e60f1d8fd9 | (Timo Paulssen)++ | src/QRegex/P6Regex/Actions.nqp
switch around a few anchor types inside <after>

since <after> is implemented as "flipping" the AST of the regex and matching it against a flipped version of the target string, a "right word boundary" has to become a "left word boundary", same for ^^/$$ and ^/$		 17:59
timotimo there we go.
[Coke] finally got back to running the stresstest on windows again; first few tests seem very slow, cpu utilization at 1%; guessing one of the stresstest files is just borked on windows, falling back to spectest 18:24
Zoffix Might be one of network nests. Windows got like 1s delay before retrying/failking things or something and the test assumes it'll retry/fail automagically and fast 18:26
[Coke] yah, I'll go back and look at those individually. I just wanted to make sure I had a run; still don't know what the "drop support for windows" was about earlier today, just trying to avoid that.
Zoffix nods 18:28
[Coke] ... I totally should be making sure the p6 stuff I'm using for $DAYJOB on my mac works in this VM. 18:30
AlexDaniel afk for a nap 18:34
releasable6 Next release in ā‰ˆ23 hours. 3 blockers. Please log your changes in the ChangeLog 19:00
Kaiepi shit i won't have the changes to rakudobot needed done in time for the next release 19:18
there's a lot of refactoring i need to do since it's kinda hacky atm 19:19
for now, just run build and test and i'll deal with stresstest manually 19:20
do the docs have a style guide? 19:22
Zoffix Yup, there's a bunch of .md files in root of repo 19:38
Kaiepi perfect
Zoffix STYLE/EXAMPLES/CONTRIBUTING IIRC
Kaiepi STYLE and EXAMPLES are missing for me 19:44
Zoffix Kaiepi: looks like those got moved: github.com/perl6/doc/tree/master/writing-docs
Kaiepi ah 19:47
what i was wondering about was how headers should be capitalized 19:48
i've seen "Foo bar baz" and "Foo Bar Baz" in the same pages before
Zoffix Just do whatever looks better and then you can open an Issue to ask what the better version is: github.com/perl6/doc/issues/new 19:49
Or just make it all consistent and add to Style Guide :P
Zoffix &
Kaiepi i think i'll ask for some input before making it all consistent 19:51
btw thoughts on a page for learning perl6 as a nodejs once i'm more familiar with the language 19:56
s/nodejs/\0 user/
mst can't do any harm AFAICS 20:14
Kaiepi i think it'd be helpful since stuff like classes and anything async behave completely differently between the two 20:35
well 20:36
"classes" in node's case 20:38
but stuff like getters/setters and es6's decorators proposal can be done in perl6 fairly easily 20:39
speaking of which is trait_mod useful for Variable, Attribute, etc. outside of rakudo's code? 20:40
jnthn Yeah, you can write custom ones :) 20:41
yoleaux 18:23Z <Zoffix> jnthn: is this a sane thing to do? Making custom ops work globally: `CORE::<&infix:<+>>.add_dispatchee: multi infix:<+> (O \a, O \o) { ā€¦ }` .add_dispatchee ain't in the spec, wondering if it can be added?
Kaiepi you can/
s/\///
jnthn Sure, I've done it in multiple of my modules :)
Kaiepi oh!
can you link some examples?
i've only figured out how to work with Routine with it 20:42
jnthn Bunch of parameter ones here: github.com/croservices/cro-http/bl...er.pm6#L28 20:43
Trying to remember about attributes...h 20:44
Kaiepi ohh, i didn't think about using roles with it 20:45
jnthn Hm, can't find an attribute one off hand. 20:48
And method ones you already know about :)
Kaiepi yep, i'm using one for a refactor i'm writing 20:49
timotimo .o( rakudoboot ) 20:59
Zoffix Feels like adding constrained protos to resolve R#1739 is not the best of ideas. (1) It blocks off user's multies that use more positionals (if they define their own proto, they have to make it shuttle stuff to core ops). (2) it's very fragile, both in terms that we in core and users in their code need to remember to provide proper protos AND to ensure the protos match all the available candidates so none 21:21
synopsebot R#1739 [open]: github.com/rakudo/rakudo/issues/1739 [āš  blocker āš ] Unintended consequences of converting routines from `only` to `multi`
Zoffix are blocked off by the proto's sig.
Basically, we're making it so the system depends on some manual step that isn't correlated to the .sort or whatever choosing which form to call. And requiring that step means bugs. 21:22
I think we should make the stuff that checks .count to go through candidates and figure out what the largest count is based on that. And that's a perf loss, but we can add some "apparent-count" method or something calling which makes the dispatchers return the cached value of the largest count of its multies (non-dispatchers would return their actual .count) and that cached value would be updated when 21:24
.add_dispatchee is called to add a candidate (I'm assuming that's how candidates are added; haven't actually looked)
.oO( maybe I should actually comment that on the issue... )
 21:25
jnthn If doing so, please supply examples of why (1) is a concrete problem. 21:30
Zoffix Just more work, both for the user and for the computer (currently slurpies aren't cached, so it'd be slower if you do a capture arg and shuttle it to core op). Also, it's kinda non-obvious that you can do it 21:32
jnthn Yes, but that's still abstract. I mean, I went through a bunch of the built-ins and tried to imagine when extending them with an extra positional could be a sensible API design choice and didn't come up with anything much. 21:33
One thing we could do relatively easily already is, when a multi is declared whose signature won't meet the proto signature, to complain about it at compile time. 21:35
Which would make it decidedly obvious.
Zoffix m: say &words 21:40
camelia sub words (| is raw) { #`(Sub|60887576) ... }
Zoffix OK.
I'm gonna stick the protos then some time later tonight 21:41
Change (|) to more specific protos I mean
jnthn OK. I'll think of your comment some more also.
Though a bit tired to think straight right now.
Geth rakudo: 27565bf8e8 | (Zoffix Znet)++ | lib/NativeCall.pm6
Micro-optimize guess_library_name()

Per comments on github.com/rakudo/rakudo/commit/f6...t-28677139		 23:05
rakudo: zoffixznet self-assigned Unintended consequences of converting routines from `only` to `multi` github.com/rakudo/rakudo/issues/1739
a0cbdbd8ed | (Zoffix Znet)++ | src/core/List.pm6
 23:07
Zoffix $ G 'proto ' src/core | grep -v method | wc -l 23:12
352
daum.. .that gonna take awhile
rakudo: 4f848967c8 | (Zoffix Znet)++ | 4 files
Add "sub" to proto/multi for consistency
Zoffix uh-oh 23:43
ah, nm, just a bug in my code. For a second I thought I found mis-scoped case of `for`+`without` 23:45
m: say 155/349 23:56
camelia 0.444126
Zoffix 44% of our multi subs ain't got a restrictive proto 23:57
Geth rakudo: 20ccaccad7 | (Zoffix Znet)++ | t/02-rakudo/12-proto-arity-count.t
Add fudged tests for restrictive protos

Covers currently-existing, public multis as part problem in
  github.com/rakudo/rakudo/issues/1739		 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!