[Tux] This is Rakudo version 2017.06-103-g2a8d1e7ce built on MoarVM version 2017.06-30-g389e9732 06:23
csv-ip5xs 2.728
test 12.485
test-t 4.184 - 4.274
csv-parser 12.911
timotimo buggable: speed 06:40
buggable timotimo, ███▆↑▇▃▄▄▄↑▃▅▃▃▃▃▃▃▅▃▂▃▃▃▃▆▅▁▂▂▂▃▃▄↑▃▃▅▄▄▃▄▆▆▅▃▂▇▅ data for 2017-06-13–2017-06-29; range: 3.907s–4.588s; 4% faster
timotimo huggable: speed
huggable timotimo, tux.nl/Talks/CSV6/speed4.html
[Tux] runs it again. box was relatively busy 06:53
This is Rakudo version 2017.06-103-g2a8d1e7ce built on MoarVM version 2017.06-30-g389e9732 07:00
csv-ip5xs 2.634
test 12.669
test-t 4.097 - 4.187
csv-parser 12.268
DeadDelta m: class Foo does Iterable {} 10:35
camelia 5===SORRY!5=== Error while compiling <tmp>
Method 'iterator' must be implemented by Foo because it is required by roles: Iterable.
at <tmp>:1
DeadDelta But it IS implemented :/
m: class Foo {}.iterator.say 10:36
camelia <anon|190488128>.new
lizmat no, it isn't in that code
you don't need to be Iterable to have an iterator
m: dd 42.iterator
camelia <anon|190488128>.new
DeadDelta I inherit one. What does it care where it comes from? 10:37
lizmat if it inherits one, and the base class does Iterable
you don't need the "does Iterable" in your subclass
problem solved ?
DeadDelta Not really. I have a method in my class thought by a role I'm trying to do, but it complains that it's not there. 10:38
s/thought/sought/;
lizmat hmmm...
DeadDelta m: class Foo { method x {} }; role Meow { method x {…} }; class Bar is Foo does Meow {} 10:39
camelia ( no output )
DeadDelta And actually seems to work here ^ when the inherited-from class isn't a Mu
lizmat so you're saying the implementation check should be a .can() check rather than an exists check on the stash ?
DeadDelta m: class Foo { method x {} }; role Meow { method elems {…} }; class Bar is Foo does Meow {} 10:40
camelia ( no output )
DeadDelta Works for Any
m: class Foo { method x {} }; role Meow { method x {…} }; class Bar is Foo does Meow {}
camelia ( no output )
DeadDelta m: class Foo { method x {} }; role Meow { method Bool {…} }; class Bar is Foo does Meow {}
camelia ( no output )
DeadDelta Oh, it's the Iterable that complains?
m: class Foo { method x {} }; role Meow { method iterator {…} }; class Bar is Foo does Meow {} 10:41
camelia ( no output )
lizmat the does Iterable states that you need to implement an iterator method
at composition time of Foo it doesn't see one in Foo and complains
DeadDelta method iterator() { ... } ? Is that it? 10:42
lizmat think so
DeadDelta So why doesn't above it doesn't complain with Meow role?
m: role Meow { method iterator {…} }; class Bar does Meow {}
camelia 5===SORRY!5=== Error while compiling <tmp>
Method 'iterator' must be implemented by Bar because it is required by roles: Meow.
at <tmp>:1
DeadDelta :|
lizmat hmmm.. that smells wrong
:-) 10:43
DeadDelta Filed as rt.perl.org/Ticket/Display.html?id=131676 10:46
Geth rakudo/nom: 5e34258850 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Introducing R:Q.COERCE-MAP-TO-(SET|BAG|MIX)

Shortcuts that don't need to check for existence of keys.		 11:33
[Coke] fires up a docker container with ubuntu to see if his mac segv happens elsewhere... can't build rakudo... there is no /tmp in there. weird. 11:36
Geth rakudo/nom: f34af72fc7 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Tweaks in R:Q.COERCE-MAP-TO-(BAG|MIX)
 11:39
rakudo/nom: 72e5d61411 | (Elizabeth Mattijsen)++ | src/core/Map.pm
Make Map.(Bag|Mix) 2.5x to 5x faster

  - based on a 26-element hash
  - 2.5x for normal hash
  - 5x for object hash
