dalek | ast: 19fa7f3 | labster++ | S03-operators/autoincrement-range.t: Add tests for Thai numeral increments, RT #128868 |
03:04 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128868 | ||
gfldex | .tell lizmat that was the week that was: gist.github.com/gfldex/09e86ebed67...bd2291c083 | 03:36 | |
yoleaux2 | gfldex: I'll pass your message to lizmat. | ||
gfldex | is CREATE an implementation detail? There is a test on roast but it's only a RT. | 04:35 | |
ShimmerFairy | gfldex: if there's a test in roast, and if roast is the spec, then it must be true that it's spec :) | 05:36 | |
[Tux] | This is Rakudo version 2016.07.1-137-gc8c27e9 built on MoarVM version 2016.07-16-g85b6537 | 06:09 | |
test 15.038 | |||
test-t 7.325 | |||
csv-parser 16.356 | |||
my @hdr = $csv.getline ($fh)».lc.map: { s:g{kode} = "code" }; | 07:50 | ||
Cannot modify an immutable Str | |||
my @hdr = $csv.getline ($fh)».lc.map: { s:g{kode} = "code" }; | 07:51 | ||
quick fix? | |||
This works: | 07:55 | ||
my @hdr = $csv.getline ($fh)».lc; | |||
s:g{kode} = "code" for @hdr; | |||
but does not feel perl6-example worthy | |||
pmurias | how do I rebootstrap NQP, I want to get rid of the workaround in afd690d4 | 08:40 | |
? | |||
ahh, found docs for that | |||
gfldex | .tell lizmat gist.github.com/gfldex/09e86ebed67...bd2291c083 has been updated | 10:07 | |
yoleaux2 | gfldex: I'll pass your message to lizmat. | ||
Tux__ | does perl6 have the /r from perl5 as in « my $foo = $bar =~ s/foo/bar/gr;» I did not find something like that on docs.perl6.org/routine/subst | 11:43 | |
ShimmerFairy | Tux__: you want S/// I believe, or .subst() if you'd rather the method version. | 11:44 | |
literal | Tux__: .subst behaves like Perl5's /r already | 11:45 | |
for in-place substitution (like Perl5 without /r) you need .= subst() | |||
Tux__ | { .lc ~~ S:g{kode} = "code" }); | ||
Potential difficulties: | |||
Smartmatch with S/// is not useful. You can use given instead: S/// given $foo | |||
literal | and yeah, s/// vs. S/// for the short forms | 11:46 | |
ShimmerFairy | Tux__: I have no clue why P6 thinks S/// would be useless in smartmatches. | 11:47 | |
Tux__ | { S:g/kode/code/ given .lc }); | 11:49 | |
works fine | |||
ShimmerFairy | like I said, I can't see how the smartmatch form would be considered useless, someone else will have to explain that :) | 11:50 | |
nine | ShimmerFairy: because smart match is an operator that's supposed to return a Boolish value. | 11:51 | |
Using it for applying the substitution would be quite some abuse as it's a totally different operation and result type | |||
ShimmerFairy | nine: Ah, I guess I'm more used to using ~~ // for non-subst regexes, so "it returns the result of match" transferred in my mind to "it returns the result of the substitution", I guess. (For some reason I vastly prefer .subst anyway.) | 11:53 | |
ShimmerFairy still thinks regex matching deserves its own operator, without any of that $_-modifying business, but that's another story :P | |||
nine | ShimmerFairy: understandably. It's just that a match is kind of boolish as you'd get Nil if it doesn't match while S/// would just return the original string. | 11:54 | |
ShimmerFairy | nine: though now I wonder why S/// acts different than s/// in the use of 'given' | 11:56 | |
m: my $a = "foo"; say s/f/b/ given $a; | |||
camelia | rakudo-moar c8c27e: OUTPUT«「f」» | ||
ShimmerFairy | m: my $a = "foo"; say S/f/b/ given $a; | ||
camelia | rakudo-moar c8c27e: OUTPUT«boo» | ||
nine | ShimmerFairy: because s/// is "match the regex and while you're at it modify the matches" while S/// is "change the matching places in the string". So s/// is really two distinct operations for which combining may make sense from an optimization view point. | 12:05 | |
I think, they are actually huffmanized wrong and I consider this to be historical baggage, als Perl 5 had only s/// for most of its life. | 12:06 | ||
ShimmerFairy | .oO(Why do I get the sudden feeling that this is an inconsistency that Perl 7 would target, like the ones Perl 6 did?) |
||
mst | ShimmerFairy: if you've ever used given/when in perl5, your first thought would be "to make perl5 people feel at home, perl6 decided to make given at least -slightly- unexpectedly bollocks" | 12:08 | |
ShimmerFairy | mst: I have not, and I suppose the blame lies more with s/// vs. S/// than the 'given' itself :P | 12:09 | |
Tux__ | I am so used to s{foo}{bar} in perl5, that this by now is one of the most common mistakes I make in perl6 | 12:14 | |
S:g{foo}{bar} is wrong | |||
Unsupported use of brackets around replacement; in Perl 6 please use assignment syntax | |||
unmatched} | ShimmerFairy: just use .subst/.subst-mutate | 12:18 | |
The smartmatch with S/// not being useful is become smartmatch aliases the given string to $_, S/// makes substitutions on it and returns the result, and then THAT result is compared against the original string and you get True or False, based on whether there were any substitutions (True indicating there weren't). So there's no way to get the result of the substitution and you get a confusing, nearly | 12:20 | ||
useless result from the smartmatch | |||
s/become/because/; | |||
as for difference between s/// and S/// with given... The snarky response would be that they do different things :) s/// mutates, so there's no point in returning the new result; what matches are returned instead. S/// is non-mutating, so returning the new version is all it can do. | 12:22 | ||
Tux__ | unmatched}++ thanks | 12:50 | |
lizmat | . | 13:11 | |
yoleaux2 | 03:36Z <gfldex> lizmat: that was the week that was: gist.github.com/gfldex/09e86ebed67...bd2291c083 | ||
10:08Z <gfldex> lizmat: gist.github.com/gfldex/09e86ebed67...bd2291c083 has been updated | |||
lizmat | gfldex++ | 13:27 | |
dalek | p: d5cbe8f | (Pawel Murias)++ | src/NQP/Actions.nqp: [js] Extend workaround to JS backend. |
13:39 | |
p: cb2b853 | (Pawel Murias)++ | src/vm/js/bin/run_tests_bootstrapped.pl: [js] Update "make js-test-bootstrapped". Make it skip the failing test and more tests that pass. |
|||
p: ddf5def | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp: [js] Don't emit an unnecessary cast from an integer attribute to an integer. |
|||
[Coke] | RT: 1331; @LARRY: 13; CONC: 24; GLR: 6; JVM: 66; LHF: 1; LTA: 103; NEW: 859; NYI: 82; OSX: 6; PERF: 20; POD: 17; PRECOMP: 9; RFC: 28; SEGV: 31; STAR: 4; TESTNEEDED: 15; TODO: 9; UNI: 27; UNTAGGED: 518; WEIRD: 3 | 14:43 | |
unmatched} | buggable: rt | 14:49 | |
buggable | unmatched}, TOTAL: 1390, UNTAGGED: 600, BUG: 425, LTA: 98, JVM: 62, NYI: 35, SEGV: 30, RFC: 28, UNI: 26, CONC: 24, PERF: 20, POD: 14, @LARRY: 14, PRECOMP: 9, TODO: 9, GLR: 6, BUILD: 5, STAR: 4, NATIVECALL: 4, WEIRD: 3, BOOTSTRAP: 3, MOARVM: 2, OSX: 2, LHF: 1, SPESH: 1, DOCS: 1, MATH: 1 Details: bug.perl6.party/1470667763.html | ||
unmatched} | 1390 0.o wat | ||
jnthn | Also UNTAGGED | ||
unmatched} | Ah. There's a bug. | ||
jnthn | [Coke]++ # human buggable still winning :D | 14:50 | |
unmatched} | A bug in a bot reporting bugs :) | ||
jnthn | Bugception | ||
[Coke] reported the UNTAGGED bug. | 14:52 | ||
also, mine is realtime, while buggable's is based on cached. | |||
[Coke] wonders if we shoudl get rid of stresstest and make everything run on spectest. | 14:53 | ||
(since we need to be more careful post-christmas) | |||
unmatched} | Would we need to install panda and Inline::Perl5 for every run? | 14:54 | |
*re-install that is | |||
dalek | ast: 2d54245 | lizmat++ | S03-operators/autoincrement-range.t: We must still comment out RT :-) |
||
ast: b1ee76d | lizmat++ | S32-array/splice.t: Remove SINK tests, they're an implementation detail |
|||
[Coke] | unmatched}: those tests are skipped whether you run stress or spec. | ||
really, we should be installing it and testing it regularly. | |||
(since we kind of advertise that they work when we do a release) | |||
unmatched} | They do get run on before every release. And I run them 1 week before the release too. | 14:55 | |
dalek | ast/6.c-errata: f93adc5 | lizmat++ | S32-array/splice.t: Remove SINK tests, they're an implementation detail |
14:56 | |
unmatched} | I'd push the other way, TBH. Run fewer tests on changes, run more tests regularly (Travis? Some build job daily?), run all tests before releases and maybe weekly. | 14:57 | |
Well, I guess an automated job can run all tests if it wants. I rather the devs don't sit there for 8 minutes waiting for spectest to finish for every bug they fix. | |||
[Coke] | eh. Ideally we'd want every commit to nom to match a version in roast, and pass all those tests. | 14:58 | |
dalek | kudo/nom: a44a13d | lizmat++ | / (8 files): Remove any reference to :SINK We're probably going to do this differently in the future anyway. Then we'll look at optimization opportunities again. So don't spend any extra cycles on it now. |
||
[Coke] | unmatched}: I disagree - how do you know you fixed it and didn't bust something else? push it into a branch if you're not sure or if it needs review. | ||
dalek | p: 01dfb1a | (Pawel Murias)++ | src/QAST/Regex.nqp: Make --target=ast mention cursor_type on QAST::Regexes. |
||
p: 2f9c5d5 | (Pawel Murias)++ | src/ (2 files): Set the cursor_type for all regexes compiled by NQP. |
|||
TimToady | I go find something else to do while testing | ||
[Coke] | I think that's the long term plan; push things into branch, pull them into nom when they're tested/approved. we're just operating at slightly better than pre-christmas review-process at this point. | 14:59 | |
I think our process is ok for now, but we definitely want to harden it before v6.d | 15:01 | ||
travis-ci | NQP build failed. Pawel Murias 'Set the cursor_type for all regexes compiled by NQP.' | 15:03 | |
travis-ci.org/perl6/nqp/builds/150658485 github.com/perl6/nqp/compare/ddf5d...9c5d5a6a9c | |||
pmurias checks the travis build failure | |||
[Coke] | unmatched}: rt.perl.org/Ticket/Display.html?id=126447 - there are still skip'd tests with this # in roast; do they need to be migrated to the new ticket number? | 15:05 | |
unmatched} | [Coke]: by running the test I wrote for the bug and the sparse set of tests that test a little bit of everything. Then I push, and travis (or whatever) goes on to run the full set of tests, while I move on with my life. If it's some major change, I'll run the full spectest before pushing. It's speeds up development and should the commit break on more thorough spectest, it'll be known fairly soon to fix it. | 15:08 | |
TimToady's plan to "find something else to do" is by far not ideal, as the developers get distracted from the job at hand. | |||
dalek | ast: 0ec9781 | (Zoffix Znet)++ | S04-blocks-and-statements/temp.t: Update RT ticket number for the issue |
15:11 | |
lizmat wonders whether TimToady's remark is related to a44a13d ? | |||
unmatched} | [Coke]: updated, thanks. | 15:13 | |
dalek | p: d68b9b3 | (Pawel Murias)++ | src/NQP/Actions.nqp: Fix 2f9c5d5a6a9c1b0243fd59a7b827ad1f99d113c |
||
pmurias | automatically checking that NQP changes don't break rakudo would be great | 15:17 | |
travis-ci | NQP build passed. Pawel Murias 'Fix 2f9c5d5a6a9c1b0243fd59a7b827ad1f99d113c' | ||
travis-ci.org/perl6/nqp/builds/150662765 github.com/perl6/nqp/compare/2f9c5...8b9b375f7b | |||
[Coke] | unmatched}: right, so instead of pushing to nom, you push that somewhere else, something does the full test run, -then- it gets merged to nom when it's clean. best of both worlds. | 15:18 | |
timotimo | we already have smoke-me, don't we? | ||
[Coke] | right. jnthn postulated some kind of infrastructure that was smart enough to do the merges, even, once they were clean. | 15:20 | |
timotimo | i'm sure zoffix can build an irc bot that does that | 15:21 | |
[Coke] | (not saying we have to jump to this now, just want people to be thinking about it) | ||
japhb | [Coke]: That would be a lot easier in a world with no remaining flaky tests. And a CI system that didn't time out quite so easily. :-/ | 15:27 | |
[Coke] | japhb: aye | 15:29 | |
[Coke] did a preliminary cleanup of an auto-unfudge run and left the results here: gist.github.com/coke/c7c6ae1448509...5f68d84618 | |||
for me, all those unfudgings pass. Someone can review them and clean up the tickets they are tied to (maybe). | 15:30 | ||
I'll plan on doing it tonight if no one beats me. | |||
Tux__ | Does perl6 also offers a formatted dd, more or less like perl5's Data::Dumper? *I* already understand dd's output, but for three-level-deep hashes, the output is not suitable for a presentation | 15:32 | |
timotimo | no, only as separate modules | 15:33 | |
Tux__ | any suggestion? | 15:34 | |
unmatched} | Data::Dump::Tree I heard is good | ||
timotimo | yeah, it's pretty | ||
Tux__ | modules.perl6.org/#q=dump | 15:35 | |
dalek | kudo/nom: 44a90a8 | (Zoffix Znet)++ | src/core/Exception.pm: Improve not-found module message - Detect when the user may have been attempting to use :from adverb - Fixes RT#126087 |
15:47 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126087 | ||
unmatched} | While we're on the topic of tests. We need some plan for (a) tests for compiler niceties that don't need to be in the spec, like sink warnings and super helpful error messages (like the above); and (b) internationalization. | 15:50 | |
(a) is pretty easy. Where would such tests go? Just somewhere in Rakudo's t/? | 15:51 | ||
For (b)... I just notice we have a whole bunch of tests in roast that test for English-language messages. What if (when?) we want to translate to Japaneese or Russian? Seems like such tests should take the message content from some separate place, so that we could run the roast in another language, by just changing that one "database" of messages. | 15:52 | ||
jnthn | Or we just force the language to English when running spectest. :) | 15:57 | |
Part of the reason for typed exceptions is to reduce the dependence on that, though. | |||
travis-ci | Rakudo build failed. Elizabeth Mattijsen 'Remove any reference to :SINK | ||
travis-ci.org/rakudo/rakudo/builds/150658407 github.com/rakudo/rakudo/compare/c...4a13de523c | |||
unmatched} | :o ...buggable... | 15:58 | |
TimToady | it's a shame we can't test error messages for concepts rather than specific words | 15:59 | |
unmatched} | travis-ci.org/rakudo/rakudo/builds/150658407 | 16:00 | |
travis-ci.org/rakudo/rakudo/builds/150658407 | 16:03 | ||
Aha.. "Killed" | 16:04 | ||
Looks like parsing JSON for 4 build logs uses more than 2GB RAM or whatever. | |||
Oh :o It's actually due to the regex match on, what I'm guessing, is a huge chunk of text | 16:12 | ||
m: gist.github.com/zoffixznet/3633c5a...7ecffa1a9a | 16:20 | ||
Reached 4GB before I killed it on my home box | |||
camelia | rakudo-moar 44a90a: OUTPUT«Memory allocation failed; could not allocate 387864 bytes» | ||
lizmat | afk& | ||
timotimo | but why would that allocate much? | 16:21 | |
unmatched} | Should I rakudobug this? | 16:23 | |
timotimo | can you try dropping the :i? | ||
and see if that makes it not allocate a bunch? | |||
jdv79 | [Coke]: should #128833 be "[CONC] [SEGV]"? might be a dup but i can't be certain. | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128833 | ||
unmatched} | timotimo: yeah, then it returns fast with 'False' | 16:24 | |
timotimo | OK, so it's doign something dumb when ignorecase is in there | ||
maybe it's a problem with INTERPOLATE or CONSTANT? | |||
no, it's called LITERAL | 16:26 | ||
unmatched} | travis-ci.org/rakudo/rakudo/builds/150658407 | 16:30 | |
buggable | unmatched}, 4 builds failed. NONE due to the timeout | ||
unmatched} | There... fixed forever. | 16:31 | |
[Coke] | jdv79: sure, changed. | 16:33 | |
unmatched} | Rakudobugged: rt.perl.org/Ticket/Display.html?id=128873 | 16:35 | |
jdv79 | thanks | 16:36 | |
b2gills | m: say 'ac' ~~ {S/a/b/} | 17:01 | |
camelia | rakudo-moar 44a90a: OUTPUT«bc» | ||
unmatched} | hax | 17:05 | |
dalek | p: 04c4ae3 | TimToady++ | src/QAST/Node.nqp: forgot to remove some scaffolding |
17:11 | |
TimToady | b2gills++ | 17:13 | |
unmatched} | Actually, I don't entirely follow b2gills's thing. S/// is a callable and so is {S///}, so why isn't the {S///} result gets smartmatched against the given string? | 17:20 | |
TimToady | if you smartmatch with a closure, it assumes the result is to be interpreted as boolean | 17:22 | |
we don't smartmatch recursively | |||
unmatched} | k, I think I get it | 17:23 | |
dalek | kudo/nom: d1c8664 | (Zoffix Znet)++ | src/core/Exception.pm: Trim whitespace around announced operator in error message Fixes RT#126219 |
17:44 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126219 | ||
unmatched} | AlexDaniel seems to be the Zefram of error messages... | 17:50 | |
Like this one rt.perl.org/Ticket/Display.html?id...et-history | 17:52 | ||
dalek | ast: 4e973da | (Zoffix Znet)++ | S03-operators/autoincrement.t: ++.++ construct throws a multi no match exception RT#126220 |
18:07 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126220 | ||
unmatched} | Stage parse is now at 55.005s on my google box... used to be 45s :/ | 19:21 | |
dalek | kudo/nom: fb42520 | (Zoffix Znet)++ | src/core/Mu.pm: Reword undefined stringification warning - Avoid use of word "Any" to prevent confusion with the Any type - Avoid nondescript term "undefined things" - Fixes RT#126215 |
19:28 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126215 | ||
hoelzro | j | 19:33 | |
unmatched} | k | ||
hoelzro | ugh | ||
every time my SSH connection drops | |||
unmatched} | :) | ||
m: my %h = foo => 'bar'; { temp %h<foo> = 'meow'; %h<not-foo> = 42; }; say %h | 19:41 | ||
camelia | rakudo-moar d1c866: OUTPUT«{foo => bar, not-foo => 42}» | ||
unmatched} | TimToady / jnthn ^ is the above a bug or just a limitation we have to live with? The fact that "not-foo" key ended up in %h after temp. It's in a ticket, but Sam just replied saying fixing it would be quite problematic with our current container stuff rt.perl.org/Ticket/Display.html?id=128544 | 19:43 | |
m: my %h = foo => 'bar'; { temp %h; %h<foo> = 'meow'; %h<not-foo> = 42; }; say %h | |||
camelia | rakudo-moar d1c866: OUTPUT«{foo => bar}» | ||
TimToady | that all looks perfectly correct to me | 19:44 | |
unmatched} | Cool. I'll then reject the ticket and dump the bogus spectest that was added for it | ||
TimToady | m: my %h = foo => 'bar'; { (temp %h)<foo> = 'meow'; %h<not-foo> = 42; }; say %h | ||
camelia | rakudo-moar d1c866: OUTPUT«{foo => bar}» | ||
[Coke] | TimToady++ | 19:46 | |
TimToady | temp is not a declarator; it's just a strange prefix | ||
so it's gonna temporize whatever the operator governs | |||
lizmat | well, there's one edge case here, that I think also has been ticketed already | 19:47 | |
m: my %h; { temp %h<a> = 42 }; dd %h | 19:48 | ||
camelia | rakudo-moar d1c866: OUTPUT«Hash %h = {:a(Any)}» | ||
lizmat | m: my %h; { temp %h<a> = 42 }; dd %h | ||
camelia | rakudo-moar d1c866: OUTPUT«Hash %h = {:a(Any)}» | ||
lizmat | aka, it leaves a key behind | ||
TimToady | now that one, I have no idea how/whether to fix | 19:49 | |
you'd almost need a :temp adverb instead of a prefix | |||
lizmat | yeah, I was thinking we could do something with $!whence | ||
hmmm... adverb hmmm | 19:50 | ||
TimToady | it's really the same issue as :exists and :delete, you've already lost track of the key by the time the container is returned | ||
perlpilot | weird ... I was just doing an analogous thing in P5 with local. | 19:51 | |
TimToady | p5 treats exists and delete as a little macro-y | ||
gfldex | is there a way to bail out of the temp-behaviour? | 19:52 | |
TimToady | nothing except 'let' | ||
perlpilot | gfldex: sounds like you want let | ||
gfldex | let kinda does that. I was thinking about having some cow mechanism where you can choose to merge by hand before leaving the block. | 19:54 | |
lizmat | And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/08/08/...uiet-week/ | 19:57 | |
timotimo | bisectable: help | 20:06 | |
bisectable | timotimo: Like this: bisectable: good=2015.12 bad=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # RT128181 | ||
timotimo | bisectable: run('perl6', '--profile=heap', '-e', 'say "hi"') | 20:07 | |
bisectable | timotimo: Exit code is 0 on both starting points (good=2015.12 bad=d1c8664), bisecting by using the output | ||
timotimo: bisect log: gist.github.com/42d871c86527288169...7249e122e7 | |||
timotimo: (2015-12-25) github.com/rakudo/rakudo/commit/07fecb5 | |||
timotimo | damn you, restricted setting | ||
MasterDuke | timotimo: i'm not quite sure how to do it, but AlexDaniel could run the bisect manually for you | 20:17 | |
jnthn | TimToady: fwiw, I've not been able to come up with any kind of way to fix the "temp auto-vivifies" thing. temp's working is pretty much orthogonal to ownership. | 20:28 | |
It doesn't have a way to know it's a Scalar that just happens to be under a certain key in a container. And due to binding it may live in many containers. | 20:29 | ||
So there's really not much to do about it. | |||
timotimo | it looks like the crazy allocation amount that the regex match against the long string zoffix posted is completely invisibel to both the profiler and the heap analyzer | 20:30 | |
jnthn | massif? | 20:31 | |
timotimo | 21.89user 1.60system 0:23.49elapsed 100%CPU (0avgtext+0avgdata 7801116maxresident)k | 20:32 | |
jnthn | lizmat++ # weekly | ||
timotimo | could it be the backtrack stack or something just grows without bound in this situation? | ||
jnthn | I like how a quiet week still has quite a lot going on ;) | ||
timotimo | that's one way we'd not get any GCs and such | ||
jnthn | timotimo: Maybe but the heap profiler knows about the size of a VMArray? | 20:33 | |
And it forces a GC at the end to make sure it gets a snapshot | |||
Could stick an nqp::force_gc in the regex in a block also to see if that gives any clues | 20:34 | ||
timotimo | hm. but at the end that VMArray in question has got to be garbage? | ||
jnthn | True, thus why to try sticking it in the regex somewhere :) | 20:35 | |
timotimo | the only place i can put it is in the very front | ||
because even the first literal string doesn't occur inside the string to search for | 20:36 | ||
though i can make that happen | |||
because i control the string :) | |||
my prodding must have missed it, as it's only 35 megabytes in the final and the in-the-middle snapshots | 20:40 | ||
i bet it was because the "scan" succeeded when it reached that block that forced the gc | 20:46 | ||
ZoffixMobile | #834 kinda makes me think we should be improving flat rather than adding another method that sorta-kinda-similar | 21:09 | |
lizmat | yeah, I have my doubts about descend as well | ||
timotimo | why does string_equal_at_ignore_case use lc and not fc? | 21:13 | |
lizmat | hysterical raisins ? | ||
timotimo | perhaps | 21:14 | |
gfldex | using fc would break german | 21:15 | |
m: say "in Massen".fc ~~ "in Maßen".fc | |||
camelia | rakudo-moar fb4252: OUTPUT«True» | ||
gfldex | that means that "a lot" is the same as "in moderation" | 21:16 | |
ZoffixMobile | :) | ||
timotimo | anyway, equal_at_ignore_case is absolutely pessimal. | ||
not only do we not have a proper scan (based on the floyd-warshal algorithm) for ignorecase, no, we also re-lc the haystack every single time we try to do a match | 21:17 | ||
and if we advance one character before trying again, we'll have one "lower case the whole string" operation per grapheme in the string | |||
ZoffixMobile | :o | 21:18 | |
gfldex | slowest possible way to implement it? | ||
timotimo | yes | 21:19 | |
we already have an offset and length for comparison | |||
lizmat | .oO( room for optimisations ) |
||
timotimo | and still we just lc both the haystack and the needle before comparing at the offset for the length | 21:20 | |
so ... that's bad :) | |||
[Coke] | There was a ticket at one point for foldcaseing for insensitive matching instead of lc'ing | 21:21 | |
m: say "Massen".fc | |||
camelia | rakudo-moar fb4252: OUTPUT«massen» | ||
[Coke] | say .lc, .fc for "in Maßen" | 21:22 | |
m: say .lc, .fc for "in Maßen" | |||
camelia | rakudo-moar fb4252: OUTPUT«in maßenin massen» | ||
ZoffixMobile | The issue gfldex brought up still exists with fc | ||
oh | |||
gfldex | the issue with fc wont go away. It a unicode dilemma. | 21:23 | |
[Coke] | I mean, I get that's wrong, but is it an issue with .fc, or with unicode? | ||
gfldex++ | |||
gfldex | shortly after 1900 some american defined a transcription for ß to be used with typewriters _without_ asking a german for advice. | 21:24 | |
lizmat | good night, #perl6-dev! | ||
ZoffixMobile | night | 21:25 | |
jnthn | timotimo: Nice find. I'm an order of magnitude too tired to know what best to do about it though... ;) | 21:27 | |
timotimo | well, the regex machine could know about needing the lower case version of the target string and keep it around once | 21:29 | |
that'd already make a gigantic difference | |||
and the needle can also just be lowercased for the user when we generate the QAST | |||
jnthn | TimToady: I'd kinda like to fix up the async socket test flappiness with some of my tuits available this week; if you've a moment to look over gist.github.com/jnthn/ec19c88a592c...41953ad25a and offer any thoughts, it'd be appreciated. Even if they're just "do what you think" :) | 21:30 | |
TimToady | do what you think :) | 21:36 | |
jnthn | OK :) | ||
.oO( What if I'm not sure what to think 'cus I can argue it too many ways? :) ) |
|||
TimToady | I did like the gather/take analogy | 21:37 | |
I don't suppose we await a sunk promise currently... | |||
jnthn | No | 21:38 | |
That is vaguely tempting though I dunno how strong a back-compat policy bustage it'd be... | |||
TimToady | or keep a list of all sunk promises and await them on scope exit | 21:39 | |
that'd be slightly gentler | |||
jnthn | Yeah...also a bit trickier to arrange | ||
Since potentially any scope that sinks is affected. | 21:40 | ||
TimToady | another possible approach would be a different category of self-awaiting-when-sunk promises | ||
just thinkin' out loud... | 21:41 | ||
nap & | 21:43 | ||
jnthn | Possibly... Then we'd need a policy on what built-in things returned 'em :) |