travis-ci Rakudo build failed. lizmat 'Merge pull request #903 from dwarring/pod-table-fix 04:47
travis-ci.org/rakudo/rakudo/builds/167177019 github.com/rakudo/rakudo/compare/f...f9ec9d90d4
Rakudo build failed. Elizabeth Mattijsen 'Make 42.match(/42/) set $/' 06:00
travis-ci.org/rakudo/rakudo/builds/167182211 github.com/rakudo/rakudo/compare/7...f09655534e
Rakudo build failed. Elizabeth Mattijsen '.head now uses generic R::I.SeqNextNFromIterator' 06:44
travis-ci.org/rakudo/rakudo/builds/167190459 github.com/rakudo/rakudo/compare/8...96512e3c99
Rakudo build failed. Elizabeth Mattijsen 'Add Iterator.skip-at-least-pull-one 07:26
travis-ci.org/rakudo/rakudo/builds/167200845 github.com/rakudo/rakudo/compare/6...221ee5de2a
[Tux] This is Rakudo version 2016.09-187-ga8221ee built on MoarVM version 2016.09-47-g736364c 07:27
csv-ip5xs 3.239
test 16.018
test-t 7.066
csv-parser 17.690
lizmat Files=1148, Tests=53321, 218 wallclock secs (12.84 usr 3.65 sys + 1321.28 cusr 122.52 csys = 1460.29 CPU) 07:37
psch uh, what's the moar equivalent of runtime.CallSiteDescriptor.explodeFlattening()..? 08:36
DrForr explodeFlattening... sounds dangerous :) 08:45
psch hm, i guess it's flatten_args() in args.c..? 08:56
the adhoc that gets thrown seems to mean something similar for the case i'm looking at 08:57
that's "Flattening named argument must have VMHash REPR" on jvm and "flattening of other hash reprs NYI." on moar
which, yeah, seems to mean something similar
jnthn wonders what other REPRs we even would implement it for... :) 09:08
psch the golf that triggers that stuff like e.g. 'my ($x, %h) := (1, { a => 1, b => 2 })', fwiw 09:11
+is
and, well, it's still fallout from the BOOTSTRAPATTR -> Attribute change 09:12
jnthn m: my ($x, %h) := (1, { a => 1, b => 2 }) 09:15
camelia ( no output )
psch j: my ($x, %h) := (1, { a => 1, b => 2 })
camelia ( no output )
jnthn m: my ($x, %h) := (1, { a => 1, b => 2 }); say $x; say %h;
camelia rakudo-moar a8221e: OUTPUT«1␤{a => 1, b => 2}␤»
psch well, it's on HEAD and doesn't build
jnthn Oh
psch because we do that kind of thing in install-core-dist.pl
note moar and jvm not having the same sha too 09:16
jnthn Did something like FLATTENABLE_HASH or FLATTENABLE_LIST get busted somewhere?
What would its default implementation be? 10:28
lizmat method skip-one() { self.pull-one !=:= IterationEnd } 10:29
(worded differently of course, but you get the picture)
so return True on successful skip, else False
jnthn returning Nil or IterationEnd might be better 10:42
lizmat why IterationEnd ? 11:17
Nil I could see as an optimization
but apart from the bikeshedding, you see the use case ? 11:18
thinking of reverting github.com/rakudo/rakudo/commit/e8...75fe065e30 to make the JVM build again 11:25
opinions? 11:26
psch in general i'd rather have less boot strap artifacts
so, i think the patch is one we rather want to have that not
on the other hand the fact that it is as disruptive as it is means that should probably have happened in a branch in the first place 11:27
so i'd go with +1 for reverting it, plus a comment requesting the work in a branch, including potential backend changes 11:28
because, as usual, the fact that a rakudo level change works on moar and doesn't on jvm means that we're not doing an equivalent thing 11:32
i'm not sure what other changes MasterDuke17 tried locally, but what i tried didn't fix it completely either, and the resulting problems are somewhere in how call captures are generated, from the looks of it 11:33
so this might well be some really involved thing, and not quite worth the effort just for getting rid of BOOTSTRAPATTR, depending on how important introspectability at those points is... 11:34
anyway, i've got some stuff to take care of \o
lizmat psch: noted 11:51
going to be afk for the rest of the day&
dalek ast: c65f4fe | (Zoffix Znet)++ | S32-hash/map.t:
[coverage] Cover Map.clone
 12:19
