MasterDuke is anyone getting "Failed to read dirhandle" errors? i assume this is because of the recent MoarVM commits 02:47
any reason JAST::Annotation doesn't have a filename attribute? 02:58
woohoo. looks like my line directive branch now passes spectest on moar. now to see about jvm... 05:00
[TuxCM] This is Rakudo version 2016.10-271-g59bb1b1 built on MoarVM version 2016.10-44-g4c9fd00 08:56
csv-ip5xs 3.147
test 13.962
test-t 6.394
csv-parser 14.897
jnthn lizmat: I'm a bit surprised that doesn't fail, tbh 09:58
lizmat jnthn: ok, I'll fix it then :-) 10:57
viki Reminder: Rakudo's next release will occur this Saturday. 11:03
stmuk does anyone know of a "compile farm" (ideally free) of different UNIX-like systems .. I think they existed in the past 11:35
moritz stmuk: besides travis?
stmuk ". Travis CI can test on Linux and OS X." 11:37
ideally I'd want at least windows and FreeBSD
seem to be various services (tea ci, opensuse etc) but not a unified one 11:42
gcc.gnu.org/wiki/CompileFarm 11:48
dalek kudo/nom: 15ab52c | lizmat++ | src/core/Rakudo/Internals.pm:
Introduce R:I:ShapeBranchIterator

An iterator for processing branches of a shaped array.
12:54
viki stmuk: are you able to check if this has been resolved in HEAD? rt.perl.org/Ticket/Display.html?id=130031 13:08
heh 13:12
m: say UNBASE 16, "FF"
camelia rakudo-moar 15ab52: OUTPUT«255␤»
viki m: say UNBASE 16, <FF DD EE>
camelia rakudo-moar 15ab52: OUTPUT«This call only converts base-16 strings to numbers; value $("FF", "DD", "EE") is of type List, so cannot be converted!␤(If you really wanted to convert $("FF", "DD", "EE") to a base-16 string, use $("FF", "DD", "EE").base(16) instead.)␤ in block <unit…»
viki m: say UNBASE_BRACKET 16, <FF DD EE>
camelia rakudo-moar 15ab52: OUTPUT«Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏FF' (indicated by ⏏)␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
viki m: say UNBASE_BRACKET 16, [<FF DD EE>]
camelia rakudo-moar 15ab52: OUTPUT«Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏FF' (indicated by ⏏)␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
viki waat 13:13
m: say $("FF", "DD", "EE").base(16)
camelia rakudo-moar 15ab52: OUTPUT«No such method 'base' for invocant of type 'List'␤ in block <unit> at <tmp> line 1␤␤»
moritz m: say UNBASE 16, <FF DD EE>.join
camelia rakudo-moar 15ab52: OUTPUT«16768494␤»
viki Not what I had in mind
github.com/rakudo/rakudo/blob/59bb...r.pm#L2723
timotimo unbase_bracket takes actual numbers and composes them as digits into a bigger number 13:14
viki Ah
timotimo m: say UNBASE_BRACKET 100, <20,30,40>;
camelia rakudo-moar 15ab52: OUTPUT«Type check failed in binding to @a; expected Positional but got Str ("20,30,40")␤ in block <unit> at <tmp> line 1␤␤»
timotimo m: say UNBASE_BRACKET 100, <20 30 40>;
camelia rakudo-moar 15ab52: OUTPUT«203040␤»
timotimo m: say UNBASE_BRACKET 100, <20 30 40 1 2 3>;
camelia rakudo-moar 15ab52: OUTPUT«203040010203␤»
lizmat afk&
viki Was anything done with gcd either in roast or rakudo recently? I'm getting a spectest fail, but from what I can see the spectest is wrong :\ 13:30
m: my int $i0 = 0; my int $i8 = 8; say $i0 gcd $i8
camelia rakudo-moar 15ab52: OUTPUT«8␤»
viki And it's expecting zero :\
Oh, nm, I see a commit 13:31
dalek ast: e273b55 | (Zoffix Znet)++ | S32-num/int.t:
Fix broken test

