00:06 patrickz left 00:41 MasterDuke left 05:50 Xliff left 07:43 MasterDuke joined 08:06 lichtkind joined 08:30 patrickb joined
patrickb sena_kun: As part of #3700 I got a new AzureCI setup running on my rakudo clone. It shows a bunch of test failures all looking valid. (dev.azure.com/patrickboeker/Precom...w=results) Should I deploy this to the official rakudo repo or start bugging people to look at fixing stuff? 08:36
tellable6 patrickb, I'll pass your message to sena_kun
08:36 Altai-man_ joined
patrickb Altai-man_: Did you see my question seconds ago? ^ 08:37
Altai-man_ patrickb, hi! Will look at it now. 08:38
pod-panic seems valid to me, reproducible-builds as well, file-ops... 08:43
patrickb, I would 1)run the same state for a couple of times to consider flappers; 2)collect test names + conditions which fail and then bug people, yes. I think we have green checks in rakudo repo right now, so while the new schema is very cool, we can wait a bit. 08:45
As in, no hurry with deploying it ASAP, but bugs might be interesting to look into. E.g. failures in relocatable nqp seems worth investigating.
patrickb, am I approving codefactor.io app you suggested? 08:47
patrickb I did, yes. I don't have big intentions. Just want to run it on rakubrew.org to check two shell scripts. 08:51
Altai-man_ patrickb, oh, I thought it might be something like that. Maybe we can actually extend it later to check other scripts we are using, e.g. in nqp repo. 08:53
[Tux] Rakudo version 2020.05.1-149-g81c0e1454 - MoarVM version 2020.05-15-g644533ad1
csv-ip5xs0.823 - 0.842
csv-ip5xs-207.884 - 8.144
csv-parser24.077 - 24.325
csv-test-xs-200.386 - 0.390
test7.353 - 7.705
test-t1.870 - 1.900
test-t --race0.808 - 0.815
test-t-2031.215 - 32.149
test-t-20 --race8.773 - 9.182
 09:09
09:13 lichtkind_ joined 09:16 lichtkind left
patrickb Is it worth it to run tests on JVM automatically? They take a very long time to run. (>1:35 still running) 09:19
Altai-man_ patrickb, can skip those, that's the policy I'm aware of. 09:20
patrickb Will do.
Altai-man_ From what people told me, successful build and being able to e.g. run `-e 'say 42'` is what guaranteed on JVM backend.
MasterDuke patrickb: rakudo or nqp tests? 09:21
patrickb Both. It does get built though.
MasterDuke i wouldn't expect the nqp tests to take too terribly long 09:22
Altai-man_ Oh, yes, I meant rakudo ones.
bartolin_ patrickb: No, 'make test' on the JVM backend doesn't work. The EvalServer (that is used for 'make test') has a severy memory/threads/whatever leak. 09:24
github.com/Raku/old-issue-tracker/issues/6527 (maybe there was another ticket for 'make test') 09:25
the tests for nqp should run fine and pass 09:26
speaking about the JVM backend: does anyone have objections against merging github.com/Raku/nqp/pull/630 and github.com/rakudo/rakudo/pull/3699. That's mostly a rename of org.perl6 to org.raku for the Java classes (plus some cleanup) 09:31
patrickb Altai-man_: Did you grant the CodeFactor request? I suspect the site tripped itself up and the grant didn't go through.
Altai-man_ patrickb, I did, let me check again...
eeh 09:32
I see `codefactor.io` request Approved and another codefactor.io request not approved.
patrickb meh
Altai-man_ Currently: Approved 09:33
patrickb Seems to work now. Thanks! 09:34
Altai-man_ Now we have two requests approved and I don't see anything to remove another one. o.O
Glad it works now anyway.
patrickb Is there any reason to run NQP tests on new rakudo commits? 10:00
MasterDuke nope 10:01
Altai-man_ Shouldn't be.
patrickb I think there isn't. As rakudo changes should have no influence at all on NQP.
Right
lizmat Files=1306, Tests=111304, 213 wallclock secs (28.57 usr 8.40 sys + 2995.43 cusr 274.77 csys = 3307.17 CPU) 10:05
10:27 sena_kun joined 10:28 Altai-man_ left 10:49 MasterDuke left
Geth nqp: d3870f16ed | (Christian BartolomƤus)++ | 3 files
[JVM] Fix references to unsupported Java versions
 11:25
