Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
Geth roast/6.c-errata: b433a0d249 | (Elizabeth Mattijsen)++ | 3 files
Bring up-to-date with QuantHash mutability changes

In other words: if the left hand side of a set operator is mutable, then the result will also be mutable.		 09:08
lizmat m: with ("AAS".."ABS").iterator { dd .pull-one; dd .pull-one } # looks like a genuine bug to me 09:26
camelia "AAS"
"ABS"
jnthn m: say "AAS".succ 09:27
camelia AAT
jnthn Indeed
lizmat JCO found it 09:30
Geth roast/6.c-errata: 98fae051b4 | (Aleks-Daniel Jakimenko-Aleksejev)++ | S02-literals/quoting.t
Added TODO reason

Otherwise it is transformed into `todo()` without args which won't compile.
lizmat medium.com/@jcoterhals/perl-6-smal...796efabd37
lizmat_ m: with ("AAS" ... "ABS").iterator { dd .pull-one; dd .pull-one } # the underlying issue 10:16
camelia "AAS"
"ABS"
lizmat_ SEQUENCE appears to be broken
lizmat_ is dreading to look into that 10:17
jnthn m: with ("A" ... "Z").iterator { dd .pull-one; dd .pull-one } 10:17
camelia "A"
"B"
jnthn m: with ("AA" ... "AZ").iterator { dd .pull-one; dd .pull-one } 10:18
camelia "AA"
"AB"
jnthn m: say "AAS" cmp "AAS".succ
camelia Less
jnthn m: say "AAS" cmp "ABS"
camelia Less
jnthn m: say "AAS" lt "ABS" 10:19
camelia True
jnthn Odd
lizmat AlexDaniel: did you just mark "master" as protected? 10:24
AlexDaniel lizmat: yes
lizmat ah, ok, so I guess fix for above will not make it to this release 10:25
AlexDaniel I guess that's OK… we had this issue since 2015 I think
I'm currently toasting on HEAD and I hope that's the last time I do it for this release :) 10:28
lizmat: but you can push it here github.com/rakudo/rakudo/tree/post...se-2018.08
jnthn Me too... :)
lizmat bisectable6: { my $i = ("AAS" ... "ABS").iterator; say $i.pull-one; say $i.pull-one }
bisectable6 lizmat, On both starting points (old=2015.12 new=0979b77) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «AAS␤ABS␤»
lizmat yup, at least since Christmas 10:29
AlexDaniel ehhh what's up with t/spec/S32-io/indir.t
lizmat nothing for me
Geth nqp: b7f4cb101f | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 3 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...ge530be4d3 e530be4d3 Merge pull request #945 from jstuder-gh/travis_tags_mac_os 99ddb9d4a Remove unshallow as it causes error on full repo c43a9b97e Workaround version failure on Travis CI (MacOS)		 10:32
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...ge530be4d3
rakudo: ea387a12a1 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] b7f4cb101 [MoarVM Bump] Brings 3 co […]