The test was added[^1] recently and it has an error in it.
  [1] github.com/perl6/roast/commit/8f85...9e818f022d
13:34
timotimo ah, a simple copy-paste mistake it seems like 13:36
viki yeah
timotimo good catch in any case :) 13:37
stmuk viki: #130031 works now 13:39
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130031
dalek kudo/nom: 1dc4c42 | (Zoffix Znet)++ | src/core/Exception.pm:
Improve message of X::Numeric::Confused

Do not suggest the user calls .base() unless the wrong object that triggered the error can actually do .base().
viki stmuk++ thanks 13:40
stmuk not sure if I can close it 13:41
viki I will.
After I fish out the commit and tests that did it. 13:42
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Introduce R:I:ShapeBranchIterator
travis-ci.org/rakudo/rakudo/builds/175694500 github.com/rakudo/rakudo/compare/5...ab52c21199
stmuk viki: I think it was around 404ed261 on moar 13:46
viki Yeah, it's github.com/MoarVM/MoarVM/commit/404ed261be00e2 13:49
Don't see test for it though...
stmuk well its a windows specific test
viki Well, I see a test for mkdir in S32-io/mkdir_rmdir.t so *shrug* 13:50
I guess I'll close without a specific test for this ticket.
m: say &defined ~~ Callable 13:52
camelia rakudo-moar 1dc4c4: OUTPUT«False␤»
dogbert17_ o/ viki, no new alias this week? 13:58
viki No, I still like this one.
dogbert17_ :-), btw, can you close bugs in RT? 13:59
viki I can, yeah. 14:00
dogbert17_ e.g. rt.perl.org/Public/Bug/Display.html?id=129246
viki Done 14:01
dogbert17_ thx 14:02
here's a classic: rt.perl.org/Public/Bug/Display.html?id=130096 14:04
viki Deleted. Thanks. 14:12
stmuk interesting meta ticket 14:14
rt.perl.org/Ticket/Display.html?id=129926
dogbert17_ there are quite a few tickets in RT that could possibly be closed 14:19
viki dogbert17_: ask [Coke] to give you access 14:21
He'll need you RT accounts email
dogbert17_ hmm not sure that I have an RT account 14:25
dalek kudo/nom: 189cb23 | (Zoffix Znet)++ | src/core/Junction.pm:
Make defined() correctly autothread with Junctions

Fixes RT#130099: rt.perl.org/Ticket/Display.html?id=130099
14:26
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130099
dalek ast: 6b84580 | (Zoffix Znet)++ | S03-junctions/autothreading.t:
Test defined() with Junctions autothreads

RT#130099: rt.perl.org/Ticket/Display.html?id=130099
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130099
viki dogbert17_: get one
It's kinda weird the above fix doesn't work if you augmented into Junction class:
m: gist.github.com/zoffixznet/30068ed...0ae06ac43f
camelia rakudo-moar 1dc4c4: OUTPUT«1..1␤ 1..2␤ 1..10␤Cannot resolve caller defined(Str: ); none of these signatures match:␤ (Junction:D $: *%_)␤ in block at <tmp> line 68␤ in sub subtest at /home/camelia/rakudo-m-inst-1/share/perl6/sources/C712FE6969F786C9380D643…»
viki How come?
dalek p: 1789b85 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Remove commented out debugging leftover.
14:28
p: 9abc63c | (Pawel Murias)++ | src/vm/js/ (3 files):
[js] Implement nqp::throwpayloadlexcaller.
p: 56d7687 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Remove dead code.
14:29
viki dogbert17_: I think you just sign up on www.bitcard.org/
And that will work as an account on rt.perl.org
travis-ci Rakudo build passed. Zoffix Znet 'Improve message of X::Numeric::Confused 14:31
travis-ci.org/rakudo/rakudo/builds/175705213 github.com/rakudo/rakudo/compare/1...c4c4297e3f
dogbert17_ viki: cool will do, last RT question :) what about rt.perl.org/Public/Bug/Display.html?id=129776 can that be closed? 14:32
viki Yeah, I guess. 14:34
m: dd [ :20("0xFF"), :2("0o42"), :3("0b111") ] 14:42
camelia rakudo-moar 189cb2: OUTPUT«[255, 34, 7]␤»
viki heh
m: say :20(':20<36H>') 14:44
camelia rakudo-moar 189cb2: OUTPUT«1337␤»
viki radixeptiomn 14:45
dalek ast: a10321b | (Zoffix Znet)++ | / (2 files):
Move "contributing" doc to its own file