rakudo: 12f8f1eb48 | (Christian BartolomƤus)++ | 2 files
[JVM] Fix references to unsupported Java versions
 11:28
patrickb sena-kun: Issues created. Let's see how it goes. For Rakudo it's a single issue (nmake detection failure), for NQP there are three separate test failures. 11:49
TravisCI manages to successfully test NQP though. 11:50
sena_kun patrickb, the fix proposed some time ago (trimming the detection string constant) did not work out for this flapper?
tellable6 hey sena_kun, you have a message: gist.github.com/463ba72505ebd4b804...fc4ed286bb
sena_kun patrickb++ 11:51
patrickb sena_kun: I think it's a different failure this time. It seems that nmake didn't give any output at all. So I guess something else must be off.
sena_kun hmmm
the thing is I saw discussing a flapper where nmake wasn't detected 11:52
I remember vrurg looking at it.
patrickb sena_kun: Then might actually be related.
I have to leave (probably for the day). We'll see how it goes with the issues. 11:53
o/
11:53 patrickb left
sena_kun o/ 11:54
11:54 MasterDuke joined
Geth rakudo: 285717a0d3 | (Elizabeth Mattijsen)++ | src/core.c/REPL.pm6
Add RAKU_REPL_OUTPUT_METHOD environment variable

When set, it should contain the name of the method with which the value of an expression should be output. The default is "gist", which is the current state. Expected alternate values are "raku" and "Str". But of course you can go crazy in this, and some of you probably will. ... (8 more lines)		 12:06
12:26 Altai-man_ joined
Geth roast: e455ff7deb | (Christian BartolomƤus)++ | 4 files
[JVM] Fudge some recently added/changed tests
 12:26