p3rln00b travis-ci.org/rakudo/rakudo/builds/167200845 12:20
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
p3rln00b :) Taught it to spot JVM-only failures
m: my $m = (butter => 0.22, sugar => 0.1, sugar => 0.02).Mix; dd $m.Bag 12:34
camelia rakudo-moar a8221e: OUTPUT«Type check failed in assignment; expected Int but got Rat (0.22)␤ in block <unit> at <tmp> line 1␤␤»
dalek kudo/nom: acd668e | (Zoffix Znet)++ | src/core/Mix (3 files):
Move .Bag/.BagHash into Mixy

Both Mix and MixHash have identical code in those methods, so it makes sense to move it into the role they do.		 13:06
p3rln00b is going to make .Bag/.BagHash on Mixy work for all weights. 13:22
By rounding... but I'm spotting an LTAness in it: (butter => .22).Mix gives 1 key; .Bag gives 0, because it rounds to 0 and the key disapepars 13:23
Better than crashing with a gut spill I suppose.
m: dd ('butter' => 1, 'sugar' => 1, 'sugar' => 1).Mix.Bag 13:42
camelia rakudo-moar acd668: OUTPUT«Odd number of elements found where hash initializer expected:␤Only saw: 2␤ in block <unit> at <tmp> line 1␤␤»
p3rln00b made a booboo 13:43
m: class { method foo { %.elems.say } }.foo 13:45
camelia rakudo-moar acd668: OUTPUT«Odd number of elements found where hash initializer expected:␤Only saw: 1␤ in method foo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
p3rln00b hehe
dalek kudo/nom: 5b6f4b6 | (Zoffix Znet)++ | src/core/Mix (3 files):
Revert "Move .Bag/.BagHash into Mixy"

This reverts commit acd668ee90d0f9627c4f05a966e71418b3cb7d2b. The %!elems is a private attribute and so cannot be replaced with %.elems; and we can't access %!elems in the role because reasons[^1]
  [1] irclog.perlgeek.de/perl6/2016-10-13#i_13396286		 13:47
p3rln00b ZOFVM: Files=1196, Tests=129719, 134 wallclock secs (20.29 usr 3.06 sys + 2336.09 cusr 213.69 csys = 2573.13 CPU) 13:55
dalek kudo/nom: 2d5a2c9 | (Zoffix Znet)++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
Revert "Convert some BOOTSTRAPATTRs to Attributes"

This reverts commit e8c8af60c40bbbee2c9dd8d63bb9fb75fe065e30.
Reverting per discussion[^1] to unbust JVM build. The work will be rethought and added at a later date.
  [1] github.com/rakudo/rakudo/pull/902#...-253501965
p3rln00b m: my $b = BagHash; $b<a> = -10; dd $b 14:32
camelia rakudo-moar 2d5a2c: OUTPUT«Hash $b = ${:a(-10)}␤»
p3rln00b m: my $b = BagHash.new-from-pairs: 'a' => -10; dd $b 14:33
camelia rakudo-moar 2d5a2c: OUTPUT«Use of Nil in string context␤ in block <unit> at <tmp> line 1␤Use of Nil in string context␤ in block <unit> at <tmp> line 1␤Found negative values for in ␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> l…»
p3rln00b :)
dalek kudo/nom: bf7945e | (Zoffix Znet)++ | src/core/Mix (2 files):
Fix Mixy.Bag/.BagHash coercers

