Re: [9fans] The development environment from Hell

[marius a. eriksen]

> So I thought about sam, which I also like, although I have not used it as
much as acme. Sam has remote editing, which solves the latency and
bandwidth problem, but I prefer the acme right-click to navigate
compilation errors and grep results. So, can we combine acme and sam in a
meaningful way? It turns out we can. From a local acme, I connect to the
remote Docker in one or more acme windows. This is for compilation and
grep. By adding plumber rules which sends any file which cannot be found
locally to the remotely connected sam, I can right-click on errors and grep
results and get sam to go there. The only thing is that to avoid recursion
in the plumber, I must specifically route the message to the sam named pipe
instead of to the edit port, which means I need to start sam before the
plumber. Also, I have not investigated how I can access the remote clangd
from my local acme.

An alternative is this patch
 which
implements a proper remoting layer for Acme. (Very similar to the way Sam
does it: it starts a server over ssh, and then ferries 9p back and forth.)

I use this as my daily driver, and it's _very_ close to a local experience.

See this thread 
for some more details.




On Thu, Oct 21, 2021 at 11:16 AM Ole-Hjalmar Kristensen <
ole.hjalmar.kristen...@gmail.com> wrote:

> Not exactly Hell, but rather close:
> ISPOrganizationLatitudeLongitude
> NTE Marked AS Not Available 63.4333 10.6833
> 
>
> This is the tale of a convoluted development environment, not specifically
> Plan9, but Plan9port, sam, and acme.
>
> I am working on a largish system, with about 5M LOC. The setup is as
> follows. I have a Windows laptop. It needs to be Windows, because of the
> office automation applications. It is also the only machine I have at home
> which can connect to the company VPN. The office desktop is a nice modern
> AMD Ryzen 9 16-core processor with plenty of RAM running Ubuntu. The system
> cannot (for reasons beyond my control) be compiled on the Ubuntu, it needs
> specifically CentOS 7, so we run a Docker image with CentOS 7 on the Ubuntu
> machine. Compiling on the laptop is a no-go anyway, it is much too slow, so
> I have not bothered installing WSL and Docker on it.
>
> I started out running VSCode, which is available both on Windows and
> Ubuntu, and which has nice remote editing capabilities a la sam, and tons
> of plugins. It is a better experience then Visual Studio, in my opinion. It
> has a clangd plugin which can be used to navigate the code, but for some
> reason clangd chokes on some submodules. acme with acme-lsp gives me the
> same navigation capabilities, and I prefer the user interface of acme, so I
> have reverted to acme on the Ubuntu machine. Works great, I use acme-lsp on
> the modules clangd manages to compile, and ag (parallel grep-like tool) on
> the rest. So in the office, everything is hunky-dory. I connect to the
> Docker image from acme by running win docker exec, and since both Docker
> and the Ubuntu machine has the same view of the files, everything works
> seamlessly.
>
> When working from home, acme is not an ideal solution, since the VPN
> network has high latency and relatively low bandwith (a fraction of my
> 500Mbit fiber connection). I run an X server on Windows, and start acme on
> the Ubuntu machine. Editing files works fairly well, but commands which
> spew large amounts of text really bogs acme down. I could switch to VSCode,
> but I would prefer not to.
>
> Now, I have experimented with other solutions which could give me a better
> experience. Running sshfs and a local acme would be one possibility, but it
> is not really fast enough for searching through the code. (I can search the
> 5M lines code base in about 2 seconds with ag on the desktop machine).
> Copying the whole system to the local machine and do the editing locally,
> then run Unison to synchronize, is another possibility, but not ideal.
>
> So I thought about sam, which I also like, although I have not used it as
> much as acme. Sam has remote editing, which solves the latency and
> bandwidth problem, but I prefer the acme right-click to navigate
> compilation errors and grep results. So, can we combine acme and sam in a
> meaningful way? It turns out we can. From a local acme, I connect to the
> remote Docker in one or more acme windows. This is for compilation and
> grep. By adding plumber rules which sends any file which cannot be found
> locally to the remotely connected sam, I can right-click on errors and grep
> results and get sam to go there. The only thing is that to avoid recursion
> in the plumber, I must specifically route the message to the sam named pipe
> instead of to the edit port, which means I need to start sam before the
> plumber. Also, I have not investigated how I can access the remote clangd
> from my local acme.
>
> What do you think? Suggestions?
> 

