From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200510122248.j9CMmb720817@zamenhof.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? In-reply-to: Your message of "Tue, 11 Oct 2005 17:19:12 -0400." References: <200510112012.j9BKCL815892@zamenhof.cs.utwente.nl> From: Axel Belinfante MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20813.1129157317.1@zamenhof.cs.utwente.nl.cs.utwente.nl> Date: Thu, 13 Oct 2005 00:48:37 +0200 Topicbox-Message-UUID: 9a189502-ead0-11e9-9d60-3106f5b1d025 > > 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.