ab5tract lizmat++ 00:00
01:59 hulk joined 02:01 kylese left 02:15 hulk left, kylese joined 03:32 leppard left 04:26 wayland left 04:31 wayland joined 04:52 kjp left 04:56 kjp joined 05:51 Sgeo left 06:13 xkr47 left 06:31 xkr47 joined
disbot <melezhik.> lizmat: why do you think mutsu is better ? 06:31
<melezhik.> My view it’s too early to say till one runs this on real code 06:32
<melezhik.> Roast is good , but real user codebase thus what matters to me 06:33
<melezhik.> I am quite satisfied with the state of rakupp now
<melezhik.> Also ash is very responsible and helpful 06:34
<melezhik.> I consider rakupp as the main stack for dsci and sparrow
06:38 hwj joined
disbot <melezhik.> > jvm backend is cool idea, but native interpreter in a lib is a lot better idea imo - same thought . 06:39
06:46 hwj left, hwj joined 06:53 perryprog left, perryprog joined 07:01 xkr47 left 07:02 xkr47 joined 07:38 abraxxa joined, abraxxa left 07:54 wayland left 07:59 abraxxa joined 08:07 vasko45355861 left 08:08 vasko45355861 joined
lizmat melezhik not sure how you got the impression that mutsu is better? Better than what ? 08:10
08:16 belluzj joined
disbot <melezhik.> Oh. Maybe I just misread your recent phrase 08:41
<melezhik.> “as an intro, maybe tokuhirom.github.io/mutsu/ is better” 08:42
<melezhik.> Or did you mean the certain phrasing to present mutsu is better ? 08:43
<melezhik.> Not, like mutsu vs Rakupp is better ?
lizmat the github.io page is more informative than the bare github.com page, is what I was trying to say 08:44
so: tokuhirom.github.io/mutsu/ is a better intro to mutsu than github.com/tokuhirom/mutsu 08:45
08:45 leppard joined, leppard left
disbot <melezhik.> Ok, my apologies then 08:50
08:59 abraxxa left 09:24 belluzj left, belluzj joined
lizmat no need to apologize :-) 09:24
disbot <melezhik.> )) 09:26
09:36 hwj left 09:37 hwj joined 10:06 belluzj left 10:31 belluzj joined 12:15 vasko45355861 left, vasko45355861 joined 12:16 Pixi` joined, belluzj left 12:19 Pixi left 13:22 tinita_ is now known as tinita
ab5tract TIL about mutsu .. that is pretty dang slick! 13:44
btw, there's a Kotlin+Truffle reanimation of the JVM backend cooking in my local repos 13:46
It looks like I'll have to eat my hat.. I always figured we'd end up with only one grape (MoarVM) on the implementation vine
13:59 leppard joined
disbot <antononcube> I assume you have tried it out? 14:02
ab5tract mutsu? just on the website so far 14:23
I'm not sure how Python modules address the multiplicity of Python backeneds but the list of included modules for mutsu is pretty encompassing in terms of complexity 14:24
I don't know why JSON::Tiny would be there though, except as an opportunity to measure the speed of mutsu's grammars vs moarvm 14:27
14:30 timo left
ugexe "mutsu already answers use JSON::Fast / use JSON::Tiny with a native Rust implementation (src/runtime/json.rs" 14:30
github.com/tokuhirom/mutsu/blob/ma...on-tiny.md
ab5tract interesting. I only noticed the JSON::Tiny entry on the list of included modules 14:51
not a new position for me, but to-json/from-json should be included in core (or at the very least brought in via `use JSON`) without deprecation 14:52
this could then simply call nqp::tojson / nqp::fromjson, with any NQP-based backends implementing them with the fastest possible code 14:53
non-NQP-based-backends could ship a divergent JSON.rakumod 14:54
ugexe yeah the only real problem is how to handle the non-standard stuff
like we allow storing versions as v1.2.3 without quotes for example 14:55
a core json parser sort of implies that it would be producing json output other json parsers support, yet we are using non standard json
ab5tract I didn't know that we did such a thing :/ 15:03
that sounds more like an ingestion template/schema/class kind of problem to solve?
"read this field as a version" 15:04
the writer should always stringify
the other side of this is that I would like to have a .rakudata format that could be used to safely serialize/deserialize (no EVAL, no code except stored as a string, no runtime effects of any kind) 15:06
ugexe m: my $repo = CompUnit::RepositoryRegistry.repository-for-name("core"); my $cu = $repo.resolve(CompUnit::DependencySpecification.new(short-name => "Test")); say $cu.distribution.meta<ver>.WHAT 15:08
camelia (Version)
ugexe presumably it was done like this to make some things faster by not having to parse the version from a string multiple times out of the meta data 15:10
the version itself can live as an attribute on some class post-parse to avoid that (CompUnit::Repository::Distribution has such an attribute now) but those details probably didn't come until after the meta data version thing was implemented 15:12
15:16 leppard left 15:20 timo joined
ab5tract Right. I would say this is a candidate for using that theoretical native serialization format 15:27
Alternatively, core could have access to implementation-detail versions that produce / parse this non-standard JSON 15:28
Unless JSON::Fast also does this with versions? 15:29
ugexe yes json::fast also handles versions 15:30
ab5tract Doh :(
ugexe and stuff in the ecosystems consumes meta6.json which may have come from the core like my example
ab5tract Though I do love not having to pre-declare a schema for JSON in Raku, wouldn’t a named arg that takes a class also be a possible solution? 15:31
from-json $raw, :to(VersionedClassMeta)
ugexe its not a huge thing, but there is essentially a prereq of making zef (and other distribution interfacing distributions) not assume a version 15:32
a version object rather
ab5tract Right, gotcha
disbot <antononcube> Well, I tried "mutsu", it works, but I does not let you use or install external (to "mutsu") pakcages. 15:34
ab5tract It says it includes mzef
disbot <antononcube> ... on macOS.
<antononcube> Yeah, I tried to install with mzef -- it does not work. I probably will file an issue. 15:35
<antononcube> For example: tokuhirum/mutsu> ./target/release/mzef list --installed Useless use of () in sink context at ~/GitHub/tokuhirum/mutsu/vendor/zef/lib/Zef/Client.rakumod:672 15:36
16:36 leppard joined
tbrowder howdy, i’m happy to say ChatGPT was able to fix my OLD emacs settings so the perl6/raku Index tool works again. “Hal” also fixed a horrible unicode mapping problem that regularly started running for many minutes at a time while interrupting the editing process. 17:05
lisp may be great language but it sure isn’t friendly to a non-touch typist. 17:13
17:32 hwj left 17:34 abraxxa joined 17:35 abraxxa left 17:37 abraxxa joined
disbot <antononcube> Ideally, Rakupp is going to provide binding for Emacs Lisp. This would make Emacs a great Literate Programming environment for Raku. 17:48
ab5tract I wonder which is less annoying, C bindings for Rust or C bindings for C++ 18:25
disbot <antononcube> I just told Andrew that I am interested in Rakupp bindings for Raku. 19:31
Voldenet I think that overall one has to write C bindings explicitly anyway, doesn't matter if it's rust or cpp 19:37
20:38 hwj joined 20:48 habere-et-disper joined 21:09 habere-et-disper left, hwj left 21:29 mehbark left 21:31 mehbark joined 22:12 vasko453558612 joined 22:20 vasko45355861 left, coleman left, toddr left, Altreus left, summerisle left, jcallen left, zups left, ugexe left, banna left, mtj left, vasko453558612 is now known as vasko45355861 22:24 coleman joined, toddr joined, Altreus joined, summerisle joined, jcallen joined, zups joined, ugexe joined, jcallen left, jcallen_ joined 22:26 banna joined 22:29 mtj joined 22:43 abraxxa left 23:01 Sgeo joined 23:18 sivoais left 23:19 sivoais joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!