What are actually the reasons to choose CLISP over other free
implementations?
I believe there are some. Compared to SBCL, for example:
- Fast bignum operations.
- Fast CLOS instantiations.
- Much faster compiler speed, which is nice for big projects.
- Better memory management. SBCL (and CMUCL) tends to do not return
unallocated memory and wastes a lot of OS virtual memory.
- Better memory footprint. It just need about 4 Mb of memory at
startup.
- Better debugger. CLISP usually allows you to choose from more
options when an error occurs in the debugger.
- Better internationalization. Most messages are translated into
various languages.
What do you think about? Any more ideas?
On Nov 28, 10:56 am, Javier <·······@gmail.com> wrote:
> What are actually the reasons to choose CLISP over other free
> implementations?
>
> I believe there are some. Compared to SBCL, for example:
>
> - Fast bignum operations.
> - Fast CLOS instantiations.
> - Much faster compiler speed, which is nice for big projects.
> - Better memory management. SBCL (and CMUCL) tends to do not return
> unallocated memory and wastes a lot of OS virtual memory.
> - Better memory footprint. It just need about 4 Mb of memory at
> startup.
> - Better debugger. CLISP usually allows you to choose from more
> options when an error occurs in the debugger.
> - Better internationalization. Most messages are translated into
> various languages.
>
> What do you think about? Any more ideas?
I'm on Mac OSX (intel procesor)
No FFI support.
No Multiprocess support.
-Jason
On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
> What are actually the reasons to choose CLISP over other free
> implementations?
>
> I believe there are some. Compared to SBCL, for example:
>
> - Fast bignum operations.
> - Fast CLOS instantiations.
> - Much faster compiler speed, which is nice for big projects.
> - Better memory management. SBCL (and CMUCL) tends to do not return
> unallocated memory and wastes a lot of OS virtual memory.
> - Better memory footprint. It just need about 4 Mb of memory at
> startup.
> - Better debugger. CLISP usually allows you to choose from more
> options when an error occurs in the debugger.
> - Better internationalization. Most messages are translated into
> various languages.
>
> What do you think about? Any more ideas?
- No threads so forget about web development.
- Using FFI will turn your application into GPLware.
Slobodan
On Nov 28, 3:16 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
>
>
>
> > What are actually the reasons to choose CLISP over other free
> > implementations?
>
> > I believe there are some. Compared to SBCL, for example:
>
> > - Fast bignum operations.
> > - Fast CLOS instantiations.
> > - Much faster compiler speed, which is nice for big projects.
> > - Better memory management. SBCL (and CMUCL) tends to do not return
> > unallocated memory and wastes a lot of OS virtual memory.
> > - Better memory footprint. It just need about 4 Mb of memory at
> > startup.
> > - Better debugger. CLISP usually allows you to choose from more
> > options when an error occurs in the debugger.
> > - Better internationalization. Most messages are translated into
> > various languages.
>
> > What do you think about? Any more ideas?
>
> - No threads so forget about web development.
I'm not sure I entirely agree with this, given that the Apaches most
people used until recently were also not threaded (let alone older
perl, and the way other, possibly threaded languages that still forked
an interpreter or kept a pool of them using Apache modules or fastcgi
were used to serve a grea deal of content). It is a limitation you
should be aware of though. Of course it makes clisp pretty useless
under windows for web stuff, but... well, I guess the win platform has
gotten better over the last few years. I would still hesitate to host
an important site on win.
> - Using FFI will turn your application into GPLware.
Is it only the FFI? Maybe I misread things, but it seemed, at one
point, as if the CLisp interpretation of its GPL provision resembled
"The Thing That Ate Detroit". Have they reimplemented readline? Or was
I entirely mistaken in my interpretation of their statement on the
subject? At any rate, it is certainly more portable than CMUCL or
SBCL, and it does some kinds of math fast ;). Also, it was the first
CL I used that was basically compliant, so there is a nostalgia
factor. It is also a bit less of a beast when it comes to resources,
but that is not as big an issue as it was even 5 years ago.
On 29 nov, 00:58, ··········@aol.com wrote:
> On Nov 28, 3:16 pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
> > On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
>
> > > What are actually the reasons to choose CLISP over other free
> > > implementations?
>
> > > I believe there are some. Compared to SBCL, for example:
>
> > > - Fast bignum operations.
> > > - Fast CLOS instantiations.
> > > - Much faster compiler speed, which is nice for big projects.
> > > - Better memory management. SBCL (and CMUCL) tends to do not return
> > > unallocated memory and wastes a lot of OS virtual memory.
> > > - Better memory footprint. It just need about 4 Mb of memory at
> > > startup.
> > > - Better debugger. CLISP usually allows you to choose from more
> > > options when an error occurs in the debugger.
> > > - Better internationalization. Most messages are translated into
> > > various languages.
>
> > > What do you think about? Any more ideas?
>
> > - No threads so forget about web development.
>
> I'm not sure I entirely agree with this, given that the Apaches most
> people used until recently were also not threaded (let alone older
> perl, and the way other, possibly threaded languages that still forked
> an interpreter or kept a pool of them using Apache modules or fastcgi
> were used to serve a grea deal of content). It is a limitation you
> should be aware of though. Of course it makes clisp pretty useless
> under windows for web stuff, but... well, I guess the win platform has
> gotten better over the last few years. I would still hesitate to host
> an important site on win.
>
> > - Using FFI will turn your application into GPLware.
>
> Is it only the FFI? Maybe I misread things, but it seemed, at one
> point, as if the CLisp interpretation of its GPL provision resembled
> "The Thing That Ate Detroit". Have they reimplemented readline? Or was
> I entirely mistaken in my interpretation of their statement on the
> subject? At any rate, it is certainly more portable than CMUCL or
> SBCL, and it does some kinds of math fast ;). Also, it was the first
> CL I used that was basically compliant, so there is a nostalgia
> factor. It is also a bit less of a beast when it comes to resources,
> but that is not as big an issue as it was even 5 years ago.
Some of the things you are discussing here are planned tasks for
future CLISP releases. For example, a JIT (just in time compiler, ala
Java), UFFI port, multithreading (actualy it is half finished, so a
future CLISP being multithreading is likely to be released soon), and
JVM compilation (to make it fully Java compatible).
More info:
http://sourceforge.net/pm/?group_id=1355
(As concerning to myself, I'd like to help improve CLISP. The only
thing that is limiting me to do so is that I'm not a very good Lisp
programmer yet.)
On Wed, 28 Nov 2007 16:17:49 -0800, Javier wrote:
> (As concerning to myself, I'd like to help improve CLISP. The only
> thing that is limiting me to do so is that I'm not a very good Lisp
> programmer yet.)
You'd probably be better served (to improve clisp anyway) by being a good
C programmer.
Matt
--
"You do not really understand something unless you
can explain it to your grandmother." -- Albert Einstein.
On 29 Nov, 00:17, Javier <·······@gmail.com> wrote:
> Some of the things you are discussing here are planned tasks for
> future CLISP releases. For example, a JIT (just in time compiler, ala
> Java), UFFI port, multithreading
About a year ago I found CLISP and SBCL were more distinct than they
are now. To me SBCL meant "speed" and "big" while CLISP meant
"portable" and "small". Now, with CLISP considering adding threads but
it's image size slowly growing while SBCL is starting to look more
attractive on Windows, the distinctions are becoming less obvious.
Of course, there are still many differences between the various
implementations so the best advice is to become familiar with a few of
them and use the one(s) that suits your project(s).
--
Phil
http://phil.nullable.eu/
On Nov 29, 12:58 am, ··········@aol.com wrote:
> On Nov 28, 3:16 pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
> > On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
>
> > > What are actually the reasons to choose CLISP over other free
> > > implementations?
>
> > > I believe there are some. Compared to SBCL, for example:
>
> > > - Fast bignum operations.
> > > - Fast CLOS instantiations.
> > > - Much faster compiler speed, which is nice for big projects.
> > > - Better memory management. SBCL (and CMUCL) tends to do not return
> > > unallocated memory and wastes a lot of OS virtual memory.
> > > - Better memory footprint. It just need about 4 Mb of memory at
> > > startup.
> > > - Better debugger. CLISP usually allows you to choose from more
> > > options when an error occurs in the debugger.
> > > - Better internationalization. Most messages are translated into
> > > various languages.
>
> > > What do you think about? Any more ideas?
>
> > - No threads so forget about web development.
>
> I'm not sure I entirely agree with this, given that the Apaches most
> people used until recently were also not threaded (let alone older
> perl, and the way other, possibly threaded languages that still forked
> an interpreter or kept a pool of them using Apache modules or fastcgi
> were used to serve a grea deal of content). It is a limitation you
> should be aware of though. Of course it makes clisp pretty useless
> under windows for web stuff, but... well, I guess the win platform has
> gotten better over the last few years. I would still hesitate to host
> an important site on win.
I don't say it's impossible , just I won't do it. Someday maybe even
weblocks will has such setup
Taken from http://groups.google.com/group/weblocks/browse_thread/thread/72060f1b76b6bcbf
>> I doubt hunchentoot would be of any use in a single threaded
>> implementation.
>> Unless you're planning a single user web app :)
>Actually, you can get very far with this setup. If you offload serving
>of static content to Apache and dynamic content is relatively quick to
>generate (which it normally is for web pages) you can get very high
>throughput. This setup for weblocks will remain on wishlist for a
>while, though.
But today when implementations exist who support hundreds of thousands
threads , think Erlang, Gambit, Mozart going back to single threading
seems like a bad idea. I want to see actor based threading like before
mentioned and SMP implemented in lisp implementations. Not going back
to 90s.
In today world where multicores are standard, this will be important
feature.
>
> > - Using FFI will turn your application into GPLware.
>
> Is it only the FFI? Maybe I misread things, but it seemed, ...
Kenny said that FFI and AMOP staff are in the exception, so that makes
GPL point non-issue.
Slobodan
In article
<····································@s36g2000prg.googlegroups.com>,
Slobodan Blazeski <·················@gmail.com> wrote:
> On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
> > What are actually the reasons to choose CLISP over other free
> > implementations?
> >
> > I believe there are some. Compared to SBCL, for example:
> >
> > - Fast bignum operations.
> > - Fast CLOS instantiations.
> > - Much faster compiler speed, which is nice for big projects.
> > - Better memory management. SBCL (and CMUCL) tends to do not return
> > unallocated memory and wastes a lot of OS virtual memory.
> > - Better memory footprint. It just need about 4 Mb of memory at
> > startup.
> > - Better debugger. CLISP usually allows you to choose from more
> > options when an error occurs in the debugger.
> > - Better internationalization. Most messages are translated into
> > various languages.
> >
> > What do you think about? Any more ideas?
>
> - No threads so forget about web development.
Why didn't you tell that Paul Graham years back then?
If he knew that , he would have stopped and not
developed the Viaweb editor - in CLISP.
> - Using FFI will turn your application into GPLware.
>
> Slobodan
On Nov 28, 9:28 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@s36g2000prg.googlegroups.com>,
> Slobodan Blazeski <·················@gmail.com> wrote:
>
>
>
> > On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
> > > What are actually the reasons to choose CLISP over other free
> > > implementations?
>
> > > I believe there are some. Compared to SBCL, for example:
>
> > > - Fast bignum operations.
> > > - Fast CLOS instantiations.
> > > - Much faster compiler speed, which is nice for big projects.
> > > - Better memory management. SBCL (and CMUCL) tends to do not return
> > > unallocated memory and wastes a lot of OS virtual memory.
> > > - Better memory footprint. It just need about 4 Mb of memory at
> > > startup.
> > > - Better debugger. CLISP usually allows you to choose from more
> > > options when an error occurs in the debugger.
> > > - Better internationalization. Most messages are translated into
> > > various languages.
>
> > > What do you think about? Any more ideas?
>
> > - No threads so forget about web development.
>
> Why didn't you tell that Paul Graham years back then?
He might have listen to me, just imagine the lost buzz :)
>
> If he knew that , he would have stopped and not
> developed the Viaweb editor - in CLISP.
Yes I know about Clisp / Viaweb story. Even today is possible. But
most people prefer threaded implementation.
>
> > - Using FFI will turn your application into GPLware.
>
> > Slobodan
On Nov 28, 12:28 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@s36g2000prg.googlegroups.com>,
> Slobodan Blazeski <·················@gmail.com> wrote:
>
>
>
> > On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
> > > What are actually the reasons to choose CLISP over other free
> > > implementations?
>
> > > I believe there are some. Compared to SBCL, for example:
>
> > > - Fast bignum operations.
> > > - Fast CLOS instantiations.
> > > - Much faster compiler speed, which is nice for big projects.
> > > - Better memory management. SBCL (and CMUCL) tends to do not return
> > > unallocated memory and wastes a lot of OS virtual memory.
> > > - Better memory footprint. It just need about 4 Mb of memory at
> > > startup.
> > > - Better debugger. CLISP usually allows you to choose from more
> > > options when an error occurs in the debugger.
> > > - Better internationalization. Most messages are translated into
> > > various languages.
>
> > > What do you think about? Any more ideas?
>
> > - No threads so forget about web development.
>
> Why didn't you tell that Paul Graham years back then?
>
> If he knew that , he would have stopped and not
> developed the Viaweb editor - in CLISP.
>
> > - Using FFI will turn your application into GPLware.
>
> > Slobodan
pal graham kicks ass
On Wed, 28 Nov 2007 12:16:36 -0800, Slobodan Blazeski wrote:
> - No threads so forget about web development.
It really depends on the architecture. You can build pretty large and
fast web apps using just "old school" multi-process systems. The real
advantage of threads is the fast sharing of large sets of peristent data,
which you may not do all that much. For many tasks, using a single SQL
database backend (with something like memcached thrown in when you need
it) is enough. Plus, it's usually trivial to spread those systems across
multiple servers.
The only time I've really needed to use threads for a web app was when
the amount of shared data was large and specialized enough that querying
it via the database was getting too slow and could obviously be improved
by using better suited algorithms, small enough to fit into memory (about
5 .. 10 Gb) and too large to be copied across multiple processes on an 8-
core 16Gb machine. And even then the whole multi-thread system was
separated out so we could move and duplicate it to multiple machines.
* disclaimer: this was a mostly perl/C++ system, but I think the
principle is more or less the same.
Joost.
On Nov 30, 10:13 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> On Wed, 28 Nov 2007 12:16:36 -0800, Slobodan Blazeski wrote:
> > - No threads so forget about web development.
>
> It really depends on the architecture. You can build pretty large and
> fast web apps using just "old school" multi-process systems. The real
> advantage of threads is the fast sharing of large sets of peristent data,
> which you may not do all that much. For many tasks, using a single SQL
> database backend (with something like memcached thrown in when you need
> it) is enough. Plus, it's usually trivial to spread those systems across
> multiple servers.
>
> The only time I've really needed to use threads for a web app was when
> the amount of shared data was large and specialized enough that querying
> it via the database was getting too slow and could obviously be improved
> by using better suited algorithms, small enough to fit into memory (about
> 5 .. 10 Gb) and too large to be copied across multiple processes on an 8-
> core 16Gb machine. And even then the whole multi-thread system was
> separated out so we could move and duplicate it to multiple machines.
>
> * disclaimer: this was a mostly perl/C++ system, but I think the
> principle is more or less the same.
>
> Joost.
How do you use sessions in single thread? Or some other mechanism for
people to get their customized page when they login?
Slobodan
From: Raymond Wiker
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <m2k5nx8j1t.fsf@Macintosh-2.local>
Slobodan Blazeski <·················@gmail.com> writes:
> On Nov 30, 10:13 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
>> On Wed, 28 Nov 2007 12:16:36 -0800, Slobodan Blazeski wrote:
>> > - No threads so forget about web development.
>>
>> It really depends on the architecture. You can build pretty large and
>> fast web apps using just "old school" multi-process systems. The real
>> advantage of threads is the fast sharing of large sets of peristent data,
>> which you may not do all that much. For many tasks, using a single SQL
>> database backend (with something like memcached thrown in when you need
>> it) is enough. Plus, it's usually trivial to spread those systems across
>> multiple servers.
>>
>> The only time I've really needed to use threads for a web app was when
>> the amount of shared data was large and specialized enough that querying
>> it via the database was getting too slow and could obviously be improved
>> by using better suited algorithms, small enough to fit into memory (about
>> 5 .. 10 Gb) and too large to be copied across multiple processes on an 8-
>> core 16Gb machine. And even then the whole multi-thread system was
>> separated out so we could move and duplicate it to multiple machines.
>>
>> * disclaimer: this was a mostly perl/C++ system, but I think the
>> principle is more or less the same.
>>
>> Joost.
>
>
> How do you use sessions in single thread? Or some other mechanism for
> people to get their customized page when they login?
One word: cookies.
Alternatively, encode a session id in query parameters.
This is necessary, whether you have threading available or
not, as HTTP is a connectionless protocol.
Raymond Wiker <···@RawMBP.local> wrote:
+---------------
| Slobodan Blazeski <·················@gmail.com> writes:
| > How do you use sessions in single thread? Or some other mechanism
| > for people to get their customized page when they login?
|
| One word: cookies.
| Alternatively, encode a session id in query parameters.
+---------------
The problem with cookies is that they're common to all window/tab
instances within a browser. When a user has multiple windows/tabs
open on your site, if you store state information in cookies you're
going to leak information between different active windows/tabs.
This is rarely good for storing "continuations" within a single
session, but can be good for authentication data [with suitable
encryption].
The problem with encoding session IDs in query parameters is
garbage collection of "sessions".
A third method is to store the entire continuation within
(hidden) query parameters. I tend to prefer this one, as
it allows diffent user windows/tabs to take different paths
within your site and collect separate stateful data along
the way, without leaving any "session" state on the server
that needs garbage collecting.
Authentication/encryption/serialization to avoid replay attacks
is needed for all three methods.
+---------------
| This is necessary, whether you have threading available or
| not, as HTTP is a connectionless protocol.
+---------------
Slight quibble on terminology: HTTP *is* a connection-based protocol,
since it uses TCP, which sets up [and tears down] a connection for
each HTTP request. Or maybe even holds the same connection open
across *several* requests, if both sides respect the HTTP 1.1
"Connection: open" protocol.
What you're trying to say is that HTTP is *stateless* between
HTTP requests, which it is, even when there are multiple HTTP
requests within a single TCP connection.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Raymond Wiker
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <m24pf08g3z.fsf@Macintosh-2.local>
····@rpw3.org (Rob Warnock) writes:
> Raymond Wiker <···@RawMBP.local> wrote:
> +---------------
> | Slobodan Blazeski <·················@gmail.com> writes:
> | > How do you use sessions in single thread? Or some other mechanism
> | > for people to get their customized page when they login?
> |
> | One word: cookies.
> | Alternatively, encode a session id in query parameters.
> +---------------
>
> The problem with cookies is that they're common to all window/tab
> instances within a browser. When a user has multiple windows/tabs
> open on your site, if you store state information in cookies you're
> going to leak information between different active windows/tabs.
> This is rarely good for storing "continuations" within a single
> session, but can be good for authentication data [with suitable
> encryption].
>
> The problem with encoding session IDs in query parameters is
> garbage collection of "sessions".
>
> A third method is to store the entire continuation within
> (hidden) query parameters. I tend to prefer this one, as
> it allows diffent user windows/tabs to take different paths
> within your site and collect separate stateful data along
> the way, without leaving any "session" state on the server
> that needs garbage collecting.
I was about to say that this is the same as what I suggested,
but it (obviously) is not, and I agree completely that this may be the
best option.
> Authentication/encryption/serialization to avoid replay attacks
> is needed for all three methods.
>
> +---------------
> | This is necessary, whether you have threading available or
> | not, as HTTP is a connectionless protocol.
> +---------------
>
> Slight quibble on terminology: HTTP *is* a connection-based protocol,
> since it uses TCP, which sets up [and tears down] a connection for
> each HTTP request. Or maybe even holds the same connection open
> across *several* requests, if both sides respect the HTTP 1.1
> "Connection: open" protocol.
No, HTTP is connectionless, but is commonly implemented on top
of a connection-oriented protocol :-)
> What you're trying to say is that HTTP is *stateless* between
> HTTP requests, which it is, even when there are multiple HTTP
> requests within a single TCP connection.
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
On Sun, 02 Dec 2007 02:21:50 -0800, Slobodan Blazeski wrote:
> How do you use sessions in single thread? Or some other mechanism for
> people to get their customized page when they login?
>
> Slobodan
Get their session ID from a cookie or whatever and get whatever state you
need from that session, when you need it, from whatever machinery holds
the state for that session (like a database or filesystem or memcached
process). In many cases you don't have to keep much more state in that
session than the user's name and permissions anyway.
Joost.
Slobodan Blazeski <·················@gmail.com> wrote:
> On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
>> What are actually the reasons to choose CLISP over other free
>> implementations?
>>
>> I believe there are some. Compared to SBCL, for example:
>>
>> - Fast bignum operations.
>> - Fast CLOS instantiations.
>> - Much faster compiler speed, which is nice for big projects.
>> - Better memory management. SBCL (and CMUCL) tends to do not return
>> unallocated memory and wastes a lot of OS virtual memory.
>> - Better memory footprint. It just need about 4 Mb of memory at
>> startup.
>> - Better debugger. CLISP usually allows you to choose from more
>> options when an error occurs in the debugger.
>> - Better internationalization. Most messages are translated into
>> various languages.
>>
>> What do you think about? Any more ideas?
>
> - No threads so forget about web development.
Well, the first Lisp based web development I did was with CLisp, doing
CGI based stuff with my own lisp-cgi-library ;-)
Of course, that is not something you want to do if you expect a lot of
queries per second.
> - Using FFI will turn your application into GPLware.
I've got no problem with that, but everybody has to decide that for
himself.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
From: Klaus Schilling
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <87mysufipv.fsf@web.de>
Slobodan Blazeski <·················@gmail.com> writes:
> - Using FFI will turn your application into GPLware.
this would be an advantage of CLISP,
as pointed out by R.M. Stallman.
Klaus Schilling
On Dec 2, 12:22 am, Klaus Schilling <···············@web.de> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > - Using FFI will turn your application into GPLware.
>
> this would be an advantage of CLISP,
> as pointed out by R.M. Stallman.
>
> Klaus Schilling
No it won't.
People who want their code under GPL will do it it anyway, people who
don't won't use it.
Slobodan
Slobodan Blazeski <·················@gmail.com> writes:
>
>> > - Using FFI will turn your application into GPLware.
>>
>> this would be an advantage of CLISP, as pointed out by R.M. Stallman.
>
> No it won't. People who want their code under GPL will do it it
> anyway, people who don't won't use it.
Not necessarily: if the cost of releasing under the GPL is less than the
cost of re-implementing GPLed code, then people will release their code
under the GPL regardless of whether they want to or not. This is a good
thing for users who will thus have source at their fingertips; it is a
bad thing for those who don't want to give out their source code.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The mark of the immature man is that he wants to die nobly for a cause,
while the mark of a mature man is that he wants to live humbly for one.
--Wilhelm Stekel
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| Slobodan Blazeski <·················@gmail.com> writes:
| > No it won't. People who want their code under GPL will do it it
| > anyway, people who don't won't use it.
|
| Not necessarily: if the cost of releasing under the GPL is less than the
| cost of re-implementing GPLed code, then people will release their code
| under the GPL regardless of whether they want to or not. This is a good
| thing for users who will thus have source at their fingertips; it is a
| bad thing for those who don't want to give out their source code.
+---------------
**OPEN SOURCE != GPL!!!** Do not attempt to conflate the two!!
There are many open-source arrangements which do not contain
the viral contamination clauses inherent in the GPL.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
>
> | > No it won't. People who want their code under GPL will do it it
> | > anyway, people who don't won't use it.
> |
> | Not necessarily: if the cost of releasing under the GPL is less than
> | the cost of re-implementing GPLed code, then people will release
> | their code under the GPL regardless of whether they want to or not.
> | This is a good thing for users who will thus have source at their
> | fingertips; it is a bad thing for those who don't want to give out
> | their source code.
>
> **OPEN SOURCE != GPL!!!** Do not attempt to conflate the two!!
I didn't. I try not to use 'open source' anyway, preferring 'free
software.'
The GPL is good for users, among other reasons because they have the
source code; having the source is not the sole benefit of course.
> There are many open-source arrangements which do not contain the viral
> contamination clauses inherent in the GPL.
Those arrangements generally have disadvantages for users.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A Democracy: Three wolves and a sheep voting on dinner.
A Republic: The flock gets to vote for which wolves vote on dinner.
A Constitutional Republic: Voting on dinner is expressly forbidden, and
the sheep are armed.
--Anonymous
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > **OPEN SOURCE != GPL!!!** Do not attempt to conflate the two!!
|
| I didn't. I try not to use 'open source' anyway, preferring 'free
| software.'
|
| The GPL is good for users, among other reasons because they have the
| source code; having the source is not the sole benefit of course.
|
| > There are many open-source arrangements which do not contain the viral
| > contamination clauses inherent in the GPL.
|
| Those arrangements generally have disadvantages for users.
+---------------
For *some* users, perhaps; for other users the ability to use
non-viral source in their proprietary products is an advantage.
I can see we're going to have to agree to disagree on this issue.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Ken Tilton
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <FXN4j.1486$MM2.468@newsfe09.lga>
Robert Uhl wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
>
>>>>- Using FFI will turn your application into GPLware.
>>>
>>>this would be an advantage of CLISP, as pointed out by R.M. Stallman.
>>
>>No it won't. People who want their code under GPL will do it it
>>anyway, people who don't won't use it.
>
>
> Not necessarily:
You mean because the statement that using the FFI makes client code GPL
was bullshit?
>.. if the cost of releasing under the GPL is less than the
> cost of re-implementing GPLed code,...
Oh, well, I can dream can't I?
Given that cost of the GPl is infinite, what values would it be less
than? (Just hoping some yobba pedant tries to lecture me on different
levels of infinity.)
>... then people will release their code
> under the GPL regardless of whether they want to or not.
Your grasp of human nature seems to be interfering with your grasp on
reality.
> This is a good
> thing for users who will thus have source at their fingertips;
This is true. My grandmother was freaking out over the obtuse behavior
of the timer key on her microwave oven, but fortunately it was open
source so I just gave her my C++ manual and...
> it is a
> bad thing for those who don't want to give out their source code.
>
Not me. I just run it thru my rocco-rossi confabulator and... oh my god,
have I just defeated the GPL? We write a program to obfuscate source.
The exe we ship is built from the obfuscated source, we work on the
readable source. We ship the EXE along with the obfuscated source, fully
complying with the GPL!
I scare myself sometimes.
kxo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
What a boring guy. Always talking about the same off topic things, and
against everything or everyone he can, just to catch up a moment of
glory.
On 3 dic, 08:10, Ken Tilton <···········@optonline.net> wrote:
> Robert Uhl wrote:
> > Slobodan Blazeski <·················@gmail.com> writes:
>
> >>>>- Using FFI will turn your application into GPLware.
>
> >>>this would be an advantage of CLISP, as pointed out by R.M. Stallman.
>
> >>No it won't. People who want their code under GPL will do it it
> >>anyway, people who don't won't use it.
>
> > Not necessarily:
>
> You mean because the statement that using the FFI makes client code GPL
> was bullshit?
>
> >.. if the cost of releasing under the GPL is less than the
> > cost of re-implementing GPLed code,...
>
> Oh, well, I can dream can't I?
>
> Given that cost of the GPl is infinite, what values would it be less
> than? (Just hoping some yobba pedant tries to lecture me on different
> levels of infinity.)
>
> >... then people will release their code
> > under the GPL regardless of whether they want to or not.
>
> Your grasp of human nature seems to be interfering with your grasp on
> reality.
>
> > This is a good
> > thing for users who will thus have source at their fingertips;
>
> This is true. My grandmother was freaking out over the obtuse behavior
> of the timer key on her microwave oven, but fortunately it was open
> source so I just gave her my C++ manual and...
>
> > it is a
> > bad thing for those who don't want to give out their source code.
>
> Not me. I just run it thru my rocco-rossi confabulator and... oh my god,
> have I just defeated the GPL? We write a program to obfuscate source.
> The exe we ship is built from the obfuscated source, we work on the
> readable source. We ship the EXE along with the obfuscated source, fully
> complying with the GPL!
>
> I scare myself sometimes.
>
> kxo
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Ken Tilton <···········@optonline.net> writes:
>
>> .. if the cost of releasing under the GPL is less than the cost of
>> re-implementing GPLed code,...
>
> Oh, well, I can dream can't I?
>
> Given that cost of the GPl is infinite, what values would it be less
> than?
The GPL's cost is not infinite, although it may be large. There's the
monetary cost: if I planned to make money selling proprietary
modifications to GPLed code, then using the GPL for those modifications
would obviously cost me whatever money I would have made. That's not an
infinite amount; it's a rather finite amount.
There's the philosophical cost: regardless of whether I planned to make
money or not, I may not agree with the GPL, and thus using it imposes a
cost on me. That cost is not infinite either.
There's the nuisance cost, which is a general form of the philosophical
cost: I may be annoyed that the GPL forces to play ball or go home.
That cost, too, is finite.
There's the opportunity cost: I may lose patches, modifications and
improvements from others who find the GPL's cost too high for their
benefit. The opportunity cost is difficult to know, but it is clearly
finite.
None of those costs are infinite.
>> ... then people will release their code under the GPL regardless of
>> whether they want to or not.
>
> Your grasp of human nature seems to be interfering with your grasp on
> reality.
Pardon? If your choices were to: a) release modifications to some piece
of GPLed software you use under the GPL (with a net benefit to you of,
say, $10: $10 for the improvements themselves, $5 for future
improvement, -$5 for philosophical reasons); b) keep them under your hat
(with a net benefit to you of $5: you win the philosophical points, but
have to maintain your improvements separately from the main codebase,
patch & build the software by hand with every release and lose future
improvements to the improvements); c) re-implement the GPLed tool
entirely (at a cost of, say, $10,000); or d) pay someone else for
reimplementing the GPL tool (say, for $1,000)--given those options, what
would you do?
In other words, people follow their cost function, modulo
irrationality. If it costs less to do A than B, and the results are the
same, then people will generally do A.
>> This is a good thing for users who will thus have source at their
>> fingertips;
>
> This is true. My grandmother was freaking out over the obtuse behavior
> of the timer key on her microwave oven, but fortunately it was open
> source so I just gave her my C++ manual and...
There's no reason that users cannot be programmers; in fact, that's
exactly what used to happen. It'd be nice for your grandmother if you
could modify the timer key on her microwave for her.
And proprietary timer key code doesn't really buy a microwave
manufacturer much if anything, even.
> Not me. I just run it thru my rocco-rossi confabulator and... oh my
> god, have I just defeated the GPL? We write a program to obfuscate
> source. The exe we ship is built from the obfuscated source, we work
> on the readable source. We ship the EXE along with the obfuscated
> source, fully complying with the GPL!
That, of course, is a violation of the GPL as obfuscated source is not
the form of source typically worked with.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Buttercup: We'll never survive.
Westley: Nonsense. You're only saying that because no-one ever has.
--The Princess Bride
A curuosity happened to me today: I've got a client which was an user
of a propietary/closed software. He encountered some limitations in
the program right after expanding his business, so called to the
software provider. Surprisingly, the provided closed. The software
cost him about $1000. We called some programmers of the applications,
but refused to send us the source code. So, bassically, my client
wasted $1000.
I talked to him about GPL alternatives, installed a GPL program, and
inmediatly he passed me a list of things that this program doesn't
have but he would need. So I contacted the authors of this software,
and they negotiated the introdution of these things into the program
for $1000.
Now the client, the original autor of the GPL'ed program, and also
myself, are happy (as I'm going to sign a contract to maintain his
computers). My client said that it is a great thing to have the source
code of the program, because if the original provider goes down and/or
refuse to make the modifications to the program, he can still contract
some other programmer, so he will never get orphan again.
This is not the first time I happen to encounter a similar situation.
If fact, ordinary computer users are usually happy with open source
programs, no matter if they payed for them or not. One repeated
preocupation about users (specially for very specific programs) are:
if my software providers goes down, what would happen to my business?
On 3 dic, 20:30, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Ken Tilton <···········@optonline.net> writes:
>
> >> .. if the cost of releasing under the GPL is less than the cost of
> >> re-implementing GPLed code,...
>
> > Oh, well, I can dream can't I?
>
> > Given that cost of the GPl is infinite, what values would it be less
> > than?
>
> The GPL's cost is not infinite, although it may be large. There's the
> monetary cost: if I planned to make money selling proprietary
> modifications to GPLed code, then using the GPL for those modifications
> would obviously cost me whatever money I would have made. That's not an
> infinite amount; it's a rather finite amount.
>
> There's the philosophical cost: regardless of whether I planned to make
> money or not, I may not agree with the GPL, and thus using it imposes a
> cost on me. That cost is not infinite either.
>
> There's the nuisance cost, which is a general form of the philosophical
> cost: I may be annoyed that the GPL forces to play ball or go home.
> That cost, too, is finite.
>
> There's the opportunity cost: I may lose patches, modifications and
> improvements from others who find the GPL's cost too high for their
> benefit. The opportunity cost is difficult to know, but it is clearly
> finite.
>
> None of those costs are infinite.
>
> >> ... then people will release their code under the GPL regardless of
> >> whether they want to or not.
>
> > Your grasp of human nature seems to be interfering with your grasp on
> > reality.
>
> Pardon? If your choices were to: a) release modifications to some piece
> of GPLed software you use under the GPL (with a net benefit to you of,
> say, $10: $10 for the improvements themselves, $5 for future
> improvement, -$5 for philosophical reasons); b) keep them under your hat
> (with a net benefit to you of $5: you win the philosophical points, but
> have to maintain your improvements separately from the main codebase,
> patch & build the software by hand with every release and lose future
> improvements to the improvements); c) re-implement the GPLed tool
> entirely (at a cost of, say, $10,000); or d) pay someone else for
> reimplementing the GPL tool (say, for $1,000)--given those options, what
> would you do?
>
> In other words, people follow their cost function, modulo
> irrationality. If it costs less to do A than B, and the results are the
> same, then people will generally do A.
>
> >> This is a good thing for users who will thus have source at their
> >> fingertips;
>
> > This is true. My grandmother was freaking out over the obtuse behavior
> > of the timer key on her microwave oven, but fortunately it was open
> > source so I just gave her my C++ manual and...
>
> There's no reason that users cannot be programmers; in fact, that's
> exactly what used to happen. It'd be nice for your grandmother if you
> could modify the timer key on her microwave for her.
>
> And proprietary timer key code doesn't really buy a microwave
> manufacturer much if anything, even.
>
> > Not me. I just run it thru my rocco-rossi confabulator and... oh my
> > god, have I just defeated the GPL? We write a program to obfuscate
> > source. The exe we ship is built from the obfuscated source, we work
> > on the readable source. We ship the EXE along with the obfuscated
> > source, fully complying with the GPL!
>
> That, of course, is a violation of the GPL as obfuscated source is not
> the form of source typically worked with.
>
> --
> Robert Uhl <http://public.xdi.org/=ruhl>
> Buttercup: We'll never survive.
> Westley: Nonsense. You're only saying that because no-one ever has.
> --The Princess Bride
On Dec 3, 2:20 pm, Javier <·······@gmail.com> wrote:
> A curuosity happened to me today: I've got a client which was an user
> of a propietary/closed software. He encountered some limitations in
> the program right after expanding his business, so called to the
> software provider. Surprisingly, the provided closed. The software
> cost him about $1000. We called some programmers of the applications,
> but refused to send us the source code. So, bassically, my client
> wasted $1000.
> I talked to him about GPL alternatives, installed a GPL program, and
> inmediatly he passed me a list of things that this program doesn't
> have but he would need. So I contacted the authors of this software,
> and they negotiated the introdution of these things into the program
> for $1000.
Javier what you're talking about is consultingware, making features
specifically for some users.
The problem with consultingware is that doesn't scale. On the other
side shrinkwrap software sells completely same thing to everybody. And
no Rockwell won't remove the airplane mission in GTA San Andreas
because I think it sucks. That's why they could sell it cheaply and
make millions.
How would you make money from shrinkwrap software under GPL?
Slobodan
On 4 dic, 00:53, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Dec 3, 2:20 pm, Javier <·······@gmail.com> wrote:
>
> > A curuosity happened to me today: I've got a client which was an user
> > of a propietary/closed software. He encountered some limitations in
> > the program right after expanding his business, so called to the
> > software provider. Surprisingly, the provided closed. The software
> > cost him about $1000. We called some programmers of the applications,
> > but refused to send us the source code. So, bassically, my client
> > wasted $1000.
> > I talked to him about GPL alternatives, installed a GPL program, and
> > inmediatly he passed me a list of things that this program doesn't
> > have but he would need. So I contacted the authors of this software,
> > and they negotiated the introdution of these things into the program
> > for $1000.
>
> Javier what you're talking about is consultingware, making features
> specifically for some users.
> The problem with consultingware is that doesn't scale. On the other
> side shrinkwrap software sells completely same thing to everybody. And
> no Rockwell won't remove the airplane mission in GTA San Andreas
> because I think it sucks. That's why they could sell it cheaply and
> make millions.
> How would you make money from shrinkwrap software under GPL?
Lot of people is making a lot of money with Linux. In fact, 80% or
higher of the people who is selling and suporting servers along the
world. And yes, lot of them are making the modifciations they need and
releasing the modification to the grand public. Everyone gains.
¿Releasing GTA San Andreas? Very easy: give the game for free, and
create an online server where people pay for playing with other
people. There are already games that use this system and they are
earning lot of money.
On Dec 4, 1:35 am, Javier <·······@gmail.com> wrote:
> On 4 dic, 00:53, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>
>
> > On Dec 3, 2:20 pm, Javier <·······@gmail.com> wrote:
>
> > > A curuosity happened to me today: I've got a client which was an user
> > > of a propietary/closed software. He encountered some limitations in
> > > the program right after expanding his business, so called to the
> > > software provider. Surprisingly, the provided closed. The software
> > > cost him about $1000. We called some programmers of the applications,
> > > but refused to send us the source code. So, bassically, my client
> > > wasted $1000.
> > > I talked to him about GPL alternatives, installed a GPL program, and
> > > inmediatly he passed me a list of things that this program doesn't
> > > have but he would need. So I contacted the authors of this software,
> > > and they negotiated the introdution of these things into the program
> > > for $1000.
>
> > Javier what you're talking about is consultingware, making features
> > specifically for some users.
> > The problem with consultingware is that doesn't scale. On the other
> > side shrinkwrap software sells completely same thing to everybody. And
> > no Rockwell won't remove the airplane mission in GTA San Andreas
> > because I think it sucks. That's why they could sell it cheaply and
> > make millions.
> > How would you make money from shrinkwrap software under GPL?
>
> Lot of people is making a lot of money with Linux. In fact, 80% or
> higher of the people who is selling and suporting servers along the
> world. And yes, lot of them are making the modifciations they need and
> releasing the modification to the grand public. Everyone gains.
> ¿Releasing GTA San Andreas? Very easy: give the game for free, and
> create an online server where people pay for playing with other
> people. There are already games that use this system and they are
> earning lot of money.
The question was how you going to make money from shrinkwrap software
under GPL?
Don't mix linux, consutingware, and software as service into this.
Read my question to Robert about the fishing software if you don't
understand what I'm trying to say and please explain how to make money
from shrinkwrap software under GPL?
Slobodan
P.S.
Sorry if my definition of shrinkwrap was foggy please read this for
betetr explanation: http://www.joelonsoftware.com/articles/SetYourPriorities.html
On 4 dic, 12:51, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Dec 4, 1:35 am, Javier <·······@gmail.com> wrote:
>
>
>
> > On 4 dic, 00:53, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > On Dec 3, 2:20 pm, Javier <·······@gmail.com> wrote:
>
> > > > A curuosity happened to me today: I've got a client which was an user
> > > > of a propietary/closed software. He encountered some limitations in
> > > > the program right after expanding his business, so called to the
> > > > software provider. Surprisingly, the provided closed. The software
> > > > cost him about $1000. We called some programmers of the applications,
> > > > but refused to send us the source code. So, bassically, my client
> > > > wasted $1000.
> > > > I talked to him about GPL alternatives, installed a GPL program, and
> > > > inmediatly he passed me a list of things that this program doesn't
> > > > have but he would need. So I contacted the authors of this software,
> > > > and they negotiated the introdution of these things into the program
> > > > for $1000.
>
> > > Javier what you're talking about is consultingware, making features
> > > specifically for some users.
> > > The problem with consultingware is that doesn't scale. On the other
> > > side shrinkwrap software sells completely same thing to everybody. And
> > > no Rockwell won't remove the airplane mission in GTA San Andreas
> > > because I think it sucks. That's why they could sell it cheaply and
> > > make millions.
> > > How would you make money from shrinkwrap software under GPL?
>
> > Lot of people is making a lot of money with Linux. In fact, 80% or
> > higher of the people who is selling and suporting servers along the
> > world. And yes, lot of them are making the modifciations they need and
> > releasing the modification to the grand public. Everyone gains.
> > ¿Releasing GTA San Andreas? Very easy: give the game for free, and
> > create an online server where people pay for playing with other
> > people. There are already games that use this system and they are
> > earning lot of money.
>
> The question was how you going to make money from shrinkwrap software
> under GPL?
> Don't mix linux, consutingware, and software as service into this.
> Read my question to Robert about the fishing software if you don't
> understand what I'm trying to say and please explain how to make money
> from shrinkwrap software under GPL?
I must mix "linux, consultingware, and software as service" because it
is the way to earn money with free software. There is nothing bad
about that.
You are right saying that selling "shrinkwrap" using a GPL license is
not good. But precisely what GPL is trying to avoid is "shrinkwrap"
software, because it simply do not protect the user. GPL is all about
the user, the small programmer, and consulting companies. I don't see
why this is a bad thing. It has proven to work very well along this
years.
On Dec 4, 6:13 pm, Javier <·······@gmail.com> wrote:
> On 4 dic, 12:51, Slobodan Blazeski <·················@gmail.com>
snipped
> I must mix "linux, consultingware, and software as service" because it
> is the way to earn money with free software. There is nothing bad
> about that.
I never said that there's anything bad with above but there are other
ways to earn money.
> You are right saying that selling "shrinkwrap" using a GPL license is
> not good.
Great, now we both agree that shrinkwrap software and GPL don't go
togather.
> But precisely what GPL is trying to avoid is "shrinkwrap"
> software, because it simply do not protect the user. GPL is all about
> the user, the small programmer, and consulting companies. I don't see
> why this is a bad thing. It has proven to work very well along this
> years.
SHould programmers need to create shrinkwrap or not, I feel that's
something that everybody should decide for themselve. So let's agree
to disagree on this.
kind regards
Slobodan
From: Klaus Schilling
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <87lk88qio0.fsf@web.de>
Slobodan Blazeski <·················@gmail.com> writes:
> Great, now we both agree that shrinkwrap software and GPL don't go
> togather.
Shrinkware is immoral and blasphemous.
>
> SHould programmers need to create shrinkwrap or not,
never
Klaus Schilling
On Thu, 06 Dec 2007 10:50:14 +0100, Klaus Schilling
<···············@web.de> wrote:
>Shrinkware is immoral and blasphemous.
Not to mention questionably legal in many circumstances.
George
--
for email reply remove "/" from address
On 2007-12-06 04:50:14 -0500, Klaus Schilling <···············@web.de> said:
> Shrinkware is immoral and blasphemous.
Excellent choice of words, since free software is indeed a religion for many.
Javier <·······@gmail.com> writes:
> This is not the first time I happen to encounter a similar situation.
> If fact, ordinary computer users are usually happy with open source
> programs, no matter if they payed for them or not. One repeated
> preocupation about users (specially for very specific programs) are:
> if my software providers goes down, what would happen to my business?
This has way more implications for the client than you showed him:
1. General Liabality Issues
2. Copyright Protection Issues
3. Archiving issues caused by Product Liability
As you are passing on the details of How Stuff Works the client no
longer is able to claim that he has not been aware of a certain
features (or bugs) in case of legal action from either side - even from
the client's clients' side (Gosh - do I have these apostrophes right
?). This means you are taking away the ability to claim amends for
such damage from you, the original provider or seller of the software.
Furthermore, if you do not explicity point this out to your client,
then you are open for prosecution of fraud - it is your obligation to
make these consequences known to your client. Moreover, to cover your
own ass, it is common business practice to have a paper signed stating
the fact that your client explicitely accepts these conditions.
Also, as to the second point, the client is now holder of copyright
protected documents for which he assumes responsibiliyt to abide the
copyright protection within his scope and reach. Is your client aware
of that?
The third point might be the one of highest risk for your client and
relates to the first and second points. If any personal injury follows
from usage of the software - either directly or indirectly - then the
holder of the software source code is part of the liability
chain. That chain stops at the first holder of the source code - your
client. As pointed out above it is the client's responsibility not
only to receive the software source code but he then also assumes
responsibulity for the correctness of function os that software. That
fact my cost millions of bucks - and it's not even sure if any
insurance will cover that cost because it was an act of negligence to
accept the software source code.
Curious what most of my customers do when presented with papers
covering these details? "No, thanks, we don't want the source code." ...
Beyond these legal issues it still is a main task of any client to
analyze a supplier's stability. It is his risk to take that one
supplier. Doing business means doing it right - not necessarily fast
and certainly not sloppy.
I have been personally involved in a multi million EUR product
liability case on the supplier side. Man, these law cases are no fun
and they immediately turn into personal matters.
Anyone selling or passing on GPL'ed / free / open software in the form
of source code should think twice and cover your ass bloody well.
Me, I am not so much a fan of handing out software source code. Jail
is way to close here.
Frank
On 4 dic, 14:48, Frank Goenninger DG1SBG <·············@nomail.org>
wrote:
> Javier <·······@gmail.com> writes:
> > This is not the first time I happen to encounter a similar situation.
> > If fact, ordinary computer users are usually happy with open source
> > programs, no matter if they payed for them or not. One repeated
> > preocupation about users (specially for very specific programs) are:
> > if my software providers goes down, what would happen to my business?
>
> This has way more implications for the client than you showed him:
>
> 1. General Liabality Issues
> 2. Copyright Protection Issues
> 3. Archiving issues caused by Product Liability
>
> As you are passing on the details of How Stuff Works the client no
> longer is able to claim that he has not been aware of a certain
> features (or bugs) in case of legal action from either side - even from
> the client's clients' side (Gosh - do I have these apostrophes right
> ?). This means you are taking away the ability to claim amends for
> such damage from you, the original provider or seller of the software.
>
> Furthermore, if you do not explicity point this out to your client,
> then you are open for prosecution of fraud - it is your obligation to
> make these consequences known to your client. Moreover, to cover your
> own ass, it is common business practice to have a paper signed stating
> the fact that your client explicitely accepts these conditions.
I think I don't fully understand this. By law, if you provide a
service to your client, and, because he paid for that service, you
must provide a guaranty, too. In Spain (and probably the rest of
Europe), that guaranty must be of at least 2 years.
Note: the guaranty is about the service. If in your contract you
specify that certain things are going to be added to a program X, the
the guaranty is about such things.
And you of course can provide a formal guaranty and/or support. Most
clients would like to have it.
> Also, as to the second point, the client is now holder of copyright
> protected documents for which he assumes responsibiliyt to abide the
> copyright protection within his scope and reach. Is your client aware
> of that?
Yes. And as stated above, you, as a professional and independent
programmer, must still provide a guaranty to the service you have sold
to the client, even if you don't hold the copyright of the software.
> The third point might be the one of highest risk for your client and
> relates to the first and second points. If any personal injury follows
> from usage of the software - either directly or indirectly - then the
> holder of the software source code is part of the liability
> chain.
I don't think so. Because:
1.-If the client is the holder of the source code, it does not mean
that he is responsible of whatever injuries follows from the usage of
the software. For example, if an architect presents to you a sketch of
your future house, and sells it to you, it doesn't mean that he is not
ever responsible for injuries caused to you by a bad designed house.
He would not be responsible if you made any change to the final house
not present in the sketch. The same with software: only if you made a
significant change to the source code, the service provider (the
programmer) can avoid the guaranty about the service he sold.
> That chain stops at the first holder of the source code - your
> client. As pointed out above it is the client's responsibility not
> only to receive the software source code but he then also assumes
> responsibulity for the correctness of function os that software.
He is not in obligation of assuming responsibility about the service
you provided to him.
> That
> fact my cost millions of bucks - and it's not even sure if any
> insurance will cover that cost because it was an act of negligence to
> accept the software source code.
>
> Curious what most of my customers do when presented with papers
> covering these details? "No, thanks, we don't want the source code." ...
>
> Beyond these legal issues it still is a main task of any client to
> analyze a supplier's stability. It is his risk to take that one
> supplier. Doing business means doing it right - not necessarily fast
> and certainly not sloppy.
>
> I have been personally involved in a multi million EUR product
> liability case on the supplier side. Man, these law cases are no fun
> and they immediately turn into personal matters.
Actually, "multi million EUR products" liability are happening with
lot of things, including proprietary software.
> Anyone selling or passing on GPL'ed / free / open software in the form
> of source code should think twice and cover your ass bloody well.
Your ass is not going to be better covered using not GPL'ed software.
If fact, you are in dangerous of having a software which is limited,
bug filled, and having no possibility to rescue it in the case that
the provider disappears or diminish of assisting you or just charging
an amount of money which is abusive.
From: Frank Goenninger DG1SBG
Subject: OT: Contractual issues - Was: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <lz1wa2cl6l.fsf_-_@pcsde001.de.goenninger.net>
Javier <·······@gmail.com> writes:
> On 4 dic, 14:48, Frank Goenninger DG1SBG <·············@nomail.org>
> wrote:
>> Javier <·······@gmail.com> writes:
>> > This is not the first time I happen to encounter a similar situation.
>> > If fact, ordinary computer users are usually happy with open source
>> > programs, no matter if they payed for them or not. One repeated
>> > preocupation about users (specially for very specific programs) are:
>> > if my software providers goes down, what would happen to my business?
>>
>> This has way more implications for the client than you showed him:
>>
>> 1. General Liabality Issues
>> 2. Copyright Protection Issues
>> 3. Archiving issues caused by Product Liability
>>
>> As you are passing on the details of How Stuff Works the client no
>> longer is able to claim that he has not been aware of a certain
>> features (or bugs) in case of legal action from either side - even from
>> the client's clients' side (Gosh - do I have these apostrophes right
>> ?). This means you are taking away the ability to claim amends for
>> such damage from you, the original provider or seller of the software.
>>
>> Furthermore, if you do not explicity point this out to your client,
>> then you are open for prosecution of fraud - it is your obligation to
>> make these consequences known to your client. Moreover, to cover your
>> own ass, it is common business practice to have a paper signed stating
>> the fact that your client explicitely accepts these conditions.
>
> I think I don't fully understand this. By law, if you provide a
> service to your client, and, because he paid for that service, you
> must provide a guaranty, too.
Actually this only holds "if not defined and agreed-upon otherwise"
(legalese) - according to EU law you are free to define deviating
agreements with your client based on mutual agreement.
I always try to cut this down to no more than 6 months. Warranty,
btw. is a completely different from liability and indemnification.
> In Spain (and probably the rest of
> Europe), that guaranty must be of at least 2 years.
> Note: the guaranty is about the service.
This is only true if you explicetly exclude the UN Convention on
Contracts. International business (and EU considers any Internet
business - even if it's only the pure delivery of the "product").
Which brings us to the definition of Service vs Product and Service
Contract vs Product Sale Contract and the distinction of which
liability, indemnification, and warranty responsibilities are
applicable. (No, I'm not going into the details here - other lawyers
might want to make money out of that ;-)
> If in your contract you
> specify that certain things are going to be added to a program X, the
> the guaranty is about such things.
Not withoit explicitely stating so. Because, legally, adding features
to a product creates a new product in itself.
> And you of course can provide a formal guaranty and/or support. Most
> clients would like to have it.
Of course. Not defining the scope of the warranty (guarantuee is not
the same as warranty - a fine distinction that is worth being aware of
when being the seller/supplier of a service or product) is called
Gross Negligence in any Basel II-based Risk Assessment...
>> Also, as to the second point, the client is now holder of copyright
>> protected documents for which he assumes responsibiliyt to abide the
>> copyright protection within his scope and reach. Is your client aware
>> of that?
>
> Yes. And as stated above, you, as a professional and independent
> programmer, must still provide a guaranty to the service you have sold
> to the client, even if you don't hold the copyright of the software.
True.
>> The third point might be the one of highest risk for your client and
>> relates to the first and second points. If any personal injury follows
>> from usage of the software - either directly or indirectly - then the
>> holder of the software source code is part of the liability
>> chain.
>
> I don't think so. Because:
>
> 1.-If the client is the holder of the source code, it does not mean
> that he is responsible of whatever injuries follows from the usage of
> the software.
That is true if you are not defining a transfer of perils. Something
you really want to do as a supplier.
> For example, if an architect presents to you a sketch of
> your future house, and sells it to you, it doesn't mean that he is not
> ever responsible for injuries caused to you by a bad designed house.
You might want to check recent contracts from architects on that
point. You might be surprised.
> He would not be responsible if you made any change to the final house
> not present in the sketch.
Not true, really. But hey, that requires a whole new level of
details.
> The same with software: only if you made a
> significant change to the source code, the service provider (the
> programmer) can avoid the guaranty about the service he sold.
Not true. As soon as you deliver the source code it may be no more
taceable who actually introduced a bug. That is just one reason why -
when delivering source code - you will want to print out the whole
source code and initial each and every page on two copies...
>> That chain stops at the first holder of the source code - your
>> client. As pointed out above it is the client's responsibility not
>> only to receive the software source code but he then also assumes
>> responsibulity for the correctness of function os that software.
>
> He is not in obligation of assuming responsibility about the service
> you provided to him.
It's not about the service. When delivering software you are
delivering a service but a product. That product gets used - in ways
that may not be intended by you. Normal phrasing states "if used in
ways not expressed and agreed-upon on a mutual bases Supplier is not
to be made liable ... blabla..." !
>> That
>> fact my cost millions of bucks - and it's not even sure if any
>> insurance will cover that cost because it was an act of negligence to
>> accept the software source code.
>>
>> Curious what most of my customers do when presented with papers
>> covering these details? "No, thanks, we don't want the source code." ...
>>
>> Beyond these legal issues it still is a main task of any client to
>> analyze a supplier's stability. It is his risk to take that one
>> supplier. Doing business means doing it right - not necessarily fast
>> and certainly not sloppy.
>>
>> I have been personally involved in a multi million EUR product
>> liability case on the supplier side. Man, these law cases are no fun
>> and they immediately turn into personal matters.
>
> Actually, "multi million EUR products" liability are happening with
> lot of things, including proprietary software.
Exactly. The point is that with proprietary software there's a clear
definition and up-front awareness of which risk is taken by which
side. That's what contracts are about - risk avoidance and risk sharing.
>
>> Anyone selling or passing on GPL'ed / free / open software in the form
>> of source code should think twice and cover your ass bloody well.
>
> Your ass is not going to be better covered using not GPL'ed software.
> If fact, you are in dangerous of having a software which is limited,
> bug filled, and having no possibility to rescue it in the case that
> the provider disappears or diminish of assisting you or just charging
> an amount of money which is abusive.
Assuming that you have complete control over open source software is
an illusion. I know only one category of organization in this world
who does software testing with 100% code coverage and is actually
documenting this - those that don't have a chance to fix bugs because
the object carrying the software is leaving our solar system...
Cheers
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
In order to maintain this discussion short, I'm going to cut off all
the things I consider less relevant:
On 4 dic, 20:30, Frank Goenninger DG1SBG <·············@nomail.org>
wrote:
> > I think I don't fully understand this. By law, if you provide a
> > service to your client, and, because he paid for that service, you
> > must provide a guaranty, too.
>
> Actually this only holds "if not defined and agreed-upon otherwise"
1.- Sure, but if you are going to sell free software, your customer is
not going to pay you if you do not provide him a guaranty.
2.- This issue happens equally with proprietary software.
> > The same with software: only if you made a
> > significant change to the source code, the service provider (the
> > programmer) can avoid the guaranty about the service he sold.
>
> Not true. As soon as you deliver the source code it may be no more
> taceable who actually introduced a bug. That is just one reason why -
> when delivering source code - you will want to print out the whole
> source code and initial each and every page on two copies...
Yes, it might be. When you provide the source code, it is easy to
distinguish between different versions. For example, you can provide a
CDROM with the original version. If the user truncates the original
source you provided to him, then he cannot argue that you are
responsible for nothing.
> It's not about the service. When delivering software you are
> delivering a service but a product.
Not necesarely. You can deliver the service of modifying the program
he uses, whose copyright holder may be even someone else.
> Assuming that you have complete control over open source software is
> an illusion.
You don't need so. Just need control of whatever parts are relevant.
Better on: assuming that you have even some little control over closed
software is the grand illusion. The only thing you can do when you
have a problem with both the program and the provider, is to go to
tribunals. And we all know the hell is that.
With open source, you've got at least the source code, and the
possibility to contract someone competent to modify it.
From: Frank Goenninger DG1SBG
Subject: Re: OT: Contractual issues - Was: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <lzir3dto7y.fsf@pcsde001.de.goenninger.net>
Javier <·······@gmail.com> writes:
> In order to maintain this discussion short, I'm going to cut off all
> the things I consider less relevant:
That's part of the problem, actually - every single word and its place
in a paragraph has its own, sometimes different, meaning in such
"discussions" on legal issues.
But:
>
> On 4 dic, 20:30, Frank Goenninger DG1SBG <·············@nomail.org>
> wrote:
>> > I think I don't fully understand this. By law, if you provide a
>> > service to your client, and, because he paid for that service, you
>> > must provide a guaranty, too.
>>
>> Actually this only holds "if not defined and agreed-upon otherwise"
>
> 1.- Sure, but if you are going to sell free software, your customer is
> not going to pay you if you do not provide him a guaranty.
If you have a product then yes, that is true. For a service customers
often are more than happy to not pay for warranty (not guarantuee)
costs. It is part of the selling / negotiation phase to make these
costs transparent. As stated in another post you as the supplier
certainly want to define the scope (in terms of functionality and
time) for your warranty. As warranty services are oftentimes (but not
necessarily in every case) free of charge for the client you have to
calculate these costs (usually by doing a risk assessment and weighing
risks by probability and financial impact) into your service
pricing. Not doing so killed way too many companies...
> 2.- This issue happens equally with proprietary software.
>
>> > The same with software: only if you made a
>> > significant change to the source code, the service provider (the
>> > programmer) can avoid the guaranty about the service he sold.
>>
>> Not true. As soon as you deliver the source code it may be no more
>> taceable who actually introduced a bug. That is just one reason why -
>> when delivering source code - you will want to print out the whole
>> source code and initial each and every page on two copies...
>
>
> Yes, it might be. When you provide the source code, it is easy to
> distinguish between different versions. For example, you can provide a
> CDROM with the original version.
Oh - CD-ROMs as any other non-paper media has an astonishingly good
ability to vanish into nirwana just the moment you need it. Of course
your client never has received any such CD-ROM - or so he
claims. Because, even if you have the CD-ROM, the client will state he
received another one - with different contents.
This is not about being fair - this is business.
> If the user truncates the original
> source you provided to him, then he cannot argue that you are
> responsible for nothing.
>
>> It's not about the service. When delivering software you are
>> delivering a service but a product.
>
> Not necesarely. You can deliver the service of modifying the program
> he uses, whose copyright holder may be even someone else.
Which opens up a whole new set of challenges: You will need written
permission of the original copyright holder to distribute her work.
I will repeat what I said here once again:
When you add a feature or functionality to an existing product or
software you are in fact (legal interpretation) creating a NEW
PRODUCT for which you assume full responsibility (read: liability,
indemnification, guarantuee, warranty).
>> Assuming that you have complete control over open source software is
>> an illusion.
>
> You don't need so. Just need control of whatever parts are relevant.
> Better on: assuming that you have even some little control over closed
> software is the grand illusion.
No: I *know* I don't have control. This is why I am preparing myself
against me being hold responsible for those parts that I did not
create - How? Easy: Get a contract with your supplier!
> The only thing you can do when you
> have a problem with both the program and the provider, is to go to
> tribunals. And we all know the hell is that.
Yes. That is why there is Risk Mitigation Planning being part of being
a full business person. If you are a One Man Show - your own risk. If
you are running a company with employees depending on you ... I
consider myself responsible for those ...
> With open source, you've got at least the source code, and the
> possibility to contract someone competent to modify it.
True. That might make it easier to Fix The Bug. Ever read 500 k LoC of
C of foreign code trying to understand what the hell that piece of
sh*t really does? Open source. Easy? No. Low effort? 60 days effort to
get it done in this one case. 30 days * 2 people's salaries + loss of
revenues due to assigning those 2 people to this task. Yes - it is a
lot of money.
Puh - ok. Enough on that one ;-) Thanks for the chat, Javier.
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
On 5 dic, 11:44, Frank Goenninger DG1SBG <·············@nomail.org>
wrote:
> > With open source, you've got at least the source code, and the
> > possibility to contract someone competent to modify it.
>
> True. That might make it easier to Fix The Bug. Ever read 500 k LoC of
> C of foreign code trying to understand what the hell that piece of
> sh*t really does? Open source. Easy? No. Low effort? 60 days effort to
> get it done in this one case. 30 days * 2 people's salaries + loss of
> revenues due to assigning those 2 people to this task. Yes - it is a
> lot of money.
You are assuming too much:
1.- That open source programs are difficult to understand, everyone of
them, which is not right.
2.- That it might get 60 days to make a modification, which is not
right (it might take 2 hours, 2 days, 2 months or 2 years).
3.- That even making such modification, it will cost more than buying
a comercial product.
4.- That getting the modification from your closed software provider
is cheap.
5.- That your closed software provider will be at your disposal for
making such modifications.
6.- That you are safe charging the responsibility on your closed
software provider. Windows is a great example. You are not safe using
it (Linux is much safer, but not perfect), and Microsoft will ever
respond to your requirement? They will not. Now try to demand them,
and see what's going to happen... you'll lose for sure.
From: Frank Goenninger DG1SBG
Subject: Re: OT: Contractual issues - Was: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <lzir3b25bn.fsf@pcsde001.de.goenninger.net>
Javier <·······@gmail.com> writes:
> On 5 dic, 11:44, Frank Goenninger DG1SBG <·············@nomail.org>
> wrote:
>
>> > With open source, you've got at least the source code, and the
>> > possibility to contract someone competent to modify it.
>>
>> True. That might make it easier to Fix The Bug. Ever read 500 k LoC of
>> C of foreign code trying to understand what the hell that piece of
>> sh*t really does? Open source. Easy? No. Low effort? 60 days effort to
>> get it done in this one case. 30 days * 2 people's salaries + loss of
>> revenues due to assigning those 2 people to this task. Yes - it is a
>> lot of money.
>
> You are assuming too much:
>
> 1.- That open source programs are difficult to understand, everyone of
> them, which is not right.
> 2.- That it might get 60 days to make a modification, which is not
> right (it might take 2 hours, 2 days, 2 months or 2 years).
> 3.- That even making such modification, it will cost more than buying
> a comercial product.
> 4.- That getting the modification from your closed software provider
> is cheap.
> 5.- That your closed software provider will be at your disposal for
> making such modifications.
> 6.- That you are safe charging the responsibility on your closed
> software provider. Windows is a great example. You are not safe using
> it (Linux is much safer, but not perfect), and Microsoft will ever
> respond to your requirement? They will not. Now try to demand them,
> and see what's going to happen... you'll lose for sure.
And that basically reflects what is right in any case:
Depending on the scale on which you depend on others a business person
will establish the risk level and decide what decisions to take (go
open source or not) and what measures to take for risk mitigation (if
any).
It's like Lisp - depends on what you want to achieve. The tools are
there. Use them appropriately. Just don't let you fool that there is
the one and only way that fits all challenges.
Huh - I'm glad I manmage to get Lisp mentioned here again. I started
wondering which newsgroup to take this to...
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
On Tue, 4 Dec 2007 08:59:57 -0800 (PST), Javier <·······@gmail.com>
wrote:
>On 4 dic, 14:48, Frank Goenninger DG1SBG <·············@nomail.org>
>wrote:
>> Javier <·······@gmail.com> writes:
>> > This is not the first time I happen to encounter a similar situation.
>> > If fact, ordinary computer users are usually happy with open source
>> > programs, no matter if they payed for them or not. One repeated
>> > preocupation about users (specially for very specific programs) are:
>> > if my software providers goes down, what would happen to my business?
>>
>> This has way more implications for the client than you showed him:
>>
>> 1. General Liabality Issues
>> 2. Copyright Protection Issues
>> 3. Archiving issues caused by Product Liability
>>
>> As you are passing on the details of How Stuff Works the client no
>> longer is able to claim that he has not been aware of a certain
>> features (or bugs) in case of legal action from either side - even from
>> the client's clients' side (Gosh - do I have these apostrophes right
>> ?). This means you are taking away the ability to claim amends for
>> such damage from you, the original provider or seller of the software.
>>
>> Furthermore, if you do not explicity point this out to your client,
>> then you are open for prosecution of fraud - it is your obligation to
>> make these consequences known to your client. Moreover, to cover your
>> own ass, it is common business practice to have a paper signed stating
>> the fact that your client explicitely accepts these conditions.
>
>I think I don't fully understand this. By law, if you provide a
>service to your client, and, because he paid for that service, you
>must provide a guaranty, too. In Spain (and probably the rest of
>Europe), that guaranty must be of at least 2 years.
>Note: the guaranty is about the service. If in your contract you
>specify that certain things are going to be added to a program X, the
>the guaranty is about such things.
>And you of course can provide a formal guaranty and/or support. Most
>clients would like to have it.
Guarantee of service has nothing to do with your duty to inform the
client that he will be accepting certain responsibilities and
potential liabilities (e.g., abiding by the terms of the GPL) by
partaking of your services.
>> Also, as to the second point, the client is now holder of copyright
>> protected documents for which he assumes responsibiliyt to abide the
>> copyright protection within his scope and reach. Is your client aware
>> of that?
>
>Yes. And as stated above, you, as a professional and independent
>programmer, must still provide a guaranty to the service you have sold
>to the client, even if you don't hold the copyright of the software.
>> The third point might be the one of highest risk for your client and
>> relates to the first and second points. If any personal injury follows
>> from usage of the software - either directly or indirectly - then the
>> holder of the software source code is part of the liability
>> chain.
>
>I don't think so. Because:
>
>1.-If the client is the holder of the source code, it does not mean
>that he is responsible of whatever injuries follows from the usage of
>the software. For example, if an architect presents to you a sketch of
>your future house, and sells it to you, it doesn't mean that he is not
>ever responsible for injuries caused to you by a bad designed house.
>He would not be responsible if you made any change to the final house
>not present in the sketch. The same with software: only if you made a
>significant change to the source code, the service provider (the
>programmer) can avoid the guaranty about the service he sold.
That is not guaranteed. It depends on locality whether a party
injured by a product you only indirectly participated in can name you
in a damage suit. Regardless of whether the injured party can go
after you directly, the company to which you provided the code
certainly will sue you if your code is thought to have contributed to
the injury.
>> That chain stops at the first holder of the source code - your
>> client. As pointed out above it is the client's responsibility not
>> only to receive the software source code but he then also assumes
>> responsibulity for the correctness of function os that software.
>
>He is not in obligation of assuming responsibility about the service
>you provided to him.
But he *is* in the position of assuming responsibility for anything he
does with the code you provide.
>> That
>> fact my cost millions of bucks - and it's not even sure if any
>> insurance will cover that cost because it was an act of negligence to
>> accept the software source code.
>>
>> Curious what most of my customers do when presented with papers
>> covering these details? "No, thanks, we don't want the source code." ...
>>
>> Beyond these legal issues it still is a main task of any client to
>> analyze a supplier's stability. It is his risk to take that one
>> supplier. Doing business means doing it right - not necessarily fast
>> and certainly not sloppy.
>>
>> I have been personally involved in a multi million EUR product
>> liability case on the supplier side. Man, these law cases are no fun
>> and they immediately turn into personal matters.
>
>Actually, "multi million EUR products" liability are happening with
>lot of things, including proprietary software.
>
>> Anyone selling or passing on GPL'ed / free / open software in the form
>> of source code should think twice and cover your ass bloody well.
>
>Your ass is not going to be better covered using not GPL'ed software.
>If fact, you are in dangerous of having a software which is limited,
>bug filled, and having no possibility to rescue it in the case that
>the provider disappears or diminish of assisting you or just charging
>an amount of money which is abusive.
Your situation doesn't change but your client's does. In addition to
accepting liability for what he does with the code you provide, he
also accepts legal responsibility for maintaining the code you
provided, and any other code the GPL may transitively affect because
of it, under the terms of the GPL license.
You may argue that proprietary software also comes with license
restrictions ... and you would be mostly right. The difference lies
in whether the terms imposed by the GPL - which are very different
from the terms of typical proprietary licenses - are acceptable to the
client.
George
--
for email reply remove "/" from address
Robert
Imagine that you found a business opportunity making software that
helps to choose a best lure for Carp fishermans in your local lakes.
Your program operates in any cough-cough Java phone without connection
providing that you can transfer it with a blue tooth and you made a
simple protection scheme, that will stop the casual guys from copying
it( the crackers will crack it anyway}. It's a niche market but it's
worth $60 000 a year that considering your life costs will allow you
to live quite good and concentrate your programming efforts solely on
it, beside casual lisping. But that's OK becuase lisp is for hobbyists
and academics anyway who have real jobs elsewhere.
So how do you plan to make your money by releasing it under GPL when
your neighbours 15 year old teen will recompile it and give it for
free
Remember
1. You're not into consultancy by implementing features that people
want.
2. Nor you are in software as service plugging off non payers from
your web site or whatever?
3. Nor your into support business, RHEL like providing support for
your software?
4. Nor your into beggareware ?(read google ads and please donate, not
enough)
5. Nor supported by a goverment/large corporation
Please enlighten us how you gonna make money to professionally work on
this application?
Slobodan
(1) Because some people have a new phones , some have old phones, some
like menus rendered in 3d, the others doesn't have color display
phones, and the worst ones are thosewho know exactly what they want
when you sign agreements,but after you implement it, be lucky if they
pay you throw up you features never seeing from them again. If you're
not lucky maybe secong mortgage will cover legal fees.
(2) Networks sucks in the mountain lake, that has the best fishing
spots, also they want to be left alone, putting on phone to calculate
their winning lure and shut down the damn thing before it rings.
(3) The god damn application work or doesn't work, and it's not
business critical so they're not interested in 24h support. If it
doesn't work they choose some lure by chance.
{4} There are just not enough traffic for your site and your blogging
skills are modest at best
(5) Darpa/Sun/Novell doesn't give a damn about fishing. And those who
do, already found that your software makes awfull predictions for ice
fishing in Finland and underwater fishing in Aruba so you won't get a
funding.
Slobodan Blazeski <·················@gmail.com> writes:
> Robert
> Imagine that you found a business opportunity making software that
> helps to choose a best lure for Carp fishermans in your local lakes.
> Your program operates in any cough-cough Java phone without connection
> providing that you can transfer it with a blue tooth and you made a
> simple protection scheme, that will stop the casual guys from copying
> it( the crackers will crack it anyway}. It's a niche market but it's
> worth $60 000 a year that considering your life costs will allow you
> to live quite good and concentrate your programming efforts solely on
> it, beside casual lisping. But that's OK becuase lisp is for hobbyists
> and academics anyway who have real jobs elsewhere.
> So how do you plan to make your money by releasing it under GPL when
> your neighbours 15 year old teen will recompile it and give it for
> free
I don't plan to make money selling software any more than I plan to make
money as a mime: I don't consider selling software or miming to be
proper ways of making money (although of course I would never stop
someone else from trying it).
If I wrote a lure-choosing programme, I'd give it away.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Typing 'make' in a directory of fresh C++ code is just like playing
Quake. Specifically, it's like the part in Quake where you pick up
the Super Nailgun and aim it at your face. --Kevin Buhr
On Dec 5, 4:56 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > Robert
> > Imagine that you found a business opportunity making software that
> > helps to choose a best lure for Carp fishermans in your local lakes.
> > Your program operates in any cough-cough Java phone without connection
> > providing that you can transfer it with a blue tooth and you made a
> > simple protection scheme, that will stop the casual guys from copying
> > it( the crackers will crack it anyway}. It's a niche market but it's
> > worth $60 000 a year that considering your life costs will allow you
> > to live quite good and concentrate your programming efforts solely on
> > it, beside casual lisping. But that's OK becuase lisp is for hobbyists
> > and academics anyway who have real jobs elsewhere.
> > So how do you plan to make your money by releasing it under GPL when
> > your neighbours 15 year old teen will recompile it and give it for
> > free
>
> I don't plan to make money selling software any more than I plan to make
> money as a mime: I don't consider selling software or miming to be
> proper ways of making money (although of course I would never stop
> someone else from trying it).
>
> If I wrote a lure-choosing programme, I'd give it away.
So your program will be half-baked product because you won't have time
to focus on it, fishermen won't use it because they don't know Java
to fix the problems and people who do won't waste their spare time
making something that is not cool like ROR or 3d games etc.
So you didn't earn income and now you have to work for the PHB,
fishermen lost a lot of big catches, and your town lost many tourists
because only a handful of people could catch a big carpin the
mountain lake, and we at c.l.l. lost many of your helpful advices
while you're stuck doing overtime fixing bugs in undocumented code in
that sparcstation.
As I see it everybody loses, all because you were stubborn and didn't
wanted to accept the GPL doesn't work under certain conditions.
>
> --
> Robert Uhl <http://public.xdi.org/=ruhl>
> Typing 'make' in a directory of fresh C++ code is just like playing
> Quake. Specifically, it's like the part in Quake where you pick up
> the Super Nailgun and aim it at your face. --Kevin Buhr
Nice signature
cheers
slobodan
From: Sohail Somani
Subject: Off topic [was Re: Reasons to choose CLISP over other free implementations]
Date:
Message-ID: <eYp5j.21415$HH2.13001@edtnps82>
On Tue, 04 Dec 2007 20:56:55 -0700, Robert Uhl wrote:
> I don't consider selling software or miming to be
> proper ways of making money
Why? What reason could you possibly have?
--
Sohail Somani
http://uint32t.blogspot.com
From: Ken Tilton
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <XV35j.5917$Id1.4491@newsfe10.lga>
>>Not me. I just run it thru my rocco-rossi confabulator and... oh my
>>god, have I just defeated the GPL? We write a program to obfuscate
>>source. The exe we ship is built from the obfuscated source, we work
>>on the readable source. We ship the EXE along with the obfuscated
>>source, fully complying with the GPL!
>
>
> That, of course, is a violation of the GPL as obfuscated source is not
> the form of source typically worked with.
>
That is not an enforceable interpretation of "the preferred form of the
work for making modifications to it". But relax, Stallman failed, the
amount and quality of GPLed code has done nothing to create an
unstoppable infection, I was just having fun with my suggested
GPL-antidote. Which would still work, because as rocco demonstrated even
a reasonable programmer can come up with names /actively/ worse than
random character strings. I have spent a lifetime of man-years
maintining OPC where I first figured out what XXX did and then gave its
correct name, YYY. I could pop the cork on a Crystale and before it was
empty reverse come up with a mapping for a translation of my code into
something utterly inscrutable before draining the last drop. Hell, you
clowns could not work on His Kennyness's code even with Rectified Names,
what am I worried about? And another thing...
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 2, 6:01 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
>
> >> > - Using FFI will turn your application into GPLware.
>
> >> this would be an advantage of CLISP, as pointed out by R.M. Stallman.
>
> > No it won't. People who want their code under GPL will do it it
> > anyway, people who don't won't use it.
>
> Not necessarily: if the cost of releasing under the GPL is less than the
> cost of re-implementing GPLed code, then people will release their code
> under the GPL regardless of whether they want to or not.
That might be true for companies for doing a cost benefit analysis,
but companies usually keep their source proprietory. Not all of them
of course.
When it's about people, there's a lot of religiopus beliefs that won't
make such analysis. People that hate GPL, I'm one of them, won't use
it no matter what's the cost. They will use non viral lisp
implementation, or even drop lisp in favour of some other language.
Even MS can't lock everybody . GPL might be good solution sometimes,
like when applications could work at arms length but it sucks a lot of
many other times. I believe in open source, I even released some code
under boost and llgpl but I won't use anything that bullies me.
> This is a good
> thing for users who will thus have source at their fingertips; it is a
> bad thing for those who don't want to give out their source code.
if there were not proprietory software at Linux I wouldn't have a
second at Linux as desctop, because I want Compiz , which needs
propritory NVIDIA drivers, I need to watch flash with Macromedia
flash not gnash, play rm with real players, and I want my acrobat
reader and codecs to listen mp3 and watch movies. I don't give a damn
is it close or open source, as longs as the software is good. And no I
don't want to debug my programs I expect them to just work.
Slobodan
>
> --
> Robert Uhl <http://public.xdi.org/=ruhl>
> The mark of the immature man is that he wants to die nobly for a cause,
> while the mark of a mature man is that he wants to live humbly for one.
> --Wilhelm Stekel
On 3 dic, 23:53, Slobodan Blazeski <·················@gmail.com>
wrote:
> People that hate GPL, I'm one of them, won't use
> it no matter what's the cost.
Really? Read:
> if there were not proprietory software at Linux I wouldn't have a
> second at Linux as desctop, because I want Compiz , which needs
> propritory NVIDIA drivers, I need to watch flash with Macromedia
> flash not gnash, play rm with real players, and I want my acrobat
> reader and codecs to listen mp3 and watch movies. I don't give a damn
> is it close or open source, as longs as the software is good. And no I
> don't want to debug my programs I expect them to just work.
The question is: if Nvidia drivers, Flash, Acrobat Reader, and Codecs
would be released as GPL, won't you prefer using them instead of
propietary versions? (Having the same functionality, I mean).
On Dec 4, 1:28 am, Javier <·······@gmail.com> wrote:
> On 3 dic, 23:53, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > People that hate GPL, I'm one of them, won't use
> > it no matter what's the cost.
>
> Really? Read:
>
> > if there were not proprietory software at Linux I wouldn't have a
> > second at Linux as desctop, because I want Compiz , which needs
> > propritory NVIDIA drivers, I need to watch flash with Macromedia
> > flash not gnash, play rm with real players, and I want my acrobat
> > reader and codecs to listen mp3 and watch movies. I don't give a damn
> > is it close or open source, as longs as the software is good. And no I
> > don't want to debug my programs I expect them to just work.
>
> The question is: if Nvidia drivers, Flash, Acrobat Reader, and Codecs
> would be released as GPL, won't you prefer using them instead of
> propietary versions? (Having the same functionality, I mean).
I already said that's GPL is ok when you can work at arms length.
I'm fun of ubuntu, use it daily (writing this text from it) and I
recommend to all my friends, I even installed it on few of them. But
whenever working at arms length is unacceptable like GPL released
library I won't use it no matter what.
Slobodan
Slobodan Blazeski <·················@gmail.com> writes:
>
>> >> > - Using FFI will turn your application into GPLware.
>>
>> >> this would be an advantage of CLISP, as pointed out by
>> >> R.M. Stallman.
>>
>> > No it won't. People who want their code under GPL will do it it
>> > anyway, people who don't won't use it.
>>
>> Not necessarily: if the cost of releasing under the GPL is less than
>> the cost of re-implementing GPLed code, then people will release
>> their code under the GPL regardless of whether they want to or not.
>
> That might be true for companies for doing a cost benefit analysis,
> but companies usually keep their source proprietory. Not all of them
> of course.
> When it's about people, there's a lot of religiopus beliefs that won't
> make such analysis.
Yeah they do--violating those beliefs is a cost. I can pretty much
guarantee that there's a benefit large enough to outweigh that cost.
> People that hate GPL, I'm one of them, won't use it no matter what's
> the cost.
I sincerely doubt that. Everyone has his price: I do, you do, even
Richard Stallman does.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Available for immediate pickup: Industrial strength fan forced
convection heater with computer-like features. --Joe Bednorz
On Dec 5, 4:59 am, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> I can pretty much
> guarantee that there's a benefit large enough to outweigh that cost.
So did Marx.
>
> > People that hate GPL, I'm one of them, won't use it no matter what's
> > the cost.
>
> I sincerely doubt that. Everyone has his price: I do, you do, even
> Richard Stallman does.
Of course, but nobody offered me money to use GPL.
>
> --
> Robert Uhl <http://public.xdi.org/=ruhl>
> Available for immediate pickup: Industrial strength fan forced
> convection heater with computer-like features. --Joe Bednorz
On Nov 28, 1:56 pm, Javier <·······@gmail.com> wrote:
> - Much faster compiler speed, which is nice for big projects.
This has not been my experience at all. With a lot of my work, CLisp
is orders of magnitude slower compiling than SBCL. Furthermore, it's
orders of magnitude slower running the code, whether interpreted or
compiled. (To be fair, I'm still using 2.40, but that's only because
the upgrade using Macports fails to compile.)
I have other quibbles with CLisp. One of them is that with Slime, the
argument names that show up using slime-autodoc mode are nondescript
and not helpful. I often see "arg0", "arg1", etc. I use this a lot
and it's annoying when I forget the order of arguments to things like
NTH and ELT, for example.
I can't say I really enjoy using CLisp, to be quite honest. Mind you,
when I'm at a terminal (which is rare), it's considerably better to
use than most others.
On 29 nov, 01:59, Geoff Wozniak <·············@gmail.com> wrote:
> On Nov 28, 1:56 pm, Javier <·······@gmail.com> wrote:
>
> > - Much faster compiler speed, which is nice for big projects.
>
> This has not been my experience at all. With a lot of my work, CLisp
> is orders of magnitude slower compiling than SBCL. Furthermore, it's
> orders of magnitude slower running the code, whether interpreted or
> compiled. (To be fair, I'm still using 2.40, but that's only because
> the upgrade using Macports fails to compile.)
Well, in my experience, and with this graphs:
http://sbcl.boinkor.net/bench/
Here you can see that CLISP is still about 2x faster than SBCL
compiling things, and not only compiling, but a lot of other useful
stuff, like defining CLOSS classes and instantiating them, and
printing strings (useful for web serving).
Of course, SBCL is much faster for fixnum and float operations. But if
your application do not rely very much on arithmetic operations, CLISP
is a very capable Lisp implementation. This, and the fact that CLISP
needs only a portion of memory to execute the same program as SBCL,
should make everybody to consider using CLISP for certain problems.
One more thing: starting Slime is faster when you use CLISP. Not very
important, but an indicative of how fast is CLISP compiling and
loading compiled files.
> I have other quibbles with CLisp. One of them is that with Slime, the
> argument names that show up using slime-autodoc mode are nondescript
> and not helpful. I often see "arg0", "arg1", etc. I use this a lot
> and it's annoying when I forget the order of arguments to things like
> NTH and ELT, for example.
Yes, you're right. This is annoying, but not so much as to decide to
use SBCL over CLISP, I think. At the end, you are used to this.
> I can't say I really enjoy using CLisp, to be quite honest. Mind you,
> when I'm at a terminal (which is rare), it's considerably better to
> use than most others.
Consider CLISP for web, string manipulation, and CLOS. It is a very
capable Lisp distribution for these areas.
On Nov 28, 8:34 pm, Javier <·······@gmail.com> wrote:
> http://sbcl.boinkor.net/bench/
>
> Here you can see that CLISP is still about 2x faster than SBCL
> compiling things, and not only compiling, but a lot of other useful
> stuff, like defining CLOSS classes and instantiating them, and
> printing strings (useful for web serving).
Hrm... I'll have to take a closer look at those CLOS benchmarks,
although I can't help noticing that SBCL is much faster with method
calls. My programs tend to call methods a lot more than they define
classes. As for instantiation, it seems CLisp is much slower on
simple-instantiate than SBCL. I'm curious what the benchmark code
is. (I didn't see links to code anywhere on that page.)
> One more thing: starting Slime is faster when you use CLISP. Not very
> important, but an indicative of how fast is CLISP compiling and
> loading compiled files.
It only says how fast it is at compiling and loading the files for
Slime. I've had some files consistently compile ten times faster with
SBCL than Clisp, although I'll grant I may be working on outlier
cases.
> Consider CLISP for web, string manipulation, and CLOS. It is a very
> capable Lisp distribution for these areas.
I doubt the CLOS claims, but if I end up doing work in those areas, I
won't rule it out. Still, CLisp hasn't exactly worked up a good
rapport with me, so I can't say I have a lot of confidence in it.
That, and I've become enamoured with Allegro CL of late.
Geoff Wozniak <·············@gmail.com> writes:
> Hrm... I'll have to take a closer look at those CLOS benchmarks,
> although I can't help noticing that SBCL is much faster with method
> calls. My programs tend to call methods a lot more than they define
> classes. As for instantiation, it seems CLisp is much slower on
> simple-instantiate than SBCL. I'm curious what the benchmark code
> is. (I didn't see links to code anywhere on that page.)
http://www.cliki.net/cl-bench
--
Juho Snellman
From: Holger Schauer
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <yxzhcj5xshy.fsf@gmx.de>
On 5202 September 1993, Javier wrote:
> Well, in my experience, and with this graphs:
> http://sbcl.boinkor.net/bench/
Very interesting, I haven't seen those before.
> Here you can see that CLISP is still about 2x faster than SBCL
> compiling things, and not only compiling, but a lot of other useful
> stuff, like defining CLOSS classes and instantiating them, and
> printing strings (useful for web serving).
This is only one half of the truth. The other half is where the
benchmarks shows Clisp to be a lot slower.
> Of course, SBCL is much faster for fixnum and float operations. But if
> your application do not rely very much on arithmetic operations, CLISP
> is a very capable Lisp implementation.
I don't doubt the correctness of your conclusion, but in combination
with your precondition you give a misleading picture of the situation,
at least when you cite the above mentioned benchmark as the source of
your conclusion. In those benchmarks, Clisp seems to be slower than
CMUCL or SBCL on a variety of tasks that have nothing to do with
arithmetic operations. For instance, hashing seems to be considerably
slower, regardless whether you're hashing integers or strings. As
another example, CLOS methodcalls also seems to be significantly
slower.
> Consider CLISP for web, string manipulation, and CLOS. It is a very
> capable Lisp distribution for these areas.
Looking at the benchmark, I have considerable doubts to follow your
recommendation. Instead I would follow the usual advice and use
whatever I'm used to or feel most comfortabl with until I run into
some problem performance wise and defer premature optimization until
it's necessary.
Holger
--
--- http://hillview.bugwriter.net/ ---
"Ich hasse es, mich nachts an Warmes zu schmiegen, um morgens auf
platter Katze zu erwachen."
-- Cristalle Sabon in de.alt.sysadmin.recovery
Holger Schauer <··············@gmx.de> writes:
> On 5202 September 1993, Javier wrote:
>> Well, in my experience, and with this graphs:
>> http://sbcl.boinkor.net/bench/
>
> Very interesting, I haven't seen those before.
>
>> Here you can see that CLISP is still about 2x faster than SBCL
>> compiling things, and not only compiling, but a lot of other useful
>> stuff, like defining CLOSS classes and instantiating them, and
>> printing strings (useful for web serving).
>
> This is only one half of the truth. The other half is where the
> benchmarks shows Clisp to be a lot slower.
The thing is, this isn't "six of one, half a dozen of the other."
If your use cases bias towards:
a) Those where CLISP "plays better," then you'll tend to find it looks
a lot better than SBCL.
b) Those where CLISP "plays worse," then the opposite will obviously
be true.
But it is by no means obvious how things are likely to bias.
Mind you, I've found CLISP somewhat faster when playing with those
applications I have been playing with, which have tended towards
string manipulation, which is an evident strength.
Evidently, I haven't been doing stuff where it has been dreadfully slower.
--
output = ("cbbrowne" ·@" "acm.org")
http://linuxdatabases.info/info/multiplexor.html
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)." -- Matt Welsh
From: Holger Schauer
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <yxzbq96u5vd.fsf@gmx.de>
On 5206 September 1993, Christopher Browne wrote:
> Holger Schauer <··············@gmx.de> writes:
>> This is only one half of the truth. The other half is where the
>> benchmarks shows Clisp to be a lot slower.
> The thing is, this isn't "six of one, half a dozen of the other."
> If your use cases bias towards: [...]
As you deleted a lot of context, I just want to make it clear that I
don't have a bias whatsoever but that I was merely pointing out a
problem in Javiers claim. I actually haven't used clisp really.
Holger
--
--- http://hillview.bugwriter.net/ ---
"These kind of things come and go, only Emacs persists. Whether the
next hot desktop will be BeOS, Aqua, Berlin, or something else, I
know that my Emacs skills will be as useful as they are today."
-- Per Abrahamsen in comp.emacs
Javier <·······@gmail.com> writes:
> Well, in my experience, and with this graphs:
>
> http://sbcl.boinkor.net/bench/
>
> Here you can see that CLISP is still about 2x faster than SBCL
> compiling things, and not only compiling, but a lot of other useful
> stuff, like defining CLOSS classes and instantiating them, and
> printing strings (useful for web serving).
You are to some extent misinterpreting the results by implying that
the names of the tests say exactly what is being tested. For example
the CLOS/instantiate test actually tests the speed of the rather rare
(make-instance variable) while CLOS/simple-instantiate tests
(make-instance 'constant), a vastly more common case.
Or for a couple of more neutral examples:
* The methodcall benchmark does some arithmetic inside the methods that
the benchmark defines, to ensure that clever CLOS implementations can't
optimize the dispatch away completely. When run with the default
parameters, some of that arithmetic quickly overflows into bignums.
Somebody looking at the name of the test might think that it's
testing mainly the speed of method dispatch, but if the method
dispatch is quick enough (as in SBCL), it actually becomes as much
a bignum benchmark as a method dispatch one! This effect is
prominent enough that when Christophe Rhodes wrote a paper on
automatic classification the cl-bench benchmarks based on the
results, CLOS/methodcall fell into the same cluster with the tests
that were explicitly benchmarking bignums.
* In the SEARCH-SEQUENCE benchmark SBCL does the actual searching quickly
enough that more time is spent initializing the array with a loop like
(dotimes (i (length arrays) (setf (aref array i)) (mod i 1000))) than
doing the actual search. So the test isn't really benchmarking SEARCH,
it's benchmarking MOD on two fixnums.
I also don't really understand where on that page you're seeing
anything that suggests clisp is 2x faster at printing strings.
> Of course, SBCL is much faster for fixnum and float operations.
And here you are grossly misrepresenting the results, by implying that
SBCL is only faster than clisp for benchmarks that test fixnum/float
performance.
> Consider CLISP for web, string manipulation, and CLOS. It is a very
> capable Lisp distribution for these areas.
I wouldn't advise people to make decisions on what implementation to
use based just on benchmark numbers, without understanding what the
benchmarks are actually doing, and thinking about how those benchmarks
relate to their own use. For example, I expect that people interested
in CLOS performance would care a lot more about method call
performance than the speed of defining classes...
--
Juho Snellman
On 29 nov, 13:46, Juho Snellman <······@iki.fi> wrote:
> > Of course, SBCL is much faster for fixnum and float operations.
>
> And here you are grossly misrepresenting the results, by implying that
> SBCL is only faster than clisp for benchmarks that test fixnum/float
> performance.
I never said is ONLY faster htan clisp.
> > Consider CLISP for web, string manipulation, and CLOS. It is a very
> > capable Lisp distribution for these areas.
>
> I wouldn't advise people to make decisions on what implementation to
> use
I don't. I said "consider".
> I expect that people interested
> in CLOS performance would care a lot more about method call
> performance than the speed of defining classes...
Basically, this depends on the kind of CLOS program you are doing. For
example, my program is doing millions of instantiations, and much less
method calls. I wouldn't advise people to make decisions on what
implementation to not use, without understanding what the program of
everyone are actually doing. ;)
Javier <·······@gmail.com> writes:
> Basically, this depends on the kind of CLOS program you are doing. For
> example, my program is doing millions of instantiations, and much less
> method calls.
I will again point out that the common case of giving a constant class
name to MAKE-INSTANCE is much faster in SBCL:
(defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg :z)))
(defun foo () (dotimes (i (expt 2 20)) (make-instance 'a :x 1 :y 2 :z 3)))
(compile 'foo)
(time (foo))
SBCL -> 0.089s
clisp -> 0.91s
And again, the case with an variable class name is much slower in
SBCL, but exactly the same speed in clisp. Maybe this is what you're
doing, and if so, clisp would be the faster choice for you. But it
seems pretty unreasonable for you to unconditionally claim that
instantiation of CLOS objects is slower in SBCL when the common case
is much faster.
(The code path for the non-constant cases of MAKE-INSTANCE is very
much unoptimized in SBCL. That it has not been optimized is probably
due to few people using that case in practice. At least I've never had
anyone report MAKE-INSTANCE with non-constant class or initarg names
as a bottleneck in their program before this.)
> I wouldn't advise people to make decisions on what
> implementation to not use, without understanding what the program of
> everyone are actually doing. ;)
Luckily I didn't advise people on what implementations they should not
use. There are good reasons to use clisp. I'm just saying that the
benchmarks you're misinterpreting aren't such reasons.
--
Juho Snellman
From: Dimiter "malkia" Stanev
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <5r90o9F1328l2U1@mid.individual.net>
Juho Snellman wrote:
> Javier <·······@gmail.com> writes:
>> Basically, this depends on the kind of CLOS program you are doing. For
>> example, my program is doing millions of instantiations, and much less
>> method calls.
>
> I will again point out that the common case of giving a constant class
> name to MAKE-INSTANCE is much faster in SBCL:
>
> (defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg :z)))
> (defun foo () (dotimes (i (expt 2 20)) (make-instance 'a :x 1 :y 2 :z 3)))
> (compile 'foo)
> (time (foo))
>
> SBCL -> 0.089s
> clisp -> 0.91s
>
> And again, the case with an variable class name is much slower in
> SBCL, but exactly the same speed in clisp. Maybe this is what you're
> doing, and if so, clisp would be the faster choice for you. But it
> seems pretty unreasonable for you to unconditionally claim that
> instantiation of CLOS objects is slower in SBCL when the common case
> is much faster.
>
> (The code path for the non-constant cases of MAKE-INSTANCE is very
> much unoptimized in SBCL. That it has not been optimized is probably
> due to few people using that case in practice. At least I've never had
> anyone report MAKE-INSTANCE with non-constant class or initarg names
> as a bottleneck in their program before this.)
>
>> I wouldn't advise people to make decisions on what
>> implementation to not use, without understanding what the program of
>> everyone are actually doing. ;)
>
> Luckily I didn't advise people on what implementations they should not
> use. There are good reasons to use clisp. I'm just saying that the
> benchmarks you're misinterpreting aren't such reasons.
>
Gah, SBCL didn't work on Windows:
C:\>which sbcl
/cygdrive/c/Program Files/Steel Bank Common Lisp/1.0.9/sbcl
C:\>sbcl
This is SBCL 1.0.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
This is experimental prerelease support for the Windows platform: use
at your own risk. "Your Kitten of Death awaits!"
* (defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg :z)))
#<STANDARD-CLASS A>
* (defun foo () (dotimes (i (expt 2 20)) (make-instance 'a :x 1 :y 2
:z 3)))
FOO
* (compile 'foo)
FOO
NIL
NIL
* (time (foo))
fatal error encountered in SBCL pid 6792:
GC invariant lost, file "gencgc.c", line 832
LDB monitor
ldb>
-------------------------------------------------------------------------
C:\>which clisp
/usr/bin/clisp
(cygwin clisp)
C:\>CLISP
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg :z)))
#<STANDARD-CLASS A> (defun foo () (dotimes (i (expt 2 20))
(make-instance 'a :x 1 :y 2 :z 3)))
[2]> (defun foo () (dotimes (i (expt 2 20)) (make-instance 'a :x 1 :y
2 :z 3)))
FOO
[3]> (compile 'foo)
FOO ;
NIL ;
NIL
[4]> (time (foo))
Real time: 1.715 sec.
Run time: 1.703 sec.
Space: 75499920 Bytes
GC: 143, GC time: 0.924 sec.
NIL
[5]> (lisp-implementation-version)
"2.41 (2006-10-13) (built on ATGRZWN502840.avl01.avlcorp.lan [127.0.0.1])"
---------------------------------------------------------------------------
NON-CYGWIN CLISP
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg :z)))
#<STANDARD-CLASS A>
[2]> (defun foo () (dotimes (i (expt 2 20)) (make-instance 'a :x 1 :y
2 :z 3)))
FOO
[3]> (compile 'foo)
FOO ;
NIL ;
NIL
[4]> (time (foo))
Real time: 0.8593695 sec.
Run time: 0.859375 sec.
Space: 75499920 Bytes
GC: 144, GC time: 0.21875 sec.
[5]> (lisp-implementation-version)
"2.41 (2006-10-13) (built on Driven [192.168.0.4])"
----------------------------------------------------------------------------
LISPWORKS 5.0.2 PROFESSIONAL (Windows 32bit XP)
CL-USER 1 > (defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg
:z)))
#<STANDARD-CLASS A 200DE89B>
CL-USER 2 > (defun foo () (dotimes (i (expt 2 20)) (make-instance 'a
:x 1 :y 2 :z 3)))
FOO
CL-USER 3 > (compile 'foo)
FOO
NIL
NIL
CL-USER 4 > (time (foo))
Timing the evaluation of (FOO)
User time = 0.171
System time = 0.000
Elapsed time = 0.172
Allocation = 33563660 bytes
0 Page faults
NIL
--------------------------------------------------------------------------
ALLEGRO 8.1 PROFESSIONAL (Windows 32bit XP)
CG-USER(1): (defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg
:z)))
(defun foo () (dotimes (i (expt 2 20)) (make-instance 'a :x 1 :y 2 :z
3)))
(compile 'foo)
(time (foo))
#<STANDARD-CLASS A>
CG-USER(2):
FOO
CG-USER(3):
FOO
NIL
NIL
CG-USER(4):
; cpu time (non-gc) 47 msec user, 0 msec system
; cpu time (gc) 422 msec user, 0 msec system
; cpu time (total) 469 msec user, 0 msec system
; real time 468 msec
; space allocation:
; 3,060 cons cells, 58,736,120 other bytes, 0 static bytes
NIL
--------------------------------------------------------------------------
ECL-0.9i (CVS few days ago) (Windows 32bit XP)
jb_v1.07 D:\CLOW\.systems\ecl>ecl.exe
ECL (Embeddable Common-Lisp) 0.9i (CVS 2007-10-14 10:57)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help. Top level.
> (defclass a () ((x :initarg :x) (y :initarg :y) (z :initarg :z)))
#<The STANDARD-CLASS A>
> (defun foo () (dotimes (i (expt 2 20)) (make-instance 'a :x 1 :y 2
:z 3)))
FOO
> (compile 'foo)
;;; Loading #P"D:/CLOW/.systems/ecl/cmp.fas"
;;; Loading #P"D:/CLOW/.systems/ecl/sysfun.lsp"
;;; End of Pass 1.
;;; Note: Replacing variable G47 by its value
;;; Note: Emitting linking call for MAKE-INSTANCE
;;; Calling the C compiler...
;;; Note: Invoking external command:
;;; cl -MD -Z7 -EHsc -DGC_DLL -nologo -DECL_THREADS -O2
-I"D:/CLOW/.systems/ecl/" -w -c "C:/WINDOWS/TEMP/ECL7DB.c"
-Fo"C:/WINDOWS/TEMP/ECL7DB.obj"
ECL7DB.c
;;; Note: Invoking external command:
;;; cl -Fe"C:/WINDOWS/TEMP/ECL7DB.fas" "C:/WINDOWS/TEMP/ECL7DB.obj"
-LDd -MD -Z7 /link /nodefaultlib:libcmt /nodefaultlib:libcmtd
/nodefaultlib:libc /nodefaultlib:libd /LIBPATH:"D:/CLOW/.systems/ecl/"
ecl.lib user32.lib ws2_32.lib shell32
.lib /EXPORT:init_fas_CODE
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/out:C:/WINDOWS/TEMP/ECL7DB.fas
/dll
/implib:C:/WINDOWS/TEMP/ECL7DB.lib
/debug
/nodefaultlib:libcmt
/nodefaultlib:libcmtd
/nodefaultlib:libc
/nodefaultlib:libd
/LIBPATH:D:/CLOW/.systems/ecl/
ecl.lib
user32.lib
ws2_32.lib
shell32.lib
/EXPORT:init_fas_CODE
C:/WINDOWS/TEMP/ECL7DB.obj
Creating library C:/WINDOWS/TEMP/ECL7DB.lib and object
C:/WINDOWS/TEMP/ECL7DB.exp
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3
FOO
NIL
NIL
> (time (foo))
real time : 71.515 secs
run time : 71.391 secs
gc count : 1472 times
consed : 1870661192 bytes
NIL
From: Eric Marsden
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <87prxsyah5.fsf@free.fr>
>>>>> "js" == Juho Snellman <······@iki.fi> writes:
js> Luckily I didn't advise people on what implementations they should not
js> use. There are good reasons to use clisp. I'm just saying that the
js> benchmarks you're misinterpreting aren't such reasons.
As the perpetrator of the cl-bench collection, I can second Juho's
recommendation. Several of the microbenchmarks included in the
collection are poorly designed, and don't test what they purport to
test; some of the Gabriel benchmarks are too small to be an adequate
test of modern machines.
I've been meaning to make a new release for a long time, and may
finally get around to it soon. If anyone has some interesting
CL benchmark code that can be freely redistributed and would
complement the existing tests, please send me email.
--
Eric Marsden
Juho Snellman <······@iki.fi> writes:
> (The code path for the non-constant cases of MAKE-INSTANCE is very much
> unoptimized in SBCL. That it has not been optimized is probably due to
> few people using that case in practice. At least I've never had anyone
> report MAKE-INSTANCE with non-constant class or initarg names as a
> bottleneck in their program before this.)
I have been bitten by this. Maybe one year ago I profiled my PDE solver
Femlisp and found that I lose quite a lot while making small matrix
instances. My workaround in three low-level routines was the following
rewrite (?2 is a macro choosing the second argument, LRET returns the last
local variable):
(defmethod zeros (n &optional (m n) (type 'double-float))
"Returns nxn or (if m is provided) nxm zeros. The value is freshly
allocated."
(?2 (make-instance (standard-matrix type) :nrows n :ncols m)
;; this branch avoids calling make-instance with keyword arguments on
;; a class unknown at compile time, because this is a performance
;; problem for several CL implementations
(lret ((result (make-instance (standard-matrix type))))
(with-slots (store nrows ncols) result
(setf nrows n ncols m
store (make-array (* n m) :element-type type
:initial-element (coerce 0 type)))))))
Yours,
Nicolas
From: Pascal Costanza
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <5ra3q1F12knm0U1@mid.individual.net>
Nicolas Neuss wrote:
> (?2 is a macro choosing the second argument, LRET returns the last
> local variable)
Hm, these look like very useful macros to me! Nice.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Nicolas Neuss wrote:
>
>> (?2 is a macro choosing the second argument, LRET returns the last
>> local variable)
>
> Hm, these look like very useful macros to me! Nice.
>
> Pascal
Thanks:-)
Since we have so many newbies, here is the complete code:
(defmacro ?1 (&rest args)
"A macro extracting the first of its arguments."
(first args))
(defmacro ?2 (&rest args)
"A macro extracting the second of its arguments."
(second args))
(defmacro ?3 (&rest args)
"A macro extracting the third of its arguments."
(third args))
(defmacro lret (bindings &body body)
"A @macro{let}-construct which returns its last binding."
`(let
,bindings ,@body
,(let ((x (car (last bindings))))
(if (atom x)
x
(car x)))))
(defmacro lret* (bindings &body body)
"A @macro{let*}-construct which returns its last binding."
`(let*
,bindings ,@body
,(let ((x (car (last bindings))))
(if (atom x)
x
(car x)))))
Nicolas
On Nov 29, 6:03 am, Javier <·······@gmail.com> wrote:
> On 29 nov, 13:46, Juho Snellman <······@iki.fi> wrote:
>
> > > Of course, SBCL is much faster for fixnum and float operations.
>
> > And here you are grossly misrepresenting the results, by implying that
> > SBCL is only faster than clisp for benchmarks that test fixnum/float
> > performance.
>
> I never said is ONLY faster htan clisp.
>
> > > Consider CLISP for web, string manipulation, and CLOS. It is a very
> > > capable Lisp distribution for these areas.
>
> > I wouldn't advise people to make decisions on what implementation to
> > use
>
> I don't. I said "consider".
>
> > I expect that people interested
> > in CLOS performance would care a lot more about method call
> > performance than the speed of defining classes...
>
> Basically, this depends on the kind of CLOS program you are doing. For
> example, my program is doing millions of instantiations, and much less
> method calls. I wouldn't advise people to make decisions on what
> implementation to not use, without understanding what the program of
> everyone are actually doing. ;)
That is rather amusing since you seem to be strongly advising people
to use CLisp. You are also doing so on no more evidence than these
benchmarks that even on their face do not support that strong a
recommendation. They much more strongly support using SBCL fwiw.
On 15 dic, 11:43, samantha <········@gmail.com> wrote:
> you seem to be strongly advising people
> to use CLisp.
Not at all. I'm advising people to do not avoid considering CLISP.
On Wed, 28 Nov 2007 16:59:14 -0800, Geoff Wozniak wrote:
> I have other quibbles with CLisp. One of them is that with Slime, the
> argument names that show up using slime-autodoc mode are nondescript
> and not helpful. I often see "arg0", "arg1", etc. I use this a lot
> and it's annoying when I forget the order of arguments to things like
> NTH and ELT, for example.
Even when I deploy using clisp, I almost always use something else to
develop in slime: sbcl, openmcl, even allegro on occasion (kenny will
mortified).
Matt
--
"You do not really understand something unless you
can explain it to your grandmother." -- Albert Einstein.
From: Ken Tilton
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <ygt3j.5655$qb6.2743@newsfe10.lga>
Matthew D. Swank wrote:
> On Wed, 28 Nov 2007 16:59:14 -0800, Geoff Wozniak wrote:
>
>
>>I have other quibbles with CLisp. One of them is that with Slime, the
>>argument names that show up using slime-autodoc mode are nondescript
>>and not helpful. I often see "arg0", "arg1", etc. I use this a lot
>>and it's annoying when I forget the order of arguments to things like
>>NTH and ELT, for example.
>
>
> Even when I deploy using clisp, I almost always use something else to
> develop in slime: sbcl, openmcl, even allegro on occasion (kenny will
> mortified).
Nonsense! Even if Allegro's pipe from Emacs to ACL is better than Slime
(or so I am told, and why not, it's their Lisp and Franz are pros
whereas the Slime yobbos are more like reality show programmers), Slime
is the tool you know. Fluency probably matters a lot more than a feature
here and a feature there.
Some wise soul once said it is harder for a good programmer to change
editors than to change languages. Something like that.
kz0
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Thu, 29 Nov 2007 01:48:04 -0500, Ken Tilton wrote:
> (or so I am told, and why not, it's their Lisp and Franz are pros
> whereas the Slime yobbos are more like reality show programmers)
I'd like to see that show. And I don't even like reality shows.
Youtube link please!
Joost.
On Nov 28, 10:48 pm, Ken Tilton <···········@optonline.net> wrote:
> Matthew D. Swank wrote:
> > On Wed, 28 Nov 2007 16:59:14 -0800, Geoff Wozniak wrote:
>
> >>I have other quibbles with CLisp. One of them is that with Slime, the
> >>argument names that show up using slime-autodoc mode are nondescript
> >>and not helpful. I often see "arg0", "arg1", etc. I use this a lot
> >>and it's annoying when I forget the order of arguments to things like
> >>NTH and ELT, for example.
>
> > Even when I deploy using clisp, I almost always use something else to
> > develop in slime: sbcl, openmcl, even allegro on occasion (kenny will
> > mortified).
>
> Nonsense! Even if Allegro's pipe from Emacs to ACL is better than Slime
> (or so I am told, and why not, it's their Lisp and Franz are pros
> whereas the Slime yobbos are more like reality show programmers), Slime
> is the tool you know. Fluency probably matters a lot more than a feature
> here and a feature there.
>
> Some wise soul once said it is harder for a good programmer to change
> editors than to change languages. Something like that.
>
> kz0
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
awesome Ken, I like clisp too!!
does anyone use that emacs clone done in common lisp?
On Nov 28, 8:52 pm, "Matthew D. Swank" <··················@gmail.com>
wrote:
> On Wed, 28 Nov 2007 16:59:14 -0800, Geoff Wozniak wrote:
> > I have other quibbles with CLisp. One of them is that with Slime, the
> > argument names that show up using slime-autodoc mode are nondescript
> > and not helpful. I often see "arg0", "arg1", etc. I use this a lot
> > and it's annoying when I forget the order of arguments to things like
> > NTH and ELT, for example.
>
> Even when I deploy using clisp, I almost always use something else to
> develop in slime: sbcl, openmcl, even allegro on occasion (kenny will
> mortified).
>
> Matt
> --
> "You do not really understand something unless you
> can explain it to your grandmother." -- Albert Einstein.
einstein remember worked in a patent office and stole his ideas from
much smarter men
P� Wed, 28 Nov 2007 19:56:10 +0100, skrev Javier <·······@gmail.com>:
> What are actually the reasons to choose CLISP over other free
> implementations?
>
> I believe there are some. Compared to SBCL, for example:
>
> - Fast bignum operations.
> - Fast CLOS instantiations.
> - Much faster compiler speed, which is nice for big projects.
> - Better memory management. SBCL (and CMUCL) tends to do not return
> unallocated memory and wastes a lot of OS virtual memory.
> - Better memory footprint. It just need about 4 Mb of memory at
> startup.
> - Better debugger. CLISP usually allows you to choose from more
> options when an error occurs in the debugger.
> - Better internationalization. Most messages are translated into
> various languages.
>
> What do you think about? Any more ideas?
To slow with byte interpretation. I might as well use python..
--------------
John Thingstad
On 28 nov, 20:45, "John Thingstad" <·······@online.no> wrote:
> To slow with byte interpretation. I might as well use python..
Python is not Lisp: doesn't have closures, macros and CLOS. And it is
still much slower than CLISP. So I don't get your point.
Note that CLISP, even being bytecode compiled, is faster than SBCL in
some areas (and slower in others, of course).
On Nov 28, 9:13 pm, Javier <·······@gmail.com> wrote:
> On 28 nov, 20:45, "John Thingstad" <·······@online.no> wrote:
>
> > To slow with byte interpretation. I might as well use python..
>
> Python is not Lisp: doesn't have closures, macros and CLOS. And it is
> still much slower than CLISP. So I don't get your point.
>
> Note that CLISP, even being bytecode compiled, is faster than SBCL in
> some areas (and slower in others, of course).
Why don't you tell us what do you plan to use it for so we can give
you a better answers?
From my own humble experience with libraries (that I've encountered,
YMMW) authors usually tend to support the big five SBCL, OpenMCL,
ACL, LW & CMUCL. Check the domain that you're interested in to see
library situation for CLisp.
Slobodan
On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
wrote:
> Why don't you tell us what do you plan to use it for so we can give
> you a better answers?
I'm currently using SBCL, but testing CLISP I discovered that is is
fastest if you use CLOS.
> From my own humble experience with libraries (that I've encountered,
> YMMW) authors usually tend to support the big five SBCL, OpenMCL,
> ACL, LW & CMUCL. Check the domain that you're interested in to see
> library situation for CLisp.
I'm testing some AI things. I'm not actually doing any professional
work on software development.
I was using OSX, but switched to Linux, as I discovered that Linux
treats programmers (specially Lisp programmers) much better. But this
is irrelevant to the original question. I just wanted to know why
people are actually prefering CLISP over SBCL and CMUCL, as I think
this might be usefull for people trying to decide what implementation
to choose.
On Nov 28, 9:48 pm, Javier <·······@gmail.com> wrote:
> On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > Why don't you tell us what do you plan to use it for so we can give
> > you a better answers?
>
> I'm currently using SBCL, but testing CLISP I discovered that is is
> fastest if you use CLOS.
>
> > From my own humble experience with libraries (that I've encountered,
> > YMMW) authors usually tend to support the big five SBCL, OpenMCL,
> > ACL, LW & CMUCL. Check the domain that you're interested in to see
> > library situation for CLisp.
>
> I'm testing some AI things. I'm not actually doing any professional
> work on software development.
> I was using OSX, but switched to Linux, as I discovered that Linux
> treats programmers (specially Lisp programmers) much better.
Library suppoirt in linux is probably best in lisp world.
> But this
> is irrelevant to the original question. I just wanted to know why
> people are actually prefering CLISP over SBCL and CMUCL, as I think
> this might be usefull for people trying to decide what implementation
> to choose.
Than you'll have to wait for some CLisp user to explain it to you.
Probably CLisp is the most portable choice, whichever exotic OS & cpu
combination I've checked there's have been always a CLisp port.
Slobodan
In article
<····································@a39g2000pre.googlegroups.com>,
Slobodan Blazeski <·················@gmail.com> wrote:
> On Nov 28, 9:48 pm, Javier <·······@gmail.com> wrote:
> > On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
> > wrote:
> >
> > > Why don't you tell us what do you plan to use it for so we can give
> > > you a better answers?
> >
> > I'm currently using SBCL, but testing CLISP I discovered that is is
> > fastest if you use CLOS.
> >
> > > From my own humble experience with libraries (that I've encountered,
> > > YMMW) authors usually tend to support the big five SBCL, OpenMCL,
> > > ACL, LW & CMUCL. Check the domain that you're interested in to see
> > > library situation for CLisp.
> >
> > I'm testing some AI things. I'm not actually doing any professional
> > work on software development.
> > I was using OSX, but switched to Linux, as I discovered that Linux
> > treats programmers (specially Lisp programmers) much better.
> Library suppoirt in linux is probably best in lisp world.
What's the word on GNOME and KDE applications in Common Lisp?
Haven't seen many...
> > But this
> > is irrelevant to the original question. I just wanted to know why
> > people are actually prefering CLISP over SBCL and CMUCL, as I think
> > this might be usefull for people trying to decide what implementation
> > to choose.
>
> Than you'll have to wait for some CLisp user to explain it to you.
> Probably CLisp is the most portable choice, whichever exotic OS & cpu
> combination I've checked there's have been always a CLisp port.
>
> Slobodan
Rainer Joswig <······@lisp.de> writes:
>
>> Library suppoirt in linux is probably best in lisp world.
>
> What's the word on GNOME and KDE applications in Common Lisp? Haven't
> seen many...
Well, there's clg which looks nice; I've never quite gotten any work
done with it though...
--
Robert Uhl <http://public.xdi.org/=ruhl>
A pipe gives a wise man time to think and a fool something to stick in
his mouth. --Anonymous
In article <··············@latakia.dyndns.org>,
Robert Uhl <·········@NOSPAMgmail.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
> >
> >> Library suppoirt in linux is probably best in lisp world.
> >
> > What's the word on GNOME and KDE applications in Common Lisp? Haven't
> > seen many...
>
> Well, there's clg which looks nice; I've never quite gotten any work
> done with it though...
Apps, not bindings. Which GNOME or KDE applications are
written in Common Lisp?
--
http://lispm.dyndns.org/
On Nov 30, 4:39 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <··············@latakia.dyndns.org>,
> Robert Uhl <·········@NOSPAMgmail.com> wrote:
>
> > Rainer Joswig <······@lisp.de> writes:
>
> > >> Library suppoirt in linux is probably best in lisp world.
>
> > > What's the word on GNOME and KDE applications in Common Lisp? Haven't
> > > seen many...
>
> > Well, there's clg which looks nice; I've never quite gotten any work
> > done with it though...
>
> Apps, not bindings. Which GNOME or KDE applications are
> written in Common Lisp?
How do you mean GNOME or KDE applications ? Allegro is written in GTK
does that qualifies for native gnome citizen?
Slobodan
In article
<····································@i29g2000prf.googlegroups.com>,
Slobodan Blazeski <·················@gmail.com> wrote:
> On Nov 30, 4:39 pm, Rainer Joswig <······@lisp.de> wrote:
> > In article <··············@latakia.dyndns.org>,
> > Robert Uhl <·········@NOSPAMgmail.com> wrote:
> >
> > > Rainer Joswig <······@lisp.de> writes:
> >
> > > >> Library suppoirt in linux is probably best in lisp world.
> >
> > > > What's the word on GNOME and KDE applications in Common Lisp? Haven't
> > > > seen many...
> >
> > > Well, there's clg which looks nice; I've never quite gotten any work
> > > done with it though...
> >
> > Apps, not bindings. Which GNOME or KDE applications are
> > written in Common Lisp?
>
> How do you mean GNOME or KDE applications ? Allegro is written in GTK
> does that qualifies for native gnome citizen?
>
> Slobodan
Are there any other ones? Like a program that people use
and would not really notice that it is written in Lisp?
You know what I mean. A grapics app, an expert system
with GUI, a mail reader, an editor, a paint program.
Say, like Edi's Regexp tool or Clozure's Inspire Data.
But for GNOME or KDE. With the widgets and all that
stuff. Icons.
--
http://lispm.dyndns.org/
On Nov 30, 10:08 am, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@i29g2000prf.googlegroups.com>,
> Slobodan Blazeski <·················@gmail.com> wrote:
>
>
>
> > On Nov 30, 4:39 pm, Rainer Joswig <······@lisp.de> wrote:
> > > In article <··············@latakia.dyndns.org>,
> > > Robert Uhl <·········@NOSPAMgmail.com> wrote:
>
> > > > Rainer Joswig <······@lisp.de> writes:
>
> > > > >> Library suppoirt in linux is probably best in lisp world.
>
> > > > > What's the word on GNOME and KDE applications in Common Lisp? Haven't
> > > > > seen many...
>
> > > > Well, there's clg which looks nice; I've never quite gotten any work
> > > > done with it though...
>
> > > Apps, not bindings. Which GNOME or KDE applications are
> > > written in Common Lisp?
>
> > How do you mean GNOME or KDE applications ? Allegro is written in GTK
> > does that qualifies for native gnome citizen?
>
> > Slobodan
>
> Are there any other ones? Like a program that people use
> and would not really notice that it is written in Lisp?
> You know what I mean. A grapics app, an expert system
> with GUI, a mail reader, an editor, a paint program.
>
> Say, like Edi's Regexp tool or Clozure's Inspire Data.
> But for GNOME or KDE. With the widgets and all that
> stuff. Icons.
>
> --http://lispm.dyndns.org/
I guess that their number would be dwarfed compared with windows
ones. Windows rules the desktop.
Developers are rational beings if Linux marlet 20 times smaller than
windows one they wouldn't make a linux version unless it cost 20 times
cheaper, or won't make at all.
Slobodan
On Nov 30, 10:08 am, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@i29g2000prf.googlegroups.com>,
> Slobodan Blazeski <·················@gmail.com> wrote:
>
>
>
> > On Nov 30, 4:39 pm, Rainer Joswig <······@lisp.de> wrote:
> > > In article <··············@latakia.dyndns.org>,
> > > Robert Uhl <·········@NOSPAMgmail.com> wrote:
>
> > > > Rainer Joswig <······@lisp.de> writes:
>
> > > > >> Library suppoirt in linux is probably best in lisp world.
>
> > > > > What's the word on GNOME and KDE applications in Common Lisp? Haven't
> > > > > seen many...
>
> > > > Well, there's clg which looks nice; I've never quite gotten any work
> > > > done with it though...
>
> > > Apps, not bindings. Which GNOME or KDE applications are
> > > written in Common Lisp?
>
> > How do you mean GNOME or KDE applications ? Allegro is written in GTK
> > does that qualifies for native gnome citizen?
>
> > Slobodan
>
> Are there any other ones? Like a program that people use
> and would not really notice that it is written in Lisp?
> You know what I mean. A grapics app, an expert system
> with GUI, a mail reader, an editor, a paint program.
>
> Say, like Edi's Regexp tool or Clozure's Inspire Data.
> But for GNOME or KDE. With the widgets and all that
> stuff. Icons.
>
> --http://lispm.dyndns.org/
Beside there are few lisp applications anyway, desktop or not desktop.
Unfortunately.
Slobodan
Rainer Joswig <······@lisp.de> wrote:
+---------------
| > How do you mean GNOME or KDE applications ? Allegro is
| > written in GTK does that qualifies for native gnome citizen?
|
| Are there any other ones? Like a program that people use
| and would not really notice that it is written in Lisp?
| You know what I mean. A grapics app, an expert system
| with GUI, a mail reader, an editor, a paint program.
+---------------
I have a small clone of SGI's "sysmeter", that displays date/time,
uptime, % CPU, network {pkts,bytes}/sec, battery state [on laptops],
that sort of thing.
+---------------
| But for GNOME or KDE. With the widgets and all that stuff. Icons.
+---------------
Oh. Mine just uses raw CLX. "Never mind..." ;-} ;-}
[Though it *does* SET-WM-PROPERTIES to set
the :TITLE to something that suppresses the
window manager frame, and also names its icon.
Does that count? ;-} ]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Rainer Joswig <······@lisp.de> wrote:
> +---------------
> | > How do you mean GNOME or KDE applications ? Allegro is
> | > written in GTK does that qualifies for native gnome citizen?
> |
> | Are there any other ones? Like a program that people use
> | and would not really notice that it is written in Lisp?
> | You know what I mean. A grapics app, an expert system
> | with GUI, a mail reader, an editor, a paint program.
> +---------------
>
> I have a small clone of SGI's "sysmeter", that displays date/time,
> uptime, % CPU, network {pkts,bytes}/sec, battery state [on laptops],
> that sort of thing.
>
> +---------------
> | But for GNOME or KDE. With the widgets and all that stuff. Icons.
> +---------------
>
> Oh. Mine just uses raw CLX. "Never mind..." ;-} ;-}
>
> [Though it *does* SET-WM-PROPERTIES to set
> the :TITLE to something that suppresses the
> window manager frame, and also names its icon.
> Does that count? ;-} ]
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
No, Rob, sorry, doesn't count. Raw CLX!!! Heavens! ;-)
http://www.gnome.org/start/2.20/notes/en/ shows some
basic apps.
Rob, still, we need a screenshot. ;-)
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> wrote:
+---------------
| Rob, still, we need a screenshot. ;-)
+---------------
What's the easiest way to do that on a FreeBSD system
running plain ol' X11? (...with "twm" as the WM.)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Fri, 30 Nov 2007 21:27:47 -0600, Rob Warnock wrote:
> Rainer Joswig <······@lisp.de> wrote:
> +---------------
> | Rob, still, we need a screenshot. ;-)
> +---------------
>
> What's the easiest way to do that on a FreeBSD system
> running plain ol' X11? (...with "twm" as the WM.)
>
Scrot is my go-to program for screenshots.
Rob Warnock wrote:
> Rainer Joswig <······@lisp.de> wrote:
> +---------------
> | Rob, still, we need a screenshot. ;-)
> +---------------
>
> What's the easiest way to do that on a FreeBSD system
> running plain ol' X11? (...with "twm" as the WM.)
xwd | xwdtopnm | pnmtopng # or something along those lines
or xpaint and gimp both have some menu option for grabbing window
contents, if either of those is installed.
-dan
<···@telent.net> wrote:
+---------------
| Rob Warnock wrote:
| > What's the easiest way to do [screenshots] on a FreeBSD system
| > running plain ol' X11? (...with "twm" as the WM.)
|
| xwd | xwdtopnm | pnmtopng # or something along those lines
+---------------
Thanks!
+---------------
| or xpaint and gimp both have some menu option for
| grabbing window contents, if either of those is installed.
+---------------
Actually, now that you prompt my memory, I recall that in the
distant past I once used "xmag" for selecting/copying and then
pasted into "bitmap" [though that only handles two colors],
and then saved to a file.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Rainer Joswig <······@lisp.de> wrote:
> +---------------
> | Rob, still, we need a screenshot. ;-)
> +---------------
>
> What's the easiest way to do that on a FreeBSD system
> running plain ol' X11? (...with "twm" as the WM.)
Hmm, a camera?
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
--
http://lispm.dyndns.org/
Rob Warnock <····@rpw3.org> wrote:
> Rainer Joswig <······@lisp.de> wrote:
> +---------------
>| Rob, still, we need a screenshot. ;-)
> +---------------
>
> What's the easiest way to do that on a FreeBSD system
> running plain ol' X11? (...with "twm" as the WM.)
The import program from ImageMagick - simply run 'import screen.png' and
you can select a nice rectangular area of your screen.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Rainer Joswig <······@lisp.de> wrote:
> In article <··············@latakia.dyndns.org>,
> Robert Uhl <·········@NOSPAMgmail.com> wrote:
>
>> Rainer Joswig <······@lisp.de> writes:
>> >
>> >> Library suppoirt in linux is probably best in lisp world.
>> >
>> > What's the word on GNOME and KDE applications in Common Lisp? Haven't
>> > seen many...
>>
>> Well, there's clg which looks nice; I've never quite gotten any work
>> done with it though...
>
> Apps, not bindings. Which GNOME or KDE applications are
> written in Common Lisp?
None that I'm aware of. I chalk that down to Lisp programmers having too
much taste to muck around with either KDE or GNOME :-)
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
On Nov 28, 1:46 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@a39g2000pre.googlegroups.com>,
> Slobodan Blazeski <·················@gmail.com> wrote:
>
>
>
> > On Nov 28, 9:48 pm, Javier <·······@gmail.com> wrote:
> > > On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
> > > wrote:
>
> > > > Why don't you tell us what do you plan to use it for so we can give
> > > > you a better answers?
>
> > > I'm currently using SBCL, but testing CLISP I discovered that is is
> > > fastest if you use CLOS.
>
> > > > From my own humble experience with libraries (that I've encountered,
> > > > YMMW) authors usually tend to support the big five SBCL, OpenMCL,
> > > > ACL, LW & CMUCL. Check the domain that you're interested in to see
> > > > library situation for CLisp.
>
> > > I'm testing some AI things. I'm not actually doing any professional
> > > work on software development.
> > > I was using OSX, but switched to Linux, as I discovered that Linux
> > > treats programmers (specially Lisp programmers) much better.
> > Library suppoirt in linux is probably best in lisp world.
>
> What's the word on GNOME and KDE applications in Common Lisp?
> Haven't seen many...
>
> > > But this
> > > is irrelevant to the original question. I just wanted to know why
> > > people are actually prefering CLISP over SBCL and CMUCL, as I think
> > > this might be usefull for people trying to decide what implementation
> > > to choose.
>
> > Than you'll have to wait for some CLisp user to explain it to you.
> > Probably CLisp is the most portable choice, whichever exotic OS & cpu
> > combination I've checked there's have been always a CLisp port.
>
> > Slobodan
I think its time for a lisp xorg replacement
On Dec 4, 1:14 pm, gavino <·········@gmail.com> wrote:
> On Nov 28, 1:46 pm, Rainer Joswig <······@lisp.de> wrote:
>
>
>
> > In article
> > <····································@a39g2000pre.googlegroups.com>,
> > Slobodan Blazeski <·················@gmail.com> wrote:
>
> > > On Nov 28, 9:48 pm, Javier <·······@gmail.com> wrote:
> > > > On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
> > > > wrote:
>
> > > > > Why don't you tell us what do you plan to use it for so we can give
> > > > > you a better answers?
>
> > > > I'm currently using SBCL, but testing CLISP I discovered that is is
> > > > fastest if you use CLOS.
>
> > > > > From my own humble experience with libraries (that I've encountered,
> > > > > YMMW) authors usually tend to support the big five SBCL, OpenMCL,
> > > > > ACL, LW & CMUCL. Check the domain that you're interested in to see
> > > > > library situation for CLisp.
>
> > > > I'm testing some AI things. I'm not actually doing any professional
> > > > work on software development.
> > > > I was using OSX, but switched to Linux, as I discovered that Linux
> > > > treats programmers (specially Lisp programmers) much better.
> > > Library suppoirt in linux is probably best in lisp world.
>
> > What's the word on GNOME and KDE applications in Common Lisp?
> > Haven't seen many...
>
> > > > But this
> > > > is irrelevant to the original question. I just wanted to know why
> > > > people are actually prefering CLISP over SBCL and CMUCL, as I think
> > > > this might be usefull for people trying to decide what implementation
> > > > to choose.
>
> > > Than you'll have to wait for some CLisp user to explain it to you.
> > > Probably CLisp is the most portable choice, whichever exotic OS & cpu
> > > combination I've checked there's have been always a CLisp port.
>
> > > Slobodan
>
> I think its time for a lisp xorg replacement
And I think it's time to seat down and finish ANSI Common Lisp.
Slobodan
Slobodan Blazeski wrote:
> On Nov 28, 9:48 pm, Javier <·······@gmail.com> wrote:
> > On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
> > wrote:
> > But this
> > is irrelevant to the original question. I just wanted to know why
> > people are actually prefering CLISP over SBCL and CMUCL, as I think
> > this might be usefull for people trying to decide what implementation
> > to choose.
>
> Than you'll have to wait for some CLisp user to explain it to you.
two out of three free lisp books i have downloaded use clisp for
examples,
often unportably. they don't explain they just say use clisp. so i
tried it
(on osX). not too impressed, so i am focusing on the book that
describes
portable lisp programming (OnLisp).
I liked openmcl best but the port is irregular.
funny tho Clisp is most portable itself, the code you produce with it
is not really.
an introductory text should not need to spend a significant amount of
space on
non standard parts of the language, given that there is a standard.
perhaps clisp comes bundled with some libraries that help it, but it
deviates
with that support perhaps to be itself more portable ?
From: Dimiter "malkia" Stanev
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <5rm4ikF15f37hU1@mid.individual.net>
tortoise wrote:
[snipped]
> funny tho Clisp is most portable itself, the code you produce with it
> is not really.
The code clisp produces can execute only on clisp (macroses, compiler,
etc.), and probably on the same versions of clisp.
The code that YOU produce might be portable or not.
> an introductory text should not need to spend a significant amount of
> space on
> non standard parts of the language, given that there is a standard.
And what's that has to do with CLISP?
>
> perhaps clisp comes bundled with some libraries that help it, but it
> deviates
> with that support perhaps to be itself more portable ?
>
Thanks,
malkia
On Nov 28, 1:20 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Nov 28, 9:48 pm, Javier <·······@gmail.com> wrote:
>
> > On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
> > wrote:
>
> > > Why don't you tell us what do you plan to use it for so we can give
> > > you a better answers?
>
> > I'm currently using SBCL, but testing CLISP I discovered that is is
> > fastest if you use CLOS.
>
> > > From my own humble experience with libraries (that I've encountered,
> > > YMMW) authors usually tend to support the big five SBCL, OpenMCL,
> > > ACL, LW & CMUCL. Check the domain that you're interested in to see
> > > library situation for CLisp.
>
> > I'm testing some AI things. I'm not actually doing any professional
> > work on software development.
> > I was using OSX, but switched to Linux, as I discovered that Linux
> > treats programmers (specially Lisp programmers) much better.
>
> Library suppoirt in linux is probably best in lisp world.
>
> > But this
> > is irrelevant to the original question. I just wanted to know why
> > people are actually prefering CLISP over SBCL and CMUCL, as I think
> > this might be usefull for people trying to decide what implementation
> > to choose.
>
> Than you'll have to wait for some CLisp user to explain it to you.
> Probably CLisp is the most portable choice, whichever exotic OS & cpu
> combination I've checked there's have been always a CLisp port.
>
> Slobodan
I did notice that some lisp apps dont run on clisp though...
From: Frank Goenninger DG1SBG
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <lzd4tuawpw.fsf@de.goenninger.net>
Javier <·······@gmail.com> writes:
> I'm testing some AI things. I'm not actually doing any professional
> work on software development.
> I was using OSX, but switched to Linux, as I discovered that Linux
> treats programmers (specially Lisp programmers) much better.
Huh? What makes you make that statement? (I have been using both Linux
and OS X for years now and did not have any experience justifying such
a statement for myself - so: I'd really like to know ...)
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
On 28 nov, 22:25, Frank Goenninger DG1SBG <·············@nomail.org>
wrote:
> Javier <·······@gmail.com> writes:
> > I'm testing some AI things. I'm not actually doing any professional
> > work on software development.
> > I was using OSX, but switched to Linux, as I discovered that Linux
> > treats programmers (specially Lisp programmers) much better.
>
> Huh? What makes you make that statement? (I have been using both Linux
> and OS X for years now and did not have any experience justifying such
> a statement for myself - so: I'd really like to know ...)
Just three examples:
- CLISP was not avaible for Intel OSX for more than one year. I don't
know if it is avaible right now. Elsewhere, you still need to install
a lot of foreing stuff in order to make it run.
- SBCL thread support is very experimental and not enabled by default
on OSX.
- GTK is working badly on OSX (you have to install X11 which is not
nice and works slowly and not very well integrated), and compiling it
might be a hell. So bingins for GTK are working bad for Lisp
implementations.
Javier <·······@gmail.com> writes:
> On 28 nov, 22:25, Frank Goenninger DG1SBG <·············@nomail.org>
> wrote:
>> Javier <·······@gmail.com> writes:
>> > I'm testing some AI things. I'm not actually doing any professional
>> > work on software development.
>> > I was using OSX, but switched to Linux, as I discovered that Linux
>> > treats programmers (specially Lisp programmers) much better.
>>
>> Huh? What makes you make that statement? (I have been using both Linux
>> and OS X for years now and did not have any experience justifying such
>> a statement for myself - so: I'd really like to know ...)
>
> Just three examples:
>
> - CLISP was not avaible for Intel OSX for more than one year. I don't
> know if it is avaible right now. Elsewhere, you still need to install
> a lot of foreing stuff in order to make it run.
> - SBCL thread support is very experimental and not enabled by default
> on OSX.
> - GTK is working badly on OSX (you have to install X11 which is not
> nice and works slowly and not very well integrated), and compiling it
> might be a hell. So bingins for GTK are working bad for Lisp
> implementations.
Oh man - you need thread support and GTK to do "testing some AI
things"? What kind of AI are you talking of?
I assume you know these "minor" implementations named AllegroCL and
LispWorks?
You wouldn't have the "problems" given in your examples if you used
these ...
Meanwhile I enjoy Allegro CL and Lispworks in their Free editions here
and even get the best quality support you ever could want.
Oh - and yes, I am on OS X Intel here.
But, hey, it's your decision. And I thought I get to see something
substantial.
Frank
--
Frank Goenninger
http://www.goenninger.net
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
On 29 nov, 21:58, Frank Goenninger DG1SBG <·············@nomail.org>
wrote:
> Oh man - you need thread support and GTK to do "testing some AI
> things"? What kind of AI are you talking of?
I have other projects.
> I assume you know these "minor" implementations named AllegroCL and
> LispWorks?
I meant free (as in freedom, not "gratis") implementations.
> You wouldn't have the "problems" given in your examples if you used
> these ...
>
> Meanwhile I enjoy Allegro CL and Lispworks in their Free editions here
> and even get the best quality support you ever could want.
It's what you have choosen. Not of mine.
> Oh - and yes, I am on OS X Intel here.
>
> But, hey, it's your decision.
That's right.
> And I thought I get to see something
> substantial.
And please, do not enter into the classical and boring discussion
about free vs commercial software. There are other reasons because I
dropped off OSX from my computer.
On Nov 28, 1:25 pm, Frank Goenninger DG1SBG <·············@nomail.org>
wrote:
> Javier <·······@gmail.com> writes:
> > I'm testing some AI things. I'm not actually doing any professional
> > work on software development.
> > I was using OSX, but switched to Linux, as I discovered that Linux
> > treats programmers (specially Lisp programmers) much better.
>
> Huh? What makes you make that statement? (I have been using both Linux
> and OS X for years now and did not have any experience justifying such
> a statement for myself - so: I'd really like to know ...)
>
> Frank
>
> --
>
> Frank Goenninger
>
> frgo(at)mac(dot)com
>
> "Don't ask me! I haven't been reading comp.lang.lisp long enough to
> really know ..."
put linux on that mac hardware :)
On Nov 28, 9:48 pm, Javier <·······@gmail.com> wrote:
> On 28 nov, 21:24, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > Why don't you tell us what do you plan to use it for so we can give
> > you a better answers?
>
> I'm currently using SBCL, but testing CLISP I discovered that is is
> fastest if you use CLOS.
>
> > From my own humble experience with libraries (that I've encountered,
> > YMMW) authors usually tend to support the big five SBCL, OpenMCL,
> > ACL, LW & CMUCL. Check the domain that you're interested in to see
> > library situation for CLisp.
>
> I'm testing some AI things. I'm not actually doing any professional
> work on software development.
> I was using OSX, but switched to Linux, as I discovered that Linux
> treats programmers (specially Lisp programmers) much better. But this
> is irrelevant to the original question. I just wanted to know why
> people are actually prefering CLISP over SBCL and CMUCL, as I think
> this might be usefull for people trying to decide what implementation
> to choose.
Just use MacPorts, I use CLISP + Emacs + SVN on Linux, OSX and
Windows. No problem with platforms on my side.
Jurgen
On Wed, 28 Nov 2007 12:13:39 -0800, Javier wrote:
> On 28 nov, 20:45, "John Thingstad" <·······@online.no> wrote:
>
>> To slow with byte interpretation. I might as well use python..
>
> Python is not Lisp: doesn't have closures, macros and CLOS. And it is
> still much slower than CLISP. So I don't get your point.
>
> Note that CLISP, even being bytecode compiled, is faster than SBCL in
> some areas (and slower in others, of course).
Thread support notwithstanding, I've found that over all, clisp is the
best free lisp available on Windoze. It's more stable than sbcl, and (as
mentioned elsewhere) has a small memory footprint.
The GPL thing doesn't worry me too much, as all the apps I use it for are
internal. Also, I tend to run parallel clisp and sbcl installations to
help keep things portable as possible.
There is one apt comparison to python: much like python, file->string
processing tasks are usually comparable in speed, or significantly faster
on clisp versus sbcl on any platform I use it on. When I started doing
significant amounts of text processing in lisp, I found this most
surprising.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." -- Albert Einstein.
From: Ken Tilton
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <0Qm3j.127$Pk.15@newsfe09.lga>
Matthew D. Swank wrote:
> On Wed, 28 Nov 2007 12:13:39 -0800, Javier wrote:
>
>
>>On 28 nov, 20:45, "John Thingstad" <·······@online.no> wrote:
>>
>>
>>>To slow with byte interpretation. I might as well use python..
>>
>>Python is not Lisp: doesn't have closures, macros and CLOS. And it is
>>still much slower than CLISP. So I don't get your point.
>>
>>Note that CLISP, even being bytecode compiled, is faster than SBCL in
>>some areas (and slower in others, of course).
>
>
> Thread support notwithstanding, I've found that over all, clisp is the
> best free lisp available on Windoze. It's more stable than sbcl, and (as
> mentioned elsewhere) has a small memory footprint.
>
> The GPL thing doesn't worry me too much, as...
...they have clarified that bit and in fact things like FFI and the MOP
do not take one into GPL-land.
kzo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Wed, 28 Nov 2007 10:56:10 -0800 (PST), Javier <·······@gmail.com> tried to
confuse everyone with this message:
>What are actually the reasons to choose CLISP over other free
>implementations?
>
The only free implementation with which you can reasonably deliver apps
on Windows. It creates small exes which can be shared with Lisp-illiterate
people. I'm using it for my roguelike games.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
From: Dimiter "malkia" Stanev
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <5r6h0sF134hk8U1@mid.individual.net>
Timofei Shatrov wrote:
> On Wed, 28 Nov 2007 10:56:10 -0800 (PST), Javier <·······@gmail.com> tried to
> confuse everyone with this message:
>
>> What are actually the reasons to choose CLISP over other free
>> implementations?
>>
>
> The only free implementation with which you can reasonably deliver apps
> on Windows. It creates small exes which can be shared with Lisp-illiterate
> people. I'm using it for my roguelike games.
>
I'm regurarly building and using ECL for Windows (XP), is CLISP more
stable than it?
On Nov 29, 8:13 am, ····@mail.ru (Timofei Shatrov) wrote:
> On Wed, 28 Nov 2007 10:56:10 -0800 (PST), Javier <·······@gmail.com> tried to
> confuse everyone with this message:
>
> >What are actually the reasons to choose CLISP over other free
> >implementations?
>
> The only free implementation with which you can reasonably deliver apps
> on Windows. It creates small exes which can be shared with Lisp-illiterate
> people. I'm using it for my roguelike games.
>
> --
> |Don't believe this - you're not worthless ,gr---------.ru
> |It's us against millions and we can't take them all... | ue il |
> |But we can take them on! | @ma |
> | (A Wilhelm Scream - The Rip) |______________|
How to create exes in CLISP?
From: Johannes Groedem
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <krhcj5ia0l.fsf@netfonds.no>
* Brian Jiang <········@gmail.com>:
> How to create exes in CLISP?
ext:saveinitmem
http://clisp.sourceforge.net/impnotes.html#image
--
Johannes Gr�dem
On Nov 28, 4:13 pm, ····@mail.ru (Timofei Shatrov) wrote:
> On Wed, 28 Nov 2007 10:56:10 -0800 (PST), Javier <·······@gmail.com> tried to
> confuse everyone with this message:
>
> >What are actually the reasons to choose CLISP over other free
> >implementations?
>
> The only free implementation with which you can reasonably deliver apps
> on Windows. It creates small exes which can be shared with Lisp-illiterate
> people. I'm using it for my roguelike games.
>
> --
> |Don't believe this - you're not worthless ,gr---------.ru
> |It's us against millions and we can't take them all... | ue il |
> |But we can take them on! | @ma |
> | (A Wilhelm Scream - The Rip) |______________|
delivering lisp apps on windows is like delivering soufflet to a
dogbowl
On Tue, 4 Dec 2007 04:13:53 -0800 (PST), gavino <·········@gmail.com>
wrote:
>delivering lisp apps on windows is like delivering soufflet to a
>dogbowl
And you would know this how?
George
--
for email reply remove "/" from address
On Dec 4, 1:13 pm, gavino <·········@gmail.com> wrote:
> On Nov 28, 4:13 pm, ····@mail.ru (Timofei Shatrov) wrote:
>
> > On Wed, 28 Nov 2007 10:56:10 -0800 (PST), Javier <·······@gmail.com> tried to
> > confuse everyone with this message:
>
> > >What are actually the reasons to choose CLISP over other free
> > >implementations?
>
> > The only free implementation with which you can reasonably deliver apps
> > on Windows. It creates small exes which can be shared with Lisp-illiterate
> > people. I'm using it for my roguelike games.
>
> > --
> > |Don't believe this - you're not worthless ,gr---------.ru
> > |It's us against millions and we can't take them all... | ue il |
> > |But we can take them on! | @ma |
> > | (A Wilhelm Scream - The Rip) |______________|
>
> delivering lisp apps on windows is like delivering soufflet to a
> dogbowl
Which lisp apps you delivered on any OS?
And did you finished ANSI Common Lisp?
Slobodan
On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
> What are actually the reasons to choose CLISP over other free
> implementations?
>
> I believe there are some. Compared to SBCL, for example:
>
> - Fast bignum operations.
> - Fast CLOS instantiations.
> - Much faster compiler speed, which is nice for big projects.
> - Better memory management. SBCL (and CMUCL) tends to do not return
> unallocated memory and wastes a lot of OS virtual memory.
> - Better memory footprint. It just need about 4 Mb of memory at
> startup.
> - Better debugger. CLISP usually allows you to choose from more
> options when an error occurs in the debugger.
> - Better internationalization. Most messages are translated into
> various languages.
>
> What do you think about? Any more ideas?
I spent the last year and a half writing a simulation of a
microprocessor I designed myself. I chose CL as the implementation
language because I wanted to learn CL, not because I thought that it
would the best language to do it (actually, because of the macro
mechanism it turned out the best solution for me).
Based upon the sources I have now, I have created a small benchmark
around it, which times how many simulated clock cycles can be run in
one second. It runs the complete system with a small program inside.
- CLISP : appr. 3000 simulated clock cycles
- CMUCL : appr. 20000 simulated clock cycles
- SBCL : appr. 125000 simulated clock cycles
I have the impression that all three compilers need about the same
time to compile the same code. The main reason for me to use CLISP is
for portability of my code between Linux and Windows. For performance
I need SBCL, but you have to learn the warnings you get from the
compiler to adapt your code for optimal performance, which means
mostly type restrictions.
Porting between the three systems has consisted mainly of using some
feature selection for the extensions of the compiled files,
interpreting the output of (time (or times in CLISP)) and the handling
of command line arguments.
I wanted to test my code with ECL too, unfortunately ECL chokes on a
(declaim) statement.
Regards,
Jurgen
In article
<····································@s36g2000prg.googlegroups.com>,
jurgen_defurne <··············@pandora.be> wrote:
> On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
> > What are actually the reasons to choose CLISP over other free
> > implementations?
> >
> > I believe there are some. Compared to SBCL, for example:
> >
> > - Fast bignum operations.
> > - Fast CLOS instantiations.
> > - Much faster compiler speed, which is nice for big projects.
> > - Better memory management. SBCL (and CMUCL) tends to do not return
> > unallocated memory and wastes a lot of OS virtual memory.
> > - Better memory footprint. It just need about 4 Mb of memory at
> > startup.
> > - Better debugger. CLISP usually allows you to choose from more
> > options when an error occurs in the debugger.
> > - Better internationalization. Most messages are translated into
> > various languages.
> >
> > What do you think about? Any more ideas?
>
> I spent the last year and a half writing a simulation of a
> microprocessor I designed myself. I chose CL as the implementation
> language because I wanted to learn CL, not because I thought that it
> would the best language to do it (actually, because of the macro
> mechanism it turned out the best solution for me).
>
> Based upon the sources I have now, I have created a small benchmark
> around it, which times how many simulated clock cycles can be run in
> one second. It runs the complete system with a small program inside.
>
> - CLISP : appr. 3000 simulated clock cycles
> - CMUCL : appr. 20000 simulated clock cycles
> - SBCL : appr. 125000 simulated clock cycles
Was that with or without optimizations?
I would hope that the majority of Lisp software runs
in fully safe mode (runtime checks, ...).
Only in those code areas that REALLY REALLY need more 'speed',
one should turn optimization for speed higher and safety lower.
>
> I have the impression that all three compilers need about the same
> time to compile the same code. The main reason for me to use CLISP is
> for portability of my code between Linux and Windows. For performance
> I need SBCL, but you have to learn the warnings you get from the
> compiler to adapt your code for optimal performance, which means
> mostly type restrictions.
>
> Porting between the three systems has consisted mainly of using some
> feature selection for the extensions of the compiled files,
> interpreting the output of (time (or times in CLISP)) and the handling
> of command line arguments.
>
> I wanted to test my code with ECL too, unfortunately ECL chokes on a
> (declaim) statement.
>
> Regards,
>
> Jurgen
On Nov 29, 3:08 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@s36g2000prg.googlegroups.com>,
>
>
>
> jurgen_defurne <··············@pandora.be> wrote:
> > On Nov 28, 7:56 pm, Javier <·······@gmail.com> wrote:
> > > What are actually the reasons to choose CLISP over other free
> > > implementations?
>
> > > I believe there are some. Compared to SBCL, for example:
>
> > > - Fast bignum operations.
> > > - Fast CLOS instantiations.
> > > - Much faster compiler speed, which is nice for big projects.
> > > - Better memory management. SBCL (and CMUCL) tends to do not return
> > > unallocated memory and wastes a lot of OS virtual memory.
> > > - Better memory footprint. It just need about 4 Mb of memory at
> > > startup.
> > > - Better debugger. CLISP usually allows you to choose from more
> > > options when an error occurs in the debugger.
> > > - Better internationalization. Most messages are translated into
> > > various languages.
>
> > > What do you think about? Any more ideas?
>
> > I spent the last year and a half writing a simulation of a
> > microprocessor I designed myself. I chose CL as the implementation
> > language because I wanted to learn CL, not because I thought that it
> > would the best language to do it (actually, because of the macro
> > mechanism it turned out the best solution for me).
>
> > Based upon the sources I have now, I have created a small benchmark
> > around it, which times how many simulated clock cycles can be run in
> > one second. It runs the complete system with a small program inside.
>
> > - CLISP : appr. 3000 simulated clock cycles
> > - CMUCL : appr. 20000 simulated clock cycles
> > - SBCL : appr. 125000 simulated clock cycles
>
> Was that with or without optimizations?
>
> I would hope that the majority of Lisp software runs
> in fully safe mode (runtime checks, ...).
> Only in those code areas that REALLY REALLY need more 'speed',
> one should turn optimization for speed higher and safety lower.
>
>
>
> > I have the impression that all three compilers need about the same
> > time to compile the same code. The main reason for me to use CLISP is
> > for portability of my code between Linux and Windows. For performance
> > I need SBCL, but you have to learn the warnings you get from the
> > compiler to adapt your code for optimal performance, which means
> > mostly type restrictions.
>
> > Porting between the three systems has consisted mainly of using some
> > feature selection for the extensions of the compiled files,
> > interpreting the output of (time (or times in CLISP)) and the handling
> > of command line arguments.
>
> > I wanted to test my code with ECL too, unfortunately ECL chokes on a
> > (declaim) statement.
>
> > Regards,
>
> > Jurgen
That is with optimisations. I know the dangers of optimising, but most
arithmetic I do is only related to 32-bit integers. All operations are
masked so that there are no overflows. All my software has first been
built without optimisations and with run-time checks, and been put
under the hammer so that possible overflows are avoided, and then I
have turned on optimisations. I could probable even go further,
because not everything has been optimised.
Jurgen
On Nov 29, 2:21 pm, jurgen_defurne <··············@pandora.be> wrote:
> I wanted to test my code withECLtoo, unfortunatelyECLchokes on a
> (declaim) statement.
Quite possibly, this bug has been solved this week in the CVS version.
Otherwise, could you submit a sample of the offending code to me
privately?
Juanjo
From: Kent M Pitman
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <uodddm2gl.fsf@nhplace.com>
Javier <·······@gmail.com> writes:
> What are actually the reasons to choose CLISP over other free
> implementations?
I don't use clisp regularly, but I had occasion to in the past for a
while because a client was using it, and it did much better than I
expected for a byte-coded implementation. Many good things have been
mentioned about it, but one I don't think I saw mentioned that I
figure is worth mentioning is this (which is kind of the silver lining
of the byte coded nature, which has some drawbacks):
It seems to reward "straightforward programming"; that is, it
encourages good programming style. A programmer can have the
temptation to "compete with" a built-in operator by writing one that
is almost the same but tries to have some extra speed edge. This
leads to custom code that isn't doing anything novel but is uselessly
harder to read. My impression was (have others have felt this?) that
when you tried to compete with it, you just lose, because its
primitive operations are often not byte-coded and your attempts to
reprogram it are. Hence, a bunch of arefs in the byte coded language
are way less efficient than just calling the equivalent high-level
thing.
It had the weird effect that code to run efficiently in multiple
implementations often has to do something very different in clisp to
get efficiency than in other dialects. For people porting code in and
out a lot, this might be a weakness. But for people just using that
one implementation, the resulting code seemed to end up more
straightforward because it wasn't rewarding second-guessing.
It's one of the odd things about CL that was sort of built into the
design and is mentioned occasionally in passing but that you often
don't see the effect of. One reason the operations are not totally
nailed down and a lot of flexibility about implementation is offered
is to allow design trade-offs to be made different ways. One can make
an all-compiled or all-interpreted implementation, for example. Or,
as recently discussed, one can save space by implementing the
non-destructive operations like reverse, etc. and then making things
like nreverse be just pointers to the same function. All of these
things are odd and surprise people when you discuss them out of
context, but they are valuable choices to someone in the context of a
particular implementation trying to hit a particular market. clisp is
one of the implementations that usefully diverged from the pack to
seek a particular optimization space that's novel and interesting.
It's not for everyone. But that's just the point.
It's why I bristle when I hear suggestions we should all adopt a
single implementation as some other languages have done. CL is about
accommodating pluralism in a great many ways that is a model for more
even than just programming. I can think of some political topics that
will decide the upcoming US election that could learn from our
theories of live and let live... but I'll spare you (this time). And
anyway, maybe I'm just restating, and probably less well, what
"sharpquote" had to say earlier in another thread about morals and
design trade-offs.
On 29 nov, 17:38, Kent M Pitman <······@nhplace.com> wrote:
> It's why I bristle when I hear suggestions we should all adopt a
> single implementation as some other languages have done. CL is about
> accommodating pluralism in a great many ways that is a model for more
> even than just programming.
That's nice, and one of the reasons I'm interested on CLISP.
I have to say that my main implementation is SBCL right now. I'm not
an expert, but like to know why some real experts are prefering CLISP
over other implementations.
Javier <·······@gmail.com> wrote:
> What are actually the reasons to choose CLISP over other free
> implementations?
>
> I believe there are some. Compared to SBCL, for example:
>
> - Fast bignum operations.
> - Fast CLOS instantiations.
> - Much faster compiler speed, which is nice for big projects.
> - Better memory management. SBCL (and CMUCL) tends to do not return
> unallocated memory and wastes a lot of OS virtual memory.
_Virtual_ memory is very cheap. On a reasonable 32 Bit UNIX system
you've got about 2-3 GB (depending on the memory layout of the specific
VM) _per_ _process_. VSS (which is used address space) is rarely a
problem, RSS (resident size, actually used physical memory) is. But SBCL
isn't _that_ hungry in that regard.
> - Better memory footprint. It just need about 4 Mb of memory at
> startup.
By now, that is a historical fact turning into a myth. A freshly started
CLisp instance here on Linux is sitting at 12 MB VSS (total VM size) and
5 MB RSS (resident size in actual memory).
> - Better debugger. CLISP usually allows you to choose from more
> options when an error occurs in the debugger.
SBCL does as well, provided there _are_ options.
> - Better internationalization. Most messages are translated into
> various languages.
Honestly, I don't care about I18N for server side stuff - it is only
important for user facing stuff. And if a (non-programming) _user_ sees
error message from the Lisp system, the programmer screwed up somewhere.
> What do you think about? Any more ideas?
Sorely missed in CLisp: Multithreading.
You actually missed the most important advantage of CLisp: portability.
CLisp, being a byte-code system, is very portable and much simpler to
port than a Lisp compiling to native code. So there is CLisp on ARM, but
no SBCL. And CLisp was AFAIR the only Lisp running on Itanium a few
years back.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
From: Klaus Schilling
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <87tzn2fit4.fsf@web.de>
Javier <·······@gmail.com> writes:
> What are actually the reasons to choose CLISP over other free
> implementations?
>
> I believe there are some. Compared to SBCL, for example:
>
> - Fast bignum operations.
> - Fast CLOS instantiations.
> - Much faster compiler speed, which is nice for big projects.
> - Better memory management. SBCL (and CMUCL) tends to do not return
> unallocated memory and wastes a lot of OS virtual memory.
> - Better memory footprint. It just need about 4 Mb of memory at
> startup.
> - Better debugger. CLISP usually allows you to choose from more
> options when an error occurs in the debugger.
> - Better internationalization. Most messages are translated into
> various languages.
>
> What do you think about? Any more ideas?
Clisp has a C API,
as opposed to SBCL where such a thing is sorely missing.
and it may be compiled completely from C sources,
as opposed to SBCL.
In addition, interpreted Clisp has local eval
in a specifiable lexical environment
which lacks in most other implementations of Lisp
Klaus Schilling
On Dec 1, 6:21 pm, Klaus Schilling <···············@web.de> wrote:
> In addition, interpreted Clisp has local eval
> in a specifiable lexical environment
> which lacks in most other implementations of Lisp
>
For those wondering, SBCL has SB-INT:EVAL-IN-LEXENV.
From: Pascal Costanza
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <5reffsF13qm2iU1@mid.individual.net>
Geoff Wozniak wrote:
> On Dec 1, 6:21 pm, Klaus Schilling <···············@web.de> wrote:
>> In addition, interpreted Clisp has local eval
>> in a specifiable lexical environment
>> which lacks in most other implementations of Lisp
>
> For those wondering, SBCL has SB-INT:EVAL-IN-LEXENV.
The interesting part in clisp is that you can capture the current
lexical environment as a first-class object any time you want, and later
evaluate any code in such a lexical environment. I doubt that you can do
that in SBCL (but I'd be very interested to know if that's the case).
In other words: How do you get the lexical environments in SBCL?
The only other Lisp/Scheme implementations I am aware of that support
this are MIT Scheme and OpenLisp.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <5regevF14730iU1@mid.individual.net>
Pascal Costanza wrote:
> Geoff Wozniak wrote:
>> On Dec 1, 6:21 pm, Klaus Schilling <···············@web.de> wrote:
>>> In addition, interpreted Clisp has local eval
>>> in a specifiable lexical environment
>>> which lacks in most other implementations of Lisp
>>
>> For those wondering, SBCL has SB-INT:EVAL-IN-LEXENV.
>
> The interesting part in clisp is that you can capture the current
> lexical environment as a first-class object any time you want, and later
> evaluate any code in such a lexical environment. I doubt that you can do
> that in SBCL (but I'd be very interested to know if that's the case).
>
> In other words: How do you get the lexical environments in SBCL?
OK, Juho answered this, so that's a no.
> The only other Lisp/Scheme implementations I am aware of that support
> this are MIT Scheme and OpenLisp.
I should have said "the only currently supported Lisp/Scheme
implementations."
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Klaus Schilling
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <87tzn1bizn.fsf@web.de>
Pascal Costanza <··@p-cos.net> writes:
>
> In other words: How do you get the lexical environments in SBCL?
>
> The only other Lisp/Scheme implementations I am aware of that support
> this are MIT Scheme and OpenLisp.
>
Guile does too, via (the-environment)
Klaus Schilling
From: Pascal Costanza
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <5rgql1F14h97gU1@mid.individual.net>
Klaus Schilling wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> In other words: How do you get the lexical environments in SBCL?
>>
>> The only other Lisp/Scheme implementations I am aware of that support
>> this are MIT Scheme and OpenLisp.
>>
> Guile does too, via (the-environment)
OK, it's correct that the Guile documentation says so.
However, very obviously there is easily a mismatch between what
documentations say in this regard and what is actually the case. So far,
I have been able to test clisp, OpenLisp and MIT Scheme. Only under
clisp, I get the expected result. See the follow transcript:
[1]> (defvar *foo*)
*FOO*
[2]> (defvar *bar* (let ((x 42))
(setq *foo* (the-environment))
(lambda () x)))
*BAR*
[3]> (funcall *bar*)
42
[4]> (eval-env '(setq x 88) *foo*)
88
[5]> (funcall *bar*)
88
The same thing under OpenLisp doesn't work as expected:
? (defglobal foo nil)
;; elapsed time = 0.001s, (0 gc).
= foo
? (defglobal bar (let ((x 42))
2> (setq foo (the-environment))
2> (lambda () x)))
;; elapsed time = 0.000s, (0 gc).
= bar
? (funcall bar)
;; elapsed time = 0.000s, (0 gc).
= 42
? (eval '(setq x 88) foo)
;; elapsed time = 0.000s, (0 gc).
= 88
? (funcall bar)
;; elapsed time = 0.000s, (0 gc).
= 42
Under MIT Scheme, I don't even get that far. After typing in the
following code:
(define foo #f)
(define bar (let ((x 42))
(set! foo (the-environment)
(lambda () x)))
I get an error message telling me that the-environment can be called
only at the top level. Bleh...
So far, clisp is the clear winner here.
I haven't been able to test Guile yet, because it doesn't compile under
Mac OS X...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Klaus Schilling
Subject: Re: Reasons to choose CLISP over other free implementations
Date:
Message-ID: <87prxo8c5s.fsf@web.de>
Pascal Costanza <··@p-cos.net> writes:
> Klaus Schilling wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>> In other words: How do you get the lexical environments in SBCL?
>>>
>>> The only other Lisp/Scheme implementations I am aware of that support
>>> this are MIT Scheme and OpenLisp.
>>>
>> Guile does too, via (the-environment)
>
> OK, it's correct that the Guile documentation says so.
guile> (define myenv (let ((x 1) (y 2)) (the-environment)))
guile> (local-eval '(+ x y) myenv)
3
Klaus Schilling
On Dec 6, 10:30 pm, Klaus Schilling <···············@web.de> wrote:
> Pascal Costanza <····@p-cos.net> writes:
> > Klaus Schilling wrote:
> >> Pascal Costanza <····@p-cos.net> writes:
[[ ... ]]
> >>> The only other Lisp/Scheme implementations I am aware of that support
> >>> this are MIT Scheme and OpenLisp.
>
> >> Guile does too, via (the-environment)
>
I would like to add another data-point too for the Elk Scheme
implementation, which I'm currently using as for application delivery.
$ elk
> (the-environment)
#<environment 3082875500>
> (global-environment)
#<environment 3082875500>
> (define myenv (let ((x 1) (y 2)) (the-environment)))
myenv
> (environment->list myenv)
(((y . 2) (x . 1)) ((myenv . #<environment 3082992724>) (the-top-
level . #< ... [[snipped]]
The environment objects are basically a list/stack of "sub-
environments", all the way up to the global environment.
> (eval '(+ x y) myenv)
3
Going back to Pascal's example a few days back, and
replacing foo/bar with *descriptive* names (sorry,
pet peeve of mine, I know it's historical, but
there's an obviously better name here!):
> (define myenv #f)
myenv
> (define get-env (let ((x 42)) (set! myenv (the-environment)) (lambda () x)))
get-env
> (get-env)
42
> myenv
#<environment 3083018288>
> (eval (set! x 88) myenv)
set!: unbound variable: x
1> (reset)
> (eval ' (set! x 88) myenv)
42
> (get-env)
88
So I would say Elk has mutable first class
environments. eval is written in C.
szergling <···············@gmail.com> writes:
> I would like to add another data-point too for the Elk Scheme
> implementation, which I'm currently using as for application delivery.
When I looked for Elk more than 10 years ago in my former Schemer life, it
was quite dead. I'm amazed that it has apparently been resurrected...
Nicolas
On Dec 8, 2:02 am, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> szergling <···············@gmail.com> writes:
> > I would like to add another data-point too for the Elk Scheme
> > implementation, which I'm currently using as for application delivery.
>
> When I looked for Elk more than 10 years ago in my former Schemer life, it
> was quite dead. I'm amazed that it has apparently been resurrected...
>
> Nicolas
Hmm, I guess it all depends on how you define "dead". There's no
activity on the mailing list, and the latest maintainer, Sam Hocevar,
is probably busy running Debian, so one could say Elk is dead. But the
source code, tarballs, SVN are still available.
I found myself to be very compatible with Elk -- we mesh nicely. It is
very small and simple, and there weren't too many surprises.
For me, it was a direct competitor with Guile: I previously tried
Guile, and didn't like it. It was big, complex, over-optimised (hard
to read, my opinion only) and too hard to build. The license had
recently been changed from LGPL to GPL too, so the carpet was yanked
out from under our feet -- yeah we can fork, but that's not too
nice... In Elk, there's no advanced C macro hackery, extra
preprocessing steps or too much autoconf etc. It doesn't try to be
everything for everyone, to take over the world. The Lisp macro system
is mainly CL-style unhygienic-by-default ones, and it has call/cc, so
it suited me.
Caveat Emptor: I had had to patch a few bugs and it seems stable
now. There were a few bugs in Elk that manifested as gc invariant
violations (it says something like "Visit in previous space
...").
Most of the bugs within Elk caused the gc to do that -- doesn't matter
if you declared your types wrong, or if you cast to unsigned int
instead of int, or if you didn't nail down your variables properly for
the gc, they all appear as the same gc bug, usually after having been
moved around a few times in memory, so you cannot trace their origin
anymore (oh, add an element of chance). This reminds me of the old
'ed' joke: http://www.gnu.org/fun/jokes/ed.msg.html (cf consistent
user interface)
It really gives me an appreciation for a good implementation, with
"bug-less garbage collectors". So... it hasn't been all fun and
games. On the plus side, I know gdb much much better now (should I
feel dirty instead?).
P� Sun, 09 Dec 2007 06:36:34 +0100, skrev szergling
<···············@gmail.com>:
>
> It really gives me an appreciation for a good implementation, with
> "bug-less garbage collectors". So... it hasn't been all fun and
> games. On the plus side, I know gdb much much better now (should I
> feel dirty instead?).
>
>
If you are willing to part with Lisp then LUA is a very popular embedded
lanuage for C/C++.
It is pure ANSI C and compiles unmodified on almost all C/C++ platforms.
http://www.lua.org/
Code example to give you a taste:
function permgen (a, n)
if n == 0 then
coroutine.yield(a)
else
for i=1,n do
-- put i-th element as the last one
a[n], a[i] = a[i], a[n]
-- generate all permutations of the other elements
permgen(a, n - 1)
-- restore i-th element
a[n], a[i] = a[i], a[n]
end
end
end
function perm (a)
local n = table.getn(a)
return coroutine.wrap(function () permgen(a, n) end)
end
function printResult (a)
for i,v in ipairs(a) do
io.write(v, " ")
end
io.write("\n")
end
for p in perm{"a", "b", "c"} do
printResult(p)
end
--------------
John Thingstad
Geoff Wozniak <·············@gmail.com> writes:
> On Dec 1, 6:21 pm, Klaus Schilling <···············@web.de> wrote:
> > In addition, interpreted Clisp has local eval
> > in a specifiable lexical environment
> > which lacks in most other implementations of Lisp
>
> For those wondering, SBCL has SB-INT:EVAL-IN-LEXENV.
That's not meant for evaluating something in an arbitrary lexical
environment. It's an internal helper that will only be called with a
limited subset of possible environments (only macrolets,
symbol-macrolets, declarations allowed). Calling it with an
environment that contains something else would not produce the
expected results.
The full SBCL interpreter can of course evaluate forms in any
interpreter environment, but that doesn't help here, since there's no
way for a user to get his hands on one of those environments. (And no
such way will be added).
--
Juho Snellman
On Dec 1, 8:19 pm, Juho Snellman <······@iki.fi> wrote:
> That's not meant for evaluating something in an arbitrary lexical
> environment. It's an internal helper that will only be called with a
> limited subset of possible environments (only macrolets,
> symbol-macrolets, declarations allowed). Calling it with an
> environment that contains something else would not produce the
> expected results.
>
Hrm, yes. I've been too engrossed in this lately, I think. :)
> The full SBCL interpreter can of course evaluate forms in any
> interpreter environment, but that doesn't help here, since there's no
> way for a user to get his hands on one of those environments. (And no
> such way will be added).
>
That's a pity, but understandable.
On Nov 28, 10:56 am, Javier <·······@gmail.com> wrote:
> What are actually the reasons to choose CLISP over other free
> implementations?
>
> I believe there are some. Compared to SBCL, for example:
>
> - Fast bignum operations.
> - Fast CLOS instantiations.
> - Much faster compiler speed, which is nice for big projects.
> - Better memory management. SBCL (and CMUCL) tends to do not return
> unallocated memory and wastes a lot of OS virtual memory.
> - Better memory footprint. It just need about 4 Mb of memory at
> startup.
> - Better debugger. CLISP usually allows you to choose from more
> options when an error occurs in the debugger.
> - Better internationalization. Most messages are translated into
> various languages.
>
> What do you think about? Any more ideas?
and paul graham used it, with vi and freebsd