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
|