🦋 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:00 reportable6 left, reportable6 joined
uzl[m] > <@uzluisf:matrix.org> Howdy everyone, long time no see :)!... (full message at <libera.ems.host/_matrix/media/v3/d...7d555>) 00:07
01:00 linkable6 left, evalable6 left 01:01 evalable6 joined 01:02 linkable6 joined
guifa_ wait so it's really a ::U and not :U? 01:21
guifa_ tries it 01:22
wow
02:02 evalable6 left, linkable6 left, linkable6 joined 02:03 evalable6 joined 02:11 tea3po joined 02:15 teatwo left 02:27 MasterDuke joined
tonyo .tell melehzik please give the fez issue you were having with busybox another try with v51 02:27
tellable6 tonyo, I haven't seen melehzik around, did you mean melezhik?
tonyo yes
.tell melezhik please give the fez issue you were having with busybox another try with v51 02:28
tellable6 tonyo, I'll pass your message to melezhik
03:05 xinming left 03:07 xinming joined 03:15 derpydoo joined 04:04 razetime joined 04:30 euandreh left 05:14 derpydoo left 05:15 razetime left 05:16 razetime joined, epony joined 05:55 razetime left 06:00 reportable6 left 06:03 reportable6 joined 06:13 razetime joined 07:13 coverable6 left, reportable6 left, committable6 left, sourceable6 left, squashable6 left, releasable6 left, shareable6 left, bloatable6 left, statisfiable6 left, notable6 left, tellable6 left, benchable6 left, unicodable6 left, quotable6 left, benchable6 joined, coverable6 joined 07:14 notable6 joined, unicodable6 joined, sourceable6 joined, statisfiable6 joined, quotable6 joined 07:15 reportable6 joined, tellable6 joined, releasable6 joined, bloatable6 joined, squashable6 joined, shareable6 joined 07:16 committable6 joined 07:18 abhinav left 07:31 abhinav joined 07:46 Sgeo_ left 07:57 razetime left 08:06 nine left, m_athias left, nine joined, m_athias joined 08:13 razetime joined 08:14 dakkar joined 08:22 sena_kun joined 08:28 derpydoo joined 08:33 grondilu joined
grondilu m: put ^3 .map: {$*=-1} 08:33
camelia -1 -1 -1
grondilu weird, that is not what I get on my machine 08:35
wait
m: say ^3 .map: {$*=-1}
camelia (-1 1 -1)
grondilu m: say (^3 .map: {$*=-1}).gist 08:36
camelia (-1 1 -1)
grondilu m: say (^3 .map: {$*=-1}).Str
camelia -1 -1 -1
grondilu m: say (^3 .map: {$*=-1})[1] 08:37
camelia 1
grondilu m: say (^3 .map: {$*=-1}).Str.words[1] 08:38
camelia -1
grondilu looks like a bug tbh
let's try with a simpler state var 08:39
m: say (^3 .map: {$++})[1]
camelia 1
grondilu m: say (^3 .map: {$++}).Str.words[1]
camelia 1
grondilu m: say ^3 .map: {$++}
camelia (0 1 2)
grondilu m: put ^3 .map: {$++}
camelia 0 1 2
grondilu that is fine
08:45 euandreh joined 09:27 jpn joined 10:17 grondilu left 10:19 razetime left, jpn left 10:22 jpn joined 10:24 xinming left 10:26 xinming joined 10:28 jpn left 11:20 jpn joined 12:00 reportable6 left 12:03 reportable6 joined 12:20 derpydoo left 13:01 Nemokosch joined
Nemokosch grondilu: I suspect this has something to do with which operations copy and which do not 13:04
tellable6 Nemokosch, I'll pass your message to grondilu
Nemokosch m: say (^3 .map: {++$}).Str.words[1] # I'd expect this to behave like the *= version 13:05
camelia 2
Nemokosch welp, maybe I was wrong
m: my \state = 'hmm'; say state 13:07
camelia ===SORRY!=== Error while compiling <tmp>
Malformed state
at <tmp>:1
------> my \state = 'hmm'; say state⏏<EOL>
Nemokosch this might be an issue 13:08
lizmat it's more a case of DIHWIDT
m: my \my = 42; say my 13:09
camelia ===SORRY!=== Error while compiling <tmp>
Malformed my
at <tmp>:1
------> my \my = 42; say my⏏<EOL>
Nemokosch is there any non-metamodel way to access a variable like that?
if not, perhaps it could be banned from declaration 13:10
lizmat m: 'my \my = 42; say MY::<my>
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 1)
at <tmp>:1
------> 'my \my = 42; say MY::<my>⏏<EOL>
expecting any of:
…
lizmat m: my \my = 42; say MY::<my>
camelia 42
Nemokosch fair enough
frankly I just coincidentally named it \state, not considering that it's a collision
hm, maybe I wasn't that far off with my hypothesis 13:12
lizmat I guess we should make it impossible to name a lexical "my", "our" or "state"
Nemokosch m: my \stateful = $; (stateful++ =:= stateful, ++stateful =:= stateful, (stateful *= -1) =:= stateful).say 13:13
camelia (False False True)
Nemokosch so I think this is the reason the ++ version(s) worked but not the $*=-1 version 13:14
$++ and ++$ created 3 independent values that can be observed individually 13:15
$*=-1 just pushed references to the same variable, as it undergoes mutation
I'm more surprised, for one, that ++$ did copy 13:16
13:19 Nemokosch left 13:33 jgaz joined 14:10 teatwo joined 14:13 tea3po left 14:16 TieUpYourCamel left
[Coke] japhb: with your terminal work, do you have a way that I can have a footer (with, say, a progress bar) but emit output that scrolls by above it? (I think it's called a viewport in some contexts) 14:30
I'm using Terminal::Spinners, but then any output causes the spinner to scroll off the screen, then get redrawn on the next step
14:55 epony left 15:01 epony joined
tonyo [Coke]: what're you writing with spinners? 15:09
15:12 Sgeo joined
lizmat clickbaits rakudoweekly.blog/2023/04/03/2023-14-fulldist/ 15:12
[Coke] tonyo: digging through a few million lines of code in a few hundred git repos, put up a progress bar so I know it's working. 15:32
(and then added progress bars to everything, even the noiser ones)
(... and then the next person to run the scripts did them in Comma, which does NOT really work with the codes that spinner's use, wonder if I should open a bug report on that.) 15:33
ls 15:42
lizmat fg 15:43
lucs Doing a .resume in an exception handler appears to be pretty noisy: stdout sees "(HANDLED) …" 15:50
Any way to avoid that message?
lizmat lucs: code?
lucs I'll golf something down, sure. 15:51
lizmat m: CATCH { .resume }; say "here"; die; say "still here"
camelia here
still here
lizmat seems pretty silent to me
15:52 jpn left
lucs Sure is :) Not sure why mine is noisy -- trying to build... 15:53
m: try { CATCH { default { .resume; }; }; put +"asdf" } 15:58
camelia (HANDLED) Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏asdf' (indicated by ⏏)
in block <unit> at <tmp> line 1
lucs I'm betting it's because it's something I don't understand about how the handling occurs :) 15:59
lizmat m: CATCH { default { .resume; }; }; put +"asdf" 16:00
camelia This exception is not resumable
in block at <tmp> line 1
in any at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat that is the root of the problem 16:01
lucs: are you interested into *why* something failed, or do you just want to ignore the problem ?
lucs I was right: I don't understand :) -- but I'll think it over.
lizmat you're mixing try and CATCH, which is a code smell 16:02
lucs Oh, I'm just trying to figure out how all this exception handling works.
lizmat m: try put +"asdf" # silent
camelia ( no output )
lizmat m: CATCH { dd $_ }; put +"asdf" # looking at the type of error
camelia X::Str::Numeric.new(source => "asdf", pos => 0, reason => "base-10 number must begin with valid digits or '.'")
Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏asdf' (indicated by ⏏)
in block <un…
lizmat you usually either use CATCH, if you want to know why something went wrong 16:03
or just try (WITHOUT CATCH) if you just want to make sure the program won't die
ugexe i use CATCH inside try when I want it scoped tighter
thats probably the only good reason to do it though 16:04
lizmat right, and then you know what you're doing and understand the exact semantics of try and CATCH in Raku
for people trying to figure it out, learning to just use try *or* use CATCH in generally a good advice 16:05
ugexe maybe. i think bare CATCH can be surprising to new people unless they already know that the entire scope (including code above and below) are now essentially wrapped in a try block 16:07
tonyo m: CATCH { when X::Str::Numeric { say 'Numeric' }; default { say 'default'; }; }; put +'asdf';
camelia Numeric
tonyo m: dd try { put +'asdf'; CATCH { 1; }; }; 16:08
camelia Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏asdf' (indicated by ⏏)
in block <unit> at <tmp> line 1
tonyo m: dd try { put +'asdf'; CATCH { default { .resume; }; 1; }; };
camelia (HANDLED) Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏asdf' (indicated by ⏏)
in block <unit> at <tmp> line 1

