samcv and then add NFG_CHECK(tc, result, "MVM_string_join") to the end 00:00
MasterDuke k
samcv you shouldn't need the strand check really. NFG_CHECK performs further tests. without MVM_DEBUG_NFG_STRICT it only counts that the resul under normalization is the same number of graphemes. with strict it renormalizes it and compares each grapheme
well it doesn't affect the string you run NFG_CHECK on, it just checks it 00:01
also make sure NFG_CHECK is within MVMROOT
for result
MVMROOT result that is
MasterDuke, it's S15-normalization/test-gen.p6 that generates my concat tests for normalization 00:02
see line 73-74 in that file. you basically need to just test what's in @list, and test it's the same under various joins. 00:04
and i *think* result is the proper result.. i'd look in the generated concat files and it should be pretty obvious what it's generating 00:05
but adding a fprintf to the section of code which triggers your optimization is important to make sure you're actually testing what you think you are
Zoffix \o/ 6lang poster :D raw.githubusercontent.com/perl6/ma...square.png 00:10
MasterDuke i like it 00:12
Zoffix AlexDaniel: cool. Thanks for going through it
samcv i like it too 00:14
needs more color though :)
Zoffix :) 00:15
Zoffix drifts towards minimalistic, often monochrome designs 00:16
i.imgur.com/lPHJfcC.jpg :) 00:19
\o/ it resolves for me already 6lang.party/ 00:22
Zoffix notices the benefit of "6lang" getting prime spot when sorted alphabetically with other names 00:23
Zoffix now needs to redesign book covers :P 00:24
MasterDuke ugh, it can be annoying testing changes when roast also changes underneath ones-self 00:29
travis-ci Rakudo build passed. Zoffix Znet 'Remove Perlism' 00:30
travis-ci.org/rakudo/rakudo/builds/280486168 github.com/rakudo/rakudo/compare/2...334512483f
Zoffix MasterDuke: note there are currently a couple of present failures 00:31
These ones gist.github.com/zoffixznet/d2ce77e...7fb398009a
lizmat++ is working on fixing the tests ATM
s/M/time period/;
MasterDuke cool, thanks 00:32
AlexDaniel Zoffix: speaking of posters, will we have a SQUASHathon poster this time? :) 00:35
maybe just s/September/October/ will do 00:36
cognominal samcv, with added camelia, no need to add more color 00:43
with such a short name, one can prepend an optional buzzword : reactive 6lang 00:46
Zoffix I'll try to make it 00:47
.in 15h squashathon poster 00:48
yoleaux Zoffix: I'll remind you at 15:48Z
Geth rakudo/nom: 3341384bfe | (Zoffix Znet)++ | 2 files
[6.d] Deprecate IO::Handle.slurp-rest
00:58
6.d-prep: 37ed0b5228 | (Zoffix Znet)++ | TODO/completed-FEATURES.md
Mark IO::Handle.slurp-rest as completed
01:01
rakudo/nom: 39a4b75b59 | (Zoffix Znet)++ | t/02-rakudo/v6.d-tests/01-deprecations.t
Restructure test routines

