|
🦋 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:09
epony left
00:52
epony joined
02:37
epony left
03:56
vrurg_ joined
03:59
vrurg left
04:31
epony joined
05:09
patrickb left
05:37
epony left
07:08
epony joined
07:14
epony left
09:15
sena_kun joined
|
|||
| Geth | rakudo/main: 61a87f0758 | (Elizabeth Mattijsen)++ | src/core.c/IO/Pipe.rakumod Revert "Install workaround for R#5444" This reverts commit b7def4aae0ad1d63013f1f1637bcb552dc266669. It did not help. |
10:41 | |
| linkable6 | R#5444 [open]: github.com/rakudo/rakudo/issues/5444 [edge cases] REA Harvester occasional crash | ||
|
13:21
patrickb joined
|
|||
| Geth | rakudo/main: 9b179a5540 | (Elizabeth Mattijsen)++ | docs/dispatchers.md Initial stab at internally documenting dispatch handlers |
13:26 | |
|
13:42
patrickb left
13:51
patrickb joined
13:56
patrickb left
|
|||
| Geth | nqp/main: 564cb03d05 | (Elizabeth Mattijsen)++ | docs/bootstrapping.pod Update IRC link for bootstrapping process |
16:39 | |
| ab5tract | Regarding Rust, it wouldn't be my preference for retrofitting MoarVM. | 17:05 | |
| It's a seriously deep, complex language (not a bad thing, so is Rakue). That raises the barrier to entry for Raku devs who want to dip their toes into statically typed languages, maybe even for their first time. | 17:10 | ||
| I'd rather use Zig because it is a much simpler, more batteries-included systems programming language that allows for very fine granularity over memory management. | 17:13 | ||
| Not to mention incredible C integration. I'll have to check into how well `MVM_ROOT` and the rest of the MoarVM macros are handled but unless they are properly obscure, they might just translate to Zig without issue, as it can handle some level of C macro-fu. | 17:16 | ||
| jdv | this whole conversation feels parrotish:( | ||
| ab5tract | jdv: sorry to hear that | ||
| jdv | lotsa real stuff is built in c. idk if that is a real problem. | 17:17 | |
| ab5tract | I'd say the contributor count to moarvm suggests otherwise | 17:18 | |
| jdv | hypthetically if the vm was written in $en_vogue_tech would it mean raku would be in a better place? | 17:19 | |
| ab5tract | my hypothesis is that if we were to see real forward momentum happening in moarvm, it would put Raku in a better place | 17:20 | |
| funny enough, this conversation didn't feel parrot-ish to me until you brought your water pail to pour on it :) | 17:21 | ||
| Geth | nqp/main: 082fb2d549 | (Elizabeth Mattijsen)++ | 2 files Add nqp::syscall, nqp::register, nqp::delegate ops These are short-cuts for: syscall nqp::dispatch('boot-syscall', …) register nqp::dispatch('boot-syscall', 'dispatcher-register', …) delegate nqp::dispatch('boot-syscall', 'dispatcher-delegate', …) This should hopefully make the dispatcher setup code in core, as well as in Rakudo, a lot better readable. Also adjust most of the tests to use these new ops |
17:23 | |
| nqp/main: 04dc665920 | (Elizabeth Mattijsen)++ | 3 files Use new syscall/register/delegate ops in dispatcher setup This improves the readability of these internals significantly. |
|||
| nqp/main: 2cc7e329f5 | (Elizabeth Mattijsen)++ | 11 files Rebootstrap to get new syscall/register/delegate ops |
|||
| jdv | pugs, Niecza, parrot. do we need another vm? | 17:26 | |
| ab5tract | I'm not talking about another vm | 17:29 | |
| jdv | make it so then!:) | 17:34 | |
| Geth | rakudo/main: a3645497bd | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to get new nqp::syscall/register/delegate ops |
||
|
18:29
timo left
18:46
timo joined
|
|||
| Geth | rakudo/main: 690c6c01ba | (Elizabeth Mattijsen)++ | docs/dispatchers.md Add set-cur-hll-config-key dispatch key |
19:20 | |
| rakudo/main: becb682e14 | (Elizabeth Mattijsen)++ | 11 files Use new nqp::syscall/register/delegate ops Instead of their long nqp::dispatch(....) versions |
|||
| nqp/main: f7451a8f0d | (Elizabeth Mattijsen)++ | 2 files Use new syscall/register/delegate ops in more tests |
19:29 | ||
| rakudo/main: bef0a9bfbf | (Elizabeth Mattijsen)++ | src/Raku/ast/signature.rakumod RakuAST: use new nqp::syscall op |
19:48 | ||
| nqp/main: df955144fd | (Elizabeth Mattijsen)++ | docs/ops.markdown Add preliminary docs for nqp::dispatch and friends |
20:18 | ||
| vrurg_ | ab5tract: what real advantages Zig could bring in? | 20:20 | |
| lizmat | memory safety is one of them, i understand | 20:21 | |
| Geth | nqp/main: d06cf15ec0 | (Elizabeth Mattijsen)++ | docs/ops.markdown Fix two anchors in ops docs |
20:23 | |
| vrurg_ | lizmat: I don't see much of it. Introduction of optional type is helpful with this respect. But does it take care of double allocations? And, as I see it, concurrent access is yet to be fully manually managed. | 20:25 | |
| lizmat | ab5tract ^^ has looked into it way more than I did ^^ | 20:26 | |
| vrurg_ | I know. :) Just expressing what I found so far. | ||
| lizmat | afk& done my hacking for today | ||
| vrurg_ | lizmat: rest well today! | ||
|
20:26
vrurg_ is now known as vrurg
|
|||
| vrurg | My preliminary view on zig attempt would be: worth trying if it doesn't take too much resources. Otherwise Rust would provide more robust grounds both from safety perspective and from the perspective of potential user base. | 20:28 | |
|
20:52
epony joined
|
|||
| nine | I somehow doubt that C is the real barrier here. There are tons of successful free software projects written in C out there. A different language might help in a few places, but really it wouldn't make developing MoarVM much easier. | 21:14 | |
| Thing is, the problems MoarVM tries to solve are really, really hard. That's independent of the language the solution is written in. | |||
| vrurg | nine: yes, and no. Ultimately, if moar to be started like today then the choice would be clear to me. But rewriting the existing codebase? Hell, no! Waste of time. | 21:32 | |
| Voldenet | `zig cc` could probably compile moarvm right now and zig fundamentally allows compile time execution | 21:49 | |
| it's not bad of a choice, but it's difficult to say why it's better | 21:53 | ||
| there's some design decisions like Allocator or async that could simplify a lot of things | 21:54 | ||
| ab5tract | Voldenet: it does indeed compile moarvm, I’ve got a branch with it working. | 23:22 | |
| Voldenet | it probably isn't significantly faster or anything like that | 23:23 | |
|
23:23
sena_kun left
|
|||
| Voldenet | but lets you use zig painlessly | 23:24 | |
| ab5tract | Not at the moment, no. | ||
| It would also likely make Windows compilation an easier story, though I haven’t tested that hypothesis yet | |||
| Voldenet | and probably other architectures too (if it works as advertised) | 23:32 | |