llfourn [Coke]: I just pulled ubuntu:latest and it had /tmp 11:49
[Coke] llfourn: weird. wonder what happened to it in my container. 11:57
dogbert2 lizmat: 'say $?BITS' returns 64 on my 32 bit linux VM 11:58
lizmat :-(
dogbert2: what does int.Range say ? 11:59
jnthn Well, what's it supposed to represent?
lizmat the size of a native int
dogbert2 lizmat: -9223372036854775808..9223372036854775807
jnthn Then it's correct in that that's alwasy 64 bits on MoarVM 12:00
lizmat yeah, that's the 64 bit one
jnthn: even on a 32 bit system ?>?
jnthn Depending what definition of "native" you're suing :)
lizmat: Yes
s/suing/using/ :)
lizmat ok, then how can one know whether you're running on a 32bit system or not ? 12:01
jnthn I guess see how nativecall figures out the size_t size :)
lizmat well, but don't we want to be able to do that in core? 12:02
lizmat is getting confused now
jnthn NativeCall surely does it by asking the VM 12:03
Anything in the VM that it's using, you could use in CORE.setting too :)
pmurias paste.debian.net/973884 - does this nqp::spawnprocasync test look sane? it passes I just want to make sure it tests for proper behavior 12:05
dogbert2 m: $*KERNEL.bits 12:06
camelia ( no output )
dogbert2 m: say $*KERNEL.bits
camelia 64
jnthn pmurias: Just glanced over it, seems reasonable to me
dogbert2 lizmat: that one gives 32 on my system 12:07
dunno if that should be used though 12:08
lizmat well, I don't know either anymore :-(
Geth rakudo/nom: 495fb5f8ac | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Make Map (+) Map between 3x and 6x faster

  - based on a 26-element hash with itself
  - 3x for normal hash (+) normal hash
  - 6x for object hash (+) object hash		 12:15
dogbert2 m: Buf.new((my int $i = 10) +& 0xFF) 12:23
camelia ( no output )
dogbert2 lizmat: I may be wrong but it looks as if RT #128655 has been fixed at some point 12:24
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=128655
dogbert2 bisect: Buf.new((my int $i = 10) +& 0xFF) 12:27
bisectable6 dogbert2, On both starting points (old=2015.12 new=495fb5f) the exit code is 0 and the output is identical as well
dogbert2, Output on both points: «»
lizmat bisect: old=2016.06 Buf.new((my int $i = 10) +& 0xFF) 12:28
bisectable6 lizmat, On both starting points (old=2016.06 new=495fb5f) the exit code is 0 and the output is identical as well 12:29
lizmat, Output on both points: «»
lizmat hmmm
m: dd Buf.new((my int $i = 10) +& 0xFF)
DeadDelta So Gabor is now spreading anti-Perl 6 propaganda? Must be raising too much money on that Perl 6 Web book
camelia Resource temporarily unavailable
lizmat DeadDelta: if this is about fayerplay.com/perl-is-schrodinger_state/ , don't blame the messenger :-) 12:30
DeadDelta IIRC that bug was fixed by pmurias with the removal of optimizer bit, which was then reverted, but the bug remained fixed somehow
I'm not blaming. I'm just amused 12:31
dogbert2 cool, if that one is fixed then RT #128624 must also be fixed
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=128624
DeadDelta IIRC there's commented out code in rakudo for 128655 12:32
That could be uncommented now
Ohh... or maybe that's why the bug is not there, cause the native candidates are commented out
Or maybe i'm thinking of a different bug :/ 12:33
s: &infix:<+&>
SourceBaby DeadDelta, Sauce is at github.com/rakudo/rakudo/blob/495f...ic.pm#L320
DeadDelta shrugs 12:34
dogbert2 DeadDelta: if you think that 128655 is sorted then RT #129844 can also be closed, that's three RT's for the price of one :)
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=129844
Geth rakudo/nom: ae4c04cef7 | (Elizabeth Mattijsen)++ | src/core/Setty.pm
Make Setty.(Bag|Mix) about 5% faster

  - based on a 1000 elem Set
  - don't call raw_hash, use $!elems directly
  - don't use helper sub		 12:35
