Re: [9fans] acme and sam - mouse suggestions?

[David Arroyo]

On Thu, Jan 27, 2022, at 23:59, Marius Eriksen wrote:
> It’s pricy, but I love the 3dconnexion CAD mouse [1]. It tracks superbly, and 
> the construction quality approaches Apple’s level. 
> 
> [1] https://3dconnexion.com/us/cadmouse/
I use the wireless model and agree it's an excellent mouse. The shape and 
buttons are perfect for me.

Some caveats, though-- it has a "smart scroll" feature which stimulates 
inertial scrolling. I have since learned to like it, but initially you will 
absolutely hate it.

David
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Md4c8607e416deeaac0a29051
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas (WAS: Re: Plan 9 Applying to GSoC 2021)

[David Arroyo]

> (1) Porting the Plan 9 kernel to a microkernel architecture, such as
> Mach.  This would give Plan 9 instant access to the whole range of
> hardware supported by the underlying microkernel.

This is kind of the opposite idea, but you could port the NetBSD rump
kernel to Plan 9. It can then be used to interface with any device that
the NetBSD kernel supports.

https://research.csiro.au/tsblog/using-rump-kernels-to-run-unmodified-netbsd-drivers-on-sel4/

David


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-M9a5ff3bda8d7b59d0a265ad7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[David Arroyo]

On Wed, Jan 27, 2021, at 11:25, Ethan Gardener wrote:
> fcp(1)? 

You are right, but fcp(1) would only produce multiple parallel read
and write messages, I'm talking about a more general approach. fcp is
probably a better compromise, though, as ori points out the client can
get complicated pretty quickly when trying to solve the problem more
generally:

On Wed, Jan 27, 2021, at 11:52, o...@eigenstate.org wrote:
> This also has some hairy edge cases. For example,
> what happens to the actions in the pipeline if one
> of the operations fails?

Yes, the tradeoff of this pipelining is that the client becomes a lot
more complex, but for this specific problem, the client would need to be
prepared to receive and discard Rerror messages for each message after
the failed one, just surfacing the first error to whatever system call
or library function kicked off this sequence of messages.

> I think that for this kind of pipelining to be
> effective, 9p may need some notion of 'bundles',
> where the first failure, short write, or other
> exceptional operation would cause all other
> commands in the bundle to be ignored.

You can get pretty close to "bundles" without changing the protocol by
having the client reserve a few bits of storage in the Tag header to
group requests in a pipeline together:

# Bundle 1, sent at once
Twalk tag=0x0100 fid=0 newfid=1 "foo/bar"
Topen tag=0x0101 fid=1 O_RDONLY
Twrite tag=0x0102 fid=1 data
Tclunk tag=0x0103 fid=1

Then the client could use a trie or some similar data structure on the
tag of an R-message to get the "state" of a pipeline.

> Another issue is that its' difficult to retrofit
> this pipelining into the plan 9 system call
> interface; when do you return an error from
> read(2)? what if there are mutiple Treads?

This is a harder problem, I think. What if non-contiguous reads or writes
succeed? An mmap()-style API might fare better here, but that comes with
its own drawbacks. I don't have a good answer here, but I think since
Twrite and Rread messages are elastic it is always better to just send
larger messages, increasing msize if necessary.

> how do you handle congestion if you can stuff as many 9p packets down
> a single connection as possible? There's no packet loss, but you can
> end up with very long delays as small reads like /dev/mouse get queued
> behind bulk transfers.

The problem you describe is analagous to the "buffer bloat" problem.
In the lower protocols like TCP it is solved by making the sender aware of
the bandwidth delay product and sizing its buffers appropriately. So it
could be handled by using a model-based congestion avoidance algorithm
like BBR or Vegas, and sending messages out of a prioritized queue,
where "interactive" files like /dev/mouse are prioritized.

David

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M6e7a64ad95ea27ac3c73a9ac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[David Arroyo]

On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote:
> It's well-known that 9P has trouble transferring large files (high
> volume/high bandwith) over high-latency networks, such as the Internet.

