🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
00:03 reportable6 left 00:04 reportable6 joined 01:04 sourceable6 left, committable6 left, shareable6 left, reportable6 left, statisfiable6 left, greppable6 left, bloatable6 left, unicodable6 left, squashable6 left, benchable6 left, releasable6 left, notable6 left, linkable6 left, tellable6 left, evalable6 left, coverable6 left, bisectable6 left, quotable6 left, nativecallable6 left 01:05 shareable6 joined, unicodable6 joined, committable6 joined 01:06 linkable6 joined, releasable6 joined 01:07 bisectable6 joined, quotable6 joined, statisfiable6 joined 02:05 evalable6 joined 02:06 sourceable6 joined, notable6 joined 02:58 xinming left 02:59 xinming joined 03:05 bloatable6 joined 03:06 nativecallable6 joined, reportable6 joined 03:07 benchable6 joined, xinming left 03:08 xinming joined 03:28 swaggboi left 03:33 swaggboi joined 03:47 squashable6 joined 03:51 Sgeo_ joined 03:54 Sgeo left 04:07 greppable6 joined 04:13 keutoi joined, xinming left, xinming joined 04:34 xinming left, xinming joined 05:06 tellable6 joined 06:02 reportable6 left, reportable6 joined 06:03 xinming left 06:04 xinming joined 06:43 jjido joined 07:06 coverable6 joined 07:40 eseyman left 08:00 lichtkind joined 08:31 eseyman joined 08:44 eseyman left 08:49 Sgeo_ left 08:53 b2gills left 09:27 jjido left
spacekookie So I'm looking at RAKULIB as a search path and I'm wondering if there's a way to make rakudo look for module more recursively. i.e. I point it at something like lib/perl6/site_perl (similarly to perl5) in which are then different raku distributions 09:52
Not 100% sure how this is supposed to work from the raku modules docs 09:53
Or should I just set RAKULIB manually to include all paths to modules that a package requires? 09:56
10:02 keutoi left 10:04 keutoi joined 10:40 jjido joined
lizmat spacekookie: feels like you want to create your own REPO logic? 10:46
spacekookie Is a REPO in Raku something special? 10:48
gfldex m: say $*REPO; 10:49
camelia inst#/home/camelia/.raku
lizmat when you want to load a module in Raku, it's basically asking whatever is in $*REPO if it knows about a given module
if it does, then you'll be able to load it
10:50 jjido left
lizmat through the $*REPO logic 10:50
in fact $*REPO is a chain of repo's
if the first doesn't know about it, it can ask the second, etc.
Raku comes standard with the "Installed modules" repo
and the "filesystem modules" repo 10:51
(and a few other ones, but that's not important right now)
the "installed modules" only knows about modules that you have installed with e.g. "zef install Foo::Bar"
the "filesystem" one only knows about modules as files in a directory 10:52
(which is much like Perl treats modules)
when you say "use lib 'foo/bar'"
you are in fact inserting a REPO at the front of the chain, that will look for modules in the "foo/bar" directory 10:53
spacekookie: are you still with me?
spacekookie Yea, that makes sense 10:54
The background to what I'm trying to build is that on NixOS there's no such thing as an "installed module". Each program has access to the modules it needs, but they are install at some path in /nix/store 10:55
So for any given program we wrap it in a script that sets RAKULIB to a path on where to find its dependencies 10:56
lizmat and "use lib" is not cutting it for you?
spacekookie But thinking about this for a bit longer, actually it makes total sense to have RAKULIB be a comma separated path for each of the dependencies
"use lib" has to look for the module somewhere though, right? Which is determined by the search path?
Or is it the filesystem one?
lizmat use lib is the filesystem one 10:57
spacekookie Ah
lizmat it has the disadvantage that it does **NOT** know about versions
spacekookie That works fine for includes _inside_ a module but to bundle an program together it's a bit inconvenient
lizmat so if you do "use foo:auth<lizmat>:ver<0.0.2>" and the use lib repo finds a "foo.rakumod", it will use that *without* checking version or auth matching 10:58
spacekookie Interesting 11:00
Anyway, I think I have a decent solution for this now (if you're interested: dev.spacekookie.de/kookie/nomicon/...lt.nix#L17 -- currently in my own fork, but it'll be upstreamed soon(tm))
lizmat ugexe tonyo El_Che might be better suited to judge that 11:02
they're more into packaging / module installations than I am
spacekookie So the general structure of a raku package is then $out/{bin,/lib/perl6/site_perl} with the latter containing the code shipped by the module. And the RAKULIB path is a set of $out/lib/perl6/site_perl and links to every other dependency that's required (and packaged at their own /nix/store/whatever/ paths
Well, thanks for your help anyway :)
lizmat yw
spacekookie fwiw it's also the first build support system I try to build for nixpkgs x) 11:03
lizmat ah, an opportunity for double learning :-) 11:06
11:50 evalable6 left, linkable6 left 11:57 keutoi left 12:02 jjido joined, reportable6 left
ugexe use lib will know about versions if it points to a repo that knows about versions 12:26
something like `use lib "lib"` might not similarly to `-I lib`, but thats why people should be using `use lib "."` or `-I .` (i.e. pointing at the base directory of the distribution where the META6.json resides, not its lib/ subdir) 12:28
lizmat spacekookie ^^ 12:29
ugexe++ # reminding me about META6.json being used if found by use "lib" 12:30
ugexe i wrote github.com/ugexe/Perl6-CompUnit--R...itory--Lib years ago to do a recursive lib/ type structure like github.com/ugexe/Perl6-CompUnit--R.../test-libs 12:34
but thats a prototype
12:50 linkable6 joined 12:52 evalable6 joined 13:52 bloatable6 left, linkable6 left, evalable6 left, quotable6 left, sourceable6 left, statisfiable6 left, squashable6 left, shareable6 left, releasable6 left, nativecallable6 left, committable6 left, greppable6 left, benchable6 left, tellable6 left 13:53 committable6 joined 13:54 shareable6 joined, releasable6 joined 13:55 quotable6 joined, benchable6 joined 14:03 reportable6 joined 14:12 monkey_ joined 14:19 dg left 14:35 squashable6 joined 14:50 jjido left 14:53 nativecallable6 joined, greppable6 joined, tellable6 joined 15:18 sftp left 15:28 TheAthlete joined
spacekookie Hmm, why are there two separate keys in the p6c.json to get the repository url (support.source and source-url)? Are there semantic differences between them? 15:34
15:36 jess left 15:38 sftp joined
moritz_ I think one is new style, one is old style, and we never finished the transition, or something 15:43
spacekookie Okay so I guess I'll start sending out some PRs x) 15:45
15:53 sourceable6 joined 15:55 evalable6 joined
raydiak I'm not entirely sure that one is meant to be deprecated. META6, which we link to from the docs on META files, uses both. zef uses only support.source in its META6.json but happily works with either one afaik. fez uses only source-url in it's META, not sure what it looks at when running. our docs have no mention of "support". S22 has no mention of "source-url". 16:07
since we have no spec for meta files and don't consider either the docs or syns or anything else authoratative, it's just "whatever the prevailing tooling wants" 16:08
16:12 monkey_ left
ugexe source-url is more something defined by ecosystems. id say support.source is for humans to enter and source-url is more something that should be generated (even though that isnt the case for p6c) 16:12
if zef was uploaded to cpan then its source-url would be a url to its cpan .tar.gz regardless of what its value was when it was uploaded, but the support.source would still point to whatever its value was (in this case the git repository) 16:17
16:24 monkey_ joined
spacekookie Hmm, okay. Is there a reason to actually have this be two fields? i.e. why not just use the "human" value for everything? 16:37
16:38 a3r0 left
ugexe who says you know what the value is before uploading? 16:46
something like our cpan usage is going to overwrite source-url with the appropriate .tar.gz url which is generated. if we only use one of these values then there is no longer an linkage to the source 16:47
spacekookie Hm, fair enough. I guess some modules are also just hosted on modules.raku.org and don't have a repo of their own somewhere? 16:48
16:54 bloatable6 joined, statisfiable6 joined
ugexe they dont have to have a repo, no 16:59
17:02 RandalSchwartz joined, RandalSchwartz left 17:15 monkey_ left 17:53 jjido joined 18:02 reportable6 left 18:03 reportable6 joined 18:12 Sgeo joined 18:55 linkable6 joined 18:58 discord-raku-bot left, discord-raku-bot joined 19:00 TheAthlete left 19:49 pounce left 19:56 pounce joined 20:13 pounce left 20:17 pounce joined 20:30 squashable6 left 20:35 jjido left 20:42 neshpion joined 20:51 jjido joined 20:55 jjido left 21:04 squashable6 joined 21:17 Altai-man left 21:18 Altai-man joined 21:38 neshpion left
japhb xinming: Missed your discussion yesterday, but not that the CBOR format is designed to be extensible for exactly things like Captures that you want to be able to roundtrip and can be described semantically, but may only be "native" in some languages. CBOR::Simple (which I wrote) supports this conceptually, but I have not yet added Capture as an explicit extension. 21:42
xinming: Anything I should know about your use case that would imply something more advanced than "2-tuple of positional and associative tagged to roundtrip as a Capture object"? 21:43
*but note that 21:44
(I suspect that a similar concept is needed by Lua for tables, but I'm not a Lua expert)
Oh, I should also note that CBOR::Simple is *way* faster than .raku/EVAL for any data structure it supports. 21:46
(see github.com/japhb/serializer-perf for more details)
raydiak Lua tables don't really distinguish between named and positional, it's all just a key lookup and positional is syntactic sugar. like our object hash, keys can be numbers or strings or whatever. as far as Lua functions go, there's no named params, you pass a table if you want to do that (at least in 5.1, when I learned it...don't think that's changed though) 22:49
not very relevant, just FYI :) 22:50
though now that I think about it like that...does CBOR::Simple support object hashes? you could theoretically just stuff the positional params into Int keys and the named into Str keys all in one hash. might be more compact. not sure about performance 22:55
or maybe not more compact since you'd have to store the type of each key. idk, was just a thought 23:01
23:53 linkable6 left, evalable6 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!