Geth rakudo: vrurg++ created pull request #3484:
Properly support generic types in Signature 'returns' attribute.		 01:14
Kaiepi vrurg, is this related to that pr you made? 01:24
m: say sub (::T $foo --> T){ $foo }(1)
camelia Died with X::TypeCheck::Return
in sub at <tmp> line 1
in block <unit> at <tmp> line 1
Kaiepi i found this a while ago but keep forgetting to bring it up
there are a couple other ways generics can fail typechecks in signatures similar to this, but they're something i'd need to golf down 01:29
01:33 sena_kun left
vrurg Kaiepi: if you have these cases somewhere around, can you test them against the PR? 01:42
Kaiepi vrurg, they're similar in that they involve generics that fail typechecks in signatures, but they aren't related to return values 01:48
vrurg Kaiepi: your case is related, as far as I see it. ::T is a generic too. But it looks like the PR doesn't fix it. 01:49
01:49 sena_kun joined
vrurg Looks like the type capture case skips Signature's instantiate_generic. Or the PR would work for this case too. 01:56
Kaiepi: you'd better open a ticket unless there's one exists already. The type capture case is more complicated as backtracking the chain of events leads me through spesh, p6typecheck op, and grammar. And I just don't have much time to dig it any further. 02:13
releasable6 Next release in ≈6 days and ≈15 hours. 3 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
03:05 hungryd49 joined 03:08 hungrydonkey left 03:12 hungrydonkey joined 03:15 hungryd49 left 03:20 Kaiepi left 03:25 Kaiepi joined, hungrydonkey left, hungrydonkey joined 03:34 sena_kun left 03:49 sena_kun joined 03:58 epony left 03:59 epony joined 05:26 linkable6 left 05:27 linkable6 joined 05:34 sena_kun left 05:47 sena_kun joined 06:47 bisectable6 left, releasable6 left, notable6 left, quotable6 left, nativecallable6 left, shareable6 left, statisfiable6 left, bloatable6 left, benchable6 left, coverable6 left, sourceable6 left, committable6 left, greppable6 left, squashable6 left, reportable6 left, linkable6 left 06:48 sourceable6 joined, coverable6 joined 06:49 benchable6 joined, notable6 joined, bisectable6 joined, releasable6 joined, squashable6 joined, committable6 joined, reportable6 joined, shareable6 joined, linkable6 joined, nativecallable6 joined, quotable6 joined, greppable6 joined 06:50 bloatable6 joined, statisfiable6 joined 07:33 sena_kun left 07:47 sena_kun joined 09:26 domidumont joined 09:32 domidumont left, domidumont joined 09:34 sena_kun left 09:49 sena_kun joined
Geth roast/6.c-errata: 5dd6bdda23 | (Elizabeth Mattijsen)++ (committed by Altai-man) | S06-signature/introspection.t
Fix test for unnamed named parameter in signature
 10:59
sena_kun how can a test pass when run on itself and fail during spec? 11:09
or, what the reasons can be? 11:10
(except races and similar issues)
lizmat load ? 11:26
sena_kun lizmat: can you please check 6.c-errata (with latest cherry-pick)? rakudo commit is 246f20db147fd1e68b296a509d2c6d2cb2595b4. S12-attributes/smiley.t has no TAP plan, and S06-signature/introspection.t fails one test, but both are clean when ran separately. 11:29
lizmat S12-attributes/smiley.t breaks for me always 11:30
11:34 sena_kun left
[Tux] Rakudo version 2020.01-213-g246f20db1 - MoarVM version 2020.01.1-39-g657b536cf
csv-ip5xs0.709 - 0.817
csv-ip5xs-205.917 - 6.080
csv-parser23.516 - 23.885
csv-test-xs-200.366 - 0.372
test7.994 - 8.179
test-t1.877 - 1.944
test-t --race0.868 - 0.931
test-t-2030.676 - 33.730
test-t-20 --race9.007 - 9.777
 11:38
lizmat Files=1302, Tests=111141, 224 wallclock secs (28.49 usr 8.49 sys + 3012.46 cusr 299.36 csys = 3348.80 CPU) 11:43
that's also quite a steep difference :-(
Geth roast/6.c-errata: 0ac2c838d7 | (Elizabeth Mattijsen)++ | S12-attributes/smiley.t
Impossible default attribute values are now compile time errors

