AlexDaniel` I just stumbled upon this: raid6.com.au/~onlyjob/posts/arena/ (on perl5 subreddit) 00:22
and here's my take on rewriting the perl5 solution in perl6: gist.github.com/AlexDaniel/baae3c4...17aaab1f2b 00:23
using `str` halves the run time, I wonder though if it affects anything else functionally
first three lines for perl5: 0sec 2sec 6sec 00:24
and using rakudo: 14sec 52sec 112sec
better than python3??? 00:25
hold on…
no, definitely not: 2sec 8sec 20sec 00:27
anyway, maybe some optimization wizards want to take a look at this :)
japhb Judging by the timestamps on the comments on that benchmark page, this was from 2011. I suspect all the other languages (including python3) got faster in the interim. 00:33
timotimo i do believe AlexDaniel knows to run these benchmarks on the same machine 00:38
yeah, this runs for a couple of minutes ...
AlexDaniel` I didn't even wait for it to finish 00:39
timotimo 11sec 42sec 90sec 158sec 244sec 349sec 474sec 00:40
m: say <11sec 42sec 90sec 158sec 244sec 349sec 474sec>.subst("sec", "")
camelia 11 42sec 90sec 158sec 244sec 349sec 474sec
timotimo m: say <11sec 42sec 90sec 158sec 244sec 349sec 474sec>.subst(/sec/, "")
camelia 11 42sec 90sec 158sec 244sec 349sec 474sec
timotimo mhh?
m: say <11sec 42sec 90sec 158sec 244sec 349sec 474sec>.Str.subst(/sec/, "")
camelia 11 42sec 90sec 158sec 244sec 349sec 474sec
timotimo oh, :g, yeah
m: say <11sec 42sec 90sec 158sec 244sec 349sec 474sec>.Str.subst(/sec/, "", :g)
camelia 11 42 90 158 244 349 474
timotimo m: say (<11sec 42sec 90sec 158sec 244sec 349sec 474sec>.Str.subst(/sec/, "", :g))>>.Int Z/ (256, 512 ... *) 00:41
camelia Cannot convert string to number: trailing characters after number in '0311⏏5 42 90 158 244 349 474' (indicated by ⏏)
in block <unit> at <tmp> line 1
timotimo m: say (<11sec 42sec 90sec 158sec 244sec 349sec 474sec>.>>.subst(/sec/, "", :g))>>.Int Z/ (256, 512 ... *)
camelia (0.042969 0.082031 0.117188 0.154297 0.190625 0.227214 0.264509)
timotimo what's that, quadratic growth?
m: say (<11sec 42sec 90sec 158sec 244sec 349sec 474sec>.>>.subst(/sec/, "", :g))>>.Int Z/ (256, 512 ... *) Z/ (1, 2, 3 ... *) 00:42
camelia (0.042969 0.041016 0.039063 0.038574 0.038125 0.037869 0.037787)
timotimo my brain definitely can't maths right now, but that looks linear?
AlexDaniel` yea, it's aproximately linear 00:43
AlexDaniel` can't do spelling right now
timotimo m: say (<11sec 42sec 90sec 158sec 244sec 349sec 474sec 616sec 776sec>.>>.subst(/sec/, "", :g))>>.Int Z/ (256, 512 ... *) Z/ (1, 2, 3 ... *)
camelia (0.042969 0.041016 0.039063 0.038574 0.038125 0.037869 0.037787 0.037598 0.037423)
timotimo this is taking looooong %) 00:52
m: say (<11sec 42sec 90sec 158sec 244sec 349sec 474sec 616sec 776sec 955 1151>.>>.subst(/sec/, "", :g))>>.Int Z/ (256, 512 ... *) Z/ (1, 2, 3 ... *)
camelia (0.042969 0.041016 0.039063 0.038574 0.038125 0.037869 0.037787 0.037598 0.037423 0.037305 0.037158)
timotimo it's at like 5 gigs at the moment, 3072k so far 00:53
*shrug* i restarted it for 1 meg %) 00:54
SETTING::src/core/Str.pm6:1187 has the #1 spot, extremely closely followed by gen/moar/stage2/QRegex.nqp:1426 (!cursor_init 00:58
) and then SETTING::src/core/Str.pm6:1182 00:59
the first two at 37.3% and 37.12% respectively, the third at 19.52%
not sure why List.pm6's ACCEPTS is called as often as the other things 01:01
and where does it get dispatch:<!>? 01:02
ah, APPLY-MATCHES
bedtime 01:03
japhb timotimo: I wasn't assuming AlexDaniel` didn't know how to benchmark. I was commenting that the original conclusions may be incorrect because relative values had changed (e.g. I doubt that perl5 still holds a clear win). Badly worded, sorry about that. 01:37
samcv i got to 2304kb and it was using about 12GB of ram (well i know my system was using 15/15.6GB of ram) so using at least 9GB 06:26
also i seem to be coming up with 36% of the cpu going to MVM's hashing function. but i'm not sure what would be hashing that often 08:25
lizmat Files=1237, Tests=76255, 308 wallclock secs (14.69 usr 5.30 sys + 2120.90 cusr 204.81 csys = 2345.70 CPU)
samcv i'm guessing it must be the changing string or something else?
not sure why this is using hashes gist.githubusercontent.com/AlexDan...178/foo.p6 08:26
or maybe i'm reading it wrong. trying a new gui 08:31
and weirder it seems to show that collapse_strands is calling MVM_string_compute_hash?? 08:49
i.imgur.com/cPLsGgC.png 08:50
lizmat that feels weird 08:51
samcv i'm using perf record -g --call-graph dwarf 08:52
Geth rakudo: 5bab5865c9 | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm6
Streamline queue selection logic
 09:14
