[clisp-list] Re: No X Window with clisp 2.35 on x86_64

[Sam Steingold <sds@gn...>]

> * Dr. Werner Fink <jreare@...> [2005-09-06 18:18:15 +0200]:
>
> Hi,
>
> it seems that on AMD64 the record type is lost for
> the display object.  I've added a fprintf's to
>
>     make_display() in modules/clx/new-clx/clx.f
>     allocate_fpointer() in x86_64-suse-linux/spvw_typealloc.c
>
> and got the result that the macro Record_type()
> report 18 within allocate_fpointer() for the
> return result and 0 from make_display() ...
> later one leads to the error that the display
> is closed by the check ensure_living_display().
>
> The build has used TYPECODES.

it appears that this is the same bug as
<http://sourceforge.net/tracker/index.php?func=detail&aid=1246342&group_id=1355&atid=101355>;

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/>; <http://www.savegushkatif.org>;
<http://www.memri.org/>; <http://www.openvotingconsortium.org/>;
NY survival guide: when crossing a street, mind cars, not streetlights.

[clisp-list] No X Window with clisp 2.35 on x86_64

[Dr. Werner Fink <werner@su...>]

Hi,

it seems that on AMD64 the record type is lost for
the display object.  I've added a fprintf's to

    make_display() in modules/clx/new-clx/clx.f
    allocate_fpointer() in x86_64-suse-linux/spvw_typealloc.c

and got the result that the macro Record_type()
report 18 within allocate_fpointer() for the
return result and 0 from make_display() ...
later one leads to the error that the display
is closed by the check ensure_living_display().

The build has used TYPECODES.


        Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

[clisp-list] Re: posix:stream-lock

[Sam Steingold <sds@gn...>]

> * Takehiko Abe <xrxr@...> [2005-09-01 20:30:23 +0900]:
>
> I cannot figure out how to use posix:stream-lock .
>
>> (defparameter *lock* (open "lock" :direction :output))
> *LOCK*
>> *lock*
> #<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"lock">
>> (posix:stream-lock *lock* t :shared nil :block nil)
> T
>> (posix:stream-lock *lock* t :shared nil :block nil)
> T
>> (close *lock*)
>
> I expected the second call to stream-lock singals error but it did
> not. What am I missing?

I fixed stream-lock over the last few days.
please get the CVS head sources and build CLISP from them.

here is what I see now (I use 2 processes):

[1]> (setq s (open "foo" :direction :output))
#<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo">
[2]> (stream-lock s t)
T
[3]> (stream-lock s nil)
NIL
[4]> (stream-lock s t)  ; hangs until the 2nd process releases the lock
T
[5]> (stream-lock s nil)
NIL
[6]> (close s)
T
[7]> (delete-file s)
#P"/.../foo"
[8]>
Bye.

[1]> (setq s (open "foo" :direction :output))
#<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo">
[4]> (stream-lock s t)  ; hangs until the 1st process releases the lock
T
[5]> (stream-lock s nil)
NIL
[6]> (stream-lock s t :block nil) ; returns NIL immediately
NIL
[7]> (stream-lock s t :block nil) ; returns T immeditely
T
[8]> (close s)
T
[9]>
Bye.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://truepeace.org>; <http://www.savegushkatif.org>; <http://www.iris.org.il>;
<http://pmw.org.il/>; <http://www.openvotingconsortium.org/>;
Sufficiently advanced stupidity is indistinguishable from malice.

[clisp-list] Re: puzzling error while loading fas file.

[Sam Steingold <sds@gn...>]

> * Takehiko Abe <xrxr@...> [2005-09-06 15:04:05 +0900]:
>
> Sam Steingold wrote:
>
>> >> <http://www.lisp.org/HyperSpec/Body/sec_3-2-2-3.html>;:
>> >>          Classes defined by defclass in the compilation environment must
>> >>          be defined at run time to have the same superclasses and same
>> >>          metaclass.
>> >
>> > In my program, the class defined in compile time is also available in
>> > run time. So I believe it is conforming.
>> 
>> the error indicates that this is not the case.
>> 
>> Let me clarify:
>> the environment in which you compiled the code (calling TYPEP) must be
>> "isomorphic" to the environment in which you load the compiled code.
>
> The hyperspec page says: "... must be defined at run time."
> Not "load time". And yes the environment in which I run my code
> is 'isomorphic' to the compile time environment.

I believe that in this context load time is included in run time.
<http://www.lisp.org/HyperSpec/Body/sec_24-1-1.html>;:
To load a file is to treat its contents as code and execute that code.

>> the reason that you are getting the error is that your class is defined
>> at compile time but not at load time.
>> thus your "program" (defined in this context as the process in which you
>> compile and load your files) is not "conforming".
>> 
>> this is a very simple matter: just clean up the dependencies in your
>> defsystem.
>
> The typep form referred to XXX is in file A, and XXX is defined as a
> class name in file B. But in the real code the file B depends on file A.
> So it is not defsystem issue though I think I can reorganize my code.

Please do. Such circular dependencies will bite you sooner or later.


> And the dependency in this case is peculiar in that clisp produces
> more robust code when the offending class is _not_ present. That
> puzzled me.