>From what I know of 9P, I don't think this is the fault of the protocol
itself. In fact, since 9P lets the clients choose Fid and Tag identifiers,
it should be uniquely well suited for "long fat pipes". You could avoid
waiting for round-trips by optimistically assuming your requests succeed.
For example, you could do the following to optimistically read the first
8K bytes of a file without needing to wait for a response from the server.

* Twalk tag=1 fid=0 newfid=1 /path/to/somefile
* Topen tag=2 fid=1 o_read
* Tread tag=3 fid=1 off=0 count=4096
* Tread tag=4 fid=1 off=4096 count=4096
* Tclunk tag=5 fid=1

I'm not aware of any client implementations that do this kind of
pipelining, though.

David

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M108d4f8ab0862aef8c9c4202
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] mice

[David Arroyo]

I use a 3DConnexion CADMouse pro wireless: https://3dconnexion.com/uk/cadmouse/ 
and I really like it. It fits my hand well and works in wired, bluetooth , or 
with a wireless usb transmitter. It's got a huge middle mouse button which was 
the main draw for me.

The downsides are that it seems to have a unique bluetooth firmware that 
crashes bluetoothd on Linux . I haven't been able to figure it out. It also has 
this fake "inertial" scrolling which I hated at first but now I quite like it.

David

On Fri, Nov 27, 2020, at 19:33, Kyle Farwell via 9fans wrote:
> On 2020-11-27 6:41 p.m., Steve Simon wrote:
> > i tried a countour mouse but didn't get on with it. i bought a cheap 
> > Chinese copy - 3 real buttons on top and a wheel on the side.
> > 
> > i cannot find the exact link, this is the same mouse but i have the 
> > wired version - never needs recharged.
> > 
> > i really like it, it fits my had well and i can use sam, and scroll 
> > windows (with the 9front changes).
> > 
> > https://www.aliexpress.com/i/404785639.html 
> > 
> > -Steve
> 
> I have the same mouse, wired version. I've used a couple different
> 3-button mice and this is my favourite.
> 
> It's a 灵智银狐 (Lingzhi Silver Fox) brand MODEL M-S3C. Here is the
> official website:
> 
> http://www.hao1885.com/products.asp
> 
> They have some other models with the wheel on top or without any wheel.
> 
> I bought mine on eBay but the listing is gone. There are some other
> sites selling it if you search around.
> 
> Mine stops working once in a while but it's fixed by unplugging it and
> plugging it back in. This behaviour is OS-independent.
> 
> Kyle

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9911dd6a42b7bc91-M8989f1a70229f542713c5044
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] p9p: 9 ls /dev

[David Arroyo]

The problem is twofold;

* The function exits early if it can't read a max-length directory
entry, so that entry is "skipped" in subsequent calls to mygetdents.
* As you said, we also lose any buffered dirents that haven't been
returned from readdir yet.

I think these are both fixable problems, but it may not be worth it.
Ori's suggestion to use Getdirentries64 on OSX might be  better.

David