[9fans] plan9port: acme remoting

[marius a. eriksen]

Lately, I have needed to do a great deal of my work on remote servers. It's
been difficult to do this with acme. Previously, I have attempted to run
acme entirely remotely, and then attach to a local devdraw instance
. This works okay, but also has
many drawbacks, among which: (1) it's not economical with networking, and
so not great for high latency or otherwise poor connections; (2) it's not
resilient to connection disconnects; (3) often I want access to local
resources too.

I built an experimental remoting layer in acme to see how far I could get
in recreating a modern "remoting" experience with acme. Since acme itself,
of course, is designed around a bunch of 9p servers, this turned out to be
fairly easy to do, and the resulting experience is nearly transparent.

A remote may be attached to one or more path prefixes. These are similar to
mount points in a file system. Thus, if the prefix /home/meriksen is
attached to the remote "dev", then any file with this prefix is transparely
fetched from the dev. Similarly, when commands are run from any directory
with this prefix, the command is transparently run on the remote. The
command is run in an environment that includes the acme and plumber 9p
servers (forwarded from the local host), and so even acme programs just
work. For example, if you run 'win' from a directory that is attached to a
remote, 'win' is run on the remote host, but it accesses the acme 9p file
tree (which is forwarded from the local acme) and creates its window and
interacts with acme. It "just works". (I regularly run other programs like
this too, e.g., acme-lsp, which uses the plumber to coordinate interaction).

The design of the feature is quite simple: a new program, acmesrv
 is
run by acme (through ssh) on the remote host. Acme becomes a client of
acmesrv, through which all further interaction is facilitated. Acmesrv
itself is really just a 9p multiplexer: the local acme program exports the
acme and plumber 9p servers; acmesrv provides two new 9p servers (exportfs
and cmdfs) that gives the local acme access to the remote's file system
(exportfs) and to run commands (cmdfs).

The local acme manages a session for each remote, and properly deals with
session disconnect/reconnect, etc. Thus, poor network conditions and
disconnects are easily supported. Since acme's file handling is anyway
stateless (the file is not kept open during editing), file state is easily
maintained through disconnect-reconnect cycles.

There are some synchronous code paths in acme, and these may cause
temporary freezes when using remoting. For example, when acme queries for
the existence of a file (stat), this blocks UI updates in acme. On session
establishment (e.g., the first time a file is accessed on a remote), this
can cause additional delays, since the file cannot be queried before first
establishing a new session. I've not found this to be a big deal.

This has been my "daily driver" for about a month at this point, and
overall I'm very happy with the experience. It creates a nearly transparent
experience editing remote files, and retains most of acme's functionality
in remote settings as well. I never hesitate to shut my laptop lid while in
the middle of a project. Most things just work. There are wrinkles, of
course, and there are some sharp edges in this (experimental)
implementation, but, to me, this provides really very useful functionality
that lets me use acme in more challenging environments. (Not to mention
that this means I can use a beefy remote host for heavy lifting.)

In case this would be useful to anyone else, this version of acme resides
in my plan9port tree on github
.
(Currently, these diffs: 1
,
2
,
3
,
4

.)

-m.

(And of course, I realize that this approach goes against the spirit of
acme and plan9 -- acmesrv here is recreating a very specific slice of
functionality that could be recreated by standard means if we had real
filesystems. But we don't live in that world, and this is immensely useful
to me.)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230
Delivery options: 

[9fans] Slashed zero in Lucida Grande (macOS)

[marius a. eriksen]

I recently read "Oh, oh, zero!"
 by Charles Bigelow,
where he mentions that Lucida Grande contains an alternative glyph for zero
that is slashed:

"In Lucida Grande, based on Lucida Sans, the numeral one is reworked with
baseline serifs but the default zero and Oh are the same as in the original
version. The Lucida Grande font also includes both slashed and dotted
versions of zero, as well as a seriffed variant of capital I, but these are
not the default forms."

Intrigued, I went poking about macOS's font book, and sure enough it's
there; but it's not accessible via the standard OpenType alternate style
sets. However you can get to it quite easily with a little lower level
glyph substitution.

Here's a patch for fontsrv
 for