So they're used as 1 routine = 1 added to plan. Easier to count.
01:10
travis-ci Rakudo build passed. Jonathan Worthington 'Do not resume after emit by closed `supply` block' 02:36
travis-ci.org/rakudo/rakudo/builds/280521317 github.com/rakudo/rakudo/compare/5...f883bc7b18
TimToady notes that 6lang isn't gonna work anywhere an identifier needs a leading alpha 03:15
it's also not a terribly sexy name
I could go for something more like psix, "where the p is silent if you want it to be" :) 03:16
TimToady is currently packing up to go home from .jp, so will likely be offline for a day or so 03:18
geekosaur the world has survived go and c#, it will manage :p 03:32
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Stage 1 of auto-generated BUILDALL methods 03:36
travis-ci.org/rakudo/rakudo/builds/280532659 github.com/rakudo/rakudo/compare/8...37687d93c9
AlexDaniel If we see “6lang” as a more marketable alternative, then the fact that some things may not parse it as an identifier practically does not matter. However, this little bit is quite useful: 04:14
m: <perl5 golang c# 6lang ruby>.sort.say
camelia (6lang c# golang perl5 ruby)
AlexDaniel :)
.oO( AAAlang – batteries included )
04:15
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Minimally invasive streamline Proc::Async.new' 04:27
travis-ci.org/rakudo/rakudo/builds/280537659 github.com/rakudo/rakudo/compare/9...0ebabc39ec
Rakudo build passed. Zoffix Znet 'Implement language version testing in &DEPRECATED 05:08
travis-ci.org/rakudo/rakudo/builds/280543575 github.com/rakudo/rakudo/compare/b...bc8e2d95b2
nine ~~ 05:28
yoleaux 27 Sep 2017 17:08Z <Zoffix> nine: you package some stuff so maybe you know: I want to add a helper test module to Rakudo's test suite. I heard that `make test` must not create any new test files or something, so I'm wondering, would that module need `no precompilation` so that it doesn't create any precompilation files when `make test` is run?
nine .tell Zoffix make test already creates precomp files as tests use the Test module, so I wouldn't worry about that. An easy way to not write into the source tree woud be running with -I/tmp/some-temp-dir 05:30
yoleaux nine: I'll pass your message to Zoffix.
nine .tell Zoffix technically you can change to 6.d any time. You cannot downgrade. Practically the compiler's behavior is very, very confusing when you switch to 6.d in the middle of a file. That's why we want to prohibit that. We can always relax such a restriction later on.
yoleaux nine: I'll pass your message to Zoffix.
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Revert "Minimally invasive streamline Proc::Async.new" 05:55
travis-ci.org/rakudo/rakudo/builds/280556339 github.com/rakudo/rakudo/compare/3...7f0f83c9bf
[Tux] I ran it twice, just to be sure :( 06:28
This is Rakudo version 2017.09-132-g39a4b75b5 built on MoarVM version 2017.09.1-50-g3059ba28 06:29
csv-ip5xs 1.339 - 1.578
test 9.930 - 10.076
test-t 3.569 - 4.010
csv-parser 12.803 - 13.827
travis-ci Rakudo build passed. Zoffix Znet 'Deprecate dummy arg on .Rat/.FatRat… 06:37
travis-ci.org/rakudo/rakudo/builds/280573630 github.com/rakudo/rakudo/compare/1...337e8ef9fa
Rakudo build passed. Elizabeth Mattijsen 'Stage 2 of auto-generated BUILDALL methods 07:25
travis-ci.org/rakudo/rakudo/builds/280633116 github.com/rakudo/rakudo/compare/4...cf246fd4ca
lizmat wonders if this is the correct way of handling auto-generated BUILDALL in tests: github.com/perl6/roast/commit/031b9cecdd 07:54
[Tux]: it's doing the extra work of generated BUILDALL, but not reaping the benefits of it yet 08:01
Zoffix . 08:15
yoleaux 05:30Z <nine> Zoffix: make test already creates precomp files as tests use the Test module, so I wouldn't worry about that. An easy way to not write into the source tree woud be running with -I/tmp/some-temp-dir
05:30Z <nine> Zoffix: technically you can change to 6.d any time. You cannot downgrade. Practically the compiler's behavior is very, very confusing when you switch to 6.d in the middle of a file. That's why we want to prohibit that. We can always relax such a restriction later on.
Zoffix Thanks!
The identifier thing occured to me yesterday, when I thought about our .perl method, but you can always do "slang" and if it's an alt-name only and not a full rename, then people can do "p6" instead. 08:20
6lang is pretty sexy. "psix" IMO isn't... it got pee in it :}
Someone saying "slang" would have bad reputation: twitter.com/lumbininep/status/9132...5462496256 08:30
Zoffix doesn't get why
lizmat www.urbandictionary.com/define.php?term=slang perhaps ? 08:40
stmuk what about another gemstone?
"Beryl often crystallizes in perfect, six-sided hexagons"
lizmat
.oO( it's a Beryl of fun )
08:41
Zoffix I don't see anything iffy on that UD page 08:42
lizmat hence my "perhaps" :-) 08:43
Zoffix ah
teatime there's already an open-source project called Beryl 08:45
(naming things)-- 08:46
lizmat hmmm.. it appears Geth is not alive, or github is slow 08:47
Zoffix Yeah, not in the channel
lizmat just pushed github.com/rakudo/rakudo/commit/5a...ac01272d4a 08:48
Zoffix (Geth_ is my old copy that isn't hooked up to rakudo/roast)
lizmat Stage 3 of auto-generated BUILDALL
- Mu.BUILDALL has become an only again, taking a useless array as first para
- Mu.new/bless have been adapted to this
- auto-generated BUILDALL now also an only, taking the array also
- however is not installed yet, as that breaks building the setting
This should make test-t faster again and spectest clean.
afk for a few hours&
Zoffix nine: ping Geth seems to have disconnected (and I haven't had a chance to fix that bug in IRC::Client yet :()
stmuk beril is more restrospective acronym fitting friendly! 09:09
butterfly enhanced rubbish interpreting language 09:19
gfldex .tell lizmat did you see www.nntp.perl.org/group/perl.perl6...g4318.html ? 09:23
yoleaux 27 Sep 2017 12:42Z <tbrowder> gfldex: Zoffix says you have a fast travis yml, can you let me see it? thanks
gfldex: I'll pass your message to lizmat.
Zoffix commit 43c348a8e7006978057fad2e360a700d263fcbd8 09:42
Author: Zoffix Znet [email@hidden.address]
Date: Thu Sep 28 05:41:48 2017 -0400
Undo unintended aliasing of ≤, ≥, ≠ ops
With userland-defined Texas versions.
Zoffix just pushed
travis-ci Rakudo build failed. Zoffix Znet 'Restructure test routines 09:53
travis-ci.org/rakudo/rakudo/builds/280681782 github.com/rakudo/rakudo/compare/3...a4b75b59bf
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
Zoffix github error 10:01
nine Zoffix: fixed, thanks for pointing that out!
Zoffix Thanks! 10:02
lizmat . 10:17
yoleaux 09:23Z <gfldex> lizmat: did you see www.nntp.perl.org/group/perl.perl6...g4318.html ?
lizmat gfldex: yes, I even mentioned it in the P6W :-)
Zoffix New blog post: "6lang: The Naming Discussion Update": 6lang.party/post/6lang-The-Naming-...ion-Update 10:20
gfldex lizmat: I tried it to parse DateTime heavy JSON and it makes a big difference 10:26
lizmat gfldex: if you could devise some piece of code that I could --profile to find out where the bottleneck is, that would be brill! 10:27
gfldex lizmat: I also wonder if it would make sense to keep the original Str around and parse it lazily for cases where JSON is just turned back into JSON after holding the DateTime briefly 10:28
lizmat: example that uses RL-data gist.github.com/gfldex/000b2c3e8da...5f643a1ecd 10:30
Geth 6.d-prep: d8cb95181f | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/README.md
List 6lang update in the naming section
10:31
rakudo/nom: 31a03a41f0 | (Elizabeth Mattijsen)++ | src/core/Lock/Async.pm
Fix chicken/egg problem with Lock::Async::Holder

Trying to call .new at compile time on a class that refers to an outer class that has not been composed yet, explodes at least during setting compilation (without much useful feedback).
Since the .new was without parameters, a simple nqp::create is enough.
This allows setting compilation to complete with auto-generated BUILDALL installed. But "make install" still fails :-(
10:51
dogbert2 .seen Zoffix 11:16
yoleaux I saw Zoffix 11:01Z in #perl6: <Zoffix> squashable6: status
dogbert2 Zoffix: when changing the t/spec/VERSION file to 6.c should it complain about missing test files when starting the spectest? 11:18
Testing Roast version 6.c using test file list from t/spectest.data.6.c
Missing test file: t/spec/S03-operators/bag.t
...
Zoffix dogbert2: you don't change the version, you checkout 6.c-errata. Yes it should complain, since that file is not in master branch 11:29
Prolly should add extra make targets to stresstest/spectest multiple language versions 11:32
And prolly should rip out the 'use v6.c' (if we got it) from master test files but stick it into released roast versions 11:33
Zoffix & 11:34
dogbert2 oh, my mistake, was a bit annoyed wrt to the increased spectest time and stupidly thought that I could get back to the 'old' spectest.data by way of a VERSION change 11:39
Zoffix m: constant s'lang = 'works as ifentifier'; say s'lang 11:40
camelia works as ifentifier
Zoffix dogbert2: how much is the increase? the new multi-roast should be a few milliseconds faster, if anything, since it no longer runs the 4-6 dummy test files 11:42
(on master)
m: for ^10000 { DEPRECATED 'meow', '6.d', '6.e', :lang-vers }; say now - INIT now 11:45
camelia 2.8320810
Zoffix ouch
That's prolly why slower 11:46
Gonna take a look into it after $work
Zoffix &
m: $*PERL.^lookup('version').file.say 12:16
camelia /home/camelia/rakudo-m-inst-1/share/perl6/runtime/CORE.setting.moarvm
jdv79_ Zoffix: why did you say "in 5? in your poster? i'd have used 6 or at least not 5 - reminds me of p5 but could be me. 12:36
Zoffix "9 to 5" 12:37
9/2 => 5 12:38
jdv79 oh, i guess
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Fix chicken/egg problem with Lock::Async::Holder 12:39
travis-ci.org/rakudo/rakudo/builds/280815689 github.com/rakudo/rakudo/compare/4...a03a41f0e3
Zoffix jdv79: changed. Thanks: github.com/perl6/marketing/blob/ma...oncise.png 12:50
lizmat timotimo jnthn: still puzzeled about how to attach type object name to generate BUILDALL method :-(
Zoffix oh damn, overwrote over the wrong file 12:51
jnthn "type object name"? 12:54
jdv79 every single thing you ever wanted to do could be done in 6 hours if only you used 6lang! 12:57
good stuff;) 12:58
timotimo lizmat: attach where? 13:04
lizmat well, somewhere that would show up in stack traces
timotimo ooooh
yeah, that's tricky
lizmat now, if something blows in the generated BUILDALL, there's no way to tell which BUILDALL 13:05
timotimo not worse than before :P
lizmat well, so far I got it to build the setting
but loading any module with "use" dies 13:06
somewhere
timotimo right :(
lizmat most likely in CompUnit::DependencySpecification
timotimo stack trace should tell you which .new was called though?
lizmat but that's probably just the first
that's usually Mu.new if BUILDALL is in play anyway
Geth rakudo: gerd++ created pull request #1174:
add documentation to use the script
13:08
jnthn If we had the $/ of the class decl, we could just put the file/line number there 13:11
Then it'd at least point straight at the class it was generated for
Geth rakudo/nom: b7f8daf001 | gerd++ | tools/install-dist.pl
add documentation to use the script
rakudo/nom: fe75e31b43 | lizmat++ (committed using GitHub Web editor) | tools/install-dist.pl
Merge pull request #1174 from gerd/nom

add documentation to use the script
lizmat jnthn: do we have $/ around at compose time ? 13:12
jnthn m: class A { has $.a }; A.a 13:15
camelia Cannot look up attributes in a A type object
in block <unit> at <tmp> line 1
jnthn m: class A { has $.a }; A.a; CATCH { Backtrace.new.full.note }
camelia in code at SETTING::src/core/Backtrace.pm line 85
in method new at SETTING::src/core/Backtrace.pm line 85
in block at <tmp> line 1
in block <unit> at <tmp> line 1

Cannot look up attributes in a A type object
in block <unit> at <t…
lizmat m: class A { has $.a }; dd A.can("a")[0].signature # yet the signature appears to be ok ?? 13:16
camelia :(A:D $: *%_)
lizmat m: class A { has $!a; method a(A:D:) { $!a } }; dd A.can("a")[0].signature # yet the signature appears to be ok ?? 13:17
camelia :(A:D $: *%_)
jnthn heh, I had no idea it has that signature :P
lizmat m: class A { has $!a; method a(A:D:) { $!a } }; dd A.a
camelia Invocant of method 'a' must be an object instance of type 'A', not a type object of type 'A'. Did you forget a '.new'?
in method a at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn I expected the error it gave :)
I was looking at whether the accessor method's line/file pointed to the declaring mocation 13:18
lizmat so somehow, the method is not generated the same was as if done by hand
jnthn Well, more like a :D is sneaked into the signature but the code that's compiled doesn't reflect it
The easy fix is to make the signature more truthful
jdv79 lizmat: what exactly has you on this quest to lazify construction? 13:19
jnthn Anyway, that's not relevant
For the current topic at hand
lizmat jdv79: it's not about lazifying
jnthn: sorry I misunderstood the topic :-) 13:20
jdv79: this is about making all object creation using Mu.new about 1.5x faster (preliminary benchmarks)
jnthn I was checking if the line/file are set on the generated method, 'cus I didn't fancy looking at the code :P
jdv79 ok
jnthn Now I'm looking at the code and they aren't in that case either
jdv79: At the moment, we interpret the setup of objects using a loop in Mu.BUILDALL. That means all the attribute lookups, attribute default thunks, and BUILD method calls are late-bound and megamorphic. lizmat is looking at compiling that setup work instead of interpreting it. 13:22
Zoffix \o/ 13:23
jnthn lizmat: Ah, there's not an easy way to pass the $/ down at the moment
lizmat ok, I had come to that conclusion also :-( 13:24
jnthn But there's perhaps an easy solution
lizmat I hope so :-) 13:25
jnthn Add a $!current-match or some such to CompilerServices
And then pass $/ to get_compiler_services
And have it bind the $/ (which we have at that point) into the attribute
lizmat ah, ok
jnthn Doing it every time, not in the unless nqp::isconcrete(...)
It's cached on a World and a World isn't shared between concurrent compiles, so it'll be safe :) 13:26
(The "it" in this case being the CompilerServices instance)
jdv79 i was just curious what the motivating source was
lizmat yeah, gotcha
jdv79: a question I asked jnthn at the SPW: what would be a good place for me to work on optimization :-) 13:27
jnthn Object setup is a bottleneck at the moment 13:28
And the interpreter approach missed out on a lot of nice things spesh can do
jdv79 ah. very nice.
lizmat jnthn: what about auto-generating .new instead of BUILDALL ? 13:29
jnthn Like inlining a small BUILD submethod or attribute default thunk into the generated BUILDALL
lizmat: That means folks writing a custom new having other constructors wouldn't be able to take advantage of this 13:30
*or having
Zoffix "This representation (P6int) cannot unbox to other types (for type int)"
what's that mean?
jnthn Did you get it from NQP code of Perl 6 code?
*or 13:31
Zoffix Perl 6
m: use nqp; my \a := v1.2; my \b = v1.3; $ = nqp::getattr(nqp::decont(a),Version,'$!plus') cmp nqp::getattr(nqp::decont(b),Version,'$!plus')
camelia This representation (P6int) cannot unbox to other types (for type int)
in block <unit> at <tmp> line 1
jnthn Odd, I dunno how you ended up with a boxed form of a native type
That isn't Perl 6, it's Perl 6 with nqp:: ops, so all bets are off :P 13:32
Zoffix $!plus is `has int $!plus`
jnthn ohh
Zoffix Ah, ok :)
jnthn then that's the problem
Should use nqp::getattr_i :)
Zoffix Ohhhh. Right. Thanks!
lizmat jnthn: yeah but no but 13:43
so the R:I:CompilerServices now has the $!current-match attribute 13:44
ahh. sorry
figured it out
jnthn puts away the stuffed bear costume :) 13:46
Zoffix :o 13:47
jnthn heh, I thought everyone knew the "Before you tell your problem to IT support, first explain it to this stuffed bear" story :-) 13:48
(A good number of problems are solved by a realization that comes when trying to explain it to somebody else. :))
Zoffix I know that as explaining to a rubber duck 13:49
lizmat jnthn: the accessor / buildall generator methods now take $/ as the first param
and I've added a ":node($/)" to the QAST::Block 13:50
don't see a difference just yet :-(
jnthn I think it needs to go on the QAST::Stmts 13:51
lizmat ack
Zoffix ZOFFLOP: t/spec/S11-modules/nested.t 13:52
ZOFVM: Files=1275, Tests=152190, 139 wallclock secs (20.62 usr 3.28 sys + 2925.76 cusr 198.47 csys = 3148.13 CPU)
Geth rakudo/nom: 1d9553f01f | (Zoffix Znet)++ | src/core/Version.pm
Make &inifx:<cmp> with Version:Ds 7.2x faster

