Re: display bug, was: Maxima rtestint failures with GCL 2.6.14

On 4/9/24 10:40, Robert Dodier wrote: On Mon, Apr 8, 2024 at 8:36 AM Robert Dodier wrote: Running tests in rtestint: ** Problem 56 *** Input: cos(x) integrate(--, x, minf, inf) 2 x + 1 Result: - 12 %e(%e + 1) %pi --- 2 This

Re: display bug, was: Maxima rtestint failures with GCL 2.6.14

On 4/9/24 10:40 AM, Robert Dodier wrote: On Mon, Apr 8, 2024 at 8:36 AM Robert Dodier wrote: Running tests in rtestint: ** Problem 56 *** Input: cos(x) integrate(--, x, minf, inf) 2 x + 1 Result: - 12 %e(%e + 1) %pi --- 2 This

Re: Maxima rtestint failures with GCL 2.6.14

On 4/9/24 10:37, Robert Dodier wrote: I've chased this bug into MTOSC in src/defint.lisp, where it seems to have something to do with the functions RIB, CSEMIUP, and CSEMIDOWN. There are a couple of special variables BPTU and BPTD which are supposed to tie those together. Could be a bug in the

Re: Maxima rtestint failures with GCL 2.6.14

On 4/8/24 8:36 AM, Robert Dodier wrote: The current version of Maxima (00fcc04) bumps into several failures in rtestint when compiled with GCL 2.6.14. GCL advertises itself as: GCL (GNU Common Lisp)  2.6.14 Fri Jan 13 10:47:56 AM EST 2023  ANSI    git: Version_2_6_14 The failures start

Re: [Maxima-discuss] Careful arithmetic ... was Re: +-Inf and NaN

On Tue, Mar 5, 2024 at 6:05 AM Camm Maguire wrote: > Greetings! > > Richard Fateman writes: > > > 2. fix sbcl flags so that the handler still works after the first > floating-point error.. > > Not sure about sbcl, but this sounds like the standard IEEE SIGFPE > handling in which it is

Re: [Maxima-discuss] Careful arithmetic ... was Re: +-Inf and NaN

;>> some task that's >>>>> >>>>> never been researched before in SW. >>>>> >>>>> >>>>> >>>>> Re: uninitialized/missing data: >>>>> >>>>> >>>>> >>>>&

Re: +-Inf and NaN

On Wed, Feb 28, 2024 at 7:38 AM Stavros Macrakis wrote: > On Wed, Feb 28, 2024 at 10:12 AM Raymond Toy > wrote: > >> On Wed, Feb 28, 2024 at 5:44 AM Camm Maguire >> wrote: >> >>> ... >>> > I hope you will consider changing the default to

Re: +-Inf and NaN

On Wed, Feb 28, 2024 at 5:44 AM Camm Maguire wrote: > Greetings! > > Raymond Toy writes: > > > On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire > wrote: > > > > Greetings, and thanks to all for the very helpful feedback! > > > > I'd also like t

Re: +-Inf and NaN

On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire wrote: > Greetings, and thanks to all for the very helpful feedback! > > > > I'd also like to note in passing that the excellent SBCL out of the box > triggers an error, which we separately refer to as an 'exception trap', > when NaN is passed to the

Re: [Maxima-discuss] +-Inf and NaN

