00:02 Kaiepi left 00:03 Kaiepi joined 00:37 Kaiepi left, Kaeipi joined 00:40 sena_kun joined 00:41 Altai-man_ left 00:57 hungrydonkey joined 00:59 Kaeipi left 01:00 Kaeipi joined 01:08 Kaeipi left 01:09 Kaiepi joined 01:21 hungrydonkey left 01:23 Kaiepi left, Kaiepi joined 01:25 hungrydonkey joined 01:33 hungrydonkey left 01:47 hungrydonkey joined 02:35 hungrydonkey left 02:37 hungrydonkey joined 02:39 Altai-man_ joined 02:42 sena_kun left 03:51 MasterDuke left 04:01 Kaiepi left 04:02 Kaiepi joined 04:40 sena_kun joined 04:42 Altai-man_ left 04:57 lichtkind joined 05:43 Kaiepi left, Kaiepi joined 06:39 Altai-man_ joined 06:41 sena_kun left 06:44 vrurg_ joined 06:48 vrurg left 07:16 hungrydonkey left 07:24 hungrydonkey joined 07:48 MasterDuke joined, hungrydonkey left
MasterDuke jnthn: dispatcher stuff sounds cool. any idea how long/difficult it will be to implement? 07:51
07:56 hungrydonkey joined 08:02 lichtkind left 08:40 sena_kun joined 08:41 Altai-man_ left
lizmat Files=1306, Tests=111228, 212 wallclock secs (28.59 usr 8.19 sys + 2987.25 cusr 269.94 csys = 3293.97 CPU) 09:16
Kaiepi m: say Mu.new ~~ Mu:D 09:21
camelia Cannot resolve caller ACCEPTS(Mu:D:U: Mu:D); none of these signatures match:
(Mu:U: \topic, *%_)
(Mu:U: Mu:U \topic, *%_)
in block <unit> at <tmp> line 1
Kaiepi it's correct for this to throw, but what's with Mu:D:U in the output?
ah, looks like it's nothing serious, just an error with how X::Multi::NoMatch generates the message 09:26
lizmat feels to me that should just return True 09:29
sena_kun yes 09:31
and isn't smartmatching policy is "never die"? 09:32
e.g. github.com/rakudo/rakudo/issues/1594
Kaiepi yeah, it'd be nice for that to return true 09:36
would something like `multi method ACCEPTS(Mu:U: Mu:D --> True)` and `multi method ACCEPTS(Any:U: Mu:D --> False)` work? 09:37
hm, that's not quite right i don't think 09:39
maybe the `:(Mu:U: Mu:U)` candidate could accept Mu:_ values instead? 09:40
if it works, that would allow the :(Mu:U: Any) candidate to be removed, which might speed up smartmatching a little 09:42
lizmat is testing: nqp::eqaddr(self,nqp::decont(topic)) && nqp::eqaddr(self.WHAT,Mu) && nqp::eqaddr(topic.WHAT,Mu) 09:44
aaahhh, /me is not awake yet 09:45
sourceable6 42 ~~ Mu:D 09:46
sourceable6: 42 ~~ Mu:D 09:47
sourceable6 lizmat, github.com/rakudo/rakudo/blob/6040....pm6#L1109
tyil hmm, 2 modules for Rakudo Star still failing: gitlab.com/tyil/rakudo-star/-/jobs/506277387 (OpenSSL and DBIish)
lizmat hmmm.. that's not very useful
tyil anyone got a clue on what to fix for these?
AlexDaniel lizmat: what were you looking for? 09:48
lizmat tyil: afaik, sena_kun has been looking into the OpenSSL stuff
AlexDaniel: trying to find the candidate that handles 42 ~~ Mu:D
tyil alright, I'll assume that highlight of them is enough for now, I'm not in a rush :>
sena_kun I was simply removing a test which relies on particular ssl implementation too much. 09:49
lizmat Kaiepi: leaving that up to you to figure out :-) 09:50
tyil sena_kun: ah, I guess you have no idea on what to "fix" here either, then :(
AlexDaniel sourceable6: Mu.ACCEPTS(42)
sourceable6 AlexDaniel, github.com/rakudo/rakudo/blob/6040...Mu.pm6#L21
AlexDaniel lizmat: like this? 09:51
lizmat yup
sena_kun tyil, what's the ssl implementation on this machine? ` Cannot locate symbol '(null)' in native library '(null)'` is odd. Can you check what github.com/sergot/openssl/blob/mas...Lib.pm6#L4 evaluates to on this machine? 09:52
AlexDaniel I just copied the code from the link above :)
the answer was about right
tyil sena_kun: it's an alpine docker image, which runs on a coreos host with linux 4.19
gitlab.com/tyil/rakudo-star/-/jobs...277387#L66 this is all the information I have about this particular runner 09:53
sena_kun `make openssl-dev` hmm 09:54
m: $*VM.platform-library-name('ssl'.IO).Str;
camelia ( no output )
sena_kun m: $*VM.platform-library-name('ssl'.IO).Str.say;
camelia libssl.so
sena_kun >Connect failed with error DBIish: DBDish::mysql needs '(null)', not found 09:55
hmm, it seems something is wrong with natives detection
Can't help with this. :(
tyil too bad
at least I know a little bit more :)
I'm not too concerned with a weird test environment not working completely, so long as people using it in practice don't have any problems
but the more things I can fix, the better 09:56
thanks for giving me a pointer, sena_kun
sena_kun tyil, I'd run a simple script with the line I linked to above to see if it produces some null. If yes, that's a bug, otherwise - a more complex bug which has to be golfed... 09:57
*run in the same env, of course 09:58
tyil yeah, that's what I was afraid of
sena_kun tyil, by the way, was it working before or is it a new thing?
tyil it's a pain to run just a single line on one of these testrunners
sena_kun: I don't think I've tested this before
sena_kun tyil, oh... might it be that e.g. `make openssl-dev` doesn't pull .so itself? 09:59
no, it seems openssl is a sub-package of openssl-dev... 10:00
tyil it doesn't seem to be an Alpine specific issue, it seems to return "libssl.so" correctly on a Rakudo Star docker image using Alpine locally 10:01
gonna grab some breakfast, and then I'll play around some more 10:05
I'd like to avoid "commit a script and trigger a gitlab-ci run", since it's incredibly cumbersome to test with :p 10:06
[Tux] Rakudo version 2020.02.1-299-g604085fb2 - MoarVM version 2020.02.1-78-ge7fee00d1
csv-ip5xs0.707 - 0.734
csv-ip5xs-206.114 - 6.192
csv-parser25.291 - 25.643
csv-test-xs-200.386 - 0.392
test7.538 - 7.626
test-t1.956 - 2.019
test-t --race0.975 - 0.994
test-t-2031.985 - 33.492
test-t-20 --race9.320 - 10.042
 10:20