pmurias DeadDelta: the problem with the Bufs was 2 part, the multi dispatch optimizer bug (which was fixed and reverted as it speeds some other stuff up) and Buf.new failing when passed a native int (which I didn't fix) 12:38
DeadDelta "...and reverted..." 12:39
Yeah, but it looks like even after the revert the bug is gone?
lizmat: what do you think about generalizing this commit to use a hash of options instead of a single dynvar? github.com/rakudo/rakudo/commit/af...47f6a4e64d 12:45
lizmat: it's probably not the only thing users will want to have configurable. Or perhaps there could be an option to provide a parsing class (like GetOpt::Whatever) 12:46
lizmat All for it, I see MAIN-ALLOW... as a hack really
pmurias DeadDelta: if the native candidates are commented out they multi inliner won't see it (and do it's incorrect but sometimes wanted optimalization)
m: my int $x = 123;my $y = Buf.new($x+1) 12:48
camelia Type check failed in initializing element #0 to Buf; expected uint8 but got Int (124)
in block <unit> at <tmp> line 1
pmurias DeadDelta: it's still a problem for ops that are too important to comment their fast path out
DeadDelta Oh, ok, the bug's still there 12:49
pmurias m: my $x = 2**63-1;say($x+1) 12:50
camelia 9223372036854775808
pmurias m: my int $x = 2**63-1;say($x+1)
camelia -9223372036854775808
DeadDelta And disappears with --optimize=off
dogbert2 :( 12:51
jnthn I suspect we'll have to at some point consider whether the native integer literal handling stuff in the optimizer really belongs in the optimizer, since it's actually required for resolving which literals are compiled as int and which are compiled as Int
otoh, do we want slower compilers by adding another pass? 12:52
*compiles
DeadDelta greppable6: MAIN-ALLOW-NAMED-ANYWHERE
greppable6 DeadDelta, gist.github.com/fe7f6681e9b331914c...d2ac6b2039
pmurias jnthn: we do have QAST::Want so the optimizer could turn $native-int + 123 into a add_i in native int context and a bignumy infix:<+> when we want an object 12:56
jnthn pmurias: That's not the only reason 12:57
pmurias: It's much more generally used by the QAST compiler
So anywhere that an nqp::op is used and there's an integer/num/string literal, it knows it can use the native version for the nqp::op 12:58
lizmat DeadDelta: if that's the only occurrence of MAIN-ALLOWED, I guess we're good :-)
pmurias jnthn: what would be an example of that? 12:59
jnthn nqp::substr($foo, 0, 1) 13:00
DeadDelta lizmat: yeah. I'll implement a hash tonight 13:01
Geth rakudo/nom: d5bf5b0c25 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Add some internal documentation

Was actually part of a bigger commit, but realized in time it was mostly bogus, so dropped the code but kept the improved comments.
DeadDelta Oh, and another question that was asked before awhile back
m: say set() ~~ Iterable
camelia False
DeadDelta Should QuantHash be Iterable? Maps are. But on the other hand the fact that slurpies break Maps into Pairs is kidna meh, so would we want the same to happen with QuantHashes? 13:02
pmurias jnthn: you mean when the nqp::substr is inside the multi which we are inlining?
jnthn pmurias: I mean in general 13:03
DeadDelta m: sub foo (*@a) { dd @a }; foo %(:a, :b); foo (:a, :b).Bag
camelia [:a, :b]
[("b"=>1,"a"=>1).Bag]
DeadDelta m: sub foo (*@a) { dd @a }; foo $%(:a, :b); foo (:a, :b).Bag.pairs
camelia [{:a, :b},]
[:b(1), :a(1)]
pmurias jnthn: the reverted commit only changed how multis are inlined 13:04
pmurias is confused 13:05
DeadDelta I think current way is fine. But I might write an article about Perl 6 Iterables and so wanted to find out if QuantHash isn't one on purpose :)
jnthn pmurias: Yes, it changed it so that for $a + 1 where $a is declared as a native int so they never were!
By removing the allomorph analysis 13:06
pmurias which is not correct in generally but speeds things like my int $a = 2; $a = $a + 1 up 13:08
lizmat DeadDelta: could you check if something breaks if you add "does Iterable" to the QuantHash role ? 13:09
DeadDelta lizmat: it cries about wanting iterator (the bug I found this morning) and when I worked around it by adding method iterator { self.pairs.iterator } it wanted .kv implemented too. Then I left to work 13:10
pmurias what I mean is that we could explicitly do it for the things that we know work the same with a int or a Int
DeadDelta s: set, 'iterator', \() 13:11
SourceBaby DeadDelta, Something's wrong: ␤ERR: ===SORRY!=== Error while compiling -e␤Function "set" may not be called without arguments (please use () or whitespace to denote arguments, or &set to refer to the function as a noun, or use .set if you meant to call it as a method on $_)␤at -e:6␤------> put sourcery( set<HERE>, 'iterator', \() )[1];␤
DeadDelta *groan*
s: set(), 'iterator', \()
SourceBaby DeadDelta, Sauce is at github.com/rakudo/rakudo/blob/495f...Set.pm#L36
DeadDelta Yeah, it already got its own iterator. So I think what will be affected is how QuantHashes flatten in slurpies or .deepmap or .nodemap or ».foo 13:12
DeadDelta & 13:15
pmurias jnthn: do more complex things then simple ops even get inlined? 13:17
jnthn pmurias: Not in the static optimizer, no 13:18
pmurias: We used to try and do more
There's certainly some cleanups to be had in this area
It dates back to before we were running on VMs that can do inlining
Nowadays all we really want to do is worry about native ops
In terms of transformations 13:19
Though we also do a bunch of catching impossible code at compile time too
Transformation wise, though, we only care about natives 13:20
pmurias so if I get the ops to run as fast as they do know without the allomorph analysis I can remove that again?
jnthn And doing the allomorphic lowering 13:21
Uh
But the allomorph analysis is key to it, no?
We have to compile-time dispatch $a + 1 considering the 1 native
Geth rakudo/nom: 41ed2c03ab | (Elizabeth Mattijsen)++ | src/core/Rational.pm
Allow for "does Rational" and "does Rational[foo]"