samcv lizmat: i seem to have gotten it working. going to try and see what change i made fixed it 09:15
lizmat cool! samcv++
Geth rakudo: 8e2ee64e48 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Streamline Hash.BIND-KEY a bit

Both normal and object hashes		 09:32
samcv lizmat: i needed the -a option --all-cpus 09:34
the hash function is still 6% cpu hmm. but i will focus on other things 09:38
lizmat I guess the question is really: why ? right?
samcv yeah 09:39
timotimo on my end it's 72.5% iterate_gi_into_string and 18.95% copy_to_32bit 09:51
samcv timotimo: what compiler and options 10:03
timotimo: also i am only running it a short period of time. maybe it changes the longer it goes 10:04
timotimo just the regular --optimize=3 --debug=3
samcv and gcc?
|Tux| Rakudo version 2018.03-110-g8e2ee64e4 - MoarVM version 2018.03-31-gfdb5e4d6b
csv-ip5xs0.891 - 0.922
csv-ip5xs-208.820 - 8.911
csv-parser36.607 - 37.247
csv-test-xs-200.479 - 0.508
test9.036 - 9.119
test-t2.484 - 2.597
test-t --race1.018 - 1.056
test-t-2043.574 - 44.007
test-t-20 --race14.729 - 16.729
 10:05
