🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
00:30
MasterDuke joined
|
|||
MasterDuke | anyone have any objections to merging github.com/rakudo/rakudo/pull/5844 ? | 00:31 | |
JimmyZ: are you going to do any more work on github.com/Raku/nqp/pull/843 or is it ready to merge? | 00:33 | ||
tellable6 | MasterDuke, I'll pass your message to JimmyZ | ||
MasterDuke | i have a branch that makes singletons for the most common Nodify() calls, but if there's a way to get rid of Nodify all together that's even better... | 00:35 | |
00:48
[Coke]_ joined
00:49
greenfork_ joined,
nativecallable6_ joined,
shareable6__ joined,
releasable6__ joined
00:50
releasable6 left,
nativecallable6 left,
shareable6 left,
[Coke] left,
greenfork left,
greenfork_ is now known as greenfork
00:51
jdv left
00:52
jdv joined
00:53
MasterDuke left
|
|||
Geth | rakudo/main: b527cefcb2 | MasterDuke17++ (committed using GitHub Web editor) | 5 files Some random attribute access consistency changes (#5844) Fix a couple cases of native attributes not using the typed accessor, and make some other attributes consistent with similar ones. |
08:55 | |
nine | MasterDuke: I've played around a bit with the build system. With this you get it to compile the BOOTSTRAP before Raku::Actions: | 09:25 | |
tellable6 | nine, I'll pass your message to MasterDuke | ||
nine | @comp(@bsm(RAKUDO_A_R)@: @bpm(NQP_VERSION_FILE)@ @use_prereqs(@nfp(@bpm(BUILD_DIR)@/RakuActions.nqp)@)@ @bsm(RAKUDO_P)@ @bsm(RAKUDO_BOOTSTRAP_C)@ @bsm(RAKUDO_OPS)@)@ | ||
Then you can use Perl6::BOOTSTRAP::v6c; in Raku::Actions | 09:26 | ||
However that also imports the EXPORTHOW so we then try to create Raku classes instead of NQP classes and the metamodel is very confused. So I think we'd have to put RakuAST into its own file and import that from both Raku::Actions and the SETTING | |||
09:49
dogbert17 left
11:07
JimmyZhuo joined
|
|||
JimmyZhuo | MasterDuke: I think it's ok to merge, but I didn't test raku roast yet. | 11:08 | |
tellable6 | JimmyZhuo, I'll pass your message to MasterDuke | ||
12:21
[Coke]_ is now known as [Coke]
12:27
melezhik joined
|
|||
melezhik | copy pasting from raku channel - "question from Alpine maintainer who is doing raku-* package for Sparrow - "are the precompilation files specific to a particular version of Rakudo? In other words, after a Rakudo upgrade, do i need to precompile every Raku module again?"11:28 My knowlege it is not, but I am not sure." | 12:27 | |
12:38
melezhik left
|
|||
nine | Yes they are. That's why the compiler's id is included in the path name | 12:39 | |
12:44
melezhik joined
|
|||
melezhik | . | 12:44 | |
tellable6 | 2025-04-25T12:43:02Z #raku <nine> melezhik: if that alpine list impresses you, what about the openSUSE one? build.opensuse.org/project/show/de...uages:raku | ||
melezhik | nine: what then alpine maintainer should do? recomple every time for every new rakudo version is bad idea | 12:45 | |
nine | No, it's exactly the right idea. | 12:46 | |
It's also absolutely pain free on e.g. the open build service. | |||
13:04
melezhik left
|
|||
JimmyZhuo | by using moar --dump Grammar.moarvm, and reading these codes, I can see there is a lot of room for improvement to reduce it's size, and make it faster. some of these improvements is easy, and some is hard for me | 13:05 | |
nine | JimmyZhuo: keep in mind that spesh will simplify that code a lot at runtime with the information about observed types | ||
JimmyZhuo | nine: yes, I think some can be remove by spesh, and some can't | 13:07 | |
13:14
JimmyZhuo left
13:24
melezhik joined
|
|||
melezhik | nine: I am looking from an end user point of vie - so every time Rakudo gets upgraded on VM they need to upgrade all the Raku packages , doubt this is a good scenario | 13:26 | |
nine | Why is it not? It's exactly the same as I get with almost every other software including Python and Perl | 13:29 | |
13:30
melezhik left,
raku joined
13:36
raku left
|
|||
lizmat | also: why include .precomp files at all for modules? | 13:45 | |
they're created automatically on first usage ? | 13:46 | ||
nine | For the same reason we're not all using Gentoo? | ||
Why would you do the same work millions of times when the result should be identical in every case? | 13:47 | ||
lizmat | ok, but don't we have an issue then with updates, leaving stale .precomp files around? | 13:48 | |
nine | On inferior systems maybe. But since we're talking about Linux distributions with proper package managers, no, not at all. | 13:49 | |
That's after all the point of having package managers in the first place. | |||
lizmat | ok, I'm glad to hear then: melezhik: please ignore my earlier "advice" :-) | ||
nine | It's actually the opposite: the stale .precomp problem only exists if you rely on Rakudo's auto-compilation. | 13:50 | |
lizmat | which I do a lot... :-) hence my worries | 13:52 | |
nine: does this not also imply that one could exclude source files from a distribution ? | 13:53 | ||
nine | Almost. I think I wrote about binary-only distributions years back and the conclusion was that it would only take a few tweaks to make that possible | 13:54 | |
lizmat | cool... something to think about :) | ||
afk& | |||
15:01
finanalyst joined
15:34
melezhik joined
15:35
melezhik left,
melezhik joined
15:36
melezhik left,
melezhik joined
|
|||
melezhik | nine: ok, looks like Python has the similar situation with that regards - stackoverflow.com/a/43547026/5147708 | 15:37 | |
tellable6 | 2025-04-25T13:44:14Z #moarvm <lizmat> melezhik: .precomp directories will be created automatically on first execution of a module | ||
2025-04-25T13:44:44Z #moarvm <lizmat> melezhik: they should probably *not* be included in a distribution | |||
melezhik | ok, I will update alpine maintenaners  on that matter | 15:38 | |
looks like given all the distributions are in place apk update && apk upgrade should be enough | 15:40 | ||
15:42
melezhik left
16:12
finanalyst left
16:37
nine left,
nine joined
|
|||
[Coke] | releasable6__: next | 16:58 | |
releasable6__ | [Coke], Next release in ≈22 days and ≈2 hours. There are no known blockers. 5 out of 7 commits logged | ||
[Coke], Details: gist.github.com/31ea17d24eae49f5ae...3622c40499 | |||
[Coke] | anyone know how to get them to rename themselves? I think I can do a trivial change on the repo, but is there a better/devops way? | 16:59 | |
17:12
Xliff joined
18:41
finanalyst joined
19:41
finanalyst left
|
|||
patrickb | jdv: I did not intend for this to happen again. I actually spent 2 hours or so moving my PC to my parents to keep it available during my absence. But for some reason I'm again unable to access the system. Argh! | 20:31 | |
I did recently buy a JetKVM (did not arrive yet) which will hopefully once end for all put an end to this misery. | 20:32 | ||
Fundamental issue: How do I remotely and reliably boot up a computer? (Failed attempts: WakeOnLAN, a WiFi plug + PC boot up on power up) | 20:34 | ||
jdv | nice:) | 20:35 | |
ab5tract | patrickb: you can always try bribing the parental units into pressing the power button as necessary :) | 20:42 | |
the folks who I know who have tried the non-human-driven options have not been able to make them work reliable | 20:46 | ||
*reliably | |||
jdv | there's these things called laptops | 20:57 | |
i've used console server type stuff before but its a pain | 20:58 | ||
ugexe | iDRAC, etc | 21:19 | |
lizmat | patrickb: remote power switch ? | 22:00 | |
22:21
rakkable left,
rakkable joined
|