🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
grondilu it's stuck line 381, waiting for a byte. And frankly I don't get why that hangs as it's in a thread. I thought threads cannot hang the main process. 00:11
00:11 stanrifkin_ left
timo did you have a link to the code yet? 00:14
or was it literally the code you had roughly an hour ago here in irc?
+ a use in front 00:15
now that's interesting 00:17
native-descriptor is blocking, waiting for the lock on the file handle to be released
if you just move the `say @dim` before the `leave-raw-mode` you get the output immediately and then you have to press any key to stop the program 00:19
japhb Gah, that's annoying. I've already had to work around the native-descriptor blocking problem in T::W, I didn't realize it would be a problem here too. 00:21
grondilu or put leave-raw-mode in a LEAVE phaser
so it's not me being dumb? it's a bug alright? 00:22
(btw the line is 379, not 381. I added some debug lines.) 00:24
github.com/japhb/Terminal-LineEdit...kumod#L379
timo i am not entirely certain that MVM_io_fileno should be forced to acquire a lock on the file handle
00:25 lichtkind left
timo for sockets it does something a little more complex, but for syncfile and syncsocket it literally just does a member access on the struct 00:27
alternatively, T::LE could just remember the fd number after enter-raw-mode is used 00:28
not sure it makes sense for the number to change between enter and leave
grondilu interestingly I think this is the kind of issue that made me look for a library in the first place. I had tried parsing csi myself but I always ended up blocking sometimes for some reason. 00:31
timo oh, that leave-raw-mode might actually have come from my local changes to T::LE? 00:33
ok, it looks like it doesn't matter
but the issue of the reader thread not being cancellable "from outside" while it's in the read call is something i stumbled upon literally a day ago 00:35
you can query the terminal to respond with something random though, that will get the read call to finish
grondilu hum 00:36
timo or just exit()
grondilu I've tried exit. didn't work well 00:37
timo ah, i guess it didn't exit raw mode?
grondilu yes
timo right, that makes sense
grondilu shouldn't it be possble to send a byte from the main thread? 00:39
timo no, stuff you output aren't echoed back into the stuff you read i don't think
grondilu I've tried $*IN.print(' ') 00:40
didn't work
timo gist.github.com/timo/3be2887bbece1...8496257683 try this patch
are you on linux? 00:41
grondilu yes 00:42
your patch adds a $! twigil to a my variable 00:43
timo rakudo -e '"/proc/self/fd/0".IO.resolve.say; "/proc/self/fd/0".IO.resolve.say;; "/proc/self/fd/0".IO.resolve.say;'
oops, just remove the "my " from there 00:44
grondilu you're right that works.
timo that rakudo command gives "/dev/pts/0" three times
that explains why when you $*IN.print(" ") you won't be able to $*IN.read() and get the space out
$*IN and $*OUT are literally the same file. which means you can also $*OUT.read if you like 00:45
but that only works if your rakudo was invoked by a shell that has a TTY
if you use any kind of input/output redirection, that's no longer guaranteed
grondilu I see. This explains why in Term::termios the author was using 1 as the fd for stdin. This was confusing. 00:46
is your patch a work-around or a real fix? 00:48
timo i'd want japhb to chime in, but i think it's reasonable 00:49
grondilu doesn't look outlandish to save a file descriptor
timo yeah and $.output and $.input are also not "is rw" so you wouldn't expect them to change either 00:51
grondilu you don't have to make it an attribute of the class though, but I suppose why not. 00:53
timo how would you keep it around?
oh it might also make sense to zero it out when $!saved-termios is Nilled
japhb That looks like a reasonable patch to me (delta the 'my' thinko and zeroing it when Nil'ing as timo said). PR it? 00:54
timo nope! bedtime! :) maybe grondilu could PR it?
grondilu huh 00:55
I'll try
timo you don't have to. good luck bye! 00:56
grondilu github.com/japhb/Terminal-LineEditor/pull/12 00:59
thanks timo++
japhb grondilu: Looks like the PR missed the bit about clearing the saved-fd when the saved-termios is Nil'ed? 01:12
01:12 grondilu left 01:19 grondilu joined, kylese left 01:20 hulk joined 01:26 derpydoo joined 01:36 Aedil joined 02:15 toddr left, hulk left, kylese joined 02:18 toddr joined 04:30 kylese left 04:32 kylese joined 04:40 human-blip joined 04:46 stanrifkin joined 05:12 human-blip left 05:13 human-blip joined 05:30 kylese left 05:32 kylese joined 06:00 Xliff joined
Xliff \o 06:00
tellable6 2025-04-14T04:12:00Z #raku <SmokeMachine> Xliff in theory, CommonSQL driver should handle most of (if not all) of them...
06:36 human-blip left 07:40 Sgeo left 07:43 human-blip joined 08:11 dakkar joined 10:26 lichtkind joined 10:32 grondilu left, derpydoo left 10:33 jpn joined 10:34 grondilu joined 11:16 grondilu left 11:18 grondilu joined
grondilu If I have `unit module Foo; our $bar = rand`, can I expect $Foo::bar to be different after every load of Foo? 11:40
I mean I sure can if Foo is not a compunit: 11:41
m: package Foo { our $bar = rand }; $Foo::bar
camelia ( no output )
grondilu m: package Foo { our $bar = rand }; print $Foo::bar 11:42
camelia 0.8950838548422354
grondilu m: package Foo { our $bar = rand }; print $Foo::bar
camelia 0.12659758324193893
grondilu hum... it seems that it works for compunits too. Not sure what's wrong then. 11:44
well that is weird. 11:52
it seems that I'll be able to golf it 11:58
so, in Foo.rakumod : `unit Foo; our %h = 'a'..'e' Z=> ^1_000 .pick..*;` 12:02
in Bar.rakumod: `unit Bar; use Foo;`
and now : `raku -I. -M{Foo,Bar} -e 'say %Foo::h'` always display the same values
but not `raku -I. -MFoo -e 'say %Foo::h'` 12:03
it has to be a hash, also. I couln't replicate it if I use just a range. 12:04
lizmat what if you lose the "unit Bar" in Bar.rakumod ? 12:06
grondilu same result, apparently
that is always the same values show up
if I use `require` instead of `use` though, then I get different values. 12:07
with `need` on the other hand, again always the same values. 12:08
btw by `unit Bar` above I meant `unit module Bar`, but we now know that is not the cause of the problem 12:09
lizmat ack
I was just about to ask :-)
grondilu (also `unit Foo` meant `unit module Foo`) 12:10
and as expected, if I remove .precomp between two run, then I get different values. 12:11
and that seems very wrong, as %h is not defined as a constant. 12:12
FYI this was preventing me to generate new image ids each time I was displaying a chessboard with my chess module. 12:13
12:21 human-blip left 12:23 human-blip joined 12:28 jpn left 12:34 jpn joined 12:36 JimmyZhuo joined 12:40 jpn left 12:51 Aedil left 13:25 sftp joined 13:30 jpn joined 13:42 Aedil joined 13:43 JimmyZhuo left
grondilu timo: japhb: It's still not ideal, though. The thread is still learking if the main process is not done. It's reading STDIN which can be unexpected.. 14:50
yesterday I posted this:
timo did you try asking the terminal emulator for a random report so that it writes something into the process's stdin to break the lock?
grondilu no 14:51
ah can't find the line in history
got it
so : my Terminal::LineEditor::CLIInput $term .= new; $term.enter-raw-mode; my $dim = await $term.detect-window-size; LEAVE $term.leave-raw-mode; say $dim; 14:52
^this works with the patch
but now consider this:
so : for ^2 { my Terminal::LineEditor::CLIInput $term .= new; $term.enter-raw-mode; my $dim = await $term.detect-window-size; LEAVE $term.leave-raw-mode; say $dim; }
this does not work. the first iteration is still hanging aftewards.
but yeah I have to look for a random report to print 14:53
timo right, without having something write to stdin, the little reader worker doesn't have the opportunity to exit its loop
grondilu why can't I just do LEAVE print q{*} ? 14:55
sorry I meant:
why can't I just do LEAVE $*IN.print: q{*} ?
I mean if it doesn't get the char I send it, I'm not sure sending a random report request would change anything 14:57
oh
I forgot you meant having the terminal write something 14:58
timo yes
you just don't get a handle that you can write to that will result immediately in your PTY receiving what you wrote
you need the terminal to help out
do you know how SIGTTIN works? 14:59
grondilu I've just tried with "\e14t". Didn't help. Still hanging.
Do I know how SIGTTIN works? No.
notice that with "\e14t", I see the terminal responding. But apparently the zombie thread does not catch it. 15:00
timo oh 15:02
i wonder if we have to 1) tell the background thread that it should stop, 2) send the request, 3) only then make the terminal no longer be raw 15:03
grondilu there is $!done for this but it's no use if the thread hangs before it has a change to notice it has changed its value. 15:05
basically the start-parser method will always end up hanging without input, no? 15:06
timo ok i think SIGTTIN and SIGTTOU are not interesting here 15:07
yeah, you can set done so that it stops looping, but you can not just make the read call exit on its own 15:08
grondilu is there no way to kill a read operation? 15:09
timo it sounds like if you handle a signal that your process gets, then the read call we do on the inside will return with EINTR. currently moarvm then just calls read again 15:11
tbrowder ugexe: shouldn't there be something in the docs about the dies-ok weird behavior if using "$p = run(|c)" 15:14
timo i suspect it will be annoying to try to make syncfile compatible with cancellable operations somehow. might be better to instead actually introduce a file handle that's backed by libuv 15:16
especially since that'll give us crossplatform support without us having to jump through whatever amount fo hoops 15:18
grondilu I suppose I should only ever use one Terminal::LineEditor::CLIInput by application, as it seems this class does not destroy gracefully. 15:19
which is ok I guess.
timo one per TTY ... you might have multiple TTYs to work with :D 15:23
grondilu or I could make a specific app to catch terminal events, and run it with `run`. 15:24
so that it has its own process. 15:25
grondilu wonders what happened to `fork`
timo hmm ... you can get a regular file descriptor from a socket, but you can't turn a TTY into a socket and use send and receive on it right?
grondilu I don't know much about sockets. 15:26
I'm still considering using fork.
after all it should be incredibly easy to call with NativeCall.
timo m: say fork; 15:27
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
fork used at line 1
grondilu m: use NativeCall; sub int fork is native {*}
camelia ===SORRY!=== Error while compiling <tmp>
Did you mean to write "my int sub fork" or put "returns int" before the block?
at <tmp>:1
------> use NativeCall; sub int fork<HERE> is native {*}
grondilu m: use NativeCall; sub fork returns int is native {*}
camelia Potential difficulties:
The returning type of 'fork' --> int is erroneous. You should not
return a non NativeCall supported type (like Int inplace of int32),
truncating errors can appear with different architectures
at <tmp>:1…
timo m: use nqp; say nqp::fork() 15:28
grondilu m: use NativeCall; sub fork returns Int is native {*}
camelia 16520
0
Potential difficulties:
The returning type of 'fork' --> Int is erroneous. You should not
return a non NativeCall supported type (like Int inplace of int32),
truncating errors can appear with different architectures
at <tmp>:1…
grondilu m: use NativeCall; sub fork returns int32 is native {*}
camelia ( no output )
timo fork is 1) incredibly easy to call and 2) extremely pointy
grondilu m: use NativeCall; sub fork returns int32 is native {*}() ; print "1"
camelia 11
grondilu ^see, that workded.
kind of amazing 15:29
timo please see nqp::fork
grondilu ok ok
I'm not sure why I shouldn't just use native fork, though.
timo long ago a very brave brrt made moarvm not explode violently when you fork
github.com/MoarVM/MoarVM/blob/b405...1251-L1252 15:30
this is what nqp::fork does that nativecalled fork probably doesn't
grondilu though now that I think about it, I would then need IPC to retrieve data from the child process. 15:31
so it may be complicated too.
timo > Unlike network I/O, there are no platform-specific file I/O primitives libuv could rely on, so the current approach is to run blocking file I/O operations in a thread pool. 15:34
that is just ...
ugexe i don't think it is safe to use fork in user code 16:01
timo with nqp::fork, it will at least take care of moarvm's different internal threads 16:02
ugexe from what i remember that has to be done as like an initialization type thing, i.e. it was being used in a way that was ok but that regular user code can not emulate
it was being used internally rather 16:03
ah i see the code you linked to has a bunch of information about that type of stuff, so ignore me in favor of whatever those comments say 16:04
16:05 jpn left 16:11 jpn joined 16:15 jpn left 16:51 jpn joined 16:57 dakkar left
grondilu timo: japhb: the parser reads STDIN in a loop that is essentially controlled by the variable $!done. It's nice that this variable is atomic, but that won't change the issue that the variable can't be read while the thread is waiting for a character to come from stdin. 18:04
timo i spent an amount of time today trying to make TTYs async-readable inside moarvm. i couldn't get it working yet, and i'm not sure exactly if it's the right way forward 18:06
grondilu IMHO, the parser should be given a closure to assess whether the loop should continue or not. Could be optional of course, but I think that's how it should be done. like method start-parser(&until)
timo do you have a specific case that that can do that the done variable can't? though the &until can of course just check the variable 18:08
grondilu the point is that the &until entails the logic behind the application, so it should know whether to keep reading input or not. 18:09
instead of being told to do so from the outside. 18:10
which can't work
as for the use case, let me tell you what I'm trying to do right now. I'm trying to make some routine or method that would allow me to input a chess move graphically. The problem I have is that I can't quit make it quit cleanly, after the move has been inputed. 18:13
timo the only way i know to set done is to leave-raw-mode, is that not the right semantics?
grondilu I've tried that, I couln't make it work.
timo by asking the terminal to send you a reply, right? 18:14
grondilu no. the command leave-raw-mode just doesn't get executed IIRC 18:15
and there's always that read operation that hangs, unless I either type a character or end the process. 18:16
timo with the fix we did to not have to ask for the native fd again, that should just get stuck because the reader is waiting for input 18:17
grondilu honestly I don't quite understand how you fix worked.
but it did, so there is that. 18:18
timo hm. why doesn't the code that i took from irc backlog work
it's detect-terminal-size not detect-window-size, now it works 18:20
grondilu the thing is : once a move has been inputed, I can do self.set-done; but I'm pretty sure that won't be enough to stop the read operation. Your fix just allowed the main process to quit, but I don't want the main process to end after just one move has been inputed. 18:21
timo right
your code is currently reusing the same Terminal::LineEditor::CLIInput object? 18:22
grondilu it's inheriting from it, yes.
but I haven't pushed anything yet so it's not public.
what has been pushed uses Term::termios and a custom CSI parsing routine.
I suppose I should create a new branch 18:23
oh I misunderstood your question about CLIInput. Yes, I'm trying to use a single instance now. 18:24
timo ok i have something that seems to work how i want it to 18:27
grondilu Now that I think about it, I can override start-parser since I'm using inheritance.
and let it use a &until closur.
timo can always mixin, too
grondilu I can't mixin a class, can I?
timo no, but you can put the bits you want into a role and mix that in 18:28
grondilu true
though I think CLIInput has a few methods I want already.
grondilu checks 18:29
well, actually not, apart from TWEAK which is not a method anyway. 18:30
so yes, mixins it is 18:31
timo github.com/timo/Terminal-LineEdito...65ba624f40 18:33
my test code for that is this:
use Terminal::LineEditor::RawTerminalInput; for ^5 { my Terminal::LineEditor::CLIInput $term .= new; $term.enter-raw-mode; my $dim = await $term.detect-terminal-size; LEAVE { $term.leave-raw-mode; }; say $dim }
this now just spits out the size of the terminal five times and quits immediately 18:34
... /cc japhb
grondilu shouldn't you put that code in set-done instead? 18:37
I mean one might want to leave the terminal in raw mode for some reason. 18:38
timo yeah i think that makes sense 18:43
if we want an "undefined" value for the saved fd, maybe it should be an Int attribute and not an int one 18:50
japhb BAK. Addressing some backlog - yes, in the patch the saved fd should *not* be a native int, so that we can clear it to an undefined value properly. 18:55
grondilu: If you're doing individual keypresses to control things, rather than input lines, you shouldn't be going in and out of raw mode all the time and having the app in control of time ... you should be having your app react to async arriving key presses as part of its overall control loop, and staying raw until you actually *need* cooked mode. 18:58
github.com/japhb/Terminal-Widgets/...al.rakumod does this in Terminal-Widgets, dispatching tasks from its start react as needed. 19:00
19:00 mtj left 19:12 mtj joined 19:26 jpn left
melezhik. Copy pasting from cro irc channel just in case - If someone would take a look at github.com/croservices/cro/issues/168 I would appreciate it, helping rocky linux team adapt some Raku tools , thanks 🙏 19:28
19:32 Aedil left 19:49 jpn joined
librasteve in my experience about hakf of bugs are caused by security permissions 19:52
this one say [cro] # Check service up attempt 1: connection refused
[Coke] out of curiosity, why 2025.02 and not 2025.03? 19:54
(I don't expect that to fix your problem) 19:56
librasteve what is the hardware? 19:57
the prior line #62 says my $got-body = test-request("localhost:$port/"); 19:58
my first stab is that the local firewall rules deny http on localhost - please can you check 19:59
i have requested more info / fw permissions check in the issue 20:06
20:07 jpn left 20:14 jpn joined
melezhik. librasteve: thanks for swift reply 20:19
20:31 jpn left
librasteve yw ... do you have a clean rocky linux instance ... maybe you can check the default fw settings (is the endpoint reachable in the --/test case??) 20:33
crag '₃₆123.45' #3F.G77777 20:36
20:37 jpn joined, swaggboi left 20:41 swaggboi joined
^^ big improvement to App::Crag ... no longer have to say say 20:41
antononcube I assume that is a number system representation. 20:47
librasteve base 36 20:48
crag 'molecular-mass("SO2")' #64.058 20:49
antononcube Just tried it. 20:53
librasteve github.com/librasteve/raku-App-Cra...the-day.md 20:54
^^ some examples
21:21 jpn left 21:59 MasterDuke joined 22:51 stanrifkin left 23:24 lichtkind left
grondilu timo: it seems that calling self.set-done at the right place in the code is actually enough to stop the loop. My bad. 23:31
gist.github.com/grondilu/5e3192b23...aff0d33280 23:33
japhb I'm not completely incompetent! \o/ ;-) 23:46
23:48 MasterDuke left 23:49 Sgeo 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!