gmane.lisp.openmcl.devel

Re: Profiling Parenscript compilation

Gary Byers — 2008-12-03T20:06:26

On Wed, 3 Dec 2008, Scott Bell wrote: Use CHUD 4.5.0, and read ccl/library/chud-profiling.txt ? CHUD 4.5.0 matches what was released with XCode 3.0. Later versions seem to break support for using ".spatch" files to name otherwise anonymous memory regions (like lisp functions.)

Re: Profiling Parenscript compilation

Hans Hübner — 2008-12-03T20:04:12

Scott, you can give the deterministic profiler a try. It is included with the CCL distribution in tools/advice-profiler, but it needs to be manually loaded. I have not looked into it in a while, but if you find any problems with it, let me know and I'll try to help out. -Hans On Wed, Dec 3, 2008 at 20:56, Scott Bell me.com> wrote:

Profiling Parenscript compilation

Scott Bell — 2008-12-03T19:56:21

Hi folks, We have a series of Parenscript `scripts' that seem to be quite expensive to compile under most Lisps. SBCL takes between 8 and 12 seconds, and CCL takes up to 90 seconds. In my attempts to locate the most expensive calls, I have used CHUD- METERING, Apple's Instruments profiler, and out-of-the-box Shark. Since these do not seem to be able to profile Lisp functions, I'm at a bit of a loss on how to proceed. Does anyone have any advice? Thanks, - Scott Bell

Re: how to use quicktime

Alexander Repenning — 2008-12-02T20:32:09

_______________________________________________ Openmcl-devel mailing list Openmcl-devel< at >clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

Re: Unprintable CCL::IMMEDIATE : #xEB

Gary Byers — 2008-12-02T18:19:23

Matt fixed this yesterday (see ). As far as I can tell, the fix works: Welcome to Clozure Common Lisp Version 1.3-dev-r11451M-trunk (DarwinX8632)! ? (concatenate 'string '("a" "b" "cde")) Openmcl-devel mailing list Openmcl-devel< at >clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

Re: Unprintable CCL::IMMEDIATE : #xEB

Daniel Lyons — 2008-12-02T17:45:23

Hi Gary, On Nov 30, 2008, at 11:10 PM, Gary Byers wrote: Unfortunately, I'm running the same platform (OS X 10.5, 32-bit Intel) and I saw the same error when I was making other, much stupider mistakes today. Namely with these: (concatenate 'string '("a" "b" "cde")) (coerce '("a" "b" "cd") 'string) Under SBCL, I get the following type error: * (concatenate 'string '("a" "b" "cde")) debugger invoked on a TYPE-ERROR in thread #: The value "a" is not of type CHARACTER. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-IMPL::OPTIMIZED-DATA-VECTOR-SET # # #) 0] But under CCL (trunk) I get this: ? (concatenate 'string '("a" "b" "cde")) > Error: value # is not of the expected type CCL::UVECTOR. > While

Re: value * is not of the expected type LIST

R. Matthew Emerson — 2008-12-02T07:12:21

On Dec 1, 2008, at 5:59 PM, Cyrus Harmon wrote: This should be fixed in the trunk now. Thanks for the bug report.

Re: NSOpenPanel display bug

Raffael Cavallaro — 2008-12-02T03:20:25

On Dec 1, 2008, at 10:03 PM, R. Matthew Emerson wrote: this was it - I just edited the plist file. Thanks for your help, warmest regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro< at >mac.com

Re: NSOpenPanel display bug

R. Matthew Emerson — 2008-12-02T03:03:23

On Dec 1, 2008, at 9:18 PM, Raffael Cavallaro wrote: I couldn't duplicate what you're seeing on my machine, but I wouldn't be surprised if there was some bad data in the defaults database. To look at the defaults database, run one of the following two commands: defaults read "com.clozure.Clozure CL" (if you launch via a double- clickable app) or defaults read "com.clozure.temp bundle" (if you start the IDE via (require 'cocoa)) I'd look for a suspicious entry for "NSTableView Columns NSNavOutlineColumnSettings.v1" or something like that. "NSNav" is the substring to look for. (The system saves the order of the columns, the sort order of the columns, and other stuff like that in the defaults database. I'm guessing this information got screwed up somehow.) If you see something weird, delete it with a command like: defaults delete "com.clozure.Clozure CL" "NSTableView Columns NSNavOutlineColumnSettings.v1" If you don't care to go spelunking in the defaults database, and don't car

NSOpenPanel display bug

Raffael Cavallaro — 2008-12-02T02:18:44

If I execute this simple bit of code (or any other call to NSOpenPanel) I get multiple Date Modified columns. These then persist in new launches of the CCL IDE. At first there were just two, but now there are a total of 4. Restarting the IDE doesn't change this, nor does logging out, or restarting, or rebuilding ccl. Finally, these extra columns are also present in the IDE's open file dialog as well: (#/runModalForTypes: (#/openPanel (< at >class "NSOpenPanel")) nil) Any Idea what's going on here? regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro< at >mac.com _______________________________________________ Openmcl-devel mailing list Openmcl-devel< at >clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

value * is not of the expected type LIST

Cyrus Harmon — 2008-12-01T22:59:17

and here's another CCL issue that happens on both x86 and x8664 on Darwin. The problem seems to have something to do with declarations of the form: (declare (type (simple-array ,element-type *) ,vals)) changing the * to (*) seems to fix the problem, but it would seem that * should work here as well, declaring that this is a simple-array, not that it is a simple array of one dimension of unknown size. thanks again, cyrus value * is not of the expected type LIST. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY-COMPILE-FILE] Retry compiling #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/matrix.lisp" 1: [SKIP-COMPILE-FILE] Skip compiling #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/matrix.lisp" 2: [TRY-RECOMPILING] Try recompiling matrix 3: [RETRY] Retry performing # on #. 4: [ACCEPT] Continue, treating # on # as having

Re: Unprintable CCL::IMMEDIATE : #xEB

R. Matthew Emerson — 2008-12-01T21:13:24

On Dec 1, 2008, at 11:49 AM, Cyrus Harmon wrote: I think I fixed the error reporting bug in r11449. Thanks for pointing that out. http://trac.clozure.com/openmcl/changeset/11449

yet another ccl/x86 issue

Cyrus Harmon — 2008-12-01T18:47:03

The combination of ccl and my code seems to be quite good at picking up subtle "issues" in both systems. Here's the latest: Bug (probably): can't determine class of # #x8F1F7B6> [Condition of type SIMPLE-ERROR] Restarts: 0: [LOAD-SOURCE] Load "home:projects;git.cyrusharmon.org;clem;src;subtr.lisp" instead of "/ Users/sly/projects/git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/ subtr.dx32fsl" 1: [RECOMPILE] Compile "home:projects;git.cyrusharmon.org;clem;src;subtr.lisp" into "/Users/ sly/projects/git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/ subtr.dx32fsl" then load "/Users/sly/projects/git.cyrusharmon.org/clem/ src/ccl-1.3-darwin-x86/subtr.dx32fsl" again 2: [RETRY-LOAD] Retry loading #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/subtr.dx32fsl" 3: [SKIP-LOAD] Skip loading #P"/Users/sly/projects/ git.cyrusharmon.org/clem/src/ccl-1.3-darwin-x86/subtr.dx32fsl" 4: [LOAD-OTHER] Load other file instead of #P"/Users/sly/projects/ git.cyrushar

Re: Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T16:49:23

Yes, changing the :element-type in with-open-file from :default to '(unsigned-byte 8) makes the problem go away on both x86 and x86-64. So it looks like it is a combination of some sort of problem with the error reporting pathway and a creeping SBCL-ism that should be fixed. thanks, cyrus On Dec 1, 2008, at 8:02 AM, Cyrus Harmon wrote:

Re: Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T16:02:37

One reliable way to reproduce the bug (?) is to try loading a TIFF file using my retrospectiff package: To reproduce: 1. install retrospectiff, which can be found at: http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=retrospectiff.git 2. enter the following from the retrospectiff directory in ccl: (asdf:oos 'asdf:load-op :retrospectiff) (defparameter *snow-image* (retrospectiff:read-tiff-file "images/ snow.tiff")) Interestingly, this also fails in x86-64 darwin, but with a more sensible error message. So perhaps it's a bug in my code that is triggering a deficient error mechanism: #\M doesn't match array element type of #(0 0). [Condition of type SIMPLE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT-BREAK] Reset this thread 3: [ABORT] Kill this thread Backtrace: 0: (CCL::GENERIC-CHARACTER-READ-VECTOR #

Re: Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T15:35:43

My bug writing skills have clearly atrophied. Yes, this is 32-bit x86 on darwin (10.5.5). This is in the trunk (or the trunk as of a couple days ago). It's quite possible that I'm the culprit by lying to the compiler with various declarations in ways that SBCL isn't offended by. I'll see what I can do about a reproducible test case. thanks, cyrus On Nov 30, 2008, at 10:10 PM, Gary Byers wrote:

Re: (setf (find-class ...) ...) problem

Pascal Costanza — 2008-12-01T08:20:55

Hi there, Section 4.3.1 defines what a proper name of a class is. The restriction is there because otherwise you could have ambiguities in the type system. (Two different classes can have the same name, but only one can have that name as a proper name.) Pascal On 1 Dec 2008, at 06:04, Cyrus Harmon wrote:

Re: Unprintable CCL::IMMEDIATE : #xEB

Gary Byers — 2008-12-01T06:10:55

It's hard to respond to something like this without knowing what version of the lisp you're running. Unless you're really sure that that information is irrelevant, it's generally a good idea to include it when reporting a problem like this. My best guess is that you're running some 32-bit X86 version on Darwin. On that platform, #xeb is just a placeholder value used to reserve space for an outgoing stack frame in some cases; nothing's supposed to ever "see" that marker value. Having one of these things get passed around is indicative of a fairly serious bug (the compiler's lost track of what's on the stack, or the runtime is pushing or popping more than it's supposed to, or something like that.) It's been a while since I've seen that sort of bug in the x86-32 trunk lisps, but that doesn't mean that such a bug isn't still there. If it is still present in the trunk, then knowing how to reproduce it would be helpful. On Sun, 30 Nov 2008, Cyrus Harmon wrote:

Unprintable CCL::IMMEDIATE : #xEB

Cyrus Harmon — 2008-12-01T05:07:19

Ok, so my latest issue in trying to port my stuff to ccl is the error shown below. Not sure where to begin with this one. thanks, Cyrus value # is not of the expected type CCL::UVECTOR. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT-BREAK] Reset this thread 3: [ABORT] Kill this thread Backtrace: 0: ((:INTERNAL CCL::%XERR-DISP)) 1: (CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION #) 2: (CCL::%XERR-DISP -334757490) 3: (CCL::%PASCAL-FUNCTIONS% 2 -334757490) 4: (CCL::%PR-INTEGER # 10 # T NIL) 5: (CCL::%RSC-STRING #) 6: (CCL::%ERR-DISP-INTERNAL # (# \M #(0 0)) 1564382) 7: (READ-SEQUENCE #(0 0) #

Re: (setf (find-class ...) ...) problem

Cyrus Harmon — 2008-12-01T05:04:04

Gary, Thanks for the thoughtful explanation. Explicitly deftype'ing the class first sounds reasonable to me. I've asked the cxml-stp developers for their opinion as well. thanks again, cyrus On Nov 30, 2008, at 6:12 PM, Gary Byers wrote:

Re: how to use quicktime

R. Matthew Emerson — 2008-12-01T02:15:03

On Nov 30, 2008, at 8:15 PM, Alexander Repenning wrote: Welcome to Clozure Common Lisp Version 1.2-r11429M (DarwinX8664)! ? (require 'cocoa) [...] ;;; open shared library, use interface dir, update objc bridge info ? (objc:load-framework "QTKit" :qtkit) NIL ? (make-instance 'ns:q-t-movie-view) # (#x127C1B00)> ? http://trac.clozure.com/openmcl/wiki/AddressBook is another example (but it uses the AddressBook framework instead of QTKit).