NQP bump brought: github.com/perl6/nqp/compare/2018....gb7f4cb101
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....gb7f4cb101
thundergnat++ created pull request #2237: Fix precision calculation in FatRat .Str
AlexDaniel weird 10:38
just a flop I guess 10:46
AlexDaniel so, releasable is happy 12:43
canary is clean
toaster, uh… well, I see a lot of false burns because of the zef change 12:44
but not other way around so that's probably good 12:45
toast.6lang.org/ 12:46
it looks very red but according to my last analysis everything is good
one exception right now is Image::Resize 12:47
c: 2018.06,HEAD^,HEAD run :cwd(‘sandbox/perl6-image-resize’), <perl6 -I../perl6-gd-raw>, ‘t/02-more.t’ 13:09
committable6 AlexDaniel, gist.github.com/a86cde5ed135eea943...2162ed3b5e
AlexDaniel eh, it's just a flapper
c: 2018.06,2018.06,2018.06,2018.06,2018.06,2018.06,2018.06 run :cwd(‘sandbox/perl6-image-resize’), <perl6 -I../perl6-gd-raw>, ‘t/02-more.t’ 13:10
committable6 AlexDaniel, gist.github.com/14af82e13e401ee64b...272ce82980
AlexDaniel yup
OK!!
filed a ticket here github.com/dagurval/perl6-image-re.../issues/18 13:12
jnthn: so what do you think about R#2231 ? 13:13
synopsebot_ R#2231 [open]: github.com/rakudo/rakudo/issues/2231 [SEGV][regression][⚠ blocker ⚠] SEGV in Audio::Sndfile
AlexDaniel nine: ↑ ?
jnthn: I mean, do we move on without figuring it out?
jnthn AlexDaniel: IMO yes; we can leave the ticket for later 13:14
AlexDaniel jnthn: I'm relatively sure that I had it segfault before that commit… the way it happened was that I left the tests running in a loop and forgot, after about half an hour it segv'd 13:15
but 🤷 13:16
alright R#1976 13:18
synopsebot_ R#1976 [open]: github.com/rakudo/rakudo/issues/1976 [Windows][⚠ blocker ⚠] 2018.06 build for JVM fail
AlexDaniel I see that everyone is very eager to test things on windows and with jvm, and especially with both combined :)
appveyor is not even set up to test r-j 13:19
but why is that? 13:20
AlexDaniel samcv: alright! LGTM. Feel free to release now 13:39
|Tux| Big span today. No idea why 14:17
Rakudo version 2018.06-480-gea387a12a - MoarVM version 2018.06-434-ge530be4d3
csv-ip5xs0.942 - 0.979
csv-ip5xs-207.511 - 7.738
csv-parser23.488 - 24.156
csv-test-xs-200.450 - 0.459
test9.222 - 9.502
test-t2.040 - 2.238
test-t --race0.888 - 0.906
test-t-2036.695 - 37.040
test-t-20 --race11.702 - 11.876
nine AlexDaniel: looks like the generated methods for NativeCall subs don't handle explicitly managed strings correctly 14:37
i.e. it makes no difference between strings that are and strings that aren't explicitly managed. 14:39
timotimo i thought the difference was in how the GC treats the Str objects, but explicitly-manage has been confusing me for a while and i never took the time to look close enough 14:40
Ulti |Tux|: the two values is that the current run vs previous or just min and max time taken? 14:47
timotimo the latter
both numbers are put into the speed log separately, too
and i think the graph either only shows the higher one, or averages
|Tux| it is the fastest and the slowest run of two consequetive runs 14:49
Ulti so essentially pre and post OS level caching 14:51
timotimo no, i don't think so
Ulti well my second run of any Perl 6 code is always considerably faster than the first
and not sure its precomp type things since thats more on install right? or is there a more general precomp cache thats not local to your code 14:53
timotimo i think tux runs the code more than these two times
|Tux| sometimes, but usually just two full runs 14:54
TimToady .tell lizmat Note that "AAS" ... "ABS" is working as currently specced, since they are equal-sized strings and we're assuming something like '000' .. '377' is wanted. You hafta write "AAS", *.succ ... "ABS" to get the other behavior under current rules. 15:06
yoleaux TimToady: I'll pass your message to lizmat.
TimToady jnthn: ^^^ 15:08
|Tux| Rakudo version 2018.06-480-gea387a12a - MoarVM version 2018.06-434-ge530be4d3
csv-ip5xs0.919 - 0.964
csv-ip5xs-207.705 - 7.873
csv-parser23.268 - 23.316
csv-test-xs-200.457 - 0.463
test8.599 - 8.661
test-t2.057 - 2.067
test-t --race0.879 - 0.885
test-t-2035.946 - 36.542
test-t-20 --race11.859 - 11.895
 15:10
so, that's better
pmurias samcv: is the hash issue still present in modern JVMs? 20:31
lizmat looking at the code in SEQUENCE, I realize that much of the thinking that went into that, is very pre-GLR 22:55
yoleaux 15:06Z <TimToady> lizmat: Note that "AAS" ... "ABS" is working as currently specced, since they are equal-sized strings and we're assuming something like '000' .. '377' is wanted. You hafta write "AAS", *.succ ... "ABS" to get the other behavior under current rules.
lizmat .ask TimToady ok, so that means that my fix for "AAS" .. "ABS" (the Range version) is correct, right? 22:58
yoleaux lizmat: I'll pass your message to TimToady.
TimToady .tell lizmat I didn't see any fix. The .. operator is currently specced to translate to ... when iterated, and ... is operating as designed. We could make .. behave differently, but then we might break any current code that relies on '000000' .. '177777' to generate all the octals. 23:33
yoleaux 22:58Z <lizmat> TimToady: ok, so that means that my fix for "AAS" .. "ABS" (the Range version) is correct, right?
TimToady: I'll pass your message to lizmat.
TimToady .tell lizmat so any such change would have to be for 6.d 23:34
yoleaux TimToady: I'll pass your message to lizmat.

Powered by Cro and the Raku® Programming Language.

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

Thank you!