On Thu, Feb 22, 2024 at 5:01 PM James Cloos wrote: > > "SM" == Stavros Macrakis writes: > > SM> Lisp arithmetic should be compatible with IEEE float arithmetic. > > There are cases where other forms of floats make sense. > > Such as posits or arbitrary precision floats. > > (The underlying

Re: +-Inf and NaN

On Wed, Feb 21, 2024 at 2:13 PM Richard Fateman wrote: > One rationale for NaNs is based on the assumption that you might have > pipelined/ vector/ etc > computers where an "interrupt" in impossible -- it may happen at a time > and place that no longer exists. > So the NaN is carried along and

Re: +-Inf and NaN

On Wed, Feb 21, 2024 at 1:20 PM Stavros Macrakis wrote: > On Wed, Feb 21, 2024 at 1:46 PM Raymond Toy wrote: > >> ... >> I think CLHS isn't really super clear on IEEE floats. >> > > CL was defined before IEEE floats existed. > I used to think that too, so I c

Re: [Maxima-discuss] +-Inf and NaN

y Lisp that runs on a GPU (as opposed to the CPU), so I'm not sure the GPU number support is relevant here. > look to them for inspiration > of how to proceed. > > -Original Message----- > From: Camm Maguire > Sent: Feb 21, 2024 7:55 AM > To: Raymond To

Re: +-Inf and NaN

On Wed, Feb 21, 2024 at 7:54 AM Camm Maguire wrote: > Greetings, and thanks for your feedback! > > Raymond Toy writes: > > > When a is a floating-point number (= a a) should not be optimized to > > T. Likewise (/= a a) should not be optimized to NIL. I'm pretty sure &

Re: +-Inf and NaN

mely minor gain. > > As for most-positive-long-float, I am fine with interpreting that > as most-positive-long-finite-float. > Same. > > On Wed, Feb 21, 2024 at 10:54 AM Camm Maguire > wrote: > >> Greetings, and thanks for your feedback! >> >> Raymond Toy writes:

Re: +-Inf and NaN

On Tue, Feb 20, 2024 at 3:19 PM Camm Maguire wrote: > Greetings! I know this has been discussed before, but I would like to > explore the possibility of defining these bit patterns as members of a > special type orthogonal to common-lisp::number. This is prompted by the > NaN blockage on the

Re: enough-namestring doesn't work?

mestring is the shortest reasonable string that will satisfy this criterion. It is not necessarily possible to construct a valid namestring by concatenating some of the three shorter namestrings in some order. = Perhaps this

enough-namestring doesn't work?

I tried the followin: |(enough-namestring #P"/a/b/c/d.txt" #P"/a/b/")|. I was expecting |"c/d.txt"|. But gcl 2.6.13 release returns “/a/b/c/d.txt”. I actually can’t find any example where |enough-namestring| produces anything other than the namestring for the first arg. How do I invoke

Re: [Maxima-discuss] gcl-2.6.14 released [stable]

ing out what happened easier and git bisect easier too. > > I say your very helpful bug report at savannah -- thanks! They indeed > seem to have changed the web interface so that no one can close bugs. > I'll correspond with them on this. > > Take care, > > Robert Dodie

Adding --version command line option

It would be nice if gcl supported a --version option to print out the gcl version. This should probably just print out what (lisp-implementation-version) prints, for consistency. Handy for scripts that want or need to know the version. More convenient than having to figure out how to use -eval

Re: [Maxima-discuss] gcl-2.6.13 released [stable]

On Sat, Jan 14, 2023 at 3:40 PM Richard Fateman wrote: > It would be interesting to hear of a few benchmarks. What observations to > make? > > WASM advocates seem to hold that WASM code > executes fast and efficient. > >From what I remember people at work saying, wasm was about 2-3 times

Re: [Maxima-discuss] gcl-2.6.13 released [stable]

On Sat, Jan 14, 2023 at 11:19 AM Henry Baker wrote: > Re: emscripten version of ECL: > > You can attempt to build it yourself: > > https://gitlab.com/embeddable-common-lisp/ecl/-/tree/emscripten That is really cool! I didn't know that ecl was working on it. > > > -Original Message-

Re: [Maxima-discuss] gcl-2.6.13 released [stable]

On Sat, Jan 14, 2023 at 9:31 AM Oscar Benjamin wrote: > I don't know GCL or Lisp at all really but according to wikipedia GCL > "produces native object code by first generating C code and then > calling a C compiler". If that's correct then in combination with a C > compiler that generates WASM

Re: 2.6.14pre5 fails to compile (with gcc 12.2.1, Fedora)

On Tue, Jan 10, 2023 at 8:42 AM Camm Maguire wrote: > Greetings, and thanks for your report! Could you please checkout/pull > Version_2_6_14pre (not tagged yet) and retry, sending me your > config.log? Should be the same mod committed yesterday for centos. > Ah, that works great. Compiles

2.6.14pre5 fails to compile (with gcc 12.2.1, Fedora)

Updated my git repo and set the branch to Version_2_6_14pre5. Did a make clean then ran 'configure --prefix=$HOME/dev --enable-ansi" and finally make. I get many errors now. Here's the first few: gcc -c -fsigned-char -pipe -fcommon -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie

Re: gcl-2.6.13 released [stable]

On Sat, Jan 7, 2023 at 10:10 AM Camm Maguire wrote: > Greetings! Correct -- my upload was rejected for an as yet undetermined > signature verification failure. I am corresponding with them about it, > and received my first reply yesterday. > Will there be an updated version of 2.6.13 that

Re: gcl-2.6.13 released [stable]

out clang -- would love to see the whole build log. I just > did a successful build on debian unstable with clang 1:14.0-55.3. > > Take care, > > Raymond Toy writes: > > > On Wed, Dec 21, 2022 at 12:37 PM Raymond Toy > wrote: > > > > On Wed, Dec 21, 2022 at 9

Re: gcl-2.6.13 released [stable]

On Wed, Dec 21, 2022 at 12:37 PM Raymond Toy wrote: > > > On Wed, Dec 21, 2022 at 9:23 AM Camm Maguire > wrote: > >> Greetings, and thanks so much for your feedback! >> >> My strong guess is that you are using gcc-12. There is a known bug >> therein preve

Re: gcl-2.6.13 released [stable]

gcc <= 11. You should be > able to do CC=gcc-11 ./configure when building gcl and that will > take care of it. > > Take care, > > Raymond Toy writes: > > > On Tue, Dec 20, 2022 at 10:58 AM Camm Maguire < > c...@transcendence.maguirefamily.org> wrote: >

Re: gcl-2.6.13 released [stable]

On Tue, Dec 20, 2022 at 10:58 AM Camm Maguire < c...@transcendence.maguirefamily.org> wrote: > > Greetings! The GCL team is happy to announce the release of version > 2.6.13, the latest achievement in the 'stable' (as opposed to > 'development') series. Please see

Re: Windows [ was Re: [Maxima-discuss] GCL Version_2_6_13pre125 ]

On Mon, Nov 21, 2022 at 8:00 AM Camm Maguire wrote: > Greetings! > > I have followed your very helpful suggestion below, and restored the > mingw32 build in a virtualbox. > > As 64bit seems required nowadays, I've gotten cygwin64 ready as well, > all up to well known and documented fork()

Re: [Gcl-devel] File load algorithm

te it > > or use of of the DEFSYSTEMs. > > > > -- J. > > > > > > On 12 November 2015 at 16:21, Camm Maguire > wrote: > >> Greetings! > >> > >> Blake McBride writes: > >> > >>> O

Re: [Gcl-devel] [Maxima-discuss] gcl memory usage

> "Camm" == Camm Maguire writes: Camm> Greetings! Camm> Gunter Königsmann writes: >> >> @camm: Is there a way to manually trigger the garbage collector in gcl? >> Camm> (si::gbc t) will collect everything. One can

Re: [Gcl-devel] #n= syntax

> "Camm" == Camm Maguire writes: Camm> Greetings! The ansi-spec describes n as an unsigned decimal, but all Camm> lisp printers I have seen start n at 1. Is there any problem starting it Camm> at 0? Didn't see anything in the spec that says it can't

Re: [Gcl-devel] [Maxima-discuss] Ansi change in upcoming gcl release

> "Camm" == Camm Maguire writes: Camm> Greetings! There are ways to make this patch backward compatible. I Camm> was soliciting suggestions. On the face of it, I have no objections to this change, but I think it's up to you to provide some hints on how to

Re: [Gcl-devel] File load algorithm

> "Camm" == Camm Maguire writes: Camm> Here is a somewhat crazy idea which is nonetheless related to the Camm> pathname work I'm doing now. What about supporting version :newest, Camm> with non-wildcard pathnames containing this referring to the pathname,

Re: [Gcl-devel] File load algorithm

> "Camm" == Camm Maguire writes: Camm> Greetings! Thanks for the suggestion! An interesting idea -- let me Camm> cogitate on it It would be nice if gcl would look for foo.lsp and foo.lisp. It seems nowadays most people use "lisp" as the extension, and

Re: [Gcl-devel] gcl vs sbcl vs ccl

>>>>> "Andrey" == Andrey G Grozin <a.g.gro...@inp.nsk.su> writes: Andrey> On Sat, 10 Oct 2015, Raymond Toy wrote: >> What is the advantage of a 64-bit lisp for maxima? It's not like >> being able to manipulate expressions taking GBs

Re: [Gcl-devel] gcl vs sbcl vs ccl

> "Gunter" == Gunter Königsmann writes: Gunter> The things I have solved by switching to a 64-bit linux so far are: Gunter>  - misusing wxMaxima as a replacement of excel that isn't Gunter> limited to a million cells or so. A million cells doesn't seem so

Re: [Gcl-devel] gcl vs sbcl vs ccl

> "Gunter" == Gunter Königsmann writes: Gunter> If that Means we might have a chance to get a 64-bit Gunter> maxima for windows... ... Then I'm an for it. What is the advantage of a 64-bit lisp for maxima? It's not like being able to manipulate expressions

Re: [Gcl-devel] Package ansification in upcoming GCL 2.6.13

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! It is my intention to have the next GCL release, hopefully Camm in about a month, have a fully compliant :cl package, e.g. with only the Camm standard symbols exported. There will be a :cltl1-compat package with

Re: [Gcl-devel] utf8 and emacs text/string multibyte representation

Matt == Matt Kaufmann kaufm...@cs.utexas.edu writes: Matt I saw your question and was curious, so I looked into it a bit: To your knowledge, is there any objection to defining alpha-char-p as including code-char's = 128? Matt I see that SBCL 1.2.2 is OK with that, for example:

Re: [Gcl-devel] utf8 and emacs text/string multibyte representation

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! One other thing -- any opinions on using locales and wchar_t Camm for conversions? Camm Is there really any other (than utf-8) external encoding that needs Camm support in a common lisp, practically speaking?

Re: [Gcl-devel] utf8 and emacs text/string multibyte representation

Matt == Matt Kaufmann kaufm...@cs.utexas.edu writes: Matt Hi -- Matt I think you and Camm know more about this than I do, but to answer Matt your question, below is what I get in GCL 2.6.12. Except, I don't Matt know how mailers handle high characters of the sort GCL printed in

Re: [Gcl-devel] utf8 and emacs text/string multibyte representation

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings, and thanks so much! I think we are converging... Camm 1) The proposal under consideration is due to Carl, that gcl's lisp Camm character still be governed by char-code-limit==256, i.e. equivalent to Camm an

Re: [Gcl-devel] utf8 and emacs text/string multibyte representation

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! I've recently been considering supporting unicode in gcl by Camm representing strings internally in utf8. It appears that emacs does the Camm same or similar. Apart from the obvious memory footprint benefits,

Re: [Gcl-devel] rtest8.mac test failure

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! When compiling some functions that were previously Camm interpreted under gcl, I have one small test failure on 32bit intel Camm only: Camm ev (e7, alfa=2, vita=1); (of rtest8.mac) Camm returns Camm

Re: [Gcl-devel] libopcodes

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! I am considering releaseing a SIGFPE handler in 2.6.11. For Camm example, here is how it works: (si::break-on-floating-point-exceptions :division-by-zero t) Presumably there are other keyword args for the other

Re: [Gcl-devel] subprojects

Camm == Camm Maguire c...@maguirefamily.org writes: I've some experience with submodules, if you'd like to run that route, I may be able to iron out any bumps; the biggest gotcha is generally to commit (and push) any changes in the submodule first, then push the containing

Re: [Gcl-devel] subprojects

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! We provide a convenience copy of gmp in our sources in all Camm versions, and one of binutils in master. I'm asking here for advice on Camm how to manage these using git. Ideally we'd just eliminate them, but I

Re: [Gcl-devel] call-arguments-limit

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! Henry Baker hbak...@pipeline.com writes: Does GCL use some sort of bit mask for argument lists? That's fine, but I'm having trouble understanding when a bit mask will be useful beyond -- e.g., 32

Re: [Gcl-devel] call-arguments-limit

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! Raymond Toy toy.raym...@gmail.com writes: Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! Henry Baker hbak...@pipeline.com writes: Does GCL use some sort of bit mask

Re: [Gcl-devel] Compiling GCL

Far == Far Far writes: Far Exploring http://www.reddit.com/r/lisp/ I realized that GCL 2.6.8 and Far 2.6.9 had been released. Congratulations! Far I'm not sure what happened to the GCL 2.7.0 code that was once made Far available in Debian, and when compiling your code from git

Re: [Gcl-devel] Can't print 1d-6

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings, and thanks so much for your report! I think this is fixed Camm now. Thanks! Which branch did you fix it on? Ray ___ Gcl-devel mailing list Gcl-devel@gnu.org

Re: [Gcl-devel] 2.6.9

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! As time permits, if anyone can provide feedback as to the Camm desirability of the changes in 2.6.9, that would be most appreciated. Camm If needed, I could post a short tutorial on the effects of the Camm

Re: [Gcl-devel] 2.6.9

Gabriel == Gabriel Dos Reis g...@integrable-solutions.net writes: Gabriel On Mon, Jun 10, 2013 at 10:42 PM, Raymond Toy toy.raym...@gmail.com wrote: I do have a couple of items on my wishlist: an implementation of ensure-directories-exist I tried sometime ago to use gcl's ffi

Re: [Gcl-devel] ASDF 2.32 released

Fare == Far Far writes: Fare On Wed, Mar 6, 2013 at 10:12 AM, Jerry James loganje...@gmail.com wrote: I maintain the GCL package for Fedora. I gave up on 2.6.7 over 4 years ago; it just won't build on modern Linux systems. But I've been building the 2.6.8pre branch

Re: [Gcl-devel] ASDF 2.32 released

Jerry == Jerry James loganje...@gmail.com writes: Jerry On Wed, Mar 6, 2013 at 11:39 AM, Raymond Toy toy.raym...@gmail.com wrote: The ancient 2.6.8pre was much better at compliance than 2.6.7. I think 2.6.8 is even better, but I suspect it might still be missing some things

Re: [Gcl-devel] Building GCL from CVS on Ubuntu 12.04

Camm == Camm Maguire c...@maguirefamily.org writes: Camm I haven't updated cvs head recently as I've been trying to Camm solidify the experimental branch, which I hope to make the Oh. Maybe I should try the experimental branch. Why do you need a heap ceiling? How would I find

Re: [Gcl-devel] Building GCL from CVS on Ubuntu 12.04

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings, and thanks! Here is the version from experimental, which Camm (hopefully) will shortly be cvs head: Cammheap_ceiling=0x`/bin/cat /proc/self/maps | egrep /lib/([[^/]]*/)?ld Camm| cut -f1 -d- | head -1`

Re: [Gcl-devel] [Maxima] Out of range floating point number determination

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings, and thanks! Camm Raymond Toy toy.raym...@gmail.com writes: Don't know about the value fop or foff regs. But as I understand it, the sse instructions signal exceptions at the offending instruction, unlike

Re: [Gcl-devel] [Maxima] Stable Maxima version on Gentoo

Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! Camm Raymond Toy toy.raym...@gmail.com writes: Camm == Camm Maguire c...@maguirefamily.org writes: Camm Greetings! Camm Stewart W. Wilson wil...@prediction-dynamics.com writes: The fix

Re: [Gcl-devel] [Maxima] Out of range floating point number determination

Camm == Camm Maguire c...@maguirefamily.org writes: Camm I've got something working for the x87, but as far as I can see, there Camm is no pertinent sse information passed in ucontext_t to the sighandler Camm (e.g. like the fpregs for the x87). Furthermore, the chip does not set

[Gcl-devel] Re: 2.6.8 licensing

On 11/5/10 9:52 AM, Camm Maguire wrote: Greetings, and thanks so much for this! I've been asked to query -- are there any GPLv2 only projects using GCL? If so, please now so state. I think maxima is GPLv2 only. GCL isn't the only Lisp that can be used with maxima, but it has historically

[Gcl-devel] Re: frozen defstructs

Camm Maguire wrote: Greetings! GCL can optimize predicates for 'frozen' defstructs, which can be indicated by calls to (si::freeze-defstruct 'foo) or (setq compiler::frozen-defstructs* t). The default for the latter is nil. As the standard states that redefining a defstruct can have

[Gcl-devel] Signaling floating-point overflow?

Does gcl signal an arithmetic-error on floating-point overflow? I vaguely remember that it did, but my gcl 2.6.8 build (solaris) does something and produces an error about printing a non-number. I guess that means an infinity was generated? Can I make gcl produce an arithmetic-error on FP

[Gcl-devel] Accessing mkdir?

Can any one help me to get gcl to allow me to call mkdir? I've tried a few obvious things, but everyone fails when loading the generated .o file. It says it can't find mkdir. :-( Am I missing something? Oh, I've been using gcl 2.6.7 and 2.6.8pre-something for this, if it matters. Ray

[Gcl-devel] Re: Building gcl from cvs?

Camm Maguire wrote: Greetings! Raymond Toy [EMAIL PROTECTED] writes: Camm Maguire wrote: GCL has certain build dependencies, a working C compiler and libc development header environment being among them. Conventionally, GCL also requires binutils-dev and libgmp3-dev at build time

[Gcl-devel] Re: Building gcl from cvs?

Camm Maguire wrote: GCL has certain build dependencies, a working C compiler and libc development header environment being among them. Conventionally, GCL also requires binutils-dev and libgmp3-dev at build time, but there are local snapshots of these libraries to make do in a pinch. The GMP

[Gcl-devel] pathname-directory and other pathname issues

Consider the following: (pathname-directory #p/abc/def/g.lsp) - (:root abc def) (pathname-directory #pabc/g.lsp) - (abc) (make-pathname :directory '(:absolute a)) - #pABSOLUTE/a (make-pathname :directory '(:relative a)) - #pRELATIVE/a (make-pathname :directory '(:root a :wild-inferiors)) -

[Gcl-devel] Re: printing IEEE 754 special values (inf, nan)

Robert Dodier wrote: Hello Camm, Greetings! I could probably implement 'Inf' an 'NaN' as the print forms of these float pretty trivially -- the question is whether the reader must be modified to read them in, and what are the compliance issues if any. Well, maybe some special symbols can

[Gcl-devel] Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]

Camm Maguire wrote: Raymond Toy writes: On the sparc port, this area can be zeroed out with appropriate optimization settings. I ran some tests using Eric Marsden's cl-bench. If the stack is always cleared, the cost of some benchmarks go up, but some go down, because the cost of GC