lizmat good night, #perl6-dev 00:00
jnthn 'night lizmat
samcv Alphabetic = Lowercase + Uppercase + Lt + Lm + Lo + Nl + Other_Alphabetic
but our <alpha> is not like that 00:01
that is intended
?
j: say so 'šŸ…' ~~ /<alpha>/ 00:03
camelia rakudo-jvm fb4f16: OUTPUTĀ«Falseā¤Ā»
jnthn Not sure... :) 00:06
Bed time for me...'night
samcv this is weird. we make it way more complicated than it needs to be.... 00:07
no wonder it' slower
there is an alphabetic property we can just check :P 00:08
we check Lo, Ll, Lu, Lt, Lm
so that does seem like an error
i can make a lot of our things like \d and \w a lot faster 00:10
i guess it doesn't make it much faster here because we hold onto the property values between queries 00:17
alpha can def get faster tho. but \d is gonna stay the same
are we getting failures in Inline::perl5? 00:58
.ask TimToady aside from <alpha> also matching underscore, is it intentionally different from Unicode property Alphabetic? 01:02
yoleaux2 samcv: I'll pass your message to TimToady.
samcv .ask TimToady at the moment it does not cover all of Unicode property Alphabetic in MVM it only covers some of them (Lo, Ll, Lu, Lt, Lm) Per Unicode spec: Alphabetic = Lowercase + Uppercase + Lt + Lm + Lo + Nl + Other_Alphabetic 01:04
yoleaux2 samcv: I'll pass your message to TimToady.
TimToady I'm sure all those distinctions didn't exist when we started. :) 01:47
yoleaux2 01:02Z <samcv> TimToady: aside from <alpha> also matching underscore, is it intentionally different from Unicode property Alphabetic?
01:04Z <samcv> TimToady: at the moment it does not cover all of Unicode property Alphabetic in MVM it only covers some of them (Lo, Ll, Lu, Lt, Lm) Per Unicode spec: Alphabetic = Lowercase + Uppercase + Lt + Lm + Lo + Nl + Other_Alphabetic
samcv ah ok
yeah i thought
that was likely
TimToady and when bootstrapping, we were doing everything by enumeration; c.f. the brackets and such 01:48
samcv though 'fixing it' breaks Nl's
because i guess it assumes they won't match <alpha>
TimToady I doubt there are many people using P6 on roman numerals yet 01:50
samcv yeah 01:52
u: { my $chr = .chr; ($chr ~~ /\s/).Bool != ($chr ~~ /<:ws>/).Bool } 01:59
unicodable6 samcv, U+0009 <control-0009> [Cc] (control character) 02:00
samcv, U+000A <control-000A> [Cc] (control character)
Geth nqp: fe0dd2f24d | (Samantha McVey)++ | src/QRegex/P6Regex/Grammar.nqp
Make <ws> ~4% faster

We don't need the `+` on the \s because we already have a * on the group.		 02:54
MasterDuke samcv++ 02:58
samcv BLAZING FAST
brokenchicken Sweet. That doesn't affect Rakudo though, does it?
MasterDuke samcv *= 1.04 02:59
samcv probably
brokenchicken Awesome.
samcv brokenchicken, github.com/rakudo/rakudo/blob/nom/...#L598-L617 is this using <ws>
but yeah it affects <ws. in regex generally
not sure what we do in that link ^
brokenchicken samcv: don't we override it here? github.com/rakudo/rakudo/blob/nom/...#L595-L617 03:00
samcv i just linked that :p
brokenchicken Oh you linked to same page :)
samcv not sure what we do there. also not convinced that would be faster than just <ws>
brokenchicken m: for ^100000 { if 0 { 1 } else { 5 } }; say now - INIT now 03:01
camelia rakudo-moar f799a0: OUTPUTĀ«WARNINGS for <tmp>:ā¤Useless use of constant integer 1 in sink context (line 1)ā¤Useless use of constant integer 5 in sink context (line 1)ā¤0.0612390ā¤Ā»
brokenchicken m: for ^3000000 { if 0 { $ = 1 } else { $ = 5 } }; say now - INIT now
camelia rakudo-moar f799a0: OUTPUTĀ«2.642503ā¤Ā»
samcv well i went from 135.97s to 130s compile time
brokenchicken m: for ^3000000 { 0 ?? $ = 1 !! $ = 5 }; say now - INIT now
camelia rakudo-moar f799a0: OUTPUTĀ«5===SORRY!5=== Error while compiling <tmp>ā¤Precedence of = is too loose to use inside ?? !!; please parenthesizeā¤at <tmp>:1ā¤------> 3for ^3000000 { 0 ?? $7ā5 = 1 !! $ = 5 }; say now - INIT nowā¤ expecting any of:ā¤ infixā¤ ā€¦Ā»
samcv just one test of each tho;ugh
brokenchicken m: for ^3000000 { 0 ?? ($ = 1) !! ($ = 5) }; say now - INIT now
camelia rakudo-moar f799a0: OUTPUTĀ«1.50586049ā¤Ā»
brokenchicken m: say 2.64/1.5 03:02
camelia rakudo-moar f799a0: OUTPUTĀ«1.76ā¤Ā»
brokenchicken samcv: ^ seems changing the if/else in method ws to a ternary gives a win
samcv nice
i'll change that and then bench again :) 03:03
wow 03:05
down to 105 seconds compile time! 03:06
actually dunno if i did a make clean
gonna make clean and then time it
ok 128s 03:13
so i'm seeing about 5% improvement in compile times
MasterDuke awesome! 03:15
japhb m: say 1.05 ** 10 03:21
camelia rakudo-moar f799a0: OUTPUTĀ«1.628894626777441ā¤Ā»
Geth rakudo/nom: 0bb7c20637 | (Samantha McVey)++ | tools/build/NQP_REVISION
Bump NQP to get a 4% speed increase for <ws>

