[Gcl-devel] Re: [Maxima] Bugs in gcl cause maxima build failures

Greetings!

Raymond Toy <toy@rtp.ericsson.se> writes:

> >>>>> "Camm" == Camm Maguire <camm@enhanced.com> writes:
> 
>     Camm> Please keep the gcl-list abreast of these hacks!  Probably all need to
>     Camm> find there way into gcl at some point.
> 
> With your latest changes, I don't really think there is a need for
> this anymore, after you fix the least-positive-normalized-single-float
> issue. :-)
> 

OK, this is now set to the unnormalized result.  I think that's right
from the spec.

>     >> >     James> ; (DEFUN IFIX ...) is being compiled.
>     >> >     James> ;; Warning: INT (in lisp package) is called as a function--not yet
>     >> >     James> defined
>     >> >     James> ; (DEFUN IDFIX ...) is being compiled.
>     >> >     James> ;; Warning: INT (in lisp package) is called as a function--not yet
>     >> >     James> defined
>     >> >     James> ; (DEFUN MAX1 ...) is being compiled.
>     >> >     James> ;; Warning: INT (in lisp package) is called as a function--not yet
>     >> >     James> defined
>     >> > 
>     >> > This looks wrong since INT is defined before these functions.
>     >> > 
> 
>     Camm> I agree.  Am looking into this.  Could this be a namespace collision?
>     Camm> My very primitve lisp knowledge would indicate that an 'export'
>     Camm> statement would only be needed were (int to be invoked outside the
>     Camm> file. 
> 
> I don't really know where this is coming from.  Is INT defined by gcl?
> I also don't understand why it says lisp package.  There's an
> in-package at the top so we're not in the Lisp package anyway.

Here is the compiler code:

	((progn
	   (and (eq (symbol-package fname) (symbol-package 'and))
		(not (fboundp fname))
		(cmpwarn "~A (in lisp package) is called as a function--not yet defined"
			 fname))


And yes, lisp::int does appear to be a symbol, with a nil plist, and
no value or function setting.  So I think we can get rid of it.
Prblem is, I can't find where it is defined.  It is mentioned in
lsp/stdlisp.lsp as a non-standard lisp symbol, but this file is not
used in the build.

If someone more in the know could investigate whether lisp::int does
anything at all, I'd be appreciative.

> 
>     >> > 
>     >> >     James> ; (DEFUN LUN->STREAM ...) is being compiled.
>     >> >     James> ;; Warning:  LUN->STREAM is proclaimed but not in *inline-functions* 
>     >> > 
>     >> > No idea what this means.  Maybe the declaim for lun->stream can be
>     >> > removed?  Not sure why that's there anymore.
>     >> 
>     >> Actually, I already know the proclaims/declaims are screwed up. One more
>     >> thing that should be fixed.
>     >> 
> 
>     Camm> Could someone please clarify the proclaims/declaims issue here?  What
>     Camm> is the purpose of *inline-functions*?  Is this variable supposed to be
> 
> I don't know.  f2cl-lib doesn't have *inline-functions*.  I assumed
> that was from gcl.
> 

OK, must be.

>     Camm> modified in f2cl-lib.lsp before defining this function in this way?
>     Camm> If someone is really kind, maybe they could even throw in a sentence
>     Camm> on the meaning of the -> syntax -- is it as in C?
> 
> I just wrote that to say I'm mapping a Fortran LUN (logical unit
> number) to a Lisp stream.  No relationship to C.
> 

OK, so just text as far as the code goes.

>     Camm> Also, can this f2cl-lib be used to generate a blas interface as well?
> 
> Yes and no.  f2cl-lib (and f2cl in general) is all about taking
> existing Fortran code and converting it to Lisp.  The result is you
> get Lisp code to compile.  The original Fortran is out of the picture.
> 

I see.  Well, the whoe point would be a matlisp interface here,
performance wise.

> So, if you don't mind having BLAS completely in Lisp, then yes, f2cl
> will give that to you.  If you really wanted to have an interface from
> a precompiled BLAS library to Lisp, then, no, f2cl doesn't really do
> that.  In principle f2cl could write out the necessary code to a
> foreign-function interface that you could use.  I haven't actually
> done this though.
> 
> If you're interested in connecting Lisp with BLAS and/or LAPACK, you
> may want to look at Matlisp (see sourceforge.net).  It only supports
> ACL and CMUCL right now.  Could work with GCL in principle, but GCL
> must store (simple-array double-float (*)) just like C would store
> double x[n], and you also need to provide some means for getting at
> the actual storage.
> 

The latter I can do, but I'm unsure about how to ensure the former,
epsecially with garbage collecting.  Do other lisps avoid splitting
arrays across pages?  If memory serves, there is a cont-block type in
gcl which does this.  Can I define a special array which lives in a
cont-block? 

>     Camm> Would a blas.o providing a gcl lisp interface into the blas (when
>     Camm> fasloaded) properly belong in the gcl package, or as a separate
>     Camm> add-on?  I'm a bit confused on what is expected to be included in a
> 
> I think that's up to you to decide what to bundle with gcl.
> 

Wow -- what power! :-) I just thought this might be useful vis-a-vis
maxima because one typically does some symbolic work, gets to a point
where no further progress is possible, and then wants to investigate
things numerically, at least in my work.  Maybe its better to just
copy/paste into octave?  Would anyone else find this useful in maxima? 

Take care,

> Ray
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah