Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
timotimo Ven``: code blocks have their first line shifted by like a third of a character, right? 00:17
Ven`` in the post from 2015th? there seems to be too many lines
timotimo oh, i see that now 00:24
01:09 Ven`` left 01:51 Ven`` joined, p6bannerbot sets mode: +v Ven`` 02:13 lizmat left 02:23 Ven`` left 02:29 lizmat joined, p6bannerbot sets mode: +v lizmat 02:34 lizmat left 06:07 AlexDaniel left 07:08 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 07:43 Tux__ left 09:06 Tux__ joined 09:07 p6bannerbot sets mode: +v Tux__ 09:25 Tux__ left, Tux__ joined 09:26 p6bannerbot sets mode: +v Tux__
masak I'm pretty sure those posts used to render fine :( 09:45
yoleaux 09:01Z <nine> masak: there's something really wrong with the text of your advent blog post: perl6advent.wordpress.com/2018/12/...happiness/ Seems like a large chunk is repeated over and over
masak will check those out when I have the time
timotimo did someone try to fix something in the article and the wordpress editor went to work on everything in there? 09:46
09:52 [TuxCM] joined 09:53 p6bannerbot sets mode: +v [TuxCM] 09:56 Tux__ left 10:23 Tux__ joined 10:24 p6bannerbot sets mode: +v Tux__ 10:26 [TuxCM] left 10:27 [TuxCM] joined, p6bannerbot sets mode: +v [TuxCM] 10:28 Tux__ left 10:49 Tux__ joined 10:50 p6bannerbot sets mode: +v Tux__ 10:53 [TuxCM] left, [TuxCM] joined 10:54 Tux__ left, p6bannerbot sets mode: +v [TuxCM] 11:06 klapperl left 11:12 lizmat joined, p6bannerbot sets mode: +v lizmat
lizmat Files=1262, Tests=87960, 368 wallclock secs (19.89 usr 6.09 sys + 2621.44 cusr 223.96 csys = 2871.38 CPU) 11:12
11:21 Tux__ joined 11:22 p6bannerbot sets mode: +v Tux__ 11:24 [TuxCM] left 11:25 [TuxCM] joined, Tux__ left 11:26 p6bannerbot sets mode: +v [TuxCM]
Geth roast: 38beb38576 | (Elizabeth Mattijsen)++ | S32-num/rat.t
Add test for R#2569
 11:48
synopsebot R#2569 [open]: github.com/rakudo/rakudo/issues/2569 [regression][severe][testneeded] SIGFPE when rounding a 0/0 Rat
11:52 Tux__ joined 11:53 p6bannerbot sets mode: +v Tux__ 11:56 [TuxCM] left 11:57 [TuxCM] joined, Tux__ left, p6bannerbot sets mode: +v [TuxCM] 12:16 klapperl joined, p6bannerbot sets mode: +v klapperl 12:23 Tux__ joined 12:24 p6bannerbot sets mode: +v Tux__ 12:27 [TuxCM] left, [TuxCM] joined 12:28 Tux__ left, p6bannerbot sets mode: +v [TuxCM] 12:50 Tux__ joined 12:51 p6bannerbot sets mode: +v Tux__ 12:53 [TuxCM] left 12:54 [TuxCM] joined, Tux__ left 12:55 p6bannerbot sets mode: +v [TuxCM] 13:08 lucasb joined, p6bannerbot sets mode: +v lucasb 13:21 Tux__ joined 13:22 p6bannerbot sets mode: +v Tux__ 13:24 [TuxCM] left 13:25 [TuxCM] joined, Tux__ left 13:26 p6bannerbot sets mode: +v [TuxCM]
|Tux| Rakudo version 2018.12-52-g5c0ac4db9 - MoarVM version 2018.12-8-g45d15efe9
csv-ip5xs0.988 - 0.988
csv-ip5xs-207.266 - 7.533
csv-parser22.622 - 22.882
csv-test-xs-200.430 - 0.451
test7.500 - 7.627
test-t1.779 - 1.868
test-t --race0.821 - 0.830
test-t-2030.424 - 30.986
test-t-20 --race9.557 - 9.846
 13:39
Geth rakudo: df748ea76f | (Elizabeth Mattijsen)++ | src/core/operators.pm6
Add infix:<=~>

As part of fixing R#2556		 13:46
synopsebot R#2556 [open]: github.com/rakudo/rakudo/issues/2556 Should =~ be a warning rather than an error?
13:52 Tux__ joined 13:53 p6bannerbot sets mode: +v Tux__ 13:56 [TuxCM] left, [TuxCM] joined 13:57 Tux__ left, p6bannerbot sets mode: +v [TuxCM]
Geth rakudo: af868f8470 | (Elizabeth Mattijsen)++ | src/Perl6/Grammar.nqp
Make .obs/.obsvar/.sorryobs/.worryobs work better

