00:32
yewscion left
00:55
SrainUser left
02:07
ulipink left
02:40
guifa joined
02:44
hulk joined,
kylese left
02:45
ulipink joined
02:51
ulipink left
03:12
ulipink joined,
ulipink left,
ulipink joined
03:15
hulk left,
kylese joined
03:18
ulipink left
|
|||
grondilu | Hello. Please look at this gist.github.com/grondilu/ebceff32e...fdb4516f24 and tell me what I am missing. | 03:30 | |
03:31
zetaaaa left
|
|||
grondilu | basically I'm trying to catch a pattern in a multiline string but the regex grabs all the trailing newlines. | 03:31 | |
m: say grammar { rule TOP { ^ <line>+ $ }; rule line { <.alpha>+ } } .parse: "foo\n" | 03:37 | ||
camelia | 「foo 」 line => 「foo 」 |
||
grondilu | how can I extract "foo" and not "foo\n"? | 03:38 | |
03:39
ulipink joined
|
|||
grondilu | in a nutshell I want to parse a file with blocks of text separated by empty lines. | 03:39 | |
that can't work as I've tried if the regex catches trailing newlines. | 03:40 | ||
guifa | I would use token instead | 03:42 | |
or change <ws> to be \h | |||
so | 03:43 | ||
say grammar { rule TOP { <line> %% \n }; rule line { <.alpha>+ } } .parse: "foo\nbar\nxyz\n" | 03:44 | ||
m: say grammar { rule TOP { <line> %% \n }; rule line { <.alpha>+ } } .parse: "foo\nbar\nxyz\n" | |||
camelia | ===SORRY!=== Error while compiling <tmp> Missing quantifier on the left argument of %% at <tmp>:1 ------> say grammar { rule TOP { <line> %%<HERE> \n }; rule line { <.alpha>+ } } .parse: |
||
guifa | m: say grammar { rule TOP { <line>+ %% \n }; rule line { <.alpha>+ } } .parse: "foo\nbar\nxyz\n" | ||
camelia | Nil | ||
guifa | m: say grammar { token TOP { <line>+ %% \n }; token line { <.alpha>+ } } .parse: "foo\nbar\nxyz\n" | 03:45 | |
camelia | 「foo bar xyz 」 line => 「foo」 line => 「bar」 line => 「xyz」 |
||
grondilu tries | |||
grondilu fails | 03:47 | ||
03:48
guifa left
|
|||
grondilu | m: say grammar { token TOP { <line>+ %% \n }; token line { <.alpha>+ } } .parse: "foo\n\nbar\n\nxyz\n" | 03:49 | |
camelia | Nil | ||
grondilu | there is no empty line in "foo\nbar" | ||
ugexe | <.alpha>* | 03:55 | |
03:59
ulipink left
04:19
pony left
04:27
Aedil left
04:33
Aedil joined,
nine left,
camelia left,
nine_ joined
04:41
camelia joined
05:09
ulipink joined
05:10
yewscion joined
05:13
yewscion left
06:11
yewscion joined
06:16
yewscion left
06:55
tejr joined
07:41
Sgeo left
08:22
yewscion joined
08:26
yewscion left
08:34
renormalist left
09:20
yewscion joined
09:22
yewscion left
09:33
sena_kun joined
09:39
sena_kun left
|
|||
grondilu | m: my $pgn = "e4 e5\n\ne4 d5\n"; $pgn.match(/[<ident>+ % <ws>]+ % [^^$$]/) | 09:54 | |
camelia | ( no output ) | ||
grondilu | m: my $pgn = "e4 e5\n\ne4 d5\n"; say $pgn.match(/[<ident>+ % <ws>]+ % [^^$$]/) | ||
camelia | 「e4 e5 e4 d5」 ident => 「e4」 ws => 「 」 ident => 「e5」 ws => 「 」 ident => 「e4」 ws => 「 」 ident => 「d5」 |
||
grondilu | m: my $pgn = "e4 e5\n\ne4 d5\n"; say grammar { regex TOP { [<ident>+ % <ws>]+ % [^^$$] } }.parse: $pgn | 09:55 | |
camelia | Nil | ||
grondilu | yet it's the exact same regex! | ||
grondilu throws hand in the air in despair | 09:56 | ||
09:57
yewscion joined
|
|||
lizmat | perhaps Grammar::Debugger/Tracer can be of help ? | 09:59 | |
10:00
yewscion left
10:25
msiism left
12:25
kathe joined
|
|||
kathe | Hello to everybody. :) | 12:25 | |
timo | greetings | ||
kathe | I don't know if Mr Wall hangs out over here anymore. In case he still does: | 12:26 | |
I tasted "Pepsi" yesterday, and honestly, I liked it. | |||
As opposed to my preference from ThumbsUp and Coca Cola. | 12:27 | ||
The Pepsi people have made some changes to their formula, | |||
as far as the Indian market goes. It is not as sweet as it used to be before. | 12:28 | ||
Alrighty, bye to everybody, and I hope Raku not just survives, but also thrives. | |||
Have a great time ahead. :) | |||
12:29
kathe left
12:39
bisectable6 left
12:42
bisectable6 joined
13:27
hankache joined
13:31
hankache left
13:41
hankache joined
|
|||
hankache | hello #raku | 13:42 | |
timo | oh hai | 13:43 | |
long time no see, it feels like | |||
hankache | hello timo, indeed long time! | ||
timo | long timo :P | 13:44 | |
hankache | hahaha | ||
lizmat | hankache o/ | 13:47 | |
and best wishes for 2025! | |||
hankache | hello liz happy new year | 13:48 | |
lizmat | thank you :-) | ||
14:00
ulipink left
14:05
hankache left
|
|||
librasteve | o/ ... hi folks | 14:13 | |
turns out my JetBrains IntelliJ Ultimate subscription will expire on 13th Jan ... since I only use for non-commercial OSS development about 95% on raku, I would like to try and get a JetBrains IntelliJ Ultimate licence under the raku or cro projects ... | 14:16 | ||
... here is the application form www.jetbrains.com/shop/eform/opensource | |||
lizmat | patrickb ab5tract is that something you can do ? | ||
librasteve | this says JetBrains can support your open source project by providing free All Products Pack and Team Tools licenses to use for the development of your project. If you are a project lead or a core contributor, please fill out the form below to request this support. | ||
14:17
ulipink joined
|
|||
there is some kind of licence www.jetbrains.com/legal/docs/toolb...pensource/ that the applier would need to agree | 14:19 | ||
lizmat | librasteve: from the legalese: "Customer may renew its Product subscription for another year by submitting a written request to JetBrains 30 (thirty) days prior to the end of the Subscription period." | 14:21 | |
feels to me we won't be able to fix before the 13th :-( | |||
librasteve | well, don't worry about my deadline too much --- I am raising this for the general benefit for any contributors who like an IDE with strong raku support but cannot afford the commercial subscription | 14:22 | |
also I get the feeling that the raku community maybe has a shot at getting on the JetBrains OSS partnerships - ie sponsorships (see other languages / framworks here www.jetbrains.com/community/opensource/) --- while we are not as big as those listed, we do have strong and active JetBrains Raku plugin project ... if the RSC things that's worth making an approach, let me know if I can help with writing a | 14:27 | ||
proposal ... | |||
lizmat | looks like we have a point on the agenda in tomorrow's meeting :-) | 14:28 | |
librasteve | nice | 14:43 | |
antononcube | When I apply for the Ultimate Open Source program of JetBrains "online" I always get the automatic response that I do not qualify. Then I ask for human review and get the corresponding license granted within 1-3 days. | 14:46 | |
I think their automatic system checks for both history length and commits saturation of single repository (or three.) It did not allow (as far as I know) to apply with a set of multiple repositories that are active. | 14:48 | ||
Again, that is the automated system. Human reviewers seem to "get it" very quickly. | 14:49 | ||
14:50
ulipink left
15:00
Sgeo joined
15:09
ulipink joined,
ulipink left,
ulipink joined
15:15
ulipink left
15:46
ulipink joined
|
|||
[Coke] | we only have custom code for date formatting, right? (can't pass a string like "HH::MM" somewhere?) | 15:51 | |
15:51
ulipink left
|
|||
antononcube | Format to print a date, or format to "ingest" a date? | 15:57 | |
...i.e. interpret a date. | |||
lizmat | HH::MM with 2 colons ? | 15:58 | |
[Coke] | some languages have a set of formatting codes (probably last one I dealt with was oracle's sql) - the colons would just be passthrough, but if you have an "HH" in the format string, that's a 12-hour hour, etc. let me find the sql ref... | 16:00 | |
lizmat | TIL :-) | 16:10 | |
[Coke] | docs.oracle.com/en/database/oracle...1DAFC6D0A3 | 16:17 | |
I think a full implementation of that would be nifty but is not needed for a first pass at the PROMPT var. | 16:18 | ||
16:23
ulipink joined,
ulipink left,
ulipink joined
16:28
ulipink left
16:43
ulipink joined
16:48
ulipink left
17:03
ulipink joined
17:07
ulipink left
17:21
yewscion joined
17:38
ulipink joined,
ulipink left,
ulipink joined
17:43
ulipink left
17:48
yewscion left
18:21
yewscion joined
18:41
yewscion left
18:54
yewscion joined
18:58
ulipink joined
18:59
yewscion left
19:03
ulipink left
19:04
msiism joined
19:07
yewscion joined
|
|||
msiism | [Coke]: Looking at your latest verison if the configurable Rakudo prompt. Looks good to me in general. | 19:10 | |
Though I think it would be a good idea to offer the actual name of the software corresponding to the language and compiler version, respectively, as well. | 19:11 | ||
But cramming that into `\l` and `\v` might not be the best idea. | 19:12 | ||
[Coke] | there's a bunch of information under $*RAKU - let me know what you'd like to see. | 19:22 | |
m: dd $*RAKU | |||
camelia | Raku.new(compiler => Compiler.new(id => "E3372814772281C70E296626151E51AA68B35AB7", release => "", codename => "", name => "rakudo", auth => "Yet Another Society", version => v2024.12.40.g.633.df.2893, signature => Blob, desc => Str), name => "Raku", … | ||
[Coke] | m: dd $*RAKU | ||
camelia | Raku.new(compiler => Compiler.new(id => "E3372814772281C70E296626151E51AA68B35AB7", release => "", codename => "", name => "rakudo", auth => "Yet Another Society", version => v2024.12.40.g.633.df.2893, signature => Blob, desc => Str), name => "Raku", … | ||
[Coke] | m: say $*RAKU | 19:23 | |
camelia | Raku (6.d) | ||
[Coke] | m: say $*RAKU.compiler | ||
camelia | rakudo (2024.12.40.g.633.df.2893) | ||
[Coke] | (somewhere there's info about the VM and its version also | 19:24 | |
There was discussion recently about putting the ansi codes in a lookup somewhere - if we had that in core, we could definitely take advantage and used named colors in the prompt instead of raw escapes. | 19:25 | ||
msiism | That would be great, yes. | 19:27 | |
So, as for names, I'd personally take Raku correspoding to the language version and Rakudo to the compiler version. | 19:28 | ||
[Coke] | so instead of just "v6.d" you'd expect "Raku v6.d" ? | ||
or, I guess, "Raku (6.d)", since that's what we get above. | 19:29 | ||
? | |||
msiism | I would probably expect that, yes, in whatever the official way of putting it is. | 19:30 | |
But then, some people might prefer not to see the name. | |||
That's reasonable too. | |||
19:32
ulipink joined
|
|||
msiism | Not sure if also having `\V` and `\L` ("with name") would solve this. | 19:35 | |
19:36
ulipink left
19:38
Aedil left
|
|||
msiism | Is there a particular reason you chose `v` for the compiler version? | 19:38 | |
[Coke] | nope | 19:39 | |
I mean, I had a slight preference for the choices, but nothing super compelling, no | 19:40 | ||
basically just trying to see if it worked, and then to give a target we could make suggestions at. | |||
timo | any ideas how to make the syntax to specify the prompt formatting less annoying to work with? maybe something like "whitespace means nothing" so you can space things out a little for example? | 19:41 | |
[Coke] | also not meant to be exhaustive. Possible update: make index smarter when it's a subcommand. | ||
Could make a little mini lang, sure | |||
You might also be wanting PROMPT_COMMAND instead? | 19:42 | ||
(which i didn't write (yet)) | |||
any REPLS with prior art to inspire also welcome | 19:44 | ||
msiism | Python's REPL has ways to set the prompt through some variable in… uhh… `sys` I think. | 19:45 | |
So, I think it would be useful to have lowercase `l` for only the language version and uppercase `L` for language name plus version. | 19:46 | ||
If the version displayed alone is not surrounded by parentheses, which I'd say it shouldn't be, then the same should be the case when a name is also displayed. | 19:47 | ||
timo | and uppestcase L will give also the git commit in the version | 19:48 | |
[Coke] | I would rather just show the output of the existing commands rather than do more post-processing, if that's possible. | ||
the git commit is just part of the existing version if it's present? | |||
timo | it's in the $*RAKU.compiler output yeah | 19:49 | |
everything after the g | |||
[Coke] | I wouldn't add it in if it happens to be an actual release. | ||
timo | right, it wouldn't have it for a tag | ||
[Coke] | +1 | 19:50 | |
I'll push something that does a basic version of \l vs. \L for feedback shortly | |||
19:51
ulipink joined
|
|||
timo | committable6: 2024.6 say $*RAKU.compiler | 19:51 | |
committable6 | timo, ¦2024.6: «Cannot find this revision (did you mean “2024.06”?)» | ||
timo | committable6: 2024.06 say $*RAKU.compiler | ||
committable6 | timo, ¦2024.06: «rakudo (2024.06)» | ||
msiism | I'd probably go with `s` instead of `v`. But that's just because the Unix shells I've used give you their name with `\s` in the prompt and use `\v` to provide their version number. | 19:53 | |
`\l` versus `\s` (language versus shell) makes sense to me in the Raku context. | |||
19:55
ulipink left
|
|||
[Coke] | I like that we get \v(ersion) and \l(anguage). | 19:57 | |
msiism | My idea was that "version" is the general term, and then there is a language version and a compiler/repl version. | 19:58 | |
[Coke] | ... I also wonder if we should go with : instead of \ as the prefix to make it slightly more raku-like. | ||
msiism | As long as you can still put a literal colon into your prompt, that would work too. | 19:59 | |
ugexe | might have been nice to called 6.c, 6.d, etc standards, i.e. std | 20:00 | |
[Coke] | yah, that would be either :: or \: ... which is annoying enough that I'll leave it as is. :) | ||
ugexe | like with -std=c++11 -std=c++17 | ||
[Coke] | would we want a combined "version" then? | ||
msiism | Displaying both the language and the compiler version? | 20:07 | |
[Coke] | eh. user can write them both if they want both. | 20:12 | |
msiism | Right. | ||
[Coke] | I may do a v. small set of the date formatting and move \t and \A to \d{HH:MM} or so. | 20:18 | |
msiism | That would be an idea, yes. | 20:24 | |
There's probably some ISO standard on how to write those formats. | |||
20:26
ulipink joined,
apac joined
|
|||
[Coke] | If you can find one, that'd be helpful - otherwise I'll follow the Oracle SQL format | 20:30 | |
timo | presumably the posix standard specifying the date program and maybe the C standard or again unix that specifies strftime? | 20:31 | |
20:31
ulipink left
|
|||
msiism | Yeah, you could use strftime format strings. | 20:32 | |
[Coke] | www.man7.org/linux/man-pages/man3/...ime.3.html ? | ||
msiism | pubs.opengroup.org/onlinepubs/9699...ftime.html | 20:33 | |
That's probably the same. | |||
[Coke] | so something like \t (defaulting to %T) or \t{%H:%M} ? | ||
msiism | Sounds good to me. | 20:34 | |
The advantage of strftime format strings is also that they are all two characters long and you wouldn't need to type YYYY for the year. | 20:35 | ||
timo | pubs.opengroup.org/onlinepubs/9699...ftime.html strftime definition from i think POSIX.1-2008 | 20:36 | |
msiism | Oh, there's now a 2024 version of POSIX. | 20:37 | |
timo | i'm not sure how to navigate posix standard versions | ||
[Coke] | timo: I am tempted to just roll the few I care about (hour, minute, second) - would you have a preference to actually just call strftime ? | ||
msiism | And here's the strftime definition from that: pubs.opengroup.org/onlinepubs/9799...ftime.html | ||
timo: Older documents will hint at the latest one. | 20:38 | ||
timo | "issue 6: [...] are added for consistency with the ISO POSIX-2 standard date utility" | ||
msiism | Starting point for the latest is at pubs.opengroup.org/onlinepubs/9799919799/, apparently. | ||
timo | en.wikipedia.org/wiki/Austin_Group | 20:39 | |
msiism | And that is issue 8, it says. | ||
timo | i was looking for the first version that has it, not the newest :D | ||
newest was relatively easy to find. i guess that is the magic of this "austin group" who are working on "the one posix specification" | 20:40 | ||
msiism | :) | ||
[Coke] | Is there a way to call a formatter on an existing DateTime.now result? | 20:44 | |
I can pass it into the constructor... | |||
lizmat | .now takes a :formatter and :timezone argument | 20:45 | |
it may not be documented as such, but it does take it :-) | |||
[Coke] | I want to grab the time and then call formatting multiple times, not have to grab a fresh time for each format. | 20:46 | |
(I'm using .now(formatter) already, apologies) | |||
Guess I can do it "manually" by poking the attributes. (which is how the formatter code is working anyway) | 20:47 | ||
lizmat | what are you trying to achieve? Better efficiency ? | 20:48 | |
just OOC | |||
[Coke] | doing piecewise printing of, e.g. hour/min/sec - don't want there to be a chance that the time flips a second between grabbing the pieces. | 20:49 | |
e.g. at 11:59:59 grab the hour, then it ticks over, then grab the minutes at 60, then I print 11:00 | |||
I don't *need* the formatter, I already have all the components, I realize. no worries. | 20:50 | ||
timo | i'd probably take now.DateTime and grab everything from that | ||
lizmat | .substr on the .hh-mm-ss output ? | ||
timo | instead of using the now sub to give me whatever with a formatter | ||
[Coke] | timo: exactly. I was just used to the formatter approach when I could do it all at once. | 20:51 | |
20:52
yewscion left
|
|||
librasteve | m: my $formatter = sub ($self) { sprintf "%02d/%02d/%04d", .month, .day, .year given $self; }; say DateTime.new(now, :$formatter); | 21:00 | |
evalable6 | 01/10/2025 | ||
Raku eval | 01/10/2025 | ||
21:01
ulipink joined,
ulipink left,
ulipink joined
|
|||
librasteve | ^^ sorry folks ... I was just curious what can be done | 21:01 | |
(this from the docs) | |||
lizmat | m: say DateTime.now.mm-dd-yyyy("/") # librasteve | 21:03 | |
camelia | 01/10/2025 | ||
21:06
ulipink left
21:21
yewscion joined
21:38
ulipink joined
|
|||
librasteve | ah - thanks | 21:42 | |
21:42
ulipink left
|
|||
m: say %( DateTime.now.mm-dd-yyyy.split('-') Z=> <mm dd yyyy> ) | 21:43 | ||
evalable6 | {01 => mm, 10 => dd, 2025 => yyyy} | ||
Raku eval | {01 => mm, 10 => dd, 2025 => yyyy} | ||
librasteve | oops | 21:44 | |
m: say %( <mm dd yyyy> Z=> DateTime.now.mm-dd-yyyy.split('-')) | |||
evalable6 | {dd => 10, mm => 01, yyyy => 2025} | ||
Raku eval | {dd => 10, mm => 01, yyyy => 2025} | ||
[Coke] | remove \A, updated \t to support %T %R %H %I %M %S | 21:48 | |
21:59
ulipink joined
22:04
ulipink left
22:36
ulipink joined
22:41
ulipink left
22:46
apac left
|
|||
Geth | problem-solving/coke/repl: d3a10c7da9 | (Will Coleda)++ | solutions/rakudo/Configurable-REPL.md Add Solution for #459 |
22:59 | |
problem-solving/coke/repl: 04eae3684e | (Will Coleda)++ | solutions/rakudo/Configurable-REPL.md add defaults |
23:01 | ||
problem-solving/coke/repl: cdaa27bae6 | (Will Coleda)++ (committed using GitHub Web editor) | solutions/rakudo/Configurable-REPL.md fix markdown |
23:02 | ||
problem-solving/coke/repl: ccd0bad368 | (Will Coleda)++ (committed using GitHub Web editor) | solutions/rakudo/Configurable-REPL.md fix markdown |
23:03 | ||
problem-solving/coke/repl: d574b3cbc8 | (Will Coleda)++ (committed using GitHub Web editor) | solutions/rakudo/Configurable-REPL.md fix env var set |
|||
problem-solving/coke/repl: 73bfd80c82 | (Will Coleda)++ (committed using GitHub Web editor) | solutions/rakudo/Configurable-REPL.md fix markdown |
23:04 | ||
problem-solving/coke/repl: 29bdec4ca9 | (Will Coleda)++ (committed using GitHub Web editor) | solutions/rakudo/Configurable-REPL.md fixes |
23:07 | ||
problem-solving/coke/repl: a52cfe4491 | (Will Coleda)++ (committed using GitHub Web editor) | solutions/rakudo/Configurable-REPL.md Update Configurable-REPL.md |
23:08 | ||
problem-solving: coke++ created pull request #460: Configurable REPL prompt |
23:09 | ||
[Coke] | github.com/Raku/problem-solving/pull/460 | ||
23:12
ulipink joined
23:17
ulipink left
|
|||
msiism | Nice. | 23:18 | |
[Coke] | Needs *13*? approvals? I assume we'll see some comments and have to chsnge some things. I addressed most of your concerns here, but I think not all | 23:24 | |
msiism | I won't be able to take advantage of any changes all too soon anyway. The system I use has a 2-year-ish release cycle. | 23:27 | |
I might be tempted to build a more recent version of Rakudo from source, though. | 23:28 | ||
[Coke] | rakubrew makes that easy and also has prebuilt ones you can install | ||
msiism | Good to know. | 23:29 | |
23:35
ulipink joined
23:41
ulipink left
|