🦋 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.
japhb stevied: github.com/Raku/REA ? 00:05
(And why do you want to *fork* them all?) 00:06
stevied ok, cool. I can probably extract the github urls from this fairly easily 00:55
Nemokosch is cloning them not enough? 😅
stevied I was thinking about updating the legacy filename extensions on the modules that need it. 00:56
and that got me to wondering if there might be an easy way to do that.
comma ide has a way to easily update the legacy filename extensions 00:57
but then it would be a pain to open each module individually in comma. so I'm wondering if a script might already exist for the the job. 00:58
Nemokosch I absolutely love this idea, lol. Even opened an issue concerning this ambivalent status quo 01:01
stevied ambivalent status quo? what do you mean? that people don't seem motivated to update the file extensions? 01:02
Nemokosch that's a fair way to put it 01:04
And I think this is really a marketing/management kind of choice
stevied I just did a pull request for one module: github.com/jonathanstowe/XDG-BaseD...tory/pulls 01:05
Nemokosch The extension could be .foobar for all I care
or .deadperl - okay, maybe not, marketing/management again
stevied not very hard to do with comma but would be very tedious to do them all with comma
Nemokosch my point is that I don't mind the old extensions - but if we do the change, let's be serious about it 01:06
it has been like 3 years
guifa I basically update stuff as I come across it in my modules
like if I push an update to Old::Module today and it's still using .pm6 I make a change
stevied it's a tedious job to do by hand. I gotta imagine someone wrote a script for it. maybe it's just a matter of publicizing it
Nemokosch guifa: let me ask you about the ecosystem/module/distribution "polemy" 01:08
it only occured to me in the last couple of days that the unit of dependencies is a module and not a distribution 01:09
I can't say it sounds like a good idea to me still but that's besides the point...
how do you go about naming your... well, distributions?
the point being that ultimately the name of the distribution is more or less a fun fact, compared to the provides section in the META6 file 01:10
guifa I just name it the same as what the primary module would be (e.g. what I'd expect 90+% of people to want to interface with) 01:12
In one case (Intl::LanguageTag) that actually literally just parrots out symbols from Intl::LanguageTag::BCP47 which is just one of several (but it's the most logical default for numerous reasons), but power users can import stuff with longer package names as needed 01:13
Nemokosch Oh, that's interesting from a technical point of view as well 01:14
github.com/alabamenhu/LanguageTag/...ag.rakumod gotcha 01:16
back to "the topic" - my worry is that I'm not the only one who has treated distribution names as the unit of dependency, and now that I know they are, I feel somewhat cheated by the gazillion of distributions that have module name-looking names 01:19
stevied just stumbled on this list: github.com/Raku/ecosystem/blob/main/META.list 01:24
Nemokosch not to say that I'm the best person to hold you a history lesson but you might want one 😄 01:25
Raku/ecosystem IS basically the so-called p6c ecosystem. It is being turned off, by the way.
You can see many commits like "moving XY to zef", "lives on zef now" and the likes 01:26
guifa Although I guess to be fair it's fairly similar with other languages. The difference being Raku doesn't need the use foo::bar::* syntax or whatever, because you can use foo::bar and the module author will mostly likely have it do whatever makes most sense 02:24
leont doesn't making «use Foo::bar» make sense typically means stuffing absolutely everything in one file 02:46
s/doesn't/& like how/
jaguart though I see distributions where there is nothing in that file except a place-holder class, e.g. github.com/tony-o/raku-fez/blob/ma...ez.rakumod 04:13
SmokeMachine Red, for example, if you use it, you will probably just need to `use Red` and it will import a lot of things from many different files… (github.com/FCO/Red/blob/master/lib/Red.pm6) 04:35
stevied I got my META.json file here: github.com/sdondley/Proc-Easier/bl...META6.json 04:39
and then I'm looking at github.com/Raku/REA but the url to my github repo is nowhere to be found in any file. some modules have "source" urls in the json and some don't. 04:40
so how can I reliably extract the url to the module's source code? 04:41
I notice some modules use "source" in META6.json and some use "source-url" 04:55
seems like the modules that use "source" have the urls to github repo in tact
i guess only way is to pull the META6.json file out of the tar.gz in the archive file? 04:56
i guess only way is to get the url is to pull the META6.json file out of the tar.gz in the archive file and check it?
jaguart stevies: isnt this available in 360.zef.pm for zef modules? an array of JSON that contains source-urls 07:01
stevied: isnt this available in 360.zef.pm for zef modules? an array of JSON that contains source-urls
source-url looks more common there - might be a tooling change 07:03
Nemokosch to my knowledge, distributions absolutely don't have to expose any modules, and even if they do, those modules don't have to have anything in common with the distribution name 09:27
guifa: it's not about `use`. The quintessential difference is that most "package managers" in programming languages don't make you depend on namespaces. 09:30
I can imagine there are dependency management systems that simply don't draw a difference between a namespace/module and an entry uploaded to the ecosystem (what Raku calls distribution). But Raku does and still picks a *distribution* to install based on a *namespace* it provides... 09:35
dakkar (nitpick: Raku doesn't install anything; rakudo doesn't install anything; zef install things) 09:38
tellable6 2022-07-06T20:54:41Z #raku <Xliff> dakkar Thanks
dakkar (ok ok, the CompUnit::something does most of the installing, but zef definitely does the looking up)
Nemokosch Well, one could counter-nitpick: github.com/Raku/old-design-docs/bl...on-manager 09:40
tbh I'm not sure if it was fortunate to spec this behavior of all things, rather than let it to the tooling that develops over time 09:41
dakkar well… the authority/version/api keys are used at `use` time too, so it had to be in the language spec
(I was only nit-picking on the "install" verb) 09:42
Nemokosch I think tying `use` and dependency management is the bad path to walk down upon itself
`use` has no knowledge of code out there, it works on compilation units 09:43
dakkar the aim of that design was to be able to have multiple versions of the same package/module/thing installed at the same time, and being able to "use" the one you really want
so if I release MagicThing:api<1> and you `use MagicThing:api<1>` in your code,
then I release MagicThing:api<2> and some of your other dependencies use _that_, your code still works 09:44
(this scenario currently breaks perl5, and that's why several CPAN distributions bake the api version in their name)
Nemokosch dakkar: this way of phrasing itself carries a misconception. You *don't* release the same conceptual unit that one can use.
dakkar ? 09:45
Nemokosch You release a distribution and one uses a module
Conceptually there is no way to "release a module"
dakkar ok, sure; how does that affect what I said?
Nemokosch well, makes it kinda meaningless 09:46
dakkar I release a distribution that contains modules… each module carries authority/version/api metadata (inherited from its distribution at install time, maybe?) 09:47
then you can select a module via its name and that metadata, when `use`ing it
Nemokosch the problem itself is to use these two actions in the same sentence. One doesn't "release a new version of a module". META6 doesn't even correspond to a module but a distribution. All that metadata exists on a distribution level.
dakkar ok, sure 09:48
Nemokosch I'm not even sure if modules can define their own version, auth, api in a way that doesn't need you to install the distribution in order to get them for that one module specifically 09:49
dakkar that's why I wrote «each module carries authority/version/api metadata (inherited from its distribution at install time, maybe?)»
the compunit repository definitely has access to that info
Nemokosch the compunit repository kicks in after you installed the distribution, no? 09:50
dakkar yes
I was trying to explain why S22 specifies the behhaviour of authority/version/api 09:51
Nemokosch anyway, you see where I'm going, right? Is it even possible to specify auth, version, api *for a module*, in a way that matters for dependency management?
dakkar I don't think so, no 09:52
Nemokosch because my most obvious point against this whole design in the first place is that you need to specifically know the distribution anyway, it's not possible to abstract it away, by the very design
dakkar uh? 09:53
Nemokosch the distribution provides the metadata used for fully specifying the module to retrieve 09:54
dakkar sure, but I only care about that metadata… if the author splits a distribution in two, without changing the module names / authority / api, and the new distributions have versions >= the old distribution's version, I don't really need to care at `use` time 09:55
once installed, we can really pretend the metadata is attached to the module
Nemokosch IF the author does something very specific 09:56
but why would the author 1. split the distribution in two 2. if they do - manage the metadata with an implicit connection inherited? 09:57
that's a very delicate situation
dakkar updating the `api` number is also something the author must remember to do
we always depend on authors being careful
with perl5/cpan, we do attach the version to the module 09:58
Nemokosch the author can be careful by simply not trying to split distributions afterwards
dakkar with the result that a ton of distributions have modules with different version numbers 09:59
Nemokosch because the author knows that a distribution is an undivisible unit by META6
dakkar which is *very confusing*
Nemokosch I don't know what you are talking about. A distribution CANNOT have modules with different version numbers, we have just clarified that.
dakkar re: split, sure, that was an example I came up with to show that, at `use` time, you don't really need to care about where a module came from, you only need to specify what you (the user) care about
re: different version numbers, I said "in perl5/cpan…" 10:00
Nemokosch okay, that's 3 lines above for me
dakkar: I agree for `use`. Tbh `use` can't even work differently, without coming up from something fundamentally different from scratch. My whole point is that dependency management has no meaningful reason to "dumb down" to the level of `use`. 10:03
dakkar I clearly arrived in the middle of a longer discussion, and lack enough context…
Nemokosch For cpan: I think this is a really good point why this whole "share distributions, look up modules" approach is something to be fixed about Perl5 10:04
dakkar: well, I felt I needed to clarify that `use X` shouldn't matter for dependency management because e.g you have different metadata to make decisions upon. And this does seem to be recurring in the "longer discussion"... 10:06
My stance/role in the "longer discussion" is there are two choices. I think the right choice - and to my judgement, the simpler choice, even - would be to ditch the design and consistently migrate to distributions as dependencies; maybe offering a fallback to the "historical spec" but that should be a secondary thing at best. 10:12
But there is also the choice to consistently and eagerly applying the practices required for the supposed design.
I named 3 examples in my Raku scratchpad: github.com/2colours/Raku-ideas/blo...0wishes.md 10:13
jaguart I think Modules can have their own version independant of the distribution Meta6
you can ask $module.^ver to see the module version 10:14
Nemokosch jaguart: modules exist on code level so that's fairly certain 10:15
the thing is, that won't help you at dependency resolution time...
jaguart and it can be different from the distribution meta version
Nemokosch it's not transparent enough for that.
jaguart I can check further, but the compiled things are all keyed by their version too
Nemokosch I don't know if the spec has a say about what an ecosystem consists of, or how recommendations are made 10:17
jaguart even a single compunit can contain multiple modules - each with their own auth/version/api
Nemokosch one thing is quite sure: at the moment, it's the META6 files that can provide data for dependency management, and pretty much only them.
Actually, you are making really good points for what I'm saying 10:18
jaguart for install or execution?
Nemokosch installation
You are perfectly demonstrating why `use` wouldn't act like the dependency resolution and installation 10:20
jaguart isn't that just a broad-stroke installation thing - if you wanted zef to act like apt you would have to do the dependency at the lowest level
Nemokosch I'm not sure what this means
jaguart I dont know how modules get their auth/ver/api if it's not specified - maybe as dakkar said it's backfilled from the meta 10:21
It is annoying though how a meta6 in the cwd screws with module loading 10:22
dakkar see docs.raku.org/type/CompUnit::Repos...od_install and docs.raku.org/type/Distribution 10:23
Nemokosch I mean, anyway. When you install a... distribution, even if you theoretically mark the modules as the dependencies, the lookup can only happen based on the META6 file, and that doesn't specify individual auth-api-version for modules
jaguart I'm currently working on grokking compunits from disk - I'm working in a folder with a META6.json - I see that even though compunits are loaded from other distributions, the current (unrelated) distribution is attached to the compunit. Probably explains some of the oddities when you work in a folder with a meta6.json 10:35
I will dig tomorrow - it's 21:36 in Melb. 10:36
Nemokosch 🥱
jaguart this gist as an example: gist.github.com/jaguart/199e14bf31...042282d03c 10:39
Nemokosch how do you use it? 10:53
lizmat clickbaits rakudoweekly.blog/2023/01/09/2023-...ofeatures/ 12:29
Skarsnik I am trying to build rakudo 2016.1 and I get a Can't locate build/setup.pm in @INC error. Someone remember what module do I need? x) 13:44
lizmat wow 13:44
setup.pm ? 13:45
Nemokosch there's a reason rakubrew can't build 2016.1, and iirc it's blamed on Perl indeed 13:46
Skarsnik Well, it was working in 2016 x)
Nemokosch github.com/Raku/App-Rakubrew/issues/45 13:47
patrickb it's the back compat breaking "remove . from inc" change Perl went through. I don't think there is a sensible way to fix this. 13:48
Ah, Nemokosch already dug out an issue. 13:49
Skarsnik I could add . to PERL5LIB?
Where the hell is the setup.pm anyways ^^ 13:55
Ok, here we go, compiling all rakudo from 2016.1 x) 14:09
lizmat Skarsnik could you document how you did that? 14:10
also note that some commits are unbuildable
I've made a few over the years :-(
Skarsnik I only take tagged release 14:11
I don't have PetaBytes of storage sadly x)
I should have multithread the thing, since rakudo build does not take much core 14:12
lizmat it should take 1 core and a bit though
nine You are mixing design and implementation. What's currently implemented is the installation process taking version, auth, etc. from the distribution only. But the design doesn't prescribe that. We can extend the system to take the versions from the comp units themselves if the need arises. 14:14
lizmat nine: wrong channel? 14:15
nine No, just a bit late to the discussion
lizmat ah ok
Skarsnik I think there was a 'simple' way to split a loop into multithrad/process ?
The script that does the dl/build is a raku script 14:16
lizmat .race(:1batch)
Nemokosch nine: I don't know if it prescribes it or not but it's much more important that what it does describe drifted in this very direction for obvious reasons. There is an archive for obtaining the sources and a META6 file corresponding to the *distribution*. 14:19
Yes, probably it could be done right even with the handicap this approach itself gives. Will it ever happen? With the attitude that even denies the problem, surely not. 14:20
Skarsnik I replace 'for @rakudo-version -> $rakudo {' with for [email@hidden.address] -> $rakudo {' ? 14:21
I replace 'for @rakudo-version -> $rakudo {' with for '@rakudo-version.race(6) -> $rakudo {' ?
I am not sure if this is safe anyways, I use the shell function to execute command ~~ 14:25
Nemokosch does race take a positional argument? 14:27
Skarsnik Oh right, it's a named one 14:30
Nemokosch I think shell is blocking but I wouldn't bet my life how that works on multiple threads 14:40
there is the cool thing Proc::Async which is more sophisticated 14:41
Skarsnik anyways, the code of this is <gist.github.com/Skarsnik/e6835801c...5c3980> I am too lazy to bother with proc::async x) 14:56
Nemokosch did the exporting work? if it did, it probably won't go away afterwards anyway 15:24
Skarsnik yes, but need to update it for each rakudo 15:27
2016 done, halfway through 2017 15:29
Nemokosch oh right, the variable changes 15:37
I came across an interesting error while piping raku -e's one after the other: trying to write a long line resulted in an error for MoarVM 16:04
again, when would this happen if not while work 😅
piping raku over raku may also play a role 16:12
Skarsnik 2018.05 failed, hm 16:41
linking 3rdparty/libuv/libuv.a 16:43
linking libmoar.so
/usr/bin/ld : src/6model/serialization.o:(.bss+0x0) : définitions multiples de « cmp_tc »; src/6model/reprs/MVMHash.o:(.bss+0x0) : défini pour la première fois ici
collect2: error: ld returned 1 exit status
same error on 06 16:46
Nemokosch such French 16:56
grondilu m: use NativeCall; # testing if I can show NativeCall code here 17:21
camelia ( no output )
grondilu m: use NativeCall; my @a := CArray[num32].new; @a[$_] = rand for ^10; print nativesizeof(@a) 17:22
camelia 8
grondilu why 8?
m: use NativeCall; my $a = CArray[num32].new; $a[$_] = rand for ^10; print nativesizeof($a) 17:23
camelia 8
grondilu m: use NativeCall; my $a = CArray[num32].allocate(10); $a[$_] = rand for ^10; print nativesizeof($a)
camelia 8
grondilu 🤷 17:24
m: use NativeCall; my $a = CArray[num64].allocate(10); $a[$_] = rand for ^10; print nativesizeof($a)
camelia 8
grondilu 😕
Nemokosch is this what you also see for yourself? 17:45
Skarsnik nativesizeof give only the size of the 'container' I think 17:51
since you always need to know the size of an array in C. 17:58
2018-2019 refuse to build too >< 17:59
2022.12 was fine
Nemokosch do they contain corresponding NQP and Moar versions as well? 18:00
Skarsnik I build from release tarball 18:01
Nemokosch yes, I mean do they contain this stuff? 18:02
Skarsnik no, it's always get by git I think 18:11
Nemokosch I wouldn't be surprised if there were "misbumps" or something of that sort 18:24
lizmat yeah, that's happened as well :-( 18:27
but not with release versions afaik
Skarsnik yes 18:38
especially on like a whole year 18:39
lizmat ooh wow
Skarsnik 2019.07.1 18:41
Can't locate NQP/Config.pm in @INC (you may need to install the NQP::Config module) (@INC contains: /mnt/hgfs/Perl6/benchmark/rakudo-2019.07.1/tools/lib /mnt/hgfs/Perl6/benchmark/rakudo-2019.07.1/3rdparty/nqp-configure/lib /mnt/hgfs/Perl6/benchmark/rakudo-2016.01.1/nqp/MoarVM/ /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /u
ugexe are you building using e.g. rakubrew? 18:42
Skarsnik No, I build from release tarball 18:43
Not sure why it the configure.pl keep failing now 18:46
ugexe 2019.07 is around when rakudo was updated to use github.com/Raku/nqp-configure I think 18:57
Skarsnik 2020.06 has the same issue 19:18
I skipp 2018-2020 so far 19:19
ugexe i imagine it has to do with git submodules
tonyo . 19:20
Skarsnik I just run perl Configure.pl --gen-moar --gen-nqp --backends=moar
ugexe but you are using tarballs
if you were cloning the git repo and switching to that tag it might work due to submodules 19:21
Skarsnik Yeah, but usally release tar ball work
tonyo if you have moar or nqp in the environment already you can omit those two flags 19:22
Skarsnik it worked throu 2016-2017
No, because I want to build with then
tonyo is there a .gitmodules in the release tar? 19:23
Skarsnik skarsnik@debianraku:/mnt/hgfs/Perl6/benchmark/rakudo-2022.03$ cat .gitmodules 19:24
[submodule "3rdparty/nqp-configure"]
path = 3rdparty/nqp-configure
url = github.com/Raku/nqp-configure.git
tonyo is the 3rdparty/nqp-configure directory empty in the release tar? 19:25
or nonexistent
Skarsnik Why should it matter? the configure script is supposed fetch everything. I always built using release x) 19:26
ugexe that doesn't really answer their question 19:57
Skarsnik but yes it's emtpy 20:06
(sorry for delay between reply x)) 20:14
ugexe well, thats why it cant find NQP::Configure, and why the script can't even compile (and hence doesn't matter if its actually needed or not) 20:40
Skarsnik Yes, but is the configure script supposed to do the correct git stuff to have all the component? 21:01
ugexe the configure script cant compile 21:02
its missing NQP::Configure
which is a submodule of the rakudo repo
the configure script can't do anything until it can compile 21:03
should nqp-configure/ be missing from the release tarball? I dunno, probably not. but that sure seems why it isn't working for you
Skarsnik Ho I think I found why maybe, the script download tagged source I think and not release 21:06
ok, all 2018 compile fine now, sorry for the dumb mistae x) 21:27