Before they were apparently returning 1 if they didn't throw, which caused the NQP regex engine to go berserk.
Fixes R#2556.		 14:10
synopsebot R#2556 [open]: github.com/rakudo/rakudo/issues/2556 Should =~ be a warning rather than an error?
14:19 [TuxCM] left
Geth rakudo: e50f4f2e33 | (Elizabeth Mattijsen)++ | 18 files
Add return signature to .WHICH methods

that were missing. There's quite a few .WHICH methods that return Str rather than a ObjAt / ValueObjAt, so that will be fixed next.		 14:43
lizmat m: sub a(--> Str:D) { Nil }; dd a # jnthn: isn't this a potential optimization issue? I mean, if you can't be sure you'll get a Str:D ? 14:53
camelia Nil 14:54
dogbert11 lizmat: stupid question but shouldn't your example above fail some kind of type check? 15:05
lizmat well, I think it is by design that it doesn't
m: sub a(--> Str:D) {Failure.new }; dd a # same for Failure 15:06
camelia Failure.new(exception => X::AdHoc.new(payload => "Failed"), backtrace => Backtrace.new)
dogbert11 you're probably right. Our doc has the following to say: "Along with Failure, Nil and its sub classes may always be returned from a routine even when the routine specifies a particular return type. It may also be returned regardless of the definedness of the return type, however, Nil is considered undefined for all other purposes." 15:07
Geth rakudo/master: 4 commits pushed by (Elizabeth Mattijsen)++ 16:19
rakudo: ca8d8afc71 | (Elizabeth Mattijsen)++ | src/core/Bag.pm6
Make Bag.WHICH return a ValueObjAt
 16:22
rakudo: 4b91610ea3 | (Elizabeth Mattijsen)++ | src/core/Mix.pm6
Make Mix.WHICH return a ValueObjAt
rakudo: 537621e410 | (Elizabeth Mattijsen)++ | src/core/Set.pm6
Make Set.WHICH return a ValueObjAt
lizmat only CompUnit and CompUnit::Repository::Locally do not have the correct WHICH yet, but they look potentially complicated and disrupting 16:23
so not touching them nnow
16:27 lucasb left
Geth rakudo: 922d41b3d0 | (Elizabeth Mattijsen)++ | src/core/Int.pm6
Make constraint check on UInt about 15% faster

By using NQP ops. There seems to be a lot of overhead involved with
  "where" base constraints, specifically find_method calls		 16:50
