gmane.lisp.cmucl.general

Re: bugs in C::SOURCE-LOCATION and string reversal

Matt Kaufmann — 2013-05-16T15:37:37

Thanks for dealing with these issues.

Regarding:


I did a little test with CCL, LispWorks, and GCL and found that they
retain the value too.  So apparently it's the application's
responsibility (i.e., my responsibility) to deal with this.
Interestingly, SBCL and Allegro CL apparently do not retain the value,
instead setting it at startup to match the current working directory;
and CLISP seems to set it to #P"" at startup.

I'll probably just arrange that when my application starts up, if
(pathname-directory *default-pathname-defaults*) is non-nil, then
*default-pathname-defaults* is assigned the value of (make-pathname).

Regards,
Matt
   From: Raymond Toy <toy.raymond< at >gmail.com>
   Date: Wed, 15 May 2013 20:34:20 -0700

   >>>>> "Matt" == Matt Kaufmann <kaufmann< at >cs.utexas.edu> writes:

       Matt> The first bug pertains to C::SOURCE-LOCATION.  Below is part of the
       Matt> log, showing three errors during compilation followed by a break
       Matt> during load of the resulting compiled file.

Re: bugs in C::SOURCE-LOCATION and string reversal

Raymond Toy — 2013-05-16T03:34:20

    Matt> The first bug pertains to C::SOURCE-LOCATION.  Below is part of the
    Matt> log, showing three errors during compilation followed by a break
    Matt> during load of the resulting compiled file.

    Matt> ; 
    Matt> ; 
    Matt> ; File: /v/filer4b/v11q002/acl2space/acl2/devel/books/centaur/gl/gl< at >expansion.lsp

    Matt> ; In: DEFMACRO GL-BDD-MODE => DEFATTACH GL::BFR-MODE

    Matt> ;   (DEFATTACH GL::BFR-MODE GL::BFR-BDD)
    Matt> ; --> DEFPARAMETER PROGN LISP::SET-DEFVAR-SOURCE-LOCATION 
    Matt> ; --> LISP::SET-DEFVAR-SOURCE-LOCATION 
    Matt> ; ==>
    Matt> ;   (C::SOURCE-LOCATION)
    Matt> ; Error: (during macroexpansion)
    Matt> ; Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
    Matt> ;    27574 is not of type (UNSIGNED-BYTE 14)

With help from Matt, I've been able to reproduce this.  I think the
issue is that the file gl< at >expansion.lsp is a 500 KB source file with
way too many forms in it and exceeding the limit 14 bits that the
compiler allocates for the top-level form n

Re: bugs in C::SOURCE-LOCATION and string reversal

Matt Kaufmann — 2013-05-14T19:55:35

Hello --

Thanks for the reply!  Please see replies below.

   From: Raymond Toy <toy.raymond< at >gmail.com>
   Date: Mon, 13 May 2013 19:18:05 -0700

   >>>>> "Matt" == Matt Kaufmann <kaufmann< at >cs.utexas.edu> writes:

       Matt> Hi --
       Matt> I downloaded the 2013-05 snapshot from
       Matt> http://trac.common-lisp.net/cmucl
       Matt> (http://common-lisp.net/project/cmucl/downloads/snapshots/2013/05/cmucl-2013-05-x86-linux.tar.bz2),
       Matt> and I am running into two bugs, discussed below.  The first is kind of
       Matt> a show-stopper.  It's hit me before using CMUCL 19e (so I guess it's
       Matt> been around awhile), but at that time I was able to avoid it simply by
       Matt> not running my application in a particular "mode".  I'd appreciate any
       Matt> suggestions for easily working around that first bug.  I've worked
       Matt> around the second bug, but I thought I should report it, and I do so
       Matt> at the end, below.

   First, sorry for the trouble you're having.  A

Re: bugs in C::SOURCE-LOCATION and string reversal