macOS that substitutes the slashed zero when available. It's very pleasant
to use in practice. (Small screenshot attached.)

[image: Screen Shot 2019-04-02 at 6.35.40 PM.png]

-m.

[9fans] Proof of concept inertial scrolling on macOS with devdraw/acme

[marius a. eriksen]

It’s surprisingly pleasant to use (with a Mac laptop, a Magic Trackpad or
aMagic Mouse)

Demo here: https://www.youtube.com/watch?v=1XJFJ4coS48=youtu.be

commit d782c880d4ca30fcacddfbab298dad82fe8277c3
Author: marius a. eriksen <mar...@grailbio.com>
Date:   Sat Feb 25 21:48:50 2017 -0800

devdraw/acme: support for inertial scrolling on macOS.

diff --git a/src/cmd/acme/acme.c b/src/cmd/acme/acme.c
index b471a29..d84322f 100644
--- a/src/cmd/acme/acme.c
+++ b/src/cmd/acme/acme.c
@@ -614,6 +614,14 @@ mousethread(void *v)
  }
  /* scroll buttons, wheels, etc. */
  if(w != nil && (m.buttons & (8|16))){
+ if((m.buttons >> 2) != 0){
+ winlock(w, 'M');
+ t->eq0 = ~0;
+ xtextscroll(t, m.buttons>>2);
+ winunlock(w);
+ goto Continue;
+ }
+
  if(m.buttons & 8)
  but = Kscrolloneup;
  else
diff --git a/src/cmd/acme/text.c b/src/cmd/acme/text.c
index 7634d92..72b29c2 100644
--- a/src/cmd/acme/text.c
+++ b/src/cmd/acme/text.c
@@ -653,6 +653,35 @@ textcomplete(Text *t)
  return rp;
 }