lizmat could it be that the where blocks don't have a name, that they're not being cached ? 16:51
17:14 ilogger2 joined 17:15 p6bannerbot sets mode: +v ilogger2
AlexDaniel jnthn, nine, timotimo, lizmat, robertle, dogbert11: So what can we do to make these issues get resolved faster? R#2563 R#2564 R##2564 17:27
synopsebot R#2563 [open]: github.com/rakudo/rakudo/issues/2563 [⚠ blocker ⚠] "Cannot declare pseudo-package GLOBAL" on mips
R#2564 [open]: github.com/rakudo/rakudo/issues/2564 [⚠ blocker ⚠] "Cannot invoke this object (REPR: Null; VMNull)" in t/04-nativecall/06-struct.t on mipsel
AlexDaniel R#2564
oh, R#2567
synopsebot R#2567 [open]: github.com/rakudo/rakudo/issues/2567 [⚠ blocker ⚠] Non-zero wait status: 11 in testt
AlexDaniel my understanding is that if we don't resolve them, we're not going to end up with 2018.12 or 2018.11 in debian 17:28
lizmat doesn't really know :-(
AlexDaniel which is going to suck in so many ways
like really, really bad for perl6 adoption…
nine AlexDaniel: can Debian not set MVM_SPESH_DISABLE=1 in the rakudo build? 17:29
AlexDaniel robertle: ↑ ? At least for mips 17:30
nine And why can't Debian ship a somewhat up to date rakudo in the first place?
AlexDaniel nine: it already has 2018.10 in testing, but 2018.10 is not a release with v6.d 17:31
now 2018.11 didn't end up there because we had an issue of some kind on big endian, which I think was fixed by you
so I was hoping that 2018.12 will be good, but we got hit unluckily by these flappers 17:32
lizmat AlexDaniel++ # pushing the packaging issues
AlexDaniel don't know if flappers can be ignored, but I'm pretty sure R#2563 has to be resolved 17:37
synopsebot R#2563 [open]: github.com/rakudo/rakudo/issues/2563 [⚠ blocker ⚠] "Cannot declare pseudo-package GLOBAL" on mips
AlexDaniel nine: also, I asked robertle if 2019.01 will end up in testing (it'll be released after the transition freeze), and they said that it's unclear 17:38
so my understanding is that we have to fix it before the transition freeze, which is 2019-01-12 17:39
plus 5 days required for the migration? makes it 2019-01-05
nine: ah, so IIRC if a package used to work fine on some architecture, then it has to keep working on it 17:44
and I remember there was a thing when rakudo package was removed completely just because it stopped working on big endian, something like that
nine Sounds like pretty stupid and destructive rules. They ship old and buggy software to all users because a newer version has some issues on some fringe architecture? 17:47
AlexDaniel I don't know the motivation for that policy and if it's actually that strict, but I suggest we don't spend energy arguing with the policy and instead fix our thing 17:50
17:53 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
nine Yep, arguing is pointless. I would just so much like users of said architectures to take part in the super boring and hard work to get stuff going there. 17:54
AlexDaniel interestingly we wouldn't have had this problem if rakudo *never* worked on mips :) 17:56
robertle I could argue for that policy if necessary, but I agree that it is kinda pointless. the two flappers are not nice, but with some luck they just disapepar for a while on the next build. which leaves #2563 as the main stumbling block to have some 6.d in the next debian release. 18:01
if there is anything I can do to help resolve it, please let me know. I am not a moar hacker, but I could run experiments or bisect something... 18:02
Geth rakudo: ef565b2ba8 | (Elizabeth Mattijsen)++ | src/core/Int.pm6
Add Int return signatures where appropriate
 18:36
rakudo: 66f8ee0fbb | (Elizabeth Mattijsen)++ | src/core/Str.pm6
Add Str return signatures where appropriate
lizmat I'm only slightly worried about the effects this has on the size of CORE.setting.moarvm 18:37
Geth rakudo: fb517b29a1 | (Elizabeth Mattijsen)++ | 2 files
Add return signatures to native arrays, where appropriate
 18:57
rakudo: 6af22bc3d6 | (Elizabeth Mattijsen)++ | 2 files
Add return siggnatures to native shaped arrays where appropriate
 19:38
20:18 lucasb joined, p6bannerbot sets mode: +v lucasb
lucasb c: ef565b2ba8,^ef565b2ba8 dd Int.Int 20:20
committable6 lucasb, ¦ef565b2: «Type check failed for return value; expected Int:D but got Int (Int)␤ in block <unit> at /tmp/9_68bxKe_A line 1␤␤ «exit code = 1»» ¦^ef565b2ba8: «Cannot find this revision (did you mean “ef565b2”?)»
lucasb c: ef565b2ba8,ef565b2ba8^ dd Int.Int
committable6 lucasb, ¦ef565b2: «Type check failed for return value; expected Int:D but got Int (Int)␤ in block <unit> at /tmp/7ng080eHCm line 1␤␤ «exit code = 1»» ¦ef565b2ba8^: «Int␤»
lucasb lizmat: ^^
c: 66f8ee0fbb,66f8ee0fbb^ dd Str.Str 20:21
committable6 lucasb, ¦66f8ee0,66f8ee0fbb^: «Use of uninitialized value of type Str in string context.␤Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful.␤ in block <unit> at /tmp/KnsxJQIynX line 1␤""␤»
lizmat lucasb: I'd argue that Int.Int should be an error, like 20:40
m: Str.Int 20:41
camelia Invocant of method 'Int' must be an object instance of type 'Str', not a type object of type 'Str'. Did you forget a '.new'?
in block <unit> at <tmp> line 1
lizmat coercion of type objects is sorta not good, right?
lucasb yeah, dunno what to think. Everything is messy :) 20:47
m: dd quietly Cool.Int 20:48
camelia 0
lucasb m: dd (quietly Cool.Num, Num.Num) 20:49
camelia (0e0, Num)
lizmat I'd argue that both are wrong 20:50
Geth rakudo: 30a534d1cb | (Elizabeth Mattijsen)++ | src/core/Int.pm6
Restore Int.Int behaviour, spotted by lucasb++

I think this warrant further discussion about what a coercer should do on a type object in general. I see a Failure as well as Nil as valid options and not the type object itself.		 21:24
lizmat m: dd Cool.IO # hrmph 21:42
camelia IO::Path
21:50 dct joined, p6bannerbot sets mode: +v dct
Geth rakudo: 2ce79561d9 | (Elizabeth Mattijsen)++ | 3 files
Add return signatures to Cool where appropriate
 22:20
23:34 MasterDuke left 23:48 lucasb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!