A couple weeks ago I was in New York and did a couple talks, one at
the LispNYC group and the other at Google's NY office. The video of
the Google talk is up at:
<http://video.google.com/videoplay?docid=448441135356213813>
In theory the LispNYC talk was taped too but apparently there were
some problems with the audio that the AV wizards may or may not be
able to straighten out; I'll post again if it shows up on the web.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> A couple weeks ago I was in New York and did a couple talks, one at
> the LispNYC group and the other at Google's NY office. The video of
> the Google talk is up at:
>
> <http://video.google.com/videoplay?docid=448441135356213813>
>
> In theory the LispNYC talk was taped too but apparently there were
> some problems with the audio that the AV wizards may or may not be
> able to straighten out; I'll post again if it shows up on the web.
>
> -Peter
>
Perfect timing as I just watched the video today... could you summarize
your response to the last question in the talk? (it was cut off in the
video)
Thanks,
Phil
Foxpointe <·········@comcast.net> writes:
> Peter Seibel wrote:
>> A couple weeks ago I was in New York and did a couple talks, one at
>> the LispNYC group and the other at Google's NY office. The video of
>> the Google talk is up at:
>> <http://video.google.com/videoplay?docid=448441135356213813>
>> In theory the LispNYC talk was taped too but apparently there were
>> some problems with the audio that the AV wizards may or may not be
>> able to straighten out; I'll post again if it shows up on the web.
>> -Peter
>>
>
> Perfect timing as I just watched the video today... could you summarize
> your response to the last question in the talk? (it was cut off in the
> video)
The really short version is "Plank Road Fever" as described in the
book "The Wisdom of Crowds".
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
>
> The really short version is "Plank Road Fever" as described in the
> book "The Wisdom of Crowds".
>
> -Peter
>
That was a really short summary ;-) Did a quick search on PRF and
learned a bit of history that was new to me as well as seeing the
obvious comparisons to the tech industry which can be made esp. re: your
answer in the talk. I'll check out the book as it looks interesting.
Phil
Peter Seibel wrote:
> A couple weeks ago I was in New York and did a couple talks, one at
> the LispNYC group and the other at Google's NY office. The video of
> the Google talk is up at:
>
> <http://video.google.com/videoplay?docid=448441135356213813>
>
Very cool. I'd also be interested in hearing why you think nobody uses
CL :)
Brad
From: Wade Humeniuk
Subject: Re: Video of a talk I did at Google's NYC office
Date:
Message-ID: <HQ6cg.32814$fV1.16366@edtnps82>
Peter Seibel wrote:
> A couple weeks ago I was in New York and did a couple talks, one at
> the LispNYC group and the other at Google's NY office. The video of
> the Google talk is up at:
>
> <http://video.google.com/videoplay?docid=448441135356213813>
>
> In theory the LispNYC talk was taped too but apparently there were
> some problems with the audio that the AV wizards may or may not be
> able to straighten out; I'll post again if it shows up on the web.
>
Hey Peter, Good Job.
Next time, if there is a next one, I would like to hear you ask the
audience why some of them have not taken the time to learn Lisp.
Obviously the crowd was there because they were intellectually
curious, but some had not taken the time to learn Lisp. I assume
that the room was full of the cream of the crop and it would have
been a great opportunity to learn something.
Sometimes when I discuss Lisp in-person with programmers I get this
feeling that they are scared of it.
Wade
Wade Humeniuk <··················@telus.net> writes:
> Sometimes when I discuss Lisp in-person with programmers I get this
> feeling that they are scared of it.
I get the feeling that most programmers want Java just because it
creates work. Just like breaking windows keeps glaziers in business.
--
http://www.david-steuber.com/
1998 Subaru Impreza Outback Sport
2006 Honda 599 Hornet (CB600F) x 2 Crash & Slider
The lithobraker. Zero distance stops at any speed.
David Steuber <·····@david-steuber.com> writes:
> Wade Humeniuk <··················@telus.net> writes:
>
>> Sometimes when I discuss Lisp in-person with programmers I get this
>> feeling that they are scared of it.
>
> I get the feeling that most programmers want Java just because it
> creates work. Just like breaking windows keeps glaziers in business.
Programmers want Java because it does the job for them, and it does it
well. No matter what library you need, it's already there, just get the
jar file and use it. Database, sockets, threads, web apps - it's all in
the language standard, easy to learn and use.
I like Lisp very, and whenever I program for fun, I use it (I am
restricted to Java at my day job).
But let me give you an example why I recently used Java in one of my
"for fun" projects: I wanted to write an editor that can do keyword
highlighting. I thought may be I could use some part of Climacs and I
tried it: it turned out that it is almost unusable, at least at its
current stage. Then I looked for a Java solution, and it took me about 20
minutes to embed the highlighting package from the jEdit editor in my
application.
So the reason people use Java is quite simple: it has zillions of freely
distributable libraries that do the job well, so people use them.
--
vedm
vedm <··@ns.com> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Wade Humeniuk <··················@telus.net> writes:
> >
> >> Sometimes when I discuss Lisp in-person with programmers I get this
> >> feeling that they are scared of it.
> >
> > I get the feeling that most programmers want Java just because it
> > creates work. Just like breaking windows keeps glaziers in business.
>
> Programmers want Java because it does the job for them, and it does it
> well.
After spending the last couple days fighting this god forsaken shit, I
really must object to this highly inflated claim. And it's not as if
I am trying to do something really over the moon either. Java just
plain is waaaaaayyy toooo much work for very little return. Which
sort of fits Peter's point: it makes work.
> No matter what library you need, it's already there, just get the
> jar file and use it.
LOL. No, actually shake head and sob....
> "for fun" projects: I wanted to write an editor that can do keyword
> highlighting. I thought may be I could use some part of Climacs and I
> tried it: it turned out that it is almost unusable, at least at its
> current stage.
This is very funny. This is a small part of the stuff that Java (well
to be fair in this particular, Swing) sort of gets right at the
expense of getting other stuff wrong - and you have no hope of fixing
it without a lot of effort either.
> minutes to embed the highlighting package from the jEdit editor
^^^^^
At the moment, I would consider this thing one of the biggest pieces
of shit ever foisted off as real working and useable code.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
On Sun, 21 May 2006 21:43:55 -0400, jayessay wrote:
>> minutes to embed the highlighting package from the jEdit editor
> ^^^^^
>
> At the moment, I would consider this thing one of the biggest pieces
> of shit ever foisted off as real working and useable code.
I'm sure this would come as quite a surprise to Slava. Just to get another
data point, how big a piece of shit do you consider the clever, elegant,
and highly productive Factor(http://factorcode.org/)
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank <·······································@c.net> writes:
> Just to get another data point, how big a piece of shit do you
> consider the clever, elegant, and highly productive
> Factor(http://factorcode.org/)
Don't know anything about, so can't comment. Sorry.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Ken Tilton
Subject: Re: Video of a talk I did at Google's NYC office
Date:
Message-ID: <WR8cg.1225$w05.465@fe10.lga>
vedm wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>
>>Wade Humeniuk <··················@telus.net> writes:
>>
>>
>>>Sometimes when I discuss Lisp in-person with programmers I get this
>>>feeling that they are scared of it.
>>
>>I get the feeling that most programmers want Java just because it
>>creates work. Just like breaking windows keeps glaziers in business.
>
>
> Programmers want Java because it does the job for them, and it does it
> well. No matter what library you need, it's already there, just get the
> jar file and use it. Database, sockets, threads, web apps - it's all in
> the language standard, easy to learn and use.
>
> I like Lisp very, and whenever I program for fun, I use it (I am
> restricted to Java at my day job).
>
> But let me give you an example why I recently used Java in one of my
> "for fun" projects: I wanted to write an editor that can do keyword
> highlighting. I thought may be I could use some part of Climacs and I
> tried it: it turned out that it is almost unusable, at least at its
> current stage. Then I looked for a Java solution, and it took me about 20
> minutes to embed the highlighting package from the jEdit editor in my
> application.
If you use one of the many Lisp interfaces to Tk you would not need to
look for anything; the text widget supports that out of the box with
tags. Tcl and Tk offer a lot of things out of the box, including sockets
and threads. Portably. And I can stop pining for Supercollider real-time
audio synthesis: Tcl has Snack. Something I did have to go looking for.
kt
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
> > I get the feeling that most programmers want Java just because it
> > creates work. Just like breaking windows keeps glaziers in business.
>
> Programmers want Java because it does the job for them, and it does it
> well. No matter what library you need, it's already there, just get the
> jar file and use it. Database, sockets, threads, web apps - it's all in
> the language standard, easy to learn and use.
Being a 30-year Lisp programmer, and having published on and taught
Lisp and Lisp-related topics hundreds of times, and being a big
supporter of Lisp [yeah yeah, I wrote a lisp book too!], I have to say
that I agree with this completely! About seven years ago I
painstakingly wrote a small but complex Java program that did some
multi-media stuff (using awt/jmf). I did it in emacs using examples
from books, and it worked moderately well. It was very painful, but I
was told that that's what Java is for, and so I did it, although it
wasn't too fun.
This year I have set out to rewrite that program, and the world is a
different place! First off, Eclipse is great! (If it had macros,
keyboard commands, and was Lisp-programmable it would be The Killer
App!) Eclipse does half the work for you by debugging stupid typos (and
many thinkos!) and looking up arguments and methods really efficiently.
But the most important thing that really makes Java fantastically
useful for complex (esp. graphical) apps is google: Pretty near
anything that you can image has either a package, or example code
online, and often both! It really is like lego programming: Need to
iconize images? Hey, no problem: Here's a package and your choice of,
like, a hundred example code snippets. Need to run a video, start and
stop it on command, float it across the screen, and let the user drag
and drop it into a windows hierarchy? Well, there's no code for that
complete thing, but there are for each piece, and the things amazingly
ust work together like magic!
You might say: Well, yeah, but you can call that Java stuff from Lisp
too, and you get other advantages, like macros and multiple-inheritance
and theorem provers. Okay, and I agree that if I had anything smart to
do, like something needing a theorem prover or inventing my own
sublanguage, I'd certainly turn to Lisp, not Java (and still do!**) But
if what you're doing is pasting together lots of fancy interface
machinery, and all that the language itself is doing for you is calling
out to complex routines that you have no idea how they work -- but they
*do* work -- then Java/Eclipse is fun and easy and get's it done.
[** In fact, what I do these days is to do the interface in Java and
the complex computing in Lisp, and talk between them using XML-RPC. So,
when I hit the wall in Java I send the problem to Lisp, and v.v. It's
not the most efficient thing in the world bcs of the serialization, but
it works well, and since the Java does the complex graphical stuff
locally -- if you can tell the local (java) GUI what to do and then let
it go, no sweat! This works great, and it makes both side of the task
fun by putting the relevant work on the relevant language. ]
Having avoided Java for ... well, since its birth, I have to say that
I'm having fun making rather complex things happen on the screen in
pretty much no time at all! (And, BTW, my friends and family can
download my code using WebStart and It Just Works!)
[And don't Tk me! I spent three years as Director of Engineering of a
startup that used Lisp/Tk. I've programmed extremely complex Lisp/Tk
and we made literally *millions* of dollars at it, but it was among the
most painful experiences I've ever had! (Not the making money part --
the Tk graphics part!)]
> [And don't Tk me! I spent three years as Director of Engineering of a
> startup that used Lisp/Tk. I've programmed extremely complex Lisp/Tk
> and we made literally *millions* of dollars at it, but it was among the
> most painful experiences I've ever had! (Not the making money part --
> the Tk graphics part!)]
>
Jes curious, since I am just starting down the Lisp/Tk route, what was
painful? Buggy? Hard to get it to do what you wanted? Weak widget set?
I have just built the Lisp interface so have not really engaged the
beast in anger, jes wondering if I have wandered onto a mine field.
kenny
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
On Mon, 22 May 2006 17:53:44 -0400, Ken Tilton <·········@gmail.com>
wrote:
>
>> [And don't Tk me! I spent three years as Director of Engineering of a
>> startup that used Lisp/Tk. I've programmed extremely complex Lisp/Tk
>> and we made literally *millions* of dollars at it, but it was among the
>> most painful experiences I've ever had! (Not the making money part --
>> the Tk graphics part!)]
>>
>
>Jes curious, since I am just starting down the Lisp/Tk route, what was
>painful? Buggy? Hard to get it to do what you wanted? Weak widget set?
>I have just built the Lisp interface so have not really engaged the
>beast in anger, jes wondering if I have wandered onto a mine field.
>
>kenny
I haven't tried Lisp/Tk ... I still have a bad taste in my mouth from
a C++/Tk experience (the Tk part, not the C++) about 10 years ago.
The app I worked on was part of a distributed system, was
multithreaded and had a number of autonomous background tasks to
monitor as well as a mix of short and long running user tasks that
could be initiated and controlled from the Tk gui.
I suppose that Tk is very different now, but when I used it, the only
way to communicate with Tk was to pass it ASCII commands in formatted
strings and only global variables with simple data types (int, float,
etc.) could be shared between Tk and C++ - no structured data.
It was very complicated to set up data passing between the gui and the
service code beneath it. The (necessary) multithreading made things
worse because only the main program thread could communicate with Tk.
The Tk event loop dispatched in strict FIFO order ... prioritizing or
rearranging event handling had to be done in the service code and
required user defined events and queue management.
I won't say it was overwhelmingly hard ... but it sure was a lot more
convoluted than doing the same thing using X/Motif or Mac Toolkit or
Windows -- at least from the C/C++ perspective.
I've heard a lot of good things about Tk in the last few years, but
I've just been loathe to try it again.
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Mon, 22 May 2006 17:53:44 -0400, Ken Tilton <·········@gmail.com>
> wrote:
>
> >
> >> [And don't Tk me! I spent three years as Director of Engineering of a
> >> startup that used Lisp/Tk. I've programmed extremely complex Lisp/Tk
> >> and we made literally *millions* of dollars at it, but it was among the
> >> most painful experiences I've ever had! (Not the making money part --
> >> the Tk graphics part!)]
> >>
> >
> >Jes curious, since I am just starting down the Lisp/Tk route, what was
> >painful? Buggy? Hard to get it to do what you wanted? Weak widget set?
> >I have just built the Lisp interface so have not really engaged the
> >beast in anger, jes wondering if I have wandered onto a mine field.
> >
> >kenny
>
> I haven't tried Lisp/Tk ... I still have a bad taste in my mouth from
> a C++/Tk experience (the Tk part, not the C++) about 10 years ago.
> The app I worked on was part of a distributed system, was
> multithreaded and had a number of autonomous background tasks to
> monitor as well as a mix of short and long running user tasks that
> could be initiated and controlled from the Tk gui.
>
> I suppose that Tk is very different now, but when I used it, the only
> way to communicate with Tk was to pass it ASCII commands in formatted
> strings and only global variables with simple data types (int, float,
> etc.) could be shared between Tk and C++ - no structured data.
When I last used Tk in 2002 it was still like this unfortunately. It's
really fast and really easy to code simple things with. The Canvas
widget is very good.
But it's troublesomely addicted to simple interfaces, such as strings
for everything.
Tk is not thread safe, but neither is GTK really or wxWidgets or Win32
- though some provide ways to do thread-safety in programs.
I had another small problem with it, I couldn't find a good way to
print out images in the GUI.
Rob Thorpe wrote:
> But it's troublesomely addicted to simple interfaces, such as strings
> for everything.
There is a C API now, and the string interface is deprecated in favor of
an object interface, nicely latered under the string interface so you
can mix calls between the two.
>
> Tk is not thread safe, but neither is GTK really or wxWidgets or Win32
> - though some provide ways to do thread-safety in programs.
>
> I had another small problem with it, I couldn't find a good way to
> print out images in the GUI.
>
I have a budding portable common lisp displayPDF library built to the
Quartz API I plan to use for hardcopy. Yusuke Shinyama is the author and
is doing a great job.
kenny
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
George Neuner wrote:
> I suppose that Tk is very different now, but when I used it, the only
> way to communicate with Tk was to pass it ASCII commands in formatted
> strings and only global variables with simple data types (int, float,
> etc.) could be shared between Tk and C++ - no structured data.
There is a full C API now, to Tcl and Tk.
http://tmml.sourceforge.net/doc/tcl/#DIVid8195388
http://tmml.sourceforge.net/doc/tk/#DIVid8194960
kenny
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
George Neuner <·········@comcast.net> writes:
> I suppose that Tk is very different now, but when I used it, the only
> way to communicate with Tk was to pass it ASCII commands in formatted
> strings and only global variables with simple data types (int, float,
> etc.) could be shared between Tk and C++ - no structured data.
This is "just" a matter of wrapping it. Which is exactly what Ltk has
done. As far as you, the Lisp programmer, are concerned, Tk is just a
widget set implemented with CLOS.
From: Ken Tilton
Subject: Cello Rizng (was Re: Lisp v. Java/Eclipse)
Date:
Message-ID: <EPLcg.789$mN3.750@fe09.lga>
Rajappa Iyer wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>>[And don't Tk me! I spent three years as Director of Engineering of a
>>>startup that used Lisp/Tk. I've programmed extremely complex Lisp/Tk
>>>and we made literally *millions* of dollars at it, but it was among the
>>>most painful experiences I've ever had! (Not the making money part --
>>>the Tk graphics part!)]
>>>
>>
>>Jes curious, since I am just starting down the Lisp/Tk route, what was
>>painful? Buggy? Hard to get it to do what you wanted? Weak widget set?
>>I have just built the Lisp interface so have not really engaged the
>>beast in anger, jes wondering if I have wandered onto a mine field.
>
>
> I haven't looked at Lisp/Tk (I presume you're talking about Ltk by
> Peter Herth)
No, Peter's fine exmaple turned me on to Tcl/Tk, but I first did the
Cells thing on it, then Frank Goenninger and I decided we could not live
without OpenGL, so we had to get Tk running in the same process (or use
the string interface to do Opengl -- eewwwww). Took out the LTk core and
called Tcl_Interp to get an embedded interpreter.
Makes everything a lot easier, actually, and bindings are a joy with CFFI.
kenny
ps. Cello (my OpenGL-based GUI) is being resurrected atop the Togl
widget, though we will use many Tk widgets to get the native thing.
kt
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
········@gmail.com writes:
> This year I have set out to rewrite that program, and the world is a
> different place! First off, Eclipse is great! (If it had macros,
> keyboard commands, and was Lisp-programmable it would be The Killer
> App!) Eclipse does half the work for you by debugging stupid typos (and
> many thinkos!) and looking up arguments and methods really efficiently.
At least on my machine Eclipse felt sluggish with JDK 1.4.1 and
painfully sluggish with 1.5 (both on FreeBSD). Even most basic commands
take seconds, e.g. creating a new file which you do fairly often with
Eclipse. Of course, Eclipse eases writing Java considerably, but I am
far from calling it "Killer App".
> Having avoided Java for ... well, since its birth, I have to say that
> I'm having fun making rather complex things happen on the screen in
> pretty much no time at all! (And, BTW, my friends and family can
> download my code using WebStart and It Just Works!)
Deploying Java applications sucks, if you are not on Windows or some
well-known Linux distribution. If Java was so great for "making complex
things happen" on every system a JDK runs on, why are there so few
projects using it? The number of Java projects in the FreeBSD ports tree
seems not to be orders of magnitude larger than the number of Lisp-based
ports despite the hype.
> [And don't Tk me! I spent three years as Director of Engineering of a
> startup that used Lisp/Tk. I've programmed extremely complex Lisp/Tk
> and we made literally *millions* of dollars at it, but it was among the
> most painful experiences I've ever had! (Not the making money part --
> the Tk graphics part!)]
I can withstand some pain, if it involves lots of money. :)
Regards,
--
Julian Stecklina
Being really good at C++ is like being really good at using rocks to
sharpen sticks. - Thant Tessman
Julian Stecklina wrote:
> ········@gmail.com writes:
>
> > This year I have set out to rewrite that program, and the world is a
> > different place! First off, Eclipse is great! (If it had macros,
> > keyboard commands, and was Lisp-programmable it would be The Killer
> > App!) Eclipse does half the work for you by debugging stupid typos (and
> > many thinkos!) and looking up arguments and methods really efficiently.
>
> At least on my machine Eclipse felt sluggish with JDK 1.4.1 and
> painfully sluggish with 1.5 (both on FreeBSD). Even most basic commands
> take seconds, e.g. creating a new file which you do fairly often with
> Eclipse.
I have 2.0 GHz 512MB machine and I run eclipse just fine. May be the
problem is with your machine, regarding the performance. Eclipse only
start to slow down for me when I have large and lots of source code
opened at the same time.
> Of course, Eclipse eases writing Java considerably, but I am
> far from calling it "Killer App".
>
In the area of IDE it is Killer App.
It is best tool for doing refactoring in Java.
- How do you rename a class/method/variable and have every references
to it also renamed?
think this:
(let ((foo 'foo))
(format t "~A~%" foo)
(let ((foo 'bar))
(format t "foo ~A~%" foo)))
and rename only the inner variable foo to bar without effecting the
string, symbol or outer foo in Emacs with only a few key strokes.
- How do you move method of a class up to its super class in emacs?
- Keep history of your source code every time you save a buffer.
- Error is highlighted as you type, no need to wait for separate
compilation phase to see warning or compile error.
Compare to Eclipse, SLIME is way inferior. symbol completion is basic
in any IDE.
> > Having avoided Java for ... well, since its birth, I have to say that
> > I'm having fun making rather complex things happen on the screen in
> > pretty much no time at all! (And, BTW, my friends and family can
> > download my code using WebStart and It Just Works!)
>
> Deploying Java applications sucks, if you are not on Windows or some
> well-known Linux distribution. If Java was so great for "making complex
> things happen" on every system a JDK runs on, why are there so few
> projects using it? The number of Java projects in the FreeBSD ports tree
> seems not to be orders of magnitude larger than the number of Lisp-based
> ports despite the hype.
>
Checking from my Debian, both Lisp and Java packages available are
mostly development tool. Java seems to have twice more packages than
lisp.
Instead of showing the number of development library, I will instead
show applications that end-users uses -- as it is actually what counts
for how many project people use it.
Go to see SwingSighting, just issue 22 and 21 is enough, If you have
JRE installed, you can even click webstart button to run an application
in a sandbox:
http://java.sun.com/products/jfc/tsc/sightings/S22.html
Graphic/Sound Editor, 3D Game, MindMap, DB Frontend, PIM, Report
Generator, SpreadSheet, CVS Client, XML Editor, Data Visualization, Web
site builder, Blog tool, Desktop Publishing, .
And be honest, have you seen all that applications in Common Lisp? Does
it fills 22 pages?
P.S.
It's not that I hate Lisp, I just don't like to bend reality.
>
> Regards,
> --
> Julian Stecklina
>
> Being really good at C++ is like being really good at using rocks to
> sharpen sticks. - Thant Tessman
"Pisin Bootvong" <··········@gmail.com> writes:
> Julian Stecklina wrote:
>> ········@gmail.com writes:
>>
>> > This year I have set out to rewrite that program, and the world is a
>> > different place! First off, Eclipse is great! (If it had macros,
>> > keyboard commands, and was Lisp-programmable it would be The Killer
>> > App!) Eclipse does half the work for you by debugging stupid typos (and
>> > many thinkos!) and looking up arguments and methods really efficiently.
>>
>> At least on my machine Eclipse felt sluggish with JDK 1.4.1 and
>> painfully sluggish with 1.5 (both on FreeBSD). Even most basic commands
>> take seconds, e.g. creating a new file which you do fairly often with
>> Eclipse.
>
> I have 2.0 GHz 512MB machine and I run eclipse just fine. May be the
> problem is with your machine, regarding the performance. Eclipse only
> start to slow down for me when I have large and lots of source code
> opened at the same time.
Well, that's not really acceptable, is it? Also, if I'm going to have
to give up as much memory as Eclipse demands, I'd want neat features
like interactive extensibility, online documentation, etc. But Emacs
already gives me all that and uses less memory than Eclipse.
>
>> Of course, Eclipse eases writing Java considerably, but I am
>> far from calling it "Killer App".
>>
>
> In the area of IDE it is Killer App.
> It is best tool for doing refactoring in Java.
> - How do you rename a class/method/variable and have every references
> to it also renamed?
> think this:
> (let ((foo 'foo))
> (format t "~A~%" foo)
> (let ((foo 'bar))
> (format t "foo ~A~%" foo)))
> and rename only the inner variable foo to bar without effecting the
> string, symbol or outer foo in Emacs with only a few key strokes.
Is this important to you? It is well within the capabilities of
Elisp.
As for renaming classes: hopefully, you're following good Lisp style
and using constructor functions instead of raw MAKE-INSTANCE calls.
(defun make-foo (name address ...)
(make-instance 'foo :name name :address ...))
becomes
(defun make-foo (name address ...)
(make-instance 'bar :name name :address ...))
> - How do you move method of a class up to its super class in emacs?
(defmethod foo ((a subclass))
...)
becomes
(defmethod foo ((a superclass))
...)
> - Keep history of your source code every time you save a buffer.
Emacs has built-in support for versioned backups. There are also
version control systems.
> - Error is highlighted as you type, no need to wait for separate
> compilation phase to see warning or compile error.
To me, this isn't useful unless the function is fully written, in
which case I get highlighted errors when I press C-c C-c.
>
> Compare to Eclipse, SLIME is way inferior. symbol completion is basic
> in any IDE.
>
>> > Having avoided Java for ... well, since its birth, I have to say that
>> > I'm having fun making rather complex things happen on the screen in
>> > pretty much no time at all! (And, BTW, my friends and family can
>> > download my code using WebStart and It Just Works!)
>>
>> Deploying Java applications sucks, if you are not on Windows or some
>> well-known Linux distribution. If Java was so great for "making complex
>> things happen" on every system a JDK runs on, why are there so few
>> projects using it? The number of Java projects in the FreeBSD ports tree
>> seems not to be orders of magnitude larger than the number of Lisp-based
>> ports despite the hype.
>>
>
> Checking from my Debian, both Lisp and Java packages available are
> mostly development tool. Java seems to have twice more packages than
> lisp.
>
> Instead of showing the number of development library, I will instead
> show applications that end-users uses -- as it is actually what counts
> for how many project people use it.
>
> Go to see SwingSighting, just issue 22 and 21 is enough, If you have
> JRE installed, you can even click webstart button to run an application
> in a sandbox:
>
> http://java.sun.com/products/jfc/tsc/sightings/S22.html
>
> Graphic/Sound Editor, 3D Game, MindMap, DB Frontend, PIM, Report
> Generator, SpreadSheet, CVS Client, XML Editor, Data Visualization, Web
> site builder, Blog tool, Desktop Publishing, .
>
> And be honest, have you seen all that applications in Common Lisp? Does
> it fills 22 pages?
>
>
> P.S.
> It's not that I hate Lisp, I just don't like to bend reality.
No, it's just that you don't seem to have used Emacs (and/or Lisp)
enough to know what you're talking about.
>
>>
>> Regards,
>> --
>> Julian Stecklina
>>
>> Being really good at C++ is like being really good at using rocks to
>> sharpen sticks. - Thant Tessman
>
--
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!
On 4648 September 1993, Bill Atkins wrote:
> "Pisin Bootvong" <··········@gmail.com> writes:
[...]
> Well, that's not really acceptable, is it? Also, if I'm going to have
> to give up as much memory as Eclipse demands, I'd want neat features
> like interactive extensibility, online documentation, etc. But Emacs
> already gives me all that and uses less memory than Eclipse.
Being an Emacs user for more than a decade, I think you're
nethertheless comparing apples and oranges, though you're certainly
right that Eclipse is a memory hog [1]. There are tons of features in
Eclipse that are currently not present in any of the Emacs modes.
>> In the area of IDE it is Killer App.
>> It is best tool for doing refactoring in Java.
>> - How do you rename a class/method/variable and have every references
>> to it also renamed?
>> think this:
>> (let ((foo 'foo))
>> (format t "~A~%" foo)
>> (let ((foo 'bar))
>> (format t "foo ~A~%" foo)))
>> and rename only the inner variable foo to bar without effecting the
>> string, symbol or outer foo in Emacs with only a few key strokes.
> Is this important to you? It is well within the capabilities of
> Elisp.
I'm sure the Slime or Ilisp team is waiting for your patches as this
would be a very handy tool. Currently, there is nothing like that in
either mode. And it would be a very handsome addition. I agree that it
is likely to be possible to come up with something similar if you're
using slime, as slime already knows a lot about symbols etc.
> As for renaming classes: hopefully, you're following good Lisp style
> and using constructor functions instead of raw MAKE-INSTANCE calls.
That's funny. I think yesterday I saw a posting here on cll that
claimed otherwise.
>> - How do you move method of a class up to its super class in emacs?
> (defmethod foo ((a subclass)) ...
> becomes
> (defmethod foo ((a superclass)) ...
Come on. The question was how to have Emacs handle that modification
without editing the source. Actually, I think that this might be
possible to achieve starting from OO-browser (which is rather dead,
btw. I'm not sure whether ecb is intended as a replacement and if so
whether it supports CLOS (I think it doesn't)).
>> It's not that I hate Lisp, I just don't like to bend reality.
> No, it's just that you don't seem to have used Emacs (and/or Lisp)
> enough to know what you're talking about.
Your answers show that you should keep your stones in your pockets.
Holger
Footnotes:
[1] Perhaps, Eclipse is becoming the new Emacs wrt. that old joke
about 8 megs and constantly swapping? It's quite easy to have Eclipse
consume 800 megs, after all. But what would that leave for
Emacs-as-we-know-it then? Perhaps some native speaker can tell me the
real meaning of the acronym Eclipse ...
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"I don't do drugs or windows."
"You need the one to do the other :-)"
-- Steve Baur and Adrian Aichner on xemacs-beta
Holger Schauer <··············@gmx.de> writes:
> On 4648 September 1993, Bill Atkins wrote:
>> "Pisin Bootvong" <··········@gmail.com> writes:
> [...]
>> Well, that's not really acceptable, is it? Also, if I'm going to have
>> to give up as much memory as Eclipse demands, I'd want neat features
>> like interactive extensibility, online documentation, etc. But Emacs
>> already gives me all that and uses less memory than Eclipse.
>
> Being an Emacs user for more than a decade, I think you're
> nethertheless comparing apples and oranges, though you're certainly
> right that Eclipse is a memory hog [1]. There are tons of features in
> Eclipse that are currently not present in any of the Emacs modes.
>
>>> In the area of IDE it is Killer App.
>>> It is best tool for doing refactoring in Java.
>>> - How do you rename a class/method/variable and have every references
>>> to it also renamed?
>>> think this:
>>> (let ((foo 'foo))
>>> (format t "~A~%" foo)
>>> (let ((foo 'bar))
>>> (format t "foo ~A~%" foo)))
>>> and rename only the inner variable foo to bar without effecting the
>>> string, symbol or outer foo in Emacs with only a few key strokes.
>> Is this important to you? It is well within the capabilities of
>> Elisp.
>
> I'm sure the Slime or Ilisp team is waiting for your patches as this
> would be a very handy tool. Currently, there is nothing like that in
> either mode. And it would be a very handsome addition. I agree that it
> is likely to be possible to come up with something similar if you're
> using slime, as slime already knows a lot about symbols etc.
What makes this difficult is that there are so many ways to introduce
local variables in Lisp, since lots of macros expand into LET's. So,
on second thought, you're right; it would be far from straightforward
to do this in Elisp.
>> As for renaming classes: hopefully, you're following good Lisp style
>> and using constructor functions instead of raw MAKE-INSTANCE calls.
>
> That's funny. I think yesterday I saw a posting here on cll that
> claimed otherwise.
This is discussed in Keene's "Object-oriented Programming with CLOS,"
the canonical introduction to CLOS. It also Just Makes Sense.
Constructors can take required arguments as positional arguments and
insulate the caller from the knowledge that they're dealing with an
instance of class FOO.
>
>>> - How do you move method of a class up to its super class in emacs?
>
>> (defmethod foo ((a subclass)) ...
>> becomes
>> (defmethod foo ((a superclass)) ...
>
> Come on. The question was how to have Emacs handle that modification
> without editing the source. Actually, I think that this might be
> possible to achieve starting from OO-browser (which is rather dead,
> btw. I'm not sure whether ecb is intended as a replacement and if so
> whether it supports CLOS (I think it doesn't)).
I'm sorry, but I don't see how that's useful. My point was that
changing a method's class in Lisp is trivial compared to performing
the same operation in Java. If I have to look up the method with
M-. and then change the name in the source, that's fine. What time
does Eclipse save me by freeing me from "editing the source"?
>
>>> It's not that I hate Lisp, I just don't like to bend reality.
>
>> No, it's just that you don't seem to have used Emacs (and/or Lisp)
>> enough to know what you're talking about.
>
> Your answers show that you should keep your stones in your pockets.
They do indeed. :) Knee-jerk replies are always regretted afterwards.
--
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!
Bill Atkins <············@rpi.edu> writes:
> Holger Schauer <··············@gmx.de> writes:
>
>> That's funny. I think yesterday I saw a posting here on cll that
>> claimed otherwise.
>
> This is discussed in Keene's "Object-oriented Programming with CLOS,"
> the canonical introduction to CLOS. It also Just Makes Sense.
> Constructors can take required arguments as positional arguments and
> insulate the caller from the knowledge that they're dealing with an
> instance of class FOO.
On the other hand, the use of constructor functions typically
prohibits free subclassing of application classes: if I want to extend
your foo-object with my bar-mixin and create a subclass, I can no
longer use your constructor function. (Alternatively, I would have to
define a stealth mixin to your foo-object, but then all foo-objects,
not just the ones I'm interested in, acquire that stealth mixin.) I
don't think that Keene's is the final word on this subject.
Christophe
Bill Atkins <············@rpi.edu> writes:
> Holger Schauer <··············@gmx.de> writes:
>
>> On 4648 September 1993, Bill Atkins wrote:
>>> As for renaming classes: hopefully, you're following good Lisp
>>> style and using constructor functions instead of raw MAKE-INSTANCE
>>> calls.
>>
>> That's funny. I think yesterday I saw a posting here on cll that
>> claimed otherwise.
>
> This is discussed in Keene's "Object-oriented Programming with
> CLOS," the canonical introduction to CLOS. It also Just Makes Sense.
> Constructors can take required arguments as positional arguments and
> insulate the caller from the knowledge that they're dealing with an
> instance of class FOO.
Nevertheless there are a number of Lispers, myself being one, who
think that Keene is wrong to encourage always writing constructors.
There are times when you want to hide the class machinery but
reflexively writing a MAKE-FOO constructor for every class FOO is
probably not a good idea. It's *handy* to use a factory method to
create objects rather than a hard-wired constructor and MAKE-INSTANCE
is the (almost) universal factory method. Plus you probably want to
put any customizations, beyond filling in :initargs, in specilized
methods on INITIALIZE-INSTANCE, SHARED-INITIALIZE, et al. which are
all part of of the MAKE-INSTANCE protocol. If you put logic necessary
to properly construct an object into a constructor function you open
the possibility for objects to get improperly constructed if you ever
use MAKE-INSTANCE directly.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> Bill Atkins <············@rpi.edu> writes:
>
>> Holger Schauer <··············@gmx.de> writes:
>>
>>> On 4648 September 1993, Bill Atkins wrote:
>
>>>> As for renaming classes: hopefully, you're following good Lisp
>>>> style and using constructor functions instead of raw MAKE-INSTANCE
>>>> calls.
>>>
>>> That's funny. I think yesterday I saw a posting here on cll that
>>> claimed otherwise.
>>
>> This is discussed in Keene's "Object-oriented Programming with
>> CLOS," the canonical introduction to CLOS. It also Just Makes Sense.
>> Constructors can take required arguments as positional arguments and
>> insulate the caller from the knowledge that they're dealing with an
>> instance of class FOO.
>
> Nevertheless there are a number of Lispers, myself being one, who
> think that Keene is wrong to encourage always writing constructors.
> There are times when you want to hide the class machinery but
> reflexively writing a MAKE-FOO constructor for every class FOO is
> probably not a good idea. It's *handy* to use a factory method to
> create objects rather than a hard-wired constructor and MAKE-INSTANCE
> is the (almost) universal factory method. Plus you probably want to
> put any customizations, beyond filling in :initargs, in specilized
> methods on INITIALIZE-INSTANCE, SHARED-INITIALIZE, et al. which are
> all part of of the MAKE-INSTANCE protocol. If you put logic necessary
> to properly construct an object into a constructor function you open
> the possibility for objects to get improperly constructed if you ever
> use MAKE-INSTANCE directly.
>
> -Peter
I basically agree with this. I do put any initialization code in
:default-initargs, :initform's or the *-INITIALIZE-* methods. As far
as I'm concerned, constructors should be no more than a thin, thin
wrapper around a MAKE-INSTANCE call. The generalness of MAKE-INSTANCE
can become unwieldy [(make-instance 'person :name name :address
address :phone phone) vs (make-person name address phone)] and it is
sometimes not clear what arguments are required and which can be left
out. So I think constructors have their uses.
IMO, a constructor should be little more than:
(defun make-foo (a b c &rest keys)
(apply #'make-instance 'foo :a :b b :c c keys)
with perhaps some extra code to be more flexible in the kinds of
parameters accepted.
Where a constructor isn't appropriate, the MAKE-INSTANCE interface is
always there to fall back on, and a new constructor could be written
to abstract other ways of initializing the object.
--
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!
Bill Atkins wrote:
> Holger Schauer <··············@gmx.de> writes:
>
>> On 4648 September 1993, Bill Atkins wrote:
>>> "Pisin Bootvong" <··········@gmail.com> writes:
>>>
>>>> In the area of IDE [Eclipse] is Killer App.
>>>> It is best tool for doing refactoring in Java.
>>>> - How do you rename a class/method/variable and have every references
>>>> to it also renamed?
>>>> think this:
>>>> (let ((foo 'foo))
>>>> (format t "~A~%" foo)
>>>> (let ((foo 'bar))
>>>> (format t "foo ~A~%" foo)))
>>>> and rename only the inner variable foo to bar without effecting the
>>>> string, symbol or outer foo in Emacs with only a few key strokes.
>>> Is this important to you? It is well within the capabilities of
>>> Elisp.
>> I'm sure the Slime or Ilisp team is waiting for your patches as this
>> would be a very handy tool. Currently, there is nothing like that in
>> either mode. And it would be a very handsome addition. I agree that it
>> is likely to be possible to come up with something similar if you're
>> using slime, as slime already knows a lot about symbols etc.
>
> What makes this difficult is that there are so many ways to introduce
> local variables in Lisp, since lots of macros expand into LET's. So,
> on second thought, you're right; it would be far from straightforward
> to do this in Elisp.
The comparison starts to become unfair. Who thinks that Java is
especially suited for refactoring tools is misguided. Java supports
reflective field accesses and reflective method calls. In other words,
the name/signature in a method call might be determined as late as
runtime - if you are refactoring your program, there is always the
danger that reflective calls break afterwards, and there is no tool that
is going to warn you about this. Maybe it's not so common to use
reflection in Java, but I wouldn't count on this. Consider determining a
method call based on the contents of configuration files.
This is not to say that Eclipse's support for refactoring is useless. It
is apparently indeed a useful tool. But it shouldn't be overrated as well.
In Lisp I also use a refactoring tool. It's called "clicking on a
parenthesis, which selects a form, and then cut and paste in the right
position." This requires more manual intervention than the typical
refactoring tool, like in Smalltalk or Java, but nonetheless works quite
well in my experience. (Yes, it could be better.)
>>> As for renaming classes: hopefully, you're following good Lisp style
>>> and using constructor functions instead of raw MAKE-INSTANCE calls.
>> That's funny. I think yesterday I saw a posting here on cll that
>> claimed otherwise.
>
> This is discussed in Keene's "Object-oriented Programming with CLOS,"
> the canonical introduction to CLOS. It also Just Makes Sense.
> Constructors can take required arguments as positional arguments and
> insulate the caller from the knowledge that they're dealing with an
> instance of class FOO.
There are pros and cons, so you will find both styles. In Common Lisp,
programming conventions are not as strictly and widely followed as in
other languages. This makes it also harder to develop tools which in
other languages can typically make a lot more assumptions about the
programming idiom and style. The upside in Lisp is that you are not
forced to code in a style that might not be appropriate for the task at
hand.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Bill Atkins wrote:
> > Holger Schauer <··············@gmx.de> writes:
> >
> >> On 4648 September 1993, Bill Atkins wrote:
> >>> "Pisin Bootvong" <··········@gmail.com> writes:
> >>>
> >>>> In the area of IDE [Eclipse] is Killer App.
> >>>> It is best tool for doing refactoring in Java.
> >>>> - How do you rename a class/method/variable and have every references
> >>>> to it also renamed?
> >>>> think this:
> >>>> (let ((foo 'foo))
> >>>> (format t "~A~%" foo)
> >>>> (let ((foo 'bar))
> >>>> (format t "foo ~A~%" foo)))
> >>>> and rename only the inner variable foo to bar without effecting the
> >>>> string, symbol or outer foo in Emacs with only a few key strokes.
> >>> Is this important to you? It is well within the capabilities of
> >>> Elisp.
> >> I'm sure the Slime or Ilisp team is waiting for your patches as this
> >> would be a very handy tool. Currently, there is nothing like that in
> >> either mode. And it would be a very handsome addition. I agree that it
> >> is likely to be possible to come up with something similar if you're
> >> using slime, as slime already knows a lot about symbols etc.
> >
> > What makes this difficult is that there are so many ways to introduce
> > local variables in Lisp, since lots of macros expand into LET's. So,
> > on second thought, you're right; it would be far from straightforward
> > to do this in Elisp.
>
> The comparison starts to become unfair. Who thinks that Java is
> especially suited for refactoring tools is misguided. Java supports
> reflective field accesses and reflective method calls. In other words,
> the name/signature in a method call might be determined as late as
> runtime - if you are refactoring your program, there is always the
> danger that reflective calls break afterwards, and there is no tool that
> is going to warn you about this. Maybe it's not so common to use
> reflection in Java, but I wouldn't count on this. Consider determining a
> method call based on the contents of configuration files.
>
I'm reasonable enough not to expect a refactoring tool that support
runtime reflection. :-)
Reflection is consider in java world the same as EVAL, try not to use
it.
There is no way you could track method name that is read from file, in
ANY language.
But symbol from standard construct: let, defclass, defun, defmethod,
function calls in form (foo a b) and may be function in form #'foo. A
refactoring tool for a language should be able to support this.
> This is not to say that Eclipse's support for refactoring is useless. It
> is apparently indeed a useful tool. But it shouldn't be overrated as well.
>
> In Lisp I also use a refactoring tool. It's called "clicking on a
> parenthesis, which selects a form, and then cut and paste in the right
> position." This requires more manual intervention than the typical
> refactoring tool, like in Smalltalk or Java, but nonetheless works quite
> well in my experience. (Yes, it could be better.)
>
> >>> As for renaming classes: hopefully, you're following good Lisp style
> >>> and using constructor functions instead of raw MAKE-INSTANCE calls.
> >> That's funny. I think yesterday I saw a posting here on cll that
> >> claimed otherwise.
> >
> > This is discussed in Keene's "Object-oriented Programming with CLOS,"
> > the canonical introduction to CLOS. It also Just Makes Sense.
> > Constructors can take required arguments as positional arguments and
> > insulate the caller from the knowledge that they're dealing with an
> > instance of class FOO.
>
> There are pros and cons, so you will find both styles. In Common Lisp,
> programming conventions are not as strictly and widely followed as in
> other languages. This makes it also harder to develop tools which in
> other languages can typically make a lot more assumptions about the
> programming idiom and style. The upside in Lisp is that you are not
> forced to code in a style that might not be appropriate for the task at
> hand.
>
>
>
> Pascal
>
> --
> 3rd European Lisp Workshop
> July 3 - Nantes, France - co-located with ECOOP 2006
> http://lisp-ecoop06.bknr.net/
Am 24.05.2006 23:35 Uhr schrieb "Pascal Costanza" unter <··@p-cos.net> in
···············@individual.net:
> In Lisp I also use a refactoring tool. It's called "clicking on a
> parenthesis, which selects a form, and then cut and paste in the right
> position." This requires more manual intervention than the typical
> refactoring tool, like in Smalltalk or Java, but nonetheless works quite
> well in my experience. (Yes, it could be better.)
Look for 'mouse copy' ;-) . LispWorks has it, MCL has it, Genera has it.
http://www.lispworks.com/documentation/lw445/EDUG-W/html/eduser-w-89.htm
Look for shift-right-button .
I've put that LispWorks version on mouse-middle. It does the following:
place your text cursor somewhere useful. Then click on some other
Lisp form (symbol, number, parentheses, ...) mouse-middle. The Lisp form
will be inserted at the text cursor position. Actually some functionality is
more complicated (for example space can be added automatically , ...).
Rainer Joswig writes:
> Am 24.05.2006 23:35 Uhr schrieb "Pascal Costanza" unter <··@p-cos.net> in
> ···············@individual.net:
>> In Lisp I also use a refactoring tool. It's called "clicking on a
>> parenthesis, which selects a form, and then cut and paste in the right
>> position." This requires more manual intervention than the typical
>> refactoring tool, like in Smalltalk or Java, but nonetheless works quite
>> well in my experience. (Yes, it could be better.)
> Look for 'mouse copy' ;-) . LispWorks has it, MCL has it, Genera has it.
[ also posted to gnu.emacs.sources ]
(defun mouse-insert-sexp-at-point (start-event)
"Insert the sexp under the mouse cursor at point.
This command must be bound to a mouse event."
(interactive "*e")
(let ((posn (event-start start-event)))
(let ((sexp-at-mouse-pos
(with-selected-window (posn-window posn)
(save-excursion
(goto-char (posn-point posn))
(thing-at-point 'sexp)))))
(if sexp-at-mouse-pos
(insert sexp-at-mouse-pos)
(error "Mouse not at a sexp")))))
;; (global-set-key (vector 'S-mouse-3) 'mouse-insert-sexp-at-point)
--
Em�lio C. Lopes
Munich, Germany
Bill Atkins wrote:
>
> This is discussed in Keene's "Object-oriented Programming with CLOS,"
> the canonical introduction to CLOS. It also Just Makes Sense.
> Constructors can take required arguments as positional arguments and
> insulate the caller from the knowledge that they're dealing with an
> instance of class FOO.
I have to disagree with Keene here.
One of the brilliant things about CLOS is that MAKE-INSTANCE is a
generic function.
It isn't *required* to return an instance of the specified class. You
can, for example,
define a method on MAKE-INSTANCE specialized for a class that cannot
even be
instantiated and have it return an appropriate concrete class (a proxy
or derived class).
There is no need for `factories'.
If you write your own constructor, you have the problem that people may
deliberately
or unintentionally do an end-run around it by calling MAKE-INSTANCE
directly. On the
other hand, if you add the right smarts to your methods, you can get
MAKE-INSTANCE
to do whatever your constructor does and avoid the problem altogether.
Joe Marshall wrote:
> Bill Atkins wrote:
>
>>This is discussed in Keene's "Object-oriented Programming with CLOS,"
>>the canonical introduction to CLOS. It also Just Makes Sense.
>>Constructors can take required arguments as positional arguments and
>>insulate the caller from the knowledge that they're dealing with an
>>instance of class FOO.
>
>
> I have to disagree with Keene here.
>
> One of the brilliant things about CLOS is that MAKE-INSTANCE is a
> generic function.
> It isn't *required* to return an instance of the specified class. You
> can, for example,
> define a method on MAKE-INSTANCE specialized for a class that cannot
> even be
> instantiated and have it return an appropriate concrete class (a proxy
> or derived class).
> There is no need for `factories'.
>
> If you write your own constructor, you have the problem that people may
> deliberately
> or unintentionally do an end-run around it by calling MAKE-INSTANCE
> directly. On the
> other hand, if you add the right smarts to your methods, you can get
> MAKE-INSTANCE
> to do whatever your constructor does and avoid the problem altogether.
>
Joe, I think it's time we told them The Right Answer: if you want terser
syntax, create a macro that expands directly into make-instance. See
Celtk or Cello for examples.
kzo
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Joe Marshall wrote:
--->8--- snip --->8---
>
> One of the brilliant things about CLOS is that MAKE-INSTANCE is a
> generic function.
> It isn't *required* to return an instance of the specified class. You
> can, for example,
> define a method on MAKE-INSTANCE specialized for a class that cannot
> even be
> instantiated and have it return an appropriate concrete class (a proxy
> or derived class).
> There is no need for `factories'.
>
> If you write your own constructor, you have the problem that people may
> deliberately
> or unintentionally do an end-run around it by calling MAKE-INSTANCE
> directly. On the
> other hand, if you add the right smarts to your methods, you can get
> MAKE-INSTANCE
> to do whatever your constructor does and avoid the problem altogether.
I've attempted to do this in the past, but with no success. Can anybody
provide
an example of specializing MAKE-INSTANCE?
My own naive attempts look similar to the following:
(defclass abstract-a () ())
(defclass concrete-a (a) ())
(defmethod make-instance ((class abstract-a) &rest initargs &key
&allow-other-keys)
(format t "Here we are in abstract-a make-instance...~%")
;; return a CONCRETE-A rather than an ABSTRACT-A...
(make-instance 'concrete-a))
(make-instance 'abstract-a)
=> #<ABSTRACT-A #x....>
(class-of (make-instance 'abstract-a))
=> #<STANDARD-CLASS ABSTRACT-A>
(find-class 'abstract-a)
=> #<STANDARD-CLASS ABSTRACT-A>
(class-of (find-class 'abstract-a))
=> #<STANDARD-CLASS STANDARD-CLASS>
(make-instance (make-instance 'abstract-a))
=> Here we are in abstract-a make-instance...
=> #<CONCRETE-A #x....>
... which leads me to think, that if (make-instance (symbol ...)) is
equivalent
to (make-instance (find-class symbol)) that my specialized
MAKE-INSTANCE
*should* be specializing standard-class rather than ABSTRACT-A.
Using EQL specializers works:
(defmethod make-instance ((symb (eql 'abstract-a)) &rest i &key
&allow-other-keys)
(make-instance 'concrete-a))
(make-instance 'abstract-a)
=> #<CONCRETE-A #x....>
... but is insufficient for my needs since eql specializers don't form
any kind of
superclass / subclass hierarchy (i.e. I'd need an eql specialized
MAKE-INSTANCE
for each abstract class in the class hierarchy, which I'd rather
avoid...).
My guess: I'm missing something fundamental here. I'd love some
pointers :-)
-Duncan
Duncan Rose wrote:
>
> I've attempted to do this in the past, but with no success. Can anybody
> provide an example of specializing MAKE-INSTANCE?
There may be some `technically illegal' code here, but here is an
example:
(defmethod make-instance ((class (eql (find-class
'persistent-hash-table))) &rest initargs
&key
(size *default-persistent-hash-table-size*)
(test 'eq)
(bucket-vector (make-instance
'persistent-vector :size (or size
*default-persistent-hash-table-size*)))
&allow-other-keys)
(apply #'call-next-method class
:bucket-vector bucket-vector
:test test
initargs))
(defmethod make-instance :around ((class (eql (find-class
'integer-range-mapper)))
&rest initargs &key repository-mapper
&allow-other-keys)
(apply #'call-next-method class
:current-entry (make-instance 'integer-range-mapper-entry
:local-start 0
:remote-start 0
:repository-mapper
repository-mapper)
initargs))
Try
(defmethod make-instance((class-name (eql 'abstract-a))
&rest initargs &key &allow-other-keys)
...)
- y ou want to specialise on a specific symbol representing the class
name.
>>>>> "Duncan" == Duncan Rose <···········@jdwilliams.co.uk> writes:
Duncan> Joe Marshall wrote:
---> 8--- snip --->8---
>> One of the brilliant things about CLOS is that MAKE-INSTANCE
>> is a generic function. It isn't *required* to return an
>> instance of the specified class. You can, for example, define
>> a method on MAKE-INSTANCE specialized for a class that cannot
>> even be instantiated and have it return an appropriate concrete
>> class (a proxy or derived class). There is no need for
>> `factories'.
>>
>> If you write your own constructor, you have the problem that
>> people may deliberately or unintentionally do an end-run around
>> it by calling MAKE-INSTANCE directly. On the other hand, if
>> you add the right smarts to your methods, you can get
>> MAKE-INSTANCE to do whatever your constructor does and avoid
>> the problem altogether.
Duncan> I've attempted to do this in the past, but with no
Duncan> success. Can anybody provide an example of specializing
Duncan> MAKE-INSTANCE?
Duncan> My own naive attempts look similar to the following:
Duncan> (defclass abstract-a () ()) (defclass concrete-a (a) ())
Duncan> (defmethod make-instance ((class abstract-a) &rest
Duncan> initargs &key &allow-other-keys) (format t "Here we are in
Duncan> abstract-a make-instance...~%") ;; return a CONCRETE-A
Duncan> rather than an ABSTRACT-A... (make-instance 'concrete-a))
Duncan> (make-instance 'abstract-a) => #<ABSTRACT-A #x....>
Duncan> (class-of (make-instance 'abstract-a)) => #<STANDARD-CLASS
Duncan> ABSTRACT-A>
Duncan> (find-class 'abstract-a) => #<STANDARD-CLASS ABSTRACT-A>
Duncan> (class-of (find-class 'abstract-a)) => #<STANDARD-CLASS
Duncan> STANDARD-CLASS>
Duncan> (make-instance (make-instance 'abstract-a)) => Here we are
Duncan> in abstract-a make-instance... => #<CONCRETE-A #x....>
Duncan> ... which leads me to think, that if (make-instance
Duncan> (symbol ...)) is equivalent to (make-instance (find-class
Duncan> symbol)) that my specialized MAKE-INSTANCE *should* be
Duncan> specializing standard-class rather than ABSTRACT-A.
Duncan> Using EQL specializers works:
Duncan> (defmethod make-instance ((symb (eql 'abstract-a)) &rest i
Duncan> &key &allow-other-keys) (make-instance 'concrete-a))
Duncan> (make-instance 'abstract-a) => #<CONCRETE-A #x....>
Duncan> ... but is insufficient for my needs since eql
Duncan> specializers don't form any kind of superclass / subclass
Duncan> hierarchy (i.e. I'd need an eql specialized MAKE-INSTANCE
Duncan> for each abstract class in the class hierarchy, which I'd
Duncan> rather avoid...).
Duncan> My guess: I'm missing something fundamental here. I'd love
Duncan> some pointers :-)
Duncan> -Duncan
--
Dr. John A.R. Williams
Electronic Engineering, Aston University, Birmingham B4 7ET
Tel: 0121 359 3621 x 4989 Fax: 0121 359 0156
www: http://www.ee.aston.ac.uk/staff/willijar
PGP key: 6606795A185C384C
Dr. John A.R. Williams wrote:
> Try
>
> (defmethod make-instance((class-name (eql 'abstract-a))
> &rest initargs &key &allow-other-keys)
> ...)
>
> - y ou want to specialise on a specific symbol representing the class
> name.
Oh no you don't!
See:
http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
(point 19)
What it means is that defining (EQL SOME-SYMBOL) methods on
MAKE-INSTANCE is undefined.
The question is: why do you need this? Depending on your answer the
right thing is to either specialize SHARED-INITILIZE &co instead, or
possibly to define your own metaclass -- in which case you can then
specialize the MAKE-INSTANCE on that.
Sorry for being rather terse. Must run.
Cheers,
-- Nikodemus Siivola
Nikodemus Siivola wrote:
> Dr. John A.R. Williams wrote:
> > Try
> >
> > (defmethod make-instance((class-name (eql 'abstract-a))
> > &rest initargs &key &allow-other-keys)
> > ...)
> >
> > - y ou want to specialise on a specific symbol representing the class
> > name.
>
> Oh no you don't!
>
> See:
>
> http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
>
> (point 19)
>
> What it means is that defining (EQL SOME-SYMBOL) methods on
> MAKE-INSTANCE is undefined.
>
> The question is: why do you need this? Depending on your answer the
> right thing is to either specialize SHARED-INITILIZE &co instead, or
> possibly to define your own metaclass -- in which case you can then
> specialize the MAKE-INSTANCE on that.
>
I'm currently attempting to convert DUIM from Dylan to Lisp in my
copious (!)
amounts of spare time. It's a common idiom in DUIM to present a set of
abstract classes to the user, but to instantiate some concrete
subclasses of
these when the user attempts to make use of the exported / documented
type.
(Just in case you are unaware, DUIM is a (slightly more up-to-date, and
also
slightly less comprehensive) windowing substrate along the lines of
CLIM's
Silica (for pedants -- this doesn't nearly describe it well enough, but
it should
be sufficient to put this post into context).)
For example, DUIM documents that button widgets in the GUI can be
constructed using 'make <push-button>' (in the Dylan). This method (and
every other 'make' method on a gadget type) queries some underlying
code
('class-for-make-pane' in this instance) regarding what the actual
concrete
implementation class is for a 'push button' and constructs one of
those. In
this case, we might have:-
-> The user of the API wants a button -- so they write 'make
<push-button>'
-> to get one.
-> <push-button> is an abstract class -- the actual type of button will
depend
-> mainly on the back end that provides the native windowing interface
that
-> DUIM talks to.
-> DUIM constructs an appropriate concrete class (for arguments sake,
let's
-> say that this could be any one of <WINDOWS-BUTTON>, <CAPI-BUTTON>,
-> <COCOA-BUTTON>, <TK-BUTTON> .....)
-> The user makes use of the methods that specialize on <push-button>
(that
-> provide the 'protocol' for buttons of this type) to do -- well,
whatever.
The fact that the user has an instance of a different class to the one
that they
were perhaps expecting is irrelevent (unless they're doing hacking on
the library
internals, in which case they'd better understand how all this fits
together).
Perhaps this is an abstraction that is easier to achieve in Dylan
(type-based rather
than class-based specialization, or such is my understanding) than in
Lisp, but it
seems a rather elegant approach to the problem that DUIM attempts to
address.
I suspect that the 'right' solution is to define my own metaclasses
(metaclasii?),
but it looks to me like for this approach to work I'll need to define a
distinct
metaclass for each abstract class that is defined.
Now I suppose I should do what I should have done before penning this
response,
and go look up SHARED-INITIALIZE in the HyperSpec :-)
-Duncan
ps. I noticed a typo in my original post (which got snipped somewhere
along the
line):
(defclass concrete-a (a) ())
should of course read
(defclass concrete-a (abstract-a) ())
D'oh!
-D
> Sorry for being rather terse. Must run.
>
> Cheers,
>
> -- Nikodemus Siivola
Duncan Rose schrieb:
> I'm currently attempting to convert DUIM from Dylan to Lisp in my
> copious (!)
> amounts of spare time. It's a common idiom in DUIM to present a set of
> abstract classes to the user, but to instantiate some concrete
> subclasses of
> these when the user attempts to make use of the exported / documented
> type.
Like abstract gadgets in CLIM...
http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/30-2.html
"Duncan Rose" <···········@jdwilliams.co.uk> writes:
>> What it means is that defining (EQL SOME-SYMBOL) methods on
>> MAKE-INSTANCE is undefined.
>>
>> The question is: why do you need this? Depending on your answer the
>> right thing is to either specialize SHARED-INITILIZE &co instead, or
>> possibly to define your own metaclass -- in which case you can then
>> specialize the MAKE-INSTANCE on that.
>>
>
> I'm currently attempting to convert DUIM from Dylan to Lisp in my
> copious (!) amounts of spare time. It's a common idiom in DUIM to
> present a set of abstract classes to the user, but to instantiate
> some concrete subclasses of these when the user attempts to make use
> of the exported / documented type.
You don't have to use make-instance either.
(defgeneric make-object (preferred-class &rest args &key &allow-other-keys))
and then just use MAKE-OBJECT
MAKE-INSTANCE shall make an instance of the specified class.
MAKE-OBJECT shall make an object. There's a preferred class, but
that's just a hint.
(And you can specialize MAKE-OBJECT since it's your own little generic function).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Pascal Bourguignon wrote:
> "Duncan Rose" <···········@jdwilliams.co.uk> writes:
> >> What it means is that defining (EQL SOME-SYMBOL) methods on
> >> MAKE-INSTANCE is undefined.
> >>
> >> The question is: why do you need this? Depending on your answer the
> >> right thing is to either specialize SHARED-INITILIZE &co instead, or
> >> possibly to define your own metaclass -- in which case you can then
> >> specialize the MAKE-INSTANCE on that.
> >>
> >
> > I'm currently attempting to convert DUIM from Dylan to Lisp in my
> > copious (!) amounts of spare time. It's a common idiom in DUIM to
> > present a set of abstract classes to the user, but to instantiate
> > some concrete subclasses of these when the user attempts to make use
> > of the exported / documented type.
>
> You don't have to use make-instance either.
>
> (defgeneric make-object (preferred-class &rest args &key &allow-other-keys))
>
> and then just use MAKE-OBJECT
>
> MAKE-INSTANCE shall make an instance of the specified class.
>
> MAKE-OBJECT shall make an object. There's a preferred class, but
> that's just a hint.
>
> (And you can specialize MAKE-OBJECT since it's your own little generic function).
>
This is the solution I'm currently working with, but I consider it to
be a leaky
abstraction for serveral reasons, all of which pretty much were
enumerated
by Joe Marshall earlier in the thread (and have since been snipped :-).
To repeat one of them:
JM> If you write your own constructor, you have the problem that people
JM> may deliberately or unintentionally do an end-run around it by
calling
JM> MAKE-INSTANCE directly. On the other hand, if you add the right
JM> smarts to your methods, you can get MAKE-INSTANCE to do
JM> whatever your constructor does and avoid the problem altogether.
The fact that MAKE-INSTANCE can be specialized to provide some kind of
factory-like behaviour is something that I've seen mentioned a couple
of times
in the past and I've never been able to find any code that provided an
example.
My guess is that this (specializing MAKE-INSTANCE) isn't actually
something
that's as easy to do as perhaps I might like -- particularly for the
kind of usage
(as a factory) that initiated this subthread -- which is a shame I
think. I was
hoping some prodding might lead to some code being posted ;-)
Another option of course, is just to use constructor factory-type
methods and
get rid of MAKE-OBJECT (which in my code is actually called MAKE for
symmetry with the original Dylan code) altogether and fall back on a
'MAKE-PUSH-BUTTON' method instead. Of course, I'll need to define a
'MAKE-XXX' method for each abstract class that's documented.
This all just seems to back Keene and Bill up in the overall thread....
On the other hand, since I consider it to be a better abstraction than
the
alternatives, I'd still like at least some idea of how it could be
done; so far
Nikodemus' suggestion of creating my own metaclasses looks to be the
only one with any legs. This sounds like more work than I'd like, so
I'll take
some time deciding whether doing this work is more important to me than
accepting what is, to my mind, an inferior abstraction.
That is if nobody posts anything a little more concrete in the
meantime,
of course.
-Duncan
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> Cats meow out of angst
> "Thumbs! If only we had thumbs!
> We could break so much!"
Duncan Rose wrote:
> Nikodemus Siivola wrote:
>> Dr. John A.R. Williams wrote:
>>> Try
>>>
>>> (defmethod make-instance((class-name (eql 'abstract-a))
>>> &rest initargs &key &allow-other-keys)
>>> ...)
>>>
>>> - y ou want to specialise on a specific symbol representing the class
>>> name.
>> Oh no you don't!
>>
>> See:
>>
>> http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
>>
>> (point 19)
>>
>> What it means is that defining (EQL SOME-SYMBOL) methods on
>> MAKE-INSTANCE is undefined.
>>
>> The question is: why do you need this? Depending on your answer the
>> right thing is to either specialize SHARED-INITILIZE &co instead, or
>> possibly to define your own metaclass -- in which case you can then
>> specialize the MAKE-INSTANCE on that.
>>
>
> I'm currently attempting to convert DUIM from Dylan to Lisp in my
> copious (!)
> amounts of spare time. It's a common idiom in DUIM to present a set of
> abstract classes to the user, but to instantiate some concrete
> subclasses of
> these when the user attempts to make use of the exported / documented
> type.
I can think of the following ways to do this:
- Define and use make-object as proposed by the other Pascal. If you
don't like the fact that people might accidentally call make-instance,
you could possibly shadow 'make-instance and replace it with your own
definition. This probably doesn't work too well, though.
- Use the CLOS MOP. Provide a subclass of standard-class and specialize
on that, roughly like this:
(defclass abstract-class (standard-class)
())
(defmethod make-instance ((class abstract-class) &rest initargs)
(apply #'call-next-method (determine-actual-class) initargs))
Then your abstract classes can/should be defined like this:
(defclass something-abstract (...)
(...)
(:metaclass abstract-class))
This only works if you have the CLOS MOP available.
- Change the class of an object after it has been created, roughly like
this:
; Note: The following is not a metaclass,
; but could rather be used as a mixin class.
(defclass abstract-class ()
())
(defmethod initialize-instance :after
((object abstract-class) &rest initargs)
(apply #'change-class object (determine-actual-class) initargs))
But note that especially the last one is just an idea, there are
probably some subtle issues to solve first.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Nikodemus Siivola wrote:
> Dr. John A.R. Williams wrote:
> > Try
> >
> > (defmethod make-instance((class-name (eql 'abstract-a))
> > &rest initargs &key &allow-other-keys)
> > ...)
> >
> > - y ou want to specialise on a specific symbol representing the class
> > name.
>
> Oh no you don't!
>
> See:
>
> http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
>
> (point 19)
>
> What it means is that defining (EQL SOME-SYMBOL) methods on
> MAKE-INSTANCE is undefined.
>
Why is it so? Could you please clarify?
How are these two method different:
make-instance (class standard-class) &rest initargs
and
initialize-instance (instance standard-object) &rest initargs
Isn't <standard-object> standardized class too?
If it is then why am I allowed to specialized on the latter but not the
former?
Also, the rule was not to define when all arguments are standardized
class. But isn't &rest argument considered part of the argument too? If
it is then &rest are not direct instance of standardized class, is it?
So shouldn't I be allowed to specialize make-instance?
Anyway, if it is not ok to redefine or eql-specialize (make-instance
'symbol) is it ok to intercept it?
The following solution use :around qualifier.
CL-USER> (defvar *replaced-class* (make-hash-table))
*REPLACED-CLASS*
CL-USER> (setf (gethash 'a *replaced-class*) 'concrete-a)
CONCREATE-A
CL-USER> (defclass a () ())
#<STANDARD-CLASS A>
CL-USER> (defclass concrete-a (a) ())
#<STANDARD-CLASS CONCRETE-A>
CL-USER> (defmethod make-instance :around ((class symbol) &rest
initarg)
(format t "making ~A~%" class)
(apply #'call-next-method (gethash class *replaced-class* class)
initarg))
#<STANDARD-METHOD MAKE-INSTANCE :AROUND (SYMBOL) {B5DD241}>
CL-USER> (make-instance 'standard-object)
making STANDARD-OBJECT
#<STANDARD-OBJECT {B5EEC81}>
CL-USER> (make-instance 'a)
making A
#<CONCRETE-A {A924A49}>
CL-USER>
Probably as simple as you may get. replace (gethash) with some complex
algorithm if you like.
The only question is, it this conforming code?
>
> Cheers,
>
> -- Nikodemus Siivola
Pisin Bootvong wrote:
> Nikodemus Siivola wrote:
>> Dr. John A.R. Williams wrote:
>>> Try
>>>
>>> (defmethod make-instance((class-name (eql 'abstract-a))
>>> &rest initargs &key &allow-other-keys)
>>> ...)
>>>
>>> - y ou want to specialise on a specific symbol representing the class
>>> name.
>> Oh no you don't!
>>
>> See:
>>
>> http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
>>
>> (point 19)
>>
>> What it means is that defining (EQL SOME-SYMBOL) methods on
>> MAKE-INSTANCE is undefined.
>>
>
> Why is it so? Could you please clarify?
>
> How are these two method different:
>
> make-instance (class standard-class) &rest initargs
> and
> initialize-instance (instance standard-object) &rest initargs
>
> Isn't <standard-object> standardized class too?
> If it is then why am I allowed to specialized on the latter but not the
> former?
There is no difference. You are not allowed to do this:
(defmethod make-instance :around
((class standard-class) ...)
...)
(defclass foo (...) (...))
(defmethod make-instance :around
((class (eql (find-class 'foo))) ...)
...)
(defmethod make-instance :around
((class (eql 'foo)) ...)
...)
Likewise, you are not allowed to do this:
(defmethod initialize-instance :around
((object standard-object) ...)
...)
(defparameter *foo* (make-instance 'standard-object))
(defmethod initialize-instance :around
((object (eql *foo*)) ...)
...)
Your are allowed to say the following:
(defclass my-class (standard-class)
...)
(defmethod make-instance :around
((class my-class) ...)
...)
(defclass my-object-1 () (...)
(:metaclass my-class))
(defmethod make-instance :around
((class (eql (find-class 'my-object-1))) ...)
...)
(defclass my-object-2 (standard-object)
...)
(defmethod initialize-instance :around
((object my-object-2) ...)
...)
You are still not allowed to say this:
(defmethod make-instance :around
((class (eql 'my-object-1)) ...)
...)
...because 'my-object-1 is still an instance of the specified class 'symbol.
In other words: You are allowed to specialize on your own classes or
instances of your own classes.
> Also, the rule was not to define when all arguments are standardized
> class. But isn't &rest argument considered part of the argument too? If
> it is then &rest are not direct instance of standardized class, is it?
> So shouldn't I be allowed to specialize make-instance?
You cannot specialize &rest arguments.
In this context "not allowed to" means "the consequences are undefined
if you do it."
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Pisin Bootvong wrote:
> > Nikodemus Siivola wrote:
> >> Dr. John A.R. Williams wrote:
> >>> Try
> >>>
> >>> (defmethod make-instance((class-name (eql 'abstract-a))
> >>> &rest initargs &key &allow-other-keys)
> >>> ...)
> >>>
> >>> - y ou want to specialise on a specific symbol representing the class
> >>> name.
> >> Oh no you don't!
> >>
> >> See:
> >>
> >> http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
> >>
> >> (point 19)
> >>
> >> What it means is that defining (EQL SOME-SYMBOL) methods on
> >> MAKE-INSTANCE is undefined.
> >>
> >
> > Why is it so? Could you please clarify?
> >
> > How are these two method different:
> >
> > make-instance (class standard-class) &rest initargs
> > and
> > initialize-instance (instance standard-object) &rest initargs
> >
> > Isn't <standard-object> standardized class too?
> > If it is then why am I allowed to specialized on the latter but not the
> > former?
>
> There is no difference. You are not allowed to do this:
>
> (defmethod make-instance :around
> ((class standard-class) ...)
> ...)
>
> (defclass foo (...) (...))
>
> (defmethod make-instance :around
> ((class (eql (find-class 'foo))) ...)
> ...)
>
> (defmethod make-instance :around
> ((class (eql 'foo)) ...)
> ...)
>
--->8--- snip further examples --->8---
I'm finding this all very interesting. What I think has been said so
far (in the context of the original message, which was to do with
specializing MAKE-INSTANCE so it can be used as a factory method in
case it's been forgotten :-) is that this *is* possible, in a simple
manner, but relies on undefined behaviour.
The only proposal that I've seen so far that doesn't invoke undefined
behaviour (i.e. that doesn't use MOP or EQL specialize on standardized
classes, both of which are undefined by ANSI at least I think) was
Pascal's CHANGE-CLASS solution -- whether there exist any subtleties
with this approach remains to be seen (and compared to the other two
options, I must confess I think this 'third way' (there's a political
joke in there somewhere I'm sure) is a little ugly (perhaps that's just
because I'm not in enough of a dynamic mind-set yet so CHANGE-CLASS
makes me instinctively uncomfortable...)
I'd like to thank everybody that responded -- it's been most useful.
-Duncan
ps. I'm experimenting with google groups posting at the moment, so if
my paragraphs are unfilled in this message, I apologise.
-D
"Duncan Rose" <···········@jdwilliams.co.uk> writes:
> I'm finding this all very interesting. What I think has been said so
> far (in the context of the original message, which was to do with
> specializing MAKE-INSTANCE so it can be used as a factory method in
> case it's been forgotten :-) is that this *is* possible, in a simple
> manner, but relies on undefined behaviour.
There's also the notion (which is more what I was thinking of when I
described MAKE-INSTANCE as a "factory" method) that you can defer the
decision of what class to instantiate until runtime:
(make-instance *class-to-make*)
I'm not sure that I'd appreciate having (make-instance 'foo) not
return me a direct instance of FOO even if it were technically legal
to do so (which it's not, as it turns out) but I like being able to
let a given call to MAKE-INSTANCE use runtime information to decide
what class to make.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> "Duncan Rose" <···········@jdwilliams.co.uk> writes:
>
> > I'm finding this all very interesting. What I think has been said so
> > far (in the context of the original message, which was to do with
> > specializing MAKE-INSTANCE so it can be used as a factory method in
> > case it's been forgotten :-) is that this *is* possible, in a simple
> > manner, but relies on undefined behaviour.
>
> There's also the notion (which is more what I was thinking of when I
> described MAKE-INSTANCE as a "factory" method) that you can defer the
> decision of what class to instantiate until runtime:
>
I do hope this doesn't degenerate into a design patterns discussion; I
have enough of those at work... ;-)
> (make-instance *class-to-make*)
>
> I'm not sure that I'd appreciate having (make-instance 'foo) not
> return me a direct instance of FOO even if it were technically legal
> to do so (which it's not, as it turns out) but I like being able to
> let a given call to MAKE-INSTANCE use runtime information to decide
> what class to make.
>
I can understand that coercing MAKE-INSTANCE to return an instance of a
class other than the class requested could be considered less than
ideal (I sense tangential discussions regarding encapsulation in
general could be on-topic here too, if it's not oxymoronic for a
tangential discussion to be on-topic :-) but this all does seem to beg
the question of why MAKE-INSTANCE is a generic function at all -- is it
only to support non-standardized (by ANSI) extensions, such as the MOP?
Do there exist circumstances in 'pure' CL where MAKE-INSTANCE being a
gf has any value?
-Duncan
> -Peter
>
> --
> Peter Seibel * ·····@gigamonkeys.com
> Gigamonkeys Consulting * http://www.gigamonkeys.com/
> Practical Common Lisp * http://www.gigamonkeys.com/book/
Pascal Costanza wrote:
> Pisin Bootvong wrote:
> > Nikodemus Siivola wrote:
> >> Dr. John A.R. Williams wrote:
> >>> Try
> >>>
> >>> (defmethod make-instance((class-name (eql 'abstract-a))
> >>> &rest initargs &key &allow-other-keys)
> >>> ...)
> >>>
> >>> - y ou want to specialise on a specific symbol representing the class
> >>> name.
> >> Oh no you don't!
> >>
> >> See:
> >>
> >> http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
> >>
> >> (point 19)
> >>
> >> What it means is that defining (EQL SOME-SYMBOL) methods on
> >> MAKE-INSTANCE is undefined.
> >>
> >
> > Why is it so? Could you please clarify?
> >
> > How are these two method different:
> >
> > make-instance (class standard-class) &rest initargs
> > and
> > initialize-instance (instance standard-object) &rest initargs
> >
> > Isn't <standard-object> standardized class too?
> > If it is then why am I allowed to specialized on the latter but not the
> > former?
>
> There is no difference. You are not allowed to do this:
>
> (defmethod make-instance :around
> ((class standard-class) ...)
> ...)
>
> (defclass foo (...) (...))
>
> (defmethod make-instance :around
> ((class (eql (find-class 'foo))) ...)
> ...)
>
> (defmethod make-instance :around
> ((class (eql 'foo)) ...)
> ...)
>
> Likewise, you are not allowed to do this:
>
> (defmethod initialize-instance :around
> ((object standard-object) ...)
> ...)
>
> (defparameter *foo* (make-instance 'standard-object))
>
> (defmethod initialize-instance :around
> ((object (eql *foo*)) ...)
> ...)
>
> Your are allowed to say the following:
>
> (defclass my-class (standard-class)
> ...)
>
> (defmethod make-instance :around
> ((class my-class) ...)
> ...)
>
> (defclass my-object-1 () (...)
> (:metaclass my-class))
>
> (defmethod make-instance :around
> ((class (eql (find-class 'my-object-1))) ...)
> ...)
>
> (defclass my-object-2 (standard-object)
> ...)
>
> (defmethod initialize-instance :around
> ((object my-object-2) ...)
> ...)
>
> You are still not allowed to say this:
>
> (defmethod make-instance :around
> ((class (eql 'my-object-1)) ...)
> ...)
>
> ...because 'my-object-1 is still an instance of the specified class 'symbol.
>
> In other words: You are allowed to specialize on your own classes or
> instances of your own classes.
>
> > Also, the rule was not to define when all arguments are standardized
> > class. But isn't &rest argument considered part of the argument too? If
> > it is then &rest are not direct instance of standardized class, is it?
> > So shouldn't I be allowed to specialize make-instance?
>
> You cannot specialize &rest arguments.
>
>
> In this context "not allowed to" means "the consequences are undefined
> if you do it."
>
>
Thank you for answer :-D
> Pascal
>
> --
> 3rd European Lisp Workshop
> July 3 - Nantes, France - co-located with ECOOP 2006
> http://lisp-ecoop06.bknr.net/
The text in
http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
says:
``11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming
Programs
Except where explicitly allowed, the consequences are undefined if any
of the following actions are performed on an external symbol of the
COMMON-LISP package:
....
19. Defining a method for a standardized generic function which is
applicable when all of the arguments are direct instances of
standardized classes. ''
But the text in 7.1 Object Creation and Initialization says
``In addition, make-instance is itself a generic function and thus
also can be customized.''
and 7.1.7 Definitions of Make-Instance and Initialize-Instance says
``Customizing at the Programmer Interface level includes using the
:initform, :initarg, and :default-initargs options to defclass, as well
as _defining methods for make-instance_, allocate-instance, and
initialize-instance.'' [emphasis mine]
It isn't clear to me whether these statements are strong enough to
count as ``explicitly
allowing'' one to define methods on make-instance that modify the
behavior of making
instances of user-defined classes.
Make-instance is a weird edge-case. Since you don't have an instance
to start with, it
only makes sense to specialize make-instance on EQL specializations,
not class
specializations (that is, you specialize on an instance of a class, not
on a class of
instances). It seems that the intent of clause 19 is to prohibit
screwing around with
the creation of system-defined classes, but since the standard
meta-class is itself a
system defined class, this can be interpreted as disallowing
customization of make-instance on anything but hand-rolled metaclasses.
I don't think is what was intended.
What would be interesting is to do a survey of implementations to see
what the current
de-facto standard is with regard to adding methods to make-instance.
Joe Marshall wrote:
--->8--- snipped, hopefully I've left enough context... --->8---
>
> Make-instance is a weird edge-case. Since you don't have an instance
> to start with, it
> only makes sense to specialize make-instance on EQL specializations,
> not class
> specializations (that is, you specialize on an instance of a class, not
> on a class of
> instances). It seems that the intent of clause 19 is to prohibit
> screwing around with
> the creation of system-defined classes, but since the standard
> meta-class is itself a
> system defined class, this can be interpreted as disallowing
> customization of make-instance on anything but hand-rolled metaclasses.
> I don't think is what was intended.
>
> What would be interesting is to do a survey of implementations to see
> what the current
> de-facto standard is with regard to adding methods to make-instance.
LispWorks 4.3 (Mac + Windows), OpenMCL (0.14.3, ouch, I should upgrade
that ...), and CLISP 2.38 (Windows) appear to permit it (and do the
expected thing).
I suppose the real problem is if you're writing (or porting, in my
case) a hopefully-portable-between-Lisps library, it only takes one
implementation to disallow this either now or in the future to make a
partial library redesign necessary -- in which case it's probably best
to design for that eventuality now, rather than later when potentially
a large body of code dependent on said library might end up getting
broken.
-Duncan
"Duncan Rose" <···········@jdwilliams.co.uk> writes:
> Joe Marshall wrote:
>
>> What would be interesting is to do a survey of implementations to see
>> what the current
>> de-facto standard is with regard to adding methods to make-instance.
>
> LispWorks 4.3 (Mac + Windows), OpenMCL (0.14.3, ouch, I should upgrade
> that ...), and CLISP 2.38 (Windows) appear to permit it (and do the
> expected thing).
In this kind of area, it wouldn't surprise me if there were
differences between interpreted and compiled code, and quite possibly
between compiled code under different optimization policies, too.
> I suppose the real problem is if you're writing (or porting, in my
> case) a hopefully-portable-between-Lisps library, it only takes one
> implementation to disallow this either now or in the future to make a
> partial library redesign necessary -- in which case it's probably best
> to design for that eventuality now, rather than later when potentially
> a large body of code dependent on said library might end up getting
> broken.
This seems sound to me. :-)
Christophe
"Pisin Bootvong" <··········@gmail.com> writes:
> Also, the rule was not to define when all arguments are standardized
> class. But isn't &rest argument considered part of the argument too? If
> it is then &rest are not direct instance of standardized class, is it?
> So shouldn't I be allowed to specialize make-instance?
The &rest arguments are arguments too, but it does not matter.
The test in point 19 of section 11.1.2.1.2 is whether there is
*any* argument list to which your method would be applicable and
which consists only of direct instances of standardized classes.
If your method for MAKE-INSTANCE is eql-specialized on the symbol
SOME-SYMBOL, then the argument list (SOME-SYMBOL) satisfies both
conditions, so the consequences of defining such a method are
undefined.
Bill Atkins wrote:
> "Pisin Bootvong" <··········@gmail.com> writes:
>
> > Julian Stecklina wrote:
> >> ········@gmail.com writes:
> >>
> >> > This year I have set out to rewrite that program, and the world is a
> >> > different place! First off, Eclipse is great! (If it had macros,
> >> > keyboard commands, and was Lisp-programmable it would be The Killer
> >> > App!) Eclipse does half the work for you by debugging stupid typos (and
> >> > many thinkos!) and looking up arguments and methods really efficiently.
> >>
> >> At least on my machine Eclipse felt sluggish with JDK 1.4.1 and
> >> painfully sluggish with 1.5 (both on FreeBSD). Even most basic commands
> >> take seconds, e.g. creating a new file which you do fairly often with
> >> Eclipse.
> >
> > I have 2.0 GHz 512MB machine and I run eclipse just fine. May be the
> > problem is with your machine, regarding the performance. Eclipse only
> > start to slow down for me when I have large and lots of source code
> > opened at the same time.
>
> Well, that's not really acceptable, is it? Also, if I'm going to have
> to give up as much memory as Eclipse demands, I'd want neat features
> like interactive extensibility, online documentation, etc. But Emacs
> already gives me all that and uses less memory than Eclipse.
>
Online documentation? I never think Eclipse lacks documentation. Or do
you mean documentation for a class/method you are working on? Then
there is shortcut in Eclipse, or just hover the mouse over item.
> >
> >> Of course, Eclipse eases writing Java considerably, but I am
> >> far from calling it "Killer App".
> >>
> >
> > In the area of IDE it is Killer App.
> > It is best tool for doing refactoring in Java.
> > - How do you rename a class/method/variable and have every references
> > to it also renamed?
> > think this:
> > (let ((foo 'foo))
> > (format t "~A~%" foo)
> > (let ((foo 'bar))
> > (format t "foo ~A~%" foo)))
> > and rename only the inner variable foo to bar without effecting the
> > string, symbol or outer foo in Emacs with only a few key strokes.
>
> Is this important to you? It is well within the capabilities of
> Elisp.
>
local variable is simple one, it's defmethod/defun that is hard.
Alright, may be it's not that hard, but the point is, it is in Eclipse
today.
> As for renaming classes: hopefully, you're following good Lisp style
> and using constructor functions instead of raw MAKE-INSTANCE calls.
>
> (defun make-foo (name address ...)
> (make-instance 'foo :name name :address ...))
>
> becomes
>
> (defun make-foo (name address ...)
> (make-instance 'bar :name name :address ...))
>
And now all subclass of foo refer to non existing foo instead of bar.
Either you forget to mention that you need to update all subclasses of
foo to point to bar instead, or that you forget this step at all. But
Eclipse always remebers to do that.
Also now your function name confuse the reader. Unless you do
refactoring "rename method" to make-bar. Which you have to search and
replace in Emacs, trying not to rename make-foo that is actually from
another package. But Eclipse suport method rename and every method call
to make-foo, within your project source code, get rename to make-bar,
taking in to account the correct package.
> > - How do you move method of a class up to its super class in emacs?
>
> (defmethod foo ((a subclass))
> ...)
>
> becomes
>
> (defmethod foo ((a superclass))
> ...)
>
> > - Keep history of your source code every time you save a buffer.
>
> Emacs has built-in support for versioned backups. There are also
> version control systems.
>
I knew about version control (CVS, SVN, etc). This Eclipse is like
between-commit version control. It's probably the same as versioned
back-up in Emacs. I assume Emacs version probably pollutes your working
directory with the backup file, and has no comment about the
refactoring that has been done (in Eclipse you can see the changes
"semantically" -- as in "what class change, in what method, is it a
rename or a move, etc.")
By the way, How do I turn versioned backup in Emacs on? it seems useful
when I'm toying with code.
> > - Error is highlighted as you type, no need to wait for separate
> > compilation phase to see warning or compile error.
>
> To me, this isn't useful unless the function is fully written, in
> which case I get highlighted errors when I press C-c C-c.
>
> >
> > Compare to Eclipse, SLIME is way inferior. symbol completion is basic
> > in any IDE.
> >
> >> > Having avoided Java for ... well, since its birth, I have to say that
> >> > I'm having fun making rather complex things happen on the screen in
> >> > pretty much no time at all! (And, BTW, my friends and family can
> >> > download my code using WebStart and It Just Works!)
> >>
> >> Deploying Java applications sucks, if you are not on Windows or some
> >> well-known Linux distribution. If Java was so great for "making complex
> >> things happen" on every system a JDK runs on, why are there so few
> >> projects using it? The number of Java projects in the FreeBSD ports tree
> >> seems not to be orders of magnitude larger than the number of Lisp-based
> >> ports despite the hype.
> >>
> >
> > Checking from my Debian, both Lisp and Java packages available are
> > mostly development tool. Java seems to have twice more packages than
> > lisp.
> >
> > Instead of showing the number of development library, I will instead
> > show applications that end-users uses -- as it is actually what counts
> > for how many project people use it.
> >
> > Go to see SwingSighting, just issue 22 and 21 is enough, If you have
> > JRE installed, you can even click webstart button to run an application
> > in a sandbox:
> >
> > http://java.sun.com/products/jfc/tsc/sightings/S22.html
> >
> > Graphic/Sound Editor, 3D Game, MindMap, DB Frontend, PIM, Report
> > Generator, SpreadSheet, CVS Client, XML Editor, Data Visualization, Web
> > site builder, Blog tool, Desktop Publishing, .
> >
> > And be honest, have you seen all that applications in Common Lisp? Does
> > it fills 22 pages?
> >
> >
> > P.S.
> > It's not that I hate Lisp, I just don't like to bend reality.
>
> No, it's just that you don't seem to have used Emacs (and/or Lisp)
> enough to know what you're talking about.
>
There were two things that I disagreed so I replied.
1.) Eclipse is so slow even for a simple commands. It lacks online
documentation. Why use it when it has less feature than Emacs.
+ It's not that slow in my experience, I have used it since version 2.3
(four-five years ago) and it was fast enough at that time. Now with
faster machine, no need to doubt that (version 2.3 still has more
feature than SLIME today).
Eclipse probably has more online documentation than Emacs. But I find
my self rarely need to look up documentation in Eclipse.
I did not try to compare whole Emacs to Eclipse, only the IDE part. I'm
not trying to argue that Eclipse can not check mail or be irc client
for you, but that's different story.
And in that area Eclipse is considered killing App It is part the
reason Java developer gain productivity and like programming in Java.
Its refactoring support is among the top. Most refactoring feature
SLIME doesn't have.
Sure, with more elisp code, SLIME can proably do anything Eclipse can.
But it's not here, today, in my SLIME. That's the point. MS Vista would
feature new DB file system, too, but it's not here today yet.
2.) If Java is so great why are there are not many java project.
+ This is bullsh*t. If there are not many java project. Why do you call
it 'mainstream'? Why there are lots of rant about so much java
programmer? Why do I see lots and variety of applications in
SwingSighting, many you don't see in CL?
Java is used in corporate and in open source world. It is obvious
bullshit to say there are so few project using it. Note that I'm not
talking about good/bad of the Java language. I'm only disagreeing with
"so few java project" part.
> >
> >>
> >> Regards,
> >> --
> >> Julian Stecklina
> >>
> >> Being really good at C++ is like being really good at using rocks to
> >> sharpen sticks. - Thant Tessman
> >
>
> --
> You fool! You fell victim to one of the classic blunders! The most
> famous is, "Never get involved in a land war in Asia", but only
> slightly less well-known is this: "Never go in against a Sicilian when
> death is on the line"!
"Pisin Bootvong" <··········@gmail.com> writes:
>> At least on my machine Eclipse felt sluggish with JDK 1.4.1 and
>> painfully sluggish with 1.5 (both on FreeBSD). Even most basic commands
>> take seconds, e.g. creating a new file which you do fairly often with
>> Eclipse.
>
> I have 2.0 GHz 512MB machine and I run eclipse just fine. May be the
> problem is with your machine, regarding the performance. Eclipse only
> start to slow down for me when I have large and lots of source code
> opened at the same time.
I tried it on my Athlon XP 2008MHz with 1GB RAM and my 1,4GHz Pentium-M
with 512MB. The Athlon made it run "acceptably", but still
sluggish. Maybe the JDK on FreeBSD has performance problems or
something.
> In the area of IDE it is Killer App.
> It is best tool for doing refactoring in Java.
> - How do you rename a class/method/variable and have every references
> to it also renamed?
> think this:
> (let ((foo 'foo))
> (format t "~A~%" foo)
> (let ((foo 'bar))
> (format t "foo ~A~%" foo)))
> and rename only the inner variable foo to bar without effecting the
> string, symbol or outer foo in Emacs with only a few key strokes.
A plus for Eclipse.
> - How do you move method of a class up to its super class in emacs?
This is an artificial problem of Java. Replace one word in the defmethod
line and optionally remove the method from your running project. Done.
> - Keep history of your source code every time you save a buffer.
Version control is tightly integrated in Emacs. CVS in Eclipse just
plain sucks.
> - Error is highlighted as you type, no need to wait for separate
> compilation phase to see warning or compile error.
Neccessary in Java. I do not miss it in CL.
> Compare to Eclipse, SLIME is way inferior. symbol completion is basic
> in any IDE.
Slime has the better debugging and inspecting tools.
> Checking from my Debian, both Lisp and Java packages available are
> mostly development tool. Java seems to have twice more packages than
> lisp.
Compare that to the C packages.
> Go to see SwingSighting, just issue 22 and 21 is enough, If you have
> JRE installed, you can even click webstart button to run an application
> in a sandbox:
>
> http://java.sun.com/products/jfc/tsc/sightings/S22.html
I have a JDK/JRE and it works with map24.com. Firefox just wants to
download the file, if I hit "Launch", anyway...
> And be honest, have you seen all that applications in Common Lisp? Does
> it fills 22 pages?
:)
Regards,
--
Julian Stecklina
Being really good at C++ is like being really good at using rocks to
sharpen sticks. - Thant Tessman
Wade Humeniuk <··················@telus.net> writes:
> Peter Seibel wrote:
>> A couple weeks ago I was in New York and did a couple talks, one at
>> the LispNYC group and the other at Google's NY office. The video of
>> the Google talk is up at:
>> <http://video.google.com/videoplay?docid=448441135356213813>
>> In theory the LispNYC talk was taped too but apparently there were
>> some problems with the audio that the AV wizards may or may not be
>> able to straighten out; I'll post again if it shows up on the web.
>>
>
> Hey Peter, Good Job.
>
> Next time, if there is a next one, I would like to hear you ask the
> audience why some of them have not taken the time to learn Lisp.
> Obviously the crowd was there because they were intellectually
> curious, but some had not taken the time to learn Lisp. I assume
> that the room was full of the cream of the crop and it would have
> been a great opportunity to learn something.
That's an excellent idea. I think I really need to distill this talk
down to a simple "Why Lisp?" talk because, having given two versions
of it now I think that's what folks really want. And in that context
turning around and asking the audience "Why Not Lisp?" would make a
lot of sense. Maybe someone at Google's West Coast campus will invite
me. (It seemed a little silly to fly clear across the country in order
to talk at Google--not that that was the only reason I went east.)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Sun, 21 May 2006 00:07:28 GMT
Peter Seibel <·····@gigamonkeys.com> wrote:
> A couple weeks ago I was in New York and did a couple talks, one at
> the LispNYC group and the other at Google's NY office. The video of
> the Google talk is up at:
>
> <http://video.google.com/videoplay?docid=448441135356213813>
Is it possible to download it using wget? My inet connection isn't fast enough
to watch it "in place". I think, if its size is some 600M even downloading will take days.
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> On Sun, 21 May 2006 00:07:28 GMT
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
>> A couple weeks ago I was in New York and did a couple talks, one at
>> the LispNYC group and the other at Google's NY office. The video of
>> the Google talk is up at:
>>
>> <http://video.google.com/videoplay?docid=448441135356213813>
> Is it possible to download it using wget? My inet connection isn't fast enough
> to watch it "in place". I think, if its size is some 600M even downloading will take days.
Look on the right side of that page, There is a "Download" button there,
and also a link, if you want to use wget:
http://vp.video.google.com/videodownload?version=0&secureurl=xQAAAG7ggqAHSiJjpW0D3w4aYTV3h-AELKIxGbLwuyrbclo-c3HAo8XNvPP-tSdQRYgL-fYsVHix9Z2q-F5B3REkiyTE_HZJvPkhu4eDCkM4HKRc8SlPUxrUsd-Ba_tu3Lr53joXikyP1R8ZHFoJQPwDYgzJpOA2US7E7E5xqEfCIjI_YlX-56jF9eEDJYFim45jTIRUX1luHVQUWdgzvi4sYa1o6shWIQd259xtBq-ZldZbgsfpfYGxlOpo5ly1rwgZKGq2PFEnvCw6z6uRWf8d9JI&sigh=JvIoYg3pw8WdsWkYR0ACzRefvgI&begin=0&len=4324668&docid=448441135356213813
--
vedm
vedm <··@ns.com> writes:
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>
> > On Sun, 21 May 2006 00:07:28 GMT
> > Peter Seibel <·····@gigamonkeys.com> wrote:
> >
> >> A couple weeks ago I was in New York and did a couple talks, one at
> >> the LispNYC group and the other at Google's NY office. The video of
> >> the Google talk is up at:
> >>
> >> <http://video.google.com/videoplay?docid=448441135356213813> Is
> >it possible to download it using wget? My inet connection isn't
> >fast enough to watch it "in place". I think, if its size is some
> >600M even downloading will take days.
>
> Look on the right side of that page, There is a "Download" button there,
> and also a link, if you want to use wget:
>
> http://vp.video.google.com/videodownload?version=0&secureurl=xQAAAG7ggqAHSiJjpW0D3w4aYTV3h-AELKIxGbLwuyrbclo-c3HAo8XNvPP-tSdQRYgL-fYsVHix9Z2q-F5B3REkiyTE_HZJvPkhu4eDCkM4HKRc8SlPUxrUsd-Ba_tu3Lr53joXikyP1R8ZHFoJQPwDYgzJpOA2US7E7E5xqEfCIjI_YlX-56jF9eEDJYFim45jTIRUX1luHVQUWdgzvi4sYa1o6shWIQd259xtBq-ZldZbgsfpfYGxlOpo5ly1rwgZKGq2PFEnvCw6z6uRWf8d9JI&sigh=JvIoYg3pw8WdsWkYR0ACzRefvgI&begin=0&len=4324668&docid=448441135356213813
Oddly, Quicktime 7.1 won't play sound on my OS X Panther machine. VLC
works just fine though. Just an FYI.
--
http://www.david-steuber.com/
1998 Subaru Impreza Outback Sport
2006 Honda 599 Hornet (CB600F) x 2 Crash & Slider
The lithobraker. Zero distance stops at any speed.