releasable6 | Next release in ≈6 days and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 03:00 | |
timo | patrickb: "syscall" would probably be preferred nowadays | 06:08 | |
Geth | rakudo/main: b27e2d0772 | (Elizabeth Mattijsen)++ | src/core.c/REPL.rakumod Make REPL message for missing editor more clear Also make it more readable generally by using the naive word wrapper. Inspired by gursoy.social/@burak/113324561499675000 |
09:53 | |
10:25
nine left,
nine joined
|
|||
Geth | rakudo/main: 4c046d45fa | (Elizabeth Mattijsen)++ | src/core.c/REPL.rakumod Seamlessly wrap the "rlwrap" readline wrapper in the REPL If none of the Raku line editors is installed, but the `rlwrap` program *is* installed, then just run that from within raku instead of telling the user to have to wrap it themselves. |
10:44 | |
ab5tract | happy to see the `rlwrap` addition here | 10:59 | |
lizmat | too bad it isn't installed by default on Linux (at least on Debian I'm told) | 11:00 | |
ab5tract | I'm curious though: is it for licensing reasons that we don't ship linenoise as a 3rdparty lib in moar? | ||
lizmat: probably not on macos either, I would imagine | 11:01 | ||
timo | we can make it a suggested package on debian, or actually a dependency if we like. | ||
ab5tract | Having a repl that can withstand backspaces seems like it should be a must-have to me :) | 11:02 | |
timo | it's true. we can also make linenoise or readline a dependency instead of rlwrap | 11:03 | |
i'm not exactly sure if we can just say "either raku-linenoise or raku-readline or rlwrap, but definitely one of those" in the control file | |||
ab5tract | I'm thinking of something that is pulled into the moar source tree | 11:04 | |
timo | right | ||
but moar rather than rakudo? | |||
ab5tract | yeah, as I don't expect either of the nativecall packages actually work with JVM anyway | 11:05 | |
meaning that solving it there would be a different mission anyway | |||
timo | oh? i would have thought they work | ||
ab5tract | it's worth checking. but unfortunately none of the repl fix packages seem to install cleanly on macos atm anyway | 11:06 | |
at least for me, though I think I'm somehow still suffering from the wrong-arch-from-rakubrew issue that has been fixed and which I thought I had updated to | 11:07 | ||
also, I was under the impression the third option was a Raku-native solution without NativeCall, but I seem to be wrong about that | 11:08 | ||
timo | no, unfortunately not. though i seem to recall someone worked on an interactive line editor of some kind in a pure-raku impl? | 11:10 | |
presumably something is in Terminal::UI that handles line editing | |||
ab5tract | `Escape sequences are parsed by Terminal::ANSI::parse-input` (git.sr.ht/~bduggan/raku-terminal-u...t.rakumod) | 11:13 | |
Maybe this deserves a problem solving discussion... | 11:14 | ||
In theory and practice, `Terminal::ANSI` is stable enough that including it as a core module shouldn't be an issue... | 11:15 | ||
then at least we could have working delete and arrow keys, with I think would get us a good amount of the coverage for what the repl-fix packages are used for | 11:17 | ||
timo | right, will we also have to come up with history file handling on our own and other stuff like that? | 11:20 | |
ab5tract | hmm, that's a fair question.. I'd like to see the repl infrastucture shipping in a way that makes ecosystem extension of it trivial. | 11:28 | |
timo | right, make it all reachable and discoverable from just the "rakudo" command, ideally with a completely negligible overhead when you're calling a program rather than going into interactive mode, etc etc | 11:29 | |
ab5tract | in terms of "must-haves", I feel significantly less emphatic about history files. Not sure what else the readline/linenoise families provide.. but being able to open a repl with a freshly compiled rakudo and erase a character or move back and forth across an incantation I'm composing would be 🤌 | 11:31 | |
Geth | roast: 59df1a901b | (Elizabeth Mattijsen)++ | S06-other/introspection.t Add tests for #4730 leont++ for providing github.com/Raku/roast/pull/835 |
11:37 | |
¦ rakudo: lizmat self-unassigned Various methods in CompUnit::RepositoryRegistry are not thread safe github.com/rakudo/rakudo/issues/4737 | 11:39 | ||
timo | yes, backspace and left/right arrow keys are absolutely essential | 11:53 | |
not having them is absolutely infuriating | |||
Geth | rakudo/main: 5753baf2a0 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest Add tests for #4757 |
11:58 | |
rakudo/main: ab40807631 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest Add tests for #4797 |
12:24 | ||
[Coke] | I use Terminal::LineEditor on macos, which is mostly fine | 14:57 | |
ab5tract | It’s really not acceptable to me that we require a third party module (installable via a package manager we don’t include) in order to have even the most basic of interactions in the repl | 14:58 | |
At the very least we could prevent emitting control codes, since they can’t even be deleted after they are produced | 14:59 | ||
16:30
coleman left,
coleman joined
|
|||
lizmat | fwiw, now with "rlwrap" installed, it works also like a charm without needing zef | 16:44 | |
16:45
coleman left,
coleman joined
|
|||
Geth | rakudo/main: 0649fcc55a | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest Add test for #4847 |
17:43 | |
lizmat | ok, this is weird: | 18:20 | |
zef install 'Hash::Merge:ver<2.0.0>:auth<github:scriptkitties>:api<2>' fails with: Failed to find dependencies: Hash::Merge:ver<2.0.0+>:auth<github:scriptkitties>:api<2> | 18:21 | ||
however: zef install Hash::Merge will install ===> Installing: Hash::Merge:ver<2.0.0>:auth<github:scriptkitties>:api<2> | |||
oops, the error is a pasto, it was: No candidates found matching identity: Hash::Merge:ver<2.0.0>:auth<github:scriptkitties>:api<2> | 18:22 | ||
patrickb | ab5tract, Timo, [Coke]: There is a REPL frontend using Terminal-LineEditor (github.com/rakudo/rakudo/blob/main...mod#L103). As soon as this PR (github.com/japhb/Terminal-LineEditor/pull/6) is merged, that frontend is completely free of native code. | 18:23 | |
[Coke] | japhb: ^^ | ||
patrickb | I'd prefer us promoting a raku code only REPL solution over a solution requiring us to add more C code to Moar or require external dependencies. | ||
lizmat | well, "zef" is an external dependency :-) | 18:24 | |
patrickb | We need to add something to gain line editing abilities. I'd prefer us bundling more raku code to bundling more c code. | 18:25 | |
For bundling raku code we could either add the code to Rakudo core, or bundle the modules in all the different raku install packages we provide (that's what I'd do). | 18:26 | ||
I also support bundling zef by default. | |||
The binary archives on rakudo.org do so, rakudo-pkg does so as well. | 18:27 | ||
coleman | I am a fan of rlwrap as a standalone tool, but I do agree with pabrickb approach in this case | 18:28 | |
patrickb, even | 18:29 | ||
them too | |||
patrickb | Distros usually like having separate packages for separate things. So I guess the most conformant way would be to have a separate zef distro package and a separate Terminallineeditor package. Then let dependencies and suggestions do their magic. | 18:31 | |
Geth | rakudo/main: b5c3607504 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest Add tests for #4904 |
18:32 | |
lizmat | afk& | 18:34 | |
patrickb | In general I oppose bundling many modules by default, as I'd rather encourage users to learn using a module manager. | 18:37 | |
timo | in debian we have zef as a package, and a couple of modules are packaged as well | 18:38 | |
ab5tract | patrickb: not everyone is running a Linux distro | 18:40 | |
coleman | Line editing is an interesting case, though. It's a table-stakes modern feature that also has quite low-level concerns (terminals). | ||
ab5tract | it feels downrigh | ||
it feels downright amateurish to pass escape sequences through unhandled in your default repl | |||
we ship the entire unicode database but we can't be bothered to include a small lookup table of ANSI codes? | 18:42 | ||
coleman | Also it is worth mentioning that I expect this area (terminal protocols, escapes) to become a bit more diverse in the next decade. I use Kitty, and it is not in the default terminfo db, so I hit bugs a lot. | ||
ab5tract | that's what I ask myself every time I am face to face with it | ||
lizmat | .oO( PRs welcome! ) |
||
ab5tract | lizmat: this is the discussion phase. it doesn't make sense to start in on an MR that | 18:43 | |
will face objections | |||
or that is to say, I'd rather work on an approach that has a high chance of being accepted | |||
coleman | (to be clear I hit bugs logging in w/ ssh) | ||
patrickb | But there is a minimal set of modules that I'd support bundling by default. Amongst them zef and a line editor. I'm undecided if I'd want to bundle an SSL lib or not. | 18:44 | |
lizmat | having line editing support out of the box would be nice, also for the "repl" function | ||
patrickb | ab5tract: Our Windows packages all bundle zef. I'm willing to also add Terminal-Line-Editor to the mix. | 18:45 | |
ab5tract: Ah, I think I get now what you were referring to with "not everyone is using Linux". I did only mean Linux stuff when I wrote about distros. On Windows I'd just provide a single installer that bundles that minimal set of modules. Our current Win installer already bundles zef, I'm leaning towards adding a line editing solution to the mix. | 18:48 | ||
ab5tract | Terminal::LineEditor doesn't install cleanly for me on macOS, unfortunately: gist.githubusercontent.com/ab5trac...9a/sad.txt | 18:51 | |
I think my preferred approach would be to add whatever hooks to core/vms that make sense in support of exposing sensible and easy to extend hooks into the REPL process | 18:52 | ||
and then include a basic-ish starter extension module in core | 18:53 | ||
patrickb | ab5tract: That issue you are hitting is solved by the above mentioned PR. | 18:54 | |
ab5tract: I know too little about the escape code issue you were mentioning. If you find the time, I'd value some more elaboration on that issue. | 18:55 | ||
ab5tract | patrickb: Ah! I misseed that message, sorry | ||
patrickb | I have to leave now though. But I'll definitely backlog... | ||
'night / UGT everyone. o/ | 18:56 | ||
coleman | night, and thanks <3 | ||
ab5tract | cheers patrickb! | 18:57 | |
That PR totally explains why I was thinking Terminal::LineEditor didn’t have native dependencies:) | 19:01 | ||
japhb rezzes in from the background noise | 21:50 | ||
[Coke]: Thanks for pointing out this discussion. Going to take a look at patrickb's PR now. | 21:51 | ||
22:25
sena_kun left
|
|||
releasable6 | Next release in ≈5 days and ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 23:00 | |
ab5tract | japhb! nice to see you | 23:13 | |
japhb | ab5tract: Right back atcha! :-) | 23:27 | |
Aside from discussions about line editing, what have you been up to? | 23:28 | ||
Terminal::ANSIParser 0.0.4 released with patrickb | 23:42 | ||
's PR for OSC/BEL support | |||
On to the next PR |