🦋 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.
00:00 reportable6 left 00:01 reportable6 joined
japhb stevied: github.com/Raku/REA ? 00:05
(And why do you want to *fork* them all?) 00:06
00:09 Guest22 joined 00:10 Guest22 left 00:30 samcv left, samcv joined
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
01:07 Kaiepi joined
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
01:19 jpn joined
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
01:21 bigdata joined
stevied just stumbled on this list: github.com/Raku/ecosystem/blob/main/META.list 01:24
01:24 jpn left
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
01:33 bigdata left
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
02:33 linkable6 left, evalable6 left 02:34 linkable6 joined 02:36 evalable6 joined
leont doesn't making «use Foo::bar» make sense typically means stuffing absolutely everything in one file 02:46
s/doesn't/& like how/
03:07 jpn joined 03:13 jpn left 03:21 rf left 04:03 jpn joined 04:09 jpn left 04:12 ToddAndMargo left
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
04:15 vrurg_ joined, vrurg left 04:26 jpn joined 04:30 alfonsox joined
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?
05:27 jpn left 05:56 jpn joined 06:00 reportable6 left 06:01 jpn left 06:02 reportable6 joined 06:31 Kaiepi left 06:51 jpn joined 06:57 jpn left
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
07:09 razetime joined 07:33 abraxxa joined 07:37 abraxxa left 07:38 abraxxa joined 07:45 jpn joined 07:50 razetime left 07:54 jpn left 08:01 razetime joined 08:02 jjido joined 08:08 Sgeo left 08:20 jpn joined 08:25 jpn left 08:33 jjido left 08:36 buffet left 08:38 buffet joined 08:41 sena_kun joined 08:58 alfonsox left 09:03 jjido joined 09:05 jjido left 09:12 dakkar joined 09:24 buffet left 09:25 buffet joined
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
09:30 justReddy is now known as justache
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
10:23 jpn joined
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 🥱
10:39 jpn left
jaguart this gist as an example: gist.github.com/jaguart/199e14bf31...042282d03c 10:39
10:42 jpn joined
Nemokosch how do you use it? 10:53
10:56 Kaiepi joined 11:11 jpn left 11:26 jjido joined 11:27 jjido left 11:30 alfonsox joined 12:00 reportable6 left, reportable6 joined 12:05 jpn joined 12:10 jpn left 12:16 jpn joined
lizmat clickbaits rakudoweekly.blog/2023/01/09/2023-...ofeatures/ 12:29
12:38 discord-raku-bot left, discord-raku-bot joined 12:41 jpn left 12:47 andreoss` left 12:48 andreoss` joined 12:56 discord-raku-bot left, discord-raku-bot joined 13:00 jpn joined 13:05 jpn left 13:06 razetime left 13:15 dakkar left 13:16 dakkar joined, dakkar left, jpn joined 13:17 dakkar joined, dakkar left 13:35 MoC joined
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
13:44 lichtkind joined
lizmat wow 13:44
setup.pm ? 13:45
13:45 jpn left
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
13:58 jpn joined 14:00 razetime joined 14:06 jpn left
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
14:14 dakkar joined
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)
14:17 xinming_ joined
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
14:19 jpn joined
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 {' ?
14:22 Kaiepi left, Kaiepi joined
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
14:50 jgaz joined
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
15:50 linkable6 left, evalable6 left, linkable6 joined 15:52 evalable6 joined 15:55 Sgeo joined 15:58 MoC left
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
16:22 jpn left 16:26 jpn joined
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
16:57 alfonsox left 17:00 jpn left 17:14 razetime left 17:21 grondilu joined
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 😕
17:37 dakkar left
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
18:00 reportable6 left
Nemokosch do they contain corresponding NQP and Moar versions as well? 18:00
18:00 reportable6 joined
Skarsnik I build from release tarball 18:01
Nemokosch yes, I mean do they contain this stuff? 18:02
18:07 abraxxa left 18:09 thowe left 18:10 thowe joined
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
18:30 lichtkind left
Skarsnik yes 18:38
especially on like a whole year 18:39
lizmat ooh wow
18:39 jgaz left
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
18:55 jgaz joined
ugexe 2019.07 is around when rakudo was updated to use github.com/Raku/nqp-configure I think 18:57
19:02 ab5tract joined 19:06 bigdata joined
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
19:21 ab5tract left
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
19:25 ab5tract joined
tonyo is the 3rdparty/nqp-configure directory empty in the release tar? 19:25
or nonexistent
19:26 El_Che left
Skarsnik Why should it matter? the configure script is supposed fetch everything. I always built using release x) 19:26
19:27 El_Che joined 19:29 Kaiepi left 19:31 grondilu left 19:34 lichtkind joined 19:43 jgaz left 19:49 ab5tract left
ugexe that doesn't really answer their question 19:57
Skarsnik but yes it's emtpy 20:06
20:09 Kaiepi joined 20:12 jgaz joined
(sorry for delay between reply x)) 20:14
20:24 bigdata left 20:29 jpn joined 20:33 ab5tract joined
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
20:43 ab5tract left 21:00 Maylay left 21:01 Maylay joined
Skarsnik Yes, but is the configure script supposed to do the correct git stuff to have all the component? 21:01
21:01 jpn left
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
21:03 bigdata joined
Skarsnik Ho I think I found why maybe, the script download tagged source I think and not release 21:06
21:10 ab5tract joined 21:19 ab5tract left 21:23 ProperNoun left
ok, all 2018 compile fine now, sorry for the dumb mistae x) 21:27
21:51 jpn joined, jaguart left 21:56 bigdata left 22:11 jgaz left, jaguart joined 22:21 Xliff joined 22:53 jpn left 22:58 sena_kun left 23:19 lichtkind left 23:38 lichtkind joined 23:49 jpn joined 23:55 jpn 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!