[9fans] plan9port changes to rc and acme

[9fans] plan9port changes to rc and acme

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

Hi all,

In plan9port, back in 2020, I wrote a new parser in rc to clean up a few
things, most notably that = signs are now allowed in command arguments.
This makes rc much nicer for using programs with -foo=bar flag syntax. It
was pointed out to me that I may not have announced it here, so I'm
belatedly mentioning it now, in case the Plan 9 distributions want to pick
it up.

https://groups.google.com/g/plan9port-dev/c/AS8acHti7eo/m/0tZF7h7FBQAJ
(three relevant commits linked there)

While I'm writing, another interesting plan9port change is that I made
shift-right-click in acme search backward from the current position. This
is very helpful when you are cycling through many results and go one step
too far. To pick that up, the Plan 9 mouse driver would have to be updated
to treat shift-click as adding 5 to the usual button number. (That is, the
normal buttons are 0 1 2 3 4, and the shifted ones are 5 6 7 8 9.)

https://github.com/9fans/plan9port/commit/0c79c32675e83ff3d87d5bf52082652d85486a45

Best,
Russ

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M8c1df39be15674b13bd6a7b6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2094 bytes --]

Re: [9fans] plan9port changes to rc and acme

[Kurt H Maier via 9fans]

On Mon, Sep 30, 2024 at 09:52:58AM -0400, Russ Cox wrote:
> Hi all,
> 
> In plan9port, back in 2020, I wrote a new parser in rc to clean up a few
> things, most notably that = signs are now allowed in command arguments.
> This makes rc much nicer for using programs with -foo=bar flag syntax. It
> was pointed out to me that I may not have announced it here, so I'm
> belatedly mentioning it now, in case the Plan 9 distributions want to pick
> it up.
> 
> https://groups.google.com/g/plan9port-dev/c/AS8acHti7eo/m/0tZF7h7FBQAJ
> (three relevant commits linked there)

I don't know why you told TUHS that 9front is unmaintained; it is
maintained and in fact developed.  Our source code repository is at 

http://git.9front.org/plan9front/plan9front/HEAD/info.html

We have working heredocs and error messages with line numbers, in case
the Plan 9 distributions want that.  Compatibility with unix-style
parameter specification isn't particularly high on our to-do list, I
don't think, but someone might find the time to work on it.

khm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-Mb190dcfef7e1d71ef3bf0c7c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: plan9port changes to rc and acme

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Monday, 30 September 2024, at 2:53 PM, Russ Cox wrote:
> While I'm writing, another interesting plan9port change is that I made shift-right-click in acme search backward from the current position. This is very helpful when you are cycling through many results and go one step too far. To pick that up, the Plan 9 mouse driver would have to be updated to treat shift-click as adding 5 to the usual button number. (That is, the normal buttons are 0 1 2 3 4, and the shifted ones are 5 6 7 8 9.)

If I was building graphical software for Plan 9 (and I'd like to), I'd really want/need the separate state of each of the CTRL, SHIFT and ALT (and any other modifier) keys delivered with the mouse events - perhaps as honorary mouse buttons - i.e. 3 more bits in the bit mask. 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M06842df744045582f8f5b528
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1650 bytes --]

Re: [9fans] plan9port changes to rc and acme

[ori]

Quoth Russ Cox <rsc@swtch.com>:
> 
> While I'm writing, another interesting plan9port change is that I made
> shift-right-click in acme search backward from the current position. This
> is very helpful when you are cycling through many results and go one step
> too far. To pick that up, the Plan 9 mouse driver would have to be updated
> to treat shift-click as adding 5 to the usual button number. (That is, the
> normal buttons are 0 1 2 3 4, and the shifted ones are 5 6 7 8 9.)
> 
> https://github.com/9fans/plan9port/commit/0c79c32675e83ff3d87d5bf52082652d85486a45

That seems useful, but as a person with a 7 button mouse, I think
the interface to shifted mouse buttons should probably be different.

I think my preference would be to have the keyboardctl device keep a
map of which modifiers are currently pressed.

        if((mc->buttons&1) && (kc->mods&Mshift))
                ...


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M14a56f4ba72b52e2b1621562
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port changes to rc and acme

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

If mouse click events are queued and the keyboard modifier state changes are not (or are queued separately), they can get out of step. By the time the program receives a mouse click event, the keyboard may be unshifted again. This could happen if a program is late processing mouse input.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-Mbcc6a0e0025a9f26e94b89c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1010 bytes --]

Re: [9fans] plan9port changes to rc and acme

[ori]

This is a problem that can happen with any keyboard input;
if I press 'A' and click, this problem can also happen.

Fixing this would probably need merging both event streams
into one /dev/input or similar.

Quoth Alyssa M via 9fans <9fans@9fans.net>:
> If mouse click events are queued and the keyboard modifier state changes are not (or are queued separately), they can get out of step. By the time the program receives a mouse click event, the keyboard may be unshifted again. This could happen if a program is late processing mouse input.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-Me031123e9d3176edc4c4c188
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port changes to rc and acme

