|
🦋 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 | |
|
00:06
reportable6 left
00:10
guifa joined
00:21
jgaz joined
|
|||
| El_Che | crosscompiling moarvm/rakudo ia less that obvious due the non-static nature of the setup? | 00:30 | |
|
00:52
morte_ joined
01:09
reportable6 joined
01:52
jgaz left
02:18
morte_ left
02:28
frost joined
02:37
monkey_ left
03:03
guifa left
03:06
morte_ joined
03:41
lockywolf joined
04:41
squashable6 left,
notable6 left,
linkable6 left,
sourceable6 left,
benchable6 left,
quotable6 left,
releasable6 left,
coverable6 left,
shareable6 left,
tellable6 left,
bisectable6 left,
bloatable6 left,
nativecallable6 left,
unicodable6 left,
statisfiable6 left,
committable6 left,
evalable6 left,
reportable6 left,
greppable6 left,
sourceable6 joined,
benchable6 joined
04:42
bloatable6 joined,
quotable6 joined,
evalable6 joined,
reportable6 joined
04:43
releasable6 joined
04:52
morte_ left
05:41
notable6 joined
05:42
committable6 joined
05:43
coverable6 joined,
greppable6 joined,
linkable6 joined
05:44
nativecallable6 joined,
statisfiable6 joined,
tellable6 joined
05:58
mexen joined
06:08
reportable6 left
|
|||
| Woodi | do using classic modules versioning (like in Perl5), without that guix-like hashes mess, would speed things up ? | 06:27 | |
|
07:08
linkable6 left,
evalable6 left
07:09
evalable6 joined
07:10
reportable6 joined
07:24
guifa joined
07:28
seednode left
07:29
seednode joined
07:45
guifa left
08:32
Sgeo left
08:42
bisectable6 joined
08:43
unicodable6 joined,
shareable6 joined
08:45
epony left
08:48
epony joined
09:01
jjido joined
09:10
linkable6 joined
|
|||
| lizmat is not sure what Woodi means | 09:44 | ||
|
09:46
Skarsnik joined
09:56
MoC joined
10:48
jjido left
11:14
sena_kun joined
11:17
jjido joined
12:07
reportable6 left,
reportable6 joined
12:19
jjido left
12:34
jjido joined
|
|||
| ugexe | do you feel hashing is slow? if so, why? | 12:41 | |
|
12:41
squashable6 joined
|
|||
| 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 | |
|
13:25
jjido left
13:40
monkey_ joined
13:55
monkey_ left
14:00
monkey_ joined
14:40
guifa joined
15:02
Kaiepi joined
15:06
monkey_ left
15:13
Sgeo joined
15:20
jjido joined
15:26
squashable6 left
15:44
guifa left
16:09
seednode left
16:10
guifa joined
16:23
seednode joined
16:29
squashable6 joined
16:53
euandreh left
16:57
euandreh joined
17:15
lucasb joined
17:56
sena_kun left
18:07
reportable6 left
18:09
reportable6 joined
|
|||
| moon-child | maybe longer pathnames? But I wouldn't expect that to be a bottleneck anyway | 18:11 | |
|
18:41
qorg11 left
19:08
jgaz joined
|
|||
| 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 | |
|
19:26
qorg11 joined
19:33
qorg11 left,
qorg11 joined
|
|||
| Woodi | ugexe: too bad it's slower. still, hours for base distro installation is not good. any idea which part is slow ? | 19:33 | |
|
19:35
lucasb left
|
|||
| 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. | ||
|
20:35
linkable6 left,
evalable6 left
|
|||
| jdv | the thing precomp tries to ameliorate:( | 20:35 | |
| Woodi | zef is like cpanm not installing from tarball... | ||
|
20:36
linkable6 joined
|
|||
| 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++ | ||
|
20:37
evalable6 joined
|
|||
| 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 | |
|
20:46
guifa left
|
|||
| 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 | |
|
21:01
bdju left
21:09
bdju joined
|
|||
| 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 | ||
|
21:42
MoC left
21:47
bdju left
21:54
bdju joined
|
|||
| 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 | ||
| ? | |||
|
22:26
bdju left
22:33
bdju joined
|
|||
| 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 | ||
|
23:33
evalable6 left,
linkable6 left,
djerius left
23:40
djerius joined
23:54
jjido left
|
|||