Hi
are there any efforts/URLs with regards to integrating/using OpenMCL
with ProjectBuilder and InterfaceBuilder on OSX?
all I could find was this screenshot at
http://lemonodor.com/archives/images/openmcl-ide-rainer.png
but nothing that explained how to set something like this up.
Also, I would like to know if anyone has managed to or has an idea how
to run a listener from within ProjectBuilder.
thanks in advance
rgds
bk
·········@yahoo.co.uk (BK) writes:
> Hi
>
> are there any efforts/URLs with regards to integrating/using OpenMCL
> with ProjectBuilder and InterfaceBuilder on OSX?
InterfaceBuilder sounds like a good idea -- integrating with
ProjectBuilder would be a terrible idea. It's meant for static
languages, which Lisp is not.
> all I could find was this screenshot at
> http://lemonodor.com/archives/images/openmcl-ide-rainer.png
>
> but nothing that explained how to set something like this up.
If you have both the binaries and source installed, you can do
(require "COCOA"). It's not ready for serious use, though.
IMO, the first thing to do would be to nicen up the Lisp<->ObjC
bridge. Right now it's functional, but too low-level and grungy to be
convenient. I have some thoughts on this subject, #1 being "fix
OpenMCL's broken implementation of :invert readcase".
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote ...
> InterfaceBuilder sounds like a good idea -- integrating with
> ProjectBuilder would be a terrible idea. It's meant for static
> languages, which Lisp is not.
Well, I use AppleScript Studio which is rather nicely integrated into
ProjectBuilder. AppleScript isn't Lisp, but it is a dynamic language.
Anyway, what I am looking for at this stage is
- getting a listener up inside the ProjectBuilder editor windor; or
- getting a listener up inside Emacs under Aqua; or
- some combination of the two.
any ideas?
> If you have both the binaries and source installed, you can do
> (require "COCOA"). It's not ready for serious use, though.
I'll have a go at that, thanks for the hint.
> IMO, the first thing to do would be to nicen up the Lisp<->ObjC
> bridge. Right now it's functional, but too low-level and grungy to be
> convenient. I have some thoughts on this subject, #1 being "fix
> OpenMCL's broken implementation of :invert readcase".
That's beyond my skillset. I haven't been doing any serious
programming for years, so I am rusty and try to get back into things.
I suppose OpenMCL is good enough for that or is there any other Lisp
that does Cocoa?
thanks again
rgds
bk
·········@yahoo.co.uk (BK) writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote ...
>
> > InterfaceBuilder sounds like a good idea -- integrating with
> > ProjectBuilder would be a terrible idea. It's meant for static
> > languages, which Lisp is not.
>
> Well, I use AppleScript Studio which is rather nicely integrated into
> ProjectBuilder. AppleScript isn't Lisp, but it is a dynamic language.
>
>
> Anyway, what I am looking for at this stage is
>
> - getting a listener up inside the ProjectBuilder editor windor; or
> - getting a listener up inside Emacs under Aqua; or
> - some combination of the two.
>
> any ideas?
Number 2 should be easy. The latest release of Emacs supports Carbon.
Install that and ILISP (an Emacs<->CL package that works pretty well),
plus the HyperSpec, and you'll have a decent environment.
Email me offline if you want, and I can send you a tarball of the
setup I use (modulo Emacs itself).
> I suppose OpenMCL is good enough for that or is there any other Lisp
> that does Cocoa?
I think LispWorks will, but it's in beta testing right now. So, at
the moment, OpenMCL is your best bet.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote ...
> The latest release of Emacs supports Carbon.
> Install that and ILISP
Well, I have to say, whoever wrote the installation section in the
ILISP User Guide (ilisp.pdf) quite obviously expected far too much
prior knowledge about their installation process than they should
have.
What I expect is either a script that automatically does the whole
thing (this is what should be reasonably ecpected in this day and age
- anything else is 1950s and toys for boys who refused to grow up) or
failing that, at the very least I would expect a step by step
installation guide.
For starters, I find it careless to say "put your package wherever you
want it" without making a suggestion where it might sensibly be put. I
don't have any clue where I want ILISP to reside and quite franky I
couldn't care less.
Should I put it in the same folder as Emacs itself? Perhaps, but that
might have certain consequences when I am going to upgrade Emacs, so,
perhaps it should be sitting somewhere else. Should it reside
alongside OpenMCL? What if I want to use it with another Lisp one day,
do I need a separate instance then or not? These and perhaps many
other things should be considered when determining where ILISP should
be installed. Yet, if you don't know anything about it, then you can't
make any informed decision at all. That is very worrisome.
If I am to make a decision, then I want to be put into the position
where I can make an *informed* decision. If I am not, then I want
somebody else who is, to make to make that informed decision for me
(ie an install script).
Next, I have no idea what I should set the EMACS variable to.
Obviously I have /usr/bin/emacs preinstalled on my system, but I don't
want to use that for editing. I want to use the carbonised Emacs which
I have put in /Developer/Applications/Emacs 21.1/
Do I have to set EMACS = /Developer/Applications/Emacs 21.1/Emacs.app
?
perhaps that won't work because *.app is just a folder which OSX
treats as if it was an executable.
So is it EMACS = /Developer/Applications/Emacs
21.1/Emacs.app/Contents/MacOS/Emacs ?
Or can I safely use /usr/bin/emacs to compile ILISP and then use it
with Emacs.app ?
Sure, I could just use trial-and-error, but as I don't know much about
these tools, I cannot safely rule out that I break something and even
if it appears to be working eventually there may be a disaster further
down the road because I compromised the setup with my trial-and-error.
As you can see, although I am not computer illiterate, I am stuck with
this thing at the very first step before it even started. This is
really frustrating.
I would appreciate if somebody who has done this before using OSX to
give me some hints, please.
thanks in advance
rgds
bk
From: Tim Bradshaw
Subject: Re: How to integrate OpenMCL w/ProjectBuilder&InterfaceBuilder on OSX?
Date:
Message-ID: <ey3n0i76oub.fsf@cley.com>
* BK wrote:
> What I expect is either a script that automatically does the whole
> thing (this is what should be reasonably ecpected in this day and age
> - anything else is 1950s and toys for boys who refused to grow up) or
> failing that, at the very least I would expect a step by step
> installation guide.
Maybe what you want is some commercial software where you pay for this
kind of support. Alternatively I'm sure the ILISP maintainers will be
happy to sell you a few hours consultancy.
--tim
Hi Tim Bradshaw,
>> What I expect is either a script that automatically does the whole
>> thing (this is what should be reasonably ecpected in this day and age -
>> anything else is 1950s and toys for boys who refused to grow up) or
>> failing that, at the very least I would expect a step by step
>> installation guide.
>
> Maybe what you want is some commercial software where you pay for this
> kind of support. Alternatively I'm sure the ILISP maintainers will be
> happy to sell you a few hours consultancy.
Also one can use a distribution where the smart people have already
configured the software and the user merely has to apt-get install ilisp.
Debian comes to mind. Available on a Compaq IPAQ through to an IBM S/390.
Also on PowerPC. Just replace or dual boot with OS X:
http://www.debian.org/ports/powerpc/inst/pmac
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> wrote ...
> Also one can use a distribution where the smart people have already
> configured the software and the user merely has to apt-get install ilisp.
> Debian comes to mind. Available on a Compaq IPAQ through to an IBM S/390.
> Also on PowerPC. Just replace or dual boot with OS X:
> http://www.debian.org/ports/powerpc/inst/pmac
Dual boot is not an option because this Mac is also an email and
webserver (running OSX Server) and it wouldn't make sense to maintain
two server configurations just to be able to dual boot.
For the avoidance of doubt, I am not avoiding commercial packages or
paying for software or anything like that. Instead, I spent quite a
bit of money on Digitool's MCL, but then came OSX and I have been
waiting ever since. Whenever I checked with Digitool an OSX version
was "just around the corner". I know there is a friendly user trial
now, but after waiting for almost three years I take the attitude "I
believe it when it is shipping".
I assumed there would be other OSX users who have also been waiting
and use OpenMCL as an interim tool. Consequently, some of them would
probably have found out how to install ILISP.
Anyway, it seems to me that part of the problem is that I don't know
where the proper forum is to ask this kind of question. So, please
allow me to go two steps back and ask this:
Which NG or other forum should I ask about how to install ILISP under
OSX to work with a carbonised Emacs ?
thanks
rgds
bk
From: Edi Weitz
Subject: Re: How to integrate OpenMCL w/ProjectBuilder&InterfaceBuilder on OSX?
Date:
Message-ID: <87issu4ptr.fsf@bird.agharta.de>
·········@yahoo.co.uk (BK) writes:
> I assumed there would be other OSX users who have also been waiting
> and use OpenMCL as an interim tool. Consequently, some of them would
> probably have found out how to install ILISP.
>
> Anyway, it seems to me that part of the problem is that I don't know
> where the proper forum is to ask this kind of question. So, please
> allow me to go two steps back and ask this:
>
> Which NG or other forum should I ask about how to install ILISP
> under OSX to work with a carbonised Emacs ?
You might want to work towards getting OpenMCL and ILISP integrated
into Fink <http://fink.sf.net/>.
Edi.
Edi Weitz <···@agharta.de> wrote ...
> You might want to work towards getting OpenMCL and ILISP integrated
> into Fink <http://fink.sf.net/>.
good idea.
I have submitted a request. let's see what comes of it.
rgds
bk
Hi BK,
> Which NG or other forum should I ask about how to install ILISP under
> OSX to work with a carbonised Emacs ?
Well there are always the ilisp mailing lists:
http://sourceforge.net/mail/?group_id=3957
Did you also see the c.l.l. archives where Michael James Barber solved a
similar problem in February:
http://groups.google.com/groups?selm=b2anre%2417k%40ascc.artsci.wustl.edu
Good luck,
Adam
"Adam Warner" <······@consulting.net.nz> wrote ...
> Did you also see the c.l.l. archives where Michael James Barber solved a
> similar problem in February:
> http://groups.google.com/groups?selm=b2anre%2417k%40ascc.artsci.wustl.edu
thanks, that looks very promising. will report back later
rgds
bk
From: Marco Antoniotti
Subject: Re: How to integrate OpenMCL w/ProjectBuilder&InterfaceBuilder on OSX?
Date:
Message-ID: <tkasa.31$aX1.4137@typhoon.nyu.edu>
BK wrote:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote ...
>
>
> >The latest release of Emacs supports Carbon.
> >Install that and ILISP
>
>
> Well, I have to say, whoever wrote the installation section in the
> ILISP User Guide (ilisp.pdf) quite obviously expected far too much
> prior knowledge about their installation process than they should
> have.
You are most welcome to provide pathces.
> What I expect is either a script that automatically does the whole
> thing (this is what should be reasonably ecpected in this day and age
> - anything else is 1950s and toys for boys who refused to grow up) or
> failing that, at the very least I would expect a step by step
> installation guide.
You are most welcome to provide that as well.
> For starters, I find it careless to say "put your package wherever you
> want it" without making a suggestion where it might sensibly be put. I
> don't have any clue where I want ILISP to reside and quite franky I
> couldn't care less.
I usually have a directory $HOME/lib/elisp/ set up. I usually put the
ilisp subdirectory there.
> Should I put it in the same folder as Emacs itself? Perhaps, but that
> might have certain consequences when I am going to upgrade Emacs, so,
> perhaps it should be sitting somewhere else. Should it reside
> alongside OpenMCL? What if I want to use it with another Lisp one day,
> do I need a separate instance then or not? These and perhaps many
> other things should be considered when determining where ILISP should
> be installed. Yet, if you don't know anything about it, then you can't
> make any informed decision at all. That is very worrisome.
You are asking questions here, aren't you? In the process you learn. :)
>
>
> If I am to make a decision, then I want to be put into the position
> where I can make an *informed* decision. If I am not, then I want
> somebody else who is, to make to make that informed decision for me
> (ie an install script).
... which I suggested you could provide :)
> Next, I have no idea what I should set the EMACS variable to.
>
> Obviously I have /usr/bin/emacs preinstalled on my system, but I don't
> want to use that for editing. I want to use the carbonised Emacs which
> I have put in /Developer/Applications/Emacs 21.1/
>
> Do I have to set EMACS = /Developer/Applications/Emacs 21.1/Emacs.app
> ?
>
> perhaps that won't work because *.app is just a folder which OSX
> treats as if it was an executable.
>
> So is it EMACS = /Developer/Applications/Emacs
> 21.1/Emacs.app/Contents/MacOS/Emacs ?
>
> Or can I safely use /usr/bin/emacs to compile ILISP and then use it
> with Emacs.app ?
>
> Sure, I could just use trial-and-error, but as I don't know much about
> these tools, I cannot safely rule out that I break something and even
> if it appears to be working eventually there may be a disaster further
> down the road because I compromised the setup with my trial-and-error.
>
>
> As you can see, although I am not computer illiterate, I am stuck with
> this thing at the very first step before it even started. This is
> really frustrating.
>
> I would appreciate if somebody who has done this before using OSX to
> give me some hints, please.
I cannot help you too much. I have not installed Emacs in the
/Developer/Applications/... subdirectory. I just have it in /usr/bin.
With that I just have made sure to have /usr/bin in my PATH and then the
ILISP Makefle (once unpacked) works out of the box.
Cheers
--
Marco Antoniotti
Marco Antoniotti <·······@cs.nyu.edu> wrote ...
> > Well, I have to say, whoever wrote the installation section in the
> > ILISP User Guide (ilisp.pdf) quite obviously expected far too much
> > prior knowledge about their installation process than they should
> > have.
>
> You are most welcome to provide pathces.
I will be happy to write up an OSX specific installation subsection
for inclusion into the UG once I have figured out how to get it to
work. Hopefully I'll get there with a little help from others.
> > For starters, I find it careless to say "put your package wherever you
> > want it" without making a suggestion where it might sensibly be put. I
> > don't have any clue where I want ILISP to reside and quite franky I
> > couldn't care less.
>
> I usually have a directory $HOME/lib/elisp/ set up. I usually put the
> ilisp subdirectory there.
thanks. You don't consider ILISP a system wide interface then?
> > Should I put it in the same folder as Emacs itself? Perhaps, but that
> > might have certain consequences when I am going to upgrade Emacs, so,
> > perhaps it should be sitting somewhere else. Should it reside
> > alongside OpenMCL? What if I want to use it with another Lisp one day,
> > do I need a separate instance then or not? These and perhaps many
> > other things should be considered when determining where ILISP should
> > be installed. Yet, if you don't know anything about it, then you can't
> > make any informed decision at all. That is very worrisome.
>
> You are asking questions here, aren't you? In the process you learn. :)
Well, there is nothing wrong with asking and learning. But more
importantly, what I am trying to say is that it might not be such a
good idea to let it entirely open where a software is installed.
Think of it this way: If the author of the software makes a suggestion
where he thinks it is sensible to put it, then many users will just
follow that suggestion, unless they know what they are doing and have
a good reason why they would put it somewhere else. The side-effect
would be that most of the installed base of the software will be at a
"standardised" location, which is beneficial in terms of maintenance
and troubleshooting.
> > Next, I have no idea what I should set the EMACS variable to.
> >
> > Obviously I have /usr/bin/emacs preinstalled on my system, but I don't
> > want to use that for editing. I want to use the carbonised Emacs which
> > I have put in /Developer/Applications/Emacs 21.1/
> > So is it EMACS = /Developer/Applications/Emacs
> > 21.1/Emacs.app/Contents/MacOS/Emacs ?
> I cannot help you too much. I have not installed Emacs in the
> /Developer/Applications/... subdirectory. I just have it in /usr/bin.
That's the terminal based version which comes pre-installed with OSX.
I am talking about the carbonised version, the one that runs in the
Aqua GUI. Aqua apps typically go into /Applications or
/Developer/Applications. If you were to put an Aqua app into /usr/bin,
you wouldn't be apple to double click it anymore because the Aqua GUI
hides that part of the filesystem. You'd have to open the terminal and
launch it from the command line.
Also, what looks like an executable within Aqua is actually a special
directory (*.app) and the actual executable is buried underneath. The
exectuable for the carbonised Emacs is therefore
<Emacs folder>/Emacs.app/Contents/MacOS/Emacs
As the Makefile for ILISP expects emacs' location to be specified,
this raises the question whether the aforementioned path should go in
there.
If that path is used only to compile the sources where Emacs is the
compiler, then it may well be feasible to specify /usr/bin/emacs and
have it compile the sources. Then again, I don't know if the
carbonised Emacs can use files that have been compiled with
/usr/bin/emacs.
If someone could provide some insight on this, that would be helpful,
thanks.
rgds
bk
From: Marco Antoniotti
Subject: Re: How to integrate OpenMCL w/ProjectBuilder&InterfaceBuilder on OSX?
Date:
Message-ID: <S4dsa.34$aX1.4187@typhoon.nyu.edu>
BK wrote:
> Marco Antoniotti wrote ...
>
>
> >>Well, I have to say, whoever wrote the installation section in the
> >>ILISP User Guide (ilisp.pdf) quite obviously expected far too much
> >>prior knowledge about their installation process than they should
> >>have.
> >
> >You are most welcome to provide pathces.
>
>
> I will be happy to write up an OSX specific installation subsection
> for inclusion into the UG once I have figured out how to get it to
> work. Hopefully I'll get there with a little help from others.
That is good. It is probably useful to ask this questions also on the
··········@lists.sf.net mailing list.
>
>
>
> >>For starters, I find it careless to say "put your package wherever you
> >>want it" without making a suggestion where it might sensibly be put. I
> >>don't have any clue where I want ILISP to reside and quite franky I
> >>couldn't care less.
> >
> >I usually have a directory $HOME/lib/elisp/ set up. I usually put the
> >ilisp subdirectory there.
>
>
> thanks. You don't consider ILISP a system wide interface then?
That is just the way I set it up. Another rational place would be in
the Emacs elisp directory for example.
> >>Should I put it in the same folder as Emacs itself? Perhaps, but that
> >>might have certain consequences when I am going to upgrade Emacs, so,
> >>perhaps it should be sitting somewhere else. Should it reside
> >>alongside OpenMCL? What if I want to use it with another Lisp one day,
> >>do I need a separate instance then or not? These and perhaps many
> >>other things should be considered when determining where ILISP should
> >>be installed. Yet, if you don't know anything about it, then you can't
> >>make any informed decision at all. That is very worrisome.
> >
> >You are asking questions here, aren't you? In the process you learn. :)
>
>
> Well, there is nothing wrong with asking and learning. But more
> importantly, what I am trying to say is that it might not be such a
> good idea to let it entirely open where a software is installed.
>
> Think of it this way: If the author of the software makes a suggestion
> where he thinks it is sensible to put it, then many users will just
> follow that suggestion, unless they know what they are doing and have
> a good reason why they would put it somewhere else. The side-effect
> would be that most of the installed base of the software will be at a
> "standardised" location, which is beneficial in terms of maintenance
> and troubleshooting.
Point taken.
>
>
>
>
> >>Next, I have no idea what I should set the EMACS variable to.
> >>
> >>Obviously I have /usr/bin/emacs preinstalled on my system, but I don't
> >>want to use that for editing. I want to use the carbonised Emacs which
> >>I have put in /Developer/Applications/Emacs 21.1/
>
>
> >>So is it EMACS = /Developer/Applications/Emacs
> >>21.1/Emacs.app/Contents/MacOS/Emacs ?
>
>
> >I cannot help you too much. I have not installed Emacs in the
> >/Developer/Applications/... subdirectory. I just have it in /usr/bin.
>
>
> That's the terminal based version which comes pre-installed with OSX.
Yes, but the byte codes are compatible with the Emacs-on-Aqua I am using.
> I am talking about the carbonised version, the one that runs in the
> Aqua GUI. Aqua apps typically go into /Applications or
> /Developer/Applications. If you were to put an Aqua app into /usr/bin,
> you wouldn't be apple to double click it anymore because the Aqua GUI
> hides that part of the filesystem. You'd have to open the terminal and
> launch it from the command line.
>
> Also, what looks like an executable within Aqua is actually a special
> directory (*.app) and the actual executable is buried underneath. The
> exectuable for the carbonised Emacs is therefore
>
> /Emacs.app/Contents/MacOS/Emacs
>
> As the Makefile for ILISP expects emacs' location to be specified,
> this raises the question whether the aforementioned path should go in
> there.
I understand. It looks like "things just worked" for me and I did not
really thought through all the ramifications.
Note that another thing I do is to explicitely modify the Emacs
`load-path' in my .emacs file, to make sure that the `ilisp'
subdirectory is visible.
> If that path is used only to compile the sources where Emacs is the
> compiler, then it may well be feasible to specify /usr/bin/emacs and
> have it compile the sources. Then again, I don't know if the
> carbonised Emacs can use files that have been compiled with
> /usr/bin/emacs.
It looks like you can. However, that is something to keep an eye on.
Cheers
--
Marco Antoniotti
·········@yahoo.co.uk (BK) writes:
> Also, what looks like an executable within Aqua is actually a special
> directory (*.app) and the actual executable is buried underneath. The
> exectuable for the carbonised Emacs is therefore
>
> <Emacs folder>/Emacs.app/Contents/MacOS/Emacs
>
> As the Makefile for ILISP expects emacs' location to be specified,
> this raises the question whether the aforementioned path should go in
> there.
>
> If that path is used only to compile the sources where Emacs is the
> compiler, then it may well be feasible to specify /usr/bin/emacs and
> have it compile the sources. Then again, I don't know if the
> carbonised Emacs can use files that have been compiled with
> /usr/bin/emacs.
I think
EMACS=<Emacs folder>/Emacs.app/Contents/MacOS/Emacs
should work.
/Applications/Emacs.app/Contents/MacOS/Emacs -nw
got me Emacs in a terminal window, anyway, so I preusme other command
line arguments will work as expected.
Cheers,
M.
--
well, take it from an old hand: the only reason it would be easier
to program in C is that you can't easily express complex problems
in C, so you don't. -- Erik Naggum, comp.lang.lisp
·········@yahoo.co.uk (BK) wrote in message news:<····························@posting.google.com>...
> Well, I use AppleScript Studio which is rather nicely integrated into
> ProjectBuilder. AppleScript isn't Lisp, but it is a dynamic language.
AppleScript is object oriented, and very english-like, but it is a
statically compiled language. There is no read-eval-print-loop; you
must halt the app and recompile entirely if you modify classes (i.e.,
no change-class, no update-instance-for-redefined-class, for example),
or indeed any source code at all.
I think you misunderstand what is meant by a "dynamic language." In a
dynamic language you can modify code in a running application/image
*while it is running*. Smalltalk is a dynamic language, as are scheme,
and common lisp. AppleScript is not.
In a statically compiled language, like AppleScript, you must halt the
running application, recompile after making any changes, and restart
the application. This is how ProjectBuilder works. This is how
AppleScript works (whether in ProjectBuilder or Script Editor).
ProjectBuilder is nice for statically compiled languages. It is
designed for the edit-compile-debug cycle crowd (C, C++, Objective-C,
Java, and now, AppleScript), but it is not suitable for a dynamic
language like lisp.
·······@mediaone.net (Raffael Cavallaro) wrote ...
> ·········@yahoo.co.uk (BK) wrote ...
>
> > Well, I use AppleScript Studio which is rather nicely integrated into
> > ProjectBuilder. AppleScript isn't Lisp, but it is a dynamic language.
>
> AppleScript is object oriented, and very english-like, but it is a
> statically compiled language. There is no read-eval-print-loop; you
> must halt the app and recompile entirely if you modify classes (i.e.,
> no change-class, no update-instance-for-redefined-class, for example),
> or indeed any source code at all.
>
> I think you misunderstand what is meant by a "dynamic language."
I don't think so, I just don't have a binary definition for "dynamic
language". I think in fuzzy sets. If you think of a scale where C is
on one end and Lisp is on the other end, then AppleScript is somehwere
in between, but closer to the Lisp end of the scale than its distance
from the C end of the scale.
In particular I was thinking about "dynamically typed" as one
important element within the "is a dynamic language" fuzzy set.
Besides, even by your own definition as presented above, your
conclusion is not entirely correct. You can organise your AppleScript
code around so called script objects and they can be compiled and
stored separately and then used in a fashion that allows you to modify
parts of your code while it is running. This may not be a very
widespread way to use AppleScript but the language certainly allows
you to do that. I use this all the time. It is another important
element within my "is a dynamic language" fuzzy set.
Your definition on what a dynamic language is would seem to be
measured against certain reference languages, such as Lisp for
example. Consequently, everything that doesn't meet the same threshold
as the reference will not qualify.
In principle, there is nothing wrong with that model. It's as good as
anybody else's. However, if you use this model, then you almost
certainly will need a few more categories for the "oddball" stuff that
doesn't seem to fit neither category. If your reference point is
dynamic languages, someone else's may be static languages. That is,
you define a static language as "not a dynamic language when measured
against a reference dynamic language" and someone else will define a
dynamic language against "not a static language when measured against
a reference static language". This is bound to leave many languages
fitting neither category.
In other words, your box model hasn't got enough boxes or it will be
incompatible with other people's box models which often leads to
unnecessary arguments. Of course, you can always define another box,
but the trouble is that there is always some "bastard" item that
doesn't seem to fit into any box no matter how many boxes you have
got.
< Philosophic excursion >
Before Calculus was invented, there was no way to tell the gradient of
a function at a given point. You could only determine an average
between two points. This was good enough for most requirements, but in
Newton's time, problems were tackled for which this level of
granularity wasn't good enough anymore. So, Newton (and also Leibniz)
came up with a brilliant idea. They said, what if I pretend to make
the distance between two points smaller and smaller so that in the end
it is just as if it was infinitely small and there was only one point
to coincide with the one I am really interested in. And once I have
figured out how to do this, I am going to pretend to do the same for
all points at once.
The clarity and beauty of the straightforward thinking process
involved here has never failed to amaze me again and again. Today,
Calculus is an old hat, but we are still using boxes to categorise
just about everything. Even worse, most of the time we don't even
allow for more than two boxes. At the same time, we are trying to
tackle problems, which to solve almost certainly requires a much
better level of granularity.
What has happened to clarity and beauty of straightforward thinking?
Why are we looking at the whole universe with binary glasses on? Is
this what they mean by "the digital age"? Newton and Leibniz have
given us an example we should try to follow. Why don't we do with our
boxes as they did when they invented Calculus? That is to say,
increase the number and shrink the size of our boxes to ultimately
reach the point where we have an infinite number of infinitely small
boxes.
Unlike Newton and Leibniz, we don't even have to face the
extraordinary task to invent the tools for doing so. Somebody's
already done that for us back in the 1960s, we may as well use them.
Fuzzy sets and fuzzy logic shouldn't be an oddball engineering
technique, we should have the philosophy embedded in our daily
thinking by now, at least as a secondary utility to carry out a
reality check of our box model once in a while.
Of all the people in this world, I have confidence that the readers of
this newsgroup will be able to appreciate this philosophy. It is my
philosophy.
< /Philosophic excursion >
> In a dynamic language you can modify code in a running application/image
> *while it is running*.
Absolutely. And you can do it with AppleScript ;-)
> Smalltalk is a dynamic language, as are scheme,
> and common lisp. AppleScript is not.
If so, then not as a result of failing the test you describe.
> In a statically compiled language, like AppleScript, you must halt the
> running application, recompile after making any changes, and restart
> the application.
You don't have to. You can modify, recompile and save script objects,
not unlike Lisp packages and have them replace older versions of those
script objects while your application is executing. Of course, in Lisp
you have a lot more control and flexibility for doing this than you
have in AppleScript, but compared to what you would perhaps call
conventional static languages, AppleScript is a lot more Lispish than
you might realise.
If you take a C or Pascal programmer and explain the concept to them,
they will realise that this is something they cannot do. If you show
them how you can do it in AppleScript and Lisp, they will probably not
fully understand what the limitations are in AppleScript that make
Lisp excel at it, but they will see that both AppleScript and Lisp are
in a different camp than C and Pascal in respect of this concept.
I totally agree with you that the level of flexibility Lisp gives you
is what you will want to have once you started programming in this
way. After all this is one of the reasons why I would like to get back
into Lisp. Each time I use AppleScript it reminds me how much better
and more of the same thing I would get if I bit the bullet and get
back into Lisp.
I am not talking academic here. I have written a client/server
application entirely in AppleScript that uses script objects to do
live patching of the running application.
The main disadvantage AppleScript has in this respect is that you
cannot just start a listener to connect to your application and patch
it with new code as you please like you can do with Lisp. You have to
build the code for replacing script objects inside your running
application yourself and use other means to signal the application
that it should patch itself. Therefore you can patch only code that
you have anticipated beforehand would be a good idea to have patchable
and prepared accordingly. This takes careful planning and you could
always run into a situation you didn't foresee. With Lisp you just
take it for granted that you can patch no matter what even if you
didn't plan for it. Of course that is an incredible benefit.
However, if you use a "purely" static language, you couldn't even
begin to imagine to patch anything. Most people using static languages
can't even fathom the concept. If I try to explain to them what I am
doing, they either think I am telling them a tale or they think
patching as in "hex-editor", which is of course not what I am talking
about :-)
The c/s app I did in AppleScript exchanges messages between different
instances of Excel on different machines so that users can share data
they have in their spreadsheet without having to make it read/only. I
started off with a very simple design with very limited abilities and
used an NFS mounted filesystem to send messages accross. I wanted to
see if the whole thing worked before going fancy and before going into
network sockets etc.
However, I did this for a friend's company as a pet project and I
wanted to be able to give them new code at any time. I tested
everything at my own place and I didn't want to have to wait and then
sit into the night in their office. By using script objects I was able
to insert new features while the application was running and
eventually I replaced the underlying filesystem centric message
passing mechanism with a network protocol also while it was running in
production and under load.
I would place the compiled script objects in the appropriate location
on the NFS shared filesystem for every machine to have access to
them. While the main script was ticking along on all those Macs, I
would send them all a message to load the new code. The next time the
idle handler ran the application would act upon the message, load the
new script objects and learn new tricks. I also implemented a signal
to go back to the previous version. All in AppleScript and all without
stopping or starting anyting.
So, you tell me again AppleScript is not a dynamic language by your
own definition ;-)
Would it have been easier to do with Lisp if my Lisp skills were up to
it? Absolutely yes it would have been easier, more pleasant and far
more elegant. Although it would have been more difficult to interface
with Excel - that is where AppleScript really shines.
> This is how ProjectBuilder works.
[snip]
> ProjectBuilder is nice for statically compiled languages. It is
> designed for the edit-compile-debug cycle crowd (C, C++, Objective-C,
> Java, and now, AppleScript), but it is not suitable for a dynamic
> language like lisp.
I disagree. PB has a plug-in architecture. You may recall that I asked
if anyone knew how to get a listener up and running within PB. As long
as you can get the following:
1) a listener to run inside an editor
2) syntax colouring and paren matching
3) shortcut to online reference and templates
... any IDE is about as suitable for Lisp as any other.
ProjectBuilder does have the hooks to do just that.
It has a plug-in architecture which makes it possible to build an
equivalent to what ILISP is to Emacs. In fact, I found a reference
that suggested somebody has already plugged in Emacs into PB, though I
couldn't find any details. Further, PB already does paren matching and
I have located the property lists where language specifications are
stored, which is what takes care of syntax colouring. I am tempted to
create such a spec for CL, I once did something similar for VAX/LSE
just for fun while learning some VAX-Lisp years ago. The templates
system in PB is customisable via property lists, too and context
sensitive online reference (ie hyperspec) can be achieved using OSX
services.
Somebody has actually done some work like that for Dylan to integrate
with PB and while we agree to disagree on AppleScript, I don't think
you will disagree that Dylan is a dynamic language ;-)
If something like that shows up for CL or if I can figure out how to
do at least some of this DIY, I will be likely using PB over Emacs and
it won't limit the level of interaction with CL a bit.
In case you are curious how I could possibly contemplate using
anything other than Emacs, here is my emacs rant:
< EMACS RANT >
I know most folks do a lot more with their Emacs editors and I don't
doubt for a moment that this is perfect for them but for me the
aforementioned three items are my personal invocation of Gabriel's
metaphor, slightly modified into "'less is better' is better".
What I really want to do is brush up my rusty Lisp skills and have a
bit of fun with it, perhaps suggest it for a project some day some
place. The centre of my attention is therefore Lisp, not Emacs. If I
can make Emacs work without having to fight it all the time, I will
use it, otherwise I won't.
One particular problem I have with Emacs are the myriad of mostly
volatile and awkwardly positioned keyboard shortcuts. It drives me
nuts!
I travel a lot, particularly in Asia. I have to work with a variety of
different keyboard arrangements all the time and I am not always using
the same machine either. Why would I invest all that time into
learning exotic keyboard shortcuts, if they are ***never*** where they
are supposed to be?! And even if they are there, often the most
crucial ones have the most awkward locations on non-English keyboards
and you need a black belt in finger-yoga to invoke them. It's a
nightmare on every system, Windoze, Mac, Unix, VAX, always has been. I
absolutely hate keyboard shortcuts! I use the mouse/trackpad and the
GUI. If I ever settle down in the US one day, I'll reconsider.
I have managed to work the Mac with only knowing eight keyboard
shortcuts and Unix with only knowing six vi shortcuts. I will manage
to work Lisp, even without Emacs if I have to.
To me cut/copy/paste is Cmd-x/c/v and that works just fine. I write a
lot more natural language text than I ever will in Lisp so I don't
want to neither miss nor relearn cut/copy/paste, in particular not if
the shortcuts keep moving and I have to relearn them yet once more
again. Worse, I have to find them by trial and error before I can even
think about whether or not I want to relearn them again. That kind of
nonsense drives me crazy and it would totally annihilate any
productivity gain Lisp might give me if I had to make a living from
doing any work with Lisp (although I would then probably have a
dedicated workstation some place and not travel as much).
< /EMACS RANT >
anyway, thanks for your comments
rgds
bk
·········@yahoo.co.uk (BK) writes:
> ·······@mediaone.net (Raffael Cavallaro) wrote ...
>
> > I think you misunderstand what is meant by a "dynamic language."
>
> I don't think so
Well, I do. Think "context". If I was posting on comp.lang.misc, I'd
have been more careful in my wording. Given that this is a Lisp
group, the phrase "dynamic language", *especially* when talking about
an IDE, implies a toplevel-type situation, as opposed to an
edit-compile-debug routine.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote ...
> ·········@yahoo.co.uk (BK) writes:
>
> > ·······@mediaone.net (Raffael Cavallaro) wrote ...
> >
> > > I think you misunderstand what is meant by a "dynamic language."
> >
> > I don't think so
>
> Well, I do. Think "context".
Let's have a look at what the context was, shall we? I had asked:
"... how to run a listener from within ProjectBuilder."
which clearly means interaction with CL and therefore the
edit-compile-link-run nature that PB exhibits when used in a different
context does not apply in the context I had asked the question in.
In other words, the idea is that PB adapts to the language you are
using it with and not the other way round.
rgds
bk
·········@yahoo.co.uk (BK) wrote in message news:<····························@posting.google.com>...
> In other words, the idea is that PB adapts to the language you are
> using it with and not the other way round.
But you miss the essential point that ProjectBuilder is incapable of
"adapting" to a certain class of language - those that are dynamic,
those where programmers can change code in a running application.
Project builder only works for statically compiled languages.
Please accept the fact that that lispers recognize one of the
principal advantages of lisp to be the fact that one can modify a live
application/image, while it is running. It greatly facilitates
exploratory development, and it is a programming style that is simply
unavailable in a statically compiled language that uses the
edit-compile-debug development cycle.
Your original question is rather like asking "how to integrate emacs
with an underwood manual typewriter," since emacs is a dynamic editor,
and a manual typewriter can only create static pages, that must be
completely retyped in order to change them.
·······@mediaone.net (Raffael Cavallaro) wrote ...
> But you miss the essential point that ProjectBuilder is incapable of
> "adapting" to a certain class of language - those that are dynamic,
> those where programmers can change code in a running application.
Apparently, PB is not incapable of that. Apparently, you can hook in
your own code and replace the built-in editors and insert your own
listeners. As soon as you get a listener, you have your interaction
with Lisp. Apparently, someone has done just that with PB for Dylan
already.
You will have to concede that if this has been done for Dylan, then
there is a possibility someone has done it for Lisp or someone is
working on doing so, and thus it is perfectly permissible to ask the
question with the aim to find out more about this, such as description
of what actually has been done, what are the plans, limitations, how
to do it etc etc.
It is thus not very helpful to insist that it cannot be done in a
manner which provides a level of interaction that is comparable to an
Emacs environment. Emacs does not have a monopoly on interaction with
an external Lisp engine.
> Project builder only works for statically compiled languages.
Ha, what about the Dylan integration then? Have you seen it? Can you
definitely say that it is so severely limited by PB contraints that it
has to be considered a failed attempt? If so, I would be interested in
details, seriously.
Then, even if the current level of integration for Dylan falls short
of the average wishlist (I wouldn't know), then can you definitely say
that there is no chance for this to evolve? I have to say, it would
seem rather insulting to the people who put their effort into this.
Are you saying they are wasting their time because they have missed
the point? Again, if you have any details, I would be honestly
interested to hear about them.
And even if the Dylan/PB integration is only very rudimentary, absence
of evidence is not evidence of absence. Do you know the Cocoa
framework so well that you can say it is so seriously flawed that it
cannot be used to enhance editor classes with listeners similar in
effect to ILISP enhancing Emacs? I think if you were to make such a
statement you'd find thousands of Cocoa developers who would disagree
and show you stuff that proofs you wrong.
> Your original question is rather like asking "how to integrate emacs
> with an underwood manual typewriter," since emacs is a dynamic editor,
> and a manual typewriter can only create static pages, that must be
> completely retyped in order to change them.
You seem to be rather obsessed with the idea that Emacs is not only
the last word in extensible editors but that it is also the only
editor that can have a listener hooked in. Either idea would be
proposterous.
There is absolutely no reason to believe that PB would impose an
edit-compile-link-run workflow on a newly integrated environment. It
is entirely up to the implementor/integrator to make that decision.
Just because the defaults that ship with ProjectBuilder use that
workflow doesn't mean that this is the only workflow that can be
integrated with PB.
A long time ago, I learned VAX-Lisp at University and the resident
Lisp hacker had built himself a plug-in for VAX-LSE (Language
Sensitive Editor, which was part of a DEC's CASE tool called VAXset).
Like ProjectBuilder this was mostly used for static languages and in
its stock status it, too, assumed an edit-compile-link-build-run
workflow. Nevertheless, the plug-in made the VAX-Lisp listener show up
within LSE and thereby introducing an interactive Lisp workflow. Yet,
much of the added value of the LSE/VAXset environment was preserved
and so there was significant synergy.
Let me give you a rough and very high level idea how a ProjectBuilder
Lisp integration could look like ...
(Please do me a favour and take this in its entire context)
=============================================================================
HOW AN INTERACTIVE LISP ENVIRONMENT INTEGRATED INTO PROJECT BUILDER
MIGHT LOOK LIKE
1) Starting a new "project"
you'd launch PB and select "new project"
In addition to what you see when you do this on a stock PB, you will
have additional entries for Lisp, for example
Under "Application"
- Lisp Cocoa Application
- Lisp Droplet Application
- Lisp Server Application (headless)
Under a new section "Core Lisp"
- Lisp Listener only (no Cocoa)
- External Emacs session
from which you'd choose and get a framework accordingly - let's assume
we wanted to work on a new Cocoa Application ...
We'd choose "Lisp Cocoa Application" give it a name (ie "MyApp") and
get something like
MyApp
MyApp.lisp
MyApp.listener
Resources
MyApp.icns
MainMenu.nib
InfoPlist.strings
AppleScriptKit.asdictionary (optional)
Packages
ObjC-Lisp.lisp
Cocoa.lisp
Products
MyApp.app
License.rtf
which would appear in the "Groups & Files" coloumn.
The file "MyApp.lisp" is for our source code, obviously. Depending on
the template which is user definable, it would already contain various
skeletal items, in particular for using the Cocoa framework, for
example:
----------------------------------------------
;;;-*-Mode: LISP; Package: CCL -*-
;;;
;;; Copyright (C) ...
;;;
;;; Author ...
(in-package "CCL")
(eval-when (:compile-toplevel :execute)
(use-interface-dir :cocoa))
(require "Cocoa")
(defclass cocoa-application ...)
(save-application ...)
----------------------------------------------
We could add more source files either by adding them to the template
or using PB's "Project -> Add Files ..." menu. This could also be
integrated with the interactive use of files within the Lisp listener
(ie creating/loading a file in the listener could add that file into
the project tree).
The file "MyApp.listener" would determine which Common Lisp we are
going to connect to and this would be user defined (again by editing
the templates). In other words, this would do what (autoload ...) in
your .ilisp file does. There could be multiple *.listener files to
connect to different Common Lisp environments (ie.
"MyApp.OpenMCL.listener" for OpenMCL, "MyApp.Allegro.listener" for ACL
etc etc).
The Resource folder contains the application's icon, the user
interface definitions (.nib) made with InterfaceBuilder, info strings
that conform with Apple's application bundle system, and an *optional*
AppleScript dictionary if we wanted our application to be AppleScript
scriptable.
The Packages folder contains the lisp code needed to interface with
the Cocoa application framework. This could be further divided into
global packages that came with our Common Lisp (probably low level)
and user packages that we wrote/customised (probably on top of the low
level ones). Note that this is not here for linking as the
corresponding "Frameworks" tree in an Objective-C project would be,
but for easy access and version management.
Finally, the Products folder would contain the target application
conforming to Apple's application bundle system which would be
automatically created when we use (save-application ...) within the
interactive Lisp environment. This is one of the areas where
integration with PB would shine, because in a core-only Lisp
environment we will have to assemble our Aqua application piecemeal.
Through integration with PB, we could automate this. The Lisp image
that contains our application would automatically be saved into the
Application Bundle along with all the resources such as NIBs, icons,
localisable strings etc. Further, whenever we open the project in a
later session, we will always be working in the proper image, thus the
added value of PB to keep various simultaneous projects apart would be
preserved.
Please note that had we chosen another project type, ie Droplet or
headless Server Application, the target in the Products folder would
turn out accordingly. Again, this is where the PB environment brings
significant benefits.
Another benefit would be that PB would make it easier to mix Lisp with
code from other languages already integrated with PB and do so in a
clean and consistent manner with proper version management and
automatic "assembly" of the resulting target application. If you want
to do this now, you have to leave your Lisp environment aside and work
on C/C++, Objective-C, Java, AppleScript within another environment
and then manually put all the pieces together, without any version
management which makes maintenance more elaborate and assembly prone
to errors. Integration into one environment would not only help
Lispers to hook into foreign code, but it would also make it easier
for developers using other languages to integrate Lisp code and
thereby lower the hurdle to explore Lisp.
2) Interacting with Common Lisp
Once we have created our project, we could click on "MyApp.listener"
and PB would open a Lisp listener in the right hand side of the
project window. Within this listener window we'd be able to interact
with our Common Lisp (depending on what engine we have defined in
MyApp.listener) and it would not be much different from Emacs. The
NSTextView class in the Cocoa framework supports Emacs keybindings
already, so if this was used to implement our listener-editor, Emacs
keybindings would come almost free. Then again, the listener-editor
could as well be implemented in Lisp using callback functions for PB
to hook in.
Lisp awareness for paren matching, syntax colouring and indenting
could be achieved either by implementing the listener-editor in Lisp
itself or by extending the Text Application framework within Cocoa
with Lisp specific subclasses and methods. I don't have the skills to
accomplish either, but I can read the documentation and see that it
can be done.
The benefit of writing the listener-editor plug-in in Lisp is of
course that it can then be easily enhanced by Lispers, which is one of
the attractions for Lispers to use Emacs today.
3) Misc
Of course the Build and Debug menus of PB the way they are within a
static language project don't make sense while we'd be in a Lisp
project, but they could be replaced so that they show different
options while in a Lisp project. The Build menu could be replaced with
"Save Application" (corresponding to (svae-application ...) and the
Debug menu could provide access to the Lisp internal debugger.
PB's integrated CVS support could be used for Lisp projects and PB's
Help menu would have a few additional options to bring up the
HyperSpec, CLtL2, the Lisp Cookbook ect etc.
4) Conclusions
- there is no reason why ProjectBuilder would in any way present an
impediment to live interaction with a Lisp environment
- a Lisp listener-editor plug-in for ProjectBuilder could be
implemented in Objective-C/Cocoa or in Common Lisp providing callbacks
to ProjectBuilder
- a Lisp implemented listener-editor plug-in would benefit many
Lispers' wish to customise their environment directly in Lisp
- the main attraction of integrating Lisp into ProjectBuilder is the
added value of a seamless Cocoa development environment
- for anyone who is not interested in using the Cocoa framework and
create Cocoa applications using Lisp, integration into ProjectBuilder
is less interesting
=============================================================================
This is meant to show how ProjectBuilder could be used *without*
imposing a edit-compile-link-build-run workflow on Lisp while at the
same time leveraging added value provided by PB. If someone whould sit
down and give this more thought, I am sure there would be more ideas
how to create synergy.
rgds
bk
·········@yahoo.co.uk (BK) wrote in message news:<····························@posting.google.com>...
> Apparently, PB is not incapable of that. Apparently, you can hook in
> your own code and replace the built-in editors and insert your own
> listeners. As soon as you get a listener, you have your interaction
> with Lisp. Apparently, someone has done just that with PB for Dylan
> already.
>
> You will have to concede that if this has been done for Dylan, then
> there is a possibility someone has done it for Lisp
No, this hasn't been done for Dylan. I've actually used Gwydion Dylan
on Mac OS X. The PB support consists of syntax highlighting, and
telling PB to use d2c (a static compiler), not a top level listener.
Dylan is still a statically compiled language on Mac OS X, using PB.
> You seem to be rather obsessed with the idea that Emacs is not only
> the last word in extensible editors but that it is also the only
> editor that can have a listener hooked in. Either idea would be
> proposterous.
I don't even use Emacs. It was simply an example since many people are
familiar with it. I use BBEdit for text editing, and MCL for a lisp
IDE.
[much mercifully snipped]
> Of course the Build and Debug menus of PB the way they are within a
> static language project don't make sense while we'd be in a Lisp
> project,
Which should be hint as to why we've been telling you that PB and lisp
are not a good fit.
> but they could be replaced so that they show different
> options while in a Lisp project. The Build menu could be replaced with
> "Save Application" (corresponding to (svae-application ...) and the
> Debug menu could provide access to the Lisp internal debugger.
Any part of any applicationcan be replaced with an entire lisp IDE, if
you rewrite that application. The simple fact is, you can't add a
listener to PB without rewriting Project Builder. So your claim
reduces to "If we rewrite PB to have a top level listener, then it
will be a lisp IDE."
I think I've seen this claim before, but it's usually phrased "if my
aunt had wheels, she'd be a tea cart." (That's the polite version.
Often it involves one's aunt being one's uncle, and a certain part of
the male anatomy).
Raf
·······@mediaone.net (Raffael Cavallaro) wrote ...
> > You will have to concede that if this has been done for Dylan, then
> > there is a possibility someone has done it for Lisp
>
> No, this hasn't been done for Dylan. I've actually used Gwydion Dylan
> on Mac OS X. The PB support consists of syntax highlighting, and
> telling PB to use d2c (a static compiler), not a top level listener.
> Dylan is still a statically compiled language on Mac OS X, using PB.
Thank you. Do you realise that this is the first time you are actually
coming up with some useful information in respect of the topic of this
thread? ;-)
Do you have a link for this? Or an email address for the developers?
It would be interesting to learn what their plans are. If they intend
to write a listener plug-in for PB, perhaps this could be used or
modified for Lisp.
> I don't even use Emacs. It was simply an example since many people are
> familiar with it. I use BBEdit for text editing, and MCL for a lisp
> IDE.
BBEdit is a great editor. It's a good example, too, because it, too,
has a plug-in architecture. There is no reason why one couldn't write
a listener plug-in for BBEdit so one would have a live listener inside
BBEdit, Lisp indentation and syntax colouring and other goodies.
> > Of course the Build and Debug menus of PB the way they are within a
> > static language project don't make sense while we'd be in a Lisp
> > project,
>
> Which should be hint as to why we've been telling you that PB and lisp
> are not a good fit.
Should it? Not a good fit because of two menus you don't need? Are you
being serious? If you really mean this, then you will also have to
declare Emacs to be not a good fit for Lisp. Emacs has a bunch of
games menus and a virtual psychiatrist menu built-in. Totally
unsuitable for Lisp development, ergo Emacs is no good for Lisp -
following your reasoning.
> > but they could be replaced so that they show different
> > options while in a Lisp project. The Build menu could be replaced with
> > "Save Application" (corresponding to (svae-application ...) and the
> > Debug menu could provide access to the Lisp internal debugger.
>
>
> Any part of any applicationcan be replaced with an entire lisp IDE, if
> you rewrite that application. The simple fact is, you can't add a
> listener to PB without rewriting Project Builder.
Yes you can. You can plug-in other editors and you can add and
overload methods in the Cocoa framework in which PB is written. You
won't have to rewrite PB. Cocoa is a framework, not a toolkit, it's
been designed for this kind of thing.
I can change or replace menus in PB within a few minutes. I don't need
the source code for that and it is not like poking around in the
binaries. Just fire up InterfaceBuilder and modify the NIBs.
Apart from that, Apple/NeXT *intended* ProjectBuilder to be flexible
and extensible without rewriting. It has been designed that way. And
Apple has said on various developer events that they are still making
it even more flexible.
I have read of some folks who have plugged in other editors into PB.
> So your claim reduces to "If we rewrite PB to have a top level listener,
> then it will be a lisp IDE."
Not what I said. Not even close.
And the hacker I told you about who wrote that VAX-Lisp listener
plug-in for LSE, certainly didn't rewrite VAXset nor LSE. It would
have been rather difficult to get the source code from DEC.
Proposterous idea :-) :-) :-)
rgds
bk
In article <····························@posting.google.com>,
·········@yahoo.co.uk (BK) wrote:
> Apart from that, Apple/NeXT *intended* ProjectBuilder to be flexible
> and extensible without rewriting. It has been designed that way. And
> Apple has said on various developer events that they are still making
> it even more flexible.
"Flexible" by statically compiled language standards, meaning late
binding, and a good deal more introspection than c, but nevertheless,
still statically compiled.
Support for real dynamism has to come at the runtime level, and the
Cocoa runtime is not sufficiently dynamic to support the dynamism of
common lisp. Specifically, update-instance-for-redefined-class, &
friends. I believe I've mentioned this before, say, two weeks ago, when
I first posted to this thread, and practically every post since...
Please try to see the big picture here. All of Apple's technologies
assume that developers will be using a statically compiled language. The
whole OS was compiled using gcc, which compiles many languages, all of
them statically. To add real support for lisp to PB would mean:
1. writing a lisp aware editor, with...
2. hooks into the running lisp runtime image, and lisp compiler, and...
3. packaging 1 and 2 above as extensions to PB.
But after writing 1 and 2, we already have a full fledged common lisp
IDE, so, at this point, what do we need PB for again?
Raf
Hi BK,
> To me cut/copy/paste is Cmd-x/c/v and that works just fine. I write a
> lot more natural language text than I ever will in Lisp so I don't want
> to neither miss nor relearn cut/copy/paste
http://www.cua.dk/cua.html
This is the CUA-mode package which provides a complete emulation of the
standard CUA key bindings (Motif/Windows/Mac GUI) for selecting and
manipulating the region where S-<movement> is used to highlight &
extend the region.
...
Only when the region is currently active (and highlighted since
transient-mark-mode is used), the C-x and C-c keys will work as CUA
keys, i.e. cut and copy, but when the region is not active, C-x and C-c
works as ordinary emacs prefix keys!
This probably sounds strange and difficult to get used to - but based
on my own experience and the feedback from many users of CUA-mode, it
actually works very well and users adapt to it instantly - or at least
very quickly. So give it a try!
"Adam Warner" <······@consulting.net.nz> wrote ...
> http://www.cua.dk/cua.html
>
> This is the CUA-mode package which provides a complete emulation of the
> standard CUA key bindings (Motif/Windows/Mac GUI) for selecting and
> manipulating the region where S-<movement> is used to highlight &
> extend the region.
thank you Adam, that looks helpful. I'll check it out.
rgds
bk
·········@yahoo.co.uk (BK) wrote in message news:<····························@posting.google.com>...
[lengthy post snipped]
The term "dynamic language" has been used for some time, and with a
consensus as to its meaning in the Common Lisp community. In
particular, lispers consider lisp dynamic because the programmer can
change code in a running appliction/image.
This cannot be done in AppleScript. Therefore, by Common Lisp
standards, AppleScript is not a dynamic language. It is a statically
compiled language.
When posting to a particular forum, one should expect to be corrected
if one uses accepted terms in a manner inconsistent with existing
standard usage for that forum.
To lispers and smalltalkers, a language is only dynamic if you can
change code in a running application/image.
·······@mediaone.net (Raffael Cavallaro) wrote ...
> The term "dynamic language" has been used for some time, and with a
> consensus as to its meaning in the Common Lisp community. In
> particular, lispers consider lisp dynamic because the programmer can
> change code in a running appliction/image.
>
> This cannot be done in AppleScript.
And stones do not fall from the sky either, I know.
> Therefore, by Common Lisp standards, AppleScript is not a dynamic language.
> It is a statically compiled language.
What you really mean to say here is that your definition of a dynamic
language is more like "It is dynamic if we say so" or "It is dynamic
if you can change code in the *Lisp* image". In other words it has got
to be Lisp by definition while you make a few exceptions for whatever
in your view is similar enough to Lisp. As Henry Ford used to say "You
can have your T-model in any colour you like, provided it is black".
> When posting to a particular forum, one should expect to be corrected
> if one uses accepted terms in a manner inconsistent with existing
> standard usage for that forum.
And one should also expect an objecting party to concede they were
wrong when one supplies an example that precisely matches -not one's
one definition- but the definition provided by the objecting party.
> To lispers and smalltalkers, a language is only dynamic if you can
> change code in a running application/image.
So it is to AppleScripters.
You are confusing availability with flexibility. Just because an
available feature isn't as flexible as you would like it to be doesn't
mean it's not available.
rgds
bk
From: Espen Vestre
Subject: Re: How to integrate OpenMCL w/ProjectBuilder&InterfaceBuilder on OSX?
Date:
Message-ID: <kwu1c7rs4a.fsf@merced.netfonds.no>
·········@yahoo.co.uk (BK) writes:
> if you can change code in the *Lisp* image". In other words it has got
> to be Lisp by definition while you make a few exceptions for whatever
> in your view is similar enough to Lisp.
Smalltalk and Prolog are both vastly different from Lisp...
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote ...
> Smalltalk and Prolog are both vastly different from Lisp...
Yep, that's why I said "exceptions for whatever *in your view* is
similar enough". [emphasis added]
rgds
bk
From: Daniel Barlow
Subject: Re: How to integrate OpenMCL w/ProjectBuilder&InterfaceBuilder on OSX?
Date:
Message-ID: <877k91bqn2.fsf@noetbook.telent.net>
·········@yahoo.co.uk (BK) writes:
>> To lispers and smalltalkers, a language is only dynamic if you can
>> change code in a running application/image.
>
> So it is to AppleScripters.
>
> You are confusing availability with flexibility. Just because an
> available feature isn't as flexible as you would like it to be doesn't
> mean it's not available.
C is a dynamic language, because you can use dlopen() and dlsym() to
change code in a running application. Or, for that matter, mmap an
area of virtual memory with the PROT_EXEC flag, poke bytes into it,
then jump to it.
(OK, that example is only applicable to Unix systems. I'm sure many
other operating systems have similar facilities, though)
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> wrote ...
> C is a dynamic language, because you can use dlopen() and dlsym() to
> change code in a running application. Or, for that matter, mmap an
> area of virtual memory with the PROT_EXEC flag, poke bytes into it,
> then jump to it.
:-)
Using my fuzzy set based model, your point is certainly valid, but it
would only yield a very low score. Certainly below 0.5. By contrast,
AppleScript would certainly be above 0.5 (more about that further
below) and Lisp would yield a score above AppleScript.
However, someone using a black-and-white based model, would probably
smile and say "Nice try!". They'd object on the grounds that you are
basically "poking" foreign and unknown code into your app, that by
doing so, your app doesn't really become any "smarter". And they'd
have a strong point with such objection.
I guess the key question is this ...
Can you write some arbitrary C code and then send that code to any
given application written in C while that application is running and
tell it to incorporate and execute the C code you have just sent it?
The answer is you can't (unless there is something I misunderstood
about C, but I'm always happy to enjoy a surprise)
Now let's ask the same question for AppleScript ...
Can you write some arbitrary AppleScript code and then send that code
to any given application written in AppleScript while that application
is running and tell it to incorporate and execute the AppleScript code
you have just sent it?
The answer is yes you can.
Of course the test would be positive for Lisp, too.
It seems to me that the reason why some folks here feel uncomfortable
about thinking of AppleScript as a dynamic language is because they
don't know it well enough to see why it should qualify. Fair enough.
So let's take a closer look ...
What I said in an earlier post that you don't have the equivalent of a
listener in AppleScript isn't exactly true, because the AppleScript
ScriptEditor can be used as a universal listener. It enables us to
talk to any AppleScript application while that application is running
and tell it to receive code, incorporate and execute it.
We can write a naked application that contains nothing but an empty
main loop and launch it with the intention that we teach it more
tricks on the fly. Let's call it "NakedBob". Now we can write some
AppleScript that we want to eventually become part of NakedBob, let's
call it "PutOnYourTrousers".
While NakedBob is running, we can just start ScriptEditor (our
listener equivalent) and type ...
tell application NakedBob
load script file "PutOnYourTrousers"
tell PutOnYourTrousers
wear(jeans)
end tell
end tell
What this does is sending a message to the running application to load
arbitrary AppleScript code and execute within that application. The
code will remain part of the application.
From now on our application NakedBob contains not only the empty main
loop but also all the objects and methods in PutOnYourTrousers. Note,
we did this while NakedBob was running and NakedBob didn't have to
know anything beforehand about us coming along to insert new code,
such as PutOnYourTrousers.
We can now write some more AppleScript to become part of NakedBob, say
"PutOnYourShirt". Again, we use ScriptEditor to talk to the running
NakedBob.
First let's find out what trousers Bob is wearing ...
tell application NakedBob
tell PutOnYourTrousers
whatTrousers()
end tell
end tell
Result: jeans
OK, so we'll tell Bob to wear a t-shirt to go along with that ...
tell application NakedBob
load script file "PutOnYourShirt"
tell PutOnYourShirt
wear(t-shirt)
end tell
end tell
Later we might want to replace PutOnYourShirt with a new version that
has a method to pick a shirt that matches the trousers. We can do that
too. All the objects and methods in PutOnYourTrousers are
automatically accessible by name from PutOnYourShirt. All we have to
do is write a new PutOnYourShirt that checks with PutOnYourTrousers
and tell NakedBob to load it in the place of the previous version.
Again, we use ScriptEditor to talk to NakedBob ...
tell application NakedBob
set PutOnYourShirt to load script file "PutOnYourShirt"
tell PutOnYourShirt
wearMatchingShirt()
end tell
end tell
Alternatively, we could have just added a new method to the existing
PutOnYourShirt, again this can be done while NakedBob is running.
Persistence is no problem either with AppleScript, so we don't have to
lose state when the program is shut down and restarted. We can save
our running application using "store script".
This is all not too far behind what you get with Lisp.
And of course this bears some dangers, too ...
tell application "Finder" of machine "eppc://127.0.0.1"
run script "some arbitrary script code"
end tell
... or less obviously ...
tell application "Finder" of machine "eppc://127.0.0.1"
script trojanHorse
-- some arbitrary script code
end script
store script trojanHorse in file ".housekeeping"
end tell
... then come back later to "tell" trojanHorse on the remote host to
spy or do nasty stuff or learn new tricks.
If you are using a Mac and this stuff scares you, don't worry, remote
AppleScript is by default disabled and it's not open doors, you need
credentials, but if you leave the doors open, then someone could come
along and insert arbitrary code into AppleScript applications running
on your system just like someone could insert Lisp code into your
running Lisp applications.
rgds
bk
·········@yahoo.co.uk (BK) writes:
> I guess the key question is this ...
>
> Can you write some arbitrary C code and then send that code to any
> given application written in C while that application is running and
> tell it to incorporate and execute the C code you have just sent it?
Sure. The persistent application has a signal handler that looks in
some directory for object files and keeps track of their dates. When
it observes a newer version than it last loaded, it uses dlopen to
reload that file, and dlsym to get the address of its startup
function, and calls it.
When you have written your arbitrary C code, you copy the output file
into said directory, then signal the persistent application. This is
really not so distant from what you were doing in Applescript, it's
just that we had to write the handler itself instead of having it
happen behind the scenes. Still only rates a 0.3 on the 0-1
dynamicity scale.
When people around here say "Applescript is not a dynamic language",
that's mostly just a shorthand for "applescript is sufficiently less
dynamic than Lisp that it does not meet my requirement for a dynamic
language". Because this is comp.lang.lisp and that's the context we
operate in. If in comp.lang.lisp I said "Java is a statically typed
language" I would not expect to be called on it because it does
runtime dispatch on the first argument of method calls (the argument
before the ., I mean). We know it does that, we know that is a trait
of dynamic typing, but we're all agreed that by the standards of the
local context, it's not _sufficent_ to claim that Java is dynamically
typed. In comp.lang.c , things would be different.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> wrote ...
> When people around here say "Applescript is not a dynamic language",
> that's mostly just a shorthand for "applescript is sufficiently less
> dynamic than Lisp that it does not meet my requirement for a dynamic
> language".
Precisely my point :-)
You'll find just that in my earlier posts. I also said, that I don't
have a problem with a definition based on a reference model where
anything that fails to meet the reference model doesn't qualify. I
didn't say such a model is wrong. I said that the drawback of this
model is that it makes comparative discussion difficult and that a
fuzzy based model has its advantages.
From a fuzzy model point of view one cannot even say, that the feature
we discussed here is the only allowable criterium for "being dynamic".
If you say "I can do this and that in C or Java or whatever, therefore
I consider them to be dynamic, static or whatever else", hey, I don't
have a problem with that. As long as you make sense, tell me what
rules you apply and I can use that to build a scale in my mind, I am
fine.
The only reason why the focus turned on the ability to patch running
applications was because Rafael insisted on that being the only
acceptable criterium. I suspected, he threw that in because he felt
AppleScript couldn't meet the test. So, I used his definition, word by
word, and I tested AppleScript against it. But it didn't fail his
test. Ooooops :-) I take that as an indication that this definition
wasn't the definition after all. I take it as an indication that
instead, the definition is based on Lisp as a reference model and
everything that doesn't closely match Lisp doesn't fit the definition.
Fair enough. As I said, I don't have a problem with such a model, I'm
cool.
Now you have come to the same conclusion, which is further indication
that I wasn't all that far off ;-)
However, Rafael doesn't seem to be happy with that, he seems to want
to have it both ways. He would like Lisp (and a few exceptions he is
willing to make) to be the only ones who can meet the test, but
doesn't want to have a test that explicitly says so, probably because
such a definition would be rather subjective.
There is the dilemma. He must find a test that is objective but keeps
everything out that he would like to keep out ;-)
I don't doubt that he will eventually succeed to come up with such a
test, but I suspect the definition will be rather bloated and have
many buts, ifs and but-only-ifs in it ;-)
In fact if you look at his response to your post, you will find he's
already started to narrow down his definition, throwing in those buts,
ifs and but-only-ifs ;-)
> > Can you write some arbitrary C code and then send that code to any
> > given application written in C while that application is running and
> > tell it to incorporate and execute the C code you have just sent it?
>
> Sure. The persistent application has a signal handler that looks in
> some directory for object files and keeps track of their dates. When
> it observes a newer version than it last loaded, it uses dlopen to
> reload that file, and dlsym to get the address of its startup
> function, and calls it.
That's interesting. I wasn't aware of that.
Does any C application have this ability or do you have to write it in
a particular way and/or link it against specific libaries to be able
to do this?
From your description it would seem that the objects have to be known
to the application in advance and they must be precompiled in order to
be loaded.
In AppleScript you can send source code to an AppleScript app and have
it incorporate that and execute it, for example ...
set sayHi to "say \"Hi there\""
run script sayHi
will coerces the text into a script object, which is then compiled at
run time and executed. You could read the text from user input if you
wanted.
Wrap this into a basic telnet server and drop it into the idle handler
of the application and you've got a listener that's pretty much like a
Lisp listener, albeit with far less vocabulary.
> When you have written your arbitrary C code, you copy the output file
> into said directory, then signal the persistent application. This is
> really not so distant from what you were doing in Applescript,
Well, that's how I *chose* to do it because I had many instances of
the same app running on various Macs who would all see the same NFS
filesystem. When I wanted to insert new code into all of them at once,
it was convenient to put a script object into a file in a
predetermined folder and have all the apps load it automatically and
upgrade themselves instead of targeting every application one by one
and do the "tell application "xyz" on machine ..." bit to achieve the
same effect. However, you can talk to any application written in
AppleScript and insert new code on the fly while it is running even if
it has *not* been prepared to be updated. This is so by design.
Whatever you do to allow live patching of C applications is certainly
not by design and it would seem the application has to be prepared
beforehand or you can't do it at all. Therefore, I'd give C a low
score on the scale.
> it's just that we had to write the handler itself instead of having
> it happen behind the scenes.
But that may be a significant factor. It indicates that C wasn't
intended to be used in this way. It has to be bolted on. It may well
be that the way in which it has been bolted on isn't necessarily a
good way because of constraints imposed by the original design of the
language.
> Still only rates a 0.3 on the 0-1 dynamicity scale.
That much? :-)
> Because this is comp.lang.lisp and that's the context we
> operate in. If in comp.lang.lisp I said "Java is a statically typed
> language" I would not expect to be called on it because it does
> runtime dispatch on the first argument of method calls (the argument
> before the ., I mean). We know it does that, we know that is a trait
> of dynamic typing, but we're all agreed that by the standards of the
> local context, it's not _sufficent_ to claim that Java is dynamically
> typed. In comp.lang.c , things would be different.
In other words the definition is always relative to a reference model
and there are different reference models, which means the superset of
all definitions is a fuzzy set after all ;-)
rgds
bk
In article <····························@posting.google.com>,
·········@yahoo.co.uk (BK) wrote:
> What this does is sending a message to the running application to load
> arbitrary AppleScript code and execute within that application. The
> code will remain part of the application.
And what happens when I create objects based on the original definition
of a class, and then redefine that class? What becomes of these
previously created objects based on the original defintion? Oops, you're
screwed.
You've desribed a well known hackish workaround for statically compiled
languages, and I've just shown why it's a badly broken solution.
You won't be able to redefine exiting objects without tearing them down
manually and rebuilding them based on the new class definition. At this
point, you would do just as well to quit the application, recompile, and
relaunch.
You haven't shown that AppleScript applications can be *changed* while
they are running. You can just send them messages, and add funtionality
by doing inter-process communication. This is a very limited form of
imitation dynamism, which is fundamentally broken for complex systems,
with lots of live objects.
Moreover, none of this is being done from the application itself. You
have to use a separate application, ScriptEditor, to compile the script
first, then tell your application stub to execute this separate compiled
script.
With Common Lisp, you get the abilty to redefine existing objects when
you change their class defintitions, as well as a built in top level
listener that lets you change your application from within that
application itself.
You don't get either with AppleScript, which is why Common Lisp is a
dynamic language, and AppleScript is not.
Raffael Cavallaro <················@junk.mail.me.not.mac.com> wrote
...
> > What this does is sending a message to the running application to load
> > arbitrary AppleScript code and execute within that application. The
> > code will remain part of the application.
>
> And what happens when I create objects based on the original definition
> of a class, and then redefine that class? What becomes of these
> previously created objects based on the original defintion?
First of all, you keep changing your test. At first, you said it was
impossible to insert new AppleScript code into an application written
in AppleScript while that application is running, without recompiling
the application and without restarting it.
I showed you how you can do just that.
Nobody claimed that the way you do this is as good as or better than
the way you do it in Lisp. The point was that it is not only possibly
to accomplish, but AppleScript has been designed this way, it is not a
clutch, not a hack, not bolted on.
Secondly, my point was that your test isn't really the issue here but
instead, you defintion is based on Lisp as a reference model and
anything that doesn't match closely in your view will therefore fall
outside your definition. Your response is further proof for that.
Not that I have a problem with using a definition based on a reference
model. I have repeatedly said that there is nothing wrong with that.
However, what I do have a problem with is your selling us your
reference model as the ultimate truth. It is *just one* of many
possible models.
> Oops, you're screwed.
What you are really talking about now, is how to manage code
dependencies in complex systems. This is a non-trivial matter and it
can be challenging in any environment, even in Lisp. It is by no means
confined to patching of running applications.
And, yes, I agree, Lisp is definitely far more suitable for complex
systems than AppleScript or most other, perhaps any other languages.
But that wasn't at issue.
The issue was whether or not you can build up an application while it
is running by adding new code without having to recompile nor restart.
Mind you, I didn't even make this an issue, but it was you who brought
it up.
With regards to the actual problem you describe, I have to say that it
has a lot to do with how you organise your code and I would avoid
running into the situation in the first place.
On the one hand I often organise script objects as data capsules, so I
can change internal representation without having to worry about
dependencies, because all dependencies are contained within the script
object.
On the other hand, AppleScript supports optional paramaters, labelled
parameters, continuation and overloading. So there are plenty of tools
at hand to extend and change script objects without breaking any code.
I am not saying that it is impossible to break code, but the same
applies to any other environment, including Lisp. If you develop a
complex system there is always a chance you paint yourself into a
corner. That's no news.
> You've desribed a well known hackish workaround for statically compiled
> languages, and I've just shown why it's a badly broken solution.
You seem to be talking about the C example Dan gave us, which I
believe was meant more jokingly that seriously.
What I have described is not a workaround and it isn't broken either.
AppleScript was *designed* to support patching of running AppleScript
apps.
> You won't be able to redefine exiting objects without tearing them down
> manually and rebuilding them based on the new class definition. At this
> point, you would do just as well to quit the application, recompile, and
> relaunch.
>
> You haven't shown that AppleScript applications can be *changed* while
> they are running. You can just send them messages, and add funtionality
> by doing inter-process communication. This is a very limited form of
> imitation dynamism, which is fundamentally broken for complex systems,
> with lots of live objects.
I don't want to appear rude, but it seems to me that you didn't
understand the examples.
What happens is you send a message to the AppleScript application,
said message telling said application to load a script object,
incorporate said script object in said application and execute code
represented by said script object within said application.
The fact that you use an IPC message to instruct the application to do
this, does not change the fact that arbitrary code is being inserted
into the application while it is running.
> Moreover, none of this is being done from the application itself.
Well, yes and no. The application has a listener that listens to
events. It cannot understand text input without a front end that
translates text into events. You may think of this as a distributed
listener, where the backend is in the application and the front-end is
separate. One such front-end is built into ScriptEditor, which comes
with AppleScript, so we may as well use that.
Having a distributed listener has its advantages. You can talk to any
AppleScript app from any other AppleScript app even across different
systems. If you want that in Lisp you have to write a remote REPL
server first, not a big deal for most Lispers, but its not there by
default.
Likewise, it is no big deal for someone experienced in AppleScript to
write a Lisp style listener and drop it into an AppleScript
application's idle handler. For example, within the application's idle
handler you could run a rudimentary telnet server and coerce the user
input received from a connected telnet client into a script object,
then incorporate and execute that code on the fly. You don't need to
use ScriptEditor to compile the script object.
> You
> have to use a separate application, ScriptEditor, to compile the script
> first, then tell your application stub to execute this separate compiled
> script.
It need not be compiled. You can send plain text to any running
AppleScript application and tell it to coerce the text into a script
object, then execute it on the fly. I don't assume that the
application itself contains the compiler, so I believe that the
application will ask the compiler behind the scenes to compile the
code as it is coerced into a script object. Again, distributed
architecture. In Lisp you've got everything in one monolithic image,
which has its advantages, too. In AppleScript you have those
instruments distributed.
Just because it's differently implemented doesn't mean it's a
workaround or a hack.
> With Common Lisp, you get the abilty to redefine existing objects when
> you change their class defintitions, as well as a built in top level
> listener that lets you change your application from within that
> application itself.
>
> You don't get either with AppleScript, which is why Common Lisp is a
> dynamic language, and AppleScript is not.
Hahaha, :-) :-) :-)
Sounds like ...
A: "Electrical engines are circular motion engines and combustion
engines are not"
B: "Umm, some combustion engines are circular motion engines, too"
A: "No, it's a fake, the generated motion is oscillating, then
converted"
B: "Er, no, the Wankel engine generates circular motion directly"
A: "But that's cheating. It's really a tri-directional *circular-like*
motion converted into circular motion. Only electrical engines
generate circular motion which is why the Wankel engine is not a
circular motion engine"
B: "???"
... to me, but if you insist, I don't want to mess with what would
seem to be a rather strange kind of logic.
rgds
bk
·········@yahoo.co.uk (BK) wrote in message news:<····························@posting.google.com>...
> Raffael Cavallaro <················@junk.mail.me.not.mac.com> wrote
> First of all, you keep changing your test. At first, you said it was
> impossible to insert new AppleScript code into an application written
> in AppleScript while that application is running, without recompiling
> the application and without restarting it.
>
No, I said it was impossible to *change* the code of a running
AppleScript application. Look at my very first response to your inane
stubbornness about ProjectBuilder and Lisp:
"There is no read-eval-print-loop; you
must halt the app and recompile entirely if you modify classes (i.e.,
no change-class, no update-instance-for-redefined-class, for example),
or indeed any source code at all."
You've simply demonstrated a hack to get a running application to run
a separate script, but this loaded script cannot change existing
objects in that running Application. More importantly, redefinitions
of exiting classes will not propagate to existing instances. This is
*fatal* for anything but a toy application.
The ability to merely run new code is not dynamism. Any application
that can run a script can do that. Dynamism is the abilty to *change*
existing objects, while the application is still running.
Please read what I wrote almost 10 days ago. From the very start, I
pointed out that AppleScript was not dynamic because you can't modify
existing objects in a running application.
[mondo snippage]
You really ought to learn how to say what you have to more succinctly.
It seems like you're ranting at length to avoid the obvious conclusion
that AppleScript is not a dynamic language.
Oh, and before you get on that hobby horse again, ProjectBuilder only
works with edit-compile-debug languages, not dynamic languages like
lisp.
Raf
·······@mediaone.net (Raffael Cavallaro) wrote ...
> No, I said it was impossible to *change* the code of a running
> AppleScript application.
And you can do that in AppleScript, too. Insert new script objects
into your code, extend existing script objects with new properties and
methods, replace existing script objects altogether. But perhaps you
are now going to tell me some restricted definition for the word
"change" that will keep these out.
Look at my very first response to your inane
> stubbornness about ProjectBuilder and Lisp:
>
> "There is no read-eval-print-loop; you
> must halt the app and recompile entirely if you modify classes (i.e.,
> no change-class, no update-instance-for-redefined-class, for example),
> or indeed any source code at all."
>
> You've simply demonstrated a hack to get a running application to run
> a separate script,
No. The Application does not run a separate script. Loading a script
object is not running an external program. That's where your
misunderstanding lies.
Then again, you may always take the view that loading a package into a
lisp image is nothing but a hack to get the lisp application to run a
separate Lisp program. I woldn't see it that way, though.
As for the remainder of your post, I should tell you that the chances
of me responding to teasing are very small. Usually, I would only
choose to be teased if the teaser is female and sitting right next to
me. Sorry to disappoint you.
rgds
bk
In article <····························@posting.google.com>,
·········@yahoo.co.uk (BK) wrote:
> ·······@mediaone.net (Raffael Cavallaro) wrote ...
>
>
> > No, I said it was impossible to *change* the code of a running
> > AppleScript application.
>
> And you can do that in AppleScript, too. Insert new script objects
> into your code, extend existing script objects with new properties and
> methods, replace existing script objects altogether.
You cannot change the definition of a script object in AppleScript and
have that new definition apply to existing script objects. Period. Read
my original post, please. I've now asked you to do this twice. There's a
reason why I specifically mentioned update-instance-for-redefined-class
in my original post *10 days ago*.
In AppleScript you can only *add* code, and *add* clases, and *add*
objects, but you cannot *change* existing classes and have those changes
*propagate to existing objects*. AppleScript can confuse the distinction
somewhat, but please realize that there is an important difference
between changing a single script object (using set myObject to...), and
changing a class of script objects (which usually means changing the "on
makeMyObject(foo, bar, baz) handler). When you do the latter in
AppleScript, existing myObject instances *do not change*.
With an application of any real size and complexity, meaning, with any
application that is not a toy, the task before us with AppleScript is to:
1. Find every instance of the redefined class in existence in our
running application at the time you redefined the class.
2. Copy their properties into new instances of the redefined class.
3. Reassign all the variables pointing to the old instances to their
equivalent new instances.
4. Do so in such a way that running processes are not broken by the
switchover.
Good luck.
Common Lisp does this for you *automatically* when you redefine a class.
I hope you see that such facilities need to be part of the runtime of
the language, not something that you write yourself - it's just too
error prone, especially for complex systems.
Such facilities are *not* part of the AppleScript runtime, which is why
AppleScript is object oriented, but not dynamic. It was designed to be
statically compiled. The designers of AppleScript assumed that you would
halt your application, recompile, and restart if you redefined classes.
Should you decide you want to add the equivalent functionality of
update-instance-for-redefined-class, don't forget about
update-instance-for-new-class,
change-class,
make-instances-obsolete ...
And now, of course, you've invoked Greenspun's Tenth Rule of programming:
"Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified, bug-ridden, slow implementation of half of Common
Lisp."
Except you've replaced "C or Fortran" with "C or Fortran or AppleScript."
Please execute the example below, and understand why the "dynamism" of
AppleScript is broken.
From the CLHS entry on update-instance-for-redefined-class with parallel
AppleScript code by yours truly:
(defclass position () ())
(defclass x-y-position (position)
((x :initform 0 :accessor position-x)
(y :initform 0 :accessor position-y)))
;;;In AppleScript this would be:
on makePosition(x, y)
script position
property xCoordinate:x
property yCoordinate:y
end script
return position
end makePoint
;;; Lets make a position object using this original defintion...
set myOldPositionObject to makePosition(3,4)
;;; It turns out polar coordinates are used more than Cartesian
;;; coordinates, so the representation is altered and some new
;;; accessor methods are added.
(defmethod update-instance-for-redefined-class :before
((pos x-y-position) added deleted plist &key)
;; Transform the x-y coordinates to polar coordinates
;; and store into the new slots.
(let ((x (getf plist 'x))
(y (getf plist 'y)))
(setf (position-rho pos) (sqrt (+ (* x x) (* y y)))
(position-theta pos) (atan y x))))
;;;This isn't possible in AppleScript - there is no equivalent to
;;;update-instance-for-redefined-class
(defclass x-y-position (position)
((rho :initform 0 :accessor position-rho)
(theta :initform 0 :accessor position-theta)))
;;; All instances of the old x-y-position class will be updated
;;; automatically. (in Common Lisp only)
;;; We should start to smell trouble already, since we know
;;; this can't happen in AppleScript
;;; The new representation is given the look and feel of the old one.
(defmethod position-x ((pos x-y-position))
(with-slots (rho theta) pos (* rho (cos theta))))
(defmethod (setf position-x) (new-x (pos x-y-position))
(with-slots (rho theta) pos
(let ((y (position-y pos)))
(setq rho (sqrt (+ (* new-x new-x) (* y y)))
theta (atan y new-x))
new-x)))
(defmethod position-y ((pos x-y-position))
(with-slots (rho theta) pos (* rho (sin theta))))
(defmethod (setf position-y) (new-y (pos x-y-position))
(with-slots (rho theta) pos
(let ((x (position-x pos)))
(setq rho (sqrt (+ (* x x) (* new-y new-y)))
theta (atan new-y x))
new-y)))
;;; In AppleScript the new class definition becomes
;;; the following, if we want to use the same x and y
;;; style coordinates for initialization...
on makePosition(x, y)
script position
property rho:(sqrt((x * x) + (y * y)))
property theta:(atan(y x))
end script
return position
end makePoint
;;; ... assuming you have two functions sqrt and atan (I don't think
;;; that they are part of the AppleScript base language).
;;; Now, when you create a new position object by doing...
set myNewPositionObject to makePosition(3, 4)
;;; it works as expected:
get rho of myNewPositionObject --returns 5
;;; But if we try to use the new class definition with
;;; an object made when the old class definition was
;;; in effect, we can't
get rho of myOldPositionObject --returns an error
Raf
It occurs to me that you may not be clearly seeing the difference
between individual instances (i.e., individual "script objects" in
AppleScript) and classes ("on makeMyObject(foo, bar, baz)" handlers in
AppleScript.
note that:
script point
property x : 0
property y : 0
end script
creates only a single instance, a single script object, but this...
on makePoint(x, y)
script point
property xCoordinate:x
property yCoordinate:y
end script
return point
end makePoint
defines a point class, from which an unlimited number of script objects
(i.e., instances) are made by doing...
set myPoint to makePoint(0, 0)
set myOtherPoint to makePoint(1, 2)
etc.
In AppleScript, if you change the "on makePoint(x, y)" handler, existing
objects such as myPoint, and myOtherPoint will not change to reflect the
new definition of of the "on makePoint(x, y)" handler.
In any non-toy, complex system, with thousands of objects, objects are
created by writing class definitions ("on makeFoo(param1, param2..)"
handlers), and initializing instances ("set myFoo to makeFoo(1, 3)"),
not by crafting each inividual object. That's why a dynamic language
needs runtime facilities to update existing object instances when the
class definition changes. AppleScript has no such runtime facilities.
Raf
·········@yahoo.co.uk (BK) writes:
> Raffael Cavallaro <················@junk.mail.me.not.mac.com> wrote
> ...
>
>
> > > What this does is sending a message to the running application to load
> > > arbitrary AppleScript code and execute within that application. The
> > > code will remain part of the application.
> >
> > And what happens when I create objects based on the original definition
> > of a class, and then redefine that class? What becomes of these
> > previously created objects based on the original defintion?
>
> First of all, you keep changing your test. At first, you said it was
> impossible to insert new AppleScript code into an application written
> in AppleScript while that application is running, without recompiling
> the application and without restarting it.
>
> I showed you how you can do just that.
>
> Nobody claimed that the way you do this is as good as or better than
> the way you do it in Lisp. The point was that it is not only possibly
> to accomplish, but AppleScript has been designed this way, it is not a
> clutch, not a hack, not bolted on.
Right! What's more, nobody said that it was better to upgrade the old
object with the new class. In some applications, it may be usefull,
but in others it may not be such a good idea. What if the change
you're making to the class are not compatible with the old objets? In
the Lisp/CLOS point of view, it does not matter, because if a problem
occurs, it just drop into the debugger and ask the programmer what to
do next, nice, but try to do that on a computer 3 hour.light away! Or
on a real-time system: oops, the blade's falling, I've got a bug here,
what should I do next, you have 1/1000 th of a second to answer ?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
On Sat, May 10, 2003 at 04:23:35PM +0200, Pascal Bourguignon wrote:
> Right! What's more, nobody said that it was better to upgrade the old
> object with the new class. In some applications, it may be usefull,
> but in others it may not be such a good idea. What if the change
> you're making to the class are not compatible with the old objets? In
> the Lisp/CLOS point of view, it does not matter, because if a problem
> occurs, it just drop into the debugger and ask the programmer what to
> do next, nice, but try to do that on a computer 3 hour.light away! Or
> on a real-time system: oops, the blade's falling, I've got a bug here,
> what should I do next, you have 1/1000 th of a second to answer ?
Presumably you program with these situations in mind. Having a segmentation
fault in either of these circumstances is no fun either.
Also I'm a bit curious what you consider to be a "change in a class that is not
compatible with old objects" in ANSI Common Lisp. Or why you'd be making these
changes to vital programs at critical moments. =)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Sat, May 10, 2003 at 04:23:35PM +0200, Pascal Bourguignon wrote:
> > Right! What's more, nobody said that it was better to upgrade the old
> > object with the new class. In some applications, it may be usefull,
> > but in others it may not be such a good idea. What if the change
> > you're making to the class are not compatible with the old objets? In
> > the Lisp/CLOS point of view, it does not matter, because if a problem
> > occurs, it just drop into the debugger and ask the programmer what to
> > do next, nice, but try to do that on a computer 3 hour.light away! Or
> > on a real-time system: oops, the blade's falling, I've got a bug here,
> > what should I do next, you have 1/1000 th of a second to answer ?
>
> Presumably you program with these situations in mind. Having a
> segmentation fault in either of these circumstances is no fun either.
>
> Also I'm a bit curious what you consider to be a "change in a class
> that is not compatible with old objects" in ANSI Common Lisp. Or
> why you'd be making these changes to vital programs at critical
> moments. =)
Almost any change to the attributes. For example:
name --> firstname,lastname
would delete the name slot in all existing object to create two new
empty slots. Or is there a way to specify a convertion function that
I don't know?
But you're right, whatever is provided by the underlying software, you
don't do such changes in running vital programs. Well, usually (cf.
comp.risks).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
On Sat, May 10, 2003 at 05:18:46PM +0200, Pascal Bourguignon wrote:
> Or is there a way to specify a convertion function that I don't know?
Please see chapter 7.2 and it's subchapters in the CLHS.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Tim Bradshaw
Subject: Re: Being dynamic - C vs AppleScript vs Lisp
Date:
Message-ID: <ey365oird6v.fsf@cley.com>
* Pascal Bourguignon wrote:
> Almost any change to the attributes. For example:
> name --> firstname,lastname
> would delete the name slot in all existing object to create two new
> empty slots. Or is there a way to specify a convertion function that
> I don't know?
Yes, there is. UPDATE-INSTANCE-FOR-REDEFINED-CLASS.
--tim
From: Eduardo Muñoz
Subject: Re: Being dynamic - C vs AppleScript vs Lisp
Date:
Message-ID: <ud6iqeqcx.fsf@terra.es>
* Pascal Bourguignon <····@thalassa.informatimago.com>
| Almost any change to the attributes. For example:
|
| name --> firstname,lastname
|
| would delete the name slot in all existing object to create two new
| empty slots. Or is there a way to specify a convertion function that
| I don't know?
See update-instance-for-redefined-class.
Isn't CL amazing? :)
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
From: Kenny Tilton
Subject: Re: Being dynamic - C vs AppleScript vs Lisp
Date:
Message-ID: <3EBD4A61.4010801@nyc.rr.com>
Eduardo Mu�oz wrote:
> * Pascal Bourguignon <····@thalassa.informatimago.com>
> | Almost any change to the attributes. For example:
> |
> | name --> firstname,lastname
> |
> | would delete the name slot in all existing object to create two new
> | empty slots. Or is there a way to specify a convertion function that
> | I don't know?
>
> See update-instance-for-redefined-class.
> Isn't CL amazing? :)
>
Yep. But I think PB was asking about AppleScript.
Pardon my "third man in" violation, I will now sneak back to the bench
before the ref gets my number.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
> But you're right, whatever is provided by the underlying software, you
> don't do such changes in running vital programs. Well, usually (cf.
> comp.risks).
Actually, if your program can't go down (e.g., it's a server with active
connections), you can, and should make changes in that program as it
runs. That's one of the reasons that
update-instance-for-redefined-class, update-instance-for-changed-class,
change-class, make-instances-obsolete, etc. exist, for precisely such
situations where a critical application cannot be halted, but changes
need to be implemented.
If you are so sure that AppleScript is not a dynamic language, I
assume you would trust a captive account tied to a single AppleScript
application (ie student exercises dialog), anything else disabled.
Well, you could have a surprise there because your students could talk
to that application and teach it new tricks, no recompile, no restart,
no memory poking, just plain AppleScript.
I'll show you how this works in another thread with a more appropriate
subject.
rgds
bk
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> ·········@yahoo.co.uk (BK) writes:
> C is a dynamic language, because you can use dlopen() and dlsym() to
> change code in a running application.
Don't let them see you posting that to comp.lang.c or you'll be flamed
mightily. Neither of these calls are defined by the C programming
language
>Or, for that matter, mmap an
> area of virtual memory with the PROT_EXEC flag, poke bytes into it,
> then jump to it.
Which only works if you know the arity, parameter types, and return
type of the function in question at compile time. Lisp lets you do
this sort of thing at run time, which is the whole point of a dynamic
language - to change code at runtime, using information you didn't
have at compile time.
In order for your scheme to work, you have to have acess to the
compiler, and the right combination of compiler switches, at run time,
and again, such acess is not uniformly available across systems. For
example, this is why Jonathan Bachrach's goo doesn't work under Mac OS
X, which *is* a Unix system.
A read-eval-print loop is uniformly available in Common Lisp, which is
why lisp is a dynamic langauge, and C is not.
·········@yahoo.co.uk (BK) wrote in message news:<···························@posting.google.com>...
> ·······@mediaone.net (Raffael Cavallaro) wrote ...
> > To lispers and smalltalkers, a language is only dynamic if you can
> > change code in a running application/image.
>
> So it is to AppleScripters.
>
> You are confusing availability with flexibility. Just because an
> available feature isn't as flexible as you would like it to be doesn't
> mean it's not available.
This facility is not availabe to AppleScripters *at all*.
Are you just being stubborn, or do you really not know what it means
to change code in a running application/image?
We're not talking about writing different AppleScripts over time that
target the same, continuously running, pre-existing application,
(e.g., Mail.app, or Safari). That's just inter-process communication,
and any language can do that, with the right OS API hooks.
We're talking about writing an application in AppleScript itself,
launching it, and changing the AppleScript code of that AppleScript
application, while that AppleScript application is still running. You
simply cannot do this in AppleScript at all. In AppleScript you have
to quit the running AppleScript application, make your code changes,
recompile, and relaunch the AppleScript application. Sorry for the
numerous "AppleScript"s above, but I want to be completely unambiguous
about this, as it's getting quite tiresome to hear that AppleScript
can do what it clearly cannot.
In fact, I challenge you to prove your assertions by providing a
series of simple steps that demonstrate your supposed abilty to change
the AppleScript code of a running AppleScript application while that
AppleScript application is running. Really, don't bother, because it
can't be done. AppleScript is a statically compiled language.
You can change code in a running application trivially in Common Lisp,
which is, once again, why Common Lisp is a dynamic language, and
AppleScript is not.
Thanks to anyone who helped me with this. A follow up post under the
more appropriate title "[How-to] carbonised/Aqua emacs with ILISP
under OSX" is at
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&group=comp.lang.lisp&selm=39d9c156.0305040229.718ae840%40posting.google.com
rgds
bk