From a question by cschwenz++ on #perl6		 13:22
jnthn That is to say, we treat the fact $a is known native as implying the literal should also be considered native in this context
pmurias yes, but we can do it in a more precise way then just assume multi dispatch works differently then it really does at runtime
jnthn Probably, but it's still going to be the case that multi-dispatch at runtime can't know what's a literal and what's not 13:23
And at compile time we do know that
pmurias do we want to have 2 different multi dispatch algorithms? 13:26
jnthn What do you consider the alternative? 13:27
I mean, I don't think making users write int(1) everywhere is really going to fly 13:28
pmurias the optimizer having knowledge where treating a literal as a native int works
jnthn That's what it has now, though?
It just uses "there's a declared native argument" as its source of knowledge 13:29
pmurias on the jvm if it doesn't inline it just selects a multi variant with a native argument and then just passes a regular not native int 13:31
jnthn Yeah, that approach didn't work out so well with having dynamic optimization stuff going on 13:32
Maybe what we want is just 13:33
pmurias m: my int $x = 2**63-1;say($x+1)
camelia -9223372036854775808
jnthn That result is fine
pmurias jnthn: it works differently with optimize=off 13:34
jnthn 1) if there is a call to a subroutine taking two arguments and one of them is declared native and the other is a literal that has a native value, then replace the QAST::Want with the native value
2) Then the multi-dispatch just works the same way
Yes, I already said earlier that it's only part of optimize for avodiing a separate pass
But if people are upset about --optimize=off making the difference we can do that. 13:35
In fact
Since it's a really quite local analysis anyway
We can pull it up trivially into actions I think
Since we know the types of our lexicals when we compile a call
pmurias so we want to change the semantics? 13:36
jnthn And we also can see the two args and the literal
So that's perhaps the best way to handle it
And then it's not affected by --optimize any more; that will just do the inlining
That's probably the way to do it. 13:37
pmurias do we want $x + 1 to have a different result than $y = 1; $x + $y? 13:38
jnthn Please write an example with types
So we can actually discuss this clearly
Because without them the answer is "yes" and "no" :P 13:39
pmurias m: my Int $y = 1;my int $x = 2**63-1;say($x+$y)
camelia 9223372036854775808
pmurias m: my $y = 1;my int $x = 2**63-1;say($x+$y)
camelia 9223372036854775808 13:40
pmurias m: my int $x = 2**63-1;say($x+1)
camelia -9223372036854775808
jnthn Yes, thsoe three are what I'd expect under the rules today, and under what I'm suggesting we do
It's either that or we make the user always write stuff like int(1) 13:41
So we don't have to try and infer what the literal should be
pmurias rules = the proposed rules? 13:43
m: my Int $y = 1;my int $x = 2**63-1;say($x+(1+1)) 13:44
camelia -9223372036854775807 13:45
jnthn Hm, that one way well change because it relies on constant folding having happened first
(With the move I suggested into actions) 13:46
Since we'd be moving the analysis ahead of constant folding
At the end of the day, all we're really trying to achieve here is making the language user get decent code produced when they use native types without having to annotate every single literal they mention 13:50
To me, if you've already decided to involve something that you *declared* native in an operation, and the other operand is a literal, then you most likely are expecting the native operation to take place. 13:51
That seems like a reasonable and quite easy to teach heuristic 13:52
That's what the allomorph code in Perl6::Optimizer is there to achieve today 13:53
The compile-time multi dispatch semantics were only intended, so far as I recall, to reflect what the result would be given something else already made a decision on whether a literal would count as native or not.
My proposal to move this into the actions would both resolve the "--optimize changes semantics" issue and completely decouple it from multiple dispatch, since it would take effect for single dispatch too 13:54
We are, however, left with the chaining issue 13:55
($x + $y) + 1
Which is harder to solve "peephole"-like
(Since a post-declared + may come later) 13:56
Though we could still move such things ahead or out of the optimization phase.
lizmat afk&
pmurias jnthn: I feel TimToady should have a look at the proposed semantics as it feels like a "if we tweak the semantics that way, I'll compile so right" sort of proposal 14:00
jnthn For sure, maybe he'll spot something I'm missing 14:02
So far as natives go, "we get this compile into the right thing" is the point :P
*compiled
pmurias jnthn: of course, the question is if we should add a 'literal is a native int literal under the right circumstances rule' or have the user just store the result of the operation in a native var (or pass it to a native op) 14:08
jnthn We already have that rule, so the question is if we want to remove it. 14:10
And it's there based on previous discussions about how we'd like to have things work
I agree how/where it happens could use some refinement.
pmurias jnthn: I mean add in terms of have it be the 'official' specced & documented way 14:38
jnthn I'd been under the impression that we had spectests that relied on it, but apparently not 14:39
ugexe gist.github.com/ugexe/799542ce4d1d...ac86096746 So I was chasing down this bug last night. While iterating and digging through strace output that I don't understand anything about I found this which *looked* interesting gist.github.com/ugexe/686d1f775836...xt-L20-L25 15:32
geekosaur that's just from the "cat" exiting 15:33
ugexe darn 15:34
geekosaur so, I would not want to bet on it being safe to close the output just because the input thread exited 15:37
that's not async-think
you are, in effect, assuming that the write thread finishing means that the cat synchronously finished reading what it wrote and writing it back out 15:38
ugexe well i've also tried $proc.out.slurp
jnthn $proc.out.Supply?! 15:41
I mean, it should work but it's a hell of a lot of indirection :) 15:42
ugexe that was just the latest iteration. I also tried $proc.out.slurp
jnthn This version is awaiting the wrong thing, for sure. It'd have to have a Promise that is kept when the output supply is done 15:43
slurp, otoh, really should Just Work 15:44
Seems it must be something in Proc 15:50
Because gist.github.com/jnthn/0add6b73021c...cc95d62d50 works very reliably here
geekosaur my test used saving the Supply and .wait it
but it makes me wonder if, say, we're not restarting the final read
jnthn A version that uses a Channel and Proc::Async also works 15:54
(That's interesting to try because Proc works by having Proc::Async dump incoming stuff into a Channel, so a .read-internal in Pipe just receives from the Channel)
geekosaur huuuuh 15:55
one of my runs got: Cannot invoke null object in block at test.pl6 line 16
line 16 being: $s.tap({ $total += .bytes }); 15:56
jnthn eek
That's...odd indeed
geekosaur ($s is the Supply, which I saved so I can .wait it)
ugexe i played with .wait too with no luck 15:57
geekosaur right, something weird is going on and my message might indicate it's not as simple as losing input
like, somehow the closure is being lost
jnthn Yeah, I'm also somewhat suspecting a data race hiding somewhere 15:59
In Proc. Grrr. 16:00
I sometimes think I'm never going to escape working on this. :/
geekosaur doing this both correctly and portably is known to be littered with random mines :/
jnthn But please, for anything that matters, use Proc::Async. 16:01
Proc is...trying to make something inherently async Just Work in a sync way. 16:03
And it's full of "but if we do X then we fix Y but break Z" 16:04
I suspect this issue is probably that in amongst the cleverness to try and Just Work there's no something nasty. :/ 16:05
*there's now
I'm not immediately seeing it right now, though 16:06
oh hah 16:14
That was dumb
Bad assumptions'll always get you 16:15
jnthn spectests
Geth rakudo/nom: 7b175bd4b3 | (Jonathan Worthington)++ | 2 files
Make Proc cope with zero-length buffers.

It seems libuv sometimes hands over an empty buffer from stdout or stderr. These are dutifully passed along, meaning they may also be observed coming out of Proc::Async. Proc and IO::Pipe assumed that this would not happen, and mis-handled it doing so as an indication of the end.		 16:18
jnthn ugexe: That seems to fix the slurp
Probably the Supply too, but I need to wander home now 16:20
[Coke] jnthn++
ugexe ah awesome 16:51
jnthn: how did you you hunt that down? 17:10
jnthn ugexe: Eliminated Proc::Async and the .Channel coercion as likely contenders, then looked carefully at the .read-internal codepath and took a lucky guess at what might be going on :) 17:15
ugexe ah, so there is a level of intuition that is needed to debug such things effectively 17:19
jnthn Well, I figured we were looking for a reason for the slurp loop to terminate prematurely, or a way that something could get dropped 17:20
And the loop was predicated on "did we get an empty buffer" 17:21
timotimo ooooh 17:34
travis-ci Rakudo build failed. Jonathan Worthington 'Make Proc cope with zero-length buffers. 19:07
travis-ci.org/rakudo/rakudo/builds/248437879 github.com/rakudo/rakudo/compare/4...175bd4b367
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
HelpBot[perl6] github errors 19:08
travis-ci.org/rakudo/rakudo/builds/248437879 19:09
buggable [travis build above] ✓ All failures are due to timeout (0), missing build log (0), GitHub connectivity (1), or failed make test (0).
dogbert2 m: say [1,2,3].dynamic # does the dynamic method tell you whether the (array in this case) has been declared with the 'is dynamic' trait? 21:08
camelia False
dogbert2 m: my @a = ^3 is dynamic; say @a.dynamic 21:10
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3my @a = ^37⏏5 is dynamic; say @a.dynamic
expecting any of:
infix
infix stopper
postfix
statement end
…
dogbert2 m: my @a is dynamic = ^3; say @a.dynamic 21:11
camelia True
jnthn Yes.
m: my @*a; say @a.dynamic 21:12
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '@a' is not declared
at <tmp>:1
------> 3my @*a; say 7⏏5@a.dynamic
jnthn m: my @*a; say @*a.dynamic
camelia True
jnthn And * applies it for you
dogbert2 jnthn: thx, it the trai is documented but the method is not. Will fix that
so is * syntactic sugar for is dynamic? 21:13
jnthn In a declaration, yes
dogbert2 anything else I should know about it from a doc standpoint? 21:14
jnthn @*foo outside of a decalration means to look it up using dynamic scope, not lexical scope
dogbert2 cool, so even if a var is declared as 'is dynamic' you can choose which scope to use? 21:15
jnthn Well, thing is
my @*foo installs the variable under the name @*foo 21:16
my @foo is dynamic installs it under the name @foo
And that means you can't look the latter up as @*foo, you'd have to do something like DYNAMIC::<@foo> or so
dogbert2 interesting 21:17
will write something up for Hash and Array then 21:20
my @*foo is dynamic # what happens now 21:28
m: my @*foo is dynamic # what happens now
camelia ( no output )
jnthn That's just a waste of chars :) 21:31
dogbert2 jnthn: should I add/change anything in the doc? gist.github.com/dogbert17/8260285b...c775dd4afe 21:44
jnthn Yes, though you may want to note that in the Scalar case you ahve to ask $foo.VAR.dynamic 21:45
dogbert2 will do 21:46
updated the gist 22:00
.ask AlexDaniel when did you last run your script which finds broken links in the docs? 22:07
yoleaux dogbert2: I'll pass your message to AlexDaniel.
AlexDaniel .
yoleaux 22:07Z <dogbert2> AlexDaniel: when did you last run your script which finds broken links in the docs?
AlexDaniel when it was marked in the ticket
I'll run it again right now then
dogbert2 AlexDaniel++ 22:08
AlexDaniel dogbert2: FWIW, so far I've been doing just this: checklink -b -D 25 -q doc.perl6.org | tee "$(date '+%F')" 22:09
so it's something anybody can run, actually
in fact, it would be nice to do it in some sort of automated way… 22:10
HelpBot[perl6] ZOFFLOP: t/spec/S12-attributes/class.t
ZOFFLOP: t/spec/S17-supply/supplier-preserving.t 22:11
t/spec/S03-operators/mix.t
I'm guess the failures in /mix.t ain't due to my change
AlexDaniel dogbert2: it will take ≈30 minutes I think :) 22:12
dogbert2: github.com/perl6/doc/blob/master/d...#L402-L403 22:16
dogbert2 AlexDaniel: nice find: L<SetHash|/type/BSetash> 22:19
AlexDaniel awwww… some broken html… 22:20
didn't we fix <a> inside <a> problem?
dogbert2 I thought so 22:21
AlexDaniel docs.perl6.org/type/Pod::Block::Para 22:22
see line 322 for example
<a class="u" href="#___top" title="go to top of document"><a href="/routine/contents#class_Pod%3A%3ABlock">
Geth roast: a1d5c4e6d0 | (Zoffix Znet)++ | S06-other/main.t
Remove trailing whitespace
 22:32
