🦋 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.
01:43 MasterDuke joined 01:51 hulk joined 01:52 kylese left 02:15 hulk left, kylese joined 03:41 jpn joined 03:45 jpn left 04:51 beanbrain joined 05:30 Sgeo left 05:36 jpn joined 05:40 jpn left 06:06 cm left 06:07 cm joined 06:23 cm left 07:04 sena_kun joined 07:36 wayland76 joined 07:58 jpn joined 08:01 oodani left 08:02 oodani joined 08:18 sena_kun left 08:20 sena_kun joined 08:21 cm joined
librasteve o/ 09:29
saw some comments on community modules ... personally I think that "domain specific" modules such as Statistics::LinearRegression should not be adopted as community modules and rather, if the original author is unresponsive, then if the licence permits anyone is free to fork, change auth and bump the version in the expectation that they would follow the usual practices of semantic versioning and deprecation and 09:32
so on eg. if they want to change the API
that keeps the community's efforts, as far as community modules goes, focused on providing a path forward for general and common modules such as Text::Wrap which have been abandoned ... and here we all should feel empowered to submit and (with permission and due process) merge PRs to keep these modules from breaking 09:36
09:52 thowe left 09:53 thowe joined 09:59 jpn left 10:08 jpn joined 10:46 avuserow_ left 10:47 avuserow_ joined
antononcube I agree that “Statistics::LinearRegression” is somewhat specialized. But it is: 1) simple, 2) fundamental for doing statistics, and 3) its code — or very similar — can be reliably generated with LLMs. 11:41
“Fundamental for doing statistics” means that if one, say, does benchmarking of routine performance having linear regression can be really handy. 11:43
Now, I do not mind forking and making that package better. (With higher API version.) As I mentioned, I would rather have “Math::Fitting” which includes the functionalities of “Statistics::LinearRegression” package. 11:45
[Coke] tbrowder: I don't see how having him publish a version that you are immediately going to obsolete helps. 11:51
My take on community owned is similar. I don't think community means "every abandoned module that one person wants to use." 11:52
I also didn't think taking over graphql was the plan, I thought you were talking about one of the Text::Wraps. 11:53
12:00 thaewrapt left 12:23 jpn left
antononcube @Coke and @librasteve I was not aware of the community modules re-adopting rules or principles. I do agree that not every abandoned module should be made a community one. 12:29
[Coke] I am not sure there is a documented plan. I think tbrowder would now better 12:32
antononcube In case this statement "every abandoned module that one person wants to use." is related to my ask about "Statistics::LinearRegression" to be a community module. If I am the only one who wants to use that module in the Raku community that is really telling about the community and the ecosystem. (Honestly, no judgment here beyond that "tell.") 12:37
12:38 xinming left
I also would like to mention that many people in Data Science would not look at Raku twice if Raku does not have at least good linear model fitting routines. (Meaning, it does not matter how much Steve and I claim or prove that Raku is good for exploratory data analysis. 12:38
12:40 xinming joined
[Coke] I think we want to support both "common" modules and "strategic" ones, but whether that support is directly under the RCM umbrella or not could be discussed - but I'd hope strategic distros already had an evangelist/contributor, yes. 12:57
holmdunc The Emacs Orphanage github org has a more fitting name for that kind of repo transfer. github.com/emacsorphanage 13:11
tbrowder hm, maybe antononcube could start another repo for ppl interested in his specialty and could give appropriate creds to other interested raku ppl. 13:14
i see that kind of grp all over github
antononcube @Coke "Strategic" is a good characterization. I was thinking that a recent addition, "Algorithm::Diff" is kind of "fundamental" in the minds of many. "Strategic" fits better that module.
@tbrowder Already done. 🙂 (With MVP-0.) : github.com/antononcube/Raku-Math-Fitting 13:15
13:16 thaewrapt joined
tbrowder no, i mean top level: github.com/raku-math-fitting 13:17
13:17 jpn joined
tbrowder ^^^ 13:17
github/Raku-Math-Fitting 13:18
librasteve tbh I don't think that community modules get a lot of love except when something is broken --- imo better to have "core skilled" devs working on core ;-)
antononcube I.e. no community love for orphans... (Sigh...) 13:24
tbrowder well, at least the comm modules are there to be adopted, or at least someone can get a PR looked at. 13:25
[Coke] Right, we don't want core devs doing work on modules, but I think we have a bunch of core-adjacent folks who could. (myself included). I don't have them on my priority list, though. Be nice if we had someone to keep an eye on community modules and ping folks here when dev cycles are needed to fix something 13:27
I volunteer tbrowder. :)
antononcube @Coke I support your right to volunteer others. 13:31
tbrowder well, i hope my upcoming linter can help. i plan to use it on comm modules and at least submit issues for a start. 13:32
13:47 MasterDuke left 14:04 Sgeo joined
[Coke] in github, I have github.com/issues - How can I say "show me all tickets in repositories owned by Raku or raku-community-modules ? 14:11
org! 14:12
here we go: github.com/issues?q=is%3Aopen+is%3...ty-modules 14:13
We should have a common set of labels for tickets to make it easier for devs to prioritize 14:14
(and colors for those labels) 14:15
librasteve nice! this is a great set of introductory issues 14:32
14:35 sena_kun left 14:40 sena_kun joined
Geth ¦ problem-solving: coke self-assigned The raku-community-modules organization and its problems. github.com/Raku/problem-solving/issues/210 14:51
15:00 sena_kun left, sena_kun joined
antononcube @Coke Great! (About community modules issues list.) 15:08
(My favority communitu module issue is on top. For now.)
ingy I have a problem with a language I'm writing (ys) where I can run a program with either `ys foo` or `./foo` if foo is +x and has a shebang line... 15:10
I have a problem where foo wants to print help when it gets `-h`, but ys is getting the -h and printing its help instead. 15:12
`./foo -- -h` works but wondering WWRD?
15:15 thaewrapt left 15:17 thaewrapt joined
ingy interesting the behavior of `raku foo -h` and `raku -h foo` 15:19
#!/usr/bin/env raku
say @*ARGS;
evalable6 []
librasteve ingy: are you using raku sub MAIN()? maybe you can share a gist with a code example? 15:48
tonyo raku is picky about the arg placement ingy
librasteve oh, yes I forgot you need the -h before the foo I guess like ys -h foo 15:49
ugexe probably needs `my %*SUB-MAIN-OPTS ; :named-anywhere` 15:52
my %*SUB-MAIN-OPTS = :named-anywhere;
librasteve .oO
ugexe docs.raku.org/syntax/%25%2ASUB-MAIN-OPTS
ingy I'm not implementing in raku. raku is just a language made my people I can what with :) 16:03
ugexe ah 16:06
_grenzo So, I guess ys is being passed a list of arguments starting with "foo" and followed by "-h"? 16:07
ugexe raku actually used to have a similar problem for all installed scripts :)
github.com/rakudo/rakudo/commit/73...9628617885
i don't think that fix is what you'd want to do tho :P 16:08
holmdunc so foo is a filesystem path, and the program ys basically needs to decide that it doesn't accept flags after its positional argument? 16:13
16:26 sena_kun left 16:27 sena_kun joined 16:32 jpn left 16:36 jpn joined 17:04 melezhik joined
melezhik o/ 17:04
17:05 soverysour joined 17:09 melezhik left 17:15 soverysour left, soverysour joined, soverysour left, soverysour joined
ingy ugexe: I think I need to special case when the first arg looks like a file path, and then pass the following args unparsed to it 18:09
18:10 soverysour left
ingy holmdunc: pretty much what you said 18:10
I currently use an options parser right away
but (imho) raku should gripe on `raku -h foo` 18:11
checking something 18:12
18:15 Altai-man joined 18:18 sena_kun left 18:35 jpn left
_grenzo @ingy: is it possible you'd do something like ys -I ../lib foo.ys -h 18:50
? 18:51
19:42 beanbrain left
ingy _grenzo: yeah good point… 19:50
I just added check if the first arg does not start with `-` but that's not perfect 19:51
looking at my current opts 19:52
gist.github.com/ingydotnet/92574ed...44f271f367 19:54
I don't have -I *yet* (just YSPATH env var) 19:56
maybe at the point I either require `ys -I ../lib foo.ys -- -h` or `ys -I ../lib --run foo.ys -h` 19:57
the former would work now
and I just realized that `-` is a valid file name for stdin... 19:59
so far the arg parsing library is great (except for today's bug) so I'd like to hold onto it 20:00
_grenzo @ingy is ys taking yaml and generating code from it (perl, raku, python, rust...)? 20:01
20:01 beanbrain joined, beanbrain left, beanbrain joined
ingy no, it's only generating clojure code and then evaluating it (but no jvm, all binary) 20:02
_grenzo oh, wait, no I see
ingy the language bindings (raku etc) pass ys to libys and get back json of compile/evaluation and decode to native 20:03
_grenzo It loads and parses yaml with bindings to those languages?
you're seconds ahead of me 🙂 20:04
ingy it's likely the best raku yaml loader
but has no dumper
but you can also add logic to yaml files, including pulling in other files etc 20:05
if the yaml/ys file starts with !yamlscript/v0
if not, then just loaded like any other yaml 20:06
_grenzo hmm manipulating docker-compose files and openAPI definitions
does it work both ways?
ingy ?
_grenzo loading and outputting
ingy I don't follow 20:07
the results of a load are same scope as json
_grenzo You can take yaml and turn it into json and transform that into perl/raku datastructures. Is it as easy to take json and turn it into yaml? 20:08
ingy $ echo '["foo", 42]' | ys -Y - 20:09
- foo
- 42
20:09 beanbrain left
ingy pandon my paste 20:09
_grenzo no problem. I should just probably read the whole readme file 20:10
ingy I mean that's because all json is valid yaml
the ys CLI used as a loader, outputs json or yaml (or edn) but using it from raku is only gonna turn json, yaml or ys files into whatever the raku json module would return 20:12
TPRC talks on YS (including for raku) in 12 days... 20:13
20:38 sena_kun joined 20:40 Altai-man left
antononcube I am not sure is the "Math::Matrix" package abandoned or not. But its functionalities are fundamental in so many ways. I consider forking it just to make sure it can be built on different architectures, passes correctness tests, and has some "low hanging fruit" features implemented. (E.g. QR decomposition, system of linear equations solving, inversion, etc.) 20:45
I do not want my brand new "Math::Fitting" to depend on such an old package!! 20:46
ingy Maybe dep on it until you get burned and not helped by the author? 20:49
antononcube Hmm... "Chemistry::Stoichiometry" depends on "Math::Matrix" -- I think I had only minor propblems with easy work-around. 20:50
ingy I've been spending time in the clojure community for past year, and old libraries are not worried about. They seem to take library API back compat as seriously as they (or perl) takes language back compat. 20:51
It feels weird for me to trust that mindset though. 20:52
antononcube That reminds me -- "Chemistry::Elements" is definitely abandoned, and "Chemistry::Stoichiometry" completely replaces it functionality-wise. Many / all of the GitHub issues of the former are implemented in the latter. 20:53
ingy I forget, does raku permit/encourage use of same named modules by different authors? 20:54
antononcube Yes -- I think different author is fine, forking and re-authoring is fine, making a new API version is fine. 20:55
ingy nice 20:56
antononcube For me, to trust many of the math-packages in Raku would be much easier after I streamline the verification of their tests with Mathematica. (Something, I have started, but I have to finish.)
I strongly suspect defining Gherkin tests and using LLMs might provide great transparency and speed-up of that kind of work. 20:58
As for Clojure -- because of Mathematica I have been asked to look into Clojure. 20:59
More precisely, because of questions and discussions at Mathematica forums and conferences. 21:00
But I know 'too many" LISP descendents, so, I decided to skip Clojure. 21:01
21:02 wayland joined, wayland76 left 21:05 BooK joined 21:09 sftp left, sftp joined 22:28 beanbrain joined 22:35 sena_kun left 23:40 teatwo left, teatwo joined 23:59 beanbrain 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!