00:08 librasteve_ left 00:14 dg left 00:21 dg joined 01:03 LainExperiments joined 01:26 LainExperiments left 01:31 LainExperiments joined 01:43 Chanakan5591 left 01:46 Chanakan joined 01:55 uniro left 02:02 LainExperiments left
coleman timo: on servers where I have root, I install the a kitty-terminfo package. On servers where I don't, I just use something besides kitty if I need full-screen programs :) 02:02
02:07 thowe left 02:08 thowe joined 02:09 Xliff left 02:52 kylese left 02:53 hulk joined
ab5tract timo: "a completely new protocol that does away with the legacy cruft? :D" I've linked to this new protocol several times already ;) 02:54
but one more time for posterity: codeberg.org/dnkl/foot/pulls/875 (XTGETCAP) 02:56
03:15 hulk left, kylese joined 04:13 holyghost left 04:33 esh left 04:43 esh joined 05:05 Aedil joined 06:13 guifa left 07:08 merp left 07:34 cm_ joined 07:35 cm left, cm_ is now known as cm 07:38 Sgeo left
patrickb ab5tract: I think I don't yet understand the reasoning for why it makes sense to have an ANSI escapes DB in core. (In contrast to having an ecosystem module or not having a centralized store at all.) Can you elaborate a bit on that? 08:03
08:56 uniro joined 08:59 uniro is now known as Manifest0 09:15 dakkar joined 09:20 melezhik joined
melezhik . 09:21
09:23 melezhik91 joined, melezhik91 is now known as melezhik_
melezhik_ not sure if someone finds this interesting but there is pitchout service to showcase your OpenSource projects , I put my there - www.pitchhut.com/project/proj_ZBJqXJduM1dI 09:24
09:25 melezhik left
melezhik_ imo markdown renders pretty well on their site 09:25
09:30 melezhik_ left 09:42 sena_kun joined
lizmat weekly: github.com/renormalist/raku-diary#...2024-11-07 09:54
notable6 lizmat, Noted! (weekly)
10:07 sena_kun left 11:27 El_Che left 11:29 El_Che joined 12:07 nine left, nine joined 12:11 apac joined
ab5tract patrickb: because I think it’s crazy that we ship a repl that can’t handle backspaces 13:05
I’ve ranted on this relatively extensively before
In my opinion all of the building blocks for an extensive line editor should already be available 13:08
It doesn’t need all the bells and whistles (history files, etc) but a user should not be prompted to install a third party module — via a mechanism we do not provide — in order to be able to move a cursor left or right 13:10
[Coke] Would be great to have something basic built in, for sure 13:14
patrickb We could bundle Terminal-LineEditor. 13:15
ab5tract patrickb: that has a lot of dependencies itself
One of which is Terminal::ANSI, so why not include it in core? 13:16
patrickb When we want to have it directly in core, I'd like to not expose parts of it.
ab5tract Which parts? 13:17
patrickb The escape sequence DB
ab5tract A) that’s the part I’m putting in NQP, B) why shouldn’t a user have access to those commands? 13:18
patrickb Such a DB is difficult to get exhaustive, and in some ways often changing. You would end up with some support from the core but a fuller thing in the ecosystem. That feels unclean.
ab5tract There are no changes to the ANSI escape sequences as far as I know 13:19
[Coke] we don't want to end up with dual-life modules if we can avoid it.
patrickb And we'll be locked in to this. We can't say that we don't want to provide this anymore.
[Coke] (just recalling headaches from maintenance there from long ago p5 days)
if it's an NQP module internally, that's fine; we already say the NQP interface isn't for users. 13:20
ab5tract The interface is wrapped around semantic concepts anyway 13:21
patrickb And if we're only using it for the built in REPL experience, then we don't need a full DB, only the bits we require for the line editor.
ab5tract patrickb: I don’t understand. I’m not talking about shipping termpcap
There is no such thing as tracking changes to a long frozen ANSI standard. It’s not a thing 13:22
patrickb But then we want sixel support. 13:24
ab5tract patrickb: says who?
In my opinion adding third party sixel support would be the equivalent of creating Ordered::Hash 13:26
patrickb I just mean to say that the DB is expected to evolve because the number of features we could possibly support is large.
ab5tract It’s not messy to extend core functionalities if the interfaces are clean
patrickb: I 100% disagree
We ship ANSI, you get ANSI, install zef for something fancy:) 13:27
It would probably make the sixel support easier because all of the basic escape sequences are available, making it straightforward to just add the new sixel subset 13:28
IMO it would also make sense to also provide XTGETCAP support, then you have the advantage that the terminal emulator itself will feed you all of its escape sequences at runtime 13:30
Without any of the hassle you are describing 13:31
But for now the ANSI codes have everything you need to build up something like Termjnal::LineEditor… 13:32
patrickb I think I'm in general hesitant to put logic into the core that could live in the eco system as well. It's easy to put stuff in but basically impossible to take stuff out. 13:34
I fear we end up with a bloated core with lots of functionality that's little maintained, but can't be removed and most people using the better maintained eco system modules. 13:35
ab5tract If we ship Terminal::LineEditor , we would ship Terminal::ANSI and the db would be even more generally exposed to users than what I have in mind 13:37
I hear your concerns. I just don’t agree that there is a cause for concern relative to maintenance on a set of escapes that by definition are not going to change 13:39
patrickb If we just bundle T:LE with our packages, it's no different from installing it manually. It's not part of core and we could just stop bundling it without much issue. 13:40
ab5tract Or (in the case of XTGETCAP) a protocol that eliminates any need for maintenance
In the end I don’t mind us bundling this but I find our approach to the REPL sub-par. We don’t provide useful hooks for writing extensions. I would prefer that core offer such things 13:43
But there is no point in working on extension hooks at the core level if those hooks require a third party module
Better to just write an entirely new third party REPL at that point. Which just feels really sad to me 13:45
patrickb I think I start to understand your perspective. 13:49
I'll need some time to think about this.
ab5tract patrickb: thank you for your time and consideration on this, I really appreciate it! 13:50
patrickb Thanks for explaining! 13:51
13:53 apac left
timo ab5tract: cool i hadn't heard of XTGETCAP before, that's not bad 13:59
ab5tract Yeah, it Just Makes Sense. But unfortunately it feels a just a wee bit under-documented 14:02
14:09 apac joined
timo huh, literally only two internet search results somehow. that seems wrong? 14:11
is there some page somewhere that would tell me what terminal emulators support xtgetcap? 14:21
oh it's gettcap not getcap?
that gives me some more results at least, including the explanation in the xterm control sequences page 14:23
ab5tract Oops yeah my bad! 14:28
timo testing out escape sequences is always annoying :D 14:40
m: my @queried = <TN Co RGB>; my $blop = @queried.map(*.ords.fmt("%2x", "")).join(";"); my $stuff = "\x90+q{$blop}\x9c"; say $stuff.raku; prompt($stuff).raku.say 14:42
camelia "\x[90]+q544e;436f;524742\x[9C]"
+q544e;436f;524742"»Wann treffen wir drei wieder zusamm?«"
timo i probably missed something, but i think this should be correct though? DCS is 0x90, ST is 0x9c, Pt is the string turned into hexadecimal ascii letters/digits, DCS + q Pt ST is gettcap 14:43
or do i have to use the escape + letter versions because uppermost bit shenanigans? 14:44
m: my @queried = <TN Co RGB>; my $blop = @queried.map(*.ords.fmt("%2x", "")).join(";"); my $stuff = "\x1bP+q{$blop}\x1b\\"; say $stuff.raku; prompt($stuff).raku.say 14:45
camelia "\x[1B]P+q544e;436f;524742\x[1B]\\"
P+q544e;436f;524742\"»Wann treffen wir drei wieder zusamm?«"
timo then i think this should be correct??
(obviously with camelia you wouldn't get a response from the ansi escape codes) 14:47
14:48 holyghost joined
timo aha! kitty responds with something. xterm didn't, though 14:49
patrickb I must admit that I don't entirely understand the benefit of xtgettcap. IIUC it allows me to work with terminfo names instead of VT names. Are the terminfo names somehow better? 15:03
timo the benefit is that you don't have to have access to the database
essentially, whatever terminal emulator you may be writing to and reading from will do the database lookup for you
so crucially, no need to call a program like tput, or NativeCall into a library like curses, and also crucially, it works if you're connected to a terminal emulator through one or more layers of ssh 15:04
patrickb But alternatively I could just use raw VT sequences directly (assuming terminals are standardized enough so I can get by). 15:08
And I suspect that if I don't trail off into the darker corners of the VT sequences space and am a bit careful I should be able to get by. 15:09
timo right. there's some common subset of sequences that you can target
i am absolutely not sure what is and isn't safe to use, though 15:10
surely people in the past have already investigated this exact question, though
patrickb If I use XTGETTCAP exclusively I can only target terminals that support it. 15:11
timo you can send it and wait a fraction of a second for a response or no response. which of course isn't optimal either :)
patrickb Looking at the terminal emulator space from high above I seem to perceive a dynamic where the TEs push to support as many escape sequences as possible for back compat with different apps (probably motivated by Microsofts Terminal entering the ring). 15:13
Given the big push in a direction where there is at least a minimal standard of VT sequences supported by most emulators, it feels strange to still go through terminfo. 15:14
timo i guess it's more interesting for editors because of the clipboard management sequences, and those are not universally supported apparently? 15:16
patrickb So a good direction to go in for the Raku Terminal space could be to use raw VT sequences directly everywhere. Along the way we'll find out what works and what doesn't. (Actually the number of different sequences we use is quite small actually. T-P uses like 10 different ones.) 15:21
15:22 apac left
patrickb Independently we can explore XTGETTCAP and how well that is supported. The two approaches are pretty much orthogonal. 15:22
timo oooh colored underline! 15:25
15:27 apac joined
timo i love them! double! curly! dotted! dashed! supported in Konsole as well! 15:28
antononcube .seen bscan 15:31
tellable6 antononcube, I saw bscan 2024-09-30T14:58:06Z in #raku: <bscan> In the Raku language server, it uses a custom rakudoc parser written in typescript to show module documentation on hover. Although I wonder if that should be updated to use rakudoc instead.
15:31 Sgeo joined 15:46 apac left
antononcube @bscan How easy do you tthink it is to make or re-purpose the VS Code Raku plugin for JupyterLab? github.com/jupyterlab/jupyterlab-desktop 15:51
timo Konsole has some kind of bug with underline colors where if you print changes to the underline color too fast they result in wrong colors? 15:56
TIL "setup semantic hints" / "show semantic hints" in Konsole 16:14
sorry, "semantic integration"*
docs.kde.org/stable5/en/konsole/ko...ation.html 16:15
ab5tract patrickb: what do you mean by “raw VT sequence”? 16:21
timo i'm assuming "literally putting the sequence in a string in our source code" 16:23
patrickb The text sequence that's actually sent to the terminal. e.g. "\e[1A"
timo but in particular "not asking the database on the end-user's machine" right? 16:24
patrickb Yes. Skip the database assuming I can rely on the standard and thus have the sequences directly in the code. 16:25
bscan I'm not sure. The Raku plug-in has two key components: syntax highlighting and the language server. Looks like Jupyterlab has an extension for lsp, but doesnt support the same type of highlighting 16:28
antononcube Thanks! I browsed the documentation in order to find how a "new" language is added, but gave up quickly. 16:30
timo if we allow plugins for the rakudo built-in repl, a module that turns on konsole semantic integration for it could be built; i'll check if the semantic integration in konsole is compatible with the one in the vscode terminal as well
antononcube That would be nice. 16:31
ab5tract patrickb: I’m confused by that because I’ve never seen a terminal control sequence that doesn’t look like a “raw VT sequence” 16:33
timo maybe those actually come from FinalTerm
> iTerm2, kitty, Windows Terminal and the VS Code integrated terminal can use FTCS sequences for better shell integration and showing marks next to commands. 16:34
ab5tract If you look at Terminal::ANSI or my branch with NQPTerminal, there is no “database” per se. It just implements the ANSI standard variety of control sequences. These should be more or less universally supported and I agree with your proposal to migrate Terminal::Print off of a tput-based “dynamic-in-theory-but-functionally-static” approach 16:37
timo github.com/microsoft/terminal/issues/11000 has a boatload of text about among other things "semantic integration" / "shell integration" / marking prompts, inputs, and outputs 16:38
ab5tract timo: ah, that’s interesting indeed. 16:39
timo i'll hack up a prototype quickly 16:40
16:43 apac joined
librasteve timo: you can run the raku repl in a raku Proc iiuc 16:44
docs.raku.org/routine/repl 16:45
ab5tract timo: not sure which layer you are going to hack on but feel free to embrace / extend / extinguish my nqp branch: github.com/Raku/nqp
Dang, the link doesn’t include the branch (“nqpterminal”) 16:46
timo thanks librasteve, i'm doing exactly that, so i don't have to recompile rakudo's core setting for each attempt 16:47
now i'm wondering why this method is called interactive_prompt when everything else in the class has dashes instead of underscores %)
probably hysterical raisins
jdv loves hysterical raisins 16:51
timo it's not working so good haha 16:53
ab5tract Might need to be combined with the PTY work?
timo i think i was getting screwed over by the "re-execute rakudo with rlwrap" feature when i didn't expect it 16:59
patrickb ab5tract: I think we agree. It was a bad wording on my side. The "raw" in "raw VT sequence" is redundant. I guess the important bit I wanted to communicate is to not pull the sequence to use from some external database. 17:00
timo we should probably Not Do That when the repl is invoked through the repl sub in user code
ab5tract patrickb: got it. Sounds like we are indeed on the same page now more or less! 17:01
timo: you mean PTY? You are probably right, but if you are using repl() primarily for ease of debugging your prototype… 17:02
Also, it seems like “spawn repl with a dedicated PTY” seems like a good example for a simple repl plugin 17:04
Anyway, I’ll leave you to it :)
timo is the repl sub not part of the rakudo language? i would expect people to perhaps want to just put "repl()" in their code to debug also. and if no line editor is found, but rlwrap is installed, then rakudo will just cheekily re-exec, leaving the user possibly very confused 17:12
well, not "re-exec", more "run itself and exit afterwards"
17:17 apac left
timo storage.aperture-labs.org/s/5DXP2JGgBqkg4Rz 17:18
ab5tract Yes, I’m only saying that you could hack in using Proc::PTY if it enables your debugging (I honestly don’t know if it would, I was only spitballing) 17:19
That wouldn’t have to be added into any final MR
timo in this case it wouldn't have helped; the problem was that my MyREPL changes were simply disappearing because the repl i was looking at was in a fresh process with none of my code in it at all 17:20
ab5tract Ah, I see
timo anyway, i turned on "alternate background color" and "red background for errors" in that video 17:21
if i had one of the line editor modules installed, I would also get "click in input line to move cursor there" support, I believe. 17:23
there's still something missing; when there was output from a command, then neither repl-print, nor anything else is called, so I can't output a FTCS_COMMAND_FINISHED unless i want to output it before the prompt, which i don't think is very clean? 17:24
env INSIDE_EMACS=1 rakudo -e 'use MONKEY; role MyREPL { method interactive_prompt($index) { "\e]133;A\e\\[$index] > \e]133;B\e\\" }; method repl-read($prompt) { LEAVE print "\e]133;C\e\\"; callsame }; method repl-print(Mu \value) { LEAVE { if value ~~ Exception { print "\e]133;D;1\e\\"; } else { print "\e]133;D\e\\"; } }; callsame } }; sub myrepl(*%_) { my $repl = REPL.new(nqp::getcomp("Raku"), %_, 17:26
True) but MyREPL; }; myrepl.repl-loop(:no-exit);'
here's the commandline for you to try. it was just a tiny bit too long for IRC
lizmat timo: I thought I inhibited that? the sub repl will *not* reinvoke with rlwrap wrapped afaik 17:27
hmmmm I guess it does :-( 17:28
ab5tract That video is not loading on my phone for some reason . I’ll have to check it out later
timo lizmat: it seems to do that when you use -e for your code and call repl from the -e code 17:29
since then rakudo wouldn't be wrapped in rlwrap yet, since it wasn't a repl "before"
lizmat agree, that needs to be fixed... 17:31
maybe remove that functionality altogether
ab5tract If we add the right stuff to core, it won’t be necessary
lizmat I mean the auto-wrapping rlwrap
right
17:34 dakkar left
timo so my results from this little experiments are mostly that REPL is not very friendly to being extended by hand? 17:35
if you subclass REPL, your methods will likely be stomped over by do-mixin, if you augment class REPL, you can't replace the methods (or is there some syntax i missed that makes it possible?), but applying a role to the return value of REPL.new works in a pinch 17:36
but the REPL class would be friendlier to augment with a whole bunch of hooks you could put your own code into 17:37
lizmat yeah, it's a bit of a mess, constructed over the years :-)
timo not sure if w ehave any prior art inside of rakudo for things we want the user to be able to change like this
yeah, i don't mean to point fingers or anything
lizmat Date DateTime are subclassable afaik 17:38
timo having %editor-to-mixin is a bit strange, giving "preferential treatment" to a few modules that live in the ecosystem kind of feels icky? 17:39
lizmat indeed, but then how would you transparently handle that ?
also, it feels that the mixin could be avoided if the REPL had an $!editor attribute, on which the API methods would be called 17:40
pretty sure the REPL logic predates the existence of "handles" :-)
timo right, is there something like an "extension point" mechanism for distros? so that we can check inside a CUR (or whatever is more appropriate) for modules inside of distros that claim to provide an implementation of "some kind of feature", like "line editor for rakudo, api version 2" 17:41
if not, maybe we can take some inspiration from python's "user site" and "site" mechanism, where you can basically put a .py file in the right spot and it'll run on startup. that definitely has interactions with precomp and startup performance though, so wouldn't be applicable 1:1 i guess 17:43
japhb ab5tract, timo, lizmat: FYI, patrickb and I have been having additional terminal discussions in #mugs 17:44
Looks like I've got a lot to backlog here as well, wow. 17:45
timo sorry about that :D
lizmat FYI: github.com/rakudo/rakudo/commit/dc03425027
timo i just saw
lizmat oki
did you also see raku.land/zef:raku-community-modul...rVM::Debug ? 17:46
timo yup, i think you might have pinged me
lizmat ack :-)
timo "semantic integration" works a bit funky in different terminal emulators; Konsole offers to type out some bash code for you on a key combo, so that the PS1 is augmented the right way with the escape sequences 17:47
vscode at the start had an "activate semantic integration" button plus a popup that shows up when it thinks you're running bash and doing it would be successful. it then would do something to get that in there, but i'm not sure what exactly it was. it wasn't visible like it is in konsole i don't think 17:48
outputting escape sequences that are not supported by your terminal emulator should be safe, since i think ansi escape sequences can be properly skipped & discarded even if you don't know what any given sequence means 17:51
Comma also has some features for the repl, but i haven't looked in a good while.
i think it's a custom repl runner thingie, not the REPL class from rakudo 17:59
and the "line editor" part of input is handled by comma entirely, which means you have all the IDE features at your fingertips 18:00
18:11 Aedil left
timo ab5tract: i think you accidentally search-replaced sub with method and ended up turning substr into methodstr near the bottom of NQPTerminal.nqp 18:13
18:17 apac joined
timo if we re-imagine the REPL, we may want to have a thought about making it a more "asynchronous" design, too? 18:18
i guess completions-for-line and update-completions aren't that slow 18:21
okay, maybe i'm getting a little too far towards jupyter kernel territory here 18:22
ab5tract timo: well-spotted! 18:26
I was thinking we might use a/some supplies
timo turn it into a Cro Service :D 18:27
ab5tract With the right setup this could make hooking plugins quite elegant
That’s an interesting thought for sure
timo only half-joking; mirroring the "middleware" structure of cro may be at the very least a good bit of inspiration? 18:28
ab5tract Yeah I think so
It’s definitely a sturdy and capable example of a pluggable architecture
timo i really have to be careful not to just plop everything into my idea for the repl that you get from, say a rakudo jupyter kernel + that one TUI frontend to jupyter kernels and notebooks 18:29
ab5tract well, as long as the right infrastructure is provided, the sky is the limit no? 18:52
timo true enough. all just a SMOP :) 18:54
19:26 sjn left 19:28 sjn joined
antononcube Raku made maze using Graph algorithms: 19:32
cdn.discordapp.com/attachments/633...32296&
timo neat 19:44
scullucs Good luck getting out of that one! 🙂 19:48
antononcube Here is a solution from left-bottom to top-right. But, yeah, not out. 19:51
cdn.discordapp.com/attachments/633...0d877&
20:01 tyzef joined 20:13 tyzef left 20:27 Sgeo_ joined, Sgeo left 20:47 Sgeo__ joined, Sgeo_ left 21:07 sena_kun joined 21:16 apac left 21:20 apac joined 21:42 guifa joined 23:01 sena_kun left 23:12 apac 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!