Now that we use DEPRECATED sub in more places due to 6.d changes, this op becomes more used, so we needed a perf boost.
Makes `v6.c cmp v6.d` 8.8x faster
13:54
gfldex m: my @l = <a b c>; @l = @l xx 2; dd @l; 14:19
camelia Array @l = ((my @Array_59828440) = [@Array_59828440, @Array_59828440])
gfldex should xx procude a circual list in this case?
jnthn No 14:20
lizmat m: 'my @l = ^10; my @m = @l xx 2; dd @m # no
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'"
at <tmp>:1
------> 3y @l = ^10; my @m = @l xx 2; dd @m # no7⏏5<EOL>
expecting any of:
single quotes
jnthn xx doesn't automatically flatten its LHS
lizmat m: my @l = ^10; my @m = @l xx 2; dd @m # no
camelia Array @m = [[0, 1, 2, 3, 4, 5, 6, 7, 8, 9], [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]]
jnthn m: my @l = <a b c>; @l = |@l xx 2; dd @l 14:21
camelia Array @l = ["a", "b", "c", "a", "b", "c"]
Zoffix was going with "yes"
jnthn And when we do slip it, then we've extracted the values
m: my @l = <a b c>; @l = |@l xx *; dd @l[^20] 14:22
Zoffix @l = @l xx 2 is like @l = @l, @l to me, so yes, you get circular values
camelia MoarVM panic: Memory allocation failed; could not allocate 25904 bytes
jnthn Oh, that kind of circular
I thought it was meant as "repeating eternally"
Zoffix Oh
jnthn hah
In that case yes, it should produce a self-referencing thing :)
Dunno why I didn't read it that way in the first place 14:23
gfldex jnthn: I found a nice new bug for you. For $repetitions < 64 this works: gist.github.com/c0af5f2033e2cfa5b8...17712d0d27 14:25
(and is fast :)
Geth rakudo/nom: eb9c3d4dd7 | (Elizabeth Mattijsen)++ | 2 files
Add $/ to CompilerServices
14:26
lizmat jnthn: still no luck on where to add :node($/) exactly
Geth rakudo/nom: 145e3156ca | (Zoffix Znet)++ | src/core/Deprecations.pm
Make &DEPRECATED 27% faster when vfrom is too large

  - This is the case for 6.d deprecations used in 6.c language
  - The speedup measure does not include Version cmp boost[^1]
  [1] github.com/rakudo/rakudo/commit/1d9553f01f