samcv timotimo: and how long were you running it?
timotimo yes
timotimo up to 1 meg
that is a wide gap today between the two runs
timotimo samcv: this copy_to_32bit part is the piece extracted from string_join, fwiw 10:07
samcv yeah
i got a lot of that too
it just ends up copying the string around all day long
timotimo btw, we call string_indexing_optimized a bunch, because this uses regex 10:08
so whatever benefit we have from ropes gets flushed down the drain :)
i'm not entirely sure why we'd build a 32bit grapheme string here, all that's in there is letters a through h and _ 10:11
samcv well join calls it 10:12
err the copying as well
well join only builds 32 bit strings if it iterates it. and it does that unless all of the pieces are strands already and under a certain amount
of strands and over an average number of graphemes per strand 10:13
and i'm guessing they may not all be strands
i had thought about fixing that so it would compose strands, but that was gonna be a lot of work
timotimo it'd be a benefit already if it made 8bit grapheme strings instead, wouldn't it? 10:14
samcv yeah
that's faster
AlexDaniel fwiw you can also try running it without nativestrs 10:17
to see what changes 10:18
(it's twice slower this way though)
timotimo the only difference is that non-nativestr will create an extra Str object to contain the underlying string
samcv AlexDaniel: that's not going to help. i just tested 10:31
all of the join's involve sections which have a 32 bit section
well practically all after after initialization 10:32
well literally all after the first few moments
timotimo OK, what gives us the 32bit part that infects everything? 10:33
samcv no clue. but changing that won't make it tons faster anyway
maybe 25% less cpu in the sections where we iterate it. but doesn't solve the underlying issue 10:34
Geth rakudo: 29b7f464e6 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Don't use private method for AT-KEY-CONTAINER

  - avoid the runtime lookup of dispatch:<!>
  - rename it to AT_KEY_CONTAINER to mark its privateness
  - should improve some Hash heavy applications
jnthn Hm, does that really involve runtime lookup? 10:36
I know private method calls in roles can, but that's entirely within the class...
lizmat ok, lemme double check that then
samcv what i need to do is have it concat instead of iterating every single time. so it can concat strings of different types 10:37
i'll work on that tomorrow 10:38
lizmat m: class A { method a() { self.b }; method b {} }; A.a for ^10000000; say now - INIT now 10:43
camelia 0.78767999
lizmat m: class A { method a() { self!b }; method !b {} }; A.a for ^10000000; say now - INIT now
camelia 0.84327224
lizmat there *is* a difference still
m: class A { method a() { self.b }; method b {} }; A.a for ^10000000; say now - INIT now 10:46
camelia 0.7832884
lizmat m: class A { method a() { self!b }; method !b {} }; A.a for ^10000000; say now - INIT now
camelia 0.8091301
lizmat must be something at nqp level, as the --profile output are identical 10:47
jnthn Pretty close, but yeah, small difference. I wonder why. 10:48
dogbert2 jnthn: I get the following message when running AlexDaniel's Cro+Digest::SHA256 SEGV example on a 32-bit box 11:10
Cannot locate symbol 'SSL_CTX_set_alpn_protos' in native library 'libssl.so'
does that mean that my ssllibs are too old or is there another problem here? 11:11
i.e. this code github.com/rakudo/rakudo/issues/1660 11:12
jnthn Yes, though we try to support pre-ALPN versions too 11:14
But perhaps missed a check somewhere
dogbert2 jnthn: gist.github.com/dogbert17/6648129d...6d6a0cb755 11:16
perhaps that gives a clue. let me know if you want it reported somewhere 11:17
timotimo samcv: but every time around the loop it does a regex match, which forces strand collapse 11:40
samcv timotimo: yes that is true. but still a lot of cpu usage also relates to join as well. not saying what you are mentioning doesn't factor in 11:42
timotimo OK 11:46
samcv if i don't collapse strands it takes 19.8 seconds to get to 256kb 11:47
timotimo and if you do?
i get to 256 in 11s, so it doesn't compare :S
samcv 12 seconds 11:49
timotimo oh, huh, so collapsing strands here is worth a lot
samcv also it's always collapsing strands of length 2
timotimo it's forced to collapse them very soon, right? 11:50
so there's not too much we can do
samcv no that's with it disabled
or enabled
timotimo oh, huh?
samcv it flattens inside join i'm guessing
then concats
then flattens
something like that not 100% sure
but if i make collapse_strands just return the string unchanged and print out the number of strands it started with. it's always 2 11:51
except for the very beginning
if i enable collapse_strands it's still 2
32bit ~ 8bit it seems like. well the first strand is 32 bit and the second is 8 bit in collapse_strands 11:57
Geth rakudo: 1fff4f106a | (Zoffix Znet)++ | .gitignore
Ignore gen/nqp-version file
 12:47
nine Zoffix: why don't we ignore the whole gen directory? We ignore src/gen so it looks like when gen was moved out of src, we just didn't update .gitignore 12:48
yoleaux 27 Mar 2018 14:54Z <ggoebel> nine: how to get the output of a command when using nmake... (stackoverflow.com/questions/488302...oft-nmake)
27 Mar 2018 22:54Z <Zoffix> nine: would you be able to take a look at this Issue? Does the path it's trying to slurp look right? with the "perl#sources" stuff in it? github.com/rakudo/rakudo/issues/1662
Geth rakudo: 68a576e62e | (Zoffix Znet)++ | .gitignore
Ignore whole /gen

  irclog.perlgeek.de/perl6-dev/2018-...i_15975687		 12:50
Zoffix FWIW, got a hang on (what looks like) t/spec/S17-supply/syntax.t while stresstesting 12:58
second run got through OK.. 13:01
ZOFVM: Files=1279, Tests=153178, 147 wallclock secs (21.29 usr 3.27 sys + 3140.29 cusr 161.46 csys = 3326.31 CPU)
hm, that time is skewed, I didn't have Inline::Perl5 installed 13:04
ran t/spec/S17-supply/syntax.t a few times, no hangs 13:07
ZOFVM: Files=1292, Tests=153265, 147 wallclock secs (20.98 usr 3.30 sys + 3160.78 cusr 161.99 csys = 3347.05 CPU)
AlexDaniel it did hang for me previously I think 13:09
there was this one file that did that… I think this was it
I wonder if we have a ticket for it already
o no it was t/spec/S07-hyperrace/basics.t 13:10
R#1529
synopsebot R#1529 [open]: github.com/rakudo/rakudo/issues/1529 [severe] Spectest sometimes gets stuck on t/spec/S07-hyperrace/basics.t
Geth rakudo/fails-like: 4abfd4ca5e | (Zoffix Znet)++ | 2 files
Implement fails-like routine in Test.pm6

Same as throws-like, except checks the code returns an armed Failure.
Failures are a ubiquitous feature of the language, yet there's no convenient way to test for them:
... (8 more lines)		 13:15
rakudo: zoffixznet++ created pull request #1664:
Implement fails-like routine in Test.pm6
samcv timotimo: super interesting. so it tries to concat a very long 32 bit string and a short 8 bit string. if i do the slow iterating method it creates one long 8 bit string 13:16
and it basically takes away taking all the time iterating and copying it it away. but instead the time it takes for string indexing is much longer
Geth roast/fails-like: 230a2aa19c | (Zoffix Znet)++ | 2 files
Spec fails-like and swap to core fails-like for tests that use it

To go with github.com/rakudo/rakudo/pull/1664
roast: zoffixznet++ created pull request #408:
Spec fails-like and swap to core fails-like for tests that use it		 13:17
samcv it went from iterate_gi_into_string taking 55% of cycles to KMP_string_index taking 30% of all cycles 13:18
and taking longer 13:19
from 11s to 13s
i'll investigate more tomorrow
night o/
AH ok guess to throw out there. is that it's not using memmem() anymore since needle and haystack don't have matching flat data types anymore if i return the 32 bit string 13:22
and and doing grapheme based KMP is much slower than memmem
ok actually sleep now :)
AlexDaniel samcv++ 13:24
timotimo aha, ouch :) 13:34
dogbert2 timotimo: are there still problems with the profiler? 14:01
timotimo yep! 14:04
there is basically every problem ever 14:05
dogbert2 I have more examples if needed, e.g. large files, MoarVM panics etc
it strikes me that you haven't merged your fixes so ignore my comments for the time being :) 14:07
timotimo yes, it's not actually correct yet
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make affinity-threshold calculation simpler 14:16
travis-ci.org/rakudo/rakudo/builds/359087133 github.com/rakudo/rakudo/compare/6...014cf67d89
Geth rakudo: 4abfd4ca5e | (Zoffix Znet)++ | 2 files
Implement fails-like routine in Test.pm6