On Tue, Apr 11, 2017, at 10:33 PM, arisawa wrote:
> I did more test on david code and found a problem.
> 
> -bash$ mk -f mkfile_david
> -bash$ o.test_dirread -a /usr/bin |wc
> 10844336   27266
> -bash$ o.test_dirread /usr/bin |wc
> 10844336   27266
> -bash$ ls /usr/bin |wc
> 110811089719
> 
> option -a is for dirreadall.
> 1108 - 1084 entries are lost.
> 
> they are:
> o.test_dirread /usr/bin | awk '{print $1}' | sort >/tmp/a
> ls /usr/bin | sort >/tmp/b
> diff /tmp/a /tmp/b
> 
> -bash$ diff /tmp/a /tmp/b
> 21a22
> > SplitForks
> 240a242,246
> > easy_install-2.6
> > easy_install-2.7
> > efax
> > efix
> > egrep
> 461a468,473
> > kcc
> > kdestroy
> > kextutil
> > keytool
> > kgetcred
> > kill.d
> 675a688,694
> > piconv
> > piconv5.16
> > piconv5.18
> > pidpersec.d
> > pkgbuild
> > pkill
> > pl
> 880a900,904
> > spfquery5.18
> > splain
> > splain5.16
> > splain5.18
> > split
> 
> sorry if I make a mistake, but I suspect readdir_r() has a buffer,
> which can make a problem in using dup().
> 
> Kenji Arisawa.
> 
> > 2017/04/09 13:18、arisawa <karis...@gmail.com> のメール：
> > 
> > thanks david.
> > 
> > using dup() is very nice idea!
> > your code works with
> >   CFLAGS=-D__DARWIN_64_BIT_INO_T# manual is wrong
> > and a fix:
> > //  buf = ((char*)buf) + d_reclen(buf);
> > buf = (struct dirent *)(((char*)buf) + d_reclen(buf));
> > and adding
> > #define NAME_MAX 256
> > in somewhere.
> > 
> > now /dev is readable.
> > 
> > one problem is left.
> > 
> > my test code:
> > fd = open(dirname,OREAD);
> > if(fd < 0)
> > fatal("%s open error",dirname);
> > while((n = dirread(fd, )) > 0){
> > print("#DBG n=%d\n",n);
> > for(i = 0; i < n; i++)
> > print("%s %s %s \n", db[i].name, db[i].uid, db[i].gid);
> > }
> > close(fd);
> > shows for dirname=$HOME
> > ...
> > arch root 501 
> > bin root 501 
> > ...
> > but they should be
> > arch arisawa staff 
> > bin arisawa staff
> > this problem comes from _p9dir() that is used in dirpackage().
> > 
> > Kenji Arisawa
> > 
> > 
> >> 2017/04/08 18:07、David Arroyo <dr...@aqwari.net> のメール：
> >> 
> >> Ignore my previous post, I was tired and forgot about dup(). How about
> >> something like this? (attached)
> >> 
> >> I only tested this on Ubuntu, I don't have an OS X machine. I still went
> >> with readdir_r because the AIX and Solaris man pages for readdir were
> >> vague about its behavior when called from multiple threads (glibc, musl,
> >> FreeBSD look pretty safe).
> >> 
> >> Cheers,
> >> David
> >> 
> >> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote:
> >>> This should be doable with some combination of fdopendir(3) and
> >>> readdir(3). I'm not sure how to avoid leaking memory through the
> >>> returned DIR pointer and any memory allocated with by readdir(3).
> >>> This is usually free'd by closedir(3), which we can't use without
> >>> closing the underlying file.
> >>> 
> >>> It should be OK to use free() on the return value of fdopendir, and
> >>> stick to the uglier readdir_r(3) interface. I can definitely see why
> >>> Russ went with  the simpler  system-specific interfaces on this.
> >>> 
> >>> David
> >>> 
> >>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
> >>>> On Sat, 8 Apr 2017 15:21:47 +0900, arisawa <karis...@gmail.com> wrote:
> >>>> 
> >>>>> but how to?
> >>>>> 
> >>>>> unix doesn’t have something like fdreaddir(int fd).
> >>>>> my guess: russ unwillingly used a low level function such as
> >>>>> int getdirentries(int fd, char *buf, int nbytes, long *basep).
> >>>>

Re: [9fans] p9p: 9 ls /dev

[David Arroyo]

Ignore my previous post, I was tired and forgot about dup(). How about
something like this? (attached)

I only tested this on Ubuntu, I don't have an OS X machine. I still went
with readdir_r because the AIX and Solaris man pages for readdir were
vague about its behavior when called from multiple threads (glibc, musl,
FreeBSD look pretty safe).

Cheers,
David

