🦋 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.
antononcube @guifa Well, if you are presenting a different talk each time it won't be that bad... 01:47
lizmat melezhik: thanks, back online now... apparently IRC::Client still has one failure mode it does not recover from :-( 10:51
melezhik lizmat: welcome 11:00
weekly: dev.to/melezhik/simple-find-in-sou...parrow-312
notable6 melezhik, Noted! (weekly)
melezhik yet another sparrow 1 minute read stuff ) 11:01
ups - wrong link
weekly: dev.to/melezhik/useful-terminal-pl...g-code-gj0
notable6 melezhik, Noted! (weekly)
melezhik here we go
lizmat he.. thanks :-) 11:02
melezhik weekly: dev.to/melezhik/developing-a-simpl...-bash-51g0 11:03
notable6 melezhik, Noted! (weekly)
melezhik so three sparrows - are enough )))
lucs m: print ~"/baz/foo/..".IO.resolve 17:47
camelia /baz/foo/..
lucs :(
lizmat and if the path exists ?
lucs Trying... 17:48
In that case it works.
(I'll rethink my usage.) 17:49
lizmat "Returns a new IO::Path object with all symbolic links and references to the parent directory (..) resolved. This means that the filesystem is examined for each directory in the path, and any symlinks found are followed."
from the docs
lucs: perhaps you want docs.raku.org/routine/cleanup 17:50
m: print ~"/baz/foo/..".IO.cleanup
camelia /baz/foo/..
lizmat maybe not :-( 17:51
lucs Interesting. I now understand why 'resolve' wouldn't work, but it appears that 'cleanup' should have... 17:53
lizmat I think cleanup is not supposed to remove .. at appears from the doc 17:55
lucs I wonder why not? 17:57
lizmat as well :-)
lucs :-)
ugexe probably because you cant know what ../ points to 18:07
and thus you dont know if it creates "a canonical representation of the invocant path" 18:08
you can do that with ./
the funny part is I think on Windows it actually would be fine to assume ../ means "remove the previous path part" 18:10
essentially "foo/bar/../baz".IO.slurp must always return the same data as "foo/bar/../baz".IO.cleanup.slurp, and just removing path parts without checking them (i.e. resolve) would break that 18:16
lucs Ah, makes sense. 18:51
Xliff I'm trying to see if I can act on Cro internal exceptions when I am running a Cro server. Say an exception of type X::Cro::HTTP::Router::OnlyInHandler is thrown. Is there any way for me to act on that at the application level? 23:40
Near as I can tell, it looks like Cro handles those internally and I can't even get a notice that such has occurred at the application logic level. 23:41
*SMACK* -- there is Cro::UnhandledErrorReporter.... thanks anyways! 23:44