From: ············@wildcard.demon.co.uk (Martin Rodgers)
We have a similar situation today, where most users have less powerful
machines than the developers of the apps they use. I'm not saying that's
a bad thing, but I _am_ concerned about history repeating itself.
Apple's description of their Apple Dylan environment at the WWDC roll-out
described an interesting approach that may mitigate this problem. It's not
really a new approach, but is one that I haven't seen in Lisp or other
dynamic systems lately. We're looking at something similar for Gwydion.
What they described is a system in which the debugging/development stuff
lives in one process, but the running code for the application being
developed and tested lives in a separate "application nub" which can be in
another process or another machine. The debugging tools reach across the
gap to monitor, tweak, and modify the running application and to down-load
new versions. (I don't know how they do this multiple-processes stuff on a
single Mac, unless they're using next year's operating system -- maybe you
don't get a firewall unless you have two Macs.)
So the application software could, in priciple, be run on whatever machine
the typical user is going to have, while the developer still has all his
heavy artillery at hand. The problem, of course, is making the cooperation
between the application and the debugging tools as intimate as we get in a
language like Lisp, and doing so without perturbing the experiment (the
application nub) too much from what it will look like at delivery time.
Interesting problem.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213
===========================================================================
In article <··········@cantaloupe.srv.cs.cmu.edu>,
···@sef-pmax.slisp.cs.cmu.edu wrote:
|What they described is a system in which the debugging/development stuff
|lives in one process, but the running code for the application being
|developed and tested lives in a separate "application nub" which can be in
|another process or another machine. The debugging tools reach across the
|gap to monitor, tweak, and modify the running application and to down-load
|new versions. (I don't know how they do this multiple-processes stuff on a
|single Mac, unless they're using next year's operating system -- maybe you
|don't get a firewall unless you have two Macs.)
Er, they're just two different applications running at the same time; much
the same as when developing with Symantec/CodeWarrior c[++].
The MacOS has long been capable of having multiple applications running...
--
--
--
-- "TANSTAAFL" Rich ·····@ils.nwu.edu
In article <··········@cantaloupe.srv.cs.cmu.edu>
···@sef-pmax.slisp.cs.cmu.edu writes:
> Interesting problem.
Yes, a real challenge. I'll be happy to see them accomplish this
technical hurdle, as it's one that I suspect a lot of developers
have been waiting for. I know that there're remote debuggers
around. In fact, my last C++ compiler uprade included a remote
debugger. That's part of the solution, but it's not complete,
as the workbench enviroment still expects you to run the app
on the same machine. All the other commercial C++ compilers that
I know about work the same way.
--
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <··········@cantaloupe.srv.cs.cmu.edu>, ···@sef-pmax.slisp.cs.cmu.edu writes:
|> From: ············@wildcard.demon.co.uk (Martin Rodgers)
|>
|> We have a similar situation today, where most users have less powerful
|> machines than the developers of the apps they use. I'm not saying that's
|> a bad thing, but I _am_ concerned about history repeating itself.
|>
|> Apple's description of their Apple Dylan environment at the WWDC roll-out
|> described an interesting approach that may mitigate this problem. It's not
|> really a new approach, but is one that I haven't seen in Lisp or other
|> dynamic systems lately. We're looking at something similar for Gwydion.
|>
|> What they described is a system in which the debugging/development stuff
|> lives in one process, but the running code for the application being
|> developed and tested lives in a separate "application nub" which can be in
|> another process or another machine. The debugging tools reach across the
|> gap to monitor, tweak, and modify the running application and to down-load
|> new versions. (I don't know how they do this multiple-processes stuff on a
|> single Mac, unless they're using next year's operating system -- maybe you
|> don't get a firewall unless you have two Macs.)
I used this same two-address-space approach for my Parallel Common Lisp.
The "debugger" ran on a TI Explorer Lisp Machine,
and the "target" ran on the Unix multiprocessor. There was a simple debug-process
on the Unix box which shared the same address space with the target Lisp system,
and communicated with the "debugger" system, sending signals to the target Lisp
processes to control it. I called it "Meta Debug."
It turned out this was critical for a parallel system, since you want to
"freeze" everything on the multiprocessor to see what's going on,
and the Lisp debugger just plain can't run when everything is stopped --
e.g., it can't intern symbols, etc.
Further extensions were planned for implementing a static delivery system which
would have all the internal data stripped out and kept only in the "debugger" system,
but I never had time to get that far. Looks like the Apple Dylan people
have taken the same tack. In fact, just like I used the great Lisp environment
of the TI Lisp Machine as the development system, I understand that
the development system/application database is
implemented using ... Macintosh Common Lisp.
--
- Kelly Murray (···@prl.ufl.edu) <a href="http://www.prl.ufl.edu">
-University of Florida Parallel Research Lab </a> 96-node KSR1, 64-node nCUBE