japhb [Coke]: Free-handed (and thus untested), but maybe this will help: gist.github.com/japhb/09b54273146e...4dfd8b0677 00:47
[Coke]: If it ends up being buggy, just send me a link to a real overview file and I'll try to fix it. 00:51
[Coke] don't know if it's buggy, but coke/raku-blin-results has a real overview file (though perhaps a little shorter) 01:04
er, coke/raku-blin-release-results 01:06
japhb: Found invalid signals: INT 01:17
(this on an ubuntu box) 01:18
if I just comment out that whenever, runs fine. :)( 01:19
:)
the flash when it redraws is scary. 01:20
doesn't seem to highlight anything.
japhb OK, fixed several bugs using your sample file. 01:41
[Coke]: Grab the latest version of the gist and try again
01:44 hulk joined 01:46 kylese left 02:15 hulk left, kylese joined 05:13 Sgeo left 05:30 hurufu joined 06:32 hurufu left 06:54 hurufu joined 06:57 hurufu left 06:58 hurufu joined 07:09 hurufu left 07:41 hurufu joined 07:44 dakkar joined 09:14 hurufu left 09:24 ptc joined 09:28 ptc left 09:32 dicit joined 10:23 camelia left 10:55 hurufu joined
tbrowder given all these new raku executables, do they all work in the surrounding support system like zef/fez and its huge body of work? 11:12
lizmat most of the installing modules logic is actually part of the core 11:13
what the core does *not* have, is a selection logic for modules: that's zef 11:14
tbrowder can i install all rakus on the same system with no conflict?
lizmat zef just finds out what needs to be installed, and then tells the core to install it
tbrowder ok, thanks
lizmat I think rakupp also installs a "raku" executable, so that *could* be a conflict 11:15
tbrowder hm, i’m happy with rakudo for now, but i know blazing speed is tempting… 11:18
11:56 johnjay left 12:00 johnjay joined 12:01 johnjay left 12:08 johnjay joined 12:10 hurufu left 12:15 hurufu joined
disbot <antononcube> FYI: dev.to/2colours/is-generative-ai-k...-raku-37ai 12:17
<antononcube> It relates to why it is "Raku Weekly News" now. (Not "Rakudo Weekly News",) 12:18
12:21 johnjay left, johnjay joined 12:36 dakkar left, dakkar joined 12:44 dakkar left 12:45 dakkar joined 14:19 Sgeo joined
disbot <antononcube> @lizmat Can trait memoized of "Sub::Memoized" be used for class methods. (I can experiment, and see, but, well, by asking I might find out quicker...) 14:34
[Coke] I think lizmat is on the road right now. 14:53
So in general, yes, but today, nope. :)
16:13 snobber left 16:17 snobber joined 16:31 abraxxa joined 16:35 hurufu left 16:40 hurufu joined 17:05 hurufu left 17:07 hurufu joined 17:10 abraxxa left 17:11 dakkar left
Voldenet re AI are mostly good questions imo 17:17
especially about how authoritative is what rakudo does vs what rakupp/mutsu do 17:18
e.g. should `nqp::bindlexdyn('&*ADD-WHENEVER', &NEW);` or RakuAST be supported by those impls too 17:19
17:20 hurufu left
[Coke] I don't believe anything in nqp is part of the Raku language. 17:22
Voldenet Yes sort of, but what if some very popular module uses nqp 17:23
like JSON::Fast
17:25 abraxxa joined
Voldenet imo there should be attempts to make this more standard in some shape 17:26
[Coke] a motivator to rewrite using only core language features. 17:27
IMO, nqp should be used ONLY in rakudo core.
Voldenet I agree to some degree 17:28
[Coke] Curious how many things in the ecosystem have a 'use nqp' in them
Voldenet but more interesting question would be "why they do use nqp" 17:29
like it'd be great if there would be no performance reasons 17:30
or if all features were available, like `.add_phaser` or `.add-leave-phaser` 17:33
performance reasons are also a lot stricter, e.g. `nqp::add_i($x, $y)` is not `$x + $y` 17:37
ugexe the direction of the language is for raku steering council. developing a compiler does not give anyone authority in directing the language, although practically speaking it puts such a developer in a good position to end up on the raku steering council 17:38
Voldenet I agree, but practically over the years the compiler has dictated what was actually possible, so modules happily used implementation details 17:42
ugexe sure. a lot of people such as myself have been saying that for awhile though. in the end its really up to module authors to think about what they are doing 17:44
Voldenet that doesn't change the fact that one "very incompatibly" dependency ends up with a lot of reverse dependencies
s/incompatibly/incompatible/
evalable6 Use of uninitialized value $_ of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in block <unit> at /tmp/tyrYbRNXhv line 1
Voldenet evalable6: I agree entirely ;p 17:45
evalable6 (exit code 1) ===SORRY!=== Error while compiling /tmp/OFQWDCnIbj
Undeclared routines:
I used at line 1. Did you mean ''?
agree used at line 1. Did you mean 'grep'?
entirely used at line 1
p used at line 1
ugexe in a way it does. authors are responsible for knowing about their dependencies
in other words: i dont see modules happily using implementation details isn't a language level problem. its a module author problem 17:48
s/isn't/as/ 17:49
Voldenet in case of JSON::Fast of course every compiler is somehow able to use `use JSON::Fast;` despite `use nqp; nqp::while(my $i++ < 3, say "foo")` not really working properly 17:50
(obviously, it was re-implemented to mimic the behavior)
since it's used by huge chunk of the ecosystem
what I'm trying to say is that if JSON::Fast could be implemented to work exactly the same (in performance terms) without nqp, it would be reasonable for it to get slight rewrite 17:51
and maybe some sort of low-level `use ops; ops::add_i` should exist for module usage 17:53
[Coke] using nqp or something like ops::add_i is the wrong approach, IMO 17:54
Voldenet while ops would contain only small subset of operations that would get translated to nqp:: ops by rakudo during compilation
[Coke] most of these usages of nqp:: was for speed on a version of the compiler that was probably over 4 years old at this point 17:55
Voldenet I partially agree, especially about things like `nqp::if/while/stmts` 17:57
[Coke] anyone know the replacement for greppable? I thought it was rakkable, but don't see that in here. 17:59
ah, it is rakkable. maybe it's just not logged in right now. 18:10
Voldenet but I still wouldn't know how to do `nqp::bindpos` or do addition on int32 especially 18:12
18:17 rnddim is now known as ShimmerFairy
[Coke] forking json::fast to see how hard it is to update. anyone have a benchmark for it? 18:24
Voldenet m: use Bench; use JSON::Fast; my $r; my $s = <test.json>.IO.slurp; say Bench.new.timeit: 1000, { to-json from-json($s), :!pretty; } # something like this 19:01
evalable6 (exit code 1) ===SORRY!=== Error while compilin…
Voldenet, Full output: gist.github.com/1e50ff5c907f82afad...10e54eb56d
Voldenet ofc test.json can be arbitrarily complex or large
depending on what's useful
Btw, JSON::Fast got its implemented in both mutsu and rakupp already 19:03
ugexe how a JSON::Fast implements something in a compiler agnostic way almost means you can't optimize it at all unless all compilers implement the same optimizations (and even that assumes the optimization implementations are created equal)
Voldenet its versions*
> github.com/tokuhirom/mutsu/blob/ma...N/Fast.pm6 19:04
I don't get it
but it looks like fork working under mutsu only 19:05
not reimplementation
rakupp does this in the meanwhile: github.com/ash/rakupp/blob/main/sr....cpp#L1083 19:08
19:14 jjido joined
japhb Serializer benchmarks: github.com/japhb/App-SerializerPerf 19:18
Updates to test a couple newer serializers as well as the different compilers would be useful, but it should get someone started. 19:19
The reason for using nqp isn't just pure per-op performance, but rather that nqp can express "scopeless" control structures in a way that Raku cannot. 19:21
In addition, there are some single nqp ops that cannot be expressed as a single operation in Raku 19:22
19:23 jjido left
japhb Sufficiently advanced optimizers might be able to solve that last one, but before they get used in place of nqp ops, those optimizations would have to be on all compilers. 19:23
Completely separate topic:
[Coke]: Did the final version of the overview watcher that I sent last night work for you? 19:24
[Coke] Didn't make it back yet, sorry! 19:44
japhb Ah! Do let me know when you do get a chance to try it. :-) 19:46
[Coke] I disagree that use HLL code instead of potentially wrongly optimized NQP is going to force compilers to use the same optimizations. 19:48
*using HLL 19:49
(Different compilers have different optimizations and different speed characteristics seems part of the point) 19:57
"This type (List) does not support elems" whee 20:01
japhb [Coke]: I meant, to give devs of performance-critical modules (like the serialization modules) sufficient reason to convert their existing nqp code back to pure-Raku. 20:03
[Coke] There's an assumption there, that the nqp code is faster. 20:07
and that nqp code was, in all cases, written before the other compilers got here, and before SO MANY changes in rakudo
(which is why I'm doing a conversion of JSON::Fast right now to benchmark it) 20:08
ugexe [Coke]: if you are referring to my comment im talking at the HLL level, e.g. what type of loop should be used. i've always been against using nqp stuff in code (although i do use it in one spot in zef for sha1s) 20:12
20:18 abraxxa left
[Coke] another note: maintainability is improved by moving out of handrolled nqp. 20:21
20:30 Some-body_ joined 20:33 DarthGandalf left 20:34 Some-body_ is now known as DarthGandalf 20:45 jjido joined
[Coke] japhb: can you resend the gist url? 20:52
20:53 Ekho left, Fondue left, Fondue joined 21:30 Ekho joined
[Coke] .seen fco 21:51
tellable6 [Coke], I haven't seen fco around, did you mean cog?
22:04 jjido left
lizmat [Coke]: rakkable only runs on #raku-dev atm 22:29
Voldenet > nqp can express "scopeless" control structures in a way that Raku cannot 22:31
ah, so optimizers should be able to guess it, but they're not forced to 22:32
maybe `could` is the righter word
but if there are low-level ops that aren't in raku (not related to inner workings of moarvm) then maybe they should get exposed somehow 22:38
maybe not via `ops.method`, but not via new operator either, something trivial to translate and unambiguous in compilation time 22:39

Powered by Cro and the Raku® Programming Language.

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

Thank you!