nine tyil: what rakudo version is that? 10:21
tyil nine: 2020.01 10:22
nine tyil: what moarvm? 10:23
tyil 2020.01.1 10:25
10:29 hungrydonkey left
tyil looks like that coreos version reached OEL anyway 10:33
EOL*
a vm with the successor version doesn't start with some systemd errors :'D 10:34
10:39 Altai-man_ joined
Geth_ rakudo: f70d95e299 | (Elizabeth Mattijsen)++ | src/core.c/Duration.pm6
Make sure Duration.new(Rat) deconts

Without deconting it would create a self-referencing structure that would make this hang:
   my $x = 20.0;
   $x = Duration.new($x);
   say $x; # .gist creation makes this hang
As described in:
   stackoverflow.com/questions/611380...ut-not-rat		 10:40
10:42 sena_kun left
lizmat sourceable6: Duration.new(20).gist 10:51
sourceable6 lizmat, github.com/rakudo/rakudo/blob/f70d...u.pm6#L710
AlexDaniel sourceable6: Duration.new(20).gist() 10:52
sourceable6 AlexDaniel, github.com/rakudo/rakudo/blob/f70d...ic.pm6#L33
AlexDaniel lizmat: without () it points to the proto, which is also useful
lizmat indeed, thanks 10:57
Kaiepi m: say all(Mu,Any) ~~ Any 11:15
camelia False
Kaiepi fixing smartmatching of Mu:D isn't as simple as just changing Mu's ACCEPTS candidates because of junctions, but making those work again should fix this as well
lizmat Kaiepi: the difference between Mu and Any is what makes junctions work 11:19
m: sub a(\a) { dd a }; a 1|2|3
camelia 1
2
3
lizmat m: sub a(Mu \a) { dd a }; a 1|2|3
camelia any(1, 2, 3)
lizmat so I'm not sure how that could ever work
Kaiepi oh right, that should return False
with the change to Any's ACCEPTS candidates needed to make junctions work again i'm doing atm it's possible that might return all(True,True) 11:21
so i might need to rethink 11:22
ok, it doesn't do that, good 12:07
12:28 Xliff left 12:40 sena_kun joined 12:42 Altai-man_ left
Geth_ rakudo: Skarsnik++ created pull request #3613:
Add a fix for issue #3535		 12:54
linkable6 RAKUDO#3535 [open]: github.com/rakudo/rakudo/issues/3535 Comparing Buf with the is routine from Test does not behave well
jjatria japhb: Hmm... I didn't specify a grid index, nor did I create additional grids. I think this was something I bumped into before I knew there could be more than one grid 13:07
japhb: I'll try to create a minimal example and put it on an issue. That might be easier than doing this through here
Kaiepi that handful of ACCEPTS candidates in Mu/Any/Junction sure carry a lot of weight 13:10
lizmat
.oO( the buck stops here )
 13:12
