[Axiom-developer] Re: sock_get_string_buf

[Waldek Hebisch]

> Greetings, and thanks so much!
> 
> Waldek Hebisch <address@hidden> writes:
> 
> > I again had problem with "sock_get_string_buf": trying to use hypertex
> > functions which require Axiom (for example search or tutorial input)
> > gives:
> > 
> > (1) ->
> >    >> System error:
> >    Unexpected end of #<string-input stream from "                ...">.
> > 
> > Recent patch to gcl fixed the problem on many machines. But on one
> > machine (using 2.4.31 kerenel) I was still getting this error.
> > 
> > So I tried the patch below and it solved the problem.  AFAICS the
> > problem is that GCL string parameter wants to preserve string
> > _value_, but what Axiom want is pass by reference.  My undersanding
> > is that GCL has full right to copy the string, so the only relaiable
> > solution must use 'object' type and extract string address from it.
> > 
> > Remark1: It seems that "official" GCL foreign function interface is
> > is very incomplete for real world needs. I would suggest either
> > promoting 'object' structure as documented, official low level
> > interface, or adding few more arguments types (mostly arrays by reference).
> > 
> > Remark 2: This may be related to Debian bug 328480 (but what Camm
> > wrote seem indicate different problem).
> > 
> 
> This indeed fixes the above -- thanks!  Some axiom code must be
> declining do write to a copied buffer or some such.
> 
> May I suggest adding
> 
>           "   if (x->st.st_fillp<j) FEerror(\"string too small\",0);"
>

Yes, good idea.
 
> to the wrapper.  In general, we might want a non-null terminated
> buffer type of a given length in the C interface too.  I'm guessing
> this is what you mean by arrays by reference.  Documenting object is a
> good idea too.
> 

Typical uses I can see are:

1) calling operating system.  This typically uses scalars and strings,
   but may require structures.
2) calling numerial librarires.  Such librarires typically operate
   on floating point arrays, but may also need integer arrays.

While support for C structures would be nice, one can use arrays
of apropriate size and use Lisp byte operations to emulate C
structures.  OTOH direct support for arrays seems essential.

> Last comment -- GCL stores strings by default in relocatable memory --
> i.e. they are copied at each gc.  This is much faster.  An immovable
> type in 'contiguous" memory is also an option, via
> 
> (make-array 10 :element-type 'character :static t)
> 
> If axiom needs these pointers not to move across gc, may I please
> suggest using the latter.  I've already checked, the pointers in use
> are relocatable.
> 

AFAICS C code does not store pointers to Lisp data (and there are no
callbacks from C to Lisp). If (as I hope) GCL will not trigger garbage
collection form a signal handler, keeping strings in relocatable memory
should be safe.

-- 
                              Waldek Hebisch
address@hidden