🦋 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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!