So it's picked up by GitHub and is announced on Issue/PR submission
15:05
FROGGS o/ 16:37
dalek kudo/nom: 2faa55b | (Zoffix Znet)++ | src/core/Exception.pm:
Add X::Syntax::Number::InvalidCharacter exception

The exception is to be used by .parse-base() routine to indicate a string contains a character that is not a valid character in the base the number is being converted to.
e.g. of output: "Invalid base-30 character: Perl6⏏ Is Great"
Awesomified with colour support.
17:15
rakudo/nom: 7e21a24 | (Zoffix Znet)++ | src/core/Str.pm: 17:21
rakudo/nom: Add parse-base() sub/method
rakudo/nom:
rakudo/nom: * Performs the reverse operation of Real.base: convert Str in a 2..36 base
rakudo/nom: to base-10 Numeric
rakudo/nom: * Make it easier to use base/source in variables, compared to :16<FF> format
rakudo/nom: * Unlike :16<FF>, to make it more acceptable to feed user data into, provides
rakudo/nom: simpler parsing, so things like :2<0xFF>, :36<0o2>, or :36(':20<36H>') would
rakudo/nom: fail instead of parsing as hex, octal, and base-20 number respectively.
rakudo/nom:
rakudo/nom: Name bikeshed: irclog.perlgeek.de/perl6/2016-11-11#i_13550787
rakudo/nom: Feature bikeshed: twitter.com/wonkden/status/797146894850002948
viki stupid robot 17:22
github.com/rakudo/rakudo/commit/7e...258920c29a
dalek ast: 553ca61 | (Zoffix Znet)++ | S32-str/parse-base.t:
Add tests for parse-base() routine

Feature added to Rakudo in
  github.com/rakudo/rakudo/commit/7e...258920c29a
kudo/nom: b1cbb8b | (Zoffix Znet)++ | t/spectest.data:
Add S32-str/parse-base.t to list of tests to run
17:23
kudo/nom: 5c40b13 | (Zoffix Znet)++ | src/core/Str.pm:
Fix typo in comment

  MasterDuke++
17:38
ast: 6e17e23 | (Zoffix Znet)++ | S32-str/parse-base.t:
Test .parse-base can handle fancy Unicode numerals

  MasterDuke++
18:02
viki Seems t\04-nativecall\20-concurrent.t is still failing on AppVoyer thing: ci.appveyor.com/project/moritz/rak...5e2wgw70wp 18:30
dalek kudo/nom: dfb58d4 | lizmat++ | src/core/ShapedArray.pm:
Make initialization of 2+dimmed array much faster

  - rewrite using nqp ops and the new R:I:ShapeBranchIterator
  - now also allows lazy lists in initialization
  - calls out an error on superfluous but empty iterators