12:29 sena_kun left 12:47 squashable6 left 12:49 squashable6 joined
lizmat What is wrong with this picture: 12:52
ā–¶IO::Path::Win32<1>(
:SPEC(IO::Spec::Win32),
:CWD("bar"),
:path("/foo"),
:$!is-absolute(Bool::True),
:$!abspath("\\foo"),
A: although the "is-absolute" flag is set to True, $!path and $!abspath are *not* the same 12:53
12:54 domidumont joined
lizmat m: my $io := IO::Path::Win32.new("/foo"); dd $io.path, $io.absolute # in short 12:55
camelia "/foo"
"\\foo"
lizmat should we consider this to be a bug? Or is the "abspath" / "absolute" name for the method wrong? 12:56
12:57 Kaiepi left
lizmat I guess the abspath attribute is a misnomer: it should probably be called $!ospath 13:01
MasterDuke isn't it called absolute because it won't have relative parts (e.g., '..') in it? 13:02
lizmat m: my $io := IO::Path::Win32.new("foo"); dd $io.path, $io.absolute # in short
camelia "foo"
"\\home\\camelia\\foo"
13:02 Kaiepi joined, Kaiepi left
lizmat MasterDuke: it will also provide the parent dirs if needed 13:02
13:03 Kaiepi joined
lizmat brb 13:03
13:09 domidumont left
Geth roast: 4b52c944f3 | (Christian BartolomƤus)++ | 5 files
[JVM] Fudge some currently failing tests
 13:39
rakudo: ea8c04db25 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Internally rename IO::Path's $!abspath to $!os-path

It took me quite some time to realize the subtle bug in my head that assumed that $!abspath would always be the same as $!path if the $!path was specified as an absolute path. $!abspath is the result of .absolute, which calls $!SPEC.rel2abs($!path), which may result in something entirely different, such as: ... (7 more lines)		 13:45
rakudo: bd7fcb28f4 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Remove incorrect absolute path optimization

Creating an IO::Path with an absolute path, does *not* guarantee that the absolute OS path is the same, as the former is more of a conceptual path, rather than a real thing that can be used to open a file with the given IO::SPEC semantics.		 13:56
nqp/master: 9 commits pushed by andreoss++, (Christian BartolomƤus)++ 14:09
rakudo: c68d4fc492 | (Christian BartolomƤus)++ | tools/templates/NQP_REVISION
Bump NQP for rename of java packages to org.raku.*
 14:10
rakudo: 26d88b9e52 | andreoss++ | 15 files
Bulk rename s/perl6/raku/g
 14:11
rakudo: 8e4e23ab64 | (Christian BartolomƤus)++ (committed using GitHub Web editor) | 15 files
Merge pull request #3699 from andreoss/jvm-naming

  [jvm] Rename s/perl6/raku/g
[Coke] bartolin_: nice. 14:19
bartolin_: is github.com/Raku/nqp/pull/562 mergable? 14:21
bartolin_ andreoss++ did all the work for the rename 14:23
[Coke] andreoss++
bartolin_ [Coke]: yes, I think the note is useful. personally, I'd move it a bit further down in the readme (there already is a section 'Troubleshooting') -- maybe I'll do that later 14:26
bartolin_ just noticed he already mentioned that in the PR ;) 14:27
14:27 sena_kun joined 14:29 Altai-man_ left
lizmat I'd like to do the same for the MoarVM backend, but would first like to handle as many PR's as possible, as it will basically invalidate all outstanding PR's 14:34
bartolin_ . o O ( sounds like a big task ) 14:41
15:05 Kaeipi joined 15:09 Kaiepi left
jnthn lizmat: I'm not sure there's much MoarVM-specific code that mentions Perl6, fwiw. 15:12
lizmat src/Perl6/* ? 15:13
I guess that's backend agnostic, ok, you're right :)
jnthn That's backend agnos...right :)
Well, maybe lets do it around the time we do the rakuast mergeback
lizmat the point stands :-) 15:14
jnthn Which will also invalidate any PR touching actions and world and probably grammar too, all of which live in there.
lizmat right
jnthn I'd rather do it at the end of that branch close to merge time, though, otherwise it'll make my life harder to keep up with master :)
[Coke] +1 15:18
15:27 Kaeipi is now known as Kaiepi 15:34 JJMerelo joined
JJMerelo Hi 15:34
Is there any chance a CATCH block resumes by itself?
Hum... sink maybe 15:35
This shouldn't resume after CATCH ā†’ github.com/JJ/perl6-recipes-apress...-recipe.p6 15:37
But it does. If you call it with a single argument such as Tuna the exception block will generate a default side dish... And then it runs the next sentence. 15:39
I am trying to golf it down, no way.
Any idea?
jnthn JJMerelo: It can rethrow, if you don't smartmatch the exception, but you have a default there. 15:47
What makes you think it resumes? 15:48
JJMerelo It simply runs the next sentence 15:49
Adding .resume makes no difference, it still runs the sentence right after the exception was produced. 15:50
timotimo yeh that's what you're asking for
JJMerelo timotimo can you ellaborate?
I have tried to golf it here github.com/JJ/my-raku-examples/blo...turning.p6
timotimo your catch block handles every exception, so when the exception is handled, execution continues 15:51
JJMerelo And there's no way the next sentence is run
timotimo theoretically it should exit the block and not run the sentence. According to docs and also the example above
timotimo got the docs link handy?
JJMerelo A sec 15:52
timotimo docs.raku.org/language/exceptions#...ing_blocks 15:53
That's what happens with the (theoretically golfed) example, that what _does not_ happen with the fleshed-out one. It definitely runs the next sentence. 15:54
timotimo oh so it exits the lbock if the catch lives outside
JJMerelo timotimo it exits the block in the same scope as the CATCH block 15:55
timotimo m: for ^20 { .say; die "oh no" if Bool.pick; }; CATCH { default { .say; .resume } }
camelia 0
oh no
in block <unit> at <tmp> line 1

1
2
3
oh no
in block <unit> at <tmp> line 1

4
oh no
in block <unit> at <tmp> line 1

5
oh no
in block <unit> at <tmp> line 1

6
oh no
in block <unit> at <tmp> ā€¦
timotimo m: for ^20 { .say; die "oh no" if Bool.pick; CATCH { default { .say; .resume } } }
camelia 0
1
2
oh no
in block <unit> at <tmp> line 1

3
oh no
in block <unit> at <tmp> line 1

4
5
oh no
in block <unit> at <tmp> line 1

6
7
oh no
in block <unit> at <tmp> line 1

8
9
10
oh no
in blockā€¦
timotimo m: for ^20 { .say; die "oh no" if Bool.pick; CATCH { default { .say; } } }
camelia 0
1
oh no
in block <unit> at <tmp> line 1

2
oh no
in block <unit> at <tmp> line 1

3
oh no
in block <unit> at <tmp> line 1

4
5
6
7
8
oh no
in block <unit> at <tmp> line 1

9
10
11
12
oh no
ā€¦
timotimo i suppose i never really used resumption of exceptions in my own programs 15:56
JJMerelo Those two examples behave according to the docs.
timotimo yeah 15:57
trying examples from github is still too many clicks and buton presses
JJMerelo That's why i tried to golf... but couldn't
timotimo "this won't be said, but 33"
JJMerelo timotimo but try without the .resume 15:58
timotimo aha, it says Foo but not the rest of the program outside of sub foo? 15:59
JJMerelo timotimo because it's running foo the second time inside of the CATCH block. But it does not return anyway, and does not print $valur 16:00
timotimo I thought that maybe if assigning to a global variable might be the thing; it's not.
timotimo oh i didn't see the foo there
can you restate your confusiong / expectation without the .resume? 16:01
i'm a bit unconcentrated 16:02
when you're not calling .resume, then the block that has "this won't be said" will be exited after the catch is finished 16:06
JJMerelo timotimo right. 16:22
That does not happen in the first example; it does resume. Thus my original question: when will a CATCH block auto-resume. 16:23
16:26 Altai-man_ joined 16:28 sena_kun left
timotimo ok, i need to read the first example again 16:34
there the catch isn't in a block that contains the die
sorry, i'm in a videoconference at the same time and can't concentrate on this right now 16:35
JJMerelo timotimo don't worry. Thanks anyway 16:36
Geth rakudo: b63976a8f1 | (Elizabeth Mattijsen)++ | 2 files
Make IO::Path.dir between 1.5x and 2.2x as fast

  - 2.2x without explicit condition, 1.5x with explicit condition
  - replaced the gather / take logic by true iterators in Rakudo::Iterator
  - introduced "cloned-from-path" method for faster similar IO::Path creation
   which is marked as an implementation detail
  - abstracted prefix logic in "prefix-for-dir" method
   which is marked as an implementation detail		 16:44
16:45 squashable6 left
timotimo there foo is inside the block that has the CATCH in it 16:46
oh, i was scrolled up
sorry
16:48 squashable6 joined 17:55 squashable6 left 17:56 squashable6 joined 18:27 sena_kun joined 18:28 lucasb joined 18:29 Altai-man_ left 19:05 JJMerelo left
bartolin_ .tell sena_kun I've just stumbled upon your question regarding the JVM build from github.com/rakudo/rakudo/issues/35...607099602. We had this topic earlier today, so I guess this is settled. But for the sake of completeness: I'd look for 1) a sucessful build, 2) clean tests for NQP, 3) a successfull 'make install' and 4) that a simple evaluation (./rakudo-j -e 'say 42') works 20:06
tellable6 bartolin_, I'll pass your message to sena_kun
sena_kun
bartolin_ . o O ( empty promises ) 20:07
sena_kun bartolin_, thanks! I think having CI to check JVM (I think it covers everything you noted now) makes releasing a lot easier already and, in fact, fulfills my initial request for this. 20:08
bartolin_++ # JVM fixes
bartolin_ yes, the CI setup should cover that nicely. patrickp++ and sena_kun++ (and problably others) 20:09
Geth rakudo: 853e62277a | (Elizabeth Mattijsen)++ | src/core.c/WhateverCode.pm6
Make WhateverCode.ACCEPTS about 2x as fast

Since a WhateverCode must always have at least on parameter, and ACCEPTS only accepts one parameter as well, there is no need to check any signature for WhateverCode, so give it its own candidate and directly use an nqp:: call to execute. This halves the Exclusive Time for ACCEPTS in a profile.
20:26 Altai-man_ joined 20:29 sena_kun left
Geth rakudo: a5eb1d4a9b | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Path.sibling about 2x as fast

By using the new `cloned-with-path' method		 20:33
rakudo: 26b9f388a6 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Path.succ/pred about 2x as fast

By using the new `cloned-with-path' method		 20:59
rakudo: 7238b0943b | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Path.succ/pred about 1.6x as fast

By using the new `cloned-with-path' method.		 21:15
timotimo looks like a copypasto 21:22
lizmat oops, indeed 21:25
it's about IO::Path.cleanup 21:26
I'm doing all of these in separate commits for bisectability
but it is in fact a bit of a rince / repeat
21:29 maggotbrain left
Geth rakudo: 71cb0c56f9 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Path.parent about 2.7x as fast

By using the new `cloned-with-path' method and refactor the rest of the code to ternaries *and* use
   !foo.first(* ne bar)
instead of
   !grep {$_ ne bar}, foo		 21:34
tbrowder oops, just checking in and getting ready for a rakudo PR, should i hold off and rename dirs from Perl6 to Raku? 21:40
or something?? 21:41
jnthn tbrowder: That won't be happening for months. 21:43
tbrowder ok, whew, not sure what i was seeing... 21:44
jnthn (Hopefully a small number of months, but that's the magnitude...)
tbrowder: Well, there was a discussion earlier that didn't said "when RakuAST merges", but that wasn't really a very clear indicator. :) 21:45
oops, s/didn't///
tbrowder ok, pr coming then... 21:46
Geth rakudo: f5b2c24055 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Path.child about 1.4x as fast

By using the new `cloned-with-path' method.		 21:47
rakudo: tbrowder++ created pull request #3708:
Add 'auth-fmt' compiler arg for option '--doc'		 21:49
rakudo: 21c3ef82c9 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make sure .cloned-with-path performs null check

This was not picked up by spectesting so far, but it did show in the IO::Path.child tests. This makes all of these .cloned-with-path optimizations a little bit slower, e.g. the .child one from 1.4x as fast to 1.25x as fast.
... (5 more lines)		 21:59
rakudo: 718d305b82 | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6
Make IO::Path.add about 1.25x as fast

By using the new `cloned-with-path' method.		 22:09
lizmat and that concludes my hacking for today, tomorrow more IO::Path and IO::Spec stuff
m: dd $*RAKU.version 22:13
camelia v6.d
lizmat m: dd $*VM.version
camelia v2020.05
lizmat .tell moritz looks like camelia is stuck at 81c0e1454 , now 1.5 days old 22:20
linkable6 (2020-05-20) github.com/rakudo/rakudo/commit/81c0e1454f Merge pull request #3696 from vrurg/rakudo_3693
tellable6 lizmat, I'll pass your message to moritz
lizmat sleep& 22:22
22:27 sena_kun joined 22:29 Altai-man_ left 22:54 lichtkind_ left 23:33 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!