🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku
Set by ChanServ on 14 October 2019.
00:44 wildtrees left 00:56 Xliff left 01:06 _jrjsmrtn joined, guifa joined 01:07 __jrjsmrtn__ left 01:23 melezhik joined
melezhik Hi Raku people. I've just posted a new proposal on Raku/automation using Sparrow, please share you comments. Thanks. sparrowdo.wordpress.com/2020/08/28...-proposal/ 01:23
comments could be sent to reddit - www.reddit.com/r/rakulang/comments..._proposal/ 01:26
01:33 molaf left 01:35 melezhik left 01:45 molaf joined 02:23 Cabanossi left 02:32 Cabanoss- joined 02:35 marcusr left 02:37 marcusr joined, aborazmeh joined, aborazmeh left, aborazmeh joined 02:53 Noisytoot left 03:26 marcusr left 03:27 marcusr joined 03:42 leont joined 03:59 rindolf joined 04:14 aborazmeh left 04:27 zacts joined 04:53 fooist joined 05:00 molaf left 05:05 maettu joined 05:20 billN1VUX left 05:26 bocaneri joined 05:32 wamba joined, maettu left 05:39 Doc_Holliwould joined 06:04 xinming left 06:05 xinming joined 06:16 maettu joined 06:37 seanrobert joined 06:51 dolmen joined 06:55 zacts left 06:56 zacts joined 06:57 sena_kun joined 07:01 dolmen left 07:05 Doc_Holliwould left 07:07 seanrobert left
Geth doc: e62d427ae3 | (Daniel Sockwell)++ (committed using GitHub Web editor) | xt/pws/words.pws
Provide a length hint for aspell (#3594)

Giving aspell a hint about the length of the word-list we provide it allows it to perform very slightly (but measurably) faster. This appears to improve the speed of our spelling test by ~2%. The hint does not need to be perfectly accurate to be helpful, so it won't be a problem if the hint isn't updated as contributors add more words to the aspell word list.
See aspell.net/man-html/Format-of-the-P...ctionaries		 07:13
linkable6 DOC#3594 [closed]: github.com/Raku/doc/pull/3594 Provide a length hint for aspell
07:32 dolmen joined, dolmen left 07:33 dolmen joined, dolmen left 07:39 wamba left 07:40 skids left 07:43 ufobat joined
Geth ecosystem/master: 4 commits pushed by (JJ Merelo)++ 07:45
07:49 pecastro joined 07:53 fooist left 07:58 nebuchadnezzar joined 07:59 maettu left 08:00 cpan-raku joined, cpan-raku left, cpan-raku joined 08:02 natrys joined 08:14 molaf joined 08:37 gabiruh left 08:38 gabiruh joined 08:57 maettu joined 09:04 aluaces left 09:07 Sgeo left 09:12 |Sno| joined 09:14 [Sno] left 09:44 Noisytoot joined 09:50 maettu left 09:53 aluaces joined 09:55 Altai-man joined 09:57 sena_kun left 10:02 Doc_Holliwould joined, Noisytoot left 10:03 wamba joined
kawaii I have a hash which contains many SetHashes, at the start of my program this hash is populated from a Redis database. During runtime users will be adding and removing values from the SetHashes within, and when a new value is added or removed it is committed to Redis. However I understand that the hash I pass into my add/remove subroutines is effectively a copy. I could make those subs `return %badwords` and call them like `%badwords = 10:14
add-word ...` of course but it seems like at scale (1000+ SetHashes containing hundreds of values), it's going to be massively inefficient to update the entire hash in-memory.
github.com/myisha/p6-zoe-badwords/...words.raku
is there an elegant way of partially updating a hash when sending it to a subroutine, can I just do something like `%badwords{$guild-id} = add...` and only update that individual SetHash in the main hash? 10:15
10:23 aluaces left
cpan-raku New module released to CPAN! Pod::Render (0.8.1) by 03MARTIMM 10:36
10:36 pecastro left 10:39 HarmtH left 10:50 Black_Ribbon left, Doc_Holliwould left 11:00 molaf left
lizmat kawaii: you could try subclassing the SetHash and provide your own ASSIGN-KEY method ? 11:30
11:33 pecastro joined 11:40 sno joined 11:43 |Sno| left 11:45 sno left 11:46 ufobat left 11:47 sno joined 11:52 kktt007 joined 12:02 maettu joined 12:08 molaf joined 12:10 mark[m]5 left
rypervenche lizmat: Thanks for the response. I'll keep tinkering with it and see if I can get the functionality I want. 12:20
tbrowder hi, anyone here running a public-facing cro server?
12:21 kktt007 left
tbrowder if so, how do you handle a reboot to start the server? manually, cron, systemd, ...? 12:22
12:24 aluaces joined, kktt007 joined
kawaii tbrowder: I played around with Cro a little, running a web app in Docker 12:26
which basically handles your init etc for you
tbrowder yeah, thnx, but i'm not yet running docker. just raw apache with 10+ virtual hosts 12:28
12:33 wamba left 12:34 wamba joined, AlexDani` left, AlexDani` joined 12:52 kktt007 left 13:22 gnufr33dom joined 13:23 hungrydonkey joined, aborazmeh joined, aborazmeh left, aborazmeh joined 13:25 wamba left 13:50 hungryd23 joined 13:53 hungrydonkey left 13:56 sena_kun joined 13:57 Altai-man left 14:03 hungrydonkey joined 14:06 hungryd23 left 14:15 hungryd96 joined 14:17 hungrydonkey left 14:31 zacts left
codesections m: say '(foo (bar) baz)' ~~ rx:r:s/ '(' .* ')' /; say '(foo (bar) baz)' ~~ rx:r/ '(' <.ws> .* <.ws> ')'/; 14:37
camelia ｢(foo (bar) baz)｣
Nil
codesections Why are the two Regex's ^^^ not the same?
My understanding from the :sigspace docs is that :s is the same as inserting <.ws> in place of every space in the Regex that follows a term. But performing that transformation manually doesn't match 14:39
14:41 aborazmeh left
Geth doc: ea2a5d1fd7 | Coke++ | xt/words.t
allow any number in pws header
 14:42
14:44 thelounge5957 joined
thelounge5957 Hello there 14:44
14:44 thelounge5957 left 14:52 gnufr33dom left 14:58 wamba joined 15:11 natrys left 15:14 Sgeo joined
codesections Here's a simplified version of the Regex issue I asked about earlier: 15:19
m: say '||' ~~ rx:s:r/'|'* '|'/; say '||' ~~ rx:r/'|'* <.ws> '|'/;
camelia ｢||｣
Nil
codesections Why do those two behave differently?
I'm thinking that the :sigspace docs must be wrong/incomplete 15:20
[Coke] "as long as that point is not within a word" 15:22
m: say '||' ~~ rx:s:r/'|'* '|' <.ws>/; 15:24
camelia ｢||｣
[Coke] m: say '||' ~~ rx:s:r/<.ws> '|'* '|' <.ws>/;
camelia ｢||｣
[Coke] m: say '||' ~~ rx:s:r/<.ws> '|'* <.ws> '|' <.ws>/;
camelia ｢||｣
[Coke] m: say '||' ~~ rx:s:r/'|'* <.ws> '|'/;
camelia ｢||｣
[Coke] (oops, the s was still there, not the same as yours)
codesections [Coke]: I _think_ I'm following you, but in that case why does `rx:s:r/'|'* '|'/` match '||'? 15:27
[Coke] Your second rx works if you take off :ratchet.
15:27 wamba left
codesections Shouldn't the space in it be turned into a <.ws>? 15:27
I know turning off ratchet fixes it, but I want to understand this for grammar purposes 15:28
15:28 wamba joined
[Coke] out of my depth, I'm afraid. 15:28
thought I saw an easy fix and then realized I didn't see the adverbs correctly
rypervenche Wouldn't '|'* '|' match '||' and then fail to match the '|' because no backtracking? 15:29
codesections [Coke]: Well, thanks very much for the attempt – it lets me know I'm not missing something super obvious, anyway :) 15:30
m: say '||' ~~ rx:s:r/'|'* '|'/
camelia ｢||｣
codesections rypervenche: I would have thought so, but then why does ^^^^ match?
rypervenche m: say 'ww' ~~ rx:s:r/'w'* 'w'/; 15:38
camelia ｢w｣
codesections odd 15:39
it's almost like :sigspace is making the * quantifier frugal? 15:40
m: say 'ww' ~~ rx:r/w*? <.ws> w/; say 'ww' ~~ rx:r/w* <.ws> w/ 15:42
camelia ｢w｣
Nil
15:42 maettu left 15:53 billN1VUX joined
codesections m: say '||||' ~~ rx:r:s/'|'* '|'/ 15:57
camelia ｢||||｣
codesections Wat? How in the world does **that** match without backtracking?
15:58 skids joined, gabiruh left, gabiruh joined
rypervenche Fails properly without the :s, hmmm. 15:59
16:00 Doc_Holliwould joined 16:04 zacts joined 16:09 JJMerelo joined
JJMerelo Hi 16:10
codesections Hmm, this seems to be related to longest-token-matching (*everything* that ends up giving me trouble with Raku's grammars has to do with not fully getting LTM…)
o/
16:10 aluaces left
guifa Actually, it has more to do with the definition of ws I think 16:10
codesections say '||||||||' ~~ rx:r:s/'|'*{} '|'/; say '||||||||' ~~ rx:r:s/'|'* {}'|'/; 16:11
evalable6 Nil
｢||||||||｣
guifa I think one of the issues is hat one would think ws = /\s*/, but … that’s not the case
ws = / <!ww> \s* /
codesections yeah, I saw that in the docs 16:12
JJMerelo Anyone around who's _not_ filled the Raku 2020 survey? Do it now! docs.google.com/forms/d/e/1FAIpQLS...Q/viewform
guifa codesections: note the difference:
m: say '||||||' ~~  rx:s:r/'|'* '|'/;
camelia ｢||||||｣
guifa m: say 'aaaaaa' ~~  rx:s:r/'a'* 'a'/; 16:13
camelia ｢a｣
codesections m: say '|||||' ~~ rx:r/'|'<.ws>'|'/ 16:14
camelia ｢||｣
codesections m: say '|||||' ~~ rx:r/'|'*<.ws>'|'/
camelia Nil
codesections guifa: I see the difference you're pointing at, but I don't understand how it gets the results with '|' 16:15
why isn't a space with :sigspace on getting the same results as a <.ws> without sigspace?
[Coke] m: say 'xxxxx' ~~ rx:r/'x'*<.ws>'x'/ 16:16
camelia Nil
guifa possibly there’s an optimizer going awry
Normally one could assume that x* x === x*
err 16:17
x* x === x+
16:18 wamba left 16:20 wamba joined
guifa Hrm, whoa. 16:22
codesections m: say '|||' ~~ rx:r:s/'|'* ./; say '|||' ~~ rx:r/'|'*<.ws>./ 16:23
camelia ｢|||｣
Nil
codesections ^^^ that doesn't really look like an optimizer issue -- you can't optimize x* . into x+ 16:24
guifa How’s this for weird 16:25
m: say '||||' ~~ m:s:r/'|'*{say "pos: ", $/.pos, " ($¢)"} '|'{say ~$¢}/;
camelia pos: 4 (||||)
pos: 4 (|||)
pos: 4 (||)
pos: 4 (|)
pos: 4 ()
False
guifa m: say '||||||' ~~ m:s:r/'|'* {say "pos: ", $/.pos, " ($¢)"}'|'{say ~$¢}/;
camelia pos: 6 (||||||)
pos: 5 (|||||)
||||||
｢||||||｣
guifa In fact, it can be golfed to 16:26
m: say '||||||' ~~ m:s:r/'|'*{} '|'/; say '||||||' ~~ m:s:r/'|'* {}'|'/;
camelia False
｢||||||｣
codesections m: say '||||' ~~ m:s:r/'|'*{} '|' 16:27
camelia 5===SORRY!5===
Regex not terminated.
at <tmp>:1
------> 3say '||||' ~~ m:s:r/'|'*{} '|'7⏏5<EOL>
Couldn't find terminator / (corresponding / was at line 1)
at <tmp>:1
------> 3say '||||' ~~ m:s:r/'|'*{} '|'7⏏5<EOL>
exp…
codesections yeah, you got there before me
But yeah, that's what I was saying right when you came in :D
And why I thought it was a LTM issu
e
(You got there a *lot* faster than I did, though!) 16:28
guifa When I get weird stuff, I like to use { say $¢ }, it can clear up stuff normally very fast
codesections (Your last camillaa expression is very nearly the one I posted right before you first said anything, by the way :D) 16:29
guifa Oh wow, yeah, I did totally miss that 16:31
guifa only just now had coffee
16:31 MasterDuke joined
rypervenche I'm curious, why are you using m/ instead of rx/? Wouldn't m/ match against $_ ? 16:32
JJMerelo rypervenche no, // matches against $_ 16:35
m// matches the other term. rx is a way of defining Regexes and delaying matching. 16:36
rypervenche Is the documentation wrong then? Or am I reading it wrong?
「The match operator m/ / immediately matches the topic variable $_ against the regex following the m.」 16:37
guifa In smart matching, they’re synonymous
And…. perl force of habit :-)
JJMerelo rypervenche then it's me who's wrong... 16:38
JJMerelo ducks and covers
16:39 eery left
JJMerelo rx _does_ define a Regex, anyway. 16:39
rypervenche I see, so with a smartmatch it doesn't really matter which you use.
That feels a little inconsistent though. 16:40
JJMerelo smartmatch aliases to $_, so I guess not.
16:43 eery joined
codesections guifa: returning to your use of ¢, above, what do you make of this: m: say '|||' ~~ rx:r:s: /'|'* {say $¢}'|'/ 16:53
m: say '|||' ~~ rx:r:s: /'|'* {say $¢}'|'/
camelia 5===SORRY!5=== Error while compiling <tmp>
Colons may not be used to delimit quoting constructs
at <tmp>:1
------> 3say '|||' ~~ rx:r:s:7⏏5 /'|'* {say $¢}'|'/
expecting any of:
colon pair (restricted)
codesections m: say '|||' ~~ rx:r:s /'|'* {say $¢}'|'/ 16:54
camelia ｢|||｣
｢||｣
｢|||｣
codesections That sure looks like backtracking
Or, this might be an even clearer case: 17:00
17:00 raku-bridge1 joined, raku-bridge1 left, raku-bridge1 joined
codesections m: say '&&&&&' ~~ rx:r:s /.* {say ".* matched: $¢"}'&&&&'/ 17:01
camelia .* matched: &&&&&
.* matched: &&&&
.* matched: &&&
.* matched: &&
.* matched: &
｢&&&&&｣
17:01 Sgeo_ joined 17:02 dogbert17 joined 17:03 raku-bridge left, zacts left
Geth ¦ problem-solving: fecundf assigned to jnthn Issue Extended identifiers-why and where, exactly? github.com/Raku/problem-solving/issues/224 17:03
17:03 raku-bridge1 is now known as raku-bridge 17:04 veesh left, Sgeo left, veesh joined, dogbert11 left, erdic left 17:05 erdic joined 17:07 JJMerelo left 17:10 wamba left 17:11 wamba joined 17:27 Doc_Holliwould left
Geth doc: coke self-assigned aspell shouldn't handle affixes, should it? github.com/Raku/doc/issues/3593
45b66a1cd4 | Coke++ | 2 files

found using util/clean-spell		 17:28
17:53 Noisytoot joined 17:55 Altai-man joined 17:56 hungrydonkey joined 17:57 sena_kun left 17:59 hungryd96 left 18:02 wamba left 18:03 wamba joined 18:12 andinus left 18:13 andinus joined 18:22 Doc_Holliwould joined 18:23 bocaneri left 18:32 Noisytoot left
18:45 yuplushi left 18:51 andinus left 18:54 wamba left 18:55 wamba joined
Geth doc: 318a806209 | Coke++ | 2 files
Remove false possessive.

Caught during review of #3593		 19:00
linkable6 DOC#3593 [closed]: github.com/Raku/doc/issues/3593 [xt] aspell shouldn't handle affixes, should it?
19:43 Benett joined 19:45 wamba left 19:46 wamba joined 19:47 wamba left 19:55 approaching236 joined 19:56 approaching236 left, approaching236 joined, hungrydonkey left 19:57 approaching236 left, hungrydonkey joined, approaching236 joined 20:00 approaching236 left 20:02 approaching236 joined 20:04 approaching236 left 20:05 approaching236 joined 20:07 Tirifto joined, approaching236 left, approaching236 joined
Geth doc: codesections++ created pull request #3596:
Normalize files to end with newline		 20:08
20:09 vgrato_ joined 20:10 vgrato_ left, approaching236 left, approaching236 joined 20:14 rindolf left
Geth ecosystem: 22b973d39f | (Ramiro Encinas)++ (committed using GitHub Web editor) | META.list
Add Win32-DrivesAndTypes to ecosystem

See github.com/ramiroencinas/Win32-DrivesAndTypes		 20:16
20:16 juniper_ joined
Geth doc: c4a6a4c577 | (Daniel Sockwell)++ | 20 files
Normalize files to end with newline

This commit normalizes all files in /doc to end with a newline (in conformity with POSIX standards). This isn't a big deal, but will allow processing files with automated tooling without generating misleading diffs in the future.		 20:25
doc: 44eee8b5c5 | (Daniel Sockwell)++ (committed using GitHub Web editor) | 20 files
Merge pull request #3596 from codesections-forks/newline

Normalize files to end with newline
20:37 wamba joined 20:40 approaching236 left
Geth doc: coke self-assigned xt/examples-compilation.t doc/Type/Signature.pod6 failing github.com/Raku/doc/issues/3455
9ac9008dfa | Coke++ | xt/final-newline.t

Inspired by #3596		 20:43
20:56 MilkmanDan left 20:57 wildtrees joined 20:59 juniper_ left
linkable6 DOC#3596 [closed]: github.com/Raku/doc/pull/3596 Normalize files to end with newline
codesections :[Coke] did you see my comment on your x/aspell commit about it causing my xtests to fail? (I can't remember if github sends notfications for comments on commits rather than PRs) 21:08
er, [Coke]: ^^
21:08 MilkmanDan joined 21:09 cpan-raku left 21:10 MasterDuke left, cpan-raku joined, cpan-raku left, cpan-raku joined
[Coke] no, comments on commits go into an email hole and I see them much later. 21:12
one sec.
21:16 hungrydonkey left 21:21 MasterDuke joined 21:25 yuplushi joined 21:28 wamba left
[Coke] codesections: please open a ticket so we can track the issue. I am getting no failures here, I assume it's a difference of aspell version or base dictionary 21:47
codesections Will do. Thanks for checking it :)
21:47 wildtrees left 21:48 approaching236 joined 21:50 approaching236 left
[Coke] out of curiosity, what version of aspell are you using? 21:52
@(#) International Ispell Version 3.1.20 (but really Aspell 0.60.8) here 21:53
codesections same
[Coke] It's also possible I'm being hit by pod::cache failures again
codesections but wouldn't it depend on the version/providence of the dictionary more than the aspell version? 21:54
[Coke] aspell-dict-en @2019.10.06_0 (active)
21:55 MasterDuke left
[Coke] codesections: gist.github.com/coke/84afef19fe451...d6892a7657 21:55
21:56 sena_kun joined
[Coke] bugs me that those aren't versioned. :| 21:56
21:57 Altai-man left
codesections [Coke]: I get the same output from `dump dicts` How do you get that aspell-dict-en version string? 21:58
[Coke] it's showing the version that macports installed
codesections: can you tell me one of the files that is failing? 21:59
(as opposed to a word)
codesections sure
[Coke] I'll be very disappointed I have I to revert that, it took over a day to run it in chunks. :|
*if
codesections First failure I got was README.md (code) 22:00
for 'runtime'
[Coke] that's not even hitting pod-cache. 22:01
yup, so it's got to be something aspell related.
aspell dump config | grep -v '^#' | grep -v '^$' # empty here. 22:02
how are you running the test? 22:04
I just tried ```xt/aspell.t README.md``` no errors, and running ```xt/aspell.t``` also no errors
```prove -v -e raku xt/aspell.t``` (to get nice prove output) 22:05
codesections how about `aspell dump master | grep 'runtime'` ?
(I get no output from that grep, which fits with 'runtime' not being in any of my dictionaries) 22:07
22:08 fooist joined
[Coke] aha. 22:18
so where *is* that master file? It's not under ~/.*spell* or *dict* 22:19
codesections aspell dump config data-dir 22:20
I think, but that shows some binary files? Are they compressed?
[Coke] that shows /opt/local/lib/aspell-0.60 which is where macports installed the en_us library. 22:21
codesections does en_us have 'runtime' in it? 22:22
:D
[Coke] I have "en.dat"
"grep runtime *" shows nothing in that dir, assuming it's in one of the compressed files. 22:23
are you maybe not using the en_us dictionary? 22:24
codesections and you don't have a personal dictionary by any chance? `aspell dump personal`
[Coke] "can not be opened for reading." 22:25
(i.e. no such file) 22:26
codesections yeah, same. Odd
[Coke] I am leaning towards you're not configured to use that dictionary. 22:27
how did you install aspell? package manager?
codesections `aspell dump config lang` gets en_US
yeah. Or, I think it may have been part of the base installation 22:28
let me check on other computers
22:29 vrurg left 22:33 seanrobert joined
codesections Ok, just checked on my laptop running Void Linux with a clean install of aspell and the en_US dictionary ... interesting 22:35
I get just one failure ('Falses' in Junction.pod6) 22:36
It seems like different systems just have different word lists?
23:06 wamba joined 23:11 dataangel joined 23:21 seanrobert left, seanrobert joined 23:32 seanrobert left 23:33 seanrobert joined 23:37 vrurg joined, seanrobert left 23:40 riasue left 23:41 tobias_ joined, zxcvz left 23:55 defaultxr joined 23:57 sena_kun left 23:58 leont left, pecastro left

Powered by Cro and the Raku® Programming Language.

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

Thank you!