Hello,
I am working with LISP-in-a-box to run my LISP programs. I have two
main functions: one creates a very large list of two-element lists (on
the order of 139*139 of these two-element lists, to be exact). The
second function evaluates each of these tuples.
The first function creates the extremely large list, but then the
second function results in an ";Evaluation aborted" return (not an
error).
The second function does work on smaller subsets of this large list,
which leads me to believe that there is some memory constraint
somewhere. Or is it something else?
Thanks for your help,
Sean
Sean D. Matthews wrote:
> Hello,
>
> I am working with LISP-in-a-box to run my LISP programs. I have two
> main functions: one creates a very large list of two-element lists (on
> the order of 139*139 of these two-element lists, to be exact). The
> second function evaluates each of these tuples.
>
> The first function creates the extremely large list, but then the
> second function results in an ";Evaluation aborted" return (not an
> error).
>
> The second function does work on smaller subsets of this large list,
> which leads me to believe that there is some memory constraint
> somewhere. Or is it something else?
>
> Thanks for your help,
> Sean
Hi Sean,
Lispbox is a very old version of LISP compared to the new SBCL
releases, to my mind you really need to set up EMACS/SBCL/SLIME as a
fresh installation with all the latest binaries.
Paul
http://www.hyperstring.net
"Sean D. Matthews" <···············@gmail.com> writes:
> Hello,
>
> I am working with LISP-in-a-box to run my LISP programs. I have two
> main functions: one creates a very large list of two-element lists (on
> the order of 139*139 of these two-element lists, to be exact). The
> second function evaluates each of these tuples.
>
> The first function creates the extremely large list, but then the
> second function results in an ";Evaluation aborted" return (not an
> error).
>
> The second function does work on smaller subsets of this large list,
> which leads me to believe that there is some memory constraint
> somewhere. Or is it something else?
Check:
ARRAY-DIMENSION-LIMIT
ARRAY-RANK-LIMIT
ARRAY-TOTAL-SIZE-LIMIT
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
Thanks for the replies. I didn't know LISP-in-a-box was so old. SBCL
does not have a complete version for Windows (port in progress,
apparently), and I wanted to avoid having to install cygwin. Are there
any other options? Install the newest emacs?
-Sean
Sean D. Matthews wrote:
> Thanks for the replies. I didn't know LISP-in-a-box was so old. SBCL
> does not have a complete version for Windows (port in progress,
> apparently), and I wanted to avoid having to install cygwin. Are there
> any other options? Install the newest emacs?
>
> -Sean
Depending on your requirements, it might be sufficient to use the
evaluation versions of commercial CL 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/
"Sean D. Matthews" <···············@gmail.com> writes:
> Thanks for the replies. I didn't know LISP-in-a-box was so old. SBCL
> does not have a complete version for Windows (port in progress,
> apparently), and I wanted to avoid having to install cygwin. Are there
> any other options? Install the newest emacs?
Update the LISP-in-a-box with the latest clisp or sbcl.
Compile clisp natively on MS-Windows.
Buy or use an evaluation copy of any commercial CL implementation.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
Sean D. Matthews wrote:
> Thanks for the replies. I didn't know LISP-in-a-box was so old. SBCL
> does not have a complete version for Windows (port in progress,
> apparently), and I wanted to avoid having to install cygwin. Are there
> any other options? Install the newest emacs?
On MS Windows I have used:
Clisp from lispbox (not "lisp-in-a-box" which is older)
http://www.gigamonkeys.com/lispbox/#download
Clisp from the cygwin package.
ECL from here
http://sourceforge.net/project/showfiles.php?group_id=30035
(See ECl 0.9h which had a Windows build, 0.9i doesn't have one)
GCL from here
http://ftp.gnu.org/gnu/gcl/binaries/stable/
All of the above work. ECL's compiler only works if you have MSVC
installed unfortunately.
I've also used SBCL v0.9.12 which as advertised doesn't work entirely
reliably. Apparently v0.9.14 does work on Windows, but it requires
building, I haven't had the time to try that properly yet.
On 23 Oct 2006 06:16:39 -0700, "Rob Thorpe" <·············@antenova.com> tried
to confuse everyone with this message:
>
>I've also used SBCL v0.9.12 which as advertised doesn't work entirely
>reliably. Apparently v0.9.14 does work on Windows, but it requires
>building, I haven't had the time to try that properly yet.
>
There is a Windows installer for SBCL 0.9.17 floating around somewhere (I found
it mentioned on Planet Lisp), and it worked quite well for me. The only bug I've
found so far is (require 'asdf) sometimes going into infinite loop. Apart from
that, it didn't do anything unexpected. With little effort I ported an
application that does file input/output and sockets, among other things.
--
|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) |______________|
Timofei Shatrov wrote:
> There is a Windows installer for SBCL 0.9.17 floating around somewhere (I found
> it mentioned on Planet Lisp), and it worked quite well for me. The only bug I've
> found so far is (require 'asdf) sometimes going into infinite loop. Apart from
> that, it didn't do anything unexpected. With little effort I ported an
> application that does file input/output and sockets, among other things.
The installer for 0.9.17 is here:
http://prdownloads.sourceforge.net/sbcl/sbcl-0.9.17-x86-windows-binary.msi?download
The bug you describe happens to be a know one (if mysterious) with a
workaround: if you create shortcuts to the SBCL binary, you need to
check the compatibility option "Turn Off Advanced Text Input" (or
whatever the exact name was -- don't have my Windows box here to
check).
Cheers,
-- Nikodemus Siivola
·········@random-state.net wrote:
> The installer for 0.9.17 is here:
>
>
> The bug you describe happens to be a know one (if mysterious) with a
> workaround: if you create shortcuts to the SBCL binary, you need to
> check the compatibility option "Turn Off Advanced Text Input" (or
> whatever the exact name was -- don't have my Windows box here to
> check).
I've started using the win32 installable version of SBCL with
lispbuilder-*. I have not yet found anything to complain about. Lots of
calls via CFFI and everything seems solid enough.
Is there a reason why SBCL reserves 512MB at initial starup? It won't
run on my laptop because of this (not enough free memory).
- Luke
Rob Thorpe wrote:
> ECL from here
> http://sourceforge.net/project/showfiles.php?group_id=30035
> (See ECl 0.9h which had a Windows build, 0.9i doesn't have one)
> [...] ECL's compiler only works if you have MSVC
> installed unfortunately.
You probably mean that with ECL you need a C/C++ compiler to compile
lisp code and produce standalone executables, which is true. However,
your statement might lead people to think that ECL is locked to the
MSVC compiler, which is wrong: ECL builds also using cygwin, mingw32
and the free version of Microsoft's .NET and C++ compilers.
Juanjo
Juanjo wrote:
> Rob Thorpe wrote:
> > ECL from here
> > http://sourceforge.net/project/showfiles.php?group_id=30035
> > (See ECl 0.9h which had a Windows build, 0.9i doesn't have one)
> > [...] ECL's compiler only works if you have MSVC
> > installed unfortunately.
>
> You probably mean that with ECL you need a C/C++ compiler to compile
> lisp code and produce standalone executables, which is true. However,
> your statement might lead people to think that ECL is locked to the
> MSVC compiler, which is wrong: ECL builds also using cygwin, mingw32
> and the free version of Microsoft's .NET and C++ compilers.
Fair enough. I didn't know it could be built with mingw32 + friends
because I hadn't seen that mentioned anywhere in the docs.
That certainly makes a difference to ECL usability for me, thanks for
the info
Rob Thorpe wrote:
> Fair enough. I didn't know it could be built with mingw32 + friends
> because I hadn't seen that mentioned anywhere in the docs.
As a matter of fact, I am now rewriting the entire documentation. A
preview is uploaded periodically to
http://ecls.sourceforge.net/new-manual/
However, the homepage has always had some (perhaps a little bit hidden)
information about mingw32/cygwin and other ports:
http://ecls.sourceforge.net/install.html
For people interested on those ports, I should mention that there will
be a maintainance gap because I am switching countries and will have no
windows computers around. There are however users at the mailing list
which have so far come up with fixes for the problems we have, and at
least the MSVC port is on active use by a company, what makes it a bit
more reliable.
Juanjo
From: Markus Grueneis
Subject: Re: LISP-in-a-box or CLISP memory constraints?
Date:
Message-ID: <4q5tsuFlbqfbU1@individual.net>
Rob Thorpe wrote:
> Sean D. Matthews wrote:
>> Thanks for the replies. I didn't know LISP-in-a-box was so old. SBCL
>> does not have a complete version for Windows (port in progress,
>> apparently), and I wanted to avoid having to install cygwin. Are there
>> any other options? Install the newest emacs?
>
> On MS Windows I have used:
>
> [several implementations...]
>
> I've also used SBCL v0.9.12 which as advertised doesn't work entirely
> reliably. Apparently v0.9.14 does work on Windows, but it requires
> building, I haven't had the time to try that properly yet.
>
CUSP delivers a ready, build SBCL 0.9.17, and seems to work basically.
-- Markus
Corman Common Lisp is also an excellent choice for Win32. Eventually,
you may be inclined to actually pay the $250 to register it. The
support has been excellent, the license agreement is about as generous
as you could possibly hope for, and unlike other lisps, there is no
requirement that your software is free if you use the FFI.
pTymN wrote:
> and unlike other lisps, there is no
> requirement that your software is free if you use the FFI.
I don't believe SBCL, ACL or LW require that you GPL your code if you
use the FFI.
- Luke
"Luke Crook" <····@balooga.com> writes:
> pTymN wrote:
>> and unlike other lisps, there is no
>> requirement that your software is free if you use the FFI.
>
> I don't believe SBCL, ACL or LW require that you GPL your code if you
> use the FFI.
Even with clisp, you can use FFI in your non-free software.
What you cannot do, is to _distribute_ any non-free software that uses
#+clisp FFI or any other clisp specific package.
Of course, there are very simple solutions.
You can write your software using CFFI instead of FFI, and since CFFI
works on any other Common Lisp implementation, then you can distribute
your lisp program non Free, even if you happen to compile it on clisp.
But notice that you still must distribute clisp with its sources, and
free license, and allow users to modify clisp under your program. So
you must provide .fas files, you cannot distribute your non free
program as a clisp executable image or even just as a loadable image.
All the point of GPL, is to allow the "users" to correct a bug in the
free software even when it's used inside proprietary software. When
you distribute your proprietary program as .fas files, with clisp
sources, if there is a bug in clisp, the users can correct the bug in
clisp and load again your .fas files.
IANAL, this is just my understanding of clisp's licensing.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?