[Top][All Lists]
[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