How to integrate OpenMCL w/ProjectBuilder&InterfaceBuilder on OSX?
BK
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
Thomas F. Burdick
> 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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
BK
> 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
Thomas F. Burdick
> t...@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.
BK
> 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.
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.
--tim
Adam Warner
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
BK
> 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
Adam Warner
> 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
Marco Antoniotti
BK wrote:
> t...@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
Edi Weitz
> 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.
BK
> 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
BK
> > 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
Marco Antoniotti
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
ilisp...@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
Michael Hudson
> 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
Raffael Cavallaro
> 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.
BK
> bk_u...@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
Adam Warner
> 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
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!
BK
>
> 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
BK
> 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
Thomas F. Burdick
> raf...@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.
BK
> bk_u...@yahoo.co.uk (BK) writes:
>
> > raf...@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
BK
more appropriate title "[How-to] carbonised/Aqua emacs with ILISP
under OSX" is at
rgds
bk
Raffael Cavallaro
[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.
Raffael Cavallaro
> 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.
BK
> 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
BK
> 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
Espen Vestre
> 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)
BK
> 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
Daniel Barlow
>> 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
BK
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
Raffael Cavallaro
> bk_u...@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.
Raffael Cavallaro
> > 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.
Raffael Cavallaro
> 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
BK
> > 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
Raffael Cavallaro
bk_u...@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