headers
clisp-cvs-request | 3 Jan 2005 12:19
Picon

clisp-cvs digest, Vol 1 #880 - 4 msgs

Send clisp-cvs mailing list submissions to
	clisp-cvs <at> lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	clisp-cvs-request <at> lists.sourceforge.net

You can reach the person managing the list at
	clisp-cvs-admin <at> lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."

CLISP CVS commits for today

Today's Topics:

   1. clisp/src lispbibl.d,1.595,1.596 stream.d,1.488,1.489 io.d,1.265,1.266
ChangeLog,1.3993,1.3994 (Bruno Haible)
   2. clisp/src NEWS,1.219,1.220 constobj.d,1.160,1.161 encoding.d,1.118,1.119
foreign.d,1.124,1.125 ChangeLog,1.3994,1.3995 (Bruno Haible)
   3. clisp/doc impext.xml,1.306,1.307 (Bruno Haible)
   4. clisp/src foreign1.lisp,1.72,1.73 ChangeLog,1.3995,1.3996 (Bruno Haible)

--__--__--

Message: 1
From: Bruno Haible <haible <at> users.sourceforge.net>
To: clisp-cvs <at> lists.sourceforge.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Haible | 3 Jan 2005 13:07

Re: :MOP in *FEATURES*

Sam wrote:
> >   - Programs which need the MOP just need it. There are no "workarounds"
> >     to make similar functionality available in an implementation that doesn't
> >     have the MOP.
>
> #+(and clisp mop)
> allows distinguishing between 2.33 and 2.34

If you have a concrete use for this, in clocc/port for example, please add
the :MOP.

Bruno

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 0 comments |
headers
Sam Steingold | 3 Jan 2005 17:10
Picon

Re: clisp/src foreign1.lisp,1.72,1.73 ChangeLog,1.3995,1.3996

> * Bruno Haible <unvoyr <at> hfref.fbheprsbetr.arg> [2005-01-03 11:18:48 +0000]:
>
> Update of /cvsroot/clisp/clisp/src
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25312/src
>
> Modified Files:
> 	foreign1.lisp ChangeLog 
> Log Message:
> Indentation fixes.

I am confused.
1. why do you need a ChangeLog entry for that?

2. why do you indent by 2 characters here?

