Subject: [Gcl-devel] RE: [Maxima] Re: Maxima cmucl patch
From: Richard Fateman
Date: Mon, 02 Feb 2004 08:19:36 -0800
I am not sure what Stavros was referring to, but I
often use dynamically defined programs .. every time
I use "trace".
(trace foo) works by redefining the program foo,
essentially doing
(setf old-program (symbol-function 'foo))
(setf (symbol-function 'foo) (tracing-program old-program))
;; plus a lot of checking so that (untrace) works and reloading works..
I also often re-load programs when I discover a bug and fix it.
In some cases the maxima system may define itself differently depending
upon environmental information, e.g. when the same code is run
on linux vs windows vs solaris.
Typically the same debuggers work on interpreted vs. compiled code,
e.g. trace. Though there may be less information in compiled code.
Camm Maguire wrote:
>Greetings!
>
>"Stavros Macrakis" <stavros.macrakis@verizon.net> writes:
>
>
>
>>If you don't have a system definition within the Lisp system (or at
>>least accessible to it), how do you support interpretive execution? In
>>the Maxima context, how would you go about integrating
>>dynamically-defined Maxima programs into the build system? Are there
>>good debuggers available for non-interpretive execution?
>>
>>Of course in principle you could make all this work in a compiled
>>environment, but....
>>
>>
>>
>
>That's interesting, if I understand you correctly. Is there any
>available real-world system making use of 'dynamically-defined'
>programs and routines? If your system generates a function at runtime
>and decides to compile it, why does it need to know where it is on a
>dependency tree?
>
>While your at it, though this is somewhat off topic -- could you
>please explain to me to what lisp development experts are referring
>when they tout the ability to modify a running program? The closest
>procedure I can imagine fitting this description would be to fire up
>gdb, attach to a running daemon, break at a point, 'p var =
>new_value', 'detach'. Of course the program is not 'running' when
>stopped. Operations on sql databases have a similar quality. But as
>far as I know, barring more recent developments such as multithreaded
>extensions, lisp has a single flow of control. Perhaps is meant
>executing a saved image, modifying, saving the image, and copying that
>to the location used in future invocations?
>
>Take care,
>
>
>
>
>> -s
>>
>>PS Even if Maclisp and other earlier systems did not have
>>fully-integrated editors (Emacs front ends ran in a separate workspace),
>>you did "live in" the Lisp system in the sense of loading new versions
>>dynamically and incrementally rather than rebuilding the system.
>>
>>
>>
>>_______________________________________________
>>Gcl-devel mailing list
>>Gcl-devel@gnu.org
>>http://mail.gnu.org/mailman/listinfo/gcl-devel
>>
>>
>>
>>
>>
>
>
>