I guess it's time I planned on creating an 'axiom-0.2' binary install
file...
I am a bit confused about the version number. NAG released 2.3. Didn't
we once say that the current gold version is Axiom 3.0? What versioning
scheme does OpenAxiom now actually have? Does somebody know? Where is
th
--- Camm Maguire <[EMAIL PROTECTED]> wrote:
> Please accept my humblest apologies for my repeated silence here --
> time management you know.
No problem - your work on GCL proper is both more important and more
likely to bear fruit. A literate Lisp may still be possible without
the direct incl
> Greetings, and thanks so much for the feedback/report! This should be
> fixed now. Releasing snapshot -70 to the Debian autobuilders...
> Take care,
ANSI version have build file, but it did not install the gcl command.
Also, during 'compiler:link' I got error about missing
'/var/tmp/hebisch/u
Camm Maguire wtote:
> Greetings, and thanks so much for the feedback/report! This should be
> fixed now. Releasing snapshot -70 to the Debian autobuilders...
Thanks, CLtL1 have build file, ANSI build is in progress. I have
noticed two little problems. One is that 'make install' did not install
The Franz Lisp system (on the VAX) had a file-compiler feature which allowed
you to
group functions that were (in today's nomenclature) private, and could only
be called
from functions in that file. It was not possible to redefine such internal
functions
without recompiling the file. The externa
On Fri, 22 Jun 2007, Waldek Hebisch wrote:
| Camm Maguire wrote:
| > 2) x64 failure -- could you please post the full log?
| >
|
| I tried cvs gcl on two different machines (both 64-bit), one
| runnimng Gentoo, the other one Debian etch. On both build
| failed. The output from configure on Deb
Greetings! Just committed a quick fix to get this working again in
the new dlopen access to external libs mechanism. More discussion
later if desired.
Warning: at present there is no limit to the number of forks -- this
is forthcoming.
Take care,
>(in-package 'si)
#<"SYSTEM" package>
SYSTEM>
Ralf Hemmecke wrote:
> On 06/22/2007 07:56 PM, Waldek Hebisch wrote:
> > Ralf Hemmecke wrote:
> >> I am pretty sure that someone can confirm that gcc has an option
> >> that compiles the #line information into the executable. I am not
> >> so sure about gcl. Camm?
> >>
> >> You don't need to deb
Greetings!
C Y <[EMAIL PROTECTED]> writes:
> --- Stephen Wilson <[EMAIL PROTECTED]> wrote:
>
> > If your working exclusively with SBCL, you /may/ be surprised when
> > you try with an ANSI 2.6.8pre. It certainly has missing features,
> > but is quite usable as a near-ansi lisp. I used to work
Greetings!
> compiler support). I do miss Slime though :(
>
Slime is on the medium term radar.
Take care,
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and
Greetings!
[ cc'ed to the maxima and axiom lists, as I would greatly appreciate
any user feedback on what they would like (that is practical) in the
forthcoming gcl release. If this is unwelcome traffic, please let me
know.]
Robert Boyer <[EMAIL PROTECTED]> writes:
> Fantastic. Thanks so much!
Greetings, and thanks so much for the feedback/report! This should be
fixed now. Releasing snapshot -70 to the Debian autobuilders...
Take care,
--
Camm Maguire[EMAIL PROTECTED]
==
BTW, I did not time it carefully but I think this build of wh-sandbox
on Windows, including running the test scripts, took significantly
less than half the time of previous versions. Great work. Thanks
again.
I guess it's time I planned on creating an 'axiom-0.2' binary install file...
Regards,
C Y <[EMAIL PROTECTED]> writes:
> --- Stephen Wilson <[EMAIL PROTECTED]> wrote:
>
> > If your working exclusively with SBCL, you /may/ be surprised when
> > you try with an ANSI 2.6.8pre. It certainly has missing features,
> > but is quite usable as a near-ansi lisp. I used to work with SBCL
> >
Bill Page wrote:
> On 6/20/07, Waldek Hebisch wrote:
> > ...
> > It looks that 'directory' implementation in GCL is rather messy, so
> > I will not try to fix it. However, you can try the following (which
> > works like the old code):
> > ...
>
> Thanks! That patch (together with two other previo
On 6/20/07, Waldek Hebisch wrote:
...
It looks that 'directory' implementation in GCL is rather messy, so
I will not try to fix it. However, you can try the following (which
works like the old code):
...
Thanks! That patch (together with two other previous patches) worked
fine. wh-sandbox now
Camm Maguire wrote:
> 2) x64 failure -- could you please post the full log?
>
I tried cvs gcl on two different machines (both 64-bit), one
runnimng Gentoo, the other one Debian etch. On both build
failed. The output from configure on Debian is at:
http://www.math.uni.wroc.pl/~hebisch/prog/clog
--- Stephen Wilson <[EMAIL PROTECTED]> wrote:
> If your working exclusively with SBCL, you /may/ be surprised when
> you try with an ANSI 2.6.8pre. It certainly has missing features,
> but is quite usable as a near-ansi lisp. I used to work with SBCL
> exclusively. But the strides GCL has made r
Hello Waldek
On 06/22/2007 07:56 PM, Waldek Hebisch wrote:
Ralf Hemmecke wrote:
I am pretty sure that someone can confirm that gcc has an option
that compiles the #line information into the executable. I am not
so sure about gcl. Camm?
You don't need to debug with sbcl. If a bug happens via
C Y <[EMAIL PROTECTED]> writes:
[...]
> I plan to show it to the world once I reach the point where I can
> successfully handle lisp, boot and spad pamphlets. Other goodies like
> the hyperdoc system and c files for sman and friends will have to come
> later. I'd like to look at alternate solutio
Greetings!
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> >> #line 56 "myalps/prtype.as.nw"
>
> > Yes, that is the best case. However, I don't know that there is a
> > general way to have the Lisp compiler preserve that information in
> > useful form in the binary. We can preserve it when we tran
--- Stephen Wilson <[EMAIL PROTECTED]> wrote:
> Hi Cliff,
>
> C Y <[EMAIL PROTECTED]> writes:
> > Well, this being Lisp, I could just program in more power, set
> > working defaults, and let the user deside. Default Lisp and boot
> > files to one behavior, spad to whatever the algebra needs, an
Ralf Hemmecke wrote:
> I am pretty sure that someone can confirm that gcc has an option that
> compiles the #line information into the executable. I am not so sure
> about gcl. Camm?
>
> You don't need to debug with sbcl. If a bug happens via SBCL and not via
> GCL then that is a bug in the comp
Hi Cliff,
C Y <[EMAIL PROTECTED]> writes:
> Well, this being Lisp, I could just program in more power, set working
> defaults, and let the user deside. Default Lisp and boot files to one
> behavior, spad to whatever the algebra needs, and have some variables
> to switch behavior around if anyone
Gaby,
On 6/20/07you wrote:
Revision: 632
http://svn.sourceforge.net/axiom/?rev=632&view=rev
Author: dos-reis
Date: 2007-06-20 14:28:50 -0700 (Wed, 20 Jun 2007)
Log Message:
---
Dissociate HyperDoc component build from X11 availability.
In particular, itis now possible to
#line 56 "myalps/prtype.as.nw"
Yes, that is the best case. However, I don't know that there is a
general way to have the Lisp compiler preserve that information in
useful form in the binary. We can preserve it when we translate to
Lisp (or C or whatever - regardless of language) but when th
--- Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
> > In general, I agree. In the specific case of intermediate
> > generated files, I would like the filenames to retain some
> > relationship to their origin to aid debugging.
>
> Again, look at ALLPROSE. The idea is that while generating the .as
>
In general, I agree. In the specific case of intermediate generated
files, I would like the filenames to retain some relationship to their
origin to aid debugging.
Again, look at ALLPROSE. The idea is that while generating the .as files
you also generate line information into that file. Someth
> In general I feel that there should be no correspondence between
> filenames and contents. The namespace and organization of files is
> not related to the namespace and organization of information.
Tim, I am happy that you share my opinion. Chunk names should be
considered like section titles:
29 matches
Mail list logo