perl6/nqp@fe0dd2f2		 03:22
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....-gfe0dd2f2
d5262e6c44 | (Samantha McVey)++ | src/Perl6/Grammar.nqp

With the NQP bump and this change I am seeing a 5% decrease in Rakudo compile times.
samcv \o/
Geth Ā¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....-gfe0dd2f2
MasterDuke i'll try to profile another build 03:24
japhb Why is it useful for token unsp to recurse? 03:32
TimToady: ^^
MasterDuke TimToady, japhb: FWIW, a rakudo built with this line ( github.com/rakudo/rakudo/blob/nom/...r.nqp#L620 ) commented out passes spectest 04:00
samcv MasterDuke, nice 04:04
MasterDuke, does it make it any faster though? 04:05
MasterDuke not noticeably 04:06
samcv yeah that's what i thought 04:07
s/thought/guessed
MasterDuke newest --profile-compile of a rakudo build sorted by exclusive time: gist.github.com/MasterDuke17/b694b...20bcb71392 04:11
samcv u: { (.chr ~~ /\v/).Bool } 04:13
unicodable6 samcv, U+000A <control-000A> [Cc] (control character)
samcv, U+000B <control-000B> [Cc] (control character)
japhb .tell jnthn Just submitted RT #130716, LTA behavior of unbounded supply {} + react/whenever. This is blocking my progress on treating raw terminal input (an unbounded source) as a supply, because any calling code that uses react/whenever instead of .act will appear to hang. :-( 05:25
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130716
yoleaux2 japhb: I'll pass your message to jnthn.
lizmat Files=1175, Tests=55871, 166 wallclock secs (10.13 usr 4.17 sys + 967.04 cusr 103.78 csys = 1085.12 CPU) 06:51
samcv u: { .uniprop('Upper') and .uniprop ne 'Lu' } 07:56
unicodable6 samcv, U+2160 ROMAN NUMERAL ONE [Nl] (ā… )
samcv, U+2161 ROMAN NUMERAL TWO [Nl] (ā…”)
samcv, gist.github.com/e499976aa394f0f7aa...864327c9bd
samcv j: say 'ā…”' ~~ /<alpha>/ 08:07
camelia rakudo-jvm fb4f16: OUTPUTĀ«ļ½¢ā…”ļ½£ā¤ alpha => ļ½¢ā…”ļ½£ā¤Ā»
samcv m: say 'ā…”' ~~ /<alpha>/
camelia rakudo-moar d5262e: OUTPUTĀ«Nilā¤Ā»
samcv so i think i am going to change Character Class Alpha === Unicode property Alphabetic 08:08
since jvm it already does that
gotta make sure nothing breaks first though 08:09
if we really want the old functionality we can use <:L> instead 08:10
m: say 'ā…”' ~~ /<:L>/
camelia rakudo-moar d5262e: OUTPUTĀ«Nilā¤Ā»
samcv i think <:Letter> == <:L> as well 08:13
@TimToady, in case you wanted to know what I have decided 08:14
m: sub ā…” { } 08:24
camelia rakudo-moar d5262e: OUTPUTĀ«5===SORRY!5=== Error while compiling <tmp>ā¤Missing blockā¤at <tmp>:1ā¤------> 3sub7ā5 ā…” { }ā¤ expecting any of:ā¤ new name to be definedā¤Ā»
samcv j: sub ā…” { } 08:25
camelia rakudo-jvm fb4f16: OUTPUTĀ«5===SORRY!5=== Error while compiling <tmp>ā¤Missing blockā¤at <tmp>:1ā¤------> 3sub7ā5 ā…” { }ā¤ expecting any of:ā¤ new name to be definedā¤Ā»
samcv say "ā…·".Int 08:46
m: say "ā…·".Int
camelia rakudo-moar d5262e: OUTPUTĀ«Cannot convert string to number: base-10 number must begin with valid digits or '.' in '3ā5ā…·' (indicated by ā)ā¤ in block <unit> at <tmp> line 1ā¤ā¤Actually thrown at:ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
samcv m: say "ā…·".Num
camelia rakudo-moar d5262e: OUTPUTĀ«Cannot convert string to number: base-10 number must begin with valid digits or '.' in '3ā5ā…·' (indicated by ā)ā¤ in block <unit> at <tmp> line 1ā¤ā¤Actually thrown at:ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
samcv m: say ā…·
camelia rakudo-moar d5262e: OUTPUTĀ«8ā¤Ā»
samcv j: say "ā’¶" ~~ /<alpha>/ 08:51
camelia rakudo-jvm fb4f16: OUTPUTĀ«ļ½¢ā’¶ļ½£ā¤ alpha => ļ½¢ā’¶ļ½£ā¤Ā»
Geth roast: c029e7f258 | (Samantha McVey)++ | S15-unicode-information/uniprop.t
Add some more tests for East_Asian_Width

Now that East_Asian_Width has been added in MoarVM, add some tests which currently pass and allow us to return the abbreviated property values but also add tests which want the full property value.		 09:04
timotimo i actually thought giving \s a + inside the []* was a performance optimization 11:51
MasterDuke: gist.github.com/timo/43777e12adc6a...cccc5c698a 11:57
jnthn m: say (-42)\ \ .abs 12:10
camelia rakudo-moar d5262e: OUTPUTĀ«42ā¤Ā»
yoleaux2 05:25Z <japhb> jnthn: Just submitted RT #130716, LTA behavior of unbounded supply {} + react/whenever. This is blocking my progress on treating raw terminal input (an unbounded source) as a supply, because any calling code that uses react/whenever instead of .act will appear to hang. :-(
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130716
jnthn MasterDuke: I think eval above is why <.unsp> recurses
And the various places <.unsp> is called don't quantify it 12:11
So looks like a case of missing spectest
timotimo i think what japhb is running into is that there's no whenever at all inside the supply block and so it ... doesn't finish? but it *does* finish in the first example ā€¦ 12:13
i mean, the supply block is supposed to run to completion before it creates the supply, right? 12:14
RabidGravy yeah 12:15
jnthn There's a misunderstanding at line 12, but that probably doesn't affect things
MasterDuke timotimo++, did you get that fancy formatting just by making it a tsv?
jnthn (A role is not a closure)
timotimo yes
i just replaced all | with \t, and then replaced a bunch of \t back to | when they were inside < > 12:16
RabidGravy a roll is not brioche
jnthn Oh, also
Spot the other bug on line 29
I suspect it meant to call $s2.done
timotimo oooh s1 :)
RabidGravy can you lot type bigger please, I'm not getting my new glasses until tomorrow :) 12:17
timotimo normally, you'd put a QUIT { } in place where japhb is using the "method done" trick, right?
MasterDuke timotimo: nice, i'll figure out how to get sqlite to use \t as the delimiter 12:18
jnthn CLOSE, perhaps
Though even more likely is a `last` in the whenever block 12:19
Even with the issues fixed, there's still the original reported issue, however.
timotimo _ _ _ _ _ _ _
(_)___ | |_| |_ (_)___ | |__ ___| |_| |_ ___ _ _
| (_-< | _| ' \| (_-< | '_ \/ -_) _| _/ -_) '_|
|_/__/ \__|_||_|_/__/ |_.__/\___|\__|\__\___|_|
MasterDuke: sqlite> .mode csv 12:20
also, .output test.csv
MasterDuke timotimo++
timotimo you may also want .headers on
jnthn It's a bit of a tricky issue in general, in so far as supply/react aren't really meant to introduce concurrency on their own, but they are meant to offer mutual exclusion 12:21
timotimo apparently there's also .once which will turn .output back to what it was directly after running your next sql statement
RabidGravy timotimo, perfect! cheers!
MasterDuke yeah, i was using .once so that just the next query i ran would get output to a file 12:22
jnthn Could I get a sorted-by-inclusive-time version of that gist also? 12:23
MasterDuke jnthn: `say (-42)\ \ .abs` still works with that line commented out
jnthn: sure, i'll put it up in a min
jnthn Ah, that may not be a good example 12:24
timotimo i'm surprised the github tsv/csv viewer won't let you sort stuff
jnthn m: $*OUT.say\ \ (42) 12:25
camelia rakudo-moar d5262e: OUTPUTĀ«42ā¤Ā»
jnthn MasterDuke: That one might be more upset with it commented out :)
The thing one ends up in <.ws> I guess
jnthn didn't finish his coffee yet :)
MasterDuke `No such method 'CALL-ME' for invocant of type 'Bool'` 12:26
timotimo m: $*OUT.say (42) 12:27
camelia rakudo-moar d5262e: OUTPUTĀ«5===SORRY!5=== Error while compiling <tmp>ā¤Two terms in a rowā¤at <tmp>:1ā¤------> 3$*OUT.say7ā5 (42)ā¤ expecting any of:ā¤ infixā¤ infix stopperā¤ statement endā¤ statement modifierā¤ statement modā€¦Ā»
timotimo i wonder how it gets that
jnthn So, that gets us our spectest that needs it to recurse, I guess :-) 12:30
MasterDuke jnthn: gist.github.com/MasterDuke17/dad51...519123da8b 12:33
jnthn: should i add `$*OUT.say\ \ (42)` to roast? 12:34
jnthn MasterDuke: Yes, lets 12:37
Well, not that precise example
But something of that form
Interesting, compile_in_context is actually less of a time sink than I expected
MasterDuke didn't dogbert17++ ask about some error in libuv? was it with uv_fs_scandir_next? 12:38
jnthn He did, I don't *think* it was that function 12:39
< dogbert17_> o/ has anyone seen ever this message? moar: 3rdparty/libuv/src/unix/stream.c:1499: uv_read_start: Assertion `((stream)->io_watcher.fd) >= 0' failed.
Was that 12:40
MasterDuke i just noticed that libuv updated on my machine, looks like the current version is `2017.02.02, Version 1.11.0 (Stable)`, but MoarVM has `2015.12.15, Version 1.8.0 (Stable)`
ah, ok, i just noticed in their changelog something about a bug fix for uv_fs_scandir_next and thought it looked familiar 12:41
m: use Test; is "a".parse-base\ \ (16), 10 12:46
camelia rakudo-moar d5262e: OUTPUTĀ«ok 1 - ā¤Ā»
MasterDuke i get `Too few positionals passed; expected 2 arguments but got 1`
better for roast?
jnthn Yes :) 12:50
MasterDuke jnthn: `unspace can recurse`, is that a sufficient and correct test description? 12:59
jnthn Yeah, I'd say so 13:04
Geth roast: cf59588ddb | (Daniel Green)++ | S02-lexical-conventions/unspace.t
Add a test that unspace can recurse

Some discussion a little before and after here:
  irclog.perlgeek.de/perl6-dev/2017-...i_14042069		 13:09
jnthn rt.perl.org/Ticket/Display.html?id=130716 ended up with a meaty answer, fwiw 15:11
away for a bit 15:13
dogbert17 MasterDuke: as jnthn wrote, it pops up when I run spectest with HARNESS_TYPE=6. 15:25
jnthn, timotimo: does the following gist give any clues wrt the spectest failure (HARNESS_TYPE=6)? gist.github.com/dogbert17/069bf4c7...e3a1a9293a 15:31
timotimo doesn't ring a bell 15:52
Geth roast: 1d5e4c25aa | (Daniel Green)++ | S02-lexical-conventions/unspace.t
Whoops, add missing semi-colon
 16:27
brokenchicken .ask [Coke] BTW is it just a typo on this grant approval page that it says "Test2 Manual" news.perlfoundation.org/2017/01/jan...votes.html ? I just thought... what if that vote was actually for Test2 Manual 17:01
yoleaux2 brokenchicken: I'll pass your message to [Coke].
brokenchicken Which is done by someone else for Perl 5's Test2
IOninja :) 17:12
MasterDuke oooh, should we expect some IO+line coverage related commits soon? 17:14
IOninja In 3-5 weeks. 17:40
Geth rakudo: jonathanstowe++ created pull request #1012:
Sort the binaries by version		 17:42
RabidGravy that had me scratching my head for a few minutes 17:51
there's still the possibility that the script might get the wrong version of the module but I think that's least surprising 17:53
IOninja Kinda overelaborate code... .sort(-> $a { $a<ver> }).reverse[0] -> .sort(*<ver>).[*-1] 17:55
RabidGravy right 17:58
amended thusly 18:01
IOninja RabidGravy++
I know nothing of that area of the code, so I'll wait for someone who does to review and merge :)
TimToady jnthn: putting $*W into the braid worked okay for nqp, but for rakudo turned into a complete mess, so that's gonna stay out for now 18:06
there are just too many routines that have no access to the current cursor
though I suppose some of them could still get at it through some node or other 18:11
but it was getting awful cluttery, so it needs a bit of a rethink on how to access world from anywhere if we eventually go that route 18:12
timotimo maybe eliminating half the lookups via $*W would already help performance a bit? 18:24
TimToady there are a lot of routines that could benefit from my $W := $*W, though why do that when we should fix the dynvar cache? 18:25
not to mention, the compiler should eventually figure out if a routine has multiple refs to the same dynvar as cache its own copy 18:27
*and cache
I mean, that's another possible cache approach, just automatically cache a dynvar in the lexpad of where its used such that multiple uses in this lexpad or in calls further down find this one instead of using up precious frame cache 18:30
though, again, with this scheme we'd probably have to outlaw rebinding of dynvars 18:31
(or invalidate the cache on a rebind, anyway)
I'm guessing we've been lucky not to have been bitten by that in nqp, where we can only rebind...and we just kind of assume that the dynvar cache will catch up at some point 18:34
it's rebinding from deep down that is dangerous, and we avoid that currently by making %*LANG its own namespace 18:35
in other words, %*LANG gets away with it by passing itself around as a container 18:51
jnthn TimToady: Rebinds work OK wiht the current cache, because we cache the pointer to the register where the lexical is stored 18:56
TimToady: So we hold it an extra level of indirection off from the bound value, to rebinds work OK 18:57
We'd be in bother with various things if not :)
OK on leaving $*W out for now
TimToady okay, thanks for the clarification
we could presumably do something similar if we cached in the lexpad of a dynvar user at compile time 18:58
then you could force a shallower level of caching just by mentioning a dynvar 19:00
and a routine would automatically share all its refs to $*W
and the frame cache could be reserved for situations where the lexpad cache doesn't help 19:01
so basically the compiler would throw in a my $*FOO := CALLERS::<$*FOO> at the top of such a routine, only with the extra indirection beyond := (if that's possible) 19:05
(wouldn't need the indirection for SSAish (SSBish?) dynvars, if we ever get 'em) 19:10
jnthn I suspect most folks call what we call binding assignment. 19:49
I'm just a tad uneasy about the extra declaration in so far as it'll probably be introspectable...and yeah, how to handle the LoI 19:50
It does make neat use of lexical storage though
And pre-allocates the space
MasterDuke .ask lizmat given your recent work with .tail(), are there any circumstances where it isn't faster than [*-1]? if not, should we replace all [*-1] in the settings with .tail()? 19:54
yoleaux2 MasterDuke: I'll pass your message to lizmat.
jnthn MasterDuke: Be careful of the small semantic difference when doing so (of course, cases where it's [*-1]:delete or so are clear, but indexing will cache a Seq, while .tail I believe will not) 19:58
(That may mean .tail is a memory improvement in some of those places)
Which is double reason to do it where we can 19:59
MasterDuke jnthn: is that the only difference?
jnthn I think there's also a difference when the thing is empty 20:00
m: dd (gather {}).tail
camelia rakudo-moar d5262e: OUTPUTĀ«Nilā¤Ā»
jnthn m: dd (gather {})[*-1]
camelia rakudo-moar d5262e: OUTPUTĀ«Failure.new(exception => X::OutOfRange.new(what => "Effective index", got => -1, range => "0..^Inf", comment => Any), backtrace => Backtrace.new)ā¤Ā»
jnthn m: my @a = 1,2,3; @a[*-1] = 42; say @a 20:01
camelia rakudo-moar d5262e: OUTPUTĀ«[1 2 42]ā¤Ā»
jnthn m: my @a = 1,2,3; @a.tail = 42; say @a
camelia rakudo-moar d5262e: OUTPUTĀ«[1 2 42]ā¤Ā»
jnthn Seems those two work out the same.
dogbert17 thinks he knows why './perl6-m -Ilib t/harness6 --fudge --tests-from-file=t/spectest.data' fails on his machine
jnthn m: my @a = 1,2,3; @a.head = 42; say @a
camelia rakudo-moar d5262e: OUTPUTĀ«[42 2 3]ā¤Ā»
jnthn Good that's consistent at least :)
m: my @a = 1,2,3; @a.head(2) = 42, 43; say @a 20:02
camelia rakudo-moar d5262e: OUTPUTĀ«Cannot modify an immutable Seqā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
jnthn m: my @a = 1,2,3; @a.head(2).list = 42, 43; say @a
camelia rakudo-moar d5262e: OUTPUTĀ«[42 43 3]ā¤Ā»
jnthn m: my @a = 1,2,3; @a.tail(2).list = 42, 43; say @a
camelia rakudo-moar d5262e: OUTPUTĀ«[1 42 43]ā¤Ā»
jnthn All looks fine :)
MasterDuke cool
jnthn Can't think of anything else :) 20:03
MasterDuke there are only ~12 instances of *-1 in the setting anyway, should be easy to test
jnthn :) 20:04
dogbert17 .oO (spam warning)
[pid 26813] socketpair(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0, [1021, 1022]) = 0
[pid 26813] pipe2(0xb5036b18, O_CLOEXEC) = -1 EMFILE (Too many open files)
[pid 26813] close(1021) = 0
[pid 26813] close(1022) = 0
[pid 26813] write(2, "moar: 3rdparty/libuv/src/unix/st"..., 111) = 111
[pid 26813] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7250000
[pid 26813] rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
[pid 26813] tgkill(24455, 26813, SIGABRT) = 0
[pid 26813] --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=24455, si_uid=1000} ---
[pid 26813] +++ killed by SIGABRT +++
jnthn Think the second line is the money shot... :) 20:05
Wonder if we're failing to close something somewhere :)
That's useful info, anyways
dogbert17++
dogbert17 did you see my gist above? 20:06
might possibly contain more clues
jnthn Yes, I was a bit confused by it 20:07
Because it looks like it's synchronously reading a pipe
But I thought TAP::Harness used Proc::Async everywhere
So will have to dig a bit deeper into that 20:08
oops, forgot something for lunch tomorrow 20:10
grocery hunting & 20:11
timotimo we're also clearly not passing on the EMFILE error
or does it immediately fail thereafter with that assertion and we can't get our foot in between those events? 20:12
dogbert17 it looks like this on stdout: 20:14
t/spec/S32-num/unpolar.t .......................................... ok
moar: 3rdparty/libuv/src/unix/stream.c:1499: uv_read_start: Assertion `((stream)->io_watcher.fd) >= 0' failed.
Aborted
MasterDuke timotimo: there have been several libuv releases since the version we're using, maybe upgrading that would help? 20:16
timotimo could help, but too many open files is a problem that you can't fix just by updating your library :) 20:18
MasterDuke maybe version n+1 comes with a small gremlin to count your open files and close some when it thinks you have too many? could have sworn i saw that in the changelog 20:22
timotimo haha 20:24
MasterDuke eyes his coffee. could it be too good/strong? is that even a thing? 20:25
dogbert17 looking at /proc/$PID/fd it seems as if the number of open sockets grows larger the longer the spectest continues 20:49
the seem to be opened like this (spam warning) 20:50
==31826== Open AF_UNIX socket 27: <unknown>
==31826== at 0x45D6A47: socketpair (socket.S:63)
==31826== by 0x42004AD: uv__make_socketpair (process.c:122)
==31826== by 0x4200719: uv__process_init_stdio (process.c:203)
==31826== by 0x4200E66: uv_spawn (process.c:428)
==31826== by 0x4137A0C: MVM_proc_spawn (procops.c:309)
==31826== by 0x40EB403: MVM_interp_run (interp.c:3821)
==31826== by 0x410C6DC: start_thread (threads.c:77)
==31826== by 0x4206895: uv__thread_start (thread.c:49)
==31826== by 0x46E4F71: start_thread (pthread_create.c:312)
==31826== by 0x45D4F8D: clone (clone.S:129)
geekosaur something to keep in mind: "socketpair" is BSDese for "pipe" 21:00
dogbert17 geekosaur: thx, didn't know that 21:01
timotimo hm, so we spawn all the processes and we never close their shit? 21:10
Geth rakudo: MasterDuke17++ created pull request #1013:
Don't constant fold x op when the result is big		 21:12
MasterDuke with that PR, `my str $a = "a" x 2**29; say $a.chars` goes from 9s to 0.14s for me 21:13
RabidGravy cool 21:16
MasterDuke heh, and max rss (according to time -v) went from 1116364 to 67576 21:19
timotimo maybe someone needs to .slurp-rest(:close) :P 21:21
MasterDuke timotimo++ 21:23
afk again
timotimo just kidding, though 21:27
if that were the case, failing tests wouldn't be noticed, or do we just rely on tap parsing for that? 21:28
Geth rakudo: AlexDaniel++ created pull request #1014:
Better error message for invalid ā€œreturnā€ trait mod
AlexDaniel oh. That's very nice of you, Geth 21:29
dogbert17 dogbert@dogbert-VirtualBox ~/repos/rakudo $ ls -l /proc/32112/fd/ | wc -l 21:42
1022 [seconds before it aborts]
timotimo hahaha 21:46
IOninja AlexDaniel: did you run spectest? 21:50
AlexDaniel IOninja: yes. Is there something wrong with it?
Geth rakudo/nom: acae345d73 | (Aleks-Daniel Jakimenko-Aleksejev)++ | src/Perl6/Grammar.nqp
Better error message for invalid ā€œreturnā€ trait mod

