TimToady | m: printf "%3d", 42 | 00:10 | |
camelia | rakudo-moar 7f245f: OUTPUT« 42» | ||
TimToady | m: printf "%3.0d", 42 | ||
camelia | rakudo-moar 7f245f: OUTPUT« » | ||
TimToady | ^^^ bug | ||
is supposed to suppress output only if the value is 0 | 00:11 | ||
brokenchicken clicks "Take" | 00:44 | ||
m: dd sprintf "%.3d", 55 | 00:53 | ||
camelia | rakudo-moar 7f245f: OUTPUT«"55"» | ||
brokenchicken | TimToady: that's broken too, innit ^? It's supposed to pad with zeros? | 00:54 | |
and give "055" | |||
MasterDuke | m: dd sprintf "%03d", 55 | 00:56 | |
camelia | rakudo-moar 7f245f: OUTPUT«"055"» | ||
TimToady | you need explicit 0 to pad there, I think | 00:58 | |
brokenchicken | m: say "|{sprintf "%10.5d", 42} | ||
camelia | rakudo-moar 7f245f: OUTPUT«5===SORRY!5=== Error while compiling <tmp>Unable to parse expression in double quotes; couldn't find final '"' at <tmp>:1------> 3say "|{sprintf "%10.5d", 42}7⏏5<EOL>» | ||
brokenchicken | m: say "|{sprintf "%10.5d", 42}" | ||
camelia | rakudo-moar 7f245f: OUTPUT«| 42» | ||
brokenchicken | $ perl -wlE 'say "|" . sprintf("%10.5d", 42) . "|"' | ||
| 00042| | |||
$ perl -wlE 'say "|" . sprintf("%.5d", 42) . "|"' | 00:59 | ||
|00042| | |||
Are we following what Perl 5 does? | |||
TimToady | huh | 01:00 | |
brokenchicken | from perldoc: "For integer conversions, specifying a precision implies that the output of the number itself should be zero-padded to this width, where the 0 flag is ignored:" | ||
geekosaur | that's also ANSI C | ||
replacing K&R's 0 flag | 01:01 | ||
brokenchicken | m: dd sprintf "%.3d", 123456789 | 01:02 | |
camelia | rakudo-moar 7f245f: OUTPUT«"123"» | ||
brokenchicken | heh :) | ||
TimToady | that's also wrong | 01:03 | |
should be minimum for d | |||
brokenchicken | will fix | 01:04 | |
TimToady | it can be inferred from the system sprintf docs that a %.3d should have minimum 3 digits, so obviously those extra digits would have to be 0 | ||
Geth | p: 92bf17d5f8 | (Zoffix Znet)++ | t/hll/06-sprintf.t Remove outdated comment The file is already in t/hll |
01:58 | |
p: 1de45e4a3d | (Zoffix Znet)++ | 2 files Fix sprintf precision parameter for `d` Currently, it just chops the number to $precision digits, producing wrong results. The correct behaviour is for the precision to signify how many digits long the number should be, prefixing it with zeros if needed. This also results in an empty string if precision is zero and the number is zero too. Bug find: irclog.perlgeek.de/perl6-dev/2017-...i_13966753 |
02:08 | ||
MasterDuke | m: dd sprintf "%0۳d", 55 | 02:18 | |
camelia | rakudo-moar 7f245f: OUTPUT«Directive d not applicable for type Int» | ||
Geth | p: ed1b835a7a | (Zoffix Znet)++ | t/hll/06-sprintf.t Add tests to sprintf "%d" precision when given as "*" |
02:22 | |
MasterDuke | m: dd sprintf "%03d", 55 | ||
camelia | rakudo-moar 7f245f: OUTPUT«"055"» | ||
MasterDuke | TimToady, brokenchicken: ^^^ should Nd's be allowed in sprintf format strings? | 02:23 | |
brokenchicken shrugs | 02:24 | ||
Geth | kudo/nom: a1c7d01502 | (Zoffix Znet)++ | tools/build/NQP_REVISION (nqp bump) Fix precision for "%d" in sprintf Fixed in github.com/perl6/nqp/commit/1de45e...8a9ce2bbe0 |
02:34 | |
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....0-ged1b835 | |||
ast: 4e3fd00b26 | (Zoffix Znet)++ | S32-str/sprintf.t Test sprintf "%d" precision parameter Rakudo fix: github.com/rakudo/rakudo/commit/a1c7d01502 NQP fix: github.com/perl6/nqp/commit/1de45e4a3dcd8a9ce |
02:38 | ||
[Tux] | This is Rakudo version 2017.01-7-ga1c7d0150 built on MoarVM version 2017.01-10-g76872dbe | 10:09 | |
csv-ip5xs 2.960 | |||
test 12.644 | |||
test-t 5.062 | |||
csv-parser 13.419 | |||
Geth | kudo: usev6++ created pull request #1002: Don't mention *CORE.setting in error message |
11:52 | |
kudo/nom: 10bcec2865 | usev6++ | src/core/Backtrace.pm Don't mention *CORE.setting in error message References to CORE.setting.moarvm where removed with 4ae08e0b24, but rakudo-j points to gen/jvm/CORE.setting (no .jar there). Fixes RT #130509 and RT #124767 on JVM |
11:53 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130509 | ||
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124767 | |||
kudo/nom: a56a895808 | lizmat++ | src/core/Backtrace.pm Merge pull request #1002 from usev6/rt130509_jvm Don't mention *CORE.setting in error message |
|||
kudo/nom: c3c86dcf51 | (Elizabeth Mattijsen)++ | src/core/Backtrace.pm Emphasize this is JVM backend specific behaviour |
12:17 | ||
bartolin | thanks :-) | 12:21 | |
lizmat | bartolin++ # for chasing JVM issues! | 12:30 | |
dogbert17 | lizmat: is gist.github.com/dogbert17/b052a9da...990cdad35f affected by the grep deopt made recently? Runs twice as slowly on head compared to 2016.12 and older | 12:41 | |
lizmat | dogbert17: yeah, I saw it | ||
but if we want to support redo in a grep, there is no way around it that I can see at the moment | |||
dogbert17 | just wanted to make sure it wasn't something else, i.e. something unintended | 12:42 | |
lizmat | it sucks, since redo is dynamic, so we can't even inspect the block in the optimizer for use of redo | ||
the only way that jnthn pointed out, was to have goto working :-) | 12:43 | ||
then we wouldn't need to penalize all greps for the use of redo | |||
dogbert17 | so it might be fixed in time then? | ||
lizmat | yes, once we have goto | 12:44 | |
dogbert17 | cool | ||
lizmat | fwiw, this would benefit *all* map processing, not just grep | ||
because everywhere we need to support redo, we need to build another layer of loop around everything to support it | |||
$redo = 1; while $redo { $redo = 0; call block } | 12:45 | ||
dogbert17 | will it go back to the speed it had in 2016.12 ot will it be even faster with goto | ||
lizmat | it should go back to the speed we had, not faster | ||
timotimo | did you see how i built redo for whenever blocks? | 12:47 | |
lizmat | timotimo: not yet | ||
timotimo | i put the loop in separately, only to be entered once we actually hit the redo handler once | ||
perhaps that could be done here as well | |||
i.e. { call block; CONTROL { when 'redo' { $redo = 1; while $redo { $redo = 0; call block } } } } | 12:48 | ||
i *think* we only pay if redo was actually used if the code is like that | |||
but i haven't measured | |||
dogbert17 | timotimo lizmat: should this snippet hang? | 12:58 | |
m: m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy # should this loop indefinitely? | |||
m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy # should this loop indefinitely? | 12:59 | ||
camelia | rakudo-moar c3c86d: OUTPUT«(timeout)» | ||
timotimo | Stringy has always had a tendency to cause endless loops | ||
lizmat | perhaps we need to look at what you're trying to achieve ? | 13:00 | |
dogbert17 | nothing :) took it from a MoarVM bug report, it used to crash before jnthn made a callsame fix | 13:01 | |
if the snippet is supposed to loop endlessly I think the original bug can be cinsidered fixed | 13:02 | ||
*considered | |||
it's from github.com/MoarVM/MoarVM/issues/412 | 13:05 | ||
lizmat | www.bleepingcomputer.com/news/secu...pril-2017/ # does this affect our use of the JVM backend ? | 13:18 | |
timotimo | i'm not sure we sign our .jar files at all? | 13:22 | |
lizmat has no idea | 13:24 | ||
timotimo | but i expect it's a trivial matter to use a different hash there. like, changing a commandline flag or something | 13:25 | |
Geth | kudo/nom: d71bf1e90c | (Elizabeth Mattijsen)++ | src/core/Supply.pm Implement Supply.skip() |
13:49 | |
moritz | stackoverflow.com/questions/4179160...-different that looks like a bug to me | 14:42 | |
timotimo | moritz: i think you'd have to use "role Either is Alpha is Digit" | 14:43 | |
moritz | timotimo: why? then you lose all the advantages that role semantics bring | 14:45 | |
timotimo | i just think you have to use derivation rather than composition? | ||
but ... *shrug* | |||
not a thing i've been doing so far | |||
brokenchicken | m: say (Empty xx 4)[0] | 18:16 | |
camelia | rakudo-moar d71bf1: OUTPUT«()» | ||
brokenchicken | m: dd (Empty xx 4)[0] | ||
camelia | rakudo-moar d71bf1: OUTPUT«Empty» | ||
brokenchicken | m: dd (Slip.new() xx 4)[0] | ||
camelia | rakudo-moar d71bf1: OUTPUT«Nil» | ||
brokenchicken | m: dd (Slip.new(42, 44) xx 4)[0] | 18:17 | |
camelia | rakudo-moar d71bf1: OUTPUT«Int <element> = 42» | ||
brokenchicken | Seems Empty is being mishandled here? | ||
:S make t/spec/S16-io/newline.t fails but prove -e './perl6' -vlr t/spec/S16-io/newline.t succeeds | 18:26 | ||
and t/spec/S10-packages/precompilation.t consistently fails | |||
mm.. and same thing with t/spec/integration/advent2011-day03.t make fails but prove succeeds :S | |||
brokenchicken git resets and tries another run | 18:27 | ||
ah, k. Prolly something with precomp. My VM froze mid one spectest run and I just ran the second one. I now rebuilt and all seems peachy | 18:36 | ||
MasterDuke | i just cleaned out the .precomp directory in my rakudo/t/spec/packages earlier this morning, it was >400Mb, with files/directories >6m old | 18:38 | |
brokenchicken | yeah, once I ran `rm -fr rakudo` and it ran for several minutes... | 18:45 | |
Geth | kudo/nom: 4e49ec135d | (Zoffix Znet)++ | src/core/List.pm Fix infix:<xx>(..., *) for empty Slips The current code makes the assumption that when a Slip is encountered, it is non-empty, and it saves it in an Array and shifts from that array, to obtain next value. This causes a Failure when the Slip is empty and there is nothing to shift. Fix by checking whether we can shift and returning IterationEnd if can't. Fixes RT#130619: rt.perl.org/Ticket/Display.html?id=130619 |
18:50 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130619 | ||
ast: 75e15bbb2a | (Zoffix Znet)++ | S03-operators/repeat.t Test empty slip with xx * works RT#130619: rt.perl.org/Ticket/Display.html?id=130619 Rakudo fix: github.com/rakudo/rakudo/commit/4e49ec135d |
18:53 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130619 | ||
brokenchicken | m: dd (Empty.new xx 4)[0] | 18:58 | |
camelia | rakudo-moar d71bf1: OUTPUT«Nil» | ||
brokenchicken | m: dd (Empty xx 4)[0] | ||
camelia | rakudo-moar d71bf1: OUTPUT«Empty» | ||
brokenchicken | (one's thunked the other isn't) | ||
prolly makes sense... | 18:59 | ||
Geth | kudo/nom: 15753fd3c3 | (Elizabeth Mattijsen)++ | src/core/Supply.pm Fix scoping issue with Supply.skip, spotted by jnthn++ |
19:11 | |
ast: 943b3ad515 | (Elizabeth Mattijsen)++ | S32-list/skip.t Add tests for Any.skip |
19:34 | ||
kudo/nom: cbb7130038 | (Elizabeth Mattijsen)++ | t/spectest.data Make sure we run Any.skip tests |
19:37 | ||
ast: 24af69c6ca | (Elizabeth Mattijsen)++ | S17-supply/skip.t Add basic Supply.skip tests |
19:41 | ||
kudo/nom: 8a448d4c63 | (Elizabeth Mattijsen)++ | t/spectest.data Make sure we run Supply.skip tests |
19:42 | ||
kudo/nom: e0201f15df | (Elizabeth Mattijsen)++ | src/core/Any-iterable-methods.pm Introducing Any.batch(n) Since Supply has a .batch, I figured we should probably also have an Any.batch, just to keep the balance :-) |
19:51 | ||
ast: ca42a37505 | (Elizabeth Mattijsen)++ | S32-list/batch.t Add some basic Any.batch tests |
20:07 | ||
kudo/nom: ce76f4c5a0 | (Elizabeth Mattijsen)++ | t/spectest.data Make sure we run the Any.batch tests |
|||
MasterDuke | is anyone else getting `Argument "3.36_01" isn't numeric in numeric gt (>) at t/harness5 line 118.` when running `make m-spectest`? | 20:49 | |
This is perl 5, version 24, subversion 1 (v5.24.1) built for x86_64-linux-thread-multi | 20:50 | ||
moritz rebuilds rakudo to reproduce | 20:52 | ||
MasterDuke | i don't think it's a rakudo thing | 20:55 | |
pretty sure perl5 was updated on my machine a day or two ago | |||
Geth | kudo: MasterDuke17++ created pull request #1003: Speedup postincrement and postdecrement by ~5% |
20:56 | |
kudo/nom: fd74c91791 | (Daniel Green)++ | src/core/Int.pm Speedup postincrement and postdecrement by ~5% Change an assign into a bind. |
20:57 | ||
kudo/nom: 8729048c3f | lizmat++ | src/core/Int.pm Merge pull request #1003 from MasterDuke17/speedup_postinc_and_postdec Speedup postincrement and postdecrement by ~5% |
|||
MasterDuke | lizmat++ that was fast | 20:58 | |
lizmat | I actually had been looking at that one just minutes before your PR :-) | ||
MasterDuke | heh. i also tried wrapping the lines in a nqp::stmts(), but i measured no difference | 20:59 | |
lizmat | did you try doing the binding of b inside the nqp::add_i ? | 21:00 | |
MasterDuke | nope | 21:01 | |
lizmat | that *may* help as well :-) | ||
it's something I would try :-) | 21:02 | ||
MasterDuke | i'll run some more tests | ||
lizmat | MasterDuke++ | ||
Geth | kudo/nom: 3a4b26283b | (Zoffix Znet)++ | t/harness5 Avoid warning when TAP::Harness's version ain't numeric |
21:09 | |
MasterDuke | lizmat: no noticeable difference | 21:26 | |
lizmat | ok, I guess the optimizer / spesh / JIT are doing their work then :-) | ||
MasterDuke | in rakudo/src there are 158 `{*}` and 337 `{ * }`. anybody have strong opinions about whether we should be consistent? and if so, which way? | 21:36 | |
brokenchicken has no opinion | 21:37 | ||
timotimo | fewer spaces to make parsing faster!!!!!!k ;) | ||
brokenchicken | :) | ||
Geth | kudo/nom: 0fdb9e4e40 | (Elizabeth Mattijsen)++ | 2 files nativeshaped.pairs returns Pair.value that is a LHS Before this, (my int @a[2;2]).pairs[0].value++ would fail with: Cannot resolve caller postfix:<++>(Int) |
21:38 | |
MasterDuke | not entirely a bad idea: gist.github.com/MasterDuke17/77230...lts-csv-L8 | ||
timotimo | We can make this file beautiful and searchable if this error is corrected: It looks like row 97 should actually have 1 column, instead of 2. | 21:39 | |
oh? | |||
MasterDuke | _ws and ws are #8 and #18 by exclusive time for profile-compile of a rakudo build | ||
github thinks it's a csv, so the infix<,> messes it up | 21:40 | ||
timotimo | ah, hehehe | ||
pretty good | |||
MasterDuke is partially to blame for naming the file .csv | |||
timotimo | tsv would be better, because i'm pretty sure we don't have an operator \t so far :D | 21:41 | |
moritz | not YET :-) | ||
timotimo | is probably possible to put in already | 21:42 | |
RabidGravy | I keep meaning to post this with regard to the performance thing as it seemed pertinent jamesclear.com/marginal-gains | 21:47 | |
yoleaux2 | 21 Jan 2017 21:35Z <MasterDuke> RabidGravy: yep, github.com/MoarVM/MoarVM/pull/501 | ||
RabidGravy | MasterDuke++ # nice one | 21:48 | |
Geth | kudo/nom: 1181afec40 | (Elizabeth Mattijsen)++ | 2 files Make sure my int @a[2].kv gives LHS valueo Before this, (my int @a[2]).kv[1]++ would fail with: Cannot resolve caller postfix:<++>(Int) |
21:49 | |
kudo/nom: e195e5f990 | (Elizabeth Mattijsen)++ | 2 files Make sure my int @a[2].values gives LHS values Before this, (my int @a[2]).values[0]++ would fail with: Cannot resolve caller postfix:<++>(Int) |
22:04 | ||
lizmat | m: my int @a[3] = (0,1,2); @a = (); dd @a # perhaps unexpected behaviour of 1dim shaped arrays ? | 22:31 | |
camelia | rakudo-moar e195e5: OUTPUT«array[int].new(:shape(3,), [0, 1, 2])» | ||
lizmat | m: my int @a = (0,1,2); @a = (); dd @a # perhaps unexpected behaviour of 1dim shaped arrays ? | 22:32 | |
camelia | rakudo-moar e195e5: OUTPUT«array[int].new()» | ||
timotimo | m: my int @a[3] = 0, 1, 2; @a = (1,); dd @a | ||
camelia | rakudo-moar e195e5: OUTPUT«array[int].new(:shape(3,), [1, 1, 2])» | ||
timotimo | at least it's consistent with that? | ||
lizmat | yes, it is | 22:33 | |
but I'm thinking, suppose we pass an array to a module somewhere, and that module does = () thinking it initializes it | |||
m: sub a(@a) { @a = () }; a(my @a[3] = (42,66,666)); dd @a | 22:34 | ||
camelia | rakudo-moar e195e5: OUTPUT«Array.new(:shape(3,), [42, 66, 666])» | ||
lizmat | m: sub a(@a) { @a = () }; a(my @a = (42,66,666)); dd @a | 22:35 | |
camelia | rakudo-moar e195e5: OUTPUT«Array @a = []» | ||
lizmat | feels a bit like a footgun to me | ||
unless we can actually have something in a signature to match shaped arrays | 22:36 | ||
I came across this while investigating the native shaped array coverage, which is minimal atm | 22:37 | ||
timotimo | m: my int @a[3] = 9, 9, 9; @a = Empty; dd @a | ||
camelia | rakudo-moar e195e5: OUTPUT«array[int].new(:shape(3,), [9, 9, 9])» | ||
timotimo | to me, that's more footgunny, as it explicitly says "empty" | ||
lizmat | yup | ||
timotimo | but i really need sleep now | ||
lizmat | timotimo: good night, sleep tight! | ||
timotimo | i'll do my best! :) | ||
jnthn | At the same time, `@shaped-array = @replace-first-elems-with-this` working fine then exploding when the second array contains zero elems would be a nasty discontinuity. | 23:13 | |
Not sure we should break a useful thing's boundary case for the sake of a footgun. | 23:14 | ||
lizmat | well, I'm working on adding a warning, would that be ok ? | ||
jnthn | Not really :( | 23:15 | |
lizmat | also for the () case ? | ||
jnthn | I mean, I guess you could put quietly but it's still a discontinuity | ||
Can we distinguish Empty? | |||
I can go with warning on Empty | |||
m: say |() | |||
camelia | rakudo-moar e195e5: OUTPUT«» | ||
jnthn | m: say (|()).perl | ||
camelia | rakudo-moar e195e5: OUTPUT«slip()» | ||
jnthn | OK, good, we can distinguish that from Empty :) | ||
I'm fine with the warning on Empty | 23:16 | ||
lizmat | ok | ||
but then I will need to rethink the code and warning | |||
and that will be tomorrow :-) | |||
jnthn | Yeah, I'm gonna turn in too :) | 23:17 | |
busy day for me tomorrow; likely won't be around all that much. | |||
lizmat | ok, sleep well! | ||
jnthn | Thanks, you also :) | 23:18 | |
'night, #perl6-dev | |||
MasterDuke | m: say sprintf '%0۳d', -3.1415 | 23:48 | |
camelia | rakudo-moar e195e5: OUTPUT«Directive d not applicable for type Rat» | ||
MasterDuke | m: say sprintf '%0۳d', -31415 | ||
camelia | rakudo-moar e195e5: OUTPUT«Directive d not applicable for type Int» | ||
MasterDuke | m: say sprintf '%03d', -31415 | ||
camelia | rakudo-moar e195e5: OUTPUT«-31415» | ||
MasterDuke | m: say sprintf '%۳.3Gd', -3.1415 | 23:49 | |
camelia | rakudo-moar e195e5: OUTPUT«This representation (Null) does not support elems (for type VMNull)» | ||
MasterDuke | m: say sprintf '%3.3Gd', -3.1415 | ||
camelia | rakudo-moar e195e5: OUTPUT«-3.14d» | ||
MasterDuke | m: say sprintf '%3.۳G', -3.1415 | ||
camelia | rakudo-moar e195e5: OUTPUT«Directive g not applicable for type Rat» | ||
MasterDuke | m: say sprintf '%3.3G', -3.1415 | ||
camelia | rakudo-moar e195e5: OUTPUT«-3.14» | ||
MasterDuke | m: say sprintf '%۳.3G', -3.1415 | 23:50 | |
camelia | rakudo-moar e195e5: OUTPUT«This representation (Null) does not support elems (for type VMNull)» | ||
MasterDuke | .ask TimToady do you have an opinion on Nd's in sprintf format strings? e.g., irclog.perlgeek.de/perl6-dev/2017-..._13970314. should they be made to work? | 23:52 | |
yoleaux2 | MasterDuke: I'll pass your message to TimToady. | ||
MasterDuke | .ask jnthn do you have an opinion on Nd's in sprintf format strings? e.g., irclog.perlgeek.de/perl6-dev/2017-..._13970314. should they be made to work? | ||
yoleaux2 | MasterDuke: I'll pass your message to jnthn. | ||
MasterDuke | .ask lizmat do you have an opinion on Nd's in sprintf format strings? e.g., irclog.perlgeek.de/perl6-dev/2017-..._13970314. should they be made to work? | ||
yoleaux2 | MasterDuke: I'll pass your message to lizmat. | ||
MasterDuke | .ask samcv do you have an opinion on Nd's in sprintf format strings? e.g., irclog.perlgeek.de/perl6-dev/2017-..._13970314. should they be made to work? | ||
yoleaux2 | MasterDuke: I'll pass your message to samcv. | ||
MasterDuke | .ask bartolin do you have an opinion on Nd's in sprintf format strings? e.g., irclog.perlgeek.de/perl6-dev/2017-..._13970314. should they be made to work? | 23:53 | |
yoleaux2 | MasterDuke: I'll pass your message to bartolin. | ||
samcv | MasterDuke, that would be cool | 23:54 | |
yoleaux2 | 23:52Z <MasterDuke> samcv: do you have an opinion on Nd's in sprintf format strings? e.g., irclog.perlgeek.de/perl6-dev/2017-..._13970314. should they be made to work? | ||
samcv | let me poke a few things and see if I have any other comments | 23:55 |