14:28
Zoffix m: for ^10000 { DEPRECATED 'meow', '6.d', '6.e', :lang-vers }; say now - INIT now 14:38
camelia 2.2482009
gfldex jnthn: it does work for some values > 64 and seams to depend on the nr. of physical cores 14:40
jnthn There's concurrency in there? 14:41
oh heck, .hyper 14:42
There's still a load of RTs about that. It needs a lot of attention. :(
Zoffix Yeah, the docs list it as experimental: docs.perl6.org/routine/hyper 14:44
jnthn It's on my "stuff to try and take care of for 6.d" list 14:46
Probably it's the next big thing I'll work on, now that the scheduler and supply changes are in
Geth rakudo/nom: 346dfeff3e | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
Make auto-generated accessors know what they are

Turns out :node($/) does need to be added to the first QAST:Stmts. This became clear after git stashing all of the other stuff I was working on.
gfldex jnthn: also it's a heisenbug 14:47
lizmat m: class A { has $!a; method a() { $!a } }; dd A.a # looks like auto-generated accessors are equivalent to this 14:48
camelia Cannot look up attributes in a A type object
in method a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: class A { has $!a; method a(A:D:) { $!a } }; dd A.a # as opposed to this 14:49
camelia Invocant of method 'a' must be an object instance of type 'A', not a type object of type 'A'. Did you forget a '.new'?
in method a at <tmp> line 1
in block <unit> at <tmp> line 1
ugexe heads up: i guess the BUILDALL changes break zef, and while its use of BUILDALL can be changed to TWEAK (which is what I would have used if it existed at the time anyway) it won't help existing zef installations for a rakudo that gets upgraded 14:56
lizmat ugexe: how does it break zef ? could you be more specific ? 14:58
ugexe github.com/ugexe/zef/pull/208
i havent looked into it anymore than reading that PR just now
lizmat ugexe: BUILDALL is an only again now 14:59
could you pull?
ugexe: having said that, TWEAK looks like the better option anyway 15:00
oddly enough, BUILDALL has been a multi for over a year 15:02
ugexe i see no problem on HEAD 15:07
lizmat *phew*
still, TWEAK would be better
Zoffix FWIW all the broken tests are passing again
all stresstest passes
lizmat guys, sorry for the noise, but putting this in a branch would just have meant these issues would prop up much later 15:10
Zoffix :) 15:12
Looks like Mexico is a bad name for Unicode ops 15:15
lizmat fwiw, I think Unicode ops is a better description 15:16
I guess we could also go for s/Texas/ASCII/ 15:17
Geth rakudo/nom: a89add0bf8 | (Zoffix Znet)++ | src/Perl6/Optimizer.nqp
Remove term "mexico ops" from source