Same as throws-like, except checks the code returns an armed Failure.
Failures are a ubiquitous feature of the language, yet there's no convenient way to test for them:
... (8 more lines)		 14:51
rakudo: 82a0e70653 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1664 from rakudo/fails-like

Implement fails-like routine in Test.pm6
roast: 230a2aa19c | (Zoffix Znet)++ | 2 files
Spec fails-like and swap to core fails-like for tests that use it

To go with github.com/rakudo/rakudo/pull/1664
roast: 220c805fbc | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Merge pull request #408 from perl6/fails-like

Spec fails-like and swap to core fails-like for tests that use it
rakudo: a0e5e88058 | (Elizabeth Mattijsen)++ | src/core/Array.pm6
Implement Array.grab, as discussed in GH R#1658
 15:08
synopsebot R#1658 [open]: github.com/rakudo/rakudo/issues/1658 [@LARRY][NYI] Why do Array / Hash not have .grab like QuantHashes do?
japhb
.oO( Why do butterflies suddenly appear, / Every time you are near? / Just like me, they long to be / Coding with you ... )
 15:11
lizmat :-)
Geth rakudo: ce82292562 | (Elizabeth Mattijsen)++ | src/core/Array.pm6
Remove some leftover code

Since we abstracted the grabbing logic to GRAB_ONE, we don't need to keep the number of elements anymore.		 15:53
Zoffix Looks like private methods can be boosted by figuring out whether we can do nqp::callstatic instead of just nqp::call them after resolving at compiletime. 16:26
Though I still don't fully get when callstatic is appropriate. There'll only ever be one closure clone, but not sure what the implications of that are. 16:27
like what does a closure clone do exactly and what happens if you don't clone it 16:28
The current choice for staticalizing a call is done with `my $scopes := $!symbols.scopes_in($call.name);` and checking if scopes is <= 1. But if I ain't got a name, does that mean I can always staticalize or never? 16:30
Based on what I'm reading here, it should be fine to nqp::callstatic a looked up private method: irclog.perlgeek.de/perl6-dev/2018-...i_15846449 16:36
oh or not 16:37
for ^5 -> $i { sub foo() { say $i }; foo() } => with class Foo { my $x = 42; method !z { say $x }; method z { self!z }; method mod { $x = 100 }; }.new { .z; .mod; .z };
Same thing right? To correctly do !z call we need to resolve the things and the $x thing, eh?
seems to update just fine if I make it static. 16:44
And makes private method calls 11% *faster* than public ones. 16:46
Zoffix waits for jnthn to say that it can't be callstatic :D 16:49
ZOFVM Files=1292, Tests=153265, 146 wallclock secs (20.21 usr 3.11 sys + 3111.76 cusr 155.04 csys = 3290.12 CPU)
At least stresstest is clean
Geth rakudo/static-privates: 1b4bb402a0 | (Zoffix Znet)++ | src/Perl6/Optimizer.nqp
Make resolved private method calls callstatic
 16:52