On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote:
> This should be doable with some combination of fdopendir(3) and
> readdir(3). I'm not sure how to avoid leaking memory through the
> returned DIR pointer and any memory allocated with by readdir(3).
> This is usually free'd by closedir(3), which we can't use without
> closing the underlying file.
> 
> It should be OK to use free() on the return value of fdopendir, and
> stick to the uglier readdir_r(3) interface. I can definitely see why
> Russ went with  the simpler  system-specific interfaces on this.
> 
> David
> 
> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
> > On Sat, 8 Apr 2017 15:21:47 +0900, arisawa <karis...@gmail.com> wrote:
> > 
> > > but how to?
> > > 
> > > unix doesn’t have something like fdreaddir(int fd).
> > > my guess: russ unwillingly used a low level function such as
> > > int getdirentries(int fd, char *buf, int nbytes, long *basep).
> > > 
> > > readdirall() might be OK in regular usage.
> > 
> > I don't use OSX regularly, although I do maintain the syscall
> > layer for Myrddin on it.
> > 
> > Getdirentries64 exists, and rudimentary testing doesn't show
> > any difficulties with using it.
> > 
> > -- 
> > Ori Bernstein
> > 
> 
diff --git a/src/lib9/dirread.c b/src/lib9/dirread.c
index 40fbe3c..6c00dff 100644
--- a/src/lib9/dirread.c
+++ b/src/lib9/dirread.c
@@ -3,54 +3,46 @@
 #include 
 #include 
 #include 
+#include 
 
 extern int _p9dir(struct stat*, struct stat*, char*, Dir*, char**, char*);
 
-#if defined(__linux__)
+#if defined(__DragonFly__)
+static inline int d_reclen(struct dirent *de) { return _DIRENT_DIRSIZ(de); }
+#else
+static inline int d_reclen(struct dirent *de) { return de->d_reclen; }
+#endif
+
 static int
 mygetdents(int fd, struct dirent *buf, int n)
 {
-   off_t off;
-   int nn;
+   int err, nn;
+   DIR *dirp;
+   
+   /* use to calculate max size of a dirent */
+   struct dirent de;
+   int max_sz = (sizeof de - sizeof de.d_name) + NAME_MAX + 1;
+
+   if ((dirp = fdopendir(dup(fd))) == nil)
+   return -1;
 
-   /* This doesn't match the man page, but it works in Debian with a 2.2 
kernel */
-   off = p9seek(fd, 0, 1);
-   nn = getdirentries(fd, (void*)buf, n, );
+   nn = 0;
+   while(n >= max_sz){
+   if ((err = readdir_r(dirp, buf, )) != 0){
+   errno = err;
+   if(nn == 0)
+   nn = -1;
+   break;
+   }
+   if (buf == nil)
+   break;
+   nn += d_reclen(buf);
+   n -= d_reclen(buf);
+   buf = ((char*)buf) + d_reclen(buf);
+   }
+   closedir(dirp);
return nn;
 }
-#elif defined(__APPLE__) 
-static int
-mygetdents(int fd, struct dirent *buf, int n)
-{
-   long off;
-   return getdirentries(fd, (void*)buf, n, );
-}
-#elif defined(__FreeBSD__) || defined(__DragonFly__)
-static int
-mygetdents(int fd, struct dirent *buf, int n)
-{
-   off_t off;
-   return getdirentries(fd, (void*)buf, n, );
-}
-#elif defined(__sun__) || defined(__NetBSD__) || defined(__OpenBSD__)
-static int
-mygetdents(int fd, struct dirent *buf, int n)
-{
-   return getdents(fd, (void*)buf, n);
-}
-#elif defined(__AIX__)
-static int
-mygetdents(int fd, struct dirent *buf, int n)
-{
-   return getdirent(fd, (void*)buf, n);
-}
-#endif
-
-#if defined(__DragonFly__)
-static inline int d_reclen(struct dirent *de) { return _DIRENT_DIRSIZ(de); }
-#else
-static inline int d_reclen(struct dirent *de) { return de->d_reclen; }
-#endif
 
 static int
 countde(char *p, int n)

Re: [9fans] p9p: 9 ls /dev

[David Arroyo]