Kaiepi it may be possible to remove some, though icr say for sure since i'm still fighting with them 13:18
13:29 travis-ci joined
travis-ci Rakudo build failed. Sylvain Colinet 'A fix for issue #3535' 13:29
travis-ci.com/Skarsnik/rakudo/builds/159783628 github.com/Skarsnik/rakudo/compare...3a01bd494b
13:29 travis-ci left 14:02 lucasb joined 14:31 travis-ci joined
travis-ci Rakudo build failed. Sylvain Colinet 'A fix for issue #3535, The Test routine 'is' was failing to display diff when receiving not equal Buf because you can't Stringify a Buf directly.' 14:31
travis-ci.com/Skarsnik/rakudo/builds/159790281 github.com/Skarsnik/rakudo/compare...f6448c2fca
14:31 travis-ci left 14:39 Altai-man_ joined 14:41 sena_kun left
Geth_ rakudo: Kaiepi++ created pull request #3614:
Improve smartmatching against Mu/Any/Junction		 15:25
15:57 lichtkind joined
nine Huh....the MoarVM Performance Tool only tells me "There is nothing at this URL. Return" 16:22
timotimo you need an earlier commit, sorry! 16:25
nine Do you have a commit id for me? 16:26
timotimo um, HEAD~1 probably 16:27
nine Doesn't make a difference. Also the latest master commit is from November. Has it really been broken for so long? Is timo/moarperf still the right repository? 16:29
timotimo it's the right repository, yes 16:34
i'm very sorry, i've been fully drained of moarperf-shaped tuits :|
nine Ah, don't be sorry for creating an awesome and much needed tool 16:35
I just wonder what's wrong, because I'm pretty sure that I have used it in the last half year and it hasn't changed in that time 16:36
timotimo yeah, i'll probably just have to spend like 5 minutes getting over myself and looking at why exactly react-router. 16:37
also, the code may be in the middle of going from "one file open at a time" to "multiple files open at a time"
16:40 sena_kun joined 16:42 Altai-man_ left 17:23 cognominal joined 17:27 cognomin_ left 17:34 MasterDuke left 17:37 MasterDuke joined 17:59 tobs left 18:03 tobs joined 18:39 Altai-man_ joined 18:42 sena_kun left
bartolin_ r: @ = (LABEL: while 1 { while 1 { last LABEL } }) 18:45
camelia ===SORRY!===
labeled last without loop construct
labeled last without loop construct
in block <unit> at <tmp> line 1
bartolin_ ^^ does this ring a bell for someone? it seems to be a variation of github.com/Raku/old-issue-tracker/issues/6336
r: @ = (LABEL: for 1 { for 1 { last LABEL } }); say "alive" ## this works 18:46
camelia alive
18:46 AlexDani` joined 18:48 AlexDaniel left
bartolin_ r: 'LABEL: while 1 { while 1 { last LABEL } }; say "alive"' ## work, too 18:48
camelia WARNINGS for <tmp>:
Useless use of constant string "LABEL: while 1 { while 1 { last LABEL } }; say \"alive\"" in sink context (line 1)
WARNINGS for <tmp>:
Useless use of constant string "LABEL: while 1 { while 1 { last LABEL } }; say \"alive\"" in sink context (line 1)
bartolin_ r: LABEL: while 1 { while 1 { last LABEL } }; say "alive" 18:49
camelia Error while reading '/home/camelia/p6eval-token': Permission denied at /home/camelia/rakudo-j-inst/bin/eval-client.pl line 10.
alive
lizmat bisectable6: FOO: for <a b> { NEXT say "bar"; .say; next FOO } 19:00
bisectable6 lizmat, Bisecting by exit code (old=2015.12 new=f70d95e). Old exit code: 0
lizmat, bisect log: gist.github.com/e1c1cb1ed26c15d737...7b9a7cfdd9
lizmat, (2017-01-29) github.com/rakudo/rakudo/commit/03...481f13ac5f
lizmat m: FOO: for <a b> { NEXT say "bar"; .say; next FOO } 19:01
camelia a
labeled next without loop construct
in block <unit> at <tmp> line 1
lizmat hmmm
m: FOO: for <a b> { .say; next FOO }
camelia a
b
lizmat m: FOO: for <a b> { .say; next FOO; NEXT say "bar"; } 19:02
camelia a
labeled next without loop construct
in block <unit> at <tmp> line 1
Geth_ rakudo: db6048e398 | (Elizabeth Mattijsen)++ | src/core.c/Mu.pm6
self is always deconted 1/3
 19:31
rakudo: a66f5c29a3 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
self is always deconted 2/3
rakudo: 80be7d193a | (Elizabeth Mattijsen)++ | src/core.c/Label.pm6
self is always deconted 3/3
lizmat done in separate commits for bisectability
MasterDuke why only 3? i see some more nqp::decont(self) 19:37
lizmat MasterDuke: you mean the one in Mu.raku? 19:39
working on that one: I think that can be removed completely
MasterDuke and lib/NativeCall/Types.rakumod and pseudostash
lizmat aaah... I only looked in src/core.c
MasterDuke: pseudostash ? 19:40
MasterDuke src/core.e/PseudoStash.pm6:546
lizmat ah, ok
hmmm...
looks like self *can* be container 19:41
m: my $a := Proxy.new(FETCH => { 42 }, STORE => -> $,$ { 666 }); dd $a.VAR.raku # case where self in Mu.raku is a container
camelia "42"
lizmat goes on to look at NativeCall and e. pseudostash 19:43
bartolin_ lizmat: poking around I noticed adding a nqp::decont for 'label' makes the problem from github.com/rakudo/rakudo/issues/2699 goes away: gist.github.com/usev6/d36fc514eaef...35fd41e6fd 19:47
bartolin_ didn't run tests yet
lizmat bartolin_++
Geth_ rakudo: a5535b2afb | (Elizabeth Mattijsen)++ | lib/NativeCall/Types.rakumod
self is always deconted 4/5
 19:53
rakudo: 0d5f87cc18 | (Elizabeth Mattijsen)++ | src/core.e/PseudoStash.pm6
self is always deconted 5/5
19:59 lucasb left
Geth_ rakudo: 3c83ce75a1 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make sure label handling is consistent wrt containerization

Also fixes R#2699. bartolin++ for spotting the actual fix		 20:07
linkable6 R#2699 [open]: github.com/rakudo/rakudo/issues/2699 [phasers] Labeled last/next doesn't work with FIRST/LAST/NEXT phasers
bartolin_ lizmat++ 20:10
Geth_ roast: d449e88273 | (Elizabeth Mattijsen)++ | S04-statements/label.t
Add tests for R#2699
 20:13
linkable6 R#2699 [open]: github.com/rakudo/rakudo/issues/2699 [phasers][tests needed] Labeled last/next doesn't work with FIRST/LAST/NEXT phasers
nine timotimo: I played around some more and stumbled across the URI localhost:20000/#/prof/home which gives me a somewhat working profiler :) 20:16
vrurg_ I was just passing by and saw a few words... Is timotimo trying to fix the profiler? If so then I'm excited! 20:23
20:23 vrurg_ is now known as vrurg
nine I just sent a pull request for fixing that redirect in the profiler 20:30
MasterDuke nine++
Geth_ nqp: 7407f3e75f | (Christian Bartolomäus)++ | 3 files
[JVM] Return VMNull from at_(pos|key)_boxed

  ... instead of plain null.
bartolin_ bisectable6: @ = (LABEL: while 1 { while 1 { last LABEL } }) 20:34
bisectable6 bartolin_, Using old=@ new=HEAD in an attempt to do what you mean
bartolin_, On both starting points (old=@ new=3c83ce7) the exit code is 1 and the output is identical as well
bartolin_, gist.github.com/3f7fe5fb741f47a967...68545162b1
bartolin_ that wasn't what I wanted to know :) 20:35
bisectable6: my @res = (LABEL: while 1 { while 1 { last LABEL } }); say "alive" 20:36
bisectable6 bartolin_, Bisecting by output (old=2015.12 new=3c83ce7) because on both starting points the exit code is 1
lizmat m: my @res = (LABEL: while 1 { while 1 { last LABEL } }); say "alive"
camelia labeled last without loop construct
in block <unit> at <tmp> line 1
bisectable6 bartolin_, bisect log: gist.github.com/c4646b4b1145e01d0b...84f3d35bba
bartolin_, There are 3 candidates for the first “new” revision. See the log for more details
AlexDani` dec807e1f3f05aebed4264820c525936b15e79a5 f5f80d7698bc05cf8638bf7b5e69f6bb6ef15471 3c5f7bcbf63b6d6386e92af036b2e49f9016a561 20:37
linkable6 (2016-05-01) github.com/rakudo/rakudo/commit/dec807e1f3 Make List.minmax about 15% faster
(2016-05-01) github.com/rakudo/rakudo/commit/3c5f7bcbf6 Refer to the actually existing variable.
AlexDani` f5f80d7698bc05
linkable6 (2016-04-30) github.com/rakudo/rakudo/commit/f5f80d7698 Correctly identify labeled next/last/redo Exception.
lizmat m: FOO: while 1 { last FOO }
camelia ( no output )
AlexDani` hmm I wonder why it doesn't print all three
lizmat m: FOO: while 1 { while 1 { last FOO } } 20:38
camelia ( no output )
lizmat m: (FOO: while 1 { while 1 { last FOO } })
camelia ( no output )
lizmat hmmm
bartolin_ lizmat: just in case you didn't see my earlier note: this seems to be a variation of github.com/Raku/old-issue-tracker/issues/6336 20:39
20:40 sena_kun joined
lizmat could you try removing the push-all method to see whether that fixes it ? 20:40
20:42 Altai-man_ left
bartolin_ I'm too tired right now, but I'll look again tomorrow. Thanks for the idea ;) 20:42
but one last note: we have similar tests (for the closed RT issue) in S04-statements/for.t (github.com/Raku/roast/commit/9f418777bc). The tests do pass on MoarVM. 20:45
21:09 MasterDuke left 21:17 cognomin_ joined 21:20 cognominal left 22:20 MasterDuke joined 22:38 sena_kun left 23:07 lichtkind 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!