🦋 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.
japhb Nah, I really need to *completely* separate download from build. I'm effectively serializing now, but I think zef runs a download/unpack, assumes it succeeds, and then proceeds with testing, only to have it fail, because there was never a working/complete tarball to unpack. 00:05
El_Che crosscompiling moarvm/rakudo ia less that obvious due the non-static nature of the setup? 00:30
Woodi do using classic modules versioning (like in Perl5), without that guix-like hashes mess, would speed things up ? 06:27
lizmat is not sure what Woodi means 09:44
ugexe do you feel hashing is slow? if so, why? 12:41
ugexe computers don't really care if a string is human readable. a computer can look up a seemingly random string as quickly as it can a human readable one, even if its encoded into a file path 12:42
moon-child maybe longer pathnames? But I wouldn't expect that to be a bottleneck anyway 18:11
Woodi moustly I mean total mess on filesystem. classic way you have source file and compiled, per version, simple. and no need for links or lookups. also I'm asking: do simpler structure could gain something in speed or unmess ? 19:10
that modern hash repos are implemented via some intermediate and generalized api's ? would be nice to have classic repositories implementation. or maybe it is one ? 19:13
ugexe I have implemented such a repository. if anything its slower 19:15
github.com/ugexe/Perl6-CompUnit--R...itory--Lib
lizmat www.reddit.com/r/rakulang/comments...dem_talks/ 19:18
Woodi ugexe: too bad it's slower. still, hours for base distro installation is not good. any idea which part is slow ? 19:33
leont If it was an IRL conference I'd submit my 'raku syntax I miss in other languages', but doing it online twice feels a bit weird 19:52
lizmat maybe you started missing more? :-) 20:06
qorg11 Is there an emacs completion framework (like company) for raku? 20:21
jdv Woodi: parsing is still painfully slow. maybe thats most of what youre seeing? 20:27
Woodi ...actually no. if problem is: initial installation of compilers distro *with modules* is slow then in classic lib/Foo/Bar.pm type of repos module installation is solved during unpacking. no need for parsing, hashing, coping, linking or running anything. just configure repo path. and, for cheating purposes, precompilation is done during first run, if I remember corectly :) but can be done just after 20:28
unpacking...
jdv by installation do you count running zef? 20:29
Woodi jdv: actually all that *hours* thing can be considered not so slow :) if raku is ~20x slower then Perl5 then 2 hours is not so bad ;)
MasterDuke nine has some suggestions about making module installation faster by not duplicating some work
Woodi jdv: not anymore. just unpack where it need to be 20:30
MasterDuke and fwiw, that hours for installation is/was just on RPIs, not more normal desktop/laptop hardware
jdv curious. be interesting what exactly is slow for you.
Woodi zef/hashes-style repos looks cargo-culted into installing distribution...
on my laptop or old desktop installing rakudo-202[01]... was around hour... 20:31
jdv what exactly did that entail? 20:32
Woodi and repositories mechanism is buildin and many types of repos can coexists ?
jdv i compiled rakudo head on my rpi4 the other day and it was minutes, not hours.
Woodi with modules ?
jdv many minutes ht still:)
*but 20:33
no
installing modules, afaik, is dominated by the parse perf issue.
Woodi parse of sources or jsons ? 20:34
jdv source. grammaes basically.
jdv the thing precomp tries to ameliorate:( 20:35
Woodi zef is like cpanm not installing from tarball...
jdv it has to comp/precomp to run tests... 20:36
Woodi also other day i found hashes are fast now with new dispatch dispatch :) jnthn++
jdv in any case its a known pain point. people are trying. thanks for playing:) 20:37
Woodi but eg. debian just unpack deb files do not run any tests. installing from release tarball is like deb, imo/ but i just could not fall into sleep but maybe I'm dreaming anyway ? 20:39
jdv raku is like perl where tests are run upon install, at least with cpan, cpanm, zef, etc... 20:40
yes, if the modules were distro pkged youd skip that...
Woodi do deb contains precompiled modules ? :) 20:41
jdv afaik no so you take inital hit...
MasterDuke the suse packages might be pre-precompiled. i think nine is involved there and he's talked about it at least 20:42
jdv perf is center stage these days. it might take a while but its a priority. 20:43
MasterDuke the problem is that the current slowest part, grammars, has the fewest people who understand it well enough to improve it. and it might be the most novel thing about raku. some of the moarvm improvements are "just" implementing a reasonably-well-known theory or algorithm (i.e., there's prior practice to learn from, even though it could very well be 20:48
quite complicated). but raku's grammar has fewer places to steal code from (as far as i'm aware, which is limited), so improving it requires doing more things for the first time
and most of the original implementors of it aren't currently active for various reasons 20:49
jdv :( 20:50
nine The openSUSE packages do contain precompiled files. It's really just installing them within seconds and your application will start up immediately 21:18
If Debian packages do not contain precomp files, they are kind of only doing half the job and I'd wonder why. 21:19
In fact being able to package precompiled files is one of the major goal of the often critiziced (and rarely understood) module management system. 21:20
Also I really don't understand why people would waste hours having an underpowered device like a Pi precompile Raku code, when you can have a system doing it that's probably tens of times faster. But then, people seem to prefer making the wildest guesses as to how to improve them to actually understanding the systems they using. 21:21
Understanding them would gain you the insight that precomp files are architecture independent and that you can simply copy them from your beefy desktop to your embedded device. 21:22
El_Che nine: copy hashed directories is something people in the know would do, but it's not something very user friendly 21:55
ask 100 raku users if they know about it and round 99 wouldn't have a clue 21:56
Skarsnik then why not have precompile file stored in mlodule management repo
?
japhb Skarsnik: Precompiles are based on versions of the compiler and other modules. A linux distro could do waterfall packaging, so guaranteed versions of all dependencies including the compiler, but zef could not reasonably do this without a storage explosion. In theory we *could* offer a variant that has precompiles only from a snapshot at the instant of a new compiler release, but ... well, that kinda 22:44
overlaps with Rakudo Star.
Woodi: As MasterDuke said, the multiple hours on RPi 4B/4 GB that I quoted was just for my full rebuild with all my favorite modules. After a couple runs of just MoarVM, NQP, Rakudo, Zef, that base stack of four builds was 35-40 minutes on the RPi. 22:47
nine: My guess would be that precomp files are arch independent in the same way MoarVM is uint agnostic -- was fine in theory, but probably less accurate in real life. I have my suspicions about whether 64-bit Linux on x64 to 32-bit Rasbian on aarch64 is handled perfectly, though to be honest I've never tested it with my full stack. (Partially because there's no existing tool to test a full suite of 22:50
*already installed* modules.) 22:51