The coercers work only for Mixies that were created with integer weight and spill guts if called on any other Mixy. Since non-integer weights is what defines a Mixy, most of them will likely be such.
Make coercers round the weights to integers instead of crashing.		 14:39
ast: f989df5 | (Zoffix Znet)++ | S02-types/mix (2 files):
[coverage] Cover [Mix|MixHash].[Bag|BagHash]
p3rln00b So negative weights are OK for Baggy/Mixy? 15:04
japhb p3rln00b: Seems legit at first glance. How else would you produce the additive inverse of a bag? 15:08
p3rln00b OK. just checking :) 15:09
japhb <-- Not a set theorist, that was just the product of quick rumination 15:11
japhb realizes that could be extended to: <-- Not a $foo, for nearly all values of $foo 15:13
p3rln00b That would be my view too. It's just the fact that we entirely wipe any keys that are zero instead of returning zero for them. So zero felt super special if we allow negatives 15:14
FROGGS o/ 15:25
p3rln00b japhb: reading the speculation, I came to conclusion negatives are not allowed. For Baggy, the integer values are "replication values" and you can convert a Baggy to a List by replicating each element by the number of weights. For Mixies, it says "Negative weights are not deleted, but the implementation may complain if it notices you attempting to use such a weight." 16:22
And nother note for Bag/BagHash says values are restricted to UInt 16:25
m: my $b = Bag.new; $b<foo>++; dd $b 16:40
camelia rakudo-moar bf7945: OUTPUT«Cannot resolve caller postfix:<++>(Int); the following candidates␤match the type but require mutable arguments:␤ (Mu:D $a is rw)␤ (Int:D $a is rw)␤␤The following do not match for other reasons:␤ (Bool:D $a is rw)␤ (Bool:U $a is rw…»
p3rln00b oh wait, immutability
m: my $b = BagHash.new; $b<foo>++; dd $b 16:41
camelia rakudo-moar bf7945: OUTPUT«BagHash $b = ("foo"=>1).BagHash␤»
p3rln00b (it's ironic I did not bother to actually read the error message I worked so hard to improve to mention the rw match :P) 16:43
m: my $b = class lolwut {}; $b<foo> = -10; $b.^name.say 17:02
camelia rakudo-moar bf7945: OUTPUT«Hash␤»
p3rln00b creepy :}
s: Int, 'AT-KEY', \(1) 17:03
SourceBaby p3rln00b, Sauce is at github.com/rakudo/rakudo/blob/bf79...ny.pm#L362
p3rln00b The defined check does nothing there... 17:04
geekosaur pretend it's c++? :p 17:05
p3rln00b doesn't know c++
geekosaur a class is just a special case of a struct (which semantically plays a similar role to some uses of a hash) 17:06
p3rln00b ah 17:07
0.o I removed that supposedly useless .defined check and got a spectest failure. 17:45
m: my %weather; %weather{<Philadelphia>;<tempurature humidity description>} = 7, .54, "Mostly cloudy"; dd %weather; 17:47
camelia rakudo-moar bf7945: OUTPUT«Hash %weather = {:Philadelphia(${:description("Mostly cloudy"), :humidity(0.54), :tempurature(7)})}␤»
p3rln00b Locally now gives Hash %weather = {:Philadelphia(${:description("Mostly cloudy")})} 17:48
p3rln00b is so confused. 17:57
I placed dd [ SELF, SELF.defined ]; inside AT-KEY(Any:U \SELF).... And both with { SELF.defined || (SELF = Hash.new); and with { SELF = Hash.new; it prints 3 Anys with Bool::False for .defined, YET, somehow removing that SELF.defined breaks things :/ 17:58
s: Any:U, 'defined', \() 17:59
SourceBaby p3rln00b, Something's wrong: ␤ERR: No such method 'can' for invocant of type 'Perl6::Metamodel::DefiniteHOW'␤ in sub sourcery at /home/zoffix/services/lib/CoreHackers-Sourcery/lib/CoreHackers/Sourcery.pm6 (CoreHackers::Sourcery) line 25␤ in block <unit> at -e line 6␤␤
p3rln00b s: Any, 'defined', \()
SourceBaby p3rln00b, Sauce is at github.com/rakudo/rakudo/blob/bf79.../Mu.pm#L85
p3rln00b weird shit
Is spectest supposed to pass with --optimize=off? 18:06
timotimo well, how badly does it fail? :)
p3rln00b Last I ran it I think there were only a couple of files where there was a repeatable failure, but I think it starts to flop more without optimizer 18:08
The script that generates perl6.wtf coverage runs stresstest 3 times, just to weed out all the floppers 18:09
dalek p: 3b26b79 | (Pawel Murias)++ | src/vm/jvm/QAST/Compiler.nqp:
Implement nqp::indexingoptimized on the JVM.
 19:32
p: eea0044 | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Respect int_box hll setting when turning native ints into objects.
 19:33
p: 682f825 | (Pawel Murias)++ | t/qast/01-qast.t:
Test that the int_box hll setting works.
p: 5a81cc9 | (Pawel Murias)++ | src/vm/js/nqp-runtime/code-ref.js:
[js] Hide warning.
p: e45f27a | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Implement a noop indexingoptimized.
nqp: ed68a7c | (Pawel Murias)++ | src/QRegex/Cursor.nqp:
nqp: Remove workaround as indexingoptimized is now avaliable on all backends.
rakudo/nom: 7f16cbb | (Zoffix Znet)++ | src/core/Cool.pm: 19:40
rakudo/nom: Fix Cool.IO coercion
rakudo/nom:
rakudo/nom: Currently, calling .IO on a type object attempts to create a new IO::Path
rakudo/nom: using it, so we end up with gut-referencing warnings. This is especially
rakudo/nom: harmful with coersions on optional args, as sub (IO(Str) :$foo) {}(), for
rakudo/nom: example will emit undef-in-Str warnings.
rakudo/nom:
rakudo/nom: Do the coersion only for :D params. For :U, return an IO::Path type object.
rakudo/nom:
rakudo/nom: Note: not sure what the purpose of |c was. IMO, its presents allows for users
rakudo/nom: to call the method with some args, expecting the args to do something.
rakudo/nom: I removed it, to prevent such silent calls with args that do nothing.
rakudo/nom: Stresstest passes.
p3rln00b github.com/rakudo/rakudo/commit/7f...b4ac0c56b4
s/presents/presence/; 19:43
FROGGS pmurias++ && p3rln00b++
lizmat Zoffix: re bf7945eec5e400d9ccef3 , I'm leaning towards .Inting rhe values, rather than .round ing 23:10
travis-ci Rakudo build failed. Zoffix Znet 'Revert "Move .Bag/.BagHash into Mixy" 23:37
travis-ci.org/rakudo/rakudo/builds/167361698 github.com/rakudo/rakudo/compare/a...6f4b6fb522
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
Zoffix lizmat, how come? 23:38
My reasoning was we preserve as much information as possible.
m: my @v = ^1000_000; given now { @v.map: *.Int; say now - $_ }; given now { @v.map: *.round; say now - $_ } 23:45
camelia rakudo-moar 7f16cb: OUTPUT«0.72849114␤0.7287468␤»
Zoffix m: my @v = ^1000_000; given now { @v.map: *.Int; say now - $_ }; given now { @v.map: *.round; say now - $_ }
camelia rakudo-moar 7f16cb: OUTPUT«0.7336577␤0.7050265␤»
Zoffix m: my @v = ^1000_000; given now { @v.map: *.Int; say now - $_ }; given now { @v.map: *.round; say now - $_ }
camelia rakudo-moar 7f16cb: OUTPUT«0.7292247␤0.7043846␤»
Zoffix m: my @v = ^1000_000 .map: *+rand; given now { @v.map: *.Int; say now - $_ }; given now { @v.map: *.round; say now - $_ } 23:46
camelia rakudo-moar 7f16cb: OUTPUT«1.4653255␤7.037124␤»
Zoffix .round is a lot slower, but then we make a language design decision to sacrifice some accuracy based on a particular implementation's perfomance. ¯\_(ツ)_/¯ 23:47
lizmat, that's my reasoning basically. If you feel .Int is a better choice, please change it. You have more experience with this thing :) 23:48
TimToady if we're totally into preserving information, we shouldn't allow the coercion in the first place :) 23:50
but nowhere else in the language do we default to rounding
m: say (0..10)[4.6] 23:52
camelia rakudo-moar 7f16cb: OUTPUT«4␤»
TimToady truncation is usually more in line with modular arithmetical thinking
so we tend to require people to specify rounding explicitly when that's what they want 23:54
we could, for instance, have an explicit .round method on a Mix that returns a Bag 23:55
Zoffix OK. Changing to Int :) 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!