[Shawn Rutledge]

If your inclination is to combine streams every time you need to ensure that event ordering is maintained, you could end up with a lot of streams being combined, and thus a traditional event queue.  Next thing you know, you might want to be able to inject application-created events into that queue, just to preserve ordering of something else relative to the incoming events.  If the system won’t let you add to the main event queue, you might create your own queue in your application (or supporting library) just to be able to mix system events with your own events.  Then you end up with a lot of event types, and switch statements in dispatching code (like Qt has a good number of, for example), and the extra queuing creates delays.  So now and then I take to pondering, what could be more elegant if that pattern is to be avoided?

One cause of the ordering problem is that separate processes handle incoming events from their respective devices, right?  e.g. kbdfs is independent, so you can’t be sure that if you are trying to read from multiple devices, that you will get the events in the same order that the user manipulates the devices.  If there were just one process to handle all input devices (call it inputfs), I would think it could continue to serve up separate streams on separate files, and still enforce ordering as long as the read operation is blocking.  I.e. if you opened both the mouse and the keyboard, and a modifier is pressed, you need to read the keyboard file to get the changed modifiers before you are allowed to read the next mouse event.  Are there some bad deadlock cases with such an approach?  (I didn’t try, it’s just an idea.)

But input events should have timestamps anyway, generated as close-to-the-hardware as possible.  (e.g. in an interrupt handler?)  That could provide an alternative mechanism to reorder events, if there is no other way to guarantee that they will be emitted to the files in the correct order.  Then if you read events in the wrong order, at least you can detect that it’s in the wrong order, and it will be obvious how to fix that bug.

I don’t like the Plan 9 tendency to put space-separated sequences of data values in files.  The knowledge of what those fields mean is out-of-line, so you rely on your memory when reading it manually, and changing the schema is also hard.  csv at least has a header line to label the fields.  This is also why things like xml, json, messagepack and all the others were invented (mostly ugly) https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats .  So now you wonder how to add keyboard modifier state to the mouse events, and are afraid to add another field, so you come up with hacks like higher-numbered mouse buttons or extra bits.  If the fields were labeled in the first place, somehow, it would be extensible.  But making every line into a dictionary is too verbose.  Well, maybe put the schema into a separate file then, and expect libraries to use it to populate their event structs?  If the struct is missing some fields that were added recently, then you are just missing the new info, but the new fields do not get in the way of populating the old struct.  If the struct has new fields that aren’t available in practice, use standard values to indicate that they are uninitialized (empty string, -1, NaN, ...).

Next evolutionary step is maybe to choose a binary format that is easily tokenized (maybe add a length to each field, so that arbitrary lengths are ok).  Maybe use small numbers for the field labels, and put the schema (table mapping the small numbers to their meanings) elsewhere.  (Maybe in the first record that you read from the file, as in csv.)  Probably some of the old standards already do it that way.  I once invented a format like that myself, for serializing arbitrary hierarchical data (like a binary XML) and compacting the element IDs into small numbers, but I suspect it’s redundant by now.  Anyway, it’s a form of unaligned bytewise serialization.  So I figured I could do better.

Next improvement is to have a standard way to represent a vector in memory (including a length field), and make the event file provide those vectors in little-endian layout so that each event can be copied into process memory and used directly.  Eliminate deserialization and parsing completely.  The “schema” would just be another vector containing the field labels.  But then you need fixed field lengths, which creates limits (e.g. it could be a vector of 64-bit values, with NaN-boxing to distinguish types, leaving you 51 bits for all non-double types; if strings are supported as a type in a vector, then the labels in the “schema" can’t be longer than 6 ascii characters, or 8 6-bit characters, or 10 5-bit characters, or else strings have to be stored separately in a hash table or something).  If a mouse event comes in this form (a vector of doubles and ints), and you want to find the “x” value, you first search for “x” in the schema vector, which gives you the offset.  Every event from then on can be expected to have “x” at the same offset.  But a future version of inputfs is free to change the schema, without breaking applications.  Adding keyboard modifiers to the mouse events would be easy then (if you haven’t solved the event timing problem some other way).  To read it by hand on the command line, you need a different tool than cat or tail, but it can read all such binary-vector files, which ought to have many other uses.  That’s something I’m working on in a different context.

If files in /dev are going to change, we ought to make it future-proof this time.  Support all possible input devices, even those that haven’t been invented yet.  For now though, there’s multi-touch (touchscreens and touchpads), jog/shuttle controls and other kinds of encoders, joysticks, tablet/stylus, VR controllers, etc. Shoehorning all of that into hacks that fit the old schemas for keyboard and mouse would be really limiting (despite the excuses that are made about that).  They are different devices for a reason.  In general, there could be many devices in use at the same time.  To me it seems natural to continue with separate streams for each, rather than interleaving the events in one file.

> On Oct 1, 2024, at 3:56 AM, ori@eigenstate.org wrote:
> 
> This is a problem that can happen with any keyboard input;
> if I press 'A' and click, this problem can also happen.
> 
> Fixing this would probably need merging both event streams
> into one /dev/input or similar.
> 
> Quoth Alyssa M via 9fans <9fans@9fans.net>:
>> If mouse click events are queued and the keyboard modifier state changes are not (or are queued separately), they can get out of step. By the time the program receives a mouse click event, the keyboard may be unshifted again. This could happen if a program is late processing mouse input.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M682112905f99c35a5eea9bce
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port changes to rc and acme

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Years ago I built an Remote Procedure Call library that used 9p as the wire protocol. It handled event 'callbacks' by sending read requests to opened virtual files well ahead of time and treating the eventual Rread replies as events. As soon as it got an event it would send another Tread.

Perhaps an approach to the multiple event stream problem, then, is to talk directly to a 9p server using the wire protocol rather than going through the mnt device in the kernel. 9p already multiplexes data streams, so why not take advantage of that? As far as I understand it the fcall library already does the 9p framing. The internal format of the input events is orthogonal to that.
If the kernel can't serve the 9p protocol for the input devices, then exportfs would, though possibly rio would be a better place to do that.

I probably need to have a closer look at drawterm. :)