And they throw a specific exception, so adjust tests for that.		 11:44
11:48 sena_kun joined
lizmat sena_kun: I have no idea what is going on with S06-signature/introspection.t :-( 11:53
feels like it is related to the closure fix that jnthn did the other day
sena_kun :S 11:54
sounds like a blocker then
lizmat yeah :-( 11:55
hmmm... looks like todays' spectest result included precomping test-libraries (which it shouldn't) 12:08
12:13 jjatria joined 12:15 jjatria left, jjatria joined
Geth rakudo: 1a7f16bc42 | (Elizabeth Mattijsen)++ | src/core.c/ThreadPoolScheduler.pm6
Make sure we assume 1 core on faulty info

It appears that some OS's at the moment report 0 for nqp::cpucores. Other places in the code already make sure there is at least 1 core. It seemed appropriate to do the same check for the ThreadPoolScheduler.		 12:30
13:05 lucasb joined 13:35 sena_kun left
Geth rakudo: b90bebae44 | (Elizabeth Mattijsen)++ | src/core.c/Lock.pm6
Make Lock.protect raw

  - no longer decontainerize
  - would fix github.com/lizmat/Object-Delayed/issues/5
  - **BUT** decontainerization was added specifically:
   github.com/Raku/old-issue-tracker/issues/6573
  - is spectest/stresstest/test clean
But perhaps we should make a Lock.protect-rw instead??		 13:37
lizmat .tell jnthn please have a look at github.com/rakudo/rakudo/commit/b90bebae44
13:49 sena_kun joined 15:31 hungrydonkey left 15:35 sena_kun left 15:52 sena_kun joined 15:53 Xliff joined
Xliff niner: You around? 15:53
nine: f5ce80e1a6d60a6a51a898da85f3100bb088dfb4 breaks my precomp-unlock changes. Are you now saying that the precomp-store requires locking? 15:54
Does Lock provide a way to check its status? 16:23
16:24 hungrydonkey joined
nine Xliff: I'm kinda surprised. What that commit does is provide the same level of protection to .repo-id files as it does to the precomp files. That should be easy to do in precomp-unlock shouldn't it? 16:29
Xliff nine: Yeah. I actually am pretty sure the problem is mine, after looking at things after waking up.
For one thing, I think I removed much of the precomp-store unlocking code. 16:30
But in my branch, calling destination DOES NOT lock the store without a flag. I am attempting to find the root cause. 16:31
However, after merging with master, last night. I noticed I could not install rakudo. The installation process would hang on the LAST step.
nine Probably the ususal small issue with large consequences :) 16:35
Xliff Yeah. 16:36
But now I am seeing an issue. My changes were originally written with the intent if removing the .precomp lock, entirely.
Now your changes are introduced to fix a bug. 16:37
So we now have the requirement of a .precomp lock in addition to the requirement of a file-level precomp lock.
nine The .destination method has all the information for creating a lock file for the proper target, since it does get the target extension as well
No need for a .precomp lock 16:38
16:38 Kaiepi left
Xliff OK. So your change just lock the .repo-id file, only? 16:39
nine yes
It protects against half written (i.e. created but empty) .repo-id files
Xliff But you are doing it with a singluar store object.
nine yes? 16:40
Xliff This works with vanilla rakudo because you are locking twice.
Once for .precomp and another for .repo-id
When you unlock .repo-id, in my code, you also unlock the file lock on the individual precomp file. 16:41
So, in my case, and in my case only... it looks like the .repo-id lock and the file.precomp lock have to be two separate operations, somehow. 16:42
nine sure 16:43
Xliff That will be a pain to figure out a mechanism that can be merged back into master.
I'll have to see how best to adjust and update the PR
Probably something stack based. 16:44
16:44 Kaiepi joined
nine .destination could e.g. return self!file($compiler-id, $precomp-id, :$extension) but role FileLock { has $!lock; method lock() { $!lock = (self.path.add('.lock').open(:create, :rw); $!lock.lock }; method unlock() { $!lock.unlock }; }; 16:47
And you either have the caller call .unlock on that object directly or have the caller pass this object to store.unlock 16:48
Xliff Hmmm... nice idea! 16:58
However, let me take some time to track down whether th is is root cause.
17:07 domidumont left 17:08 domidumont joined 17:34 sena_kun left
Kaiepi oooooo 17:46
`use experimental :cached` happens to do the same stuff to routines/methods that my Trait::Traced module does 17:47
which means 17:48
17:49 sena_kun joined
Kaiepi m: use experimental :cached; my method foo() is cached { } 17:49
camelia WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was:
Failed to create directory '/home/camelia/.raku/short' with mode '0o777': Failed…
Kaiepi oh that's... not the error i was looking for
but anyway, i know how to make it work with methods
which is nyi currently 17:50
18:03 hungrydonkey left
nine m: use experimental :cached; my method foo() is cached { } 19:13
camelia 5===SORRY!5=== Error while compiling <tmp>
'is cached' on methods not yet implemented. Sorry.
at <tmp>:1
19:34 sena_kun left 19:46 domidumont left 19:50 sena_kun joined
TreyHarris on #raku I was describing how I havu 422 .precompp dirs scattered all around my homedir, and 23 of them are in cloned Git repos that contain no Raku at all--those each have a 4-entry .precomp tree, of which three entries are dirs and the fourth is a '*.repo-id' file. I was warned by nine not to think of these as disposible, so I'm wondering--what's the purpose of a .precomp like that, and what 20:49
would be the effect of my deleting the entire .precomp tree of those?
(The initial effect of having .precomp's littered around everywhere may be because until recently I errantly had '.' as the first dir in my PERL6LIB.) 20:51
21:00 MasterDuke left 21:14 MasterDuke joined 21:33 sena_kun left 21:47 sena_kun joined 22:10 lucasb left 22:13 Kaiepi left, Kaiepi joined
Geth rakudo: Kaiepi++ created pull request #3487:
Implement support for using the `is cached` trait with methods		 22:18
roast: Kaiepi++ created pull request #618:
Add unit tests for use of the `is cached` trait with methods
releasable6 Next release in ≈5 days and ≈19 hours. 3 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
23:34 sena_kun left 23:48 sena_kun joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!