Previously it either complained about a missing block or spewed some internal gibberish. Now it suggests ā€œreturnsā€.
Resolves RT #130712		 21:51
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130712
rakudo/nom: 661a1b3bb2 | (Zoffix Znet)++ | src/Perl6/Grammar.nqp
Merge pull request #1014 from AlexDaniel/lta-returns

Better error message for invalid ā€œreturnā€ trait mod
IOninja AlexDaniel: just wasn't sure whether `return` option would start matching anything that isn't even a trait mod
AlexDaniel to be honest I'm surprised that trait mods are parsed this way 21:54
m: my $x returns Nil;
camelia rakudo-moar d5262e: OUTPUTĀ«5===SORRY!5=== Error while compiling <tmp>ā¤Cannot resolve caller trait_mod:<returns>(Variable, Nil); none of these signatures match:ā¤ (Routine:D $target, Mu:U $type)ā¤at <tmp>:1ā¤Ā»
Geth rakudo/nom: 8878af83fe | (Daniel Green)++ | src/Perl6/Optimizer.nqp
Don't constant fold x op when the result is big

If the resulting string is very large, it can take a long time to encode it on the string heap and then decode it when needed.
Some discussions:
  irclog.perlgeek.de/perl6/2017-02-04#i_14040978
  irclog.perlgeek.de/perl6/2017-02-04#i_14042387
Fixes RT #127972, rt.perl.org/Public/Bug/Display.html?id=127972
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127972
rakudo/nom: cea6a93990 | (Zoffix Znet)++ | src/Perl6/Optimizer.nqp
Merge pull request #1013 from MasterDuke17/dont_constant_fold_infix_x_when_result_is_big

Don't constant fold x op when the result is big
AlexDaniel note that in the snippet above it generally accepts it, but blows up later 21:55
raiph .ask samcv Have you read github.com/apple/swift/blob/master...ifesto.md? 22:04
yoleaux2 raiph: I'll pass your message to samcv.
Geth rakudo: MasterDuke17++ created pull request #1015:
Convert [*-1] to the faster .tail		 23:07
rakudo/nom: ed4ef3b582 | (Daniel Green)++ | 5 files
Convert [*-1] to the faster .tail
 23:39
rakudo/nom: f325eebcd9 | (Zoffix Znet)++ | 5 files
Merge pull request #1015 from MasterDuke17/replace_whatever-1_with_tail

Convert [*-1] to the faster .tail

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!