rakudo/nom: 40b0169d08 | (Zoffix Znet)++ | src/core/Main.pm
Replace $*MAIN-ALLOW-NAMED-ANYWHERE

With %*SUB-MAIN-OPTS. The way the arguments are parsed is a contentious issue and we might see more options being proposed. There's a motion[^1] to have the $*MAIN-ALLOW-NAMED-ANYWHERE be specced, which was mostly added as a hack[^2] (for panda?). So, pre-emptively let's spec an options hash in which we can keep this and all future options. ... (7 more lines)		 22:33
roast: 754a45c006 | (Zoffix Znet)++ | S06-other/main.t
Spec %*SUB-MAIN-OPTS<named-anywhere>

Rakudo impl: github.com/rakudo/rakudo/commit/40b0169d08 Closes github.com/perl6/roast/issues/274
AlexDaniel “zoffixznet commented 9 hours ago” :) 22:40
that was pretty accurate
HelpBot[perl6] ? 22:43
Ah my saying in 10 hours
AlexDaniel e: dd %*SUB-MAIN-OPTS 22:47
evalable6 {}
HelpBot[perl6] e: say $*PERL.compiler.version 22:48
evalable6 v2017.06.112.g.40.b.0169.d.0
AlexDaniel HelpBot[perl6]: can we put named-anywhere => False there by default?
HelpBot[perl6] Dunno. Avoiding repetition is nice :/ 22:49
AlexDaniel what repetition?
I'm just thinking that it will make it easier for users
just dump %*SUB-MAIN-OPTS and see what options are available and what their default values are 22:50
HelpBot[perl6] m: say %*ENV<PERL6_TEST_DIE_ON_FAIL>
camelia (Any)
HelpBot[perl6] AlexDaniel: ah. OK
Geth rakudo/nom: e2517f802b | (Zoffix Znet)++ | src/core/Main.pm
Include default %SUB-MAIN-OPTS arguments in it; AlexDaniel++
 23:07