About 10x as fast on a 2x2 initializations, 16x on a 2x2x2 one. Didn't test on larger / more dimensional initializations, but expect them to be much much faster still.
18:44
lizmat so where is the new TWEAK functionality documented ? 18:45
docs.perl6.org doesn't know about tweak :-( 18:46
mst <3 having TWEAK in mainline
viki lizmat: I see it mentioned in the text in docs.perl6.org/language/objects#Ob...nstruction 18:47
mst I think then I just need to figure out how to resurrect lizmat's lazy code, or beat one of the eco versions until it does what I want
viki I'll add an index marker
mst it's really fun watching perl6 slowly grow up :D 18:48
lizmat viki++
" (TWEAK is a new feature in v6.d / Rakudo 2016.11)" so, 2016.11 is going to be 6.d ??? 18:49
lizmat is confused now
mst: which lazy code are your referring to?
viki lizmat: I guess that means if you want to guarantee TWEAK works you can only rely on it in 6.d? *shrug* 18:50
And well, it's not part of 6.c standard 18:51
lizmat m: use v6.d
camelia rakudo-moar dfb58d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤No compiler available for Perl v6.d␤at <tmp>:1␤------> use v6.d⏏<EOL>␤»
lizmat so you cannot use that to know that TWEAK will work
mst lizmat: lazy attribute population, IIRC you wrote a 'will lazy' that got unmerged from rakudo for some reason, and then rabidgravy and ... somebody else ... wrote eco modules
lizmat ah, that bit
viki Right. There's no sane way to do it.
[Coke] I would remove "v6.d / " from that description. 18:58
mst "Tweak is a new feature in Rakudo 2016.11 which will be standardised as part of v6.d" ? 18:59
[Coke] we don't know anything concrete about v6.d yet, so I would hesitate to document it as concrete.
lizmat yes, but saying it is part of 2016.11 only enforces the notion of checking release level, rather than language level 19:01
and then we're back at Perl 5 semantics of versioning basically
which we were trying to get away from, as far as I know (did that change while I wasn't watching??)
viki I think it's really at "experimental" level of support ATM. We just don't have that good distinction. 19:04
timotimo i look ahead to when we have proper 6.c and 6.d support 19:05
lizmat timotimo: I am as well, but as of now, it is above my payrate to implement that
otherwise I would have done it already
plenty of stuff of mine waiting to be put in 6.d 19:06
[Coke] and/or removed from 6.c :)
lizmat [Coke]: yup 19:07
geekosaur still needs to ask (probably @LARRY) about the CALL-ME stuff 19:11
my original idea's not workable (and suggests Callable is misnamed)
and it's necessarily 6.d (or later) stuff 19:12
lizmat would think it would be appropriate to have 2016.12 be a 6.d 19:13
mst lizmat: ok, how about just "TWEAK is an experimental new future in 2016.11" ?
lizmat mst: that again enforces the notion you would need to check release versions, rather than language levels 19:14
viki But there's no 6.d language yet
lizmat well, that's my point: we need one :-)
viki 6.c.limbo :) 19:15
mst lizmat: well, if it's in the 2016.11 release notes, people are going to infer it anyway, and I don't see how you can avoid that
lizmat true, and that's why I'm saying we need a 6.d sooner rather than later
mst lizmat: I mean, ideally you would have a prereq on language levels, with a blacklist of release versions you know don't provide that language level properly
or suitably 19:16
or whatever
like I'll need to be able to exclude a particular release with a bug
lizmat otherwise we might as well forget about 6.x type versioning altogether
timotimo do we have a thing that tells us if the current lexical scope has .c?
because we can make looking for TWEAK depend on that
lizmat m: say $*PERL.version # timotimo
camelia rakudo-moar dfb58d: OUTPUT«v6.c␤»
timotimo but $* is kind of dynamic? 19:17
lizmat m: say $*PERL.version >= v6.c
camelia rakudo-moar dfb58d: OUTPUT«True␤»
lizmat m: say $*PERL.version >= v6.d
camelia rakudo-moar dfb58d: OUTPUT«False␤»
timotimo m: say $*PERL.perl 19:18
lizmat it *is* dynamic, that's why it would work :-)
camelia rakudo-moar dfb58d: OUTPUT«Perl.new(compiler => Compiler.new(id => "0469EDF27F3A519842CF7FEE334FC847FD7AE78C.1479150623.09795", release => "", codename => "", name => "rakudo", auth => "The Perl Foundation", version => v2016.10.279.gdfb.58.d.4, signature => Blob, desc => Str), name …»
timotimo m: say $*PERL.version.perl
camelia rakudo-moar dfb58d: OUTPUT«v6.c␤»
timotimo that's problematic, though
mst lizmat: ok, but there *has* to be some mechanic for "experimental thing that may not make it into any official 6.x"
timotimo when you don't say "use v6.c" you're supposed to get "bleeding edge"
viki m: enum Foo <a b c>; my @a[Foo] = 42; dd @a 19:23
camelia rakudo-moar dfb58d: OUTPUT«Array.new(:shape(3,), [42, Any, Any])␤»
lizmat m: use v6.c; class A { method TWEAK { dd %_ } }; A.new(foo => 42) # so this should not work 19:24
camelia rakudo-moar dfb58d: OUTPUT«{:foo(42)}␤»
viki commitable: 2016.10 enum Foo <a b c>; my @a[Foo] = 42; dd @a 19:25
committable6 viki, ¦«2016.10»: Array.new(:shape(3,), [42, Any, Any])
viki lizmat: what was broken that this commit fix? github.com/rakudo/rakudo/commit/7d...cb33ec934e
viki is trying to add it to changelog 19:26
lizmat viki: it was checking for definedness of the parameter, and thus ignored Enums altogether
viki: so specifying an Enum gave you an unshaped array
viki commitable: 2016.09 enum Foo <a b c>; my @a[Foo] = 42; dd @a 19:27
committable6 viki, ¦«2016.09»: [42]
lizmat viki: could well be I broke this *after* 2016.10
viki commitable: 1293188 enum Foo <a b c>; my @a[Foo] = 42; dd @a
lizmat so as such wouldn't require a mention
committable6 viki, ¦«1293188»: [42]
viki Aha. Thanks, lizmat++
timotimo lizmat: yes, it shouldn't work, that's what i think 19:30
geekosaur Callable rant sent (not actually as a rant :) 19:34
dalek kudo/nom: 8ff9d0a | (Zoffix Znet)++ | docs/ChangeLog:
Log all changes to date

Document commits: 189cb23 2faa55b 37d0e46 4ae3f23 59bb1b1 7e21a24 839c762 a43b0c1 d540fc8 dd7b055 dfb58d4
19:44
kudo/nom: c196afa | (Zoffix Znet)++ | docs/ChangeLog:
Move miscategorized change from Additions to Fixes
19:45
viki NeuralAnomaly: status
NeuralAnomaly viki, [✔] Next release will be in 4 days and 9 hours. Since last release, there are 32 new still-open tickets (0 unreviewed and 0 blockers) and 0 unreviewed commits. See perl6.fail/release/stats for details
lizmat viki; re 189cb23 , nqp::isconcrete is *not* the same as defined() 19:52
viki: at least, not always 19:53
viki: case in point: Failure:D
viki lizmat: hm, I just took what Mu.defined uses: github.com/rakudo/rakudo/blob/nom/.../Mu.pm#L89 19:54
lizmat viki: yes, that's the default case
viki Ohh
lizmat github.com/rakudo/rakudo/blob/nom/...ure.pm#L51 # an override
viki I'll change it to .defined() method call then. 19:55
lizmat viki++ :-)
viki lizmat++ code review
timotimo sorry, i'm bouncing in and out of irc 20:10
viki Weird. Hang when trying to run t/spec/S03-junctions/autothreading.t 20:30
m: say all(42, "x").defined 20:31
camelia rakudo-moar c196af: OUTPUT«True␤»
viki Hm. The above hangs with this patch :/ gist.github.com/zoffixznet/a4e226d...2c56ce5a0b 20:32
lizmat feels like a infiniloop that caught me when I was trying to fix this otherwise 20:33
viki I think I see a messed up closing parentheses
viki rebuilkds 20:34
ZOFVM: Files=1203, Tests=130156, 148 wallclock secs (20.31 usr 3.02 sys + 2680.25 cusr 246.31 csys = 2949.89 CPU) 20:42
dalek kudo/nom: 26e3516 | (Zoffix Znet)++ | src/core/Junction.pm:
Fix Junction.defined for types that have their own .defined