Raymond Toy — 2013-05-14T02:18:05

    Matt> Hi --
    Matt> I downloaded the 2013-05 snapshot from
    Matt> http://trac.common-lisp.net/cmucl
    Matt> (http://common-lisp.net/project/cmucl/downloads/snapshots/2013/05/cmucl-2013-05-x86-linux.tar.bz2),
    Matt> and I am running into two bugs, discussed below.  The first is kind of
    Matt> a show-stopper.  It's hit me before using CMUCL 19e (so I guess it's
    Matt> been around awhile), but at that time I was able to avoid it simply by
    Matt> not running my application in a particular "mode".  I'd appreciate any
    Matt> suggestions for easily working around that first bug.  I've worked
    Matt> around the second bug, but I thought I should report it, and I do so
    Matt> at the end, below.

First, sorry for the trouble you're having.  And thank you for
reporting it.  If you don't report it, it can't be fixed.

    Matt> The first bug pertains to C::SOURCE-LOCATION.  Below is part of the
    Matt> log, showing three errors during compilation followed by a break
    Matt> during loa

bugs in C::SOURCE-LOCATION and string reversal

Matt Kaufmann — 2013-05-13T14:07:16

Hi --

I downloaded the 2013-05 snapshot from
http://trac.common-lisp.net/cmucl
(http://common-lisp.net/project/cmucl/downloads/snapshots/2013/05/cmucl-2013-05-x86-linux.tar.bz2),
and I am running into two bugs, discussed below.  The first is kind of
a show-stopper.  It's hit me before using CMUCL 19e (so I guess it's
been around awhile), but at that time I was able to avoid it simply by
not running my application in a particular "mode".  I'd appreciate any
suggestions for easily working around that first bug.  I've worked
around the second bug, but I thought I should report it, and I do so
at the end, below.

The first bug pertains to C::SOURCE-LOCATION.  Below is part of the
log, showing three errors during compilation followed by a break
during load of the resulting compiled file.

; 
; 
; File: /v/filer4b/v11q002/acl2space/acl2/devel/books/centaur/gl/gl< at >expansion.lsp

; In: DEFMACRO GL-BDD-MODE => DEFATTACH GL::BFR-MODE

;   (DEFATTACH GL::BFR-MODE GL::BFR-BDD)
; --> DEFPARAMETER PROGN LISP::SET-DEFVAR-S

[Extended Deadline] European Lisp Symposium 2013 -Madrid - June 1-4

Didier Verna — 2013-03-05T16:12:08

;;            ______   _         _____   _   __   ____  
;;           |  ____| | |       / ____| ( ) /_ | |___ \ 
;;           | |__    | |      | (___   |/   | |   __) |
;;           |  __|   | |       \___ \       | |  |__ < 
;;           | |____  | |____   ____) |      | |  ___) |
;;           |______| |______| |_____/       |_| |____/ 
;;                                                      
;;              European Lisp Symposium 2013 - ELS'13
;;                         Madrid, Spain
;; 
;;                        June 1-4, 2013
;;
;;           http://els2013.european-lisp-symposium.org/

                ** DEADLINE EXTENSION: March 17th **

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in L

CMUCL 20d released

Raymond Toy — 2012-10-27T18:30:06

CMUCL 20d has been released.  It is functionally identical to the
2012-10 snapshot.  Binaries will be uploaded shortly, and the website
updated soon.

With this release, there will NOT be a 2012-11 snapshot. 

Also, this release marks the end of support 8-bit characters; only
Unicode will be supported from now on.  Support for x87 will remain,
however.

Hope this release is useful to you.

Ray

_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

Re: registering with trac.common-lisp.net?

Raymond Toy — 2012-08-04T02:39:43

I think you have to have an account on common-lisp.net.

Sending a bug report here or to cmucl-imp is fine too, but I personally
prefer trac where it won't get lost and can also be tracked if the bug
is fixed.

Ray

_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

special operators without a macro definition

Pascal J. Bourguignon — 2012-08-03T13:55:53

Here is the "bug report"/enhancement request I'd like to post:

------------------------------------------------------------------------

The following special operators don't have a corresponding macro
definition.

 C::%CLEANUP-FUNCTION
 C::%ESCAPE-FUNCTION
 C::%FUNCALL
 SYSTEM:%PRIMITIVE
 C::%WITHIN-CLEANUP
 C::COMPILER-OPTION-BIND
 EXTENSIONS:TRULY-THE


While the standard doesn't specify anything for special operators not in
the CL package, it would still be nice if they followed the same rule as
for CL macros implemented as special operators:

3.1.2.1.2.2 Macro Forms
An implementation is free to implement any macro operator as a special operator,
but only if an equivalent definition of the macro is also provided.

since this would ensure that portable code walkers can be written.

------------------------------------------------------------------------

(Granted, I haven't checked that all those special operators were
reachable from exported macros, but I'd bet most of them are).

registering with trac.common-lisp.net?

Pascal J. Bourguignon — 2012-08-03T13:52:47

How do I register with trac.common-lisp.net to be able to login and post
a bug report?    Or should they be sent to this or another mailing list?

Re: Inlined TYPEP over-optimization issue withCHANGE-CLASS

Christophe Rhodes — 2012-02-12T13:58:29


Here's a related test case:

  (defun %show-issue (instance)
    (when (typep instance 'foo)
      (change-class instance 'bar)
      (format t "~&;; Inlined TYPEP: ~s (~:*~:[correct~;incorrect~])~
                 ~%;; Not-inlined TYPEP: ~s (~:*~:[correct~;incorrect~])~%"
              (typep instance 'foo)
              (locally (declare (notinline typep))
                (typep instance 'foo)))))
  (%show-issue (make-instance 'foo))

I don't know whether that passes or fails on CMUCL, but it does reveal
a too-optimistic inlining (or maybe constraint propagation) on SBCL --
so it might be worth checking.

Best,

Christophe
_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

Re: Inlined TYPEP over-optimization issue withCHANGE-CLASS

Dan Corkill — 2012-02-12T12:57:28


Ray,

With the 2012-02 snapshot, I also only see the issue with the DEFMETHOD
version.  Here is the newest test code that I ran:

(in-package :cl-user)

(defclass foo () ())
(defclass bar () ())

(defmethod no-issue ((instance foo))
  (%show-issue instance))
  
(defun %show-issue (instance)
  (change-class instance 'bar)
  (format t "~&;; Inlined TYPEP: ~s (~:*~:[correct~;incorrect~])~
             ~%;; Not-inlined TYPEP: ~s (~:*~:[correct~;incorrect~])~%"
          (typep instance 'foo)
          (locally (declare (notinline typep))
            (typep instance 'foo))))

(defmethod show-issue ((instance foo))
  (change-class instance 'bar)
  (format t "~&;; Inlined TYPEP: ~s (~:*~:[correct~;incorrect~])~
             ~%;; Not-inlined TYPEP: ~s (~:*~:[correct~;incorrect~])~%"
          (typep instance 'foo)
          (locally (declare (notinline typep))
            (typep instance 'foo))))

(format t "~&;;; No issue:~%")
(no-issue (make-instance 'foo))
(format t "~2&;;; Issue:~%")
(show-issue (make-instance

Re: Inlined TYPEP over-optimization bug withCHANGE-CLASS

Raymond Toy — 2012-02-12T05:29:10

I placed your code in a file and compiled and loaded it with the 2012-02
snapshot.  I get

CL-USER> (show-bug (make-instance 'foo))
;; Inlined TYPEP: NIL (incorrect)
;; Not-inlined TYPEP: NIL (correct)

What version exactly are you using and how did you run your example to
get an incorrect result?

Ray

_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

Re: Inlined TYPEP over-optimization bug withCHANGE-CLASS

Dan Corkill — 2012-02-05T14:57:44

I fully agree (and apologies for the confusion caused by my quick-and-dirty 
example).

The issue doesn't require being within an instance method--as the following
vanilla-function example shows.

(in-package :cl-user)

(defclass foo () ())
(defclass bar () ())

(defun show-bug (instance)
  (change-class instance 'bar)
  (format t "~&;; Inlined TYPEP: ~s (incorrect)~%;; Not-inlined TYPEP: ~s (correct)~%"
          (typep instance 'foo)
          (locally (declare (notinline typep))
            (typep instance 'foo))))

(show-bug (make-instance 'foo))

Re: Inlined TYPEP over-optimization bug withCHANGE-CLASS

Christophe Rhodes — 2012-02-05T11:57:23



Changing the class of an instance within a method specializing on that
instance to a class where the method would no longer have been called is
one of the things that the CLHS description of change-class calls
"semantic difficulties".

Not speaking for CMUCL developers, I would call it a downright bad idea
to mess with the classes of specialized instances in methods -- allowing
the programmer to do invalidates whole classes of CLOS optimizations.
The CLHS specifically calls out slot access, but that's just one case of
a general problem: after you issue the change-class, the method
currently running is no longer an applicable method to the instance, so
all the compiler assumptions have just been invalidated, and all the
run-time calculations of next methods also (though they're not present
in your example).

Best,

Christophe
_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

Inlined TYPEP over-optimization bug with CHANGE-CLASS

Dan Corkill — 2012-02-05T11:18:21

Recent CMUCL releases (including the current one), incorrectly over-optimize TYPEP and
miss the class change resulting from CHANGE-CLASS. 

The following example, when placed in a file and compiled, shows the issue:

(in-package :cl-user)

(defclass foo () ())
(defclass bar () ())

(defmethod show-bug ((instance foo))
 (change-class instance 'bar)
 (format t "~&;; Inlined TYPEP: ~s (incorrect)~%;; Not-inlined TYPEP: ~s (correct)~%"
         (typep instance 'foo)
         (locally (declare (notinline typep))
           (typep instance 'foo))))

(show-bug (make-instance 'foo))

ELS 2012, Zadar, Croatia

Marco Antoniotti — 2012-02-01T13:11:37

Apologies for the multiple postings. 

PAPER SUBMISSION DEADLINE EXTENDED 


European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 

http://european-lisp-symposium.org 

The purpose of the European Lisp Symposium is to provide a forum for 
the discussion and dissemination of all aspects of design, 
implementation and application of any of the Lisp and Lisp-inspired 
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, 
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We 
encourage everyone interested in Lisp to participate. 


The main theme of the 2012 European Lisp Conference is 
"Interoperability: Systems, Libraries, Workflows".  Lisp based and 
functional-languages based systems have grown a variety of solutions 
to become more and more integrated with the wider world of Information 
and Communication Technologies in current use.  There are several 
dimensions to the scope of the solutions proposed, ranging from 
"embedding" of interpreters in C-based syste

Re: Git repo for cmucl

Raymond Toy — 2011-09-21T03:39:05

These are all available now as well as better trac and git integration.
 Commit messages can now automatically close trac tickets.  See
http://trac.common-lisp.net/cmucl/wiki for some additional information.

Ray

_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

Git repo for cmucl

Raymond Toy — 2011-09-17T16:23:53

Cmucl is now officially moving to git.  The CVS repo will be turned off
soon, and, in fact, should no longer be used at all.  The repo will
still be available for historical reasons, but no new code should be
checked in to it.

We had planned on moving to git almost a year ago, but for various
reasons never got  around to it until now.

Additional information will be placed on cmucl's trac wiki, but for now,
you can view the repo using trac (coming soon to
http://trac.common-lisp.net/cmucl/browser) or directly at
<http://common-lisp.net/gitweb?p=projects/cmucl/cmucl.git;a=summary;js=1>

For now you can clone the repo using

git clone git://common-lisp.net/projects/cmucl/cmucl.git src

or for developers

git clone ssh://<user>< at >common-lisp.net/var/git/projects/cmucl/cmucl.git src

There is a minor issue to be taken care of:  What to do with the RCS
keywords that are in all of the files.  I rather like seeing that
information when you describe something.  (Mostly to see when the file
was last modified.)

Ray

_

pressure info from wacom stylus in CLX

fred — 2011-08-01T07:08:07

Folks --

Is there a way to get pressure events from a wacom tablet in CLX?

I'm running CLX under X11 for Mac OS X (and, Tiger 10.4.11 ...
I know, I know, but thought I would ask).

thanks,
-f
livegraphicsnightly.com
"If Veli's Graphics Bar didn't exist, we'd have to invent it." H Lieberman
_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

Re: Still problems with the web site?

Marco Antoniotti — 2011-06-28T17:06:45

On Jun 28, 2011, at 14:54 , Raymond Toy wrote:




No problem....


--
Marco Antoniotti


_______________________________________________
cmucl-help mailing list
cmucl-help< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help