It's not a good name for Unicode alternatives to Texas ops for reasons.
Fixes RT#132179: rt.perl.org/Ticket/Display.html?id=132179
Zoffix ASCII is good as it lets people unfamiliar with our jargon easily figure out what it means. 15:21
lizmat FWIW, I'm pretty confident that the auto-generated BUILDALL will take about .1 from test-t 15:27
Zoffix \o/
lizmat perhaps more now that the optimizer can optimize better on it 15:29
jnthn timotimo nine: does this ring any bell? Cannot perform this operation on an uninstantiated definite type 15:34
afaict, this happens when trying to run a pre-compiled BUILDALL 15:35
timotimo if it were me i'd grep moarvm source for that string, break on it in gdb and call MVM_dump_backtrace(tc) 15:36
jnthn No, but it sounds like something about :D 15:37
lizmat yeah, that much I know as well
for a while I thought this could be because the invocant_type was not in the SC 15:38
timotimo not helpful that it says "this operation" :)
lizmat but $*W.create_definite_type appears to put it in the SC 15:39
at gen/moar/Metamodel.nqp:3834 (blib/Perl6/Metamodel.moarvm:check_instantiated)
from gen/moar/Metamodel.nqp:3839 (blib/Perl6/Metamodel.moarvm:base_type)
from gen/moar/Metamodel.nqp:3885 (blib/Perl6/Metamodel.moarvm:type_check)
jnthn What do you do with the result of that
lizmat nothing
I *think* it's because the invocant is marked :D 15:40
(on the generated BUILDALL)
jnthn nothing?
Like, not even use it somewhere?
lizmat afaics, it happens when Mu.new does a self.BUILDALL
going to try without the :D on the BUILDALL invocant 15:41
timotimo oh, doesn't BUILDALL do nqp::create first of all? 15:42
i.e. should almost always be called on a type object?
jnthn It's always called on an instance 15:43
lizmat ahh.. could it be the return value is weird ?
yoleaux Zoffix: squashathon poster 15:48
lizmat jnthn timotimo: should one need more than this as the final op? $stmts.push(QAST::Var.new(:name('self'), :scope('local')));
??
jnthn No, that should return self 15:49
Is latest code pushed?
I can see if I can spot the problem...
lizmat lemme make sure the debug stuff isn't in there 15:52
Geth rakudo/nom: 70ca505ad0 | (Elizabeth Mattijsen)++ | 2 files
Stage 5 of auto-generated BUILDALL

  - fallback to Mu.BUILDALL if the BUILDPLAN is empty
   although the methods were shared, there was no point as Mu.BUILDALL
   needs to exist anyway to handle object creation before Rakudo::Internals
   is parsed during setting compilation.
  - do not try to make/install a BUILDPLAN if there is one already
  - add :note($/) for better error reporting
  - seems to still have an issue when being precompiled
   therefore the BUILDALL is installed as BUILDALL_UNDER_CONSTRUCTION
   as to not interfere with anything out there just yet.
