|
🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel! Set by lizmat on 6 September 2022. |
|||
|
00:24
maylay left
00:26
maylay joined
00:35
derpydoo left
|
|||
| wayland | Question: In Rakudoc, how do I put a > inside a C<> block? | 00:53 | |
| Answer: Use C<<>> | 01:01 | ||
|
01:29
jpn joined
01:33
jpn left
02:06
hulk joined
02:07
kylese left
02:46
ulipink joined
03:05
yewscion_ joined
|
|||
| wayland | A comment. I just upgraded from Rakudo 2024-08 to one from the last couple of months. I have a class, and in one of the methods it has the following piece of code: for self[0..*] -> $row { | 03:07 | |
| The class "does Positional". Nothing else changed other than the upgrade. Now, rather than iterating over its own elements, it just runs the loop once, but seems to pick up the first element for some reason. | 03:08 | ||
|
03:12
yewscion_ left
03:15
hulk left,
kylese joined
|
|||
| wayland | Fix: Changing it to the following worked: self[0..*-1] | 03:15 | |
|
03:17
jpn joined
03:22
jpn left
03:42
derpydoo joined
03:53
codesections joined
03:57
codesections left
03:58
Aedil joined
04:00
Aedil left
04:12
jpn joined
04:17
jpn left
04:19
ulipink left
04:23
codesections joined
04:28
codesections left,
codesections joined
04:30
kylese left
04:32
codesections left
04:34
kylese joined
04:40
stanrifkin joined,
Opus left
04:41
stanrifkin_ left
04:55
codesections joined
04:57
Aedil joined
05:00
codesections left
06:01
jpn joined
06:05
jpn left
07:25
esh left
|
|||
| librasteve | wayland: looks to me that self[] is your issue … since that is indexing the element after the last element in your array :-) … it possible that this behaviour is undefined in different way in newer raku … btw self[^] is another way to say this | 07:33 | |
| Voldenet | actually, $a[0..*] doesn't do anything Positional, I wonder what it means | 07:35 | |
| m: my @a := role :: does Positional { method elems() { say "elems"; 0 } }.new; say @a[0..*] | |||
| camelia | (<anon|1>.new) | ||
| Voldenet | m: my @a := role :: does Positional { method elems() { say "elems"; 0 } }.new; say @a[0..*-1] | ||
| camelia | elems () |
||
| Voldenet | in the second case, "elems" get called | 07:36 | |
|
08:33
jpn joined
08:37
jpn left
09:03
jpn joined
09:05
maylay left
09:07
maylay joined
09:08
jpn left
09:15
jpn joined
09:25
kylese left
09:27
kylese joined
09:32
maylay left
09:35
maylay joined
10:00
sena_kun joined
10:08
derpydoo left
|
|||
| melezhik. | ugexe: tbh I am sure that slow part is due to compilation, zef install log shows that it takes sometimes minutes to calculate dependency tree before installation stage starts … at least from kinda “black box testing” perspective… | 10:11 | |
| .tell grondilu: are you interest in sparky badge for your Chess module ? | 10:15 | ||
| tellable6 | melezhik., I'll pass your message to grondilu | ||
|
10:23
jpn left
11:10
Sgeo left
11:37
Geth joined
11:38
maylay joined
11:41
maylay left
11:46
maylay joined
11:51
yewscion_ joined
11:53
JimmyZhuo joined
12:00
yewscion_ left
12:38
yewscion_ joined
12:45
tjr left
12:46
tjr joined
13:20
JimmyZhuo left
13:25
maylay left
13:27
maylay joined
|
|||
| melezhik. | I am sure -> I am not sure | 13:33 | |
|
13:59
apac joined
|
|||
| ugexe | What distribution is taking minutes to calculate its dependencies? | 14:02 | |
|
14:36
librasteve_ left
|
|||
| melezhik. | As an example Air - has got just a few dependencies according to this log it takes 7 minutes to resolve all its dependencies- sparky.sparrowhub.io/report/libras...-Air/24113 | 14:42 | |
| gist.github.com/melezhik/1bce3b532...9c5c48f295 | 14:44 | ||
| Time between 09:37:51 and 09:44:17 | 14:46 | ||
| ugexe | Yet all the other ones under it finish instantly | 14:47 | |
| melezhik. | And I see similar picture sometimes for other modules - like Sparrow6 | ||
| What do you mean ? | |||
| ugexe | only one of the “resolving” dependencies lives took that long | 14:48 | |
| melezhik. | ? | ||
| Let me reiterate - I see maybe 10-15 modules under search lines and it takes 7 minutes | 14:49 | ||
| ugexe | There are multiple lines searching for dependencies that you linked. And they all finish instantly. Go see | 14:50 | |
| all But one rather | |||
| melezhik. | How so ? I am not sure if I understand a there are 4 lines prefixed with “Searching for missing” and timestamp , the first line start at 09:37:51 and the forth line starts at 09:44:17 So we have around 7 minutes apart | 14:52 | |
| ugexe | …yes. And again all the other lines finish instantly. You don’t recognize that or think it’s suspicious? | 14:53 | |
| melezhik. | 09:37:51 :: ===> Searching for missing dependencies: DateTime::Format, HTML::Escape, Cro::HTTP::Router 09:44:17 :: ===> Searching for missing dependencies: IO::Socket::Async::SSL, OO::Monitors, IO::Path::ChildSecure, Base64, HTTP::HPACK:ver<1.0.1>, Cro::Core:ver<0.8.10+>:auth<zef:cro>:api<0>, Cro::TLS:ver<0.8.10+>:auth<zef:cro>:api<0>, Crypt::Random, JSON::JWT, DateTime::Parse, Log::Timeline 09:44:17 :: ===> | ||
| Searching for missing dependencies: if, CBOR::Simple, Digest::HMAC 09:44:17 :: ===> Searching for missing dependencies: Digest:ver<1+>, TinyFloats:ver<0.0.3+>In | |||
| ugexe | anyways it’s almost certainly a rakudo issue, possibly spesh related. If you attach a debugger or something you can probably find out more | 14:54 | |
| melezhik. | For me what matters is that between zef install Air and the moment when all dependencies resolved ( even the last step finishes instantly ) - takes 7 minutes | 14:55 | |
| ugexe | as far as zef is concerned the module resolution code is pretty simple and I do not think it can be the root cause of the actual issue. | ||
| melezhik. | I don’t know what zef is doing before that - but all I know it spends 7 minutes till it”I see that all dependencies are resolved | 14:56 | |
| ugexe | Yeah, you’re gonna have to figure that out with a debugger | ||
| melezhik. | Ok , I can rephrase the is as zef spends 7 minutes for something at the beginning of installation process | 14:57 | |
|
14:58
Aedil left
|
|||
| Why ? I mean I decently can , however don’t you think this zef related issue ? | 14:58 | ||
| ugexe | No | ||
| melezhik. | definitely | ||
| ugexe | the issue is zef is written in raku | ||
| melezhik. | Why ? | ||
| ugexe | Because I have a strong mental model of how zef works | 14:59 | |
|
14:59
jpn joined
|
|||
| ugexe | Let me turn the question around: what makes you think it isn’t an issue with raku? These type of performance problems with e.g. spesh get found much more regularly than performance issues in zef | 15:02 | |
| melezhik. | Hm, that is not helpful position. Sorry . Have you tried to troubleshoot it ? People use zef and people have issues with the tool . Of course its written on Raku , but if you can make something about it or at least if you can try - please do, saying it’s not a zef issue is not constructive | ||
|
15:03
jpn left
|
|||
| ugexe | It is productive you just don’t seem to like the answer | 15:04 | |
|
15:04
Aedil joined
|
|||
| ugexe | it isn’t productive to spent time alluding to it being a zef issue when the problem that needs to be fixed is in raku | 15:05 | |
| Also I’m typing on a phone so I’m a bit short | |||
| melezhik. | That’s the point - I am not saying for sure - if this is Raku or zef related or both . But because I am using the tool I just start a simple statement I have a problem with a tool , but I don’t know there reason . Now if you have already troubleshooted this and have certain answer - please provide the one . But don’t just say - it’s not zef issues . “I have a string mental model about how zef works “ - | ||
| sorry is not technically sound argument for me | |||
| ugexe | It’s the same as your argument though | 15:06 | |
| melezhik. | Please don’t say I am alluding anything , because I am not. I am just saying like I said in a “black box testing” manner - I use zef and I have problem with how long zef works . I said it already - I am not saying what is the root cause - but for me as for end user - I see those “symptoms” if you will | 15:08 | |
| ugexe | I could rewrite zef in go, but the raku issue would still exist | 15:09 | |
| melezhik. | Tbh I don’t like the overall attitude . But ok - take it or leave it . It’s up to you as for maintainer of zef to decide whether you go a troubleshot issue or not. I just think it’s always reasonable at least assume that there might me be issue with zef itself and at least send some time for it. | 15:10 | |
| What is THE issue with Raku ? Did you investigate ? | 15:11 | ||
| ugexe | I’m done dude | ||
|
15:32
maylay left
15:35
maylay joined
|
|||
| ugexe | Sigh, I really wish people would investigate issues more before they blame something | 15:50 | |
| I just looked at the log. Explain why all the output after the long line finish at the same time? | |||
| or maybe explain why I have to ask that question to begin with | 15:51 | ||
|
16:09
maylay left
16:12
maylay joined
16:37
Guest69 joined
16:42
jpn joined
16:48
wayland76 joined
16:49
habere-et-disper joined,
wayland left
17:04
habere-et-disper left
17:38
stanrifkin left
17:45
jpn left
18:10
Guest69 left
18:34
[Coke] left
19:30
abraxxa-home joined
19:32
abraxxa-home left
19:35
abraxxa-home joined
19:36
abraxxa-home left,
abraxxa-home joined
19:38
Xliff joined
|
|||
| Xliff | Hello! | 19:38 | |
| tellable6 | 2025-03-21T13:53:35Z #raku <librasteve> Xliff: I wonder if browser detection (to logs?) is a good candidate for Cro middleware? | ||
| 2025-03-21T19:02:54Z #raku-dev <lizmat> Xliff: are you using OO::Monitor's wait-condition / need-condition in your code ? | |||
| Xliff | m: my $e = q<abc>; $e .= subst( /(b)/, "{ $/[0] }e" ); $e.say | ||
| camelia | Use of Nil in string context aec in block <unit> at <tmp> line 1 |
||
| Xliff | Why doesn't that work? | ||
| lizmat: Why would I need either of those in my code? The browser detection is done in a request scopped manner. | 19:39 | ||
| I shouldn't need any such things if it's performed in an around() block, right? | |||
| librasteve: Aren't around() blocks considered middleware? | 19:40 | ||
| melezhik. | ugexe: ok , I run build with debug mode - sparky.sparrowhub.io/report/libras...-Air/24227 | ||
|
19:41
jpn joined
|
|||
| 19:36:37 :: ===> Extracting: Digest:ver<1+> 19:36:37 :: [Digest] Command: tar -zt -f ./8f2092538c1c35ea49c3e9d613a82fe2a3ba4708.tar.gz 19:39:02 :: [Digest] Extracting with plugin: Zef::Service::Shell::tar | 19:42 | ||
| Xliff | m: my $e = q<abc>; $e ~~ /(b)/; $e.substr-rw( $/.from, $/.to - $/from) = "{ $/[0] }e" ); $e.say | ||
| camelia | ===SORRY!=== Error while compiling <tmp> Unable to parse expression in argument list; couldn't find final ')' (corresponding starter was at line 1) at <tmp>:1 ------> /(b)/; $e.substr-rw( $/.from, $/.to - $/<HERE>from) = "{ $/[0] }e" ); $e.say… |
||
| Xliff | m: my $e = q<abc>; $e ~~ /(b)/; $e.substr-rw($/.from, $/.to - $/.from) = "{ $/[0] }e" ); $e.say | 19:43 | |
| camelia | ===SORRY!=== Error while compiling <tmp> Unexpected closing bracket at <tmp>:1 ------> .from, $/.to - $/.from) = "{ $/[0] }e" <HERE>); $e.say |
||
| melezhik. | Took approximately 2 minutes 20 seconds for extracting Digest to finish | ||
| Xliff | m: my $e = q<abc>; $e ~~ /(b)/; $e.substr-rw($/.from, $/.to - $/.from) = "{ $/[0] }e" }; $e.say | ||
| camelia | ===SORRY!=== Error while compiling <tmp> Unexpected closing bracket at <tmp>:1 ------> .from, $/.to - $/.from) = "{ $/[0] }e" <HERE>}; $e.say |
||
| Xliff | m: my $e = q<abc>; $e ~~ /(b)/; $e.substr-rw($/.from, $/.to - $/.from) = "{ $/[0] }e"; $e.say | ||
| camelia | abec | ||
|
19:43
Sgeo joined
|
|||
| lizmat | Xliff: the question was about something entriely else: the use of OO::Monitors | 19:44 | |
| melezhik. | Could it be that mentioned command - Extracting with plugin: Zef::Service::Shell::tar is slow for at least some distros ? | ||
| lizmat | there's one of your modules that uses it | ||
| ugexe | melezhik i asked you to explain why all the output after the problematic line has the same timestamp | 19:45 | |
| and again, in the link you just posted i see the same pattern | |||
| it isn't taking 3 minutes to extract that distribution, its taking 3 minutes before all the text to be shown or whatever | 19:46 | ||
|
19:46
jpn left
|
|||
| ugexe | like look at the 19:39:02 timestamps | 19:46 | |
| it didn't precompile all those modules in 0 seconds | |||
| melezhik. | I don’t know . Something happen between 19:36:37 and 19:39:02 and this something takes more then 2 minutes | 20:00 | |
| tbrowder | fyi i just installed Air, took about 5 min, but i have lots of ram and cores | 20:03 | |
| Xliff | lizmat: Why whould I need those routines, then? | ||
| tbrowder | the msgs i saw looked “normal” for complex deps | 20:04 | |
|
20:04
maylay left
20:07
maylay joined
|
|||
| melezhik. | Similar delay with another build 20:01:50 :: ===> Extracting: TinyFloats:ver<0.0.3+> 20:01:50 :: [TinyFloats] Command: tar -zt -f ./b0f219fa8e4ad5099e986f9ac7ee1979e498bd58.tar.gz 20:01:50 :: [TinyFloats] Extracting with plugin: Zef::Service::Shell::tar 20:04:14 :: [TinyFloats] Command: tar -zxvf ./b0f219fa8e4ad5099e986f9ac7ee1979e498bd58.tar.gz -C ../b0f219fa8e4ad5099e986f9ac7ee1979e498bd58.tar.gz HTH | 20:09 | |
| ugexe | It feels like you haven’t read anything I’ve said | 20:12 | |
| clearly there is an issue with the output buffering, either from rakudo internally or your own ci code | 20:13 | ||
| librasteve | tbrowder: lemme try | 20:20 | |
| tbrowder: did you follow the README instructions? | 20:23 | ||
| Install Air, Cro & Red - zef install --/test cro - zef install Red --exclude="pq:ver<5>" - zef install Air | 20:24 | ||
| tbrowder | duh, no my bad | ||
| librasteve | (it will take 5 mins if you don't --/test on cro) | ||
|
20:24
Xliff left
|
|||
| tbrowder | i’ll bow out now… | 20:25 | |
| librasteve | oh ... well we are "well acquainted with raku quirks - so certainly my Getting Started needs more emphasis ... I will try and improve it | 20:26 | |
| ttfn | |||
| general question - can I somehow mark META6.json deps as --/test and so on | 20:27 | ||
| ? | |||
|
20:30
[Coke] joined
20:42
Aedil left
|
|||
| [Coke] | I agree with ugexe here, this doesn't look like a systemtic zef issue - please try to install the individual dependencies one at a time (the 3 from the first line that are clearly taking longer) and see if you can figure out which of those 3 is the problem one. | 20:45 | |
| (afk on a train) | 20:46 | ||
|
21:09
vrurg joined,
vrurg_ left
|
|||
| [Coke] | You could also do a fresh install with a verbose option from zef to get more logging output to more clearly show where the slowdown is. | 21:11 | |
|
21:38
yewscion_ left
21:39
human_blip left
21:40
human_blip joined
21:49
yewscion_ joined
21:54
yewscion_ left
22:00
habere-et-disper joined
22:04
habere-et-disper left
22:06
yewscion_ joined
22:12
yewscion_ left
22:22
yewscion_ joined
22:36
yewscion_ left
22:46
jpn joined
22:47
yewscion_ joined
22:48
wbooze joined
22:51
jpn left,
maylay left
22:52
maylay joined,
yewscion_ left
22:57
maylay left
22:59
maylay joined
23:03
yewscion_ joined
23:08
yewscion_ left
|
|||
| lizmat | Xliff: if you're not using those routines, it's all good | 23:17 | |
| tellable6 | lizmat, I'll pass your message to Xliff | ||
| lizmat | this probably means we can safely remove that functionality from OO::Monitors without breaking anybody's code | ||
|
23:19
yewscion_ joined
|
|||
| coleman | rebooting docs.raku.org | 23:26 | |
|
23:26
abraxxa-home left
|
|||
| coleman | done | 23:27 | |
| lizmat | coleman++ | 23:28 | |
|
23:34
sena_kun left
23:40
sena_kun joined
23:45
jpn joined
23:47
sena_kun left
23:50
jpn left
|
|||