This should be doable with some combination of fdopendir(3) and
readdir(3).
I'm not sure how to avoid leaking memory through the returned DIR
pointer
and any memory allocated with by readdir(3). This is usually free'd by
closedir(3),
which we can't use without closing the underlying file.

It should be OK to use free() on the return value of fdopendir, and
stick to the
uglier readdir_r(3) interface. I can definitely see why Russ went with
the simpler
system-specific interfaces on this.

David

On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
> On Sat, 8 Apr 2017 15:21:47 +0900, arisawa  wrote:
> 
> > but how to?
> > 
> > unix doesn’t have something like fdreaddir(int fd).
> > my guess: russ unwillingly used a low level function such as
> > int getdirentries(int fd, char *buf, int nbytes, long *basep).
> > 
> > readdirall() might be OK in regular usage.
> 
> I don't use OSX regularly, although I do maintain the syscall
> layer for Myrddin on it.
> 
> Getdirentries64 exists, and rudimentary testing doesn't show
> any difficulties with using it.
> 
> -- 
> Ori Bernstein
> 

Re: [9fans] DNS

[David Arroyo]

I had a similar problem with 'dnscache' from the TinyDNS suite of tools a
couple years back. Certain DNS names hosted in AWS Route53 would exceed the
max number of requests to be resolved at random, because Route53 randomized
the NS records it gave for each subdomain, so every once in awhile during
the dns 'walk' dnscache would have to resolve their .net, .co.uk, .org, and
.com NS records, which blows up the number of resolutions pretty quickly.
Akamai has the same problem. The internet was much simpler 20 years ago :\.

David

On Sat, Apr 1, 2017 at 10:04 AM Steve Simon  wrote:

> possibly.
>
> however it didn't take the plan9 community long to figure out what needed
> to be changed. Thus, by definition, it was not too obscure.
>
> -Steve
>
> > On 1 Apr 2017, at 10:46, Alexandru Gheorghe 
> wrote:
> >
> > That's a weird name for CNAME traversing. Should've been (maybe more
> > appropriately): "MaxCnameDepth".
> >
> >
> >> On 04/01/2017 04:40 AM, Skip Tavakkolian wrote:
> >> Maxretries to > 5
> >
> > --
> > ;   Alexandru Gheorghe
> > ;
> > ; 
> >
>
>
>

Re: [9fans] 9pfuse and u9fs

[David Arroyo]

I have definitely used 9pfuse to mount a u9fs file server before. What auth 
method did you choose for u9fs?

David 

On February 16, 2016 5:20:51 AM EST, arisawa  wrote:
>Hello 9fans,
>
>my 9pfuse on macbook works fine in communicating plan9 file server.
>however mounting u9fs fails with the message:
>-bash$ 9pfuse /srv/mmac /n/mmac
>9pfuse: fsmount: fid unknown or out of range
>-bash$ 
>how to understand this message?
>does anyone succeed in mounting u9fs?
>
>it would be great if 9pfuse can mount u9fs
>
>Kenji Arisawa

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [9fans] Acme Edit scriptlets

[David Arroyo]

I took the template.awk script from werc[0] and use it in acme all the
time. I've a collection of template files beginning with

Edit ,|tpl
% var1=val1
% var2=val2
...

I can execute line 1 to generate stuff like Makefiles, man pages, puppet
manifests, etc.[1]

[0]: http://hg.cat-v.org/werc/file/50a9b770bb43/bin/template.awk#l1
[1]: http://aqwari.us/notes/werctpl


On Thu, Apr 4, 2013 at 9:01 AM, Bence Fábián beg...@gmail.com wrote:

 whoa. nice job.



 2013/4/4 erik quanstrom quans...@quanstro.net

 On Thu Apr  4 08:17:13 EDT 2013, beg...@gmail.com wrote:

  Cool.
 
 
  Here's a script i use to generate case
  insensitive regexes. It turns
 
  FooBar
 
  into
 
  [Ff][Oo][Oo][Bb][Aa][Rr]

 see also rune(1), http://9atom.org/magic/man2html/1/rune
 which generalizes this idea to all of unicode (rune/case),
 and also to diacritical and other markers (rune/fold; rune/unfold).
 for the latter also see grep(1)'s -I flag,
 http://9atom.org/magic/man2html/1/grep

 - erik