kbdfs on 9front looks like it will be important for me. You can get the modifier transitions as events - it's missing the timestamps, but I'm not sure how much that will matter in practice.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-Mf8fed83725e8e515a35d1ac7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

Re: [9fans] plan9port changes to rc and acme

[Steve Simon]

if you need to synchronise two streams you could timestamp them.

the timestams need not be realtime they could be just an unsigned event number. applications can then match up the timestamps if they need to.

i am not saying this is a perfect solution, but its an alternative approach.

-Steve


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-Md50b90e7b4664431a6c3d5fe
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port changes to rc and acme

[hiro]

i believe that assumes a state exists in the universe where they are "in step"

On Tue, Oct 1, 2024 at 2:14 AM Alyssa M via 9fans <9fans@9fans.net> wrote:
>
> If mouse click events are queued and the keyboard modifier state changes are not (or are queued separately), they can get out of step. By the time the program receives a mouse click event, the keyboard may be unshifted again. This could happen if a program is late processing mouse input.
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M7635cdb90d91d56ef62fb564
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port changes to rc and acme

[David Leimbach via 9fans]

Like a vector clock might? 
Sent from my iPhone

> On Oct 1, 2024, at 2:32 PM, hiro <23hiro@gmail.com> wrote:
> 
> i believe that assumes a state exists in the universe where they are "in step"
> 
>> On Tue, Oct 1, 2024 at 2:14 AM Alyssa M via 9fans <9fans@9fans.net> wrote:
>> 
>> If mouse click events are queued and the keyboard modifier state changes are not (or are queued separately), they can get out of step. By the time the program receives a mouse click event, the keyboard may be unshifted again. This could happen if a program is late processing mouse input.
>> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M1c9789630c09ab3b317a8c49
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port changes to rc and acme

[ori]

Quoth Russ Cox <rsc@swtch.com>:
> 
> In plan9port, back in 2020, I wrote a new parser in rc to clean up a few
> things, most notably that = signs are now allowed in command arguments.
> This makes rc much nicer for using programs with -foo=bar flag syntax. It
> was pointed out to me that I may not have announced it here, so I'm
> belatedly mentioning it now, in case the Plan 9 distributions want to pick
> it up.

fwiw, I had a patch that brought it in to 9front; it would be nice to have
the free caret updates, though I don't care so much about the 'foo=bar'
syntax that much, and I don't love dropping the yacc grammar.

In the end, it fell by the wayside.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M0728a9504900e041f371262c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port changes to rc and acme

[Kyohei Kadota via 9fans]

I had imported a patch[1], that is equal sign improvement, from p9p's
rc for 9legacy at that time.

[1]: https://patch-diff.githubusercontent.com/raw/lufia/plan9/pull/8.diff

If someone would like.

2024年9月30日(月) 22:54 Russ Cox <rsc@swtch.com>:
>
> Hi all,
>
> In plan9port, back in 2020, I wrote a new parser in rc to clean up a few things, most notably that = signs are now allowed in command arguments. This makes rc much nicer for using programs with -foo=bar flag syntax. It was pointed out to me that I may not have announced it here, so I'm belatedly mentioning it now, in case the Plan 9 distributions want to pick it up.
>
> https://groups.google.com/g/plan9port-dev/c/AS8acHti7eo/m/0tZF7h7FBQAJ
> (three relevant commits linked there)
>
> While I'm writing, another interesting plan9port change is that I made shift-right-click in acme search backward from the current position. This is very helpful when you are cycling through many results and go one step too far. To pick that up, the Plan 9 mouse driver would have to be updated to treat shift-click as adding 5 to the usual button number. (That is, the normal buttons are 0 1 2 3 4, and the shifted ones are 5 6 7 8 9.)
>
> https://github.com/9fans/plan9port/commit/0c79c32675e83ff3d87d5bf52082652d85486a45
>
> Best,
> Russ
>
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T1dee2a7aea3f7fa3-M20b64f2d445e52eba0fd1866
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription