axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: sock_get_string_buf


From: Camm Maguire
Subject: [Axiom-developer] Re: sock_get_string_buf
Date: 01 Nov 2006 16:16:51 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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);"

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.

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.

I'll apply this patch and upload a new Debian package closing the
bug.  BTW, axiom is again in Debian testing (aka etch).

Take care,

> 
> 
> diff -ru pp/build-improvements/src/interp/sockio.lisp.pamphlet 
> build-improvements/src/interp/sockio.lisp.pamphlet
> --- pp/build-improvements/src/interp/sockio.lisp.pamphlet     Sun Oct 29 
> 21:57:59 2006
> +++ build-improvements/src/interp/sockio.lisp.pamphlet        Sun Oct 29 
> 13:33:48 2006
> @@ -73,10 +73,14 @@
>  (progn
>    (clines "extern double plus_infinity(), minus_infinity(), NANQ();")
>    (clines "extern double sock_get_float();")
> +  (clines "int sock_get_string_buf_wrapper(int i, object x, int j)"
> +          "{ if (type_of(x)!=t_string) FEwrong_type_argument(sLstring,x);"
> +          "   return sock_get_string_buf(i, x->st.st_self, j); }")
>    (defentry open_server (string) (int "open_server"))
>    (defentry sock_get_int (int) (int "sock_get_int"))
>    (defentry sock_send_int (int int) (int "sock_send_int"))
> -  (defentry sock_get_string_buf (int string int) (int "sock_get_string_buf"))
> +  (defentry sock_get_string_buf (int object int) 
> +     (int "sock_get_string_buf_wrapper"))
>    (defentry sock_send_string_len (int string int) (int 
> "sock_send_string_len"))
>    (defentry sock_get_float (int) (double "sock_get_float"))
>    (defentry sock_send_float (int double) (int "sock_send_float"))
> 
> 
> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]