This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html
Set by lizmat on 8 June 2022.
thowe Why is this a "malformed regex"? 00:04
my regex lstname = { :i ST|BLVD|DR|CT|PASS|ALY|WAY };
oh, damn.. it's the "=" 00:06
00:09 arkiuat joined 00:13 arkiuat left 00:30 arkiuat joined 02:30 sivoais left, sivoais joined 03:18 stanrifkin_ joined 03:21 stanrifkin left 03:45 deoac left 04:00 librasteve_ left 06:47 arkiuat left
lizmat yeah, regex is similar to "method" but with different signature/ body semantics 07:14
07:15 arkiuat joined 07:20 arkiuat left 07:48 arkiuat joined 07:53 arkiuat left 08:22 arkiuat joined 08:31 arkiuat left 09:01 arkiuat joined 09:06 arkiuat left 09:28 arkiuat joined 09:33 arkiuat left
disbot4 <adorable_cheetah_13708> Not sure if this is a bug or not, but something weird is happening with the ~ character when using IO.e or IO.f: [12] > '/home/joosep/.tmux.conf'.IO.e True [13] > '/home/joosep/.tmux.conf'.IO.f True [14] > '~/.tmux.conf'.IO.e False [15] > '~/.tmux.conf'.IO.f Failed to find '/home/joosep/~/.tmux.conf' while trying to do '.f' in block <unit> at <unknown file> line 1 in any <main> at 10:02
/home/joosep/Programs/rakudo/rakudo-moar-2025.06.1-01-linux-x86_64-gcc/bin/../share/perl6/runtime/perl6.moarvm line 1 in any <entry> at /home/joosep/Programs/rakudo/rakudo-moar-2025.06.1-01-linux-x86_64-gcc/bin/../share/perl6/runtime/perl6.moarvm line 1 [16] > shell 'ls ~/.tmux.conf' /home/joosep/.tmux.conf Proc.new(in => IO::Pipe, out => IO::Pipe, err => IO::Pipe, os-error => Str, exitcode => 0, signal => 0, pid => 70436,
command => ("ls ~/.tmux.conf",)) [17] > $ raku --version Welcome to Rakudo™ v2025.06.1. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2025.06. Am I using it wrong or is something not working properly?
10:03 arkiuat joined
lizmat I don't think ~ is recognized , and intentionally so as it is not portable 10:03
disbot4 <adorable_cheetah_13708> Understood, thank you! 10:04
lizmat you could do a .subst("~",$*HOME)
10:07 arkiuat left
disbot4 <adorable_cheetah_13708> I think what tripped me up was the fact that I believed there was shell expansion going on with the tilde, but there actually wasn't. Since I didn't specify an absolute path, it instead prepended the current directory to the path and saw that there is no file named ~./tmux.conf 10:09
<adorable_cheetah_13708> but "$*HOME/.tmux.conf".IO.f works! thank you for the help 10:11
10:29 arkiuat joined 10:34 arkiuat left 11:04 arkiuat joined 11:12 arkiuat left 11:30 arkiuat joined 11:35 arkiuat left 12:05 arkiuat joined 12:09 arkiuat left 12:31 arkiuat joined 12:37 arkiuat left 13:06 arkiuat joined 13:10 arkiuat left 13:11 arkiuat joined 13:15 arkiuat left 13:32 arkiuat joined 13:38 arkiuat left 14:03 arkiuat joined 14:08 arkiuat left
disbot4 <jubilatious1_98524> Isn't there a resolve command? 14:14
<jubilatious1_98524> Oh, I guess resolve only handles symlinks: docs.raku.org/routine/resolve 14:15
14:33 arkiuat joined 14:38 arkiuat left 14:59 arkiuat joined 15:03 arkiuat left 15:15 human_blip left 15:17 human_blip joined 15:19 arkiuat joined 15:26 arkiuat left 15:44 human_blip left 15:47 human_blip joined 15:52 arkiuat joined 15:54 human_blip left 15:56 human_blip joined 15:57 arkiuat left 16:01 arkiuat joined 17:15 human_blip left 17:18 human_blip joined
thowe I'm stuck on how to write a regex... 17:21
I need to match street address strings that might be like "something RD". That part of easy, but some streets have a space between them. So I need to be able to match "something something ST" and have the something something part match, but I don't want to match "Something RD". 17:22
If I use this in a regex: my regex street { \s [\w|\d]+ [\s|\w|\d]+? } 17:24
lizmat can anything else be in front of the RD apart from the street name ? 17:25
thowe yea. I'm going to past the whole thing somewhere... hangon 17:27
lizmat also: unless you have a subset of real addresses, making assumptions about them is... hard 17:28
thowe gitlab.com/-/snippets/4878875 17:31
The problem is I ame trying to figure out how to match street names with spaces in them without capturing the "rd" part. Also, trying to capture a street name with NO space without capturing the "RD" part. 17:32
I can put the list of example street types in the regex as a "don't match this" I guess, but I don't understand why my "lazy match" isn't working at the moment.
lizmat have you considered using token instead of regex? 17:33
thowe It is currently matching "Wall ST" as the street name instead of just "wall"
lizmat that should handle the whitespace issue
thowe Which whitespace issue? The one with leading whitespace, or the space between some street names? 17:34
er, I also just corrected the example addresses, extra number in the one 17:35
I guess what I kind of have to do is say "Match everything until you see a string that looks like the "Street Name Type", but I don't know how to do that. 17:39
"look ahead assertion"? 17:42
lizmat In just pasted my example code: problem is it's eating the lstname 17:47
a lookahead assertion not match lstname should work: leaving that as an exercise :-) 17:48
thowe pasted where? 17:49
lizmat as a comment on your gist
thowe OK... I don't know what '*' does... 17:55
oh, duh
Should that still work with my named captures? 17:56
ah, crap, I was using '+' 17:57
lizmat using tokens like that will automatically capture them 17:58
with the name of the token
thowe ah
you left street as a regex and not a token, why was that? 17:59
lizmat because that needs to be able to backtrack
you probably want to define my token lstname before my regex street, so you can use it as a lookahead assertion in regex street 18:00
thowe So, I'm guessing what you are saying here is I need to use 2 different regex checks. 18:02
The second example you have doesn't work, though... It captures "Dr" as part of the street name 18:03
lizmat right, that's why you need the lookahead in street: to not match further if the next thing is the lstname 18:04
thowe I'm not grasping what needs to be done. I can't make any combination of ?before or ?after work on either the street or lstname 18:09
Are you saying one single regex should work for either case? 18:10
oh, maybe that other ? was killing it 18:12
OK, so it does need both regexes 18:14
lizmat no, I think one regex should be able to handle both cases
thowe closest I am getting is this, but it doesn't capture lstname... 18:17
"61615 Athletic Club Dr" ~~ /^ <addnum> [\s+ <predir>]? [\s+ <street>]? <?before [\s+ <lstname>] > /; 18:18
OK, I might have it 18:19
lizmat docs.raku.org/language/regexes#Loo...assertions
<!before <lstname>> 18:20
thowe this seems to work... /^ <addnum> [\s+ <predir>]? [\s+ <street>]? <?before [\s+ <lstname>]> [\s+ <lstname>]? /
lemme try against my list of 3k addresses..... 18:21
No... I can;t find one pattern now that works for both "821 NW Wall" and "821 NW Wall St" 18:31
not to mention ""61615 NW Athletic Club" vs "61615 NW Athletic Club DR" 18:33
If what it has to come before is optional, an look ahead assertion doesn't seem to be viable. 18:36
If what it has to come AFTER is optional, an look ahead assertion doesn't seem to be viable.
lizmat, thank you for all your help on this. You are, once again, my hero. 18:53
I owe you a bottle of wine. 18:54
lizmat yw 18:58
white wine please :-) 19:10
20:16 deoac joined 21:00 arkiuat left 21:19 arkiuat joined 21:32 arkiuat left 21:33 arkiuat joined 21:37 arkiuat left 22:01 arkiuat joined 22:06 arkiuat left
disbot4 <Welemtam> Hi! Running zef install Linenoise on Windows, I got stuck with a "building [FAIL]" unspecified error. The final reason is : the build script requires make (actually nmake.exe on Windows) to be in the PATH and it wasn't in my PATH. This doesn't really matter now. the real issue is that I didn't had the typical error "nmake was not recognized as a program, etc" ... the install failed silently. So I was clueless at 22:08
first ; I cloned the repo (github.com/raku-community-modules/...tree/main) and added some traces in Build.rakumod : say "Processing makefile with %vars"; note 'MY TRACE: this is stderr'; note 'MY TRACE: this is stderr (2)'; process-makefile($srcdir, %vars); note 'MY TRACE: hello before shell'; shell %vars<MAKE>, :cwd($srcdir); note 'MY TRACE: hello after shell'; Interestingly only the first stderr trace was
showed. Not even the one marked with (2). I believe it's quite a serious issue - does anyone know where this could come from ? Zef or directly Rakudo ? Thanks 🙂
22:19 arkiuat joined
lizmat I understand that raku.land/zef:japhb/Terminal::LineEditor might be a good alternative on Windows 22:26
22:29 arkiuat left
disbot4 <Welemtam> Thanks liz I will try! Though, beyond my initial problem, my concern here is rather that the stderr output disappeared in the middle of the installation for no reason 22:31
lizmat well... Windows :-( 22:37
22:37 arkiuat joined
lizmat it's been close to a quarter of a century that I last worked on Windows... so don't expect much specific feedback from me in that respect :-) 22:38
22:41 arkiuat left
disbot4 <Welemtam> Sure ^^ ... My job is to program on Windows, so I've gotten used to seeing these kind of issues. Everything related to std/console handles is a pain, but never impossible to fix. Maybe not the easiest problem for me, having never contributed here, though. At least, I'd like to open a github issue, at the right place. 22:46
22:55 arkiuat joined 22:59 arkiuat left 23:24 arkiuat joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!