more "robust" here means "less optimized".


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.savegushkatif.org>; <http://www.iris.org.il>; <http://truepeace.org>;
<http://pmw.org.il/>; <http://ffii.org/>; <http://www.palestinefacts.org/>;
Your mouse has moved - WinNT has to be restarted for this to take effect.

[clisp-list] Re: puzzling error while loading fas file.

[Takehiko Abe <keke@go...>]

Sam Steingold wrote:

> >> <http://www.lisp.org/HyperSpec/Body/sec_3-2-2-3.html>;:
> >>          Classes defined by defclass in the compilation environment must
> >>          be defined at run time to have the same superclasses and same
> >>          metaclass.
> >
> > In my program, the class defined in compile time is also available in
> > run time. So I believe it is conforming.
> 
> the error indicates that this is not the case.
> 
> Let me clarify:
> the environment in which you compiled the code (calling TYPEP) must be
> "isomorphic" to the environment in which you load the compiled code.

The hyperspec page says: "... must be defined at run time."
Not "load time". And yes the environment in which I run my code
is 'isomorphic' to the compile time environment.


> the "isomorphism" is described in the aforementioned page.
> specifically, whatever classes are defined during the compilation must
> be "similarly" (same superclasses & metaclass) defined at loading.

Again, it does not say "at loading". It says "run time".

Loading is about constructing a run time environment. If I already
have that environment, I don't have to load any file.

> the reason that you are getting the error is that your class is defined
> at compile time but not at load time.
> thus your "program" (defined in this context as the process in which you
> compile and load your files) is not "conforming".
> 
> this is a very simple matter: just clean up the dependencies in your
> defsystem.

The typep form referred to XXX is in file A, and XXX is defined as a
class name in file B. But in the real code the file B depends on file A.
So it is not defsystem issue though I think I can reorganize my code.

And the dependency in this case is peculiar in that clisp produces
more robust code when the offending class is _not_ present. That
puzzled me.
 
> > [btw, the test code I posted works fine with MCL/OpenMCL and sbcl.]
> 
> this just means that MCL/OpenMCL and sbcl can run certain non-conforming
> programs. so? there are lots of non-conforming programs that clisp can
> run and other lisps cannot.  this does not make those programs conforming.

I know. But I believe my program is conforming.

[clisp-list] Re: puzzling error while loading fas file.

[Sam Steingold <sds@gn...>]

> * Takehiko Abe <xrxr@...> [2005-09-06 10:38:21 +0900]:
>
>> If your program does not support that, it is not "conforming", see
>
> I do not agree. 
>
>> <http://www.lisp.org/HyperSpec/Body/sec_3-2-2-3.html>;:
>>          Classes defined by defclass in the compilation environment must
>>          be defined at run time to have the same superclasses and same
>>          metaclass.
>
> In my program, the class defined in compile time is also available in
> run time. So I believe it is conforming.

the error indicates that this is not the case.

Let me clarify:
the environment in which you compiled the code (calling TYPEP) must be
"isomorphic" to the environment in which you load the compiled code.
the "isomorphism" is described in the aforementioned page.
specifically, whatever classes are defined during the compilation must
be "similarly" (same superclasses & metaclass) defined at loading.
the reason that you are getting the error is that your class is defined
at compile time but not at load time.
thus your "program" (defined in this context as the process in which you
compile and load your files) is not "conforming".

this is a very simple matter: just clean up the dependencies in your
defsystem.

> [btw, the test code I posted works fine with MCL/OpenMCL and sbcl.]

this just means that MCL/OpenMCL and sbcl can run certain non-conforming
programs.  so?  there are lots of non-conforming programs that clisp can
run and other lisps cannot.  this does not make those programs conforming.


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.openvotingconsortium.org/>; <http://www.honestreporting.com>;
<http://www.camera.org>; <http://www.jihadwatch.org/>;
Winners never quit; quitters never win; idiots neither win nor quit.

[clisp-list] Re: puzzling error while loading fas file.

[Takehiko Abe <keke@go...>]

Sam Steingold wrote:

> > * Takehiko Abe <xrxr@...> [2005-09-06 00:18:10 +0900]:
> >
> > This is not like defmacro or defmethod --- it is about compiling
> > TYPEP.
> 
> Finally, some relevant information.
> Indeed, CLISP compiles TYPEP inline (see clisp/src/compiler.lisp:c-TYPEP)
> when the type argument is available at compile time.

Ok. That clisp compiles TYPEP inline is fine if it does not
error at load time. Why does clisp have to call FIND-CLASS
at load time? 

In my program, the class is available at run time. If clisp
compiler requires that a class name referred to by TYPEP is
present at compile time, I would not be very happy but it
would have been clear what was going on. But, clisp does not
require it. Instead, it quietly produces different fas files
and and the one with the inlined TYPEP signals error at load
time.


> 
> If your program does not support that, it is not "conforming", see

I do not agree. 

> <http://www.lisp.org/HyperSpec/Body/sec_3-2-2-3.html>;:
>          Classes defined by defclass in the compilation environment must
>          be defined at run time to have the same superclasses and same
>          metaclass.

In my program, the class defined in compile time is also available in
run time. So I believe it is conforming.

[btw, the test code I posted works fine with MCL/OpenMCL and sbcl.]


> Please make sure that your mailer respects "Reply-to" and
> "Mail-Copies-To" headers.

Sorry about that. I'll be carefull.