9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Ole-Hjalmar Kristensen <ole.hjalmar.kristensen@gmail.com>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] The development environment from Hell
Date: Tue, 25 Jan 2022 13:51:27 +0100	[thread overview]
Message-ID: <CAHqDL_95y-RV9ppsf4bxBCjGLqDQX-Ncu9Q3RKO0CSzWZ=7KPA@mail.gmail.com> (raw)
In-Reply-To: <CAPtk8ts-QwjOyJetZUNjBZei5guNYWG0HDe=dJ-LaYhR4btv-g@mail.gmail.com>

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

Seems to work very well. Excellent! There is one thing that is a bit
strange, though. Unless I explicitly list my home directory as one of the
remote paths, acme simply does not connect to the remote machine at all. No
big deal, though.
Another slight issue is that because acme loads whole files, opening a huge
file may take quite a bit of time. Sam avoids this issue by only loading
the file on the remote, and transfers only what is needed to refresh the
display. But that's just a different tradeoff. All in all I think I prefer
your acme, especially since it can run acme-lsp on the remote.

On Wed, Jan 12, 2022 at 5:06 AM marius a. eriksen <marius@monkey.org> wrote:

> > 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
> <https://gist.github.com/mariusae/a7b13730b7c5aa08f32b30a64f31856b> 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
> <https://www.mail-archive.com/9fans@9fans.net/msg39249.html> for some
> more details.
>
>
>
>
> On Thu, Oct 21, 2021 at 11:16 AM Ole-Hjalmar Kristensen <
> ole.hjalmar.kristensen@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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T73fbb7a533aef743-M93b4aacc25801f87ee0a8666>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T73fbb7a533aef743-M810ea0adc28e1ab2b77de79c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

      reply	other threads:[~2022-01-25 12:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 18:15 Ole-Hjalmar Kristensen
2021-10-21 21:30 ` Robbin Johnson
2021-10-21 23:55   ` Conor Williams
2021-10-22 12:07 ` Maurizio Boriani
2022-01-12  4:05 ` marius a. eriksen
2022-01-25 12:51   ` Ole-Hjalmar Kristensen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHqDL_95y-RV9ppsf4bxBCjGLqDQX-Ncu9Q3RKO0CSzWZ=7KPA@mail.gmail.com' \
    --to=ole.hjalmar.kristensen@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).