Re: [9fans] raspberry pi plan 9 image

[David Arroyo]

I cannot connect via 9P either:

% 9fs sources
srv: timeout establishing connection to tcp!sources.cs.bell-labs.com!9fs

Perhaps they are doing some server maintenance. Or maybe my ISP wasn't
ready for a snowstorm in late March.

-David


On Tue, Mar 19, 2013 at 9:45 PM, Jeremy Jackins jeremyjack...@gmail.comwrote:

 500.


 On Tue, Mar 19, 2013 at 7:36 PM, Jacob Todd jaketodd...@gmail.com wrote:

 What error are you getting?

Re: [9fans] PBSR...EI

[David Arroyo]

On Tue, Jan 15, 2013 at 1:54 AM, erik quanstrom quans...@quanstro.net
wrote:
 the server is willing, but the network is weak.  ☺
 i'm evaluating some options now.  unfortunately, they're
 not cheap.

Have you considered using torrent? I'd be happy to seed it and I'm sure
others would too.

David Arroyo

Re: [9fans] Too big a monitor for Acme?

[David Arroyo]

Sorry, I run plan9 as a CPU server use drawterm on windows.

On Mon, Dec 31, 2012 at 6:32 AM, Peter A. Cejchan tyap...@gmail.com wrote:
 27 2560x1440 display. It's pretty great to have four wide columns

 If you are on native Plan9, what graphics card do you use?

 Thanks, regards,
 ++pac

Re: [9fans] Too big a monitor for Acme?

[David Arroyo]

Acme workflow scales absolutely fantastically to a large monitor. I
would say it is one of Acme's strong points. I recently upgraded to a
27 2560x1440 display. It's pretty great to have four wide columns
(five if you have a thin one for directory listings) in a single
window. The mouse-warping helps a lot with the increased area. So if
you have some unique setup that doesn't properly move your mouse (like
using Xming on windows to run p9p acme on a remote unix host), you'll
want to get that looked at.

Cheers,
David A.

On Fri, Dec 28, 2012 at 7:25 PM, Matthew Veety mve...@gmail.com wrote:
 It works great. More columns the better really.

 On Dec 28, 2012, at 19:12, Jacek Masiulaniec jac...@dobremiasto.net wrote:

 I am planning an upgrade of my 24 display. At first I wanted a 30,
 but am now having some doubts regarding acme experience on these
 larger displays.

 Did you notice significant mousing overhead, owing to the area increase?

 Were speed/acceleration tweaks sufficient to mask it?

 Any report is welcome, as I have no test system.

 Thanks.

 Jacek

Re: [9fans] Uriel

[David Arroyo]

It's always such a shock when an online correspondence dies, you can
never tell someone's health on the other side of an irc chat unless
they want to broadcast it, so every loss seems so sudden, and so
untimely. At least now he's in a world without XML :)

RIP

On Sun, Oct 14, 2012 at 6:11 PM, Francisco J Ballesteros n...@lsub.org wrote:
 sad news.
 he was quite young, also. :(
 r.i.p.

 On Oct 14, 2012, at 10:17 PM, Devon H. O'Dell devon.od...@gmail.com wrote:

 He was certainly a lively and unique character in person and on the
 various lists / channels he frequented. RIP.

 --dho

 2012/10/14 Calvin Morrison mutanttur...@gmail.com:
 On 14 October 2012 15:55, Sergey Zhilkin szhil...@gmail.com wrote:
 Oh  F*ck...
 R.I.P

 Bad news.

 воскресенье, 14 октября 2012 г. пользователь Julius Schmidt писал:

 I am very sorry to inform you that uriel has passed away recently.

 He will be missed.



 --
 Sent from Gmail Mobile

 I'm speechless.