|
🦋 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:20
japhb left
01:21
dogbert17 left
02:56
japhb joined
03:55
japhb left
03:59
japhb joined
06:03
japhb left
06:05
japhb joined
06:21
lizmat_ joined
06:25
lizmat left
06:31
[Tux] left
06:32
kjp left,
codesections left,
ugexe left,
sivoais left,
elcaro left,
JRaspass left,
|Tux| left,
[Tux] joined,
kjp joined,
codesections joined,
ugexe joined,
sivoais joined,
patrickb left,
jjatria left,
lucs left,
coleman left
06:35
elcaro joined,
JRaspass joined,
|Tux| joined,
patrickb joined,
jjatria joined,
lucs joined,
coleman joined
06:37
patrickb left
07:54
patrickb joined
08:04
patrickb left
08:05
patrickb joined
08:33
patrickb left
08:40
sena_kun joined
08:44
patrickb joined
08:48
patrickb left
08:50
patrickb joined
09:01
patrickb left
10:08
sena_kun left
10:12
lizmat_ left,
lizmat joined
10:29
samebchase left
10:31
samebchase joined
|
|||
| Geth | rakudo/main: 77d657eee3 | (Elizabeth Mattijsen)++ | src/core.c/IO/Handle.rakumod Revert "Remove defaults from attributes in IO::Handle" This reverts commit eaf4009624a7093de09b630be06b638dea37dfdb. This did NOT stop the crash described in #5444 from occurring |
10:43 | |
| nemokosch | #5444 | 10:55 | |
| how does the bot resolve issues to links? | |||
| lizmat | not sure | 11:03 | |
| linkable6: help | |||
| linkable6 | lizmat, Like this: R#1946 D#1234 MOAR#768 NQP#509 SPEC#242 RT#126800 S09:320 524f98cdc # See wiki for more examples: github.com/Raku/whateverable/wiki/Linkable | ||
| lizmat | R#5444 | ||
| linkable6 | R#5444 [open]: github.com/rakudo/rakudo/issues/5444 [edge cases] REA Harvester occasional crash | ||
| nemokosch | thankies 👎 | 11:06 | |
| 👍 | |||
| oops wrong emoji selection xd | |||
| Geth | rakudo/main: b7def4aae0 | (Elizabeth Mattijsen)++ | src/core.c/IO/Pipe.rakumod Install workaround for R#5444 Primarily to see if the REA harvester will either crash there still, or at another location. |
||
| linkable6 | R#5444 [open]: github.com/rakudo/rakudo/issues/5444 [edge cases] REA Harvester occasional crash | ||
| lizmat | nemokosch no worries | ||
|
11:16
rypervenche left
11:20
rypervenche joined
11:40
guifa left
11:41
guifa joined
|
|||
| lizmat | vrurg nine in install/bin, should "rakudo" and "rakudo-m" be the same or not ? | 14:32 | |
| vrurg | Currently it is the same, but I'd say rakudo must point to the default backend, as raku does. | 14:42 | |
| lizmat | I just had a case where they were different :-( | 14:44 | |
| however, I'm also starting to suspect MacOS oddities | 14:45 | ||
| there was a security update for the M1, but not for my Intel box | 14:46 | ||
| weird | |||
| vrurg | There is a bit about ARM platform, I think. But it is more about how the problem manifest itself, not about the problem as such. Concurrent module loading does crash for me on M2 rather regularly. On x86 server I have no luck in reproducing the crash, except that there is something fishy going on about spawned child compilers. | 14:48 | |
| lizmat | .oO( probably shouldn't have upgraded to Sonoma ) |
14:52 | |
| vrurg | Yet, when I was running the the script under llvm, when it was crashing it was always the same place and the cause was related to the thread context structure. At the same time, while not been succesfull with the test script, in production I started receiving error reports related to threads. | ||
| Something like: "MoarVM panic: Internal error: invalid thread ID -99855152 in GC work pass" | |||
| There is one contaminant though which makes the experiment results non-trustworthy: both local tests and the production are currently using my patch for hash protection. Though it does nothing about memory management, but it disables speshing of hashes and slurpy named arguments and that could affect memory structure. | 14:56 | ||
| [Coke] setup some azure infra to test rakudo a few months ago and has been paying 5 bucks a month since then without using it. | 15:09 | ||
| (after the first time) | 15:10 | ||
| Geth | roast: e856674057 | (Elizabeth Mattijsen)++ | fudgeandrun Use RAKULIB instead of to be deprecated PERL6LIB |
15:12 | |
| vrurg | lizmat: BTW, rakudo and rakudo-m are different on my side too. | 15:15 | |
| lizmat | interesting I wonder what the difference is | 15:16 | |
| vrurg | It looks like the difference is in static executable path string only. | 15:18 | |
| lizmat | what tool did you use to figure that out ? | ||
| vrurg | Otherwise both are been compiled identically. | ||
| VIM and that optical things on my head. ;) | 15:19 | ||
| lizmat | ah... ok :-) | ||
| good to hear you have still both :-) | |||
| vrurg | Makefile entries are basically the same with the exception of -DSTATIC.... | ||
| vrurg is kicking the wood three time | 15:20 | ||
| *times | |||
| lizmat | hehe :-) | ||
| vrurg | Normally people knock the wood, but kicking it should be more reliable...... | 15:21 | |
| lizmat | argh... now I have a case again where install/bin/rakudo crashes, but install/bin/rakudo-m works :-( | ||
| the values after /usr/lib/dyld differ | 15:23 | ||
| vrurg | This could be due to different alignments in memory. The extra two bytes in the static string could (and likely to) result in other structures being shifted. So, if a wrong/double freed pointer is used, it may point to a different and, perhaps, safer location. | 15:24 | |
| I had nearly 100% reproducible problem with %!mro on Metamodel::C3MRO. And then the next hour it's gone like it never was there. | 15:26 | ||
| lizmat | changed the raku symlink to point to rakudo-m | 15:27 | |
|
15:29
MasterDukeMobile joined
|
|||
| Geth | rakudo/main: 47fdc20d73 | (Elizabeth Mattijsen)++ | 4 files Deprecate the use of PERL6LIB - mark PERL6LIB as deprecated in help message - add support for environment variables in deprecation message generation - add deprecation if PERL6LIB seen and used - adapt harness to use RAKULIB instead of PERL6LIB |
15:30 | |
| MasterDukeMobile | Might want to try setting MVM_HASH_RANDOMIZE to 0 when building MoarVM to help with reproducibility | ||
| github.com/MoarVM/MoarVM/blob/c3fe...oar.h#L158 | |||
| lizmat | ah, that's not a environment var :-( | 15:31 | |
| vrurg | [Coke]: speaking of the subscription, I regularly get an ad about app that tracks your subscriptions and lets cancel unused ones. A few years ago I started understanding their selling point... :) | 15:33 | |
| MasterDukeMobile: a thing to try, but I don't think now hashes are related. | 15:34 | ||
| Wish it was possible to use rust for MoarVM... But... | 15:35 | ||
|
15:41
MasterDukeMobile left
|
|||
| nemokosch | But? What holds back? | 15:54 | |
| Officially, the main reason for using vanilla C for MoarVM was accessibility. Now, MoarVM is absolutely not accessible anyway. | |||
| vrurg | nemokosch: would you volunteer for rewriting all that C code? | 15:56 | |
| nemokosch | why "all that"? You just said "wish it was possible to use Rust" | 16:01 | |
| What holds you back? No need to rewrite anything, just inter-operate. | |||
| (also, why "would you rewrite" when I just said that MoarVM is anything but accessible) | 16:02 | ||
| I just wish we could see the alternative story line where AlexDaniel is kept over a certain somebody who ran off anyway | 16:05 | ||
| lizmat | that somebody put in more hours than you have ever worked | 16:18 | |
| anywhere in your life | |||
| nemokosch | and got more acknowledgement for it than ever deserved | 16:22 | |
| it's one thing that meritocracy is going out of fashion - especially when it's about the merits of somebody like AlexDaniel who had to cope with the quality of Rakudo for years as a release manager | 16:23 | ||
| but this isn't even proper meritocracy, this is more like nepotism | |||
|
16:24
ChanServ sets mode: +o lizmat
|
|||
| it's arguable if his behavior was better at all than Alex's behavior, with all the moody Github blocks in a community project - but he was "one of us", right? he was the wise guy that these few selected people happened to like more | 16:25 | ||
| lizmat | no, it's not arguable | 16:26 | |
| nemokosch | that he ended up running off without leaving a proper state for the project behind, effectively sending those "hours put in" to the graveyard, who cares, right? | ||
| ironically enough, AlexDaniel did more for this project as a complete outcast than the praised architect | 16:27 | ||
| ever since | |||
| lizmat | now, not diminishing AlexDaniels work, that's not true | 16:28 | |
| nemokosch | people make mistakes but it's very alarming that you still arent' willing to even acknowledge this | ||
| that's the burden in the way of progressing | |||
| no single person's hobby project should be depended upon as much as it happened with whatever Jonathan Worthington came up with | 16:29 | ||
| lizmat | *sigh* | 16:30 | |
|
16:30
discord-raku-bot joined
|
|||
| nemokosch | not without making sure the person will be dedicated enough to not run off without any sense of responsibility for the remains left behind | 16:30 | |
|
16:30
discord-raku-bot joined
|
|||
| Ironically enough, you are the person who literally financed the creation of the only proper materials related to NQP and low-level Rakudo, and that was like 10 years ago. Should be telling enough for whom it mattered. | 16:36 | ||
| lizmat | that was not the only thing that cost me money | 16:37 | |
| nemokosch | I didn't mean to imply that anyway. I meant to say that the only time Jonathan dedicated any sufficient effort into making his own stuff (that was meant for a community project or something) accessible was when he was literally paid for it. | 16:39 | |
| Which frankly makes the whole comparison unfair because I think barely anybody else was ever paid for doing Raku stuff | 16:40 | ||
| lizmat | that's simply untrue and now I have enough of it | ||
|
16:40
lizmat sets mode: +b *!~discord-r@2001:19f0:c:d0d:5400:4ff:fe47:9405
|
|||
| lizmat | sorry people here, but it is impossible to block specific people on the bridge | 16:43 | |
|
16:49
Nemokosch joined
|
|||
| Nemokosch | I don't think it's appropriate anyway to act this much on your own. | 16:49 | |
| lizmat | well, that's your opinion | 16:51 | |
| I'll gladly pass on some of my chores to other people, such as writing the weekly | |||
| Nemokosch | That's the opinion of any well-governed project | 16:52 | |
| It's not a sufficient reason to moderate that you personally don't like to hear something | |||
| lizmat | that's your opinion again | 16:53 | |
| the ban reason is "Your behavior is not conducive to the desired environment" | |||
| and that you are not | |||
| Nemokosch | Well, would you seriously say that just because you wear a moderator hat, you get to silence others if you don't like to hear what they have to say? | ||
| That sounds totalitarian if anything | 16:54 | ||
| lizmat | don't import your political frustrations into Raku, please | ||
| that you live in a country that is very close to being totalitarian, does not mean that it is happening everywhere | 16:55 | ||
| so please, stop this, and instead of complaining about what other people have or have not done | |||
| do something productive | 16:56 | ||
| if not here, then somewhere else | |||
| Nemokosch | no, and I'd ask you to not deflect my frustration with your despotic behavior as my personal life, that doesn't sound very conductive, either | ||
|
16:56
lizmat sets mode: +b *!~Nemokosch@89.134.26.219
16:57
Nemokosch left
16:59
lizmat sets mode: -b *!~discord-r@2001:19f0:c:d0d:5400:4ff:fe47:9405
|
|||
| Voldenet | Stop the drama, mistakes happened in the past and there's no need to get upset over this IMO | 17:55 | |
| and there's no point arguing over alternate timelines – tricking sand into thinking was a mistake in the first place ;) | 17:58 | ||
| I agree that moarvm could some bits of rust | 18:00 | ||
| s/could/could use/ | |||
|
18:11
notna joined
18:25
patrickb joined
18:42
notna left
18:55
sena_kun joined
|
|||
| nine | Work began on MoarVM on March 31, 2012. Rust first appeared May 15, 2015. How was this even a discussion? | 19:39 | |
| Anyway with crazy crashes like that rr is the weapon of choice. Catch it in there and you have a good chance of fixing it. | 19:41 | ||
| tonyo | can't live in the past. | 19:46 | |
| tellable6 | 2024-01-08T11:41:15Z #raku <tbrowder__> tonyo my pm to you should be visible | ||
| vrurg | nine: Oh, my, I didn't think nobody would check the dates! | 20:11 | |
| Voldenet | Compiling one bit of a code into c-callable library could be a huge win | 20:58 | |
| like recently I've seen micronaut (java framework) using serde instead of jackson in newest versions | 21:13 | ||
| vrurg | Voldenet: if you try googling around, there is at least one post about using Raku as a Nativecall target. | 21:17 | |
| s/Raku/Rust/ | |||
| Voldenet | Yes, but I mean that the moarvm itself could use rust crates for things | 21:18 | |
| not that I'd try desperately to replace libuv with tokio or anything of this magnitude, but | 21:24 | ||
| some of the bigint ops could be rewritten to use rug or malachite for example | 21:26 | ||
| vrurg | Voldenet: what win would it bring in over the ones currently used? Either way, plugging in 3rdparty libs isn't a big deal on its own (though replacing an already used one can be a hard task). What is a big deal is using Rust in the core itself where the most critical memory management issues are likely. I'm afraid, it'd be easier to rewrite the entire VM from scratch. | 21:32 | |
| Voldenet | Most ops need to be written and defined somehow, currently in C | 21:41 | |
| Some ops could be written in pure rust entirely | 21:42 | ||
| which could reduce possible memory management issues in theory | 21:43 | ||
| The point, mostly, would be to simplify the code or use rust implementations of things | 21:45 | ||
| which would improve maintainability as long as rust is alive | |||
| vrurg | Voldenet: there is a thing you don't take into account and it's how much MoarVM code is interlinked internally. This is not flaw in MoarVM design but it's C itself. For example, macros would need to be reflected in both C and Rust code making it necessary to maintain two locations instead of one. And they have to be in sync. | 21:54 | |
| It is the most simple example that came into mind. And I was only tangentially dealing with it. I think MasterDuke or niner can tell you more terrifying stories. ;) | 21:56 | ||
| Voldenet | uhm, maintaining C macros in any other language is fundamentally impossible | 21:58 | |
| vrurg | Perhaps the best example of how hard the task is would be Linux kernel itself. There are a lot of enthusiasts, there are even some money put into the project – and, yet, it took a while until the news popped up about first fragments of Rust incorporated into the source. | ||
| Voldenet: I didn't mean it literally. I just men that, for example, MVM_ROOT macro is heavily used across the source. Rust code would need something like it too. Now, if one changes something in MVM_ROOT for C, it would do the same to MVM_ROOT in Rust. | 22:00 | ||
| Voldenet | I don't believe in forcing rust into the codebases simply because it can be done, there should be a good use case first :) | ||
| vrurg | Oh, my: "they would have to do the same in Rust" | 22:01 | |
| ugexe | it could look better on a future resume than C | ||
| vrurg | We all must admit that COBOL looks great in some resumes novadays... | 22:02 | |
| ugexe | the paycheck looks great I'm sure but i dunno how much juice it'd give a resume for any shop that does not use COBOL | 22:03 | |
| Voldenet | COBOL on most resumes looks scary | 22:04 | |
| vrurg is off to preparing another line in the resume... | 22:05 | ||
| Voldenet | what I'm saying is that adopting additional technologies is not bad | 22:07 | |
| theoretically nqp-js could run on deno, so it's already using rust :) | 22:16 | ||
| jdv | peeps used to say "perl will be another cobol, just wait". it never happened. | 22:20 | |
| vrurg | Cobol – 1952, Perl 5 – 1994. We just haven't waited long enough yet. | 22:29 | |
| jdv | ha | 22:34 | |
|
22:41
sena_kun left
|
|||