00:39 <joe9> veltas, why not flashforth? I have an amd64 port of it. But, it still has some bugs that I need to work through.

00:39 <joe9> But, this is native to 9front though.

00:40 <veltas> Okay well that's why then :)

00:40 <veltas> I'm afraid I don't run 9front

17:22 <nihilazo> https://ttm.sh/ut4.fs I'm really unsure about the way I'm handling changed? etc in this, I'm not sure what the better way would be. Currently I'm storing a value and if it's changed as two cells with the change flag after the value, which is fine except I have one value that takes two cells itself and I have to put those in cells 0 and 2 with the change flag being in cell 1, which feels inelegent.

17:22 <nihilazo> I could put the change flag in cell 0, but then accessing the value would require using 1 cells + a bunch

17:42 <inode> one way could be to have the words like CHANGED? accept an additional parameter to indicate how many cells to skip from addr

17:42 <inode> ie. : changed? ( addr -- flag ) 1 cells + @ ; -> : changed ( addr skip -- flag ) cells + @ ;

17:43 <inode> (also 1 CELLS is the same as saying CELL)

17:45 <inode> guessing you might end up wrapping it as : membercost-changed? membercost 1 changed? ;

17:45 <nihilazo> the additional parameter idea works

17:45 <nihilazo> thanks

17:46 <nihilazo> I have another question but it's not directly forth related and rather just rellated to working in a terminal so I'm not sure where is best to ask it

17:46 <inode> otherwise have an array of changed-flags where each variable in question is associated with a particular index

17:48 <inode> it doesn't hurt to ask off-topic stuff, someone here might be able to help

17:50 <nihilazo> is it possible to detect a key being pressed rather than typed, ignoring key repeat etc, in an application that runs in a terminal? Like, the physical key press

17:54 <inode> do you want to get the event without any noticable output to the tty?

17:54 <inode> at least before you've decided what to do with it frist

17:55 <inode> i'm guessing you want to put the tty into raw mode

17:56 <nihilazo> raw mode?

17:56 <inode> https://en.wikipedia.org/wiki/Terminal_mode

17:57 <nihilazo> ah ok

17:58 <nihilazo> so if the terminal is in raw mode, I get the keystrokes directly rather than them going through the terminal's line stuff, but I think then I still get key repeat? because it's done in the OS before it gets to the terminal I think. don't know

17:59 <nihilazo> wait, am I in raw mode already if I can get single keystrokes? I'm already doing that

17:59 <nihilazo> or is it not doing single keystrokes and the program is just eating the first character of the cooked input

18:01 <inode> i don't see anything in your shared code to change your terminal settings, so i'm guessing you're in cooked mode

18:03 <nihilazo> yeah the only terminal setting I'm changing is hiding the cursor

18:03 <nihilazo> I'm not sure how to enter raw mode. Everything I can see seems to be making use of a C library

18:04 <inode> you'll probably need to make the calls to tcgetattr and tcsetattr through ffi yourself

18:04 <inode> i don't think gforth has any bindings for termios stuff

18:07 <nihilazo> oh ok

18:07 <nihilazo> time to learn how, and if, ffi works

18:16 <inode> actually the manual says stdin already should be in raw mode

18:17 <inode> https://gforth.org/manual/General-files.html

18:17 <inode> key-file ... "Read one character n from wfileid. This word disables buffering for wfileid. If you want to read characters from a terminal in non-canonical (raw) mode, you have to put the terminal in non-canonical mode yourself (using the C interface); the exception is stdin: Gforth automatically puts it into non-canonical mode."

18:20 <nihilazo> huh

18:21 <nihilazo> that makes sense I guess, given that I can read single keystrokes in from stdin

18:21 <nihilazo> so that only leaves the question of key repeat which I might need to filter out manually

18:27 <mark4> or just make things large enough for any cell size/

18:28 <mark4> nihilazo: yes it is, you would use the poll call

18:28 <mark4> and pollfd's

18:28 <nihilazo> poll call? (sorry I know nothing about terminals)

18:28 <mark4> i have some example code you might like to see in my ucurses

18:28 <mark4> hang on

18:29 <mark4> poll is a linux system call

18:29 <mark4> https://github.com/mark4th/uCurses/blob/master/src/keys.c

18:29 <mark4> thats got some stuff in there you might like to study

18:29 <nihilazo> thanks

18:30 <mark4> key() returns a key, keys() returns how many are available for read i think

18:30 <mark4> the call to poll in keys() is non blocking here

18:31 <mark4> read_key will read a complete key seauence because some keys return more than one byte

18:31 <mark4> like cursor keys and function keys etc

18:31 <nihilazo> ok

18:36 <nihilazo> I'm not sure if I could call poll from gforth, hmm

18:36 <nihilazo> because it uses structs in arguments

18:36 <nihilazo> which from the docs doesn't seem to be supported

18:40 <nihilazo> I guess maybe I'd have to write C to interface to the C interface in gforth?

18:42 <mark4> you can look at how i did it in x4 sources too. src/kernel/io.f i believe at the top

18:42 <mark4> i just manually created a flat pollfd structure which is just a few bytes in size

18:42 <mark4> and then called the sys poll systemcall

18:47 <nihilazo> ok

18:47 <nihilazo> and could using poll mean I don't get key repeats?

18:47 <nihilazo> this is literally just to stop people cheeseing my game lol

23:44 <veltas> nihilazo: Key repeat is done by the keyboard

23:44 <veltas> With P/S2 keyboards at least

23:44 <veltas> It's done at a very low level

23:44 <veltas> Regardless, your terminal can't distinguish repeat keys, and doesn't get info about key releases