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
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
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
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
[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
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
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
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
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
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
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
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.
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
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
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!