rakudo: zoffixznet++ created pull request #1665:
Make resolved private method calls callstatic		 16:53
lizmat Zoffix++ :-) 16:56
Zoffix Well, I don't know if it's good. Gonna wait for jnthn to review :) 16:57
lizmat well, ++ for the work you've put into it either way :-)
Zoffix :)
OK, now I'm more confident that it's OK, 'cause QASTs for `my $i; sub bar { $i = $++; }; sub foo() { say $i }; for ^10 { foo; bar }` use static calls in the loop, so I guess the specialness of `for ^5 -> $i { sub foo() { say $i }; foo() }` isn't that `$i` is getting updated, but that the loop "creates" the sub each time. And since classes ain't closures, there's no new method created each time. 17:04
lizmat such a simple change :-) 17:05
perhaps jnthn thought it was already done long ago 17:06
Zoffix: confirm that github.com/rakudo/rakudo/pull/1665 makes the difference between public / private methods go to within noise 19:46
with what looks like a small preference for private
--profiles don't see a difference 19:47
bartolin hmm, the rakudo-j is broken and I'm unable to fix it. On the surface the build fails because the api for getrusage has been changed. But if I adjust that op to take an array, a bigger problem surfaces: Creating @rusage as a native array doesn't work -- it's the same problem that made this workaround necessary: github.com/rakudo/rakudo/commit/581edd58e9 20:20
timotimo oh, that's my fault :o 20:22
bartolin a similiar workaround should be possible by adding some more '#if jvm' statments, though
timotimo yes, indeed
bartolin well, it was an improvement for MoarVM ...
timotimo :S 20:23
bartolin should I try to add another special case for JVM there?
timotimo yes, please
bartolin ok, will look. (at a first glance I thought a lot of code expected @rusage to be a native array there, but it's not that much code, actually) 20:24
Geth rakudo: a393ff6916 | (Elizabeth Mattijsen)++ | 2 files
Implement (native array).grab, see GH R#1658
 20:39
synopsebot R#1658 [open]: github.com/rakudo/rakudo/issues/1658 [@LARRY][NYI][testneeded] Why do Array / Hash not have .grab like QuantHashes do?
Geth rakudo: f97398cfb8 | (Elizabeth Mattijsen)++ | src/Perl6/Actions.nqp
Make sure that values of `once` blocks are deconted

Fixes GH R#1610		 21:31
synopsebot R#1610 [open]: github.com/rakudo/rakudo/issues/1610 `once` places the return value into unwanted Scalar container
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Streamline Hash.BIND-KEY a bit 21:38
travis-ci.org/rakudo/rakudo/builds/359279857 github.com/rakudo/rakudo/compare/5...2ee64e48fe
buggable [travis build above] ✓ All failures are due to: missing build log (1 failure).
Geth nqp: jstuder-gh++ created pull request #433:
Profiler Template: Sort by time Instead of Pct		 21:42
rakudo: 88d61bd945 | (Elizabeth Mattijsen)++ | 2 files
Move proto method splice: Mu -> Any

As discussed in GH R#1575		 21:56
synopsebot R#1575 [open]: github.com/rakudo/rakudo/issues/1575 [6.d][@LARRY] Arbitrary drift of methods to `Mu` and `Any`
Geth nqp: 0736a0c405 | usev6++ | 2 files
[JVM] Adjust 'getrusage' to fix rakudo build

The api for getrusage has been changed -- it takes an argument now.[1]
Also, this commit adds a workaround for non-working native arrays in Rakudo's ThreadPoolScheduler.[2] Declaring @rusage as a native int array comes out as a VMArrayInstance_i instead of a VMArrayInstance. This really needs a clean fix, but I was unable to do that.
  [1] github.com/rakudo/rakudo/commit/c71fa17d8d
  [2] github.com/rakudo/rakudo/issues/1666		 22:00
rakudo: aaacc5a453 | usev6++ | src/core/ThreadPoolScheduler.pm6
[JVM] Work around problem with native arrays

  See github.com/rakudo/rakudo/issues/1666		 22:03
lizmat bartolin++ 22:04
bartolin ^^ I didn't see a better way to fix the JVM build. Please revert if this is to hacky.
timotimo thank you for fixing up my mess 22:06
bartolin yw :-) 22:07
btw, I didn't run a spectest on r-j with those changes (only on r-m). But at least S17-scheduler/basic.t came out clean. I'm waiting for my nightly spectest run ... 22:10
lizmat calls it a day 22:12
bartolin o/ 22:13
samcv AlexDaniel`: haven't fixed the collapse_strings overhead in that file. but i got this string test i made a while ago complete 25% faster gist.github.com/samcv/5c5c9916d42e...87a5dfe9cd 22:28
Geth roast: 4c1a52d755 | (Zoffix Znet)++ | S02-types/num.t
Fix wrong var in test; edwinst++
samcv basically if the haystack is a flat string, and the needle is under 100 graphemes, we convert the needle to be the same string type as the haystack
if it's an 8bit haystack and a 32 bit needle. we also bail if we encounter a non8bit grapheme. though that part isn't tested in that test file 22:29
MasterDuke samcv: any idea why that other file is creating 32bit strings in the first place? 22:47
samcv it's not. it's just concatting an 8 bit string with a 32 bit string 22:48
though i guess you could ask why the thing you're concatting on is 32 bit (the short section)
but the real slowdown comes from the flattening. but i'm going to work on that after this
at least i think. maybe i'm misremembering if the longer section was 32 bit or not 22:50
MasterDuke well yeah, why is any section 32bit
samcv though to be honest i'm much less worried about that. since in real use we get an assortment of strings 22:51
so we should be able to deal either way
MasterDuke true. but you have an idea how to speed up flattening?
samcv yeah 22:52
MasterDuke nice
samcv pretty happy with the changes i'm making right now though. should speed things up a huge amount with regex 22:53
since most of the time we don't have matching needles
and haystacks if they're both flat that is
or flat haystack (since indexingoptimized) but needle isn't. and it's pretty neat that it will bail if it encounters a 32 bit grapheme in the needle and the haystack is 8 (before even doing the memmem) 22:54
wow. crazy. looks like there's a bug in a section of code i could never trigger. at least i'm pretty sure. so memmem works on 8 bit boundaries but when we search 32 bit strings it checks and makes sure we are on a 32 bit boundary and not an 8 bit one. and i never could get that to trigger 23:27
but with these changes of converting the needle, it got triggered and entered an infinite loop. because it places the start position back at the last position (instead of one byte AFTER the last position) 23:28
MasterDuke so the new code will be faster and more correct? sounds like a win all around 23:32
samcv i'm suprised yet relieved that it triggered at the same time 23:37
now i want to print out the two strings that triggered it 23:39
wow ok that makes sense. the needle is \0 :D 23:43
that was one thing i most suspected could happen, but i never triggered it. probably because \0 would always be 8bit and for a 32 bit haystack it never triggers 23:45
that makes me feel a lot better than it's unlikely anyone has ever triggered it themselves
only if they had somehow made a 32bit based "\0"
which i never could do
m: "67 55 49 50 70 69 54 57 54 57 70 55 56 54 67 57 51 56 48 68 54 52 51 68 70 49 55 69 56 53 68 48 54 56 54 56 50 49 57 69 0 112 101 114 108 35 115 111 117 114 99 101 115 47 67 55 49 50 70 69 54 57 54 57 70 55 56 54 67 57 51 56 48 68 54 52 51 68 70 49 55 69 56 53 68 48 54 56 54 56 50 49 57 69 0 49 57 68 50 68 48 56 67 48 51 50 69 54 57 66 55 56 57 57 51 69 57 56 65 53 65 48 69 57 66 68 69 51 52 67 66 54 57 54 52 0 67 111 109 112 85 110 105 116 58 23:51
58 68 101 112 101 110 100 101 110 99 121 83 112 101 99 105 102 105 99 97 116 105 111 110 46 110 101 119 40 115 104 111 114 116 45 110 97 109 101 32 61 62 32 34 84 101 115 116 34 44 32 115 111 117 114 99 101 45 108 105 110 101 45 110 117 109 98 101 114 32 61 62 32 50 44 32 102 114 111 109 32 61 62 32 34 80 101 114 108 54 34 44 32 118 101 114 115 105 111 110 45 109 97 116 99 104 101 114 32 61 62 32 66 111 111 108 58 58 84 114 117 101 44 32 97 117
116 104 45 109 97 116 99 104 101 114 32 61 62 32 66 111 111 108 58 58 84 114 117 101 44 32 97 112 105 45 109 97 116 99 104 101 114 32 61 62 32 66 111 111 108 58 58 84 114 117 101 41".split(' ').chrs.index("\0").say
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in double quotes; couldn't find final '"' (corresponding starter was at line 1)
at <tmp>:1
------> 0354 52 0 67 111 109 112 85 110 105 116 587⏏5<EOL>
expecting…
samcv oops...
m: "67 55 49 50 70 69 54 57 54 57 70 55 56 54 67 57 51 56 48 68 54 52 51 68 70 49 55 69 56 53 68 48 54 56 54 56 50 49 57 69 0 112 101 114 108 35 115 111 117 114 99 101 115 47 67 55 49 50 70 69 54 57 54 57 70 55 56 54 67 57 51 56 48 68 54 52 51 68 70 49 55 69 56 53 68 48 54 56 54 56 50 49 57 69 0 49 57 68 50 68 ".split(' ').chrs.index("\0").say 23:52
camelia 40

Powered by Cro and the Raku® Programming Language.

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

Thank you!