9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] find acme 'window' name from which program B2-ed?
Date: Thu, 13 Oct 2005 00:48:37 +0200	[thread overview]
Message-ID: <200510122248.j9CMmb720817@zamenhof.cs.utwente.nl> (raw)
In-Reply-To: Your message of "Tue, 11 Oct 2005 17:19:12 -0400." <ee9e417a0510111419l79967af6y4c9663ec79121a@mail.gmail.com>

> > can I easily simulate B3 in box? (I can look this one up in the man)
> 
> Not without changing the source code.
> 
> One alternative is to make your "Next" program
> replace the current window contents instead of
> creating a new one.

This is what I realized (I think I posted a version of a script in a
followup posting. since then I learned and the script changed :-)

I have been wondering if it might be useful to have a 'clean'
version of a replacement script ('repl'?) in /acme/bin next
to 'new' -- if only as example for those looking for them --
my "Next" then only has to come up with the right
file name which it then passes to ``repl''.

Today I used it, and with lucidasans.13 it was pretty ok.
Only thing was that I mounted the text files via u9fs from
a sun that mounts via nfs from the central file server,
so updating the window was less quick that when all would
have been local.
I had intended to also embed commands to raise (vnc) windows
containing demo stuff but did not have time for that.

(actually, we were discussing tool integration, but the nice
 integration on the presentation system was likely missed by
 the audience... one of the more interesting parts of the
 discussion was on how to connect tools or tool components
 that have to interact with each other - typical case in our
 world would be a tool component capable of (on demand)
 unfolding (exploring) a state space, and a tool compoent
 actually traversing the state space - I would be tempted
 to make those into two separate programs and connect them
 on the shell level (which may be a bit too loosely
 coupled for the real world, think tools like spin?).
 other suggestions were to have some kind of common
 (library, oo?) infrastructure on which (in which)
 all is built - and thus have (possibility) of much tighter
 connection - nevertheless, the idea of being forced to
 use a particular library/language infrastructure does
 not sound too attractive,  and it will not work with
 external tools outside our control. oh well, we ran out
 of time before we ran out of discussion, we'll see...)

Axel.


  reply	other threads:[~2005-10-12 22:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-11 20:12 Axel Belinfante
2005-10-11 21:19 ` Russ Cox
2005-10-12 22:48   ` Axel Belinfante [this message]
2005-11-28 20:49     ` Russ Cox
2005-10-11 20:47 Federico G. Benavento
2005-10-11 22:12 ` Axel Belinfante

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=200510122248.j9CMmb720817@zamenhof.cs.utwente.nl \
    --to=axel.belinfante@cs.utwente.nl \
    --cc=9fans@cse.psu.edu \
    /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).