>                        (let* ((reserved-list
> -                              '("auto" "break" "case" "char" "continue"
> -                                "default" "do" "double" "else" "enum" "extern"
> -                                "float" "for" "goto" "if" "int" "long"
> -                                "register" "return" "short" "sizeof" "static"
> -                                "struct" "switch" "typedef" "union" "unsigned"
> -                                "void" "while"))
> +                               '("auto" "break" "case" "char" "continue"
> +                                 "default" "do" "double" "else" "enum" "extern"
> +                                 "float" "for" "goto" "if" "int" "long"
> +                                 "register" "return" "short" "sizeof" "static"
> +                                 "struct" "switch" "typedef" "union" "unsigned"
> +                                 "void" "while"))
>                               (reserved-table
>                                 (make-hash-table :key-type 'string :value-type '(eql t)
(Continue reading)

Permalink | Reply | 502 comments |
headers
Sam Steingold | 3 Jan 2005 17:21
Picon

Re: clisp/src NEWS,1.219,1.220 constobj.d,1.160,1.161 encoding.d,1.118,1.119 foreign.d,1.124,1.125 ChangeLog,1.3994,1.3995

> * Bruno Haible <unvoyr <at> hfref.fbheprsbetr.arg> [2005-01-03 11:16:29 +0000]:
>
> +  O(foreign_8bit_encoding) =
> +    (TheEncoding(O(foreign_encoding))->max_bytes_per_char == 1
> +     ? O(foreign_encoding)
> +     : Symbol_value(S(ascii)));

IMO, this is wrong: ASCII is only a partial encoding, so if the
character is non-7-bit, there will be an error even though the character
fits into 8 bits fine.  Whenever ASCII is used but not explicitly
requested, there must be a warning.

I suggest that is the *FOREIGN-ENCODING* is 1:1, it is used for
CHARACTERs too, but when it is not 1:1, CHAR-CODE is used instead.

If CHAR-CODE is above 256, an error is signaled.

An (ugly) alternative is to have a separate *FOREIGN-CHAR-ENCODING*.

TRT is to treat CHARACTER as equivalent to C uint32 instead of C char.

--

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Any programming language is at its best before it is implemented and used.

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bruno Haible | 3 Jan 2005 17:39

Re: clisp/src foreign1.lisp,1.72,1.73 ChangeLog,1.3995,1.3996

Sam wrote:
> > Indentation fixes.
>
> I am confused.
> 1. why do you need a ChangeLog entry for that?

Because I touched the code, not just comments.

> 2. why do you indent by 2 characters here?

Because that's how clisp/src/CodingStyle specifies it.

> everyone else (CLHS, CLTL, Emacs) indents by 1 character here.

And the effect is that sometimes it gets hard to understand the semantic
level of indentation. Look at this.

                               (C-FUNCTION
                                (list (list ':arguments
                                            (do ((args (coerce (svref ctype 2) 'list) (cddr args))
                                                 (i 1 (+ i 1))
                                                 (argspecs '()))
                                                ((null args) (nreverse argspecs))
                                              (let ((argtype (first args))
                                                    (argflags (second args)))
                                                (push `(,(intern (format nil "arg~D" i) compiler::*keyword-package*)
                                                        ,(deparse argtype)
                                                        ,(cond ((flag-set-p argflags ff-flag-out) ':OUT)
                                                               ((flag-set-p argflags ff-flag-in-out) ':IN-OUT)
                                                               (t ':IN))
(Continue reading)

Permalink | Reply | 502 comments |
headers
Bruno Haible | 3 Jan 2005 17:59

Re: multibyte *FOREIGN-ENCODING*

Sam wrote:
> > +  O(foreign_8bit_encoding) =
> > +    (TheEncoding(O(foreign_encoding))->max_bytes_per_char == 1
> > +     ? O(foreign_encoding)
> > +     : Symbol_value(S(ascii)));
>
> IMO, this is wrong: ASCII is only a partial encoding, so if the
> character is non-7-bit, there will be an error even though the character
> fits into 8 bits fine.

The character can fit into 8 bits, but will not fit into a single 'char'
when part of a multibyte string.

Take, for example, *FOREIGN-ENCODING* = UTF-8, and a character like 'ß'.
On the clisp side, it's a 'chart' with value 0xDF. As part of a string,
this character is coded as  { (char)0xC3, (char)0x9F }. The fact that
0xDF < 0x100 is irrelevant. If a conversion therefore wants 1 'char' per
Unicode character, you have to give an error on non-ASCII characters.

> Whenever ASCII is used but not explicitly
> requested, there must be a warning.

*FOREIGN-ENCODING* is used in most cases. The cases where ASCII is used
instead of *FOREIGN-ENCODING* are documented and rare (such as single
characters or multidimensional arrays of characters).

> I suggest that is the *FOREIGN-ENCODING* is 1:1, it is used for
> CHARACTERs too, but when it is not 1:1, CHAR-CODE is used instead.

This would be wrong: When the C side uses UTF-8 as its encoding, and
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruno Haible | 3 Jan 2005 18:04

back_trace and funcall

Hi,

The back_trace facility currently has the following bugs:
  1) The bt_caller field is a misnomer: it contains actually the callee,
     not the caller.
  2) The <n> entries in the (show-stack), backtrace-1, up/down printout
     are at different positions, depending on which of the three functions
     is called.
  3) The <n> entries actually mark a function/fsubr invocation, but their
     position in the stack trace does not correspond exactly to the point
     where the function was invoked.
  4) The meaning of the <n> entries is not clear for a user.
  5) Some <n> entries are followed by an integer that has no obvious meaning,
     such as #<SYSTEM-FUNCTION MAPCAR> 0.
  6) The integer n in <n> is useless, because up/down print always <0>,
     regardless of the number of the frame in backtrace-1 or (show-stack).
  7) The backtrace-1 output begins with a dozen of <n> entries that should
     be masked out by the *frame-limit...* facilities.
  8) In mode-1, up/down should walk the stack 1 element at a time. It is
     confusing that sys::describe-frame prints 2 elements when one of them
     is a <n> entry.

I can fix all this, but there's more to back_trace than just a stack trace
extension. It's actually part of the function call convention. And it needs
to be extended if we want to allow the user to access function arguments and
local variables of compiled closures. So I want to rethink it from the
beginning:

  - How does the function call convention need to be modified in order to
    allow access to function arguments and local variables?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sam Steingold | 3 Jan 2005 18:35
Picon

Re: clisp/src foreign1.lisp,1.72,1.73 ChangeLog,1.3995,1.3996

> * Bruno Haible <oehab <at> pyvfc.bet> [2005-01-03 17:39:35 +0100]:
>
> Sam wrote:
>> > Indentation fixes.
>>
>> I am confused.
>> 1. why do you need a ChangeLog entry for that?
>
> Because I touched the code, not just comments.

even though a "tree diff" will not detect anything?!
how can this ChangeLog entry be useful?
what bugs it will help detect?

>> 2. why do you indent by 2 characters here?
> Because that's how clisp/src/CodingStyle specifies it.

this should be fixed.

>> everyone else (CLHS, CLTL, Emacs) indents by 1 character here.
>
> And the effect is that sometimes it gets hard to understand the
> semantic level of indentation. Look at this.

I cannot look at the code which does not fit in 80 columns :-)

> Is the opening parenthesis in the last line here under the
>   (C-FUNCTION
> or under the
>   (list (list ':arguments
(Continue reading)

Permalink | Reply | 4 comments |
headers
Sam Steingold | 3 Jan 2005 18:56
Picon

Re: multibyte *FOREIGN-ENCODING*

> * Bruno Haible <oehab <at> pyvfc.bet> [2005-01-03 17:59:27 +0100]:
>
> Sam wrote:
>> > +  O(foreign_8bit_encoding) =
>> > +    (TheEncoding(O(foreign_encoding))->max_bytes_per_char == 1
>> > +     ? O(foreign_encoding)
>> > +     : Symbol_value(S(ascii)));
>>
>> IMO, this is wrong: ASCII is only a partial encoding, so if the
>> character is non-7-bit, there will be an error even though the character
>> fits into 8 bits fine.
>
> The character can fit into 8 bits, but will not fit into a single
> 'char' when part of a multibyte string.
>
> Take, for example, *FOREIGN-ENCODING* = UTF-8, and a character like 'ß'.
> On the clisp side, it's a 'chart' with value 0xDF. As part of a string,
> this character is coded as  { (char)0xC3, (char)0x9F }. The fact that
> 0xDF < 0x100 is irrelevant. If a conversion therefore wants 1 'char' per
> Unicode character, you have to give an error on non-ASCII characters.

let me be more clear.
Consider the 8-bit 1:1 encoding which maps
        $c\in[0;255]$
to
        (CODE-CHAR c)
this encoding might already have a name; if it does not, it should be
created and named ASCII-Extended or something.

This encoding, and _NOT_ ASCII, should be used when *FOREIGN-ENCODING*
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruno Haible | 3 Jan 2005 19:35

Re: clisp/src foreign1.lisp,1.72,1.73 ChangeLog,1.3995,1.3996

Sam wrote:
> >> 1. why do you need a ChangeLog entry for that?
> >
> > Because I touched the code, not just comments.
>
> even though a "tree diff" will not detect anything?!

Where is this "tree diff" command? If I can verify with this tool that
my modification cannot introduce a bug, then I can remove the ChangeLog
entry.

> how can this ChangeLog entry be useful?

The patch may contain a bug in theory.

> >> 2. why do you indent by 2 characters here?
> >
> > Because that's how clisp/src/CodingStyle specifies it.
>
> this should be fixed.

No, it's written there on purpose! Precisely because indent by 1 is
not sufficient.

> I cannot look at the code which does not fit in 80 columns :-)

If you don't want to resize your window while looking at Lisp code, ...

> > Is the opening parenthesis in the last line here under the
> >   (C-FUNCTION
(Continue reading)

Permalink | Reply | 3 comments |

Gmane