roast: c72357d46a | (Zoffix Znet)++ | S06-other/main.t
Test %SUB-MAIN-OPTS has stuff in it

Discussion: irclog.perlgeek.de/perl6-dev/2017-...i_14806565 Rakudo impl: github.com/rakudo/rakudo/commit/e2517f802b		 23:08
AlexDaniel
.oO( what if that's the only option we will ever add :) )
 23:10
HelpBot[perl6] Unlikely. %SUB-MAIN-OPTS<parser> = Getopts::Whatever looks very attractive 23:21
travis-ci Rakudo build errored. Zoffix Znet 'Replace $*MAIN-ALLOW-NAMED-ANYWHERE 23:28
travis-ci.org/rakudo/rakudo/builds/248567744 github.com/rakudo/rakudo/compare/7...b0169d0846
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
AlexDaniel dogbert2: I think I'll rerun it with a hope of a better result… 23:30
because BSetHash appears way too many times, I think :) 23:31
why do we see travis complaining for docs? 23:32
“The job exceeded the maximum time limit for jobs, and has been terminated.” – sure, but what maybe it slower?
HelpBot[perl6] syntax highlights IIRC 23:33
Or rather, building all the stuff
For syntax highlights. + more docs maybe? ::)

Powered by Cro and the Raku® Programming Language.

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

Thank you!