Nil
tonyo m: CATCH { when X::Str::Numeric { say 'Numeric' }; default { say 'default'; }; }; put +'asdf'; # lucs - if you want to handle typed errors differently 16:09
camelia Numeric
lucs gist.github.com/lucs/31159810c43a0...38b10f9120
Is my example far-fetched? Seems kinda legit to me. 16:16
ugexe you understand what is happening right?
as lizmat pointed out that exception isn't resumable
lizmat except that X::Str::Numeric isn't resumable
lucs Hmm... Is it just X::Str::Numeric (and others) that isn't resumable? 16:17
And how could I tell, or how could I make my own exceptions resumable or not? 16:18
By the way, in my example, it appears that the .resume is working, no? 16:19
lizmat no, the resume throws, and is caught by the try 16:20
lucs It appears that it's the divide by 0 that throws the second time, no? 16:21
ugexe i don't think the `try` applies to inside the CATCH block 16:22
if it did then it'd probably be best to never use CATCH inside a try block, and instead put it inside bare blocks 16:24
lucs ugexe: Seems it does: see updated gist: gist.github.com/lucs/31159810c43a0...38b10f9120
tonyo m: CATCH { X::Str::Numeric { try .resume; }; default { 'default'.say; }; }; put +'asdf'; say 'hi'; 16:25
camelia ===SORRY!=== Error while compiling <tmp>
Unexpected block in infix position (missing statement control word before the expression?)
at <tmp>:1
------> CATCH { X::Str::Numeric⏏ { try .resume; }; default { 'default'.s
expectin…
lucs ugexe: (Unless I'm misunderstanding what you're saying.)
ugexe lucs: I agree with "It appears that it's the divide by 0 that throws the second time, no?"
but i also don't have a firm grasp of what is happening either lol, im just speaking out loud 16:27
lucs The way I see/understand it, the way it's handling all this is quite correct, it's just the "(HANDLING)…" that I'd like not to have.
Er, "(HANDLED)…". 16:28
ugexe like I expect that `when X::Str::Numeric { die 666 }` would die, despite the fact it is inside a try block
lucs Oh, let me try that...
Yep, it does: "666␤ in block…", that's it. 16:30
Maybe if there was a try block inside the X::Str::Numeric handler, it would… do something different. 16:31
Anyway, not sure about that (HANDLED), but there it is. 16:32
16:35 dakkar left
ugexe github.com/MoarVM/MoarVM/blob/1e5b...#L815-L820 16:37
thats where the exception comes from
if you wrap your code in a subroutine it behaves different 16:38
i wonder if .resume inside the mainline can behave strangely
lucs This is a bit (a lot) over my head. 16:40
I believe I'll apply the KISS principle in my code :)
ugexe actually i dont think it acts different, I just messed up my test code 16:43
I was trying to see what makes an exception resumable though 16:44
lucs Oh, by different, I just meant I don't know exactly offhand what would happen, given the different embedded blocks. 16:45
lucs goes for lunch 16:47
17:05 Sauvin left 17:06 Sauvin joined 17:08 Bocaneri joined 17:09 Bocaneri is now known as Guest9137 17:11 Sauvin left
japhb [Coke]: If you're asking whether I have widgets in my full-terminal TUI that handle scrolling output, then yeah, that was one of the earliest widgets I did. Probably needs some updates to bring in line with most recent widget core improvements, actually. 17:49
If you mean, do I have something now that produces the effect you're talking about *in a normal CLI*, then kinda, sorta, a hack ... but not something immediately usable (or installable) by others. 17:50
[Coke] Would be great if we had a viewport module - I could definitely use it for these work one offs. If you want to collaborate on something, I can start with your WIP. 17:59
18:00 reportable6 left, reportable6 joined
japhb [Coke]: Ah interesting, lemme think about what I can pull out. 18:28
18:35 grondilu joined
japhb [Coke]: Does your use case require proper handling of embedded control codes? If so, is it just stuff like ANSI coloring, or do you need to literally spawn a TUI child that thinks it has a slightly smaller viewport? 18:36
18:43 grondilu left 18:56 Guest9137 is now known as Sauvin 19:56 linkable6 left, evalable6 left 19:59 evalable6 joined, linkable6 joined 20:10 jgaz left 20:16 Geth__ joined, lizmat_ joined, RakuIRCLogger left 20:17 RakuIRCLogger joined 20:18 Geth left, lizmat left, lizmat_ left 20:19 lizmat joined
[Coke] The part outside the viewport (the footer) needs enough to show the progress bar, but the port itself is just raw text. (like, the output of a 100 git commands, or something) 20:25
20:29 discord-raku-bot joined
tonyo [Coke]: you could just fire up vim and keep setting the status bar 20:34
(haha) 20:35
japhb [Coke]: Are they 100 *parallel* git commands, or *serialized*? 20:41
[Coke]: And is the Raku program controlling the launching of those commands, or just reading logs therefrom (where the actual commands are spawned by some other external process)? 20:44
Dammit [Coke], you successfully nerd sniped me. Now my brain has completely task switched to this problem. 20:57
21:05 TieUpYourCamel joined 21:33 heartburn left 21:40 heartburn joined 22:17 lizmat left 22:18 lizmat joined
lucs Welp, after hours of golfing, I found out... something. 22:19
m: class Foo { class Lbel::Excep is Exception { } }; Foo::Lbel::Excep.new.throw;
camelia Died with Foo::Lbel::Excep
in block <unit> at <tmp> line 1
lucs m: class Foo { class Label::Excep is Exception { } }; Foo::Label::Excep.new.throw;
camelia Could not find symbol '&Excep' in 'Foo::Label'
in block <unit> at <tmp> line 1
lizmat yeah, fully qualified names are *NOT* relative 22:20
lucs Looks like half-and-half. 22:21
22:21 lizmat left, RakuIRCLogger joined
[Coke] japhb: MUAHAHAHA 22:21
22:22 lizmat joined
lucs The first one works as expected, but the second one fails, because of the name "Label" which is a built-in class (any such name makes it fail in the same way.) 22:22
lizmat ah... interesting
[Coke] japhb: the commands run in parallel. I can save the output and emit it after each chunk, though.
japhb: raku has a list of repos, and then races the list, cloning or updating the repos.
lucs I was naming my exception classes X::Whatever and running into this problem. 22:23
Took me a while to figure out what was going.
[Coke] output as we go, spinner updated after each git command
lucs Well actually, I still don't know what's going on, but at least I now know what to avoid :)
I hit the problem with exceptions, but maybe that's irrelevant. 22:26
I'll need to golf some more...
22:28 abhinav left
lucs Yep, it's more general: 22:32
m: class Foo { class Lbel::Jub { } }; Foo::Lbel::Jub.new; 22:33
camelia ( no output )
lucs m: class Baz { class Label::Jub { } }; Baz::Label::Jub.new;
camelia Could not find symbol '&Jub' in 'Baz::Label'
in block <unit> at <tmp> line 1
lucs Current lesson: don't name my classes using elements of names of built-in classes. 22:35
lizmat: Does this deserve opening an issue, and if so, not sure how to title it...
Hmm... Maybe it's not just built-in classes, but any class names that are already declared (or something). 22:41
Yep: 22:44
m: class Foo { }; class Baz { class Foo::Jub { } }; Baz::Foo::Jub.new;
camelia Could not find symbol '&Jub' in 'Baz::Foo'
in block <unit> at <tmp> line 1
lucs So scope resolutiion is... interesting. 22:45
23:08 bigdata joined
tonyo that looks like a bug 23:09
m: class Foo { }; class Baz { our class Foo::Jub { } }; Foo::.keys.say;
camelia (Jub)
lucs m: class Foo { }; class Baz { our class Foo::Jub { } }; Baz::.keys.say; 23:11
camelia ()
lucs m: class Foo { }; class Baz { class Foo::Jub { } }; Baz::.keys.say;
camelia ()

Powered by Cro and the Raku® Programming Language.

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

Thank you!