+void
+xtextscroll(Text *t, int n)
+{
+ uint q0;
+
+
+ if(n == 0)
+ return;
+
+ if(t->what == Tag){
+ if(n<0)
+ texttype(t, Kscrolloneup);
+ else
+ texttype(t, Kscrollonedown);
+ return;
+ }
+
+ fprint(2, "n=%d\n", n);
+
+ if(n < 0){
+ n = -n;
+ q0 = t->org+frcharofpt(>fr, Pt(t->fr.r.min.x,
t->fr.r.min.y+n*t->fr.font->height));
+ textsetorigin(t, q0, TRUE);
+ }else{
+ q0 = textbacknl(t, t->org, n);
+ textsetorigin(t, q0, TRUE);
+ }
+}
+
 void
 texttype(Text *t, Rune r)
 {
diff --git a/src/cmd/devdraw/cocoa-screen.m b/src/cmd/devdraw/cocoa-screen.m
index 100cdd5..b83a3ff 100644
--- a/src/cmd/devdraw/cocoa-screen.m
+++ b/src/cmd/devdraw/cocoa-screen.m
@@ -1044,7 +1044,8 @@ static void
 getmouse(NSEvent *e)
 {
  float d;
- int b, m;
+ int b, m, i;
+ static int accum;

  if([WIN isKeyWindow] == 0)
  return;
@@ -1080,11 +1081,22 @@ getmouse(NSEvent *e)
 #else
  d = [e deltaY];
 #endif
+
+
+// fprint(2, "delta: %d\n", (short)d);
+
+ //fprint(2, "d: %f %d\n", d, [e hasPreciseScrollingDeltas]);
+
+ if((short)d==0)
+ return;
+
  if(d>0)
  in.mscroll = 8;
  else
  if(d<0)
  in.mscroll = 16;
+
+ in.mscroll |= ((short)d)<<1;
  break;

  case NSMouseMoved:

Re: [9fans] Acme real estate on 15 macbook pro?

[marius a. eriksen]

I use a 13” rMBP at the highest resolution setting. I run acme with 3 columns 
(though the leftmost column is a shrunk column that’s really only useful for 
directory browsing).

The only annoyance is that I regularly connect to an external display, which 
requires me to restart acme. Instead of messing with -f, -F flags, I make dumps 
(which store font settings). I restart acme with

acme -l lodpi.dump
acme -l hidpi.dump

depending on where I am.

-m.

Re: [9fans] p9p on Retina Macs

[marius a . eriksen]

Thanks for the pointers.

I finally did some sleuthing and experimentation.

Indeed, devdraw now knows about a display’s DPI, and launching a devdraw app 
with environment devdrawretina=1 enables detection of retina displays, and 
setting the current DPI accordingly.

DPI seems to affect a few things:

1. computing geometries of fixed-sized UI elements like scroll bars
2. computing scroll “ticks”

⌘-R toggles the current DPI from “retina” (220 DPI) to “non-retina” (110 DPI).

There doesn’t seem to be any sort of built-in font scaling at the moment. So 
when you launch, say, acme on a retina machine, you’ll have to supply your own 
(larger) font. I ended up using fontsrv with system fonts:

% devdrawretina=1 acme -f /mnt/font/HelveticaNeue-Medium/24a/font -F 
/mnt/font/Menlo-Regular/22a/font 

seems to work pretty well.

-m.

Re: [9fans] devdraw proxy

[marius a. eriksen]

devdrawserver is something along these lines:

https://github.com/mariusaeriksen/devdrawserver

-marius

[9fans] Plot(1) broken on p9p OSX?

[marius a. eriksen]

Graph(1) seems to work:

% @{echo 1; echo 2; echo 3} | graph -a
o
ra 0 0 4096 4096
e
li 200 200 4000 200
v 4000 4000
v 200 4000
v 200 200
li 1150 200 1150 4000
li 2100 200 2100 4000
li 3050 200 3050 4000
li 200 1150 4000 1150
li 200 2100 4000 2100
li 200 3050 4000 3050
m 200 140
t 0 = x = 2, 1 = y = 3
pe solid
co kblack
m 200 200
v 2100 2100
v 4000 4000
pe solid
cl

But not plot(1):

% @{echo 1; echo 2; echo 3} | graph -a | plot

Yields only a lonely, blank window.

Has anyone gotten this to work?

-marius

Re: [9fans] Plot(1) broken on p9p OSX?

[marius a. eriksen]

Interesting. Which version of OSX is this? I'm running Mountain Lion.

-marius

Re: [9fans] Using Acme Remotely

[marius a. eriksen]

You can also use devdrawserver:

   https://github.com/mariusaeriksen/devdrawserver

Which acts as a devdraw proxy between two machines.

See also: http://9fans.net/archive/2012/04/207

marius.

On Fri, Oct 26, 2012 at 9:57 AM, erik quanstrom
quans...@labs.coraid.com wrote:
 Unfortunately acme doesn't have provisions for remote editing, however
 you can edit any file on any file system you happen to import into
 your namespace.

 If you wish to edit within Plan 9 natively, I'd look into one of the
 many options to connect to a remote system using a file system
 interface 
 (http://www.plan9.bell-labs.com/wiki/plan9/Integration_with_other_OSs/index.html).

 If you are interested in using acme on other systems, rsc's plan9port
 (http://swtch.com/plan9port/) could be of some use to you. acme-sac
 (http://code.google.com/p/acme-sac/) is another possibility and
 provides support for Windows as well.

 sftpfs works great in a pinch with stuart's ssh2.

 - erik

[9fans] devdrawserver

[marius a. eriksen]

I've found myself in need of running acme on one machine, but devdraw
on another. Since p9p devdraw isn't a file server, exporting and
importing the devdraw server isn't something you can do without extra
help: that's where devdrawserver comes in:

  https://github.com/mariusaeriksen/devdrawserver

it provides a virtual devdraw on the remote machine, and the ability
to attach a real devdraw binary to the stream.

There's a bit of extra code in there, because eventually I might also
add detach/reattach to this (but I haven't really needed it yet).

marius.

*

mk install, then follow the instructions in the README

[9fans] OSX lion + libthread

[marius a. eriksen]

i never could get libthreaded applications to run properly in OSX Lion.

i've tried with both XCode 4.1 and 4.2.

however, disabling -O2 seems to do the trick. go figure. haven't tried that on 
XCode 4.1-- but would be curious to hear results.

marius.

¶

diff -r 8735d7708a1b bin/9c
--- a/bin/9cTue Oct 11 09:34:25 2011 -0400
+++ b/bin/9cTue Oct 11 23:04:58 2011 -0700
@@ -5,7 +5,6 @@
 {
cc=${CC9:-gcc}
ngflags= \
-   -O2 \
-c \
-Wall \
-Wno-parentheses \