16:02
lizmat jnthn: ^^^ in ClassHow, remove _UNDER_CONSTRUCTION to get full functionality 16:03
Zoffix .tell AlexDaniel 2017.10 SQUASHathon poster: github.com/perl6/marketing/tree/ma...on/2017.10 16:05
yoleaux Zoffix: I'll pass your message to AlexDaniel.
jnthn lizmat: $!w.create_definite_type( returns the type 16:06
So using it in sink context makes no sense
lizmat looks 16:07
argh
sorry, that slipped through
was an attempt to double check whether the coercion type was the problem 16:08
Geth rakudo/nom: af2ab751b8 | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
We want the definite type, jnthn++
16:10
lizmat jnthn: other than that, any other pointers ? 16:11
jnthn Does github.com/rakudo/rakudo/blob/70ca....nqp#L3024 not need an SVal case?
lizmat no, because the native str case uses nqp::isnull_s 16:12
jnthn ah, ok
That change you just did doesn't change the error?
lizmat no
jnthn hmmmm 16:13
lizmat but I have a bit more info now
I've just added a "... done" at the end of the generated BUILDALL
that is *not* run 16:14
ok, going to get very verbose by adding per action output 16:15
jnthn OK, if you're super stuck lemme know and I can run it locally 16:16
lizmat it seems to die here: 16:21
# nqp::if(
# nqp::existskey($init,'a'),
# nqp::getattr(self,Foo,'$!a') = %init.AT-KEY('a')
# ),
where Foo and 'a' are placeholders
Zoffix 6.c-errata fails t/spec/S12-introspection/methods.t t/spec/S17-supply/basic.t t/spec/integration/advent2009-day11.t. full output: gist.github.com/zoffixznet/fb53eca...51948e85c7 16:34
lizmat yeah, that's again after my last commit 16:35
the tests need fixing
but am not sure what the best way would be
Geth roast/6.c-lang-use-v6c: e59acd6cff | (Zoffix Znet)++ | 26 files
Use `v6.c` instead of `v6` so we get right language version
16:36
roast: zoffixznet++ created pull request #336:
Use `v6.c` instead of `v6` so we get right language version when 6.d comes out
16:37
AlexDaniel
.oO( you really want an identifier? Here: )
16:41
yoleaux 16:05Z <Zoffix> AlexDaniel: 2017.10 SQUASHathon poster: github.com/perl6/marketing/tree/ma...on/2017.10
AlexDaniel m: my \六lang = ‘六’.unival; say 六lang
camelia 6
Geth 6.d-prep: 05bbbbe16b | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Remove .[READ|WRITE|EOF]-SOURCE

I proposed them and no longer like 'em
16:43
Zoffix Some name bikeshedding welcome: github.com/perl6/6.d-prep/blob/mas...f-internal
Don't wanna spec "*-internal" because everywhere else "internal" means Rakudo-only guts that users must not be using. 16:44
jnthn maybe just uppercase (READ, WRITE, EOF) as we call other "called for you" methods 16:45
Zoffix +1 16:46
jnthn (AT-POS, CALL-ME, etc.)
lizmat jnthn: I think the problem occurs in the lines following github.com/rakudo/rakudo/blob/70ca....nqp#L3388 16:52
jnthn In that area, should try and get a way to change the output buffer size on an existing handle into 6.d also 16:53
Geth 6.d-prep: 559215bc74 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Add TODO: buffer size on existing IO::Handle
16:55
6.d-prep: 386cdc682c | (Jonathan Worthington)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Update status of non-blocking await
16:58
lizmat jnthn: ok, so, if I change the Str:D and Int:D in CompUnit::DependencySpecification to natives, all is fine 16:59
jnthn Oh, so it's a type check on those attrs... 17:01
But...why'd that be happening any differently here 17:02
The assign should be coming out the same
Does it work if you use p6store for everything instead of assign? That's the only difference I can immediately thing of, but it really shouldn't be the issue... 17:03
jnthn builds locally to tinker also 17:05
lizmat already tried that
also, adding a decont
like I do in the native case
jnthn What's supposed to go wrong? 17:08
I was expecting the build to explode 17:09
oh, make test fails
OK, I see the error
lizmat anytime you try to use a module 17:10
BTW, removing the :D from the sig in CU:DependencySpecification gives a different error message 17:11
jnthn Trying to reproduce it outside of CORE.setting 17:13
But things with a :D type there seem to work out
lizmat ./perl6 --ll-exception -I. -e 'use Foo'
does it for me, where Foo.pm is a file containing class A { has $.a } 17:14
jnthn Oh, for sure, I meant that I can't write something like -e 'class C { has Str:D $.foo is required }.new' and have it blow up 17:16
lizmat somehow it has to do with precomp
jnthn Urgh
But yeah, I'm sorta suspecting that
what about -e 'class A { has A:D $.x is required }' ? 17:17
uh, with .new
jnthn rebuilding locally
lizmat jnthn: is required is a separate action: it doesn't get there 17:18
if blows on trying to read from the %init hash
afaics
jnthn I was figuring it blows on the assign?
'cus that's what'd trigger the type check
lizmat I guess 17:19
jnthn oh, if I remove all the :D in CompUnit dependency class, then it loads a module and passes the test
For 53-transpose.t anyway
lizmat make install doesn't work for me with :D removed 17:20
the error seems to point to the attribute not being properly inited 17:21
Cannot find method 'item': no method cache and no .^find_method
timotimo something in $ context? 17:22
jnthn Does make test work for you with it removed?
Dinner time here, anyways
bbl
lizmat make test is clean 17:23
timotimo i put lots of debug says in there and it is indeed what you pointed out. for the short-name hash key 17:24
it's "is required" and has a :D on it
could the "is required" be problematic? 17:25
lizmat no, because that is a different action
it doesn't get there
timotimo ah, ok 17:26
we have two entries to make "is required" work?
right, the check has to go at the very end, doesn't it 17:27
lizmat yup
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Add $/ to CompilerServices' 17:36
travis-ci.org/rakudo/rakudo/builds/280892841 github.com/rakudo/rakudo/compare/1...9c3d4dd779
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
lizmat afk for a bite or two& 17:38
Zoffix travis: Stage parse : Segmentation fault (core dumped) 17:41
timotimo i don't understand why it'd think that Str:D is not parameterized 17:48
BBL 17:49
(actually, not bbl. change of plans.) 17:50
Zoffix I'm not following this commit... why is .find_lexical() needed? github.com/rakudo/rakudo/commit/43...0d263fcbd8 17:57
I compiled without it now and it's no longer texifying the op.... but I don't get why. WOuldn't find_lexical not find anything (without user's use of the op) and throw and should-texify would return 0 and not texify anything? 17:58
timotimo find_lexical also goes into the core setting 18:04
or do you mean these don't exist any more at all?
Zoffix No, they should exist. I don't get get why find_lexical is needed in that code at all. Looks like .is_from_core rakes through blocks 18:07
Or maybe it don't exist. Like this line looks for it: github.com/rakudo/rakudo/blob/nom/....nqp#L1410
ZofBot: whatishaaapenning? 18:08
ZofBot Zoffix, i like this change
Zoffix hm, well this change does result in a texified unicode op but if I remove .find_lexical, then it doesn't (I think; gonna try again now): gist.github.com/zoffixznet/7ac7991...06543639d9 18:11
timotimo it could be is_from_core expects you to check for existence first, but i don't know 18:13
Zoffix Ah, OK, is_from_core looks for <value> and find_lexical converts <lazy_value_from> to <value> 18:16
timotimo oh 18:23
Geth 6.d-prep: af6896ca6e | (Jonathan Worthington)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Add a couple more 6.d things I'm planning
18:46
Zoffix m: ' foo bar baz' ~~ /[\s+(\S+)]+/; my ($foo, @bar) = $/.list.head; say $foo, '###', @bar;
camelia 「foo」###[「bar」 「baz」]
Zoffix jdv79: ^ it's not so much about itemization but that .list's first element contains an entire Array with all the captures. You basically have list of list, so you need to go one level deeper if you wanted what you wanted 18:47
AlexDaniel fwiw there's now 6lang.org that redirects to perl6.org (including subdomains). Better safe than sorry. I'm not interested in keeping the control over the domain so please get ready for the transfer at some point (60 is days is probably what we'll have to wait? ping moritz?). I'll prepay it for a few years ahead before the transfer. 18:49
Zoffix \o/
"60 is days is probably what we'll have to wait?" hm? wait for what? 18:50
AlexDaniel there's some limit for freshly registered domains, I think
Zoffix Ah
AlexDaniel “You must wait 60 days after the initial registration or any previous transfers to initiate a transfer.” 18:51
Zoffix m: ' foo bar baz' ~~ /[\s+(\S+)]+/; my (@ ($foo, *@bar)) := $/; say $foo, '###', @bar;
camelia 「foo」###[「bar」 「baz」]
Zoffix ehehe <3 signature-based `my` 18:52
m: my (@ ($foo, *@bar)) := ' foo bar baz' ~~ /[\s+(\S+)]+/; say $foo, '###', @bar; 18:53
camelia 「foo」###[「bar」 「baz」]
Zoffix lovely
AlexDaniel++ # domain
Geth rakudo/nom: 9ff2f98f79 | (Zoffix Znet)++ | src/Perl6/Optimizer.nqp
Polish unicode -> ascii op converter

  - Explain why .find_lexical is needed
  - Move the call to converter after .find_lexical is called for
   target op
  - Remove args that weren't used in the helper sub
18:56
AlexDaniel also, if somebody can add 6lang.org alias to existing websites then I'll change the dns entry right away (so that modules.6lang.org opens up without a redirect) 19:00
AlexDaniel finds this comment interesting www.reddit.com/r/perl/comments/72s...l/dnlnrde/ 19:36
some people really flip the table even if you're changing something for a good reason
Zoffix Yeah 19:37
I flipped out at HTTP::Server::Tiny changing stuff under me twice ina week 19:38
It's really annoying.
jdv79 Zoffix: thanks 19:39
Zoffix I don't know if we're going to be similarly affected as that comment suggest, once we get the language versioning going full speed. Since if you got `use v6.c` or whatever in your code, you're basically not getting any new changes, even if you upgrade your compiler 19:40
FWIW, p5porters filed a ticket (and PR I think?) on my crappy and unloved ZofCMS just to fix the regex { bugs and then followed up on whether the fix was applied, so they did a very thorough job of reducing fallout 19:41
Geth rakudo/nom: d60ba6339a | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
HLLize shortname parameter to CU::DependencySpecification

This change makes all of the auto-generated BUILDALL stuff work.
Theory is that having a native str as a named parameter doesn't jive well with doing Str:D checking. But this can apparently only happen when being called from NQP, as in Perl 6 a native str will be hllized automatically.
20:19
timotimo wow 20:28
that's a good find, damn
lizmat well, turns out it isn't the fix :-( 20:30
I thought it was :-(
timotimo hold on 20:31
you're hllizing it to nqp aren't you?
wouldn't you have to nqp::hllizefor($stuff, "perl6")?
lizmat not sure what I was thinking there
ahhhh
lowercase 'perl6' ? 20:32
not 'Perl6' ?
looks like lowercase
timotimo not sure 20:33
lizmat ack tells me yes
ok, now I get: Something went wrong in (Assignment) 20:35
timotimo huh
AlexDaniel
.oO( is that… a butterfly?? www.amazon.com/gp/product/1680500880 )
20:36
timotimo where does that come from ..
lizmat no idea, but I'm getting *really* fed up :-(
timotimo an exception has that in its message method 20:37
oh, huh.
that's the class of exception 20:38
probably X::TypeCheck::Exception?
its message method potentially also threw an exception 20:39
lizmat I'm going to nativy all of the :D attributes in CU::DependencySpecification
that solves the issue
Geth rakudo/nom: 04ea446dd3 | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
Revert "HLLize shortname parameter to CU::DependencySpecification"

This reverts commit d60ba6339a75863cd8720fb5db7c0d5b535f0cd3.
20:43
rakudo/nom: 5cd9197fe3 | (Elizabeth Mattijsen)++ | src/core/CompUnit/DependencySpecification.pm
Nativy :D attributes on CU::DependencySpecification

Seems to be the only way to get auto-generated BUILDALL to work.
20:47
rakudo/nom: 6824e19282 | (Elizabeth Mattijsen)++ | 2 files
Stage 6 of auto-generated BUILDALL

  - auto-generated BUILDALL now installed as BUILDALL
  - so all classes have their own BUILDALL
   unless there was nothing to do, in which case they fall back to Mu.BUILDALL
  - removed/commented out debugging ops
Benchmarks show that .new on a class that uses Mu.new and named parameters, is now about 1.5x as fast. This means .2 seconds faster for test-t on my machine (about 9% faster).
20:57
lizmat now starting on cleanup of broken tests
timotimo sounds good 20:58
i wonder what opportunities await for speshing 20:59
lizmat who knows :-) 21:01
I think we also need to teach Optimizer.nqp to ignore autogenerated BUILDALL methods
no need to look in there
Geth roast: d89dc5b4b4 | (Elizabeth Mattijsen)++ | S11-compunit/compunit-dependencyspecification.t
Make failure tests less specific
21:02
roast/6.c-errata: 89f05034ae | (Elizabeth Mattijsen)++ | S11-compunit/compunit-dependencyspecification.t
Make failure tests less specific
21:03
roast: 0b90da2ece | (Elizabeth Mattijsen)++ | S12-introspection/methods.t
Make sure we only look at first 3 methods

Thereby ignoring any auto-generated methods like BUILDALL
21:06
roast/6.c-errata: 4388150623 | (Elizabeth Mattijsen)++ | S12-introspection/methods.t
Make sure we only look at first 3 methods

Thereby ignoring any auto-generated methods like BUILDALL
21:07
lizmat argh, it looks like t/spec/S32-str/sprintf.t is a real casualty :-( 21:09
Geth roast: b29c9ce977 | (Elizabeth Mattijsen)++ | integration/advent2009-day11.t
Make sure we only look at first 2 methods

Thereby ignoring any auto-generated methods like BUILDALL
21:12
timotimo don't think it'll make a big difference whether we look in there or not 21:13
Geth roast/6.c-errata: 370efd2cbb | (Elizabeth Mattijsen)++ | integration/advent2009-day11.t
Make sure we only look at first 2 methods

Thereby ignoring any auto-generated methods like BUILDALL
timotimo it's nice and flat as far as the optimizer is concerne
bigger wins are probably in other places in the optimizer
lizmat ok 21:15
judging by t/spec/S32-str/sprintf.t , we still may have some ecosystem fallout of these changes :-( 21:16
dogbert2 htmlify.p6 breaks with the latest rakudo 21:19
===SORRY!===
Missing serialize REPR function for REPR MVMContext (BOOTContext)
lizmat dogbert2: is it really 6824e19282 that breaks stuff ? 21:21
dogbert2 that's the one I'm running
lizmat :-( 21:22
dogbert2 perhaps this gist can tell us something gist.github.com/dogbert17/c637734a...ddcd4e783a
lizmat dogbert2: and 5cd9197fe3707d5136 was ok ? 21:24
dogbert2 I can check ..... 21:26
lizmat please... :-) 21:27
dogbert2 will take a few minutes 21:30
lizmat tell me about it...
I think I've run about 100 core setting builds today 21:31
waiting for that to complete was almost 2.5 hours worth
:-(
timotimo :( :( 21:32
dogbert2 yeah, it takes a while
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make auto-generated accessors know what they are 21:34
travis-ci.org/rakudo/rakudo/builds/280902222 github.com/rakudo/rakudo/compare/1...6dfeff3e2f
buggable [travis build above] ✓ All failures are due to: GitHub connectivity (1 failure).
dogbert2 hmm, tried to build that commit with rakudobrew, which worked, but then I had no modules installed for that version ... 21:38
lizmat ah?
dogbert2 anyway when doing 'zef install OO::Monitors' I get 21:39
===SORRY!===
Missing serialize REPR function for REPR MVMContext (BOOTContext)
lizmat ok, that would be the same error
timotimo: does that ring any bell with you ?
timotimo no :( 21:40
dogbert2 it happens during testing
samcv The Grants Committee would appreciate comments regarding this grant and its state of completion before it votes on whether to approve the work and proceed to payment 21:41
if anyone wants to comment news.perlfoundation.org/2017/09/fin...-perl.html
dogbert2 lizmat: what I can say is that it worked earlier today with 31a03a41f0e3a60 21:43
haven't run it since, well until now that is 21:44
no, strike my last comment, I think it was another version 21:45
dogbert2 is also having trouble with github atm
could there be something here github.com/jnthn/oo-monitors/blob/.../t/BUILD.t 21:47
Zoffix__ so much for a peaceful night of hacking... my Spyware10 updated itself and VirtualBox VM with all my tools no longer starts >:( 21:52
Geth rakudo/nom: 7363f898f6 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals.pm
Move up Rakudo::Internals::CompilerServices

So that other classes inside Rakudo::Internals get a proper autogenerated BUILDALL. Which should allow us to make Mu.BUILDALL a noop basically.
Zoffix__ I can't believe I paid good money for this POS 21:54
dogbert2 the --verbose option of zef says:
t/new.t ........ ok
===SORRY!===
Missing serialize REPR function for REPR MVMContext (BOOTContext)
t/precomp.t ....
lizmat dogbert2: could you check if a revert of 6824e19282e19a0953 fixes it ? 21:57
dogbert2 I can try but if you want to reproduce the error all it takes is 'zef install OO::Monitors' 22:01
jnthn samcv: left a comment :)
Zoffix is re-tooled 22:04
ZofBot: nothing can stop the ZOFFER! 22:05
ZofBot Zoffix, I moved a one that tested a limit with infix:x out of roast already
Zoffix Well, OK. I trust you.
timotimo also left a comment on the grant 22:11
unsurprisingly i'm +1 on proceeding to payment 22:13
dogbert2 unless I'm messing things up, not impossiblem the 04ea446dd3034b9 doesn't work either
dogbert2 is definitely messing up his spelling 22:15
lizmat is getting close to going to bed 22:19
dogbert2: so a revert of 6824e19282e19a0953fc64 didn't fix it ?
dogbert2 I've tried earlier versions and that fails as well, could be doing something wrong ofc 22:23
Geth 6.d-prep: 60a4d8254f | (Zoffix Znet)++ | 2 files
Move implemented features to completed file
Zoffix .tell moritz reminder that you're listed as steakholder for github.com/perl6/6.d-prep/blob/mas...ls-imply-d 22:24
yoleaux Zoffix: I'll pass your message to moritz.
dogbert2 e.g. 346dfeff3e2f4b built with rakudobrew didn't work
lizmat dogbert2: 346dfeff3e2f4b7e54 would also be a candidate to try reverting
dogbert2 building 31a03a41f0e3a6 atm 22:25
Zoffix Lacking better ideas, I"m adding 'die if v6.d' to is_approx() 22:28
No idea how else to remove it :)
Well, other than to actually removing it and then rewriting 6.c-errata's is_approx use. 22:29
dogbert2 lizmat: 31a03a41f0e3a6 works
Zoffix is a bit fuzzy on how all these deprecation+removal are meant to work with roast tests....
lizmat dogbert2: could you test eb9c3d4dd7791ad1b483 ? 22:30
dogbert2 sure 22:31
lizmat is going to bed 22:32
will look again in the morning
but I've had my 11+ hours of settings hacking today 22:33
good night!
dogbert2 night
Zoffix night
dogbert2 .tell lizmat eb9c3d4dd7791ad1 fails 22:39
yoleaux dogbert2: I'll pass your message to lizmat.
Geth rakudo: skids++ created pull request #1175:
Move security RT#131079 fix from Grammar to Actions
22:42
Zoffix huggable: hacktoberfest
huggable Zoffix, Hacktoberfest Issues: github.com/issues?utf8=%E2%9C%93&a...ktoberfest
Zoffix Yes! @Zoffix[2016] was right about leaving those labels around :D 22:43
Oh crap 22:44
AlexDaniel: thinking maybe hacking on rakudo repo in October is a bit LTA, since it's gonna be Hacktober and we could have proper Hacktober labeled issues users even outside 6lang community could find and join in 22:45
AlexDaniel Zoffix: awwwww… 22:46
Zoffix AlexDaniel: but you mentioned RT sucks. There is a possibility of unlocking rakudo/rakudo Issues. I mean, I have no keys to that part, but... :) 22:47
AlexDaniel that's what I'm thinking too, but even if we have rakudo/rakudo/issues, then what? We can't just move a bunch of LHF tickets in a single click 22:48
… but maybe we don't have any LHF tickets 22:49
Zoffix: OK, it's a bit LTA, I agree. We can change something. Any ideas on what can be done?
Zoffix I know of one. I think teatime called dibs on it. Actually, there are more than one open tickets, but they're all about Range quantifiers in regexes
AlexDaniel: what can be done about what? A different repo? Lots of LHF for roast 22:50
huggable: tag testneeded
huggable Zoffix, nothing found
Zoffix huggable: tag TESTNEEDED
huggable Zoffix, nothing found
Zoffix buggable: tag TESTNEEDED
buggable Zoffix, There are 45 tickets tagged with TESTNEEDED; See fail.rakudo.party/t/TESTNEEDED for details
AlexDaniel what if we open rakudo/rakudo/issues, and then move these 45 tickets? 22:51
ah wait, that's still wrong
because it's basically roast issues, hmm…
Zoffix Yeah
AlexDaniel I totally forgot that hacktoberfest is a thing so I did not think this through :S 22:52
timotimo it also surprised me, tbh 22:53
Zoffix I just got reminded about it too :) 22:54
Zoffix gonna score 4th shirt
AlexDaniel well, technically, if someone is working on RT tickets then he will be submitting pull requests for rakudo. That counts for Hacktoberfest, right? So the only issue is that we are less inclined to add Hacktoberfest labels? 23:01
Zoffix Yeah, PRs will still count to Rakudo 23:02
But Hacktoberfest labels will reach a larger audience (there's twitter hashtag and the event itself recommends adding such labels to participants could find them) 23:03
AlexDaniel yeah, I see
and yet again RT hurts us, even if a little bit 23:04
Geth rakudo/nom: cd043f2ae4 | (Zoffix Znet)++ | 2 files
"Remove" is_approx in 6.d

It long lived out its deprecation period, but is still used by 6.c roast. I'm not sure how such removals are meant to be handled, since a routine removed in 6.n is still in used in previous langs.
So I made it just die in 6.d. Close enough?
23:07
6.d-prep: 45156bf730 | (Zoffix Znet)++ | 2 files
Mark is_approx removal as complete

Removed in in 6.d in github.com/rakudo/rakudo/commit/cd043f2ae4
23:08
rakudo/nom: 01d4939c38 | (Zoffix Znet)++ | 2 files
Deprecate Str.lines: :$count in 6.d
23:20
6.d-prep: d1ef01dc13 | (Zoffix Znet)++ | 2 files
Mark Str.lines: :$count as completed

Done in github.com/rakudo/rakudo/commit/01d4939c38
23:21
timotimo hm. in my test program here range creation is rather wasteful with scalar allocations - not that it'd cost a lot 23:22
127613 calls to &infix:<..>, 392952 scalars in Range.new, 261968 in SET-SELF, 255226 in &infix:<..> 23:23
m: say 255226 / 127613; say 261968 / 127613; say 392952 / 127613 23:24
camelia 2
2.0528316
3.0792474
Geth rakudo/nom: 9cb4b167f5 | (Zoffix Znet)++ | src/core/Main.pm
Remove $*MAIN-ALLOW-NAMED-ANYWHERE

It was unspecced and temporarily added to transition users of old panda.
23:48
6.d-prep: f86587e995 | (Zoffix Znet)++ | 2 files
Mark $*MAIN-ALLOW-NAMED-ANYWHERE removal as completed

Done in github.com/rakudo/rakudo/commit/9cb4b167f5
23:49