nqp::isconcrete is only good for the default definedness. Fix by calling actual .defined method on the items.
  lizmat++ for spotting the error
  irclog.perlgeek.de/perl6-dev/2016-...i_13566837
20:44
ast: ba8278d | (Zoffix Znet)++ | S03-junctions/autothreading.t:
Test Junction.defined works on custom-defined .defined

Also... defined
ast: 1f3cadd | (Zoffix Znet)++ | S03-junctions/autothreading.t:
Fix copy/pasta error in test description
20:45
mst TimToady: the discussion further up w/lizmat about TWEAK, mentioning compiler versions, and how you deal with additive features atop the standard, is probably worth a read and a think about 20:55
because it seems like a design/policy concern and lizmat has good points about the problems and I've no idea what other approaches would be best
lizmat fwiw, the same problem exists wrt to parse-base 20:59
viki Yeah. Even minor things like "42".chrs are affected too, since that crashes on 2016.10 but not 2016.11 21:11
so you can't write code on assumption that .chrs can handle Str, if you target all 6.c compilers 21:12
timotimo so we should make things like that also asplode when "use v6.c" is in effect? 21:15
lizmat timotimo: but I think the point was that we shouldn't need to put in checks everywhere 21:16
timotimo oh
well, we're not going to make "use Rakudo:ver(* > v2011.10)" 21:17
viki nope
Make language releases more frequent? minor versions.... 6.c.1, 6.c.2 21:19
and compiler releases rarer (?) this is all converging on tying to implementation version innit and someone said that should be avoided 21:20
viki is done for the day
night \o
lizmat good night, viki!
timotimo gnite viki 21:21
[Coke] at some point, people will have to be able to say "don't allow this version of rakudo to run my code, I know it has a bug." (They can do that already with one of the $* vars) 21:22
Worth going through jnthn's document describing how he expected this to work back pre-christmas that generally was received well. 21:23
geekosaur isn't the usual way some way to declaratively specify required features? (use feature ...)
jnthn I'd imagined that we'd declare a 6.c.1 sometime during 2016, thus providing people a way to say "I expect this set of things to work" in a language-tied way. 21:24
There's not much to stop us doing that.
TimToady seems like a good first step
jnthn m: use 6.c.1 21:25
camelia rakudo-moar 26e351: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Malformed postfix call␤at <tmp>:1␤------> use 6.c.⏏1␤»
jnthn m: use v6.c.1
camelia ( no output )
jnthn uh... o.O
*sigh*
Why doesn't that explode?
committable6: 2015.12 use v6.c.1
committable6 jnthn, ¦«2015.12»:
TimToady dint we have an egregious hack at christmas to be especially accepting?
jnthn Quite possibly :/ 21:26
If so I'd forgotten about it.
TimToady I could be confabulating though
TimToady is very in need of the coming week's vacation...
[Coke] just took a week off ... to spend some quality time with some phlegm. 21:27
jnthn I guess provided we teach module installation to refuse to install stuff on a compiler that doesn't support 6.c.1 we at least make it module-useful
(And we can tighten it up some, of course.) 21:28
geekosaur ...right, forgot Callable docs got updated according to my original musings about CALL-ME, with the result that they leak an internal name *and* do not match the actual behavior. :/ 21:42
geekosaur has a headache...
...and I'm still unconvinced that scheme will actually work in practice, although I had forgotten that all Callable currently provides is "assuming" so maybe it *can* handle being the barrier between language and implementation of invocation/calling 21:43
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/11/14/...-cheaters/ 22:14
pyrimidine lizmat++ 22:16
geekosaur ok, the message I am getting here is "this is not a problem" 22:17
lizmat good night, #perl6-dev! 22:47