From steve.nunez at illation.com.sg Fri May 1 00:12:54 2009 From: steve.nunez at illation.com.sg (Steve =?iso-8859-1?b?TvrxZXo=?=) Date: Fri, 01 May 2009 07:12:54 +0000 Subject: [Openmcl-devel] Cocoa on PPC32 ? Message-ID: <20090501071254.24792qqrz15tboc6@illation.sg> Does anyone do any Cocoa work on PPC 32bit? I'm just guessing that the platform is the problem here. When I try to build the bridge, via (require 'cocoa'), CCL crashes with: Unhandled exception 11 at 0x9f84e40c, context->regs at #xbffff458 Read operation to unmapped address 0x5 In foreign code at address 0x9f84e40c [_NSRemoveHandler2 + 496] Any ideas? Regards, - Steve ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Fri May 1 01:23:46 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 1 May 2009 02:23:46 -0600 (MDT) Subject: [Openmcl-devel] Cocoa on PPC32 ? In-Reply-To: <20090501071254.24792qqrz15tboc6@illation.sg> References: <20090501071254.24792qqrz15tboc6@illation.sg> Message-ID: <20090501020100.W28729@abq.clozure.com> It's certainly supposed to work. I just tried doing (REQUIRE "COCOA") in both the current trunk and the current 1.3 release on PPCs running 10.5.6 and 10.4.11 and also ran the pre-built IDE from the clozurecl-1.3-darwinppc.dmg archive on both OSes, and didn't notice any problems; I don't remember having heard of anyone having problems, and I don't remember there having been any such problems in recent development versions. (It's certainly true that the PPC versions of CCL get less exercise these days than the x86 versions do, but a lot of the work I've been doing for the last several months has been on a Darwin PPC box, and I used a fairly current CCL on that machine fairly regularly.) _NSRemoveHandler2 is part of the (32-bit) ObjC exception handling mechanism; it's called all of the time as code transitions betwen Lisp and ObjC. My first guess is that a crash there is a symptom of something else (stack overflow ?), but that's just a guess (and not necessarily a good one.) If you can, please get it to crash like this and generate a backtrace in the kernel debugger. I'd be interested in seeing that, and it might lead to a better guess. (It also never hurts to mention what version of CCL you're using and what OS version is involved.) On Fri, 1 May 2009, Steve N??ez wrote: > Does anyone do any Cocoa work on PPC 32bit? I'm just guessing that the platform is the problem here. When I try to build the bridge, via (require 'cocoa'), CCL crashes with: > > Unhandled exception 11 at 0x9f84e40c, context->regs at #xbffff458 > Read operation to unmapped address 0x5 > In foreign code at address 0x9f84e40c > [_NSRemoveHandler2 + 496] > > Any ideas? > > Regards, > - Steve > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > From steve.nunez at illation.com.sg Fri May 1 04:31:14 2009 From: steve.nunez at illation.com.sg (Steve =?utf-8?b?TsO6w7Fleg==?=) Date: Fri, 01 May 2009 11:31:14 +0000 Subject: [Openmcl-devel] Cocoa on PPC32 ? In-Reply-To: <20090501020100.W28729@abq.clozure.com> References: <20090501071254.24792qqrz15tboc6@illation.sg> <20090501020100.W28729@abq.clozure.com> Message-ID: <20090501113114.40733a6r9wb3xcoy@illation.sg> Thanks. A fresh tarball download has solved the Cocoa problem however this same fresh checkout fails a full rebuild. The pre-built IDE runs fine, I'm trying to work through the Cocoa GUI examples. This is running 10.4.11: administrators-ibook-g4:~/Illation/Development/Applications/ccl admin$ ./dppccl Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinPPC32)! ? (rebuild-ccl :full t) Rebuilding Clozure Common Lisp using Version 1.3-r11936 (DarwinPPC32) ;Building lisp-kernel ... > Error: Error(s) during kernel compilation. > > While executing: REBUILD-CCL, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > :b (F0199B30) : 0 (REBUILD-CCL :UPDATE NIL :FULL T :CLEAN T :KERNEL T :FORCE NIL :RELOAD T :EXIT NIL :RELOAD-ARGUMENTS NIL :VERBOSE NIL :OPTIONAL-FEATURES NIL) 1188 (F0199B70) : 2 (CALL-CHECK-REGS REBUILD-CCL :FULL T) 72 (F0199B90) : 4 (TOPLEVEL-EVAL (REBUILD-CCL :FULL T) NIL) 476 (F0199BC0) : 5 (READ-LOOP :INPUT-STREAM # :OUTPUT-STREAM # :BREAK-LEVEL 0 :PROMPT-FUNCTION #) 1080 (F0199C00) : 6 (TOPLEVEL-LOOP) 72 (F0199C20) : 7 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION (CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 72 (F0199C40) : 9 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 392 (F0199C70) : 11 (RUN-PROCESS-INITIAL-FORM # (#)) 404 (F0199CB0) : 13 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET-INTERNAL)> # (#)) 164 (F0199CD0) : 14 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 176 Quoting Gary Byers : > It's certainly supposed to work. I just tried doing (REQUIRE > "COCOA") in both the > current trunk and the current 1.3 release on PPCs running 10.5.6 and > 10.4.11 and > also ran the pre-built IDE from the clozurecl-1.3-darwinppc.dmg > archive on both > OSes, and didn't notice any problems; I don't remember having heard of anyone > having problems, and I don't remember there having been any such problems in > recent development versions. > > (It's certainly true that the PPC versions of CCL get less exercise > these days > than the x86 versions do, but a lot of the work I've been doing for the last > several months has been on a Darwin PPC box, and I used a fairly current CCL > on that machine fairly regularly.) > > _NSRemoveHandler2 is part of the (32-bit) ObjC exception handling mechanism; > it's called all of the time as code transitions betwen Lisp and ObjC. > My first > guess is that a crash there is a symptom of something else (stack > overflow ?), > but that's just a guess (and not necessarily a good one.) > > If you can, please get it to crash like this and generate a backtrace in > the kernel debugger. I'd be interested in seeing that, and it might lead to > a better guess. > > (It also never hurts to mention what version of CCL you're using and what > OS version is involved.) > > On Fri, 1 May 2009, Steve N??ez wrote: > >> Does anyone do any Cocoa work on PPC 32bit? I'm just guessing that >> the platform is the problem here. When I try to build the bridge, >> via (require 'cocoa'), CCL crashes with: >> >> Unhandled exception 11 at 0x9f84e40c, context->regs at #xbffff458 >> Read operation to unmapped address 0x5 >> In foreign code at address 0x9f84e40c >> [_NSRemoveHandler2 + 496] >> >> Any ideas? >> >> Regards, >> - Steve ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From plkrueger at comcast.net Fri May 1 05:31:51 2009 From: plkrueger at comcast.net (Paul Krueger) Date: Fri, 1 May 2009 07:31:51 -0500 Subject: [Openmcl-devel] Cocoa on PPC32 ? In-Reply-To: <20090501113114.40733a6r9wb3xcoy@illation.sg> References: <20090501071254.24792qqrz15tboc6@illation.sg> <20090501020100.W28729@abq.clozure.com> <20090501113114.40733a6r9wb3xcoy@illation.sg> Message-ID: <644CBB37-835A-4711-8DBF-5578876A177C@comcast.net> My recent re-build for PPC32 via the IDE also failed, but I was able to build it via the command line by allowing it to re-define a constant to a new value when the exception occurred: Welcome to Clozure Common Lisp Version 1.3-RC1-r11875M (DarwinPPC32)! ? (rebuild-ccl :full t) Rebuilding Clozure Common Lisp using Version 1.3-RC1-r11875M (DarwinPPC32) ;Building lisp-kernel ... ... ;Compiling "/Applications/ccl/compiler/arch.lisp"... > Error: Constant ERROR-OBJECT-NOT-UNUSED-MAX-TYPE-ERROR is already defined with a different value (239) > While executing: CCL::DEFINE-CONSTANT, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Redefine ERROR-OBJECT-NOT-UNUSED-MAX-TYPE-ERROR to have new value 252 > Type :? for other options. 1 > :GO ;Loading #P"/Applications/ccl/bin/arch.dfsl"... ... I'm also routinely using Cocoa on PPC without problems. Paul On May 1, 2009, at 6:31 AM, Steve N??ez wrote: > Thanks. A fresh tarball download has solved the Cocoa problem > however this same fresh checkout fails a full rebuild. The pre-built > IDE runs fine, I'm trying to work through the Cocoa GUI examples. > This is running 10.4.11: > > administrators-ibook-g4:~/Illation/Development/Applications/ccl admin > $ ./dppccl > Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinPPC32)! > ? (rebuild-ccl :full t) > Rebuilding Clozure Common Lisp using Version 1.3-r11936 (DarwinPPC32) > ;Building lisp-kernel ... > > Error: Error(s) during kernel compilation. > > > > While executing: REBUILD-CCL, in process listener(1). > > Type :POP to abort, :R for a list of available restarts. > > Type :? for other options. > 1 > :b > (F0199B30) : 0 (REBUILD-CCL :UPDATE NIL :FULL T :CLEAN T :KERNEL > T :FORCE NIL :RELOAD T :EXIT NIL :RELOAD-ARGUMENTS NIL :VERBOSE > NIL :OPTIONAL-FEATURES NIL) 1188 > (F0199B70) : 2 (CALL-CHECK-REGS REBUILD-CCL :FULL T) 72 > (F0199B90) : 4 (TOPLEVEL-EVAL (REBUILD-CCL :FULL T) NIL) 476 > (F0199BC0) : 5 (READ-LOOP :INPUT-STREAM # *TERMINAL-IO* #x84D02B6> :OUTPUT-STREAM # *TERMINAL-IO* #x84D0246> :BREAK-LEVEL 0 :PROMPT-FUNCTION # function (:INTERNAL CCL::READ-LOOP) (Non-Global) #x81A8166>) 1080 > (F0199C00) : 6 (TOPLEVEL-LOOP) 72 > (F0199C20) : 7 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION > (CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 72 > (F0199C40) : 9 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER- > PROCESS)>) 392 > (F0199C70) : 11 (RUN-PROCESS-INITIAL-FORM # listener(1) [Active] #x84CF86E> (# #x84CF66E>)) 404 > (F0199CB0) : 13 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET- > INTERNAL)> # > (#)) 164 > (F0199CD0) : 14 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP- > FUNCTION)>) 176 > > > Quoting Gary Byers : > > > It's certainly supposed to work. I just tried doing (REQUIRE > > "COCOA") in both the > > current trunk and the current 1.3 release on PPCs running 10.5.6 and > > 10.4.11 and > > also ran the pre-built IDE from the clozurecl-1.3-darwinppc.dmg > > archive on both > > OSes, and didn't notice any problems; I don't remember having > heard of anyone > > having problems, and I don't remember there having been any such > problems in > > recent development versions. > > > > (It's certainly true that the PPC versions of CCL get less exercise > > these days > > than the x86 versions do, but a lot of the work I've been doing > for the last > > several months has been on a Darwin PPC box, and I used a fairly > current CCL > > on that machine fairly regularly.) > > > > _NSRemoveHandler2 is part of the (32-bit) ObjC exception handling > mechanism; > > it's called all of the time as code transitions betwen Lisp and > ObjC. > > My first > > guess is that a crash there is a symptom of something else (stack > > overflow ?), > > but that's just a guess (and not necessarily a good one.) > > > > If you can, please get it to crash like this and generate a > backtrace in > > the kernel debugger. I'd be interested in seeing that, and it > might lead to > > a better guess. > > > > (It also never hurts to mention what version of CCL you're using > and what > > OS version is involved.) > > > > On Fri, 1 May 2009, Steve N??ez wrote: > > > >> Does anyone do any Cocoa work on PPC 32bit? I'm just guessing that > >> the platform is the problem here. When I try to build the bridge, > >> via (require 'cocoa'), CCL crashes with: > >> > >> Unhandled exception 11 at 0x9f84e40c, context->regs at #xbffff458 > >> Read operation to unmapped address 0x5 > >> In foreign code at address 0x9f84e40c > >> [_NSRemoveHandler2 + 496] > >> > >> Any ideas? > >> > >> Regards, > >> - Steve > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From danieldickison at gmail.com Fri May 1 12:44:37 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Fri, 1 May 2009 15:44:37 -0400 Subject: [Openmcl-devel] Speed of concatenate vs format Message-ID: <9391C9E3-05FF-449B-A4BC-C0A40524CF52@gmail.com> I've been working with some legacy code that contains many instances of -- (format nil "~a~a" string1 string2) for concatenating strings. This code is in some code that is a performance bottleneck, and I thought, surely, this would be more efficient if rewritten as -- (concatenate 'string string1 string2) but this turns out not to be the case. In fact, using format for string concatenation is significantly faster. So assuming the overhead for parsing the format control string is negligible, the format version probably becomes two calls to princ wrapped in a with- output-to-string. How come this is so much faster than concatenate? Now that I've done the profiling, I know which code to use, but I'm still really curious why this is the case. I would appreciate any insight. Below is the results of some quick-and-dirty profiling on CCL Version 1.3-r11987M (DarwinX8664), an iMac Core 2 Duo. Thanks! Daniel CL-USER> (defvar *str* (make-string 2000 :initial-element #\a)) *STR* CL-USER> (time (dotimes (i 100000) (format nil "~a~a" *str* *str*))) (DOTIMES (I 100000) (FORMAT NIL "~a~a" *STR* *STR*)) took 5,547,598 microseconds (5.547598 seconds) to run with 2 available CPU cores. During that period, 3,288,825 microseconds (3.288825 seconds) were spent in user mode 770,732 microseconds (0.770732 seconds) were spent in system mode 1,076,633 microseconds (1.076633 seconds) was spent in GC. 1,606,416,016 bytes of memory allocated. NIL CL-USER> (time (dotimes (i 100000) (concatenate 'string *str* *str*))) (DOTIMES (I 100000) (CONCATENATE 'STRING *STR* *STR*)) took 10,373,570 microseconds (10.373570 seconds) to run with 2 available CPU cores. During that period, 8,092,791 microseconds (8.092791 seconds) were spent in user mode 878,887 microseconds (0.878887 seconds) were spent in system mode 1,097,819 microseconds (1.097819 seconds) was spent in GC. 1,601,600,000 bytes of memory allocated. NIL CL-USER> (time (dotimes (i 100000) (with-output-to-string (s) (princ *str* s) (princ *str* s)))) (DOTIMES (I 100000) (WITH-OUTPUT-TO-STRING (S) (PRINC *STR* S) (PRINC *STR* S))) took 5,284,978 microseconds (5.284978 seconds) to run with 2 available CPU cores. During that period, 3,153,681 microseconds (3.153681 seconds) were spent in user mode 752,712 microseconds (0.752712 seconds) were spent in system mode 1,087,328 microseconds (1.087328 seconds) was spent in GC. 1,606,416,016 bytes of memory allocated. From rme at clozure.com Fri May 1 12:53:06 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Fri, 1 May 2009 15:53:06 -0400 Subject: [Openmcl-devel] Cocoa on PPC32 ? In-Reply-To: <20090501113114.40733a6r9wb3xcoy@illation.sg> References: <20090501071254.24792qqrz15tboc6@illation.sg> <20090501020100.W28729@abq.clozure.com> <20090501113114.40733a6r9wb3xcoy@illation.sg> Message-ID: <622B39BA-CB42-4BF5-823A-E89253D58F02@clozure.com> On May 1, 2009, at 7:31 AM, Steve N??ez wrote: > Thanks. A fresh tarball download has solved the Cocoa problem > however this same fresh checkout fails a full rebuild. The pre-built > IDE runs fine, I'm trying to work through the Cocoa GUI examples. > This is running 10.4.11: > > administrators-ibook-g4:~/Illation/Development/Applications/ccl admin > $ ./dppccl > Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinPPC32)! > ? (rebuild-ccl :full t) > Rebuilding Clozure Common Lisp using Version 1.3-r11936 (DarwinPPC32) > ;Building lisp-kernel ... > > Error: Error(s) during kernel compilation. To see what the errors are, cd to ccl/lisp-kernel/darwinppc and type "make". I hesitate to mention it, but note that you need to have the Xcode tools installed in order to build the lisp kernel. I believe that Xcode 2.5 is the recommended version for 10.4 systems. (That's what I've got installed on my Tiger/ppc32 system anyway.) From gb at clozure.com Fri May 1 13:24:01 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 1 May 2009 14:24:01 -0600 (MDT) Subject: [Openmcl-devel] Cocoa on PPC32 ? In-Reply-To: <622B39BA-CB42-4BF5-823A-E89253D58F02@clozure.com> References: <20090501071254.24792qqrz15tboc6@illation.sg> <20090501020100.W28729@abq.clozure.com> <20090501113114.40733a6r9wb3xcoy@illation.sg> <622B39BA-CB42-4BF5-823A-E89253D58F02@clozure.com> Message-ID: <20090501135415.P68134@abq.clozure.com> If 'make' (installed as part of Xcode on OSX) was installed but running make generated errors, we'd almost certainly have seen some output describing what those errors were, so it's pretty likely that trying to run make just failed. About all that we can say in that case is something like "trying to run 'make' via RUN-PROGRAM failed", but we just get a pretty generic "system error" that doesn't say too much about what the problem is. Since a couple of people have run into this in the last few weeks, it's probably worth at least trying to say "trying to run 'make' ... failed for some reason", and may be worth mentioning that that may be because 'make' (and possibly other developer tools) aren't installed. I'm sure that most people realize (if they think about it) that it's pretty hard to compile C and assembler source code if the tools used to do so aren't installed; I'm not sure that we can reliably do too much more here (if the (RUN-PROGRAM "make" ...) just fails) besides suggesting the possibility that it may be an installation problem (and perhaps help people to think about that.) On Fri, 1 May 2009, R. Matthew Emerson wrote: > > On May 1, 2009, at 7:31 AM, Steve N??ez wrote: > >> Thanks. A fresh tarball download has solved the Cocoa problem >> however this same fresh checkout fails a full rebuild. The pre-built >> IDE runs fine, I'm trying to work through the Cocoa GUI examples. >> This is running 10.4.11: >> >> administrators-ibook-g4:~/Illation/Development/Applications/ccl admin >> $ ./dppccl >> Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinPPC32)! >> ? (rebuild-ccl :full t) >> Rebuilding Clozure Common Lisp using Version 1.3-r11936 (DarwinPPC32) >> ;Building lisp-kernel ... >>> Error: Error(s) during kernel compilation. > > To see what the errors are, cd to ccl/lisp-kernel/darwinppc and type > "make". > > I hesitate to mention it, but note that you need to have the Xcode > tools installed in order to build the lisp kernel. I believe that > Xcode 2.5 is the recommended version for 10.4 systems. (That's what > I've got installed on my Tiger/ppc32 system anyway.) > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From gb at clozure.com Fri May 1 16:12:05 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 1 May 2009 17:12:05 -0600 (MDT) Subject: [Openmcl-devel] Speed of concatenate vs format In-Reply-To: <9391C9E3-05FF-449B-A4BC-C0A40524CF52@gmail.com> References: <9391C9E3-05FF-449B-A4BC-C0A40524CF52@gmail.com> Message-ID: <20090501150757.O68134@abq.clozure.com> Looking at some profiling output for the (CONCATENATE 'STRING ...) case: samples % image name app name symbol name 20960 22.3674 lx86cl64 lx86cl64 misc_set_common 15148 16.1651 profccl64 profccl64 12780 13.6381 lx86cl64 lx86cl64 misc_ref_common 12281 13.1056 lx86cl64 lx86cl64 _SPbuiltin_aset1 11181 11.9317 lx86cl64 lx86cl64 _SPsubtag_misc_set 8086 8.6289 lx86cl64 lx86cl64 _SPbuiltin_aref1 7731 8.2501 lx86cl64 lx86cl64 _SPsubtag_misc_ref shows that the biggest culprits are some combination of CCL::CONCAT-TO-SIMPLE* (which may be a bit of a dog; I haven't looked at it yet ...) and things that implement AREF and (SETF AREF) on 1-dimensional arrays whose element type isn't known at compile-time. If the element-type of the result sequence in a call to CONCATENATE is known at compile-time, then those things - which are written in assembler and aren't grossly inefficient, for what they do - then those things can be replaced with simpler, inlined, type-specific things. It certainly takes FORMAT or PRINC a while to get to the point where it realizes that it's transferring characters from one string to another than it should take some flavor of CONCATENATE, but the loop that actually transfers those characters - 4000 references and 4000 assignments on each iteration - can use those simpler, type-specific reference and assignment operations that the more generic CONCATENATE and its aux functions can be. (Saving the extra generic AREF overhead 4000 times and the generic (SETF AREF) overhead another 4000 times adds up; you probably wouldn't see results like this with shorter strings.) Some uses of CONCATENATE are more common than others, and using concatenate with a result-type that's equivalent to STRING (and with source arguments that're very often STRINGs and likely SIMPLE-STRINGs) may be the most common usage of CONCATENATE. A fairly straightforward way of trying to exploit that is: (defun concatenate-to-string (&rest sequences) (declare (dynamic-extent sequences)) (let* ((len 0)) (declare (fixnum len)) (dolist (seq sequences) (incf len (length seq))) (let* ((result (make-string len)) (out 0)) (declare (simple-string result) (fixnum out) (optimize (speed 3) (safety 0))) (dolist (seq sequences result) (etypecase seq (simple-string (locally (declare (simple-string seq)) (dotimes (i (length seq)) (setf (schar result out) (schar seq i)) (incf out)))) (string (let* ((slen (length seq))) (declare (fixnum slen)) (multiple-value-bind (data offset) (ccl::array-data-and-offset seq) (declare (fixnum offset) (simple-string data)) (dotimes (i slen) (setf (schar result out) (schar seq offset)) (incf offset) (incf out))))) (vector (dotimes (i (length seq)) (setf (schar result out) (aref seq i)) (incf out))) (list (dolist (elt seq) (setf (schar result out) elt) (incf out)))))))) (I'm sure that this could be made faster still by BLTing things around and in other ways.) Since a sequence function result that's of type STRING is always a SIMPLE-STRING, that recognizes that it can always use (SETF SCHAR) to store into the result. If we're correct in assuming that the source sequences are often STRINGs (and often SIMPLE-STRINGs), the function tries to arrange to use SCHAR to access source characters in those cases. That's likely to be substantially faster than the more generic CONCATENATE (though it could surely call this code if it recognizes that the result type is appropriate, and a compiler macro could do that recognition at compile time.) This should also be faster than using FORMAT or PRINC to write to a STRING-OUTPUT-STREAM, but when the strings involved are large may not be as much faster as one might expect: the dominant inner loop in the case of doing WRITE-STRING to a STRING-OUTPUT-STREAM is pretty much the same SCHAR/(SETF SCHAR) stuff as happens above. In all of these cases, the memory-management overhead is pretty significant (and relatively constant). If I'm doing the math right and factoring that out correctly, then it looks like CONCATENATE-TO-STRING is around 7X faster than CONCATENATE on your test case (and a few X faster than the WRITE-STRING versions.) For shorter strings, the speedup isn't likely to be that dramatic, but it may still noticeable and it's unlikely that CONCATENATE-TO-STRING would ever be slower than the other approaches. On Fri, 1 May 2009, Daniel Dickison wrote: > I've been working with some legacy code that contains many instances > of -- > > (format nil "~a~a" string1 string2) > > for concatenating strings. This code is in some code that is a > performance bottleneck, and I thought, surely, this would be more > efficient if rewritten as -- > > (concatenate 'string string1 string2) > > but this turns out not to be the case. In fact, using format for > string concatenation is significantly faster. So assuming the > overhead for parsing the format control string is negligible, the > format version probably becomes two calls to princ wrapped in a with- > output-to-string. How come this is so much faster than concatenate? > > Now that I've done the profiling, I know which code to use, but I'm > still really curious why this is the case. I would appreciate any > insight. Below is the results of some quick-and-dirty profiling on > CCL Version 1.3-r11987M (DarwinX8664), an iMac Core 2 Duo. > > Thanks! > > Daniel > > > CL-USER> (defvar *str* (make-string 2000 :initial-element #\a)) > *STR* > > CL-USER> (time (dotimes (i 100000) > (format nil "~a~a" *str* *str*))) > (DOTIMES (I 100000) (FORMAT NIL "~a~a" *STR* *STR*)) took 5,547,598 > microseconds (5.547598 seconds) to run > with 2 available CPU cores. > During that period, 3,288,825 microseconds (3.288825 seconds) were > spent in user mode > 770,732 microseconds (0.770732 seconds) were > spent in system mode > 1,076,633 microseconds (1.076633 seconds) was spent in GC. > 1,606,416,016 bytes of memory allocated. > NIL > > CL-USER> (time (dotimes (i 100000) > (concatenate 'string *str* *str*))) > (DOTIMES (I 100000) (CONCATENATE 'STRING *STR* *STR*)) took 10,373,570 > microseconds (10.373570 seconds) to run > with 2 available CPU cores. > During that period, 8,092,791 microseconds (8.092791 seconds) were > spent in user mode > 878,887 microseconds (0.878887 seconds) were > spent in system mode > 1,097,819 microseconds (1.097819 seconds) was spent in GC. > 1,601,600,000 bytes of memory allocated. > NIL > > CL-USER> (time (dotimes (i 100000) > (with-output-to-string (s) > (princ *str* s) > (princ *str* s)))) > (DOTIMES (I 100000) (WITH-OUTPUT-TO-STRING (S) (PRINC *STR* S) (PRINC > *STR* S))) took 5,284,978 microseconds (5.284978 seconds) to run > with 2 available CPU cores. > During that period, 3,153,681 microseconds (3.153681 seconds) were > spent in user mode > 752,712 microseconds (0.752712 seconds) were > spent in system mode > 1,087,328 microseconds (1.087328 seconds) was spent in GC. > 1,606,416,016 bytes of memory allocated. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From steve.nunez at illation.com.sg Fri May 1 16:30:38 2009 From: steve.nunez at illation.com.sg (Steve =?utf-8?b?TsO6w7Fleg==?=) Date: Fri, 01 May 2009 23:30:38 +0000 Subject: [Openmcl-devel] Cocoa on PPC32 ? In-Reply-To: <20090501135415.P68134@abq.clozure.com> References: <20090501071254.24792qqrz15tboc6@illation.sg> <20090501020100.W28729@abq.clozure.com> <20090501113114.40733a6r9wb3xcoy@illation.sg> <622B39BA-CB42-4BF5-823A-E89253D58F02@clozure.com> <20090501135415.P68134@abq.clozure.com> Message-ID: <20090501233038.21362qktinzxzva6@illation.sg> Gentlemen, Thanks. It is the fact that I don't have XCode installed on this computer (a temporary one whilst my regular machine is out for repair). Gary's suggestion for a reminder is a good one and would have lead me to the answer straight away. Cheers, - Steve Quoting Gary Byers : > If 'make' (installed as part of Xcode on OSX) was installed but > running make generated errors, we'd almost certainly have seen some > output describing what those errors were, so it's pretty likely that > trying to run make just failed. About all that we can say in that > case is something like "trying to run 'make' via RUN-PROGRAM failed", > but we just get a pretty generic "system error" that doesn't say too > much about what the problem is. > > Since a couple of people have run into this in the last few weeks, > it's probably worth at least trying to say "trying to run 'make' > ... failed for some reason", and may be worth mentioning that that may > be because 'make' (and possibly other developer tools) aren't > installed. > > I'm sure that most people realize (if they think about it) that it's > pretty hard to compile C and assembler source code if the tools used > to do so aren't installed; I'm not sure that we can reliably do too > much more here (if the (RUN-PROGRAM "make" ...) just fails) besides > suggesting the possibility that it may be an installation problem (and > perhaps help people to think about that.) > > On Fri, 1 May 2009, R. Matthew Emerson wrote: > >> >> On May 1, 2009, at 7:31 AM, Steve N??ez wrote: >> >>> Thanks. A fresh tarball download has solved the Cocoa problem >>> however this same fresh checkout fails a full rebuild. The pre-built >>> IDE runs fine, I'm trying to work through the Cocoa GUI examples. >>> This is running 10.4.11: >>> >>> administrators-ibook-g4:~/Illation/Development/Applications/ccl admin >>> $ ./dppccl >>> Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinPPC32)! >>> ? (rebuild-ccl :full t) >>> Rebuilding Clozure Common Lisp using Version 1.3-r11936 (DarwinPPC32) >>> ;Building lisp-kernel ... >>>> Error: Error(s) during kernel compilation. >> >> To see what the errors are, cd to ccl/lisp-kernel/darwinppc and type >> "make". >> >> I hesitate to mention it, but note that you need to have the Xcode >> tools installed in order to build the lisp kernel. I believe that >> Xcode 2.5 is the recommended version for 10.4 systems. (That's what >> I've got installed on my Tiger/ppc32 system anyway.) >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danieldickison at gmail.com Fri May 1 18:36:44 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Fri, 1 May 2009 21:36:44 -0400 Subject: [Openmcl-devel] Speed of concatenate vs format In-Reply-To: <20090501150757.O68134@abq.clozure.com> References: <9391C9E3-05FF-449B-A4BC-C0A40524CF52@gmail.com> <20090501150757.O68134@abq.clozure.com> Message-ID: Gary, I really appreciate your detailed and insightful response (as always)! I hadn't thought about the difference between char and schar, and I didn't realize that it would make that much of a difference. Sure enough, your concatenate-to-string is significantly faster than format or concatenate. I'm on a different machine now, but for concatenating two 2000- character simple-strings 100,000 times, I get 4.0 vs 5.4 vs 10.8 seconds for concat-to-string, format, and concatenate, respectively. With 100-character strings, it's about 0.23 vs 0.83 vs 0.63. I imagine concatenating short simple-strings is quite a common operation, so a compiler-macro to automate this optimization might help a lot of applications. Regardless, using concatenate-to-string explicitly should give a boost. Thanks again. Daniel On May 1, 2009, at 7:12 PM, Gary Byers wrote: > Looking at some profiling output for the (CONCATENATE 'STRING ...) > case: > > > samples % image name app name > symbol name > 20960 22.3674 lx86cl64 lx86cl64 > misc_set_common > 15148 16.1651 profccl64 profccl64 > > 12780 13.6381 lx86cl64 lx86cl64 > misc_ref_common > 12281 13.1056 lx86cl64 lx86cl64 > _SPbuiltin_aset1 > 11181 11.9317 lx86cl64 lx86cl64 > _SPsubtag_misc_set > 8086 8.6289 lx86cl64 lx86cl64 > _SPbuiltin_aref1 > 7731 8.2501 lx86cl64 lx86cl64 > _SPsubtag_misc_ref > > shows that the biggest culprits are some combination of > CCL::CONCAT-TO-SIMPLE* (which may be a bit of a dog; I haven't looked > at it yet ...) and things that implement AREF and (SETF AREF) on > 1-dimensional arrays whose element type isn't known at compile-time. > If the element-type of the result sequence in a call to CONCATENATE is > known at compile-time, then those things - which are written in > assembler and aren't grossly inefficient, for what they do - then > those things can be replaced with simpler, inlined, type-specific > things. It certainly takes FORMAT or PRINC a while to get to the > point where it realizes that it's transferring characters from one > string to another than it should take some flavor of CONCATENATE, but > the loop that actually transfers those characters - 4000 references > and 4000 assignments on each iteration - can use those simpler, > type-specific reference and assignment operations that the more > generic CONCATENATE and its aux functions can be. (Saving the extra > generic AREF overhead 4000 times and the generic (SETF AREF) overhead > another 4000 times adds up; you probably wouldn't see results like > this with shorter strings.) > > Some uses of CONCATENATE are more common than others, and using > concatenate with a result-type that's equivalent to STRING (and with > source arguments that're very often STRINGs and likely SIMPLE-STRINGs) > may be the most common usage of CONCATENATE. A fairly straightforward > way of trying to exploit that is: > > (defun concatenate-to-string (&rest sequences) > (declare (dynamic-extent sequences)) > (let* ((len 0)) > (declare (fixnum len)) > (dolist (seq sequences) > (incf len (length seq))) > (let* ((result (make-string len)) > (out 0)) > (declare (simple-string result) (fixnum out) > (optimize (speed 3) (safety 0))) > (dolist (seq sequences result) > (etypecase seq > (simple-string > (locally (declare (simple-string seq)) > (dotimes (i (length seq)) > (setf (schar result out) (schar seq i)) > (incf out)))) > (string > (let* ((slen (length seq))) > (declare (fixnum slen)) > (multiple-value-bind (data offset) > (ccl::array-data-and-offset seq) > (declare (fixnum offset) (simple-string data)) > (dotimes (i slen) > (setf (schar result out) (schar seq offset)) > (incf offset) > (incf out))))) > (vector > (dotimes (i (length seq)) > (setf (schar result out) (aref seq i)) > (incf out))) > (list > (dolist (elt seq) > (setf (schar result out) elt) > (incf out)))))))) > > (I'm sure that this could be made faster still by BLTing things around > and in other ways.) > > Since a sequence function result that's of type STRING is always a > SIMPLE-STRING, > that recognizes that it can always use (SETF SCHAR) to store into > the result. If > we're correct in assuming that the source sequences are often > STRINGs (and often > SIMPLE-STRINGs), the function tries to arrange to use SCHAR to > access source > characters in those cases. That's likely to be substantially faster > than the > more generic CONCATENATE (though it could surely call this code if > it recognizes > that the result type is appropriate, and a compiler macro could do > that recognition > at compile time.) > > This should also be faster than using FORMAT or PRINC to write to a > STRING-OUTPUT-STREAM, but when the strings involved are large may > not be as > much faster as one might expect: the dominant inner loop in the case > of doing > WRITE-STRING to a STRING-OUTPUT-STREAM is pretty much the same SCHAR/ > (SETF SCHAR) > stuff as happens above. > > In all of these cases, the memory-management overhead is pretty > significant (and > relatively constant). If I'm doing the math right and factoring > that out correctly, > then it looks like CONCATENATE-TO-STRING is around 7X faster than > CONCATENATE on > your test case (and a few X faster than the WRITE-STRING versions.) > For shorter > strings, the speedup isn't likely to be that dramatic, but it may > still noticeable > and it's unlikely that CONCATENATE-TO-STRING would ever be slower > than the other > approaches. > > > > > On Fri, 1 May 2009, Daniel Dickison wrote: > >> I've been working with some legacy code that contains many instances >> of -- >> >> (format nil "~a~a" string1 string2) >> >> for concatenating strings. This code is in some code that is a >> performance bottleneck, and I thought, surely, this would be more >> efficient if rewritten as -- >> >> (concatenate 'string string1 string2) >> >> but this turns out not to be the case. In fact, using format for >> string concatenation is significantly faster. So assuming the >> overhead for parsing the format control string is negligible, the >> format version probably becomes two calls to princ wrapped in a with- >> output-to-string. How come this is so much faster than concatenate? >> >> Now that I've done the profiling, I know which code to use, but I'm >> still really curious why this is the case. I would appreciate any >> insight. Below is the results of some quick-and-dirty profiling on >> CCL Version 1.3-r11987M (DarwinX8664), an iMac Core 2 Duo. >> >> Thanks! >> >> Daniel >> >> >> CL-USER> (defvar *str* (make-string 2000 :initial-element #\a)) >> *STR* >> >> CL-USER> (time (dotimes (i 100000) >> (format nil "~a~a" *str* *str*))) >> (DOTIMES (I 100000) (FORMAT NIL "~a~a" *STR* *STR*)) took 5,547,598 >> microseconds (5.547598 seconds) to run >> with 2 available CPU cores. >> During that period, 3,288,825 microseconds (3.288825 seconds) were >> spent in user mode >> 770,732 microseconds (0.770732 seconds) were >> spent in system mode >> 1,076,633 microseconds (1.076633 seconds) was spent in GC. >> 1,606,416,016 bytes of memory allocated. >> NIL >> >> CL-USER> (time (dotimes (i 100000) >> (concatenate 'string *str* *str*))) >> (DOTIMES (I 100000) (CONCATENATE 'STRING *STR* *STR*)) took >> 10,373,570 >> microseconds (10.373570 seconds) to run >> with 2 available CPU cores. >> During that period, 8,092,791 microseconds (8.092791 seconds) were >> spent in user mode >> 878,887 microseconds (0.878887 seconds) were >> spent in system mode >> 1,097,819 microseconds (1.097819 seconds) was spent in GC. >> 1,601,600,000 bytes of memory allocated. >> NIL >> >> CL-USER> (time (dotimes (i 100000) >> (with-output-to-string (s) >> (princ *str* s) >> (princ *str* s)))) >> (DOTIMES (I 100000) (WITH-OUTPUT-TO-STRING (S) (PRINC *STR* S) (PRINC >> *STR* S))) took 5,284,978 microseconds (5.284978 seconds) to run >> with 2 available CPU cores. >> During that period, 3,153,681 microseconds (3.153681 seconds) were >> spent in user mode >> 752,712 microseconds (0.752712 seconds) were >> spent in system mode >> 1,087,328 microseconds (1.087328 seconds) was spent in GC. >> 1,606,416,016 bytes of memory allocated. >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> From martin.lisp at gmail.com Sat May 2 14:00:55 2009 From: martin.lisp at gmail.com (Martin) Date: Sun, 03 May 2009 00:00:55 +0300 Subject: [Openmcl-devel] ENSURE-DIRECTORIES-EXIST and DIRECTORY on Windows Message-ID: Hi! First, I want to appreciate the work you have put into the Windows port of Clozure CL. Thanks. At the end of this mail is a patch which attempts to make CCL's DIRECTORY and ENSURE-DIRECTORIES-EXIST functions nicer on Windows. (I am using 1.3-r11949 on Windows XP SP2.) Most of the changes typically involve the addition of the :DEVICE component for to make the functions `drive aware'---if you will. For 1 and 2, the `context' is: ? (PATHNAME-DEVICE (CURRENT-DIRECTORY)) => C 1. ? (ENSURE-DIRECTORIES-EXIST "D:/dir1/dir2/") => creates "C:/dir1/dir2/" instead. 2. ? (DIRECTORY "D:/dir1/dir2/*.*") => NIL (despite having files in D:/dir1/dir2/). 3. I have a file tree with the following structure: D:. | init.bat | +---.dir2 | | .file3 | | file1.txt | | file2 | | | +---.dir1-2 | | .file5 | | file3.txt | | file4 | | | \---dir1-1 | .file3 | file1.txt | file2 | \---dir1 | .file3 | file1.txt | file2 | +---.dir1-2 | .file5 | file3.txt | file4 | \---dir1-1 .file3 file1.txt file2 ? (DIRECTORY #P"D:/sources/lang/lisp/ccl/tests/**/.dir2/" :directories t)) => '(#P"/sources/lang/lisp/ccl/tests/.dir2/" #P"/sources/lang/lisp/ccl/tests/.dir2/.dir2/" #P"/sources/lang/lisp/ccl/tests/.dir2/.dir1-2/.dir2/" #P"/sources/lang/lisp/ccl/tests/.dir2/dir1-1/.dir2/" #P"/sources/lang/lisp/ccl/tests/dir1/.dir2/" #P"/sources/lang/lisp/ccl/tests/dir1/.dir1-2/.dir2/" #P"/sources/lang/lisp/ccl/tests/dir1/dir1-1/.dir2/") If I understand the Spec well, I expected: #P"D:/sources/lang/lisp/ccl/tests/.dir2/" Regards, Martin. Patch: (In the expected format, I hope.) ;;; -------------------------------------------------- ;;; BOF --- pathnames.orig.lisp +++ pathnames.new.lisp @@ -231,4 +231,6 @@ argument." - (let* ((pathname (make-directory-pathname :directory (pathname-directory (translate-logical-pathname (merge-pathnames pathspec))))) - (created-p nil)) + (let ((pathname (let ((pathspec (translate-logical-pathname (merge-pathnames pathspec)))) + (make-directory-pathname :device (pathname-device pathspec) + :directory (pathname-directory pathspec)))) + (created-p nil)) (when (wild-pathname-p pathname) @@ -301,4 +303,9 @@ -(defmacro with-open-dir ((dirent dir) &body body) - `(let ((,dirent (%open-dir ,dir))) +(defun %path-cat (device dir subdir) + (if device + (%str-cat device ":" dir subdir) + (%str-cat dir subdir))) + +(defmacro with-open-dir ((dirent device dir) &body body) + `(let ((,dirent (%open-dir (namestring (make-pathname :device ,device :directory ,dir))))) (when ,dirent @@ -361,4 +368,7 @@ (defun %one-wild (dir wild rest path so-far keys) - (let ((result ()) (all (getf keys :all)) name subdir) - (with-open-dir (dirent dir) + (let ((result ()) + (device (pathname-device path)) + (all (getf keys :all)) + name) + (with-open-dir (dirent device dir) (while (setq name (%read-dir dirent)) @@ -368,4 +378,5 @@ (%path-pstr*= wild name) - (eq (%unix-file-kind (setq subdir (%str-cat dir name)) t) :directory)) - (let ((so-far (cons (%path-std-quotes name nil "/;:*") so-far))) + (eq (%unix-file-kind (%path-cat device dir name) t) :directory)) + (let ((subdir (%path-cat nil dir name)) + (so-far (cons (%path-std-quotes name nil "/;:*") so-far))) (declare (dynamic-extent so-far)) @@ -376,3 +387,4 @@ (defun %files-in-directory (dir path so-far keys) - (let ((name (pathname-name path)) + (let ((device (pathname-device path)) + (name (pathname-name path)) (type (pathname-type path)) @@ -388,9 +400,12 @@ (if (not (or name type)) - (when directories - (setq ans (if directory-pathnames - (%cons-pathname (reverse so-far) nil nil) - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) - (when (and ans (or (null test) (funcall test ans))) - (setq result (list ans)))) - (with-open-dir (dirent dir) + (let (full-path) + (when (and directories + (eq (%unix-file-kind (namestring (setq full-path (%cons-pathname (reverse so-far) nil nil nil device))) + t) + :directory)) + (setq ans (if directory-pathnames full-path + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil device))) + (when (and ans (or (null test) (funcall test ans))) + (setq result (list ans))))) + (with-open-dir (dirent (pathname-device path) dir) (while (setq sub (%read-dir dirent)) @@ -404,3 +419,3 @@ (setq ans - (if (eq (%unix-file-kind (%str-cat dir sub) t) :directory) + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) (when directories @@ -408,7 +423,7 @@ (if directory-pathnames - (%cons-pathname (reverse (cons std-sub so-far)) nil nil) - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) std-sub nil)))) + (%cons-pathname (reverse (cons std-sub so-far)) nil nil nil device) + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) std-sub nil nil device)))) (when files (multiple-value-bind (name type) (%std-name-and-type sub) - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name type))))) + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name type nil device))))) (when (and ans (or (null test) (funcall test ans))) @@ -421,2 +436,3 @@ (result nil) + (device (pathname-device path)) (name (pathname-name path)) @@ -427,3 +443,3 @@ (follow-links (getf keys :follow-links)) - sub subfile dir-list ans) + sub dir-list ans) ;; First process the case that the ** stands for 0 components @@ -446,4 +462,4 @@ (setq sub (if directory-pathnames - (%cons-pathname (setq dir-list (reverse so-far)) nil nil) - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) + (%cons-pathname (setq dir-list (reverse so-far)) nil nil nil device) + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil device))) (when (or (null test) (funcall test sub)) @@ -451,3 +467,3 @@ ; now descend doing %all-dirs on dirs and collecting files & dirs if do-x is t - (with-open-dir (dirent dir) + (with-open-dir (dirent device dir) (while (setq sub (%read-dir dirent)) @@ -456,4 +472,5 @@ (not (string= sub ".."))) - (if (eq (%unix-file-kind (setq subfile (%str-cat dir sub)) t) :directory) - (let* ((std-sub (%path-std-quotes sub nil "/;:*")) + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) + (let* ((subfile (%path-cat nil dir sub)) + (std-sub (%path-std-quotes sub nil "/;:*")) (so-far (cons std-sub so-far)) @@ -463,5 +480,5 @@ (setq ans (if directory-pathnames - (%cons-pathname (reverse so-far) nil nil) + (%cons-pathname (reverse so-far) nil nil nil device) (%cons-pathname (or dir-list (setq dir-list (reverse (cdr so-far)))) - std-sub nil))) + std-sub nil nil device))) (when (or (null test) (funcall test ans)) @@ -471,3 +488,3 @@ (multiple-value-bind (name type) (%std-name-and-type sub) - (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name type)) + (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name type nil device)) (when (or (null test) (funcall test ans)) ;;; EOF ;;; -------------------------------------------------- From gb at clozure.com Sun May 3 03:03:34 2009 From: gb at clozure.com (Gary Byers) Date: Sun, 3 May 2009 04:03:34 -0600 (MDT) Subject: [Openmcl-devel] ENSURE-DIRECTORIES-EXIST and DIRECTORY on Windows In-Reply-To: References: Message-ID: <20090503040146.S97662@abq.clozure.com> Yes, both of those functions were neglecting to handle PATHNAME-DEVICE. D'oh! Thanks. On Sun, 3 May 2009, Martin wrote: > Hi! > > First, I want to appreciate the work you have put into the Windows port > of Clozure CL. Thanks. > > At the end of this mail is a patch which attempts to make CCL's > DIRECTORY and ENSURE-DIRECTORIES-EXIST functions nicer on Windows. > > (I am using 1.3-r11949 on Windows XP SP2.) > > Most of the changes typically involve the addition of the :DEVICE > component for to make the functions `drive aware'---if you will. > > For 1 and 2, the `context' is: > > ? (PATHNAME-DEVICE (CURRENT-DIRECTORY)) => C > > > > 1. > > ? (ENSURE-DIRECTORIES-EXIST "D:/dir1/dir2/") => creates "C:/dir1/dir2/" > instead. > > > > 2. > > ? (DIRECTORY "D:/dir1/dir2/*.*") => NIL (despite having files in > D:/dir1/dir2/). > > > > 3. I have a file tree with the following structure: > > D:. > | init.bat > | > +---.dir2 > | | .file3 > | | file1.txt > | | file2 > | | > | +---.dir1-2 > | | .file5 > | | file3.txt > | | file4 > | | > | \---dir1-1 > | .file3 > | file1.txt > | file2 > | > \---dir1 > | .file3 > | file1.txt > | file2 > | > +---.dir1-2 > | .file5 > | file3.txt > | file4 > | > \---dir1-1 > .file3 > file1.txt > file2 > > > ? (DIRECTORY #P"D:/sources/lang/lisp/ccl/tests/**/.dir2/" :directories t)) > => > '(#P"/sources/lang/lisp/ccl/tests/.dir2/" > #P"/sources/lang/lisp/ccl/tests/.dir2/.dir2/" > #P"/sources/lang/lisp/ccl/tests/.dir2/.dir1-2/.dir2/" > #P"/sources/lang/lisp/ccl/tests/.dir2/dir1-1/.dir2/" > #P"/sources/lang/lisp/ccl/tests/dir1/.dir2/" > #P"/sources/lang/lisp/ccl/tests/dir1/.dir1-2/.dir2/" > #P"/sources/lang/lisp/ccl/tests/dir1/dir1-1/.dir2/") > > If I understand the Spec well, I expected: > #P"D:/sources/lang/lisp/ccl/tests/.dir2/" > > Regards, > Martin. > > > Patch: (In the expected format, I hope.) > > ;;; -------------------------------------------------- > ;;; BOF > > > > --- pathnames.orig.lisp > +++ pathnames.new.lisp > @@ -231,4 +231,6 @@ > argument." > - (let* ((pathname (make-directory-pathname :directory > (pathname-directory (translate-logical-pathname (merge-pathnames > pathspec))))) > - (created-p nil)) > + (let ((pathname (let ((pathspec (translate-logical-pathname > (merge-pathnames pathspec)))) > + (make-directory-pathname :device (pathname-device pathspec) > + :directory (pathname-directory pathspec)))) > + (created-p nil)) > (when (wild-pathname-p pathname) > @@ -301,4 +303,9 @@ > > -(defmacro with-open-dir ((dirent dir) &body body) > - `(let ((,dirent (%open-dir ,dir))) > +(defun %path-cat (device dir subdir) > + (if device > + (%str-cat device ":" dir subdir) > + (%str-cat dir subdir))) > + > +(defmacro with-open-dir ((dirent device dir) &body body) > + `(let ((,dirent (%open-dir (namestring (make-pathname :device ,device > :directory ,dir))))) > (when ,dirent > @@ -361,4 +368,7 @@ > (defun %one-wild (dir wild rest path so-far keys) > - (let ((result ()) (all (getf keys :all)) name subdir) > - (with-open-dir (dirent dir) > + (let ((result ()) > + (device (pathname-device path)) > + (all (getf keys :all)) > + name) > + (with-open-dir (dirent device dir) > (while (setq name (%read-dir dirent)) > @@ -368,4 +378,5 @@ > (%path-pstr*= wild name) > - (eq (%unix-file-kind (setq subdir (%str-cat dir name)) t) :directory)) > - (let ((so-far (cons (%path-std-quotes name nil "/;:*") so-far))) > + (eq (%unix-file-kind (%path-cat device dir name) t) :directory)) > + (let ((subdir (%path-cat nil dir name)) > + (so-far (cons (%path-std-quotes name nil "/;:*") so-far))) > (declare (dynamic-extent so-far)) > @@ -376,3 +387,4 @@ > (defun %files-in-directory (dir path so-far keys) > - (let ((name (pathname-name path)) > + (let ((device (pathname-device path)) > + (name (pathname-name path)) > (type (pathname-type path)) > @@ -388,9 +400,12 @@ > (if (not (or name type)) > - (when directories > - (setq ans (if directory-pathnames > - (%cons-pathname (reverse so-far) nil nil) > - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) > - (when (and ans (or (null test) (funcall test ans))) > - (setq result (list ans)))) > - (with-open-dir (dirent dir) > + (let (full-path) > + (when (and directories > + (eq (%unix-file-kind (namestring (setq full-path (%cons-pathname > (reverse so-far) nil nil nil device))) > + t) > + :directory)) > + (setq ans (if directory-pathnames full-path > + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil > device))) > + (when (and ans (or (null test) (funcall test ans))) > + (setq result (list ans))))) > + (with-open-dir (dirent (pathname-device path) dir) > (while (setq sub (%read-dir dirent)) > @@ -404,3 +419,3 @@ > (setq ans > - (if (eq (%unix-file-kind (%str-cat dir sub) t) :directory) > + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) > (when directories > @@ -408,7 +423,7 @@ > (if directory-pathnames > - (%cons-pathname (reverse (cons std-sub so-far)) nil nil) > - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) > std-sub nil)))) > + (%cons-pathname (reverse (cons std-sub so-far)) nil nil nil device) > + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) > std-sub nil nil device)))) > (when files > (multiple-value-bind (name type) (%std-name-and-type sub) > - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name > type))))) > + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name > type nil device))))) > (when (and ans (or (null test) (funcall test ans))) > @@ -421,2 +436,3 @@ > (result nil) > + (device (pathname-device path)) > (name (pathname-name path)) > @@ -427,3 +443,3 @@ > (follow-links (getf keys :follow-links)) > - sub subfile dir-list ans) > + sub dir-list ans) > ;; First process the case that the ** stands for 0 components > @@ -446,4 +462,4 @@ > (setq sub (if directory-pathnames > - (%cons-pathname (setq dir-list (reverse so-far)) nil nil) > - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) > + (%cons-pathname (setq dir-list (reverse so-far)) nil nil nil > device) > + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil > device))) > (when (or (null test) (funcall test sub)) > @@ -451,3 +467,3 @@ > ; now descend doing %all-dirs on dirs and collecting files & dirs > if do-x is t > - (with-open-dir (dirent dir) > + (with-open-dir (dirent device dir) > (while (setq sub (%read-dir dirent)) > @@ -456,4 +472,5 @@ > (not (string= sub ".."))) > - (if (eq (%unix-file-kind (setq subfile (%str-cat dir sub)) t) > :directory) > - (let* ((std-sub (%path-std-quotes sub nil "/;:*")) > + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) > + (let* ((subfile (%path-cat nil dir sub)) > + (std-sub (%path-std-quotes sub nil "/;:*")) > (so-far (cons std-sub so-far)) > @@ -463,5 +480,5 @@ > (setq ans (if directory-pathnames > - (%cons-pathname (reverse so-far) nil nil) > + (%cons-pathname (reverse so-far) nil nil nil device) > (%cons-pathname (or dir-list (setq dir-list (reverse (cdr > so-far)))) > - std-sub nil))) > + std-sub nil nil device))) > (when (or (null test) (funcall test ans)) > @@ -471,3 +488,3 @@ > (multiple-value-bind (name type) (%std-name-and-type sub) > - (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse > so-far))) name type)) > + (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse > so-far))) name type nil device)) > (when (or (null test) (funcall test ans)) > > > > ;;; EOF > ;;; -------------------------------------------------- > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From martin.lisp at gmail.com Sun May 3 08:18:55 2009 From: martin.lisp at gmail.com (Martin) Date: Sun, 03 May 2009 18:18:55 +0300 Subject: [Openmcl-devel] Floating point exceptions on Windows Message-ID: Hi! I am using CCL 1.3-r11949 on Windows XP SP2 and have a problem with floating point exception propagation. Now, I have a file app1.c with a function with the following code extract: __declspec(dllexport) double fn1 () { double zero = 0; return 1.0/zero; } I compiled it into a DLL (Using MS Visual C++ 2005 Express Edition) with the following command: cl /LD app1.c to yield app1.dll. Using it in CCL: Welcome to Clozure Common Lisp Version 1.3-r11949M (WindowsX8632)! ? (open-shared-library "D:/studies/floats/app1/app1.dll") # ? (ff-call (%reference-external-entry-point (external "fn1")) :double-float) 1.0000000000000002D0 ? (log 10) > Error: DIVISION-BY-ZERO detected > performing LOG on (10.0) > While executing: CCL::%FP-ERROR-FROM-STATUS, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > Two questions: 1. Is there a way that to can get the error signaled on the offending statement rather than being propagated to the next? 2. How can I disable floating point exceptions from within CCL? (To put the problem in context, let me mention that I encountered a problem along these lines while trying to create a wrapper for the RealLib library.) Regards, Martin. From sky at viridian-project.de Sun May 3 09:32:37 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 3 May 2009 18:32:37 +0200 (CEST) Subject: [Openmcl-devel] Stream X is private to TTY-LISTENER Message-ID: I've just got this interesting error. What does it mean and how can I solve it? Thanks, Leslie -- http://www.linkedin.com/in/polzer From gb at clozure.com Sun May 3 11:29:29 2009 From: gb at clozure.com (Gary Byers) Date: Sun, 3 May 2009 12:29:29 -0600 (MDT) Subject: [Openmcl-devel] Stream X is private to TTY-LISTENER In-Reply-To: References: Message-ID: <20090503121814.I4013@abq.clozure.com> As noted in section 9.1.2 of the manual, functions that create streams (OPEN, MAKE-SOCKET) take a :SHARING argument whose value controls whether and how the stream can be used by multiple threads. The default value of :SHARING is :PRIVATE, which means that the stream can only be used from the thread that created it; attempting to do I/O on a :SHARING :PRIVATE stream from a thread that didn't create it results in the error in the message subject. As should be noted in the manual's dictionary entry for RUN-PROGRAM but isn't, RUN-PROGRAM also takes a :SHARING argument whose value controls how any streams created when the :INPUT, :OUTPUT, or :ERROR arguments are given a value of :STREAM are shared. On Sun, 3 May 2009, Leslie P. Polzer wrote: > > I've just got this interesting error. > > What does it mean and how can I solve it? > > Thanks, > > Leslie > > -- > http://www.linkedin.com/in/polzer > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From sky at viridian-project.de Sun May 3 11:53:10 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 3 May 2009 20:53:10 +0200 (CEST) Subject: [Openmcl-devel] Stream X is private to TTY-LISTENER In-Reply-To: <20090503121814.I4013@abq.clozure.com> References: <20090503121814.I4013@abq.clozure.com> Message-ID: Gary Byers wrote: > As noted in section 9.1.2 of the manual, My bad, that's an RTFM case then. I suspect that as CCL slowly becomes more popular for web applications this might become a FAQ, though. > As should be noted in the manual's dictionary entry for RUN-PROGRAM but > isn't, RUN-PROGRAM also takes a :SHARING argument whose value controls > how any streams created when the :INPUT, :OUTPUT, or :ERROR arguments are > given a value of :STREAM are shared. Thanks. That's not my use case, but in return for stealing your time with my issue I will amend the docs for RUN-PROGRAM. Leslie -- http://www.linkedin.com/in/polzer From joakim at joakimsandgren.com Sun May 3 11:55:05 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sun, 3 May 2009 20:55:05 +0200 Subject: [Openmcl-devel] default directory Message-ID: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> Hi, and thank you all for helping so much with my questions. here's another: based on the function choose-directory-dialog in the GUI package I have done another function adding some title strings, one for the panel one for the button. Now I would like to add the functionality that the panel opens in a default directory choosen by me. How do I do that? Sincerely Joakim (defun choose-directory-dialog () (execute-in-gui #'(lambda () (let ((op (#/openPanel ns:ns-open-panel))) (#/setAllowsMultipleSelection: op nil) (#/setCanChooseDirectories: op t) (#/setCanChooseFiles: op nil) (when (eql (#/runModalForTypes: op +null-ptr +) #$NSOKButton) ;; #/stringByStandardizingPath seems to strip trailing slashes (let* ((path (#/retain (#/ stringByAppendingString: (#/stringByStandardizingPath (#/objectAtIndex: (#/ filenames op) 0)) #@"/")))) path)))))) (defmethod choose-directory-dialog-with-strings ((dialogtitle string) (buttonstring string)) (gui::lisp-string-from-nsstring (gui::execute-in-gui #'(lambda () (let ((op (#/openPanel ns:ns-open-panel))) (#/setAllowsMultipleSelection: op nil) (#/setCanChooseDirectories: op t) (#/setCanChooseFiles: op nil) (#/setPrompt: op (ccl::%make-nsstring buttonstring)) (#/setTitle: op (ccl::%make-nsstring dialogtitle)) (when (eql (#/runModalForTypes: op +null-ptr+) #$NSOKButton) ;; #/stringByStandardizingPath seems to strip trailing slashes (let* ((path (#/retain (#/ stringByAppendingString: (#/ stringByStandardizingPath (#/ objectAtIndex: (#/filenames op) 0)) #@"/")))) path))))))) Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Sun May 3 13:15:26 2009 From: gb at clozure.com (Gary Byers) Date: Sun, 3 May 2009 14:15:26 -0600 (MDT) Subject: [Openmcl-devel] default directory In-Reply-To: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> References: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> Message-ID: <20090503131930.Y4013@abq.clozure.com> (#/runModalForTypes: panel ) is equivalent to: (#/runModalForDirectory:file:types: panel +null-ptr+ +null-ptr+ ) As one would guess from the method name, the two extra arguments accepted by the second function are an NSString denoting an absolute directory name and an NSString denoting a file in that directory. So the general idea is: (defun choose-directory-dialog (&optional default-directory) (execute-in-gui #'(lambda () ... (let* ((dirname (if default-directory (#/autorelease (ccl::%make-nsstring (namestring (truename default-directory)))) +null-ptr+))) ... (when (eql (#/runModalForDirectory:file:types: panel dirname +null-pointer+ +null-pointer+) #$NSOKButton) ...))))) is actually a good description of the functionality that NSOpenPanel offers; if you have Xcode installed, a local copy of the reference documentation is buried somewhere inside the Xcode installation directory (usually /Developer) someplace, and you may be able to find it ... Since it hasn't been plugged for a while, this seems like a good time to mention AppKido (), which is a good, free (well, the author accepts donations via PayPal now) tool for browsing a local copy of the Cocoa documentation. On Sun, 3 May 2009, Joakim Sandgren wrote: > Hi, and thank you all for helping so much with my questions. > here's another: > based on the function choose-directory-dialog in the GUI package I have done > another function adding some title strings, one for the panel one for the > button. > Now I would like to add the functionality that the panel opens in a default > directory choosen by me. > How do I do that? > > Sincerely > > Joakim > > > (defun choose-directory-dialog () > (execute-in-gui #'(lambda () > (let ((op (#/openPanel ns:ns-open-panel))) > (#/setAllowsMultipleSelection: op nil) > (#/setCanChooseDirectories: op t) > (#/setCanChooseFiles: op nil) > (when (eql (#/runModalForTypes: op +null-ptr+) > #$NSOKButton) > ;; #/stringByStandardizingPath seems to strip > trailing slashes > (let* ((path (#/retain (#/stringByAppendingString: > (#/stringByStandardizingPath > (#/objectAtIndex: (#/filenames op) > 0)) > #@"/")))) > path)))))) > > (defmethod choose-directory-dialog-with-strings ((dialogtitle string) > (buttonstring string)) > (gui::lisp-string-from-nsstring > (gui::execute-in-gui #'(lambda () > (let ((op (#/openPanel ns:ns-open-panel))) > (#/setAllowsMultipleSelection: op nil) > (#/setCanChooseDirectories: op t) > (#/setCanChooseFiles: op nil) > (#/setPrompt: op (ccl::%make-nsstring > buttonstring)) > (#/setTitle: op (ccl::%make-nsstring > dialogtitle)) > (when (eql (#/runModalForTypes: op +null-ptr+) > #$NSOKButton) > ;; #/stringByStandardizingPath seems to strip > trailing slashes > (let* ((path (#/retain > (#/stringByAppendingString: > (#/stringByStandardizingPath > (#/objectAtIndex: > (#/filenames op) 0)) > #@"/")))) > path))))))) > > > Joakim Sandgren > joakim sandgren musik > 42, rue de Maubeuge > 75009 Paris > France > +33 (0)1 45 26 43 90 > info at joakimsandgren.com > http://www.joakimsandgren.com > From joakim at joakimsandgren.com Sun May 3 13:39:49 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sun, 3 May 2009 22:39:49 +0200 Subject: [Openmcl-devel] default directory In-Reply-To: <20090503131930.Y4013@abq.clozure.com> References: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> <20090503131930.Y4013@abq.clozure.com> Message-ID: thank you gary, I did looked at the methods in the openNSPANEL class but I didnt find anything mentioning "directory"... but then i'm not at cocoa expert... (either..;-)) I will look at this and try to figure it out. it seems to me that easygui is a package that is made a little ad hoc, "for now", to resolve urgent needs now. and the gui package is part of the "real" cocoa communication in clozure ccl... and perhaps in a future better version the easygui will be obsolete but the gui package not... I am of course still waiting for some window functions in ccl, and for the moment being I dont know on wich horse I should bet... could someone enlighten me? Very Sincerely Joakim Le 3 mai 09 ? 22:15, Gary Byers a ?crit : > (#/runModalForTypes: panel ) > > is equivalent to: > > (#/runModalForDirectory:file:types: panel +null-ptr+ +null-ptr+ > ) > > As one would guess from the method name, the two extra arguments > accepted by the > second function are an NSString denoting an absolute directory name > and an NSString > denoting a file in that directory. So the general idea is: > > (defun choose-directory-dialog (&optional default-directory) > (execute-in-gui #'(lambda () > ... > (let* ((dirname (if default-directory > (#/autorelease > (ccl::%make-nsstring > (namestring (truename > default-directory)))) > +null-ptr+))) > ... > (when (eql (#/ > runModalForDirectory:file:types: > panel > dirname > +null-pointer+ > +null-pointer+) > #$NSOKButton) > ...))))) > > > > is actually a good description of the functionality that NSOpenPanel > offers; if > you have Xcode installed, a local copy of the reference > documentation is buried > somewhere inside the Xcode installation directory (usually / > Developer) someplace, > and you may be able to find it ... > > Since it hasn't been plugged for a while, this seems like a good > time to mention > AppKido (), > which is a good, > free (well, the author accepts donations via PayPal now) tool for > browsing a local > copy of the Cocoa documentation. > > On Sun, 3 May 2009, Joakim Sandgren wrote: > >> Hi, and thank you all for helping so much with my questions. >> here's another: >> based on the function choose-directory-dialog in the GUI package I >> have done another function adding some title strings, one for the >> panel one for the button. >> Now I would like to add the functionality that the panel opens in a >> default directory choosen by me. >> How do I do that? >> >> Sincerely >> >> Joakim >> >> >> (defun choose-directory-dialog () >> (execute-in-gui #'(lambda () >> (let ((op (#/openPanel ns:ns-open-panel))) >> (#/setAllowsMultipleSelection: op nil) >> (#/setCanChooseDirectories: op t) >> (#/setCanChooseFiles: op nil) >> (when (eql (#/runModalForTypes: op +null-ptr+) >> #$NSOKButton) >> ;; #/stringByStandardizingPath seems to >> strip trailing slashes >> (let* ((path (#/retain (#/ >> stringByAppendingString: >> (#/stringByStandardizingPath >> (#/objectAtIndex: (#/ >> filenames op) 0)) >> #@"/")))) >> path)))))) >> >> (defmethod choose-directory-dialog-with-strings ((dialogtitle >> string) (buttonstring string)) >> (gui::lisp-string-from-nsstring >> (gui::execute-in-gui #'(lambda () >> (let ((op (#/openPanel ns:ns-open-panel))) >> (#/setAllowsMultipleSelection: op nil) >> (#/setCanChooseDirectories: op t) >> (#/setCanChooseFiles: op nil) >> (#/setPrompt: op (ccl::%make-nsstring >> buttonstring)) >> (#/setTitle: op (ccl::%make-nsstring >> dialogtitle)) >> (when (eql (#/runModalForTypes: op +null- >> ptr+) #$NSOKButton) >> ;; #/stringByStandardizingPath seems >> to strip trailing slashes >> (let* ((path (#/retain (#/ >> stringByAppendingString: >> (#/ >> stringByStandardizingPath >> (#/ >> objectAtIndex: (#/filenames op) 0)) >> #@"/")))) >> path))))))) >> >> >> Joakim Sandgren >> joakim sandgren musik >> 42, rue de Maubeuge >> 75009 Paris >> France >> +33 (0)1 45 26 43 90 >> info at joakimsandgren.com >> http://www.joakimsandgren.com >> > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelcavallaro at mac.com Sun May 3 16:06:30 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sun, 03 May 2009 19:06:30 -0400 Subject: [Openmcl-devel] default directory In-Reply-To: References: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> <20090503131930.Y4013@abq.clozure.com> Message-ID: <414AC9C5-AE93-4693-8D27-E78F0BEEF514@mac.com> On May 3, 2009, at 4:39 PM, Joakim Sandgren wrote: > I am of course still waiting for some window functions in ccl, and > for the moment being I dont know on wich horse I should bet... > could someone enlighten me? Several options here: 1. use the cocoa bridge directly. as long as you keep to current clozure practices you code will continue to work. 2. use easygui which may or may not experience significant bit rot. 3. use alex repenning's lui. I've been doing 1 and 3, mostly 1 as 3 is relatively new. I avoided 2 because I'd already been doing 1 before 2 appeared. hth, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From rme at clozure.com Sun May 3 19:13:45 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Sun, 3 May 2009 22:13:45 -0400 Subject: [Openmcl-devel] Stream X is private to TTY-LISTENER In-Reply-To: References: <20090503121814.I4013@abq.clozure.com> Message-ID: <740328B9-89FA-460C-B3F6-A38280BC05CB@clozure.com> On May 3, 2009, at 2:53 PM, Leslie P. Polzer wrote: > > Gary Byers wrote: >> As noted in section 9.1.2 of the manual, > > My bad, that's an RTFM case then. > > I suspect that as CCL slowly becomes more popular for > web applications this might become a FAQ, though. Could be. I added an entry for this to http://trac.clozure.com/openmcl/wiki/FrequentlyAskedQuestions From rme at clozure.com Sun May 3 23:35:59 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 4 May 2009 02:35:59 -0400 Subject: [Openmcl-devel] default directory In-Reply-To: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> References: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> Message-ID: <26C17DA9-F41E-4AC9-B387-2BB6220FE3EA@clozure.com> On May 3, 2009, at 2:55 PM, Joakim Sandgren wrote: > Hi, and thank you all for helping so much with my questions. > here's another: > based on the function choose-directory-dialog in the GUI package I > have done another function adding some title strings, one for the > panel one for the button. > Now I would like to add the functionality that the panel opens in a > default directory choosen by me. > How do I do that? If you're running a trunk CCL, you can look at ccl:cocoa-ide;file- dialogs.lisp. Alternatively, you can look at it via the web: http://trac.clozure.com/openmcl/browser/trunk/source/cocoa-ide/file-dialogs.lisp At some point (soon) I think we need to decide on and document a stable API for dealing with file dialogs. This code is probably not a stable API, but it might give you some hints on how to use the Cocoa stuff directly. From rme at clozure.com Mon May 4 01:19:01 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 4 May 2009 04:19:01 -0400 Subject: [Openmcl-devel] default directory In-Reply-To: References: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> <20090503131930.Y4013@abq.clozure.com> Message-ID: <6D7F0D1D-23B7-495C-8ACC-852BAC24755D@clozure.com> On May 3, 2009, at 4:39 PM, Joakim Sandgren wrote: > it seems to me that easygui is a package that is made a little ad > hoc, "for now", to resolve urgent needs now. and the gui package is > part of the "real" cocoa communication in clozure ccl... > and perhaps in a future better version the easygui will be obsolete > but the gui package not... > > I am of course still waiting for some window functions in ccl, and > for the moment being I dont know on wich horse I should bet... At the moment, I find that I am more-or-less writing Objective-C code in Lisp. That is to say, I'm just using the Objective-C bridge directly. On the one hand, this is not so bad: it's certainly handy to be able to add and redefine Objective-C methods on-the-fly, and so forth. In some ways, it even feels pretty high-level. After a while you become desensitized to the #/callSomeMethod syntax and forget that you're calling foreign code (at least until you screw up and crash the lisp). On the other hand, you really need to know Cocoa pretty well in order to work like this. You have to understand various Cocoa conventions like naming, memory management, the model-view-controller pattern (ugh, I said "pattern"), threading issues, etc. I think we do need some sort of CLOS-y interface to Cocoa that abstracts out the need to worry about running stuff on the proper thread, takes care of appropriately retaining and releasing Objective- C objects, does something about the lisp string to NSString hassle, and so on. Easy GUI is an experiment in that direction. I am not using Easy GUI when developing code for the IDE, but I do hope that as we all get more experience programming Cocoa in CCL, we'll be able to identify and implement good abstractions for various aspects of Cocoa and put that code somewhere, whether that be Easy GUI or somewhere else. From joakim at joakimsandgren.com Mon May 4 02:18:56 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Mon, 4 May 2009 11:18:56 +0200 Subject: [Openmcl-devel] default directory In-Reply-To: <6D7F0D1D-23B7-495C-8ACC-852BAC24755D@clozure.com> References: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> <20090503131930.Y4013@abq.clozure.com> <6D7F0D1D-23B7-495C-8ACC-852BAC24755D@clozure.com> Message-ID: <0DA4AA56-68D1-484C-87F2-0218C7B45EC5@joakimsandgren.com> thank you for your thoughts!! it's exactly that. I am hesitating starting with the cocoa bridge and my own bad hacking functions to give me the visualizing windows I need in my composition environment... but if there will be a "better" or more lisp-y set of functions for cocoa windows in ccl this will be much better and probably worth waiting for. I do know a little of cocoa, I wrote 1 or 2 years ago a small visualizer app that showed spectrums read from a text file with a certain format from a Ircam app called audiosculpt. but thats all. and it was before obj-c 2.0 with garbage so I had to figure out the object counting as well. not fun. But after all I "love" cocoa but I need more time with it. (much more time). So, for the ccl development then, I wait a little more? for the window functions? I mean, I am still composing on my old power book G4 PPC in MCL 5.2 final 3 (from clozure) and all of my questions here is about porting my environement as soon as possible to the intel macbook pro... I found a midi package that works. Now the dialogs and directory stuff seemes to arrive. And finally the visualizers (I never did edit-able windows). In MCL I use find-click-view (or something like that) to inspect the object, bound to the view, in the inspector window. it would be good to be able to have the same functionality in my future clozure ccl windows... I can click in these fields with cmd, alt, ctrl shift key to have different content (like: go to pitch object, go to dynamics object, go to top level etc etc) Sincerely Joakim Le 4 mai 09 ? 10:19, R. Matthew Emerson a ?crit : > > On May 3, 2009, at 4:39 PM, Joakim Sandgren wrote: > >> it seems to me that easygui is a package that is made a little ad >> hoc, "for now", to resolve urgent needs now. and the gui package is >> part of the "real" cocoa communication in clozure ccl... >> and perhaps in a future better version the easygui will be obsolete >> but the gui package not... >> >> I am of course still waiting for some window functions in ccl, and >> for the moment being I dont know on wich horse I should bet... > > At the moment, I find that I am more-or-less writing Objective-C > code in Lisp. That is to say, I'm just using the Objective-C bridge > directly. On the one hand, this is not so bad: it's certainly > handy to be able to add and redefine Objective-C methods on-the-fly, > and so forth. In some ways, it even feels pretty high-level. After > a while you become desensitized to the #/callSomeMethod syntax and > forget that you're calling foreign code (at least until you screw up > and crash the lisp). > > On the other hand, you really need to know Cocoa pretty well in > order to work like this. You have to understand various Cocoa > conventions like naming, memory management, the model-view- > controller pattern (ugh, I said "pattern"), threading issues, etc. > > I think we do need some sort of CLOS-y interface to Cocoa that > abstracts out the need to worry about running stuff on the proper > thread, takes care of appropriately retaining and releasing > Objective-C objects, does something about the lisp string to > NSString hassle, and so on. > > Easy GUI is an experiment in that direction. I am not using Easy > GUI when developing code for the IDE, but I do hope that as we all > get more experience programming Cocoa in CCL, we'll be able to > identify and implement good abstractions for various aspects of > Cocoa and put that code somewhere, whether that be Easy GUI or > somewhere else. > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.tiff Type: image/tiff Size: 3139354 bytes Desc: not available URL: From sky at viridian-project.de Mon May 4 02:46:26 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Mon, 4 May 2009 11:46:26 +0200 (CEST) Subject: [Openmcl-devel] Stream X is private to TTY-LISTENER Message-ID: > Thanks. That's not my use case, but in return for stealing your > time with my issue I will amend the docs for RUN-PROGRAM. Patch attached. Leslie -- http://www.linkedin.com/in/polzer -------------- next part -------------- A non-text attachment was scrubbed... Name: doc_run-program_sharing-kwarg.diff Type: text/x-patch Size: 1410 bytes Desc: not available URL: From lisp at clairvaux.org Mon May 4 05:26:18 2009 From: lisp at clairvaux.org (Glen Foy) Date: Mon, 4 May 2009 08:26:18 -0400 Subject: [Openmcl-devel] default directory In-Reply-To: <6D7F0D1D-23B7-495C-8ACC-852BAC24755D@clozure.com> References: <519176E7-32C0-4558-9698-71ABD0B716FE@joakimsandgren.com> <20090503131930.Y4013@abq.clozure.com> <6D7F0D1D-23B7-495C-8ACC-852BAC24755D@clozure.com> Message-ID: <1C31A153-8783-43B6-AC81-67635D36E143@clairvaux.org> On May 4, 2009, at 4:19 AM, R. Matthew Emerson wrote: > I think we do need some sort of CLOS-y interface to Cocoa that > abstracts out the need to worry about running stuff on the proper > thread, takes care of appropriately retaining and releasing Objective- > C objects, does something about the lisp string to NSString hassle, > and so on. > > Easy GUI is an experiment in that direction. I am not using Easy GUI > when developing code for the IDE, but I do hope that as we all get > more experience programming Cocoa in CCL, we'll be able to identify > and implement good abstractions for various aspects of Cocoa and put > that code somewhere, whether that be Easy GUI or somewhere else. That sounds good to me, but I would argue that a more immediate need is better debugging support for Lisp code that is called from the Cocoa thread. Currently, if there is an error, we have no backtrace, other than a listing of the last objc function that was called, and no access to the inspector. If the callback code is complex, this is a real problem. Littering code with print statements is tedious and will only get you so far. I have have no idea how difficult it would be to add this, and rather suspect that if it was easy, it would already have been done. But it's sure would be nice. -Glen From joakim at joakimsandgren.com Tue May 5 01:15:48 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Tue, 5 May 2009 10:15:48 +0200 Subject: [Openmcl-devel] launch app Message-ID: <0BD2ED68-F447-4800-9AAD-FD720D54115A@joakimsandgren.com> in mcl I used: (#_lsopenfsref (ccl::make-fsref-from-path path) (%null-ptr)) to launch an application in the finder. how do I do this in clozure ccl? SIncerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Tue May 5 03:25:27 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 5 May 2009 04:25:27 -0600 (MDT) Subject: [Openmcl-devel] launch app In-Reply-To: <0BD2ED68-F447-4800-9AAD-FD720D54115A@joakimsandgren.com> References: <0BD2ED68-F447-4800-9AAD-FD720D54115A@joakimsandgren.com> Message-ID: <20090505024844.S33450@abq.clozure.com> The class that handles this sort of thing is NSWorkspace; like some other classes, there's a single, global instance (accessible via #/sharedWorkspace). When you searched for methods whose name contained the string "launch" in AppKido, did you find this ? (Or did you forget that AppKido has a search function ? Or ...) ? (#/launchApplication: (#/sharedWorkSpace ns:ns-workspace) #@"Safari") T ? (#/launchApplication: (#/sharedWorkspace ns:ns-workspace) #@"Bogus-application") NIL It seems that a lot of NSWorkspace methods only work in a "real" standalone .app (e.g., they don't work if you just do (require "COCOA")). Cocoa's huge. The good news is that you don't have to learn all of it (or even much of it) before doing anything. More good news: there are tools (including AppKido) that can help you to find what you're looking for. I didn't remember the name of the #/launchApplication: method (I think that I remembered that there were NSWorkspace methods that did this sort of thing) and had to look it up. If you don't know that sort of thing (have a pretty good idea of what class might support the functionality you're looking for), you might have to try other, broader approaches (like searching for "launch" and ignoring results that prove to be irrelevant.) That may seem like a lot of effort to go to to find a simple answer to a simple question, but a side-effect of that effort is that your model of how Cocoa is organized starts to get more complete (as you encounter more classes and methods and learn a little bit about them) and it starts to get easier to find things. (In other words, that effort is rewarded.) If you have questions about using Cocoa from CCL, it's certainly appropriate to ask them on this list. If you have questions about Cocoa that aren't really CCL-specific - like "what method does ___ ?" or "what does the method ___ do ?", there are probably better ways of getting answers (where "better" means, among other things, "makes better use of the time of everyone concerned.") On Tue, 5 May 2009, Joakim Sandgren wrote: > in mcl I used: > (#_lsopenfsref (ccl::make-fsref-from-path path) (%null-ptr)) > to launch an application in the finder. > how do I do this in clozure ccl? > > SIncerely > > Joakim > > > > Joakim Sandgren > joakim sandgren musik > 42, rue de Maubeuge > 75009 Paris > France > +33 (0)1 45 26 43 90 > info at joakimsandgren.com > http://www.joakimsandgren.com > > From sky at viridian-project.de Tue May 5 04:03:47 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 5 May 2009 13:03:47 +0200 (CEST) Subject: [Openmcl-devel] (SETF FIND-CLASS) Message-ID: I just noticed that CCL doesn't seem to register class aliases as types: ? (defclass foo nil nil) # ? (typep 5 'foo) NIL ? (setf (find-class 'bar) (find-class 'foo)) # ? (typep 5 'bar) > Error: Unknown type specifier: BAR But the spec (FIND-CLASS) says: Returns the class object named by the symbol in the environment. And in section 4.3.7, "Integrating Types and Classes": Every class that has a proper name has a corresponding type with the same name. This seems to be a pretty clear case to me, but I may be convinced of the converse. :) Leslie -- http://www.linkedin.com/in/polzer From sky at viridian-project.de Tue May 5 05:15:46 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 5 May 2009 14:15:46 +0200 (CEST) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <53123FBD-4DAB-41B2-8E13-40CD42056A57@setf.de> References: <53123FBD-4DAB-41B2-8E13-40CD42056A57@setf.de> Message-ID: <7b08eef6f40c23447ad8382edc9ae67b.squirrel@mail.stardawn.org> james anderson wrote: > http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_p.htm#proper_name Thanks, that was the missing bit. However: ? (defclass foo nil nil) # ? (setf (find-class 'bar) (find-class 'foo)) # ? (deftype bar () 'foo) > Error: Cannot redefine type BAR Now is BAR registered as a type by (SETF FIND-CLASS) or not? Thanks, Leslie -- http://www.linkedin.com/in/polzer From stoye at stoye.com Tue May 5 05:17:19 2009 From: stoye at stoye.com (R.Stoye) Date: Tue, 5 May 2009 14:17:19 +0200 Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: References: Message-ID: hi leslie, gary answered this question last year, see http://www.clozure.com/pipermail/openmcl-devel/2008-November/008695.html ralf From gb at clozure.com Tue May 5 05:25:35 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 05 May 2009 06:25:35 -0600 Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: References: Message-ID: ? (class-name (find-class 'bar)) FOO See the glossary entry for "proper name" in CLHS. See also which seems to be full of typos but is hopefully intelligible. If C is a class and S is a symbol, then I think that the spec says that the effect of (setf (find-class s) c) is to define S to be a type specifier (equivalent to C) if and only if (eq (class-name c) s) is also true; (SETF FIND-CLASS) checks for this in CCL and only defines S as a type specifier in that case. This interpretation seems pretty clear to me. (I'm willing to believe that there's something in the spec that contradicts that interpretation, but I can't find it and the preponderance of the evidence seems to support this interpretation.) All well and good, but it seems that many (most ? all ?) other implementations unconditionally define S to be a type-specifier whenever C is a class, and it may be true that most people expect this behavior. As noted in the earlier message, CCL's behavior would be more consistent if DEFTYPE also checked for proper-namedness (or the equivalent). --On May 5, 2009 1:03:47 PM +0200 "Leslie P. Polzer" wrote: > > I just noticed that CCL doesn't seem to register class aliases > as types: > > ? (defclass foo nil nil) ># > ? (typep 5 'foo) > NIL > ? (setf (find-class 'bar) (find-class 'foo)) ># > ? (typep 5 'bar) >> Error: Unknown type specifier: BAR > > But the spec (FIND-CLASS) says: > > Returns the class object named by the symbol in the environment. > > And in section 4.3.7, "Integrating Types and Classes": > > Every class that has a proper name has a corresponding type > with the same name. > > This seems to be a pretty clear case to me, but I may be > convinced of the converse. :) > > Leslie > > -- > http://www.linkedin.com/in/polzer > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From pc at p-cos.net Tue May 5 05:47:13 2009 From: pc at p-cos.net (Pascal Costanza) Date: Tue, 5 May 2009 14:47:13 +0200 Subject: [Openmcl-devel] CLOS: next-method-p doesn't work correctly Message-ID: <8612241B-ACAD-4EE8-AE47-2A8CF043056D@p-cos.net> Hi, See the following simple test method: (defmethod foo (x) (if (next-method-p) (call-next-method) (print x))) When I call foo with only this method defined, I get the following error: ? (foo 3) > Error: Fault during read of memory address #x120000300046 > While executing: CCL::%NEXT-METHOD-P, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > (lisp-implementation-version) "Version 1.3-r11936 (DarwinX8664)" Best, Pascal -- ELS'09: http://www.european-lisp-symposium.org/ Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Programming Technology Lab Artificial Intelligence Lab Pleinlaan 2, B-1050 Brussel, Belgium From sky at viridian-project.de Tue May 5 06:08:14 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 5 May 2009 15:08:14 +0200 (CEST) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: References: Message-ID: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> Thanks everyone for your explanations. I do believe that CCL's behaviour is correct now. Some more comments: > All well and good, but it seems that many (most ? > all ?) other implementations unconditionally define S to be a type-specifier > whenever C is a class, SBCL and ECL map all class names to types while CLISP only maps the proper name to a type. > As noted in the earlier message, CCL's behavior would be more consistent > if DEFTYPE also checked for proper-namedness (or the equivalent). Yes, indeed. I will try to enhance DEFTYPE's behavior in CCL. What do you mean by "or the equivalent"? Thanks again, Leslie -- http://www.linkedin.com/in/polzer From gb at clozure.com Tue May 5 06:29:03 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 5 May 2009 07:29:03 -0600 (MDT) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> Message-ID: <20090505071042.Y33450@abq.clozure.com> On Tue, 5 May 2009, Leslie P. Polzer wrote: > > >> As noted in the earlier message, CCL's behavior would be more consistent >> if DEFTYPE also checked for proper-namedness (or the equivalent). > > Yes, indeed. I will try to enhance DEFTYPE's behavior in CCL. > > What do you mean by "or the equivalent"? There's a (possibly slightly faster) way of determining that a symbol is a type specifier that (properly) names a class. (If it's any faster, that'd be because CLASS-NAME is a generic function.) Figuring that out (in general, mapping from a type specifier to a class or some other representation of a type) as quickly as possible is important for things like TYPEP and SUBTYPEP (when they couldn't do that simplification at compile-time), but we're talking about the expansion of DEFTYPE (CCL::%DEFTYPE) here ... That usually happens at load time and isn't much of a bottleneck, so the straightforward check for proper-namedness is fine here. > > Thanks again, > > Leslie > > -- > http://www.linkedin.com/in/polzer > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From raffaelcavallaro at mac.com Tue May 5 07:21:51 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Tue, 05 May 2009 10:21:51 -0400 Subject: [Openmcl-devel] launch app In-Reply-To: <20090505024844.S33450@abq.clozure.com> References: <0BD2ED68-F447-4800-9AAD-FD720D54115A@joakimsandgren.com> <20090505024844.S33450@abq.clozure.com> Message-ID: <1D9D7D55-F2A5-4AB1-8A10-CE437E899B4B@mac.com> On May 5, 2009, at 6:25 AM, Gary Byers wrote: > If you have questions about > Cocoa that aren't really CCL-specific - like "what method does ___ ?" > or "what does the method ___ do ?", there are probably better ways of > getting answers (where "better" means, among other things, "makes > better > use of the time of everyone concerned.") specifically, search in these places: 1. AppKiDo as Gary already suggested: 2. Xcode:Help:Documentation Whether you search on an API string, Title, or Full Text depends on what you're looking for. for example, with your question, If I select C++,ObjcC,JS,C only (instead of All Languages), API, and Contains (the broadest API search), enter "launch," and sort the results by language so that I'm only looking at the ObjC results, I see the launchApplication: method of NSWorkspace class near the top of the list. Clicking on that entry brings up the Apple Docs for the class and that method. 3. which is the searchable online archive of Apple's Cocoa-dev mailing list. 4. If these still don't get what you're looking for, sometimes you'll find that plain ol' google will. You should also consider joining Apple's cocoa-dev mailing list so you can ask cocoa-specific questions there if needed. This URL also contains a searchable archive of the cocoa-dev mailing list, but I find it less pleasant to use. warmest regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From dlw at itasoftware.com Tue May 5 08:20:52 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Tue, 05 May 2009 11:20:52 -0400 Subject: [Openmcl-devel] ENSURE-DIRECTORIES-EXIST and DIRECTORY on Windows In-Reply-To: <20090503040146.S97662@abq.clozure.com> References: <20090503040146.S97662@abq.clozure.com> Message-ID: <4A005954.5020201@itasoftware.com> By the way, in case anyone cares, SBCL sometimes calls ensure-directories-exist implicitly, where CCL does not. The language spec has nothing to say about it and I would have done it as CCL does. If you're porting from SBCL to CCL, you might have to add calls to ensure-directories-exist. Gary Byers wrote: > Yes, both of those functions were neglecting to handle > PATHNAME-DEVICE. D'oh! > > Thanks. > > On Sun, 3 May 2009, Martin wrote: > > >> Hi! >> >> First, I want to appreciate the work you have put into the Windows port >> of Clozure CL. Thanks. >> >> At the end of this mail is a patch which attempts to make CCL's >> DIRECTORY and ENSURE-DIRECTORIES-EXIST functions nicer on Windows. >> >> (I am using 1.3-r11949 on Windows XP SP2.) >> >> Most of the changes typically involve the addition of the :DEVICE >> component for to make the functions `drive aware'---if you will. >> >> For 1 and 2, the `context' is: >> >> ? (PATHNAME-DEVICE (CURRENT-DIRECTORY)) => C >> >> >> >> 1. >> >> ? (ENSURE-DIRECTORIES-EXIST "D:/dir1/dir2/") => creates "C:/dir1/dir2/" >> instead. >> >> >> >> 2. >> >> ? (DIRECTORY "D:/dir1/dir2/*.*") => NIL (despite having files in >> D:/dir1/dir2/). >> >> >> >> 3. I have a file tree with the following structure: >> >> D:. >> | init.bat >> | >> +---.dir2 >> | | .file3 >> | | file1.txt >> | | file2 >> | | >> | +---.dir1-2 >> | | .file5 >> | | file3.txt >> | | file4 >> | | >> | \---dir1-1 >> | .file3 >> | file1.txt >> | file2 >> | >> \---dir1 >> | .file3 >> | file1.txt >> | file2 >> | >> +---.dir1-2 >> | .file5 >> | file3.txt >> | file4 >> | >> \---dir1-1 >> .file3 >> file1.txt >> file2 >> >> >> ? (DIRECTORY #P"D:/sources/lang/lisp/ccl/tests/**/.dir2/" :directories t)) >> => >> '(#P"/sources/lang/lisp/ccl/tests/.dir2/" >> #P"/sources/lang/lisp/ccl/tests/.dir2/.dir2/" >> #P"/sources/lang/lisp/ccl/tests/.dir2/.dir1-2/.dir2/" >> #P"/sources/lang/lisp/ccl/tests/.dir2/dir1-1/.dir2/" >> #P"/sources/lang/lisp/ccl/tests/dir1/.dir2/" >> #P"/sources/lang/lisp/ccl/tests/dir1/.dir1-2/.dir2/" >> #P"/sources/lang/lisp/ccl/tests/dir1/dir1-1/.dir2/") >> >> If I understand the Spec well, I expected: >> #P"D:/sources/lang/lisp/ccl/tests/.dir2/" >> >> Regards, >> Martin. >> >> >> Patch: (In the expected format, I hope.) >> >> ;;; -------------------------------------------------- >> ;;; BOF >> >> >> >> --- pathnames.orig.lisp >> +++ pathnames.new.lisp >> @@ -231,4 +231,6 @@ >> argument." >> - (let* ((pathname (make-directory-pathname :directory >> (pathname-directory (translate-logical-pathname (merge-pathnames >> pathspec))))) >> - (created-p nil)) >> + (let ((pathname (let ((pathspec (translate-logical-pathname >> (merge-pathnames pathspec)))) >> + (make-directory-pathname :device (pathname-device pathspec) >> + :directory (pathname-directory pathspec)))) >> + (created-p nil)) >> (when (wild-pathname-p pathname) >> @@ -301,4 +303,9 @@ >> >> -(defmacro with-open-dir ((dirent dir) &body body) >> - `(let ((,dirent (%open-dir ,dir))) >> +(defun %path-cat (device dir subdir) >> + (if device >> + (%str-cat device ":" dir subdir) >> + (%str-cat dir subdir))) >> + >> +(defmacro with-open-dir ((dirent device dir) &body body) >> + `(let ((,dirent (%open-dir (namestring (make-pathname :device ,device >> :directory ,dir))))) >> (when ,dirent >> @@ -361,4 +368,7 @@ >> (defun %one-wild (dir wild rest path so-far keys) >> - (let ((result ()) (all (getf keys :all)) name subdir) >> - (with-open-dir (dirent dir) >> + (let ((result ()) >> + (device (pathname-device path)) >> + (all (getf keys :all)) >> + name) >> + (with-open-dir (dirent device dir) >> (while (setq name (%read-dir dirent)) >> @@ -368,4 +378,5 @@ >> (%path-pstr*= wild name) >> - (eq (%unix-file-kind (setq subdir (%str-cat dir name)) t) :directory)) >> - (let ((so-far (cons (%path-std-quotes name nil "/;:*") so-far))) >> + (eq (%unix-file-kind (%path-cat device dir name) t) :directory)) >> + (let ((subdir (%path-cat nil dir name)) >> + (so-far (cons (%path-std-quotes name nil "/;:*") so-far))) >> (declare (dynamic-extent so-far)) >> @@ -376,3 +387,4 @@ >> (defun %files-in-directory (dir path so-far keys) >> - (let ((name (pathname-name path)) >> + (let ((device (pathname-device path)) >> + (name (pathname-name path)) >> (type (pathname-type path)) >> @@ -388,9 +400,12 @@ >> (if (not (or name type)) >> - (when directories >> - (setq ans (if directory-pathnames >> - (%cons-pathname (reverse so-far) nil nil) >> - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) >> - (when (and ans (or (null test) (funcall test ans))) >> - (setq result (list ans)))) >> - (with-open-dir (dirent dir) >> + (let (full-path) >> + (when (and directories >> + (eq (%unix-file-kind (namestring (setq full-path (%cons-pathname >> (reverse so-far) nil nil nil device))) >> + t) >> + :directory)) >> + (setq ans (if directory-pathnames full-path >> + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil >> device))) >> + (when (and ans (or (null test) (funcall test ans))) >> + (setq result (list ans))))) >> + (with-open-dir (dirent (pathname-device path) dir) >> (while (setq sub (%read-dir dirent)) >> @@ -404,3 +419,3 @@ >> (setq ans >> - (if (eq (%unix-file-kind (%str-cat dir sub) t) :directory) >> + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) >> (when directories >> @@ -408,7 +423,7 @@ >> (if directory-pathnames >> - (%cons-pathname (reverse (cons std-sub so-far)) nil nil) >> - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) >> std-sub nil)))) >> + (%cons-pathname (reverse (cons std-sub so-far)) nil nil nil device) >> + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) >> std-sub nil nil device)))) >> (when files >> (multiple-value-bind (name type) (%std-name-and-type sub) >> - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name >> type))))) >> + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name >> type nil device))))) >> (when (and ans (or (null test) (funcall test ans))) >> @@ -421,2 +436,3 @@ >> (result nil) >> + (device (pathname-device path)) >> (name (pathname-name path)) >> @@ -427,3 +443,3 @@ >> (follow-links (getf keys :follow-links)) >> - sub subfile dir-list ans) >> + sub dir-list ans) >> ;; First process the case that the ** stands for 0 components >> @@ -446,4 +462,4 @@ >> (setq sub (if directory-pathnames >> - (%cons-pathname (setq dir-list (reverse so-far)) nil nil) >> - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) >> + (%cons-pathname (setq dir-list (reverse so-far)) nil nil nil >> device) >> + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil >> device))) >> (when (or (null test) (funcall test sub)) >> @@ -451,3 +467,3 @@ >> ; now descend doing %all-dirs on dirs and collecting files & dirs >> if do-x is t >> - (with-open-dir (dirent dir) >> + (with-open-dir (dirent device dir) >> (while (setq sub (%read-dir dirent)) >> @@ -456,4 +472,5 @@ >> (not (string= sub ".."))) >> - (if (eq (%unix-file-kind (setq subfile (%str-cat dir sub)) t) >> :directory) >> - (let* ((std-sub (%path-std-quotes sub nil "/;:*")) >> + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) >> + (let* ((subfile (%path-cat nil dir sub)) >> + (std-sub (%path-std-quotes sub nil "/;:*")) >> (so-far (cons std-sub so-far)) >> @@ -463,5 +480,5 @@ >> (setq ans (if directory-pathnames >> - (%cons-pathname (reverse so-far) nil nil) >> + (%cons-pathname (reverse so-far) nil nil nil device) >> (%cons-pathname (or dir-list (setq dir-list (reverse (cdr >> so-far)))) >> - std-sub nil))) >> + std-sub nil nil device))) >> (when (or (null test) (funcall test ans)) >> @@ -471,3 +488,3 @@ >> (multiple-value-bind (name type) (%std-name-and-type sub) >> - (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse >> so-far))) name type)) >> + (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse >> so-far))) name type nil device)) >> (when (or (null test) (funcall test ans)) >> >> >> >> ;;; EOF >> ;;; -------------------------------------------------- >> >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rme at clozure.com Tue May 5 10:29:28 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 5 May 2009 13:29:28 -0400 Subject: [Openmcl-devel] Floating point exceptions on Windows In-Reply-To: References: Message-ID: On May 3, 2009, at 11:18 AM, Martin wrote: > Hi! > > I am using CCL 1.3-r11949 on Windows XP SP2 and have a problem with > floating point exception propagation. > > Now, I have a file app1.c with a function with the following code > extract: > > > __declspec(dllexport) double fn1 () > { > double zero = 0; > return 1.0/zero; > } > > I compiled it into a DLL (Using MS Visual C++ 2005 Express Edition) > with > the following command: > > cl /LD app1.c > > to yield app1.dll. > > Using it in CCL: > > Welcome to Clozure Common Lisp Version 1.3-r11949M (WindowsX8632)! > ? (open-shared-library "D:/studies/floats/app1/app1.dll") > # > ? (ff-call (%reference-external-entry-point (external > "fn1")) :double-float) > 1.0000000000000002D0 > ? (log 10) >> Error: DIVISION-BY-ZERO detected >> performing LOG on (10.0) >> While executing: CCL::%FP-ERROR-FROM-STATUS, in process listener(1). >> Type :POP to abort, :R for a list of available restarts. >> Type :? for other options. > 1 > This is kind of a long shot, but...if you disassemble fn1(), does it use x87 or SSE2 instructions? On non-Darwin x8632 systems (including Windows), we assume that foreign code will use the x87 for floating-point operations. After the ff-call, we therefore will look at the x87 state to see if the foreign code signaled any fp exceptions. If the foreign code uses SS2E, we won't notice any exceptiopns (because we're looking for them in the wrong place: the x87 state, and not the mxcsr). > 2. How can I disable floating point exceptions from within CCL? The manual documents SET-FPU-MODE and GET-FPU-MODE, which will let you do this. http://ccl.clozure.com/ccl-documentation.html#floating-point From rme at clozure.com Tue May 5 10:37:54 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 5 May 2009 13:37:54 -0400 Subject: [Openmcl-devel] Stream X is private to TTY-LISTENER In-Reply-To: References: Message-ID: On May 4, 2009, at 5:46 AM, Leslie P. Polzer wrote: >> Thanks. That's not my use case, but in return for stealing your >> time with my issue I will amend the docs for RUN-PROGRAM. > > Patch attached. Applied. Thank you. From gb at clozure.com Tue May 5 16:27:14 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 5 May 2009 17:27:14 -0600 (MDT) Subject: [Openmcl-devel] Floating point exceptions on Windows In-Reply-To: References: Message-ID: <20090505160925.J33450@abq.clozure.com> For some reason, I didn't see the original message. I also have to confess to being (willfully and otherwise) x87-ignorant, so some of the details below m x87 exceptions generally aren't precise, which means that they'll be raised sometime after they occur (on some subsequent x87 instruction; an "fwait" instruction waits for the x87 to actually bother to update its status word to reflect the actual exception status of the chip. This makes for a good theory: fn1() executes some sort of "fdiv" which causes a divide-by-zero but doesn't update the status word. We return from the call to fn1(), see no exception bits in the status word, and chug merrily along. A subsequent call to log() does some x87 instruction which (finally) causes the status word to be updated; we return from the call to log, notice that the divide-by-zero bit is set, and report the error. That sounds like a good theory, but it may not be a correct one: I'm fairly sure that we'd want to use MMX instructions between the return from fn1() and the call to log(), and my (too lazy to RTFM) model of how the x87 and MMX try to coexist is that using MMX basically clears x87 state. (If that's not correct, or if the x87 status word is preserved, then the theory's still good.) If there's at least something to the theory, then it seems that we want to change .SPffcall to: - if we believe that the foreign code will use x87 math operations, ensure that the x87 status word is zeroed before the call. (We may not have to do anything explicit here.) - on return from the call, if we think that the x87 might have been involved, do the right flavor of "fwait" before reading the status word and putting its value where lisp can find it. If we can tell that any exception bits might have been set, zero the x87 status register. If we can convince ourselves that lisp's incidental use of the x87 can never cause an exception bit to be set, then zeroing the status register here might be enough to ensure that it's always zero on entry to the foreign code. On Tue, 5 May 2009, R. Matthew Emerson wrote: > > On May 3, 2009, at 11:18 AM, Martin wrote: > >> Hi! >> >> I am using CCL 1.3-r11949 on Windows XP SP2 and have a problem with >> floating point exception propagation. >> >> Now, I have a file app1.c with a function with the following code >> extract: >> >> >> __declspec(dllexport) double fn1 () >> { >> double zero = 0; >> return 1.0/zero; >> } >> >> I compiled it into a DLL (Using MS Visual C++ 2005 Express Edition) >> with >> the following command: >> >> cl /LD app1.c >> >> to yield app1.dll. >> >> Using it in CCL: >> >> Welcome to Clozure Common Lisp Version 1.3-r11949M (WindowsX8632)! >> ? (open-shared-library "D:/studies/floats/app1/app1.dll") >> # >> ? (ff-call (%reference-external-entry-point (external >> "fn1")) :double-float) >> 1.0000000000000002D0 >> ? (log 10) >>> Error: DIVISION-BY-ZERO detected >>> performing LOG on (10.0) >>> While executing: CCL::%FP-ERROR-FROM-STATUS, in process listener(1). >>> Type :POP to abort, :R for a list of available restarts. >>> Type :? for other options. >> 1 > > > This is kind of a long shot, but...if you disassemble fn1(), does it > use x87 or SSE2 instructions? > > On non-Darwin x8632 systems (including Windows), we assume that > foreign code will use the x87 for floating-point operations. After > the ff-call, we therefore will look at the x87 state to see if the > foreign code signaled any fp exceptions. If the foreign code uses > SS2E, we won't notice any exceptiopns (because we're looking for them > in the wrong place: the x87 state, and not the mxcsr). > >> 2. How can I disable floating point exceptions from within CCL? > > The manual documents SET-FPU-MODE and GET-FPU-MODE, which will let you > do this. > > http://ccl.clozure.com/ccl-documentation.html#floating-point > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From gb at clozure.com Tue May 5 16:47:50 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 5 May 2009 17:47:50 -0600 (MDT) Subject: [Openmcl-devel] CLOS: next-method-p doesn't work correctly In-Reply-To: <8612241B-ACAD-4EE8-AE47-2A8CF043056D@p-cos.net> References: <8612241B-ACAD-4EE8-AE47-2A8CF043056D@p-cos.net> Message-ID: <20090505174705.G33450@abq.clozure.com> Yuck; should be fixed in 1.3 and the trunk as of r12000. Thanks! On Tue, 5 May 2009, Pascal Costanza wrote: > Hi, > > See the following simple test method: > > (defmethod foo (x) > (if (next-method-p) > (call-next-method) > (print x))) > > When I call foo with only this method defined, I get the following > error: > > ? (foo 3) > > Error: Fault during read of memory address #x120000300046 > > While executing: CCL::%NEXT-METHOD-P, in process listener(1). > > Type :POP to abort, :R for a list of available restarts. > > Type :? for other options. > 1 > (lisp-implementation-version) > "Version 1.3-r11936 (DarwinX8664)" > > > Best, > Pascal > > -- > ELS'09: http://www.european-lisp-symposium.org/ > > Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net > Vrije Universiteit Brussel > Programming Technology Lab > Artificial Intelligence Lab > Pleinlaan 2, B-1050 Brussel, Belgium > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From gb at clozure.com Tue May 5 20:01:43 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 5 May 2009 21:01:43 -0600 (MDT) Subject: [Openmcl-devel] Floating point exceptions on Windows In-Reply-To: <20090505160925.J33450@abq.clozure.com> References: <20090505160925.J33450@abq.clozure.com> Message-ID: <20090505202544.M33450@abq.clozure.com> On Tue, 5 May 2009, Gary Byers wrote: [ramblings] After R'ing TFM and spending a little quality time with GDB, I think that I understand what's going on here (and, FWIW, it doesn't seem to be Windows-specific.) Some things that my earlier reply was confused about: - FF-CALL doesn't check to see if FP exceptions happened during the call; what it generally tries to do is store the FP exception status in thread-local storage after the call and ensure that the call is entered with the FP exception status zeroed. The code that does this originally assumed that SSE2 was used for all FP math; that's true on Darwin and on x86-64, but is not true on non-Darwin x86-32 platforms. If we're running on a platform where we can't assume that SSE2 is used for math library routines (the constant SSE2_MATH_LIB is undefined), we store the x87 status word (rather than the SSE2 mxcsr) in thread-local memory; we never do anything to clear the x87 status word. We assume that the foreign function is executed with all FP exceptions "masked" (e.g., marked in the control register to not cause a trap when they occur; we save and restore the thread's lisp FP exception mask around the FF-CALL. On return from a foreign function call to a math library routine (used to implement a CL math function), we check to see if any exception bits (in the thread-local-storage word) are set that correspond to unmasked exceptions in the thread's lisp FP exception mask; this is done using some fairly ugly undocumented internal functions. If an exception that would have caused a trap if it were unmasked occurred, we signal a lisp error. - x87 FP exceptions are indeed imprecise, but what this means is that the trap that would be taken on an unmasked FP exception doesn't take place immediately, buy the x87 status word is updated. An "fwait" instruction can be used to force the trap associated with a pending unmasked x87 exception to be taken, but that doesn't have much to do with the masked-exception-during-FF-CALL case. - what the test case (which can be reproduced under Linux) seems to show is that we're just neglecting to clear the x87 status word when we save its value in thread-local storage after returning from the call. Nothing that we do (use of MMX, etc.) seems to clear the status word, so we report a leftover FP exception when we finally do something (LOG) that actually checks to see if an FP exception happened during the most recent FF-CALL. If we clear the exception bits in the status word (via "fclex") after saving it in the non SSE2_MATH_LIB case, the problem seems to go away. From martin.lisp at gmail.com Wed May 6 00:20:50 2009 From: martin.lisp at gmail.com (Martin) Date: Wed, 06 May 2009 10:20:50 +0300 Subject: [Openmcl-devel] Floating point exceptions on Windows In-Reply-To: References: Message-ID: (I had sent this reply earlier, but it seems to have been copied only to R. Matthew Emerson. Apologies if it appears multiple times in the list.) R. Matthew Emerson wrote: > On May 3, 2009, at 11:18 AM, Martin wrote: > >> Hi! >> >> I am using CCL 1.3-r11949 on Windows XP SP2 and have a problem with >> floating point exception propagation. >> >> Now, I have a file app1.c with a function with the following code >> extract: >> >> >> __declspec(dllexport) double fn1 () >> { >> double zero = 0; >> return 1.0/zero; >> } >> >> I compiled it into a DLL (Using MS Visual C++ 2005 Express Edition) >> with >> the following command: >> >> cl /LD app1.c >> >> to yield app1.dll. >> >> Using it in CCL: >> >> Welcome to Clozure Common Lisp Version 1.3-r11949M (WindowsX8632)! >> ? (open-shared-library "D:/studies/floats/app1/app1.dll") >> # >> ? (ff-call (%reference-external-entry-point (external >> "fn1")) :double-float) >> 1.0000000000000002D0 >> ? (log 10) >>> Error: DIVISION-BY-ZERO detected >>> performing LOG on (10.0) >>> While executing: CCL::%FP-ERROR-FROM-STATUS, in process listener(1). >>> Type :POP to abort, :R for a list of available restarts. >>> Type :? for other options. >> 1 > > > This is kind of a long shot, but...if you disassemble fn1(), does it > use x87 or SSE2 instructions? > fn1() seems to be using x87 instructions. (I don't know much assembly myself---actually trying to learn at least for to be able to read compiler sources.) Regardless: Compiling app1.c with the assembly output option, _fn1() compiles to: _fn1 PROC push ebp mov ebp, esp sub esp, 8 fldz fstp QWORD PTR _zero$[ebp] fld1 fdiv QWORD PTR _zero$[ebp] mov esp, ebp pop ebp ret 0 _fn1 ENDP (A disassembly of fn1() in the compiled DLL shows the same code sequence.) ( Compiling with the /arch:SSE2 flag added yields: _fn1 PROC push ebp mov ebp, esp sub esp, 8 movsd xmm0, QWORD PTR __real at 0000000000000000 movsd QWORD PTR _zero$[ebp], xmm0 fld1 fdiv QWORD PTR _zero$[ebp] mov esp, ebp pop ebp ret 0 _fn1 ENDP So, I suspect my conclusion is correct. ) > On non-Darwin x8632 systems (including Windows), we assume that > foreign code will use the x87 for floating-point operations. After > the ff-call, we therefore will look at the x87 state to see if the > foreign code signaled any fp exceptions. If the foreign code uses > SS2E, we won't notice any exceptiopns (because we're looking for them > in the wrong place: the x87 state, and not the mxcsr). > >> 2. How can I disable floating point exceptions from within CCL? > > The manual documents SET-FPU-MODE and GET-FPU-MODE, which will let you > do this. > > http://ccl.clozure.com/ccl-documentation.html#floating-point Thanks. I hadn't thought to search the manual and/or sources. Just tried can now disable signaling. Regards, Martin. From sky at viridian-project.de Wed May 6 00:32:39 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 6 May 2009 09:32:39 +0200 (CEST) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <20090505071042.Y33450@abq.clozure.com> References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> <20090505071042.Y33450@abq.clozure.com> Message-ID: <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> Gary Byers wrote: > There's a (possibly slightly faster) way of determining that a symbol > is a type specifier that (properly) names a class. (If it's any faster, > that'd be because CLASS-NAME is a generic function.) > > Figuring that out (in general, mapping from a type specifier to a > class or some other representation of a type) as quickly as possible > is important for things like TYPEP and SUBTYPEP (when they couldn't do > that simplification at compile-time), but we're talking about the > expansion of DEFTYPE (CCL::%DEFTYPE) here ... That usually happens at > load time and isn't much of a bottleneck, so the straightforward check > for proper-namedness is fine here. CCL already has proper name handling (not in DEFTYPE though), but I think it might be flawed. CLHS's definition of a proper name: If S is a symbol such that S = (class-name C) and C = (find-class S), then S is the proper name of C. So since CLASS-NAME is redefinable by the user there's no way to circumvent the check against it (except if we were to watch and record any redefinition of it, obviously). But the current proper name framework (%class-proper-name, update-class-proper-names) does not honor this relationship and just manages the proper name via FIND-CLASS and its setter, storing it in an internal class slot. We should probably first get rid of the current code and replace it with something like this: (defun %proper-name (class) "Return the proper name of a class or NIL if there's no proper name." (let ((name (class-name class))) (when (eq (find-class name nil) name) name))) (defun %proper-name-p (name class) (and class (eq name (%proper-name class)))) Later we can think about a caching mechanism for this if it turns out to be important. Leslie -- http://www.linkedin.com/in/polzer From gb at clozure.com Wed May 6 04:29:52 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 6 May 2009 05:29:52 -0600 (MDT) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> <20090505071042.Y33450@abq.clozure.com> <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> Message-ID: <20090506035137.W33450@abq.clozure.com> On Wed, 6 May 2009, Leslie P. Polzer wrote: > > Gary Byers wrote: > >> There's a (possibly slightly faster) way of determining that a symbol >> is a type specifier that (properly) names a class. (If it's any faster, >> that'd be because CLASS-NAME is a generic function.) >> >> Figuring that out (in general, mapping from a type specifier to a >> class or some other representation of a type) as quickly as possible >> is important for things like TYPEP and SUBTYPEP (when they couldn't do >> that simplification at compile-time), but we're talking about the >> expansion of DEFTYPE (CCL::%DEFTYPE) here ... That usually happens at >> load time and isn't much of a bottleneck, so the straightforward check >> for proper-namedness is fine here. > > CCL already has proper name handling (not in DEFTYPE though), but I > think it might be flawed. I wasn't even thinking of that, just changing the: ((and *type-system-initialized* (or (built-in-type-p name) (find-class name nil))) (error "Cannot redefine type ~S" name)) clause in CCL::%DEFTYPE to: ((and *type-system-initialized* (or (built-in-type-p name) (let* ((c (find-class name nil))) (and c (eq name (class-name c)))))) (error "Cannot redefine type ~S" name)) > > CLHS's definition of a proper name: > > If S is a symbol such that S = (class-name C) and C = (find-class S), > then S is the proper name of C. > > So since CLASS-NAME is redefinable by the user there's no way > to circumvent the check against it (except if we were to watch > and record any redefinition of it, obviously). The function (SETF CLASS-NAME) happens to be implemented as a generic function in CCL; there's one method, specialized on the classes T and CLASS. The primary method on (SETF CLASS-NAME) uses (SETF CCL::%CLASS-PROPER-NAME) to update the internal proper-name slot. (It's defined around line 1700 in "ccl/level-1/l1-clos.lisp".) That method also worries about whether the name's status as a type specifier changes and whether that conflicts with type specifiers defined with DEFTYPE. User code can certainly call (SETF CLASS-NAME) to change a class's name at any time, and doing so affects whether or not the class is properly named. As far as I know, the cached proper-name slot is maintained correctly. I'm not sure that I believe that users can portably redefine what (SETF CLASS-NAME) does, though since it's a generic function in CCL they can probably define methods that're specialized to metaclasses that they've defined (unless/until (SETF CLASS-NAME) changes into a non-generic function.) If someone defined such a method, I'm not sure that I'm too concerned about what'd happen if they neglected to call the primary method. CLASS-NAME can more plausibly be redefined by the user, but (SETF CLASS-NAME) doesn't need to know anything about how CLASS-NAME is implemented: it just does (REINITIALIZE-INSTANCE class :NAME name). The MOP says that CLASS-NAME returns the defaulted value of the :NAME initarg; it doesn't say what happens if it returns something else, or if it's non-deterministic: (defmethod class-name ((c my-metaclass)) (case (day-of-week) ...)) and, to be honest, it hurts my head just to think about that ... So, I think that it's fairly safe to predict that (SETF (CLASS-NAME CLASS) NAME) will cause subsequent calls to (CLASS-NAME CLASS) to return NAME, and to exploit that to cache info about the class's proper name. (The whole point of maintaining that cached info is, IIRC, to speed up some cases of TYPE-OF, which are supposed to return a class name if the argument's class is properly named and the class itself otherwise; an application that made heavy use of the idiom: ;;; It's possible that (TYPEP X 'FOO) was intended in many cases, ;;; but it's not exactly the same thing and hard to know. (eq (type-of x) 'foo) was spending a lot of time in FIND-CLASS and CLASS-NAME, and the cached internal PROPER-NAME slot eliminated that overhead.) > > But the current proper name framework (%class-proper-name, > update-class-proper-names) does not honor this relationship > and just manages the proper name via FIND-CLASS and its setter, > storing it in an internal class slot. > > We should probably first get rid of the current code > and replace it with something like this: > > (defun %proper-name (class) > "Return the proper name of a class or NIL if there's no proper name." > (let ((name (class-name class))) > (when (eq (find-class name nil) name) > name))) > > (defun %proper-name-p (name class) > (and class (eq name (%proper-name class)))) > > Later we can think about a caching mechanism for this if it > turns out to be important. It is important (in some contexts), and AFAIK the cached info is maintained correctly. > > Leslie > > -- > http://www.linkedin.com/in/polzer > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From sky at viridian-project.de Wed May 6 04:55:24 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 6 May 2009 13:55:24 +0200 (CEST) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <20090506035137.W33450@abq.clozure.com> References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> <20090505071042.Y33450@abq.clozure.com> <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> <20090506035137.W33450@abq.clozure.com> Message-ID: <1609000effd9584000666ce974818403.squirrel@mail.stardawn.org> Gary Byers wrote: > The primary method on (SETF CLASS-NAME) uses (SETF CCL::%CLASS-PROPER-NAME) > to update the internal proper-name slot. (It's defined around line 1700 > in "ccl/level-1/l1-clos.lisp".) That method also worries about whether > the name's status as a type specifier changes and whether that conflicts > with type specifiers defined with DEFTYPE. I'm not sure to what extent it influences the callers of CCL::%CLASS-PROPER-NAME but its behavior does not match the spec definition of a proper name: ? (defclass foo nil nil) # ? (defmethod class-name ((class (eql (find-class 'foo)))) 'zoo) #))> ? (ccl::%class-proper-name (find-class 'foo)) FOO It should probably return NIL instead of FOO after the redefinition of CLASS-NAME. With a grain of salt, of course -- it's an internal function and thus is not directly affected by the spec. Leslie -- http://www.linkedin.com/in/polzer From gb at clozure.com Wed May 6 06:14:34 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 6 May 2009 07:14:34 -0600 (MDT) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <1609000effd9584000666ce974818403.squirrel@mail.stardawn.org> References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> <20090505071042.Y33450@abq.clozure.com> <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> <20090506035137.W33450@abq.clozure.com> <1609000effd9584000666ce974818403.squirrel@mail.stardawn.org> Message-ID: <20090506060221.V39353@abq.clozure.com> On Wed, 6 May 2009, Leslie P. Polzer wrote: > > Gary Byers wrote: > >> The primary method on (SETF CLASS-NAME) uses (SETF CCL::%CLASS-PROPER-NAME) >> to update the internal proper-name slot. (It's defined around line 1700 >> in "ccl/level-1/l1-clos.lisp".) That method also worries about whether >> the name's status as a type specifier changes and whether that conflicts >> with type specifiers defined with DEFTYPE. > > I'm not sure to what extent it influences the callers of > CCL::%CLASS-PROPER-NAME but its behavior does not match the > spec definition of a proper name: > > ? (defclass foo nil nil) > # > ? (defmethod class-name ((class (eql (find-class 'foo)))) 'zoo) I liked my (defmethod class-name (...) (case (day-of-week) ...)) example of a pathological case better, but sure. The MOP says that the generic function CLASS-NAME returns "the defaulted value of the :name initialization argument that was associated with the class during initialization or reinitialization." It also says that: "Portable programs may define methods that extend specified methods unless the description of the specified method explicitly prohibits this. Unless there is a specific statement to the contrary, these extending methods must return whatever value was returned by the call to call-next-method." So, something like: (defvar *class-name-foo-calls* 0) (defmethod class-name ((class (eql (find-class 'foo)))) (incf *class-name-foo-calls*) (call-next-method)) seems to be something that a portable program can reliably do; I'm not sure that either of our examples qualify, and suspect that some other aspects of class (re)definition could break if standard class reader methods are "overridden" (rather than "extended"). We'd probably both agree that anyone who does something like: (defmethod class-direct-superclasses ((class (eql (find-class 'pathological)))) 17) deserves whatever happens, and we can only hope that whatever happens happens at fairly high safety. I can't see any more reason to be concerned about the effects of a non-extending specialization of CLASS-NAME: even if a case like your example is probably relatively benign, it's just "not what CLASS-NAME is supposed to do." From james.anderson at setf.de Wed May 6 06:31:50 2009 From: james.anderson at setf.de (james anderson) Date: Wed, 6 May 2009 15:31:50 +0200 Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <20090506035137.W33450@abq.clozure.com> References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> <20090505071042.Y33450@abq.clozure.com> <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> <20090506035137.W33450@abq.clozure.com> Message-ID: <980BF3F5-88D4-4B16-B4FF-89521D864A91@setf.de> On 2009-05-06, at 13:29 , Gary Byers wrote: > > ... >> >> CLHS's definition of a proper name: >> >> If S is a symbol such that S = (class-name C) and C = (find-class >> S), >> then S is the proper name of C. >> >> So since CLASS-NAME is redefinable by the user there's no way >> to circumvent the check against it (except if we were to watch >> and record any redefinition of it, obviously). > > The function (SETF CLASS-NAME) happens to be implemented as a generic > function in CCL; which is not just happenstance: http://www.lispworks.com/ documentation/HyperSpec/Body/f_opsetf.htm > there's one method, specialized on the classes T and CLASS. > > The primary method on (SETF CLASS-NAME) uses (SETF CCL::%CLASS- > PROPER-NAME) > to update the internal proper-name slot. (It's defined around line > 1700 > in "ccl/level-1/l1-clos.lisp".) That method also worries about > whether > the name's status as a type specifier changes and whether that > conflicts > with type specifiers defined with DEFTYPE. > > User code can certainly call (SETF CLASS-NAME) to change a class's > name > at any time, and doing so affects whether or not the class is properly > named. As far as I know, the cached proper-name slot is maintained > correctly. > > I'm not sure that I believe that users can portably redefine what > (SETF CLASS-NAME) does, such a method is conformant, so long as it is not specialized on a standardized class. ... From rme at clozure.com Wed May 6 09:10:38 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Wed, 6 May 2009 12:10:38 -0400 Subject: [Openmcl-devel] Floating point exceptions on Windows In-Reply-To: <20090505202544.M33450@abq.clozure.com> References: <20090505160925.J33450@abq.clozure.com> <20090505202544.M33450@abq.clozure.com> Message-ID: On May 5, 2009, at 11:01 PM, Gary Byers wrote: > If we clear the exception bits in the status word (via "fclex") > after saving > it in the non SSE2_MATH_LIB case, the problem seems to go away. I hope I'm not belaboring the point too much, but I wanted to mention that this fix is in both the 1.3 branch and in the trunk now. Please svn update and rebuild the lisp in the usual way. http://trac.clozure.com/openmcl/wiki/UpdatingFromSource I checked in new Windows lisp kernel binaries to the 1.3 branch, so that you don't have Cygwin and gcc installed to get the fix. From sky at viridian-project.de Wed May 6 09:18:10 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 6 May 2009 18:18:10 +0200 (CEST) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: <20090506060221.V39353@abq.clozure.com> References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> <20090505071042.Y33450@abq.clozure.com> <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> <20090506035137.W33450@abq.clozure.com> <1609000effd9584000666ce974818403.squirrel@mail.stardawn.org> <20090506060221.V39353@abq.clozure.com> Message-ID: Gary Byers wrote: > We'd probably both agree that anyone who does something like: > > (defmethod class-direct-superclasses ((class (eql (find-class 'pathological)))) > 17) > > deserves whatever happens, and we can only hope that whatever happens > happens at fairly high safety. I can't see any more reason to be concerned > about the effects of a non-extending specialization of CLASS-NAME: even > if a case like your example is probably relatively benign, it's just "not > what CLASS-NAME is supposed to do." I'm not sure I agree to the first part (because we should at least warn users who do something like that), but let's put it at rest until someone actually comes up with a pathological case like this. As for the original matter I'm going to extend %DEFTYPE in the straight-forward way, write a test for it and wrap it up. Leslie -- http://www.linkedin.com/in/polzer From sky at viridian-project.de Wed May 6 10:07:21 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 6 May 2009 19:07:21 +0200 (CEST) Subject: [Openmcl-devel] (SETF FIND-CLASS) In-Reply-To: References: <2a359490c4c3628f59869cbe6311df81.squirrel@mail.stardawn.org> <20090505071042.Y33450@abq.clozure.com> <15c08da96fefb161f070ca297e661537.squirrel@mail.stardawn.org> <20090506035137.W33450@abq.clozure.com> <1609000effd9584000666ce974818403.squirrel@mail.stardawn.org> <20090506060221.V39353@abq.clozure.com> Message-ID: <1f5d7e6532767ac3602d79cacac8c000.squirrel@mail.stardawn.org> Leslie P. Polzer wrote: > As for the original matter I'm going to extend %DEFTYPE in the > straight-forward way, write a test for it and wrap it up. Attached. -- http://www.linkedin.com/in/polzer -------------- next part -------------- A non-text attachment was scrubbed... Name: deftype-handle-proper-class-name.diff Type: text/x-patch Size: 649 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test-proper-class-name.diff Type: text/x-patch Size: 1173 bytes Desc: not available URL: From dlw at itasoftware.com Wed May 6 10:56:58 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Wed, 06 May 2009 13:56:58 -0400 Subject: [Openmcl-devel] ENSURE-DIRECTORIES-EXIST and DIRECTORY on Windows In-Reply-To: <4A005954.5020201@itasoftware.com> References: <20090503040146.S97662@abq.clozure.com> <4A005954.5020201@itasoftware.com> Message-ID: <4A01CF6A.9060006@itasoftware.com> Oops, I mean CCL sometimes does, whereas SBCL never does. Sorry. -- Dan Dan Weinreb wrote: > By the way, in case anyone cares, SBCL sometimes > calls ensure-directories-exist implicitly, where CCL > does not. The language spec has nothing to say > about it and I would have done it as CCL does. > If you're porting from SBCL to CCL, you might > have to add calls to ensure-directories-exist. > > > Gary Byers wrote: >> Yes, both of those functions were neglecting to handle >> PATHNAME-DEVICE. D'oh! >> >> Thanks. >> >> On Sun, 3 May 2009, Martin wrote: >> >> >>> Hi! >>> >>> First, I want to appreciate the work you have put into the Windows port >>> of Clozure CL. Thanks. >>> >>> At the end of this mail is a patch which attempts to make CCL's >>> DIRECTORY and ENSURE-DIRECTORIES-EXIST functions nicer on Windows. >>> >>> (I am using 1.3-r11949 on Windows XP SP2.) >>> >>> Most of the changes typically involve the addition of the :DEVICE >>> component for to make the functions `drive aware'---if you will. >>> >>> For 1 and 2, the `context' is: >>> >>> ? (PATHNAME-DEVICE (CURRENT-DIRECTORY)) => C >>> >>> >>> >>> 1. >>> >>> ? (ENSURE-DIRECTORIES-EXIST "D:/dir1/dir2/") => creates "C:/dir1/dir2/" >>> instead. >>> >>> >>> >>> 2. >>> >>> ? (DIRECTORY "D:/dir1/dir2/*.*") => NIL (despite having files in >>> D:/dir1/dir2/). >>> >>> >>> >>> 3. I have a file tree with the following structure: >>> >>> D:. >>> | init.bat >>> | >>> +---.dir2 >>> | | .file3 >>> | | file1.txt >>> | | file2 >>> | | >>> | +---.dir1-2 >>> | | .file5 >>> | | file3.txt >>> | | file4 >>> | | >>> | \---dir1-1 >>> | .file3 >>> | file1.txt >>> | file2 >>> | >>> \---dir1 >>> | .file3 >>> | file1.txt >>> | file2 >>> | >>> +---.dir1-2 >>> | .file5 >>> | file3.txt >>> | file4 >>> | >>> \---dir1-1 >>> .file3 >>> file1.txt >>> file2 >>> >>> >>> ? (DIRECTORY #P"D:/sources/lang/lisp/ccl/tests/**/.dir2/" :directories t)) >>> => >>> '(#P"/sources/lang/lisp/ccl/tests/.dir2/" >>> #P"/sources/lang/lisp/ccl/tests/.dir2/.dir2/" >>> #P"/sources/lang/lisp/ccl/tests/.dir2/.dir1-2/.dir2/" >>> #P"/sources/lang/lisp/ccl/tests/.dir2/dir1-1/.dir2/" >>> #P"/sources/lang/lisp/ccl/tests/dir1/.dir2/" >>> #P"/sources/lang/lisp/ccl/tests/dir1/.dir1-2/.dir2/" >>> #P"/sources/lang/lisp/ccl/tests/dir1/dir1-1/.dir2/") >>> >>> If I understand the Spec well, I expected: >>> #P"D:/sources/lang/lisp/ccl/tests/.dir2/" >>> >>> Regards, >>> Martin. >>> >>> >>> Patch: (In the expected format, I hope.) >>> >>> ;;; -------------------------------------------------- >>> ;;; BOF >>> >>> >>> >>> --- pathnames.orig.lisp >>> +++ pathnames.new.lisp >>> @@ -231,4 +231,6 @@ >>> argument." >>> - (let* ((pathname (make-directory-pathname :directory >>> (pathname-directory (translate-logical-pathname (merge-pathnames >>> pathspec))))) >>> - (created-p nil)) >>> + (let ((pathname (let ((pathspec (translate-logical-pathname >>> (merge-pathnames pathspec)))) >>> + (make-directory-pathname :device (pathname-device pathspec) >>> + :directory (pathname-directory pathspec)))) >>> + (created-p nil)) >>> (when (wild-pathname-p pathname) >>> @@ -301,4 +303,9 @@ >>> >>> -(defmacro with-open-dir ((dirent dir) &body body) >>> - `(let ((,dirent (%open-dir ,dir))) >>> +(defun %path-cat (device dir subdir) >>> + (if device >>> + (%str-cat device ":" dir subdir) >>> + (%str-cat dir subdir))) >>> + >>> +(defmacro with-open-dir ((dirent device dir) &body body) >>> + `(let ((,dirent (%open-dir (namestring (make-pathname :device ,device >>> :directory ,dir))))) >>> (when ,dirent >>> @@ -361,4 +368,7 @@ >>> (defun %one-wild (dir wild rest path so-far keys) >>> - (let ((result ()) (all (getf keys :all)) name subdir) >>> - (with-open-dir (dirent dir) >>> + (let ((result ()) >>> + (device (pathname-device path)) >>> + (all (getf keys :all)) >>> + name) >>> + (with-open-dir (dirent device dir) >>> (while (setq name (%read-dir dirent)) >>> @@ -368,4 +378,5 @@ >>> (%path-pstr*= wild name) >>> - (eq (%unix-file-kind (setq subdir (%str-cat dir name)) t) :directory)) >>> - (let ((so-far (cons (%path-std-quotes name nil "/;:*") so-far))) >>> + (eq (%unix-file-kind (%path-cat device dir name) t) :directory)) >>> + (let ((subdir (%path-cat nil dir name)) >>> + (so-far (cons (%path-std-quotes name nil "/;:*") so-far))) >>> (declare (dynamic-extent so-far)) >>> @@ -376,3 +387,4 @@ >>> (defun %files-in-directory (dir path so-far keys) >>> - (let ((name (pathname-name path)) >>> + (let ((device (pathname-device path)) >>> + (name (pathname-name path)) >>> (type (pathname-type path)) >>> @@ -388,9 +400,12 @@ >>> (if (not (or name type)) >>> - (when directories >>> - (setq ans (if directory-pathnames >>> - (%cons-pathname (reverse so-far) nil nil) >>> - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) >>> - (when (and ans (or (null test) (funcall test ans))) >>> - (setq result (list ans)))) >>> - (with-open-dir (dirent dir) >>> + (let (full-path) >>> + (when (and directories >>> + (eq (%unix-file-kind (namestring (setq full-path (%cons-pathname >>> (reverse so-far) nil nil nil device))) >>> + t) >>> + :directory)) >>> + (setq ans (if directory-pathnames full-path >>> + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil >>> device))) >>> + (when (and ans (or (null test) (funcall test ans))) >>> + (setq result (list ans))))) >>> + (with-open-dir (dirent (pathname-device path) dir) >>> (while (setq sub (%read-dir dirent)) >>> @@ -404,3 +419,3 @@ >>> (setq ans >>> - (if (eq (%unix-file-kind (%str-cat dir sub) t) :directory) >>> + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) >>> (when directories >>> @@ -408,7 +423,7 @@ >>> (if directory-pathnames >>> - (%cons-pathname (reverse (cons std-sub so-far)) nil nil) >>> - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) >>> std-sub nil)))) >>> + (%cons-pathname (reverse (cons std-sub so-far)) nil nil nil device) >>> + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) >>> std-sub nil nil device)))) >>> (when files >>> (multiple-value-bind (name type) (%std-name-and-type sub) >>> - (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name >>> type))))) >>> + (%cons-pathname (or dir-list (setq dir-list (reverse so-far))) name >>> type nil device))))) >>> (when (and ans (or (null test) (funcall test ans))) >>> @@ -421,2 +436,3 @@ >>> (result nil) >>> + (device (pathname-device path)) >>> (name (pathname-name path)) >>> @@ -427,3 +443,3 @@ >>> (follow-links (getf keys :follow-links)) >>> - sub subfile dir-list ans) >>> + sub dir-list ans) >>> ;; First process the case that the ** stands for 0 components >>> @@ -446,4 +462,4 @@ >>> (setq sub (if directory-pathnames >>> - (%cons-pathname (setq dir-list (reverse so-far)) nil nil) >>> - (%cons-pathname (reverse (cdr so-far)) (car so-far) nil))) >>> + (%cons-pathname (setq dir-list (reverse so-far)) nil nil nil >>> device) >>> + (%cons-pathname (reverse (cdr so-far)) (car so-far) nil nil >>> device))) >>> (when (or (null test) (funcall test sub)) >>> @@ -451,3 +467,3 @@ >>> ; now descend doing %all-dirs on dirs and collecting files & dirs >>> if do-x is t >>> - (with-open-dir (dirent dir) >>> + (with-open-dir (dirent device dir) >>> (while (setq sub (%read-dir dirent)) >>> @@ -456,4 +472,5 @@ >>> (not (string= sub ".."))) >>> - (if (eq (%unix-file-kind (setq subfile (%str-cat dir sub)) t) >>> :directory) >>> - (let* ((std-sub (%path-std-quotes sub nil "/;:*")) >>> + (if (eq (%unix-file-kind (%path-cat device dir sub) t) :directory) >>> + (let* ((subfile (%path-cat nil dir sub)) >>> + (std-sub (%path-std-quotes sub nil "/;:*")) >>> (so-far (cons std-sub so-far)) >>> @@ -463,5 +480,5 @@ >>> (setq ans (if directory-pathnames >>> - (%cons-pathname (reverse so-far) nil nil) >>> + (%cons-pathname (reverse so-far) nil nil nil device) >>> (%cons-pathname (or dir-list (setq dir-list (reverse (cdr >>> so-far)))) >>> - std-sub nil))) >>> + std-sub nil nil device))) >>> (when (or (null test) (funcall test ans)) >>> @@ -471,3 +488,3 @@ >>> (multiple-value-bind (name type) (%std-name-and-type sub) >>> - (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse >>> so-far))) name type)) >>> + (setq ans (%cons-pathname (or dir-list (setq dir-list (reverse >>> so-far))) name type nil device)) >>> (when (or (null test) (funcall test ans)) >>> >>> >>> >>> ;;; EOF >>> ;;; -------------------------------------------------- >>> >>> >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >>> >>> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> > ------------------------------------------------------------------------ > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sky at viridian-project.de Wed May 6 13:21:39 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Wed, 6 May 2009 22:21:39 +0200 (CEST) Subject: [Openmcl-devel] SLOT-UNBOUND broken? Message-ID: The following code (from the test suite) fails horribly on my machine: (defclass slot-unbound-class-01 () ((a :reader sunb-a) (b :accessor sunb-b) (c :writer sunb-c) (e :reader sunb-e) (f :reader sunb-f))) (defmethod slot-unbound ((class t) (obj slot-unbound-class-01) (slot-name t)) (list (class-name class) slot-name)) (let ((obj (make-instance 'slot-unbound-class-01))) (values (slot-value obj 'a) (slot-value obj 'b) (slot-value obj 'c))) Here's some more information: [17190] Clozure CL kernel debugger: b current thread: tcr = 0xb7c12a90, native thread ID = 0x432a, interrupts enabled (#xB7AADD44) #x00000000 : # + ?? (#xB7AADD7C) #x14CB40C5 : # + 79 (#xB7AADD90) #x14A3001D : # + 735 (#xB7AADDA0) #x14A309FD : # + 991 (#xB7AADDE4) #x14A3B335 : # + 391 (#xB7AADDF8) #x14A3C00D : # + 679 (#xB7AADE5C) #x14891EE5 : # + 311 (#xB7AADE94) #x143802FD : # + 247 (#xB7AADEB0) #x143E467D : # + 447 (#xB7AADED4) #x143E4D5D : # + 1495 (#xB7AADF04) #x14329A65 : # + 71 (#xB7AADF14) #x143E357D : # + 583 (#xB7AADF60) #x1433030D : # + 671 (#xB7AADFA4) #x14330C9D : # + 335 (#xB7AADFCC) #x1431856D : # + 279 [17190] Clozure CL kernel debugger: L %ebx (arg_z) = #
%esi (arg_y) = #
------ %edi (fn) = #
------ %ecx (temp0) = 0 %edx (temp1) = marked as unboxed (DF set) ------ %edx (nargs) = -303020452 (maybe) Intriguingly one of the registers pointed at a vector in an earlier session; now the addresses seem to be bogus. On a tangent, is there a way to instrument low-level functions (like the %maybe-std-slot-value-using-class) with print statements? I've tried it but then rebuiling CCL would fail at the heap building stage. I also attempted to look at some symbols but the kernel debugger seems to have a different idea of what a symbol means as it couldn't find any I asked it about. Leslie -- http://www.linkedin.com/in/polzer From martin.lisp at gmail.com Wed May 6 14:24:05 2009 From: martin.lisp at gmail.com (Martin) Date: Thu, 07 May 2009 00:24:05 +0300 Subject: [Openmcl-devel] Floating point exceptions on Windows In-Reply-To: References: <20090505160925.J33450@abq.clozure.com> <20090505202544.M33450@abq.clozure.com> Message-ID: R. Matthew Emerson wrote: > On May 5, 2009, at 11:01 PM, Gary Byers wrote: > >> If we clear the exception bits in the status word (via "fclex") >> after saving >> it in the non SSE2_MATH_LIB case, the problem seems to go away. > > > I hope I'm not belaboring the point too much, but I wanted to mention > that this fix is in both the 1.3 branch and in the trunk now. > > Please svn update and rebuild the lisp in the usual way. > > http://trac.clozure.com/openmcl/wiki/UpdatingFromSource > > I checked in new Windows lisp kernel binaries to the 1.3 branch, so > that you don't have Cygwin and gcc installed to get the fix. I pulled the update earlier in the day and it worked fine on the test case. Let me how it goes. Thanks for looking into this. Regards, Martin. From gb at clozure.com Wed May 6 14:54:51 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 6 May 2009 15:54:51 -0600 (MDT) Subject: [Openmcl-devel] SLOT-UNBOUND broken? In-Reply-To: References: Message-ID: <20090506145549.I41243@abq.clozure.com> What I find is that it seems to work fine on all ppc and x86-64 platforms that I've tried it on and on 32-bit x86 Darwin, Windows, Solaris, and FreeBSD. On 32-bit x86 Linux, the unbound slot causes a trap (as it should on all platforms); the lisp kernel calls out to a lisp handler, the handler (seems to) call the appropriate SLOT-UNBOUND method, and when it returns to the lisp kernel, something is very, very wrong. Ah. In general, returning/continuing after an error trap seems to be broken on 32-bit x86 Linux: ? (defvar *x*) *X* ? (defun foo () *x*) FOO ? (foo)> > Error: Unbound variable: *X* > While executing: FOO, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Retry getting the value of *X*. > Type :? for other options. 1 > (use-value 1) -> crashes very hard for me; it even kills the process. On Wed, 6 May 2009, Leslie P. Polzer wrote: > > The following code (from the test suite) fails horribly > on my machine: > > (defclass slot-unbound-class-01 () > ((a :reader sunb-a) > (b :accessor sunb-b) > (c :writer sunb-c) > (e :reader sunb-e) > (f :reader sunb-f))) > > (defmethod slot-unbound ((class t) (obj slot-unbound-class-01) (slot-name t)) > (list (class-name class) slot-name)) > > (let ((obj (make-instance 'slot-unbound-class-01))) > (values > (slot-value obj 'a) > (slot-value obj 'b) > (slot-value obj 'c))) > > Here's some more information: > > [17190] Clozure CL kernel debugger: b > current thread: tcr = 0xb7c12a90, native thread ID = 0x432a, interrupts enabled > > > (#xB7AADD44) #x00000000 : # + ?? > (#xB7AADD7C) #x14CB40C5 : # + 79 > (#xB7AADD90) #x14A3001D : # + 735 > (#xB7AADDA0) #x14A309FD : # + 991 > (#xB7AADDE4) #x14A3B335 : # + 391 > (#xB7AADDF8) #x14A3C00D : # + 679 > (#xB7AADE5C) #x14891EE5 : # + 311 > (#xB7AADE94) #x143802FD : # + 247 > (#xB7AADEB0) #x143E467D : # + 447 > (#xB7AADED4) #x143E4D5D : # + 1495 > (#xB7AADF04) #x14329A65 : # (LISP-DEVELOPMENT-SYSTEM T))) #x14329A1E> + 71 > (#xB7AADF14) #x143E357D : # + > 583 > (#xB7AADF60) #x1433030D : # + 671 > (#xB7AADFA4) #x14330C9D : # #x14330B4E> + 335 > (#xB7AADFCC) #x1431856D : # #x14318456> + 279 > > [17190] Clozure CL kernel debugger: L > %ebx (arg_z) = #
> %esi (arg_y) = #
> ------ > %edi (fn) = #
> ------ > %ecx (temp0) = 0 > %edx (temp1) = marked as unboxed (DF set) > ------ > %edx (nargs) = -303020452 (maybe) > > Intriguingly one of the registers pointed at a vector in an earlier > session; now the addresses seem to be bogus. > > On a tangent, is there a way to instrument low-level functions > (like the %maybe-std-slot-value-using-class) with print statements? One issue with doing so is that you want to avoid the infinite recursion that'd occur when PRINT calls %MAYBE-STD-SLOT-VALUE-USING-CLASS (which now calls some flavor of PRINT, which eventually tries to tell you that the stack has overflowed but can't do that without PRINTing ...) > > I've tried it but then rebuiling CCL would fail at the heap > building stage. Yup. (It's probably true that %MAYBE-STD-SLOT-VALUE-USING-CLASS gets called before anything has any idea of what a STREAM is, much less how to print to one.) What sort of works (doesn't scale well but avoids recursion/bootstrapping issues) is to use CCL::DBG to enter the kernel debugger, which can sort of (if you squint) print lisp objects (some better than others.) CCL::DBG's optional argument gets loaded into the arg_z register (%ebx on x8632), and you can sometimes make sense of arg_z in the kernel debugger's L output. In this particular case, it looks to me like everything on the lisp side (at least up until the unbound slot is discovered) is OK: ? (slot-value (make-instance 'example) 'slot) > Error: Slot SLOT is unbound in # > While executing: #, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > and we call (in this case) the default SLOT-UNBOUND method; the bug seems to have to do with being able to return to the point where the unbound slot was discovered in the case where SLOT-UNBOUND tries to return a value. (And, apparently, with continuing after an error that generates a trap on x8632 Linux in general. All of that code is machine- and OS-dependent.) > > I also attempted to look at some symbols but the kernel debugger > seems to have a different idea of what a symbol means as it couldn't > find any I asked it about. ? for help [4479] Clozure CL kernel debugger: s symbol name :READ-CHAR ; it doesn't upper-case the pname for you Symbol READ-CHAR at #x140A60E6 value : # function : # All that that debugger function does is to scan the lisp heap until it finds a symbol whose pname matches the (case-sensitive) string that you enter; if it finds such a symbol, it shows its global function and value cell values. > > Leslie > > -- > http://www.linkedin.com/in/polzer > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From raffaelcavallaro at mac.com Wed May 6 15:15:31 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 06 May 2009 18:15:31 -0400 Subject: [Openmcl-devel] random statistical properties and period? Message-ID: What are the statistical properties and period of CCL's implementation of random? regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From steve.nunez at illation.com.sg Wed May 6 16:26:28 2009 From: steve.nunez at illation.com.sg (Steve =?iso-8859-1?b?TvrxZXo=?=) Date: Wed, 06 May 2009 23:26:28 +0000 Subject: [Openmcl-devel] History Message-ID: <20090506232628.13494fxhhi7m1go4@illation.sg> Gentlemen,I'm a bit courious as to the history openmcl. On the Clozure website it states in the sidebar that "Gary Byers forked the code in 1998 ... this fork was called OpenMCL when Digitool open sourced it in 2001. Digitool announced in 2007 that MCL will be open sourced. ..." The first part is clear enough, but what happened to the Digitool MCL? I don't see that anywhere on their website. In fact their website seem to have stopped being updated, with the last "What's New?" dated 2005. A long mailing list thread back in 2007 discussed porting various bits of MCL to OpenMCL. I never used MCL, but much of the discussion revolved around porting things like Fred & CAPI to OpenMCL. I personally like emacs/slime, but for some of the newer programmers in our environment, especially those coming from other, usually Java based IDE's, a good development environment would smooth the transition until they came up to speed. Hemlock just doesn't impress newcomers. This post: http://clozure.com/pipermail/info-mcl/2007-October/000109.html and Peter Paine's comments: Lisp in itself does not win more than a quirky following (and give passing students headaches). Allowing developers to do flashy MacOS-ish things could help get the bandwagon's wheels turning. Wizard Lisp compiler and terminal tools will at best serve the needs of a vanishingly small niche. But a Lisp environment that helps developers to put together modern applications which serve end user needs, surely this will open doors ... why not flood gates. The API will help bring Lisp out of the lab/ivory tower. was pretty good, I thought. Personally, I'd lean toward a great Cocoa toolkit and forget about portability, since resources would probably not permit both. Anyway, that's old news, but an interesting thread. What's happened since October 2007? We've got quite a few PPC lying about, where can we get MCL to try it out? Cheers, - SteveN ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Wed May 6 17:14:29 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 6 May 2009 18:14:29 -0600 (MDT) Subject: [Openmcl-devel] History In-Reply-To: <20090506232628.13494fxhhi7m1go4@illation.sg> References: <20090506232628.13494fxhhi7m1go4@illation.sg> Message-ID: <20090506173118.T41243@abq.clozure.com> On Wed, 6 May 2009, Steve N??ez wrote: [...] > Anyway, that's old news, but an interesting thread. What's happened > since October 2007? We've got quite a few PPC lying about, where can > we get MCL to try it out? > > Cheers, > > - SteveN > > > From rme at clozure.com Wed May 6 17:26:35 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Wed, 6 May 2009 20:26:35 -0400 Subject: [Openmcl-devel] random statistical properties and period? In-Reply-To: References: Message-ID: <0837C493-94E7-4F6B-9369-9E50B9562D0E@clozure.com> On May 6, 2009, at 6:15 PM, Raffael Cavallaro wrote: > What are the statistical properties and period of CCL's implementation > of random? I don't know the answer to this question directly, but CCL's implementation of RANDOM is based on the "minimal standard" generator as described in Park and Miller's CACM paper: http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf CCL uses a multiplier of 48271 (which Park and Miller recommend in http://www.firstpr.com.au/dsp/rand31/p105-crawford.pdf) instead of 16807. One thing of note (that might be considered a bug) is that the 32-bit and 64-bit ports don't produce the same sequence of numbers. However, the 32-bit ports should produce results that agree with each other; likewise for the 64-bit ports. From terje at in-progress.com Wed May 6 17:26:35 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Wed, 6 May 2009 17:26:35 -0700 Subject: [Openmcl-devel] History In-Reply-To: <20090506232628.13494fxhhi7m1go4@illation.sg> References: <20090506232628.13494fxhhi7m1go4@illation.sg> Message-ID: <87F87CD7-8161-4308-A15E-B5F2D9B204D0@in-progress.com> On May 6, 2009, at 4:26 PM, Steve N??ez wrote: > Anyway, that's old news, but an interesting thread. What's happened > since October 2007? We've got quite a few PPC lying about, where > can we get MCL to try it out? > MCL 5.2 can be downloaded from: ftp://ftp.clozure.com/pub/MCL/ Enjoy! -- Terje Norderhaug From gb at clozure.com Wed May 6 19:06:15 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 6 May 2009 20:06:15 -0600 (MDT) Subject: [Openmcl-devel] random statistical properties and period? In-Reply-To: References: Message-ID: <20090506181605.M41243@abq.clozure.com> It's a Linear Congruential Generator. "The literature" (e.g., Google, Wikipedia) could probably describe the statistical properties of the algorithm better than I could; a quick summary of that literature (paraphrased slightly) is: a: Linear Congruential Generators suck! b: No, they don't. a: Yes, they do. b: Do not! a: Do too! As you can see, there's quite a lively debate surrounding this issue. (Actually, I think that the debate has to do with whether or not LCG's are "good enough"; I think that there's general agreement that they can have undesirable properties.) I've seen visual aids suggesting that LCGs are prone to temporal clustering effects (that a lot of sequentially generated values or short sequences of those values share common bits or fall into clustered ranges, but whether this is true and the degree to which it is true may depend on the moduli involved (e.g., (RANDOM m) might show clustering, (RANDOM n) might not. My understanding of the issue is that other algorithms are more likely to provide statistically random distributions. The way that it's implemented, the generator cycles (pseudo-)randomly through values in the range 1..2^31-1, so if this were C we'd say that its period was 2^31-2. It's lisp (not C), and RANDOM may call the underlying generator multiple times per (RANDOM N) call; the period of (RANDOM N) depends on N for this and other reasons and can be more or less than 2^31-2. ;;; Based on a similar function used in email by Bernd Beuster (defun random-run-length (n &optional (print t)) (loop with start fixnum = (random n) for current fixnum = (random n) for i fixnum from 1 until (= current start) finally (return i) do (when (and print (zerop (mod i 10000000))) (print i)))) On Wed, 6 May 2009, Raffael Cavallaro wrote: > What are the statistical properties and period of CCL's implementation > of random? > > 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 > > From gb at clozure.com Wed May 6 23:54:55 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 7 May 2009 00:54:55 -0600 (MDT) Subject: [Openmcl-devel] SLOT-UNBOUND broken? In-Reply-To: <20090506145549.I41243@abq.clozure.com> References: <20090506145549.I41243@abq.clozure.com> Message-ID: <20090507003412.S41243@abq.clozure.com> I think that this is fixed in both the trunk and 1.3 as of r12012. If anyone's interested: the problem was that while calling back to lisp from foreign code, we pushed the register that contained the CPU flags/ condition codes on the stack, ensured that the stack was aligned on a 16-byte boundary (as it is at that point on most x8632 platforms), called out to lisp and, if we returned, popped the flags off of the stack and returned to the lisp kernel code that did the callback. Unfortunately, if the "ensure that the stack was aligned" operation actually changed the stack pointer - as it often would on Linux - we weren't popping the flags from the place they'd been pushed, and the CPU flags were set to unpredictable values: I was often getting the trace flag set (and crashing in a storm of SIGTRAP exceptions); the "direction flag" (which controls whether memory-moving instructions increment or decrement the registers that address their operands) could have been set to an unexpected value, and general wackiness would have ensued. I had thought that continuing (via STORE-VALUE/USE-VALUE/CONTINUE) after an UNBOUND-VARIABLE error was also affected by this. It was, but there are other problems with the way that those errors are signaled and handled that keep those restarts from working. Until that's fixed, we won't automatically generate those restarts on UNBOUND-VARIABLE errors. (As far as I can tell, the restarts have never worked on x86* versions of CCL; apparently, the feature isn't used that often, since I don't think that it's failure to work has ever been reported. On Wed, 6 May 2009, Gary Byers wrote: > What I find is that it seems to work fine on all ppc and x86-64 > platforms that I've tried it on and on 32-bit x86 Darwin, Windows, > Solaris, and FreeBSD. On 32-bit x86 Linux, the unbound slot causes a > trap (as it should on all platforms); the lisp kernel calls out to a > lisp handler, the handler (seems to) call the appropriate SLOT-UNBOUND > method, and when it returns to the lisp kernel, something is very, > very wrong. > > Ah. In general, returning/continuing after an error trap seems to be broken > on 32-bit x86 Linux: > > ? (defvar *x*) > *X* > ? (defun foo () *x*) > FOO > ? (foo)> >> Error: Unbound variable: *X* >> While executing: FOO, in process listener(1). >> Type :GO to continue, :POP to abort, :R for a list of available restarts. >> If continued: Retry getting the value of *X*. >> Type :? for other options. > 1 > (use-value 1) > -> crashes very hard for me; it even kills the process. > > On Wed, 6 May 2009, Leslie P. Polzer wrote: > >> >> The following code (from the test suite) fails horribly >> on my machine: >> >> (defclass slot-unbound-class-01 () >> ((a :reader sunb-a) >> (b :accessor sunb-b) >> (c :writer sunb-c) >> (e :reader sunb-e) >> (f :reader sunb-f))) >> >> (defmethod slot-unbound ((class t) (obj slot-unbound-class-01) (slot-name t)) >> (list (class-name class) slot-name)) >> >> (let ((obj (make-instance 'slot-unbound-class-01))) >> (values >> (slot-value obj 'a) >> (slot-value obj 'b) >> (slot-value obj 'c))) >> >> Here's some more information: >> >> [17190] Clozure CL kernel debugger: b >> current thread: tcr = 0xb7c12a90, native thread ID = 0x432a, interrupts enabled >> >> >> (#xB7AADD44) #x00000000 : # + ?? >> (#xB7AADD7C) #x14CB40C5 : # + 79 >> (#xB7AADD90) #x14A3001D : # + 735 >> (#xB7AADDA0) #x14A309FD : # + 991 >> (#xB7AADDE4) #x14A3B335 : # + 391 >> (#xB7AADDF8) #x14A3C00D : # + 679 >> (#xB7AADE5C) #x14891EE5 : # + 311 >> (#xB7AADE94) #x143802FD : # + 247 >> (#xB7AADEB0) #x143E467D : # + 447 >> (#xB7AADED4) #x143E4D5D : # + 1495 >> (#xB7AADF04) #x14329A65 : #> (LISP-DEVELOPMENT-SYSTEM T))) #x14329A1E> + 71 >> (#xB7AADF14) #x143E357D : # + >> 583 >> (#xB7AADF60) #x1433030D : # + 671 >> (#xB7AADFA4) #x14330C9D : #> #x14330B4E> + 335 >> (#xB7AADFCC) #x1431856D : #> #x14318456> + 279 >> >> [17190] Clozure CL kernel debugger: L >> %ebx (arg_z) = #
>> %esi (arg_y) = #
>> ------ >> %edi (fn) = #
>> ------ >> %ecx (temp0) = 0 >> %edx (temp1) = marked as unboxed (DF set) >> ------ >> %edx (nargs) = -303020452 (maybe) >> >> Intriguingly one of the registers pointed at a vector in an earlier >> session; now the addresses seem to be bogus. >> >> On a tangent, is there a way to instrument low-level functions >> (like the %maybe-std-slot-value-using-class) with print statements? > > One issue with doing so is that you want to avoid the infinite recursion > that'd occur when PRINT calls %MAYBE-STD-SLOT-VALUE-USING-CLASS (which now > calls some flavor of PRINT, which eventually tries to tell you that the > stack has overflowed but can't do that without PRINTing ...) > >> >> I've tried it but then rebuiling CCL would fail at the heap >> building stage. > > Yup. (It's probably true that %MAYBE-STD-SLOT-VALUE-USING-CLASS gets called > before anything has any idea of what a STREAM is, much less how to print to one.) > > What sort of works (doesn't scale well but avoids recursion/bootstrapping issues) > is to use CCL::DBG to enter the kernel debugger, which can sort of (if you squint) > print lisp objects (some better than others.) CCL::DBG's optional argument gets > loaded into the arg_z register (%ebx on x8632), and you can sometimes make > sense of arg_z in the kernel debugger's L output. > > In this particular case, it looks to me like everything on the lisp side (at least > up until the unbound slot is discovered) is OK: > > ? (slot-value (make-instance 'example) 'slot) >> Error: Slot SLOT is unbound in # >> While executing: #, in process listener(1). >> Type :POP to abort, :R for a list of available restarts. >> Type :? for other options. > 1 > > > and we call (in this case) the default SLOT-UNBOUND method; the bug seems to have > to do with being able to return to the point where the unbound slot was discovered > in the case where SLOT-UNBOUND tries to return a value. (And, apparently, with > continuing after an error that generates a trap on x8632 Linux in general. All > of that code is machine- and OS-dependent.) > >> >> I also attempted to look at some symbols but the kernel debugger >> seems to have a different idea of what a symbol means as it couldn't >> find any I asked it about. > > ? for help > [4479] Clozure CL kernel debugger: s > > symbol name :READ-CHAR ; it doesn't upper-case the pname for you > Symbol READ-CHAR at #x140A60E6 > value : # > function : # > > All that that debugger function does is to scan the lisp heap until it finds > a symbol whose pname matches the (case-sensitive) string that you enter; if > it finds such a symbol, it shows its global function and value cell values. > > >> >> Leslie >> >> -- >> http://www.linkedin.com/in/polzer >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From julian at cipht.net Thu May 7 11:07:54 2009 From: julian at cipht.net (Julian Squires) Date: Thu, 7 May 2009 14:07:54 -0400 Subject: [Openmcl-devel] signedness issue in %ffcall on ppc Message-ID: <8986e60905071107g3d000522p646ab3c904c0aad0@mail.gmail.com> Hi, Given the following example: (asdf:oos 'asdf:load-op :cffi) (cffi:defcfun "srandom" :void (seed :unsigned-int)) (srandom #x80000000) with Clozure Common Lisp Version 1.3-r11936 (LinuxPPC32) I receive the following error: > Error: value 2147483648 is not of the expected type (SIGNED-BYTE 32). > While executing: %FF-CALL, in process listener(1). The attached patch (to level-0/PPC/ppc-def.lisp) appears to correct this issue. Cheers, -- Julian Squires -------------- next part -------------- A non-text attachment was scrubbed... Name: ccl-level-0-unsigned-long.patch Type: text/x-diff Size: 810 bytes Desc: not available URL: From ralex at cs.colorado.edu Thu May 7 13:54:17 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Thu, 7 May 2009 14:54:17 -0600 Subject: [Openmcl-devel] debugging debugging Message-ID: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> we got early parts of our game engine ported to CCL. Things are going pretty well so far, i.e., event processing and threading working better than ever in MCL, but... In the IDE version practically 90% of the code is running in some thread other than the main one, e.g., some method dealing with a mouse click, some animation running, some opengl view rendering. No problem as long as there is no bug. The moment there is a problem in any of these event handling, animation or rendering methods one gets the AltConsole. In there I usually do not get a prompt to do anything meaningful. I have to scroll back to see what caused the problem "*** Error in event process: ...." The functionality is very limited compared to getting the same bug in the main thread with feedback in the listener. I cannot - get an interactive backtrace: backtrace list with disclosure triangles - get restart menus - clear/delete the content. Text just piles up. The Edit > Delete menu does not work. A clear button similar to the OS X console would be great In other words the problem is that in 90% of the cases (code running in non main thread) one gets 10% of the debugging functionality. In MCL a new thread associated Listener would pop up giving the developer the same debugging tools no matter which thread caused the issue. Could that functionality be added to CCL? alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Thu May 7 16:33:15 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 7 May 2009 17:33:15 -0600 (MDT) Subject: [Openmcl-devel] debugging debugging In-Reply-To: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> References: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> Message-ID: <20090507151509.B41243@abq.clozure.com> On Thu, 7 May 2009, Alexander Repenning wrote: > we got early parts of our game engine ported to CCL. Things are going pretty > well so far, i.e., event processing and threading working better than ever in > MCL, but... > > In the IDE version practically 90% of the code is running in some thread > other than the main one, e.g., some method dealing with a mouse click, some > animation running, some opengl view rendering. No problem as long as there is > no bug. The moment there is a problem in any of these event handling, > animation or rendering methods one gets the AltConsole. In there I usually do > not get a prompt to do anything meaningful. I have to scroll back to see what > caused the problem "*** Error in event process: ...." The functionality is > very limited compared to getting the same bug in the main thread with > feedback in the listener. I cannot > > - get an interactive backtrace: backtrace list with disclosure triangles > - get restart menus > - clear/delete the content. Text just piles up. The Edit > Delete menu does > not work. A clear button similar to the OS X console would be great > > In other words the problem is that in 90% of the cases (code running in non > main thread) one gets 10% of the debugging functionality. In MCL a new thread > associated Listener would pop up giving the developer the same debugging > tools no matter which thread caused the issue. > > Could that functionality be added to CCL? MCL ordinarily did event processing from a distinguished (cooperative) thread; when that got an error and needed to interact with the user, a new (cooperative) thread was created and designated as the "standin event processor", and the event thread created a window and ran a break loop in that window. "running a break loop" meant that -something- was handling updates and responding to keystrokes and other events while the thread that got the error was printing the error message and waiting for/responding to user input in a break loop. When the break loop was exited, the "standin event processor" thread was killed, the original event thread resumed event processing (presumably after the cause of the error was addressed), and things went back to normal. At no point was any thread asked to do two things at once (the original event thread in particular was not asked to both run a break loop and an event loop). It's generally hard to do two things at once, though you can sometimes fake it using timer interrupts or some scheme like that. This worked as well as it did (fairly well, in fact) in MCL for a number of reasons; one of the most important of those reasons is that Carbon allowed any cooperative thread to receive events (via #_WaitNextEvent.) Since only one cooperative thread could run at any time and since context switch between cooperative threads only happened at well-defined times, this was generally fairly tractable. (It was of course possible for one thread to see a mouse-down event and another to see the corresponding mouse-up; MCL tried to ensure that only the "designated event processor" thread actually processed events to avoid serialization issues, but the OS allowed other approaches to that problem. As far as I remember, MCL only changed its notion of the designated event processor when the current event processor got an error and wanted to enter a break loop, but it could have just passed this designation around whenever it felt like it. I'm fairly sure that any MCL thread could just put a (real, window-system) modal dialog on the screen and run a modal event loop waiting for a button to be pressed; unless special measures were taken, that wouldn't introduce serialization issues, since no other (cooperative) thread could run during that modal event loop. If the application instead uses native, preemptively-scheduled threads, the issues related to threads and event processing are different. Among other things, if multiple native threads were allowed to process events, then it'd be possible for thread A to receive a mouse-up event before thread B has received the corresponding mouse-down (this can easily happen because of scheduling issues, even if the events were issued in the right order, there's no guarantee that multiple threads would completely receive them in a predicatable order.) Because there's virtually no way to win (and many ways to lose) and because it simplifies event delivery (event messages can be sent by the window server to a thread-specific message port; replies are only expected from that port), modern Carbon and Cocoa basically only allow one (native) thread within an application to do event processing. (That thread is almost always the initial thread - the one created by the OS when the application started. There have been some loopholes and backdoors that have allowed some other thread to process events instead of the initial thread, but they've been closed and more will be closed in future OS releases.) I know of no way of changing that at runtime (and can't imagine how that could work), so we're basically (while running Cocoa in CCL with native threads) in a situtation where the initial thread is the "designated - by Cocoa - event processor" and there's no way to change that. Anyone who's ever looked at the gory details of MCL's event code might agree that that's mostly a good thing, but it does mean that when an error occurs in the event thread, we can't do what MCL did (allow the event thread to enter a break loop while some other thread took over event-processing responsibilities). (I hope that anyone who thinks that we're not doing that because we forgot to or forgot how to is dissuaded of that belief.) If the event thread can only do one thing at a time (when it gets an error or in other contexts) and can't simultaneously run a break loop in an IDE window and process events pertaining to that and other windows, we seem to have a limited choice of things that we can do. I agree that what we've been doing - just writing a backtrace to the AltConsole window if it's there or to a logging stream if it isn't, or just filling up an Emacs buffer with that backtrace, then returning to process the next event before the beachball cursor appears - is suboptimal. What one would ideally like to do is to enter a break loop and have normal debugging facilities available to you in the IDE. Doing things in the IDE generally means being able to process events, and the one thread that Cocoa allows to process events really wants to be sitting in a break loop instead and can't easily do two things at the same time. Another subpoptimal solution (which may be better than the status quo) is to choose to do one thing (enter a break loop) and completely ignore the other (event processing) and enter a break loop with I/O redirected to the AltConsole window. (AltConsole is a little ObjC program that can sort of act as a simple termimal-like device for a remote process, like the CCL IDE). Event processing in the lisp GUI application would stop and you wouldn't have access to GUI backtrace/inspector/other tools while trying to debug things, but the debugging that you'd be doing would be taking place in the dynamic context where the error occurred (unlike the current "backtrace and run") behavior. Yes, this is far from ideal, but being able to browse around the backtrace and type expressions to a break loop may make debugging easier than it has been and seems like it's at least a step in the right direction. I think that we all agree that it'd be much better to be able to use the IDE to debug the IDE than to do what we've been doing or to do what I proposed in the last paragraph. I hope that people will either agree that this requires the ability to do two things at the same time or be able to point out that this is in fact not required for reasons that I'm not thinking about. (It's not really necessary to do two things "at the same time", but it's likely necessary to slice the event thread's time up so that it transparently alternates between two execution contexts - event processing and the break loop - somehow.) If anyone reads this and finds themselves thinking that they want to go back to the simpler days of cooperative threads, the only thing I can say is "no, you don't." > > alex > > > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > From alms at clozure.com Thu May 7 17:00:00 2009 From: alms at clozure.com (Andrew Shalit) Date: Thu, 7 May 2009 20:00:00 -0400 Subject: [Openmcl-devel] debugging debugging In-Reply-To: <20090507151509.B41243@abq.clozure.com> References: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> <20090507151509.B41243@abq.clozure.com> Message-ID: On May 7, 2009, at 7:33 PM, Gary Byers wrote: > > Another subpoptimal solution (which may be better than the status quo) > is to choose to do one thing (enter a break loop) and completely > ignore > the other (event processing) and enter a break loop with I/O > redirected > to the AltConsole window. (AltConsole is a little ObjC program that > can sort of act as a simple termimal-like device for a remote process, > like the CCL IDE). Event processing in the lisp GUI application would > stop and you wouldn't have access to GUI backtrace/inspector/other > tools > while trying to debug things, but the debugging that you'd be doing > would > be taking place in the dynamic context where the error occurred > (unlike > the current "backtrace and run") behavior. Yes, this is far from > ideal, > but being able to browse around the backtrace and type expressions to > a break loop may make debugging easier than it has been and seems like > it's at least a step in the right direction. A couple of months ago we briefly discussed a less suboptimal variation of this approach. The AltConsole is currently a simple terminal-like device written in Objective C. There's no reason, in theory, why the AltConsole couldn't be a more sophisticated GUI application written in another programming language, Lisp even. It would still run as a separate application, but it could communicate with the CCL via something akin to a Slime/Swank protocol, and it could present things like backtraces and inspector windows in nice Macintosh windows. It would even be theoretically possible to reuse some of the CCL IDE code for this purpose. (I'm not familiar with that code enough to know whether that's a practical approach.) At least, that's how I remember the conversation. Someone else from Clozure, please correct me if I'm misremembering. I think extending the AltConsole in this way is beyond the scope of what we can do within the current CCL IDE pledge drive funding. But we might be able to find time to do it gratis, or some user(s) could work on it, or could fund it. From lisp at clairvaux.org Thu May 7 17:51:11 2009 From: lisp at clairvaux.org (Glen Foy) Date: Thu, 7 May 2009 20:51:11 -0400 Subject: [Openmcl-devel] debugging debugging In-Reply-To: References: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> <20090507151509.B41243@abq.clozure.com> Message-ID: On May 7, 2009, at 8:00 PM, Andrew Shalit wrote: > It would still run as a separate application, but it could communicate > with the CCL via something akin to a Slime/Swank protocol, and it > could present things like backtraces and inspector windows in nice > Macintosh windows. It would even be theoretically possible to reuse > some of the CCL IDE code for this purpose. (I'm not familiar with > that code enough to know whether that's a practical approach.) Possibly just launch a second CCL image with a customized menu for debugging? The two could communicate via a socket as in Slime/Swank. From Toomas.Altosaar at hut.fi Fri May 8 00:09:06 2009 From: Toomas.Altosaar at hut.fi (Toomas Altosaar) Date: Fri, 8 May 2009 10:09:06 +0300 Subject: [Openmcl-devel] debugging debugging Message-ID: Most likely very few people are aware of this, but from around version 5.1b4 onwards, MCL offered a bona fide real-time environment in Lisp. Tens of cooperative threads (processes) could run in "parallel" (time-sliced) without having one thread affecting the processing capabilities of another thread. If any one (or more) processes would error, processing in the other threads would continue normally without the entire show coming to a grinding halt, regardless of what the mouse or some other input device's state was or was doing. This type of behavior is an important requirement in large complex systems. Without this feature large systems become very difficult to build and test reliably in any practical manner. MCL contained a flag, ccl::*processing-events*. When T it indicated that a "normal" MCL thread was running (at this time process "Initial" would be in a "Suspended" state). When NIL, then process "Initial" was running. So it was possible for any Lisp code to check what thread was running and act accordingly, e.g., i) skip over mouse event processing and do actual work (e.g., drawing), or, ii) do mouse processing but leave other work (e.g., drawing) to another process that was calling the same code. Would it make sense to set up such a similar flag that indicates when the initial thread is running? (thread "Initial" is the one that starts up when the app starts to run) Since the Initial thread is so "control hungry" under the current OS, then it seems that it should avoid being in a error state at all costs. Could it not delegate event processing to another error-protected Lisp thread A, so that when A arrives in an error condition then Initial could initiate a stand-in error processor for failed thread A? From manuel.weikert at googlemail.com Fri May 8 01:31:20 2009 From: manuel.weikert at googlemail.com (Manuel Weikert) Date: Fri, 8 May 2009 10:31:20 +0200 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work Message-ID: Hi there, sorry to bother you with this, but I couldn't find a solution for this anywhere. A few days ago I installed ClozureCL on my mac. Everything works fine but I find the Editor which comes with the IDE a little bit inconvenient. So I decided to use Aquamacs instead. I made the necessary adjustments to the configuration files but after a M-x slime I got this: value 0 is not of the expected type CCL::CTYPE. ?? [Condition of type TYPE-ERROR] Restarts: ?0: [RETRY-LOAD] Retry loading #P"/Applications/ccl/tools/asdf.lisp" [...some other output removed...] Despite all this and the fact that I can't load any packages the rest works fine. Does anyone have any idea what sort of a stupid mistake a made? Manu From arthur.cater at ucd.ie Fri May 8 02:12:22 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Fri, 08 May 2009 10:12:22 +0100 Subject: [Openmcl-devel] debugging debugging In-Reply-To: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> References: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> Message-ID: As I mentioned in March, I have a similar problem with errors occurring on other threads, in my case often threads other than the Event?thread. I'm told to type (:Y 8) ? eg ? but neither the Listener nor the AltConsole does anything when I do so. A simple example of this is with (process-run-function "Breaker" #'(lambda nil (break "Talk to me"))) The Event thread still runs, but there is no way afaik of getting any debugging info, not even a simple backtrace. Arthur ----- Original Message ----- From: Alexander Repenning Date: Thursday, May 7, 2009 9:58 pm Subject: [Openmcl-devel] debugging debugging To: openmcl-devel Devel > we got early parts of our game engine ported to CCL. Things are going pretty well so far, i.e., event processing and threading working better than ever in MCL, but... > In the IDE version practically 90% of the code is running in some thread other than the main one, e.g., some method dealing with a mouse click, some animation running, some opengl view rendering. No problem as long as there is no bug. The moment there is a problem in any of these event handling, animation or rendering methods one gets the AltConsole. In there I usually do not get a prompt to do anything meaningful. I have to scroll back to see what caused the problem "*** Error in event process: ?...." The functionality is very limited compared to getting the same bug in the main thread with feedback in the listener. I cannot? > - get an interactive backtrace: backtrace list with disclosure triangles > - get restart?menus > - clear/delete the content. Text just piles up. The Edit > Delete menu does not work. A clear button similar to the OS X console would be great > In other words the problem is that in 90% of the cases (code running in non main thread) one gets 10% of the debugging functionality. In MCL a new thread associated Listener would pop up giving the developer the same debugging tools no matter which thread caused the issue.? > Could that functionality be added to CCL? > alex > Prof. Alexander Repenning > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at pasternacki.net Fri May 8 03:04:12 2009 From: maciej at pasternacki.net (Maciej Pasternacki) Date: Fri, 8 May 2009 12:04:12 +0200 Subject: [Openmcl-devel] patch: ability to create socket for given file descriptor number Message-ID: <5ACDF50B-3C80-4495-8296-ECD2864BAC4F@pasternacki.net> Hello everyone, I looked into possibility of using Clozure CL in shared Web hosting environment; Clozure may be really good in this kind of environment, because of more limits-friendly memory handling than SBCL. Since I care for efficiency, plain CGI is out (if I thought about plain CGI, I could use clisp as well), and FastCGI seems to be one of most widespread standards at the moment. Many shared hosting providers, however, don't provide possibility of running FastCGI servers outside of Web server on arbitrary port or socket, but support only fcgi scripts, that are spawned by Web server and receive a listening socket on stdin. So, basically, I need to create a socket structure for standard input file descriptor (fd 0) and rebind basic streams. Second part is trivial; however, CCL doesn't seem to provide way to pass a file descriptor to any of socket-creating functions. I looked a bit into l1-sockets.lisp and came up with a small patch, included here for review. Patch adds FD as an accepted keyword argument to CCL:MAKE-SOCKET, and changes FD from auxilliary variable to a keyword argument in all downstream functions. Downstream functions call c_socket only when FD argument wasn't supplied, otherwise trusting caller that given file descriptor is a descriptor for right kind of socket, and using it to create socket structure. Patch is made against SVN trunk. Regards, Maciej. -------------- next part -------------- A non-text attachment was scrubbed... Name: ccl-fdsocket.patch Type: application/octet-stream Size: 2360 bytes Desc: not available URL: -------------- next part -------------- -- Maciej Pasternacki -><- http://www.pasternacki.net/ -><- http://www.3ofcoins.net/ From gb at clozure.com Fri May 8 03:18:12 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 8 May 2009 04:18:12 -0600 (MDT) Subject: [Openmcl-devel] debugging debugging In-Reply-To: References: Message-ID: <20090508011025.U41243@abq.clozure.com> On Fri, 8 May 2009, Toomas Altosaar wrote: > > Would it make sense to set up such a similar flag that indicates when > the initial thread is running? (thread "Initial" is the one that > starts up when the app starts to run) CCL isn't directly involved in deciding when a thread is running or when it isn't; that's the OS's job. Thread A can sort of ask the OS what state thread B's in, but unless we're sure that thread B's state can't change, the answer's nearly meaningless (thread B's state may have changed several times by the time thread A gets that answer.) If you're coming from MCL and used to thinking of these things in its terms, there are lots of things that may take some getting used to. On machines with multiple CPU cores (the vast majority of the machines sold over the last few years), it's no longer meaningful to think that there's only one "current thread". > > Since the Initial thread is so "control hungry" under the current OS, > then it seems that it should avoid being in a error state at all > costs. Could it not delegate event processing to another > error-protected Lisp thread A, so that when A arrives in an error > condition then Initial could initiate a stand-in error processor for > failed thread A? > No. See my earlier message in this thread for an explanation of why this isn't possible. From gb at clozure.com Fri May 8 04:25:55 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 8 May 2009 05:25:55 -0600 (MDT) Subject: [Openmcl-devel] debugging debugging In-Reply-To: References: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> Message-ID: <20090508041825.O41243@abq.clozure.com> On Fri, 8 May 2009, Arthur W Cater wrote: > As I mentioned in March, I have a similar problem with errors occurring on other threads, > in my case often threads other than the Event?thread. > I'm told to type (:Y 8) ? eg ? but neither the Listener nor the AltConsole does anything > when I do so. A simple example of this is with > > (process-run-function "Breaker" #'(lambda nil (break "Talk to me"))) > > The Event thread still runs, but there is no way afaik of getting any > debugging info, not even a simple backtrace. > > Arthur > Yuck. Let me see if I can explain what's going on here (though I agree that what's going on and what should/could be going on are different things.) When the lisp starts up, it initializes (global) values of the standard input and output stream variables. When run in a TTY environment or under Emacs, these streams are (usefully) connected to the process-wide standard input and output devices (pipes or sockets or terminal-like devices). When a GUI application is launched on OSX, the devices to which these streams are connected aren't appropriate for interactive I/O; when the CCL IDE starts up, it tries to reconnect these streams to devices that talk to the AltConsole application (which at least provides a primitive way of doing interactive I/O.) When the (non-GUI) CCL starts up, a listener thread is created that uses these standard streams (and can therefore talk to a Terminal window, Emacs, etc.) The listener thread is marked as being the "owner" of the global standard input stream (since it's expected to make heavy use of that stream, to run the REPL, etc.) If some background thread needs to do input from that stream, it announces that fact and advises us to type (:y ); in the listener, we have to ensure that we're talking to the REPL (either at top level or in a break loop) and type that command in order to (temporarily) transfer the exclusive right to use that global input stream to the background thread. If the listener thread isn't in the REPL, we generally have to wait until it is or interrupt it to get it to that point before typing (:Y ) will have the desired effect. When the IDE starts up, the initial thread is marked as the owner of the global input stream (connected to AltConsole). When listener windows are created in the IDE, the listener threads that are created at the same time arrange to use interactive streams connected to that listener window (and its buffer.) If a background thread is created, then by default it will try to use the global (AltConsole-based) interactive streams. (See below.) If that background thread needs to use the global input stream (owned by the initial/event thread), it'll print a message to that effect on its standard error or output stream (I forget which, but they'd both be associated with AltConsole) and wait for the input stream's owner to transfer ownership (via a :y command in a REPL). Of course, the input stream's owner is busy processing events isn't really running a REPL, so (as you noted) nothing really happens. If we were to keep this paradigm (background threads try to do emergency I/O using a shared input stream), then we'd presumably want to have some other means of doing the equivalent of :Y (a menu command or something) that wouldn're require the event thread to be at a REPL prompt. If you want to see what's going on here or need to handle this situation in an emergency in the short term, you can do: - in an IDE listener, do: ? (process-run-function "background" #'break) This should cause output to the AltConsole window, announcing that the background thread wants to enter a break loop and needs someone to type a :Y command to let it use the global input stream. (Of course, it's not the act of typing that command that transfers ownership, it's the act of a REPL running in the owning thread reading and processing that command that does the transfer.) The owning thread, of course, is busy processing events, so let's change that. - in the IDE listener, do: ? (process-interrupt ccl::*initial-process* #'break) There are several ways to refer to the initial process; sadly, I don't know of a way that involves exported names. Event processing should stop, and the initial process should have entered a break loop in the AltConsole window. In that break loop typing the appropriate :Y command will do the "ownership transfer" and let the background thread use the input stream for its break loop; exiting the break loop will restore control to the event thread (which will be in the break loop we forced it into from the IDE), and exiting from that break loop will allow the event thread to get back to processing events. That's all pretty horrible; it could be made slightly less horrible if there were some GUI object (a menu item or button or something somewhere) that avoided the need to enter a break loop to do the ownership transfer of the input stream, but ... well, there's no reason for a background thread to have to use the global AltConsole-based stream for incidental or other I/O: it could create a listener window ("on demand") if it needed to do I/O, or try to share an existing listener window, or (maybe) create its own AltConsole window, or any number or other things. (It's very hard to get the event thread to do event-driven I/O to and from a GUI window, but shouldn't be any harder for a random thread to do that than it is for a listener.) From stassats at gmail.com Fri May 8 05:14:05 2009 From: stassats at gmail.com (Stas Boukarev) Date: Fri, 08 May 2009 16:14:05 +0400 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: (Manuel Weikert's message of "Fri, 8 May 2009 10:31:20 +0200") References: Message-ID: <87prejbxma.fsf@gmail.com> Manuel Weikert writes: > Hi there, > > sorry to bother you with this, but I couldn't find a solution for this > anywhere. A few days ago I installed ClozureCL on my mac. Everything > works fine but I find the Editor which comes with the IDE a little bit > inconvenient. So I decided to use Aquamacs instead. I made the > necessary adjustments to the configuration files but after a M-x slime > I got this: > > value 0 is not of the expected type CCL::CTYPE. > ?? [Condition of type TYPE-ERROR] > > Restarts: > ?0: [RETRY-LOAD] Retry loading #P"/Applications/ccl/tools/asdf.lisp" > [...some other output removed...] > > Despite all this and the fact that I can't load any packages the rest > works fine. > > Does anyone have any idea what sort of a stupid mistake a made? > Your slime is too old. I remember this was fixed some time ago. -- With best regards, Stas. From stoye at stoye.com Fri May 8 07:06:23 2009 From: stoye at stoye.com (R.Stoye) Date: Fri, 8 May 2009 16:06:23 +0200 Subject: [Openmcl-devel] Some problems with ccl/slime/aquamacs In-Reply-To: <87prejbxma.fsf@gmail.com> References: <87prejbxma.fsf@gmail.com> Message-ID: <60F663AA-45D2-445C-AF51-E22A5ED2E975@stoye.com> Greetings, recently i had some problems using slime: 1) Sometimes when you try to "go to definition" (option-.) on a method, i get the error "not a source-note". this isn't slimes fault, it is the compiler failing to record source- notes under certan conditions, see http://trac.clozure.com/openmcl/ticket/469 for a description (no workaround since i have no clue what's going on) 2) Another bug preventing the use of "who-calls" on methods, is due to wrong arguments to find-applicable-methods, see http://trac.clozure.com/openmcl/ticket/468 for a description and workaround. (version information: ccl 1.3-r11936 DarwinX8664 and 1.3-RC1-r11804 LinuxX8632, slime-2009-05-02 and slime-2009-03-18) Regards Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur.cater at ucd.ie Fri May 8 07:21:19 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Fri, 08 May 2009 15:21:19 +0100 Subject: [Openmcl-devel] debugging debugging In-Reply-To: <20090508041825.O41243@abq.clozure.com> References: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> <20090508041825.O41243@abq.clozure.com> Message-ID: Thank you Gary. I've now put into my ccl-init.lisp the line ?? (defun cl-user::yield () (process-interrupt ccl::*initial-process* #'break)) which will give me an easily remembered workaround. As I now understand it, perhaps wrongly, the Listener does run a REPL but not in the appropriate thread. The break loop in *initial-process* responds to :Y by executing code. Idea: could the Listener?thread not respond to :Y by causing that code to be executed in the initial process? Perhaps only when it is not itself in a break loop? (If that's daft, feel free to say so!) Arthur ----- Original Message ----- From: Gary Byers Date: Friday, May 8, 2009 12:26 pm Subject: Re: [Openmcl-devel] debugging debugging To: Arthur W Cater Cc: openmcl-devel Devel > > > On Fri, 8 May 2009, Arthur W Cater wrote: > > > As I mentioned in March, I have a similar problem with errors > occurring on other threads, > > in my case often threads other than the Event?thread. > > I'm told to type (:Y 8) ? eg ? but neither the Listener nor > the AltConsole does anything > > when I do so. A simple example of this is with > > > > (process-run-function "Breaker" #'(lambda nil (break "Talk to me"))) > > > > The Event thread still runs, but there is no way afaik of > getting any > > debugging info, not even a simple backtrace. > > > > Arthur > > > > Yuck.? Let me see if I can explain what's going on here > (though I agree that > what's going on and what should/could be going on are different > things.) > When the lisp starts up, it initializes (global) values of the > standard input > and output stream variables.? When run in a TTY environment > or under Emacs, > these streams are (usefully) connected to the process-wide > standard input > and output devices (pipes or sockets or terminal-like > devices).? When a GUI > application is launched on OSX, the devices to which these > streams are connected > aren't appropriate for interactive I/O; when the CCL IDE starts > up, it tries > to reconnect these streams to devices that talk to the > AltConsole application > (which at least provides a primitive way of doing interactive I/O.) > > When the (non-GUI) CCL starts up, a listener thread is created > that uses > these standard streams (and can therefore talk to a Terminal > window, Emacs, etc.) > The listener thread is marked as being the "owner" of the global > standard input > stream (since it's expected to make heavy use of that stream, to > run the REPL, > etc.)? If some background thread needs to do input from > that stream, it announces > that fact and advises us to type (:y ); in the listener, > we have to ensure > that we're talking to the REPL (either at top level or in a > break loop) and type > that command in order to (temporarily) transfer the exclusive > right to use that > global input stream to the background thread. > > If the listener thread isn't in the REPL, we generally have to > wait until it > is or interrupt it to get it to that point before typing (:Y > ) will have > the desired effect. > > When the IDE starts up, the initial thread is marked as the > owner of the global > input stream (connected to AltConsole).? When listener > windows are created in > the IDE, the listener threads that are created at the same time > arrange to use > interactive streams connected to that listener window (and its > buffer.)? If > a background thread is created, then by default it will try to > use the global > (AltConsole-based) interactive streams.? (See below.) > > If that background thread needs to use the global input stream (owned > by the initial/event thread), it'll print a message to that > effect on > its standard error or output stream (I forget which, but they'd both > be associated with AltConsole) and wait for the input stream's owner > to transfer ownership (via a :y command in a REPL).? Of course, > the input stream's owner is busy processing events isn't really > runninga REPL, so (as you noted) nothing really happens. > > If we were to keep this paradigm (background threads try to do > emergencyI/O using a shared input stream), then we'd presumably > want to have some > other means of doing the equivalent of :Y (a menu command or > something)that wouldn're require the event thread to be at a > REPL prompt.? If you > want to see what's going on here or need to handle this > situation in an > emergency in the short term, you can do: > > - in an IDE listener, do: > > ? (process-run-function "background" #'break) > > This should cause output to the AltConsole window, announcing > that the background > thread wants to enter a break loop and needs someone to type a > :Y command to let > it use the global input stream.? (Of course, it's not the > act of typing that > command that transfers ownership, it's the act of a REPL running > in the owning > thread reading and processing that command that does the > transfer.)? The owning > thread, of course, is busy processing events, so let's change that. > > - in the IDE listener, do: > > ? (process-interrupt ccl::*initial-process* #'break) > > There are several ways to refer to the initial process; sadly, I > don't know > of a way that involves exported names. > > Event processing should stop, and the initial process should > have entered a > break loop in the AltConsole window.? In that break loop > typing the appropriate > :Y command will do the "ownership transfer" and let the > background thread use > the input stream for its break loop; exiting the break loop will > restore control > to the event thread (which will be in the break loop we forced > it into from the > IDE), and exiting from that break loop will allow the event > thread to get back > to processing events. > > That's all pretty horrible; it could be made slightly less > horrible if > there were some GUI object (a menu item or button or something > somewhere) that avoided the need to enter a break loop to do the > ownership transfer of the input stream, but ... well, there's no > reason for a background thread to have to use the global > AltConsole-based stream for incidental or other I/O: it could > create a > listener window ("on demand") if it needed to do I/O, or try to share > an existing listener window, or (maybe) create its own AltConsole > window, or any number or other things.? (It's very hard to > get the > event thread to do event-driven I/O to and from a GUI window, > but shouldn't > be any harder for a random thread to do that than it is for a > listener.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reitter at cmu.edu Fri May 8 09:17:50 2009 From: reitter at cmu.edu (David Reitter) Date: Fri, 8 May 2009 12:17:50 -0400 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: <87prejbxma.fsf@gmail.com> References: <87prejbxma.fsf@gmail.com> Message-ID: <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> On May 8, 2009, at 8:14 AM, Stas Boukarev wrote: >> >> Does anyone have any idea what sort of a stupid mistake a made? >> > > Your slime is too old. I remember this was fixed some time ago. So you want to use the latest Aquamacs release along with a recent build of SLIME, both available as point-and-click installers from http://aquamacs.org . From manuel.weikert at googlemail.com Fri May 8 12:21:48 2009 From: manuel.weikert at googlemail.com (Manuel Weikert) Date: Fri, 8 May 2009 21:21:48 +0200 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> Message-ID: 2009/5/8 David Reitter : > > So you want to use the latest Aquamacs release along with a recent build of > SLIME, both available as point-and-click installers from > http://aquamacs.org. > Hmmm... I have brand new versions of Aquamacs and Slime. Both downloaded from aquamacs.org a few days ago. But I had an older Version running before, so I erased all available files belonging to Aquamacs and Slime and installed it again. Result: the same error... The website says that the version of Slime available for download works fine with OpenMCL... Well, not for me... From danieldickison at gmail.com Fri May 8 12:31:21 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Fri, 8 May 2009 15:31:21 -0400 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> Message-ID: <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> I can say for sure that the latest CCL 1.3 from SVN with the latest SLIME from CVS and Aquamacs 1.7 definitely works for me, on an Intel Mac (64-bit). I have slime checked out to ~/src/slime, and I have this in my Aquamacs Preferences.el file: (add-to-list 'load-path "~/src/slime") (require 'slime) (set-language-environment "UTF-8") (setq slime-net-coding-system 'utf-8-unix) (slime-setup '(slime-fancy slime-xref-browser)) I normally start swank from the command line and connect to it from Aquamacs, and the shell script I have for starting swank looks like: ccl -l "$HOME/src/slime/swank-loader.lisp" \ -e '(swank-loader:init :load-contribs t)' \ -e '(swank:create-server :coding-system "utf-8")' \ $@ It took me a while to figure out the :load-contribs t thing, but it seems to be necessary. Let me know if these don't work for you. I've tackled setting up CCL and SLIME on all sorts of ancient to new Macs so I can hopefully help. Including the backtrace from the error you encounter would help narrow it down. Daniel On May 8, 2009, at 3:21 PM, Manuel Weikert wrote: > 2009/5/8 David Reitter : > >> >> So you want to use the latest Aquamacs release along with a recent >> build of >> SLIME, both available as point-and-click installers from >> http://aquamacs.org. >> > > Hmmm... I have brand new versions of Aquamacs and Slime. Both > downloaded from aquamacs.org a few days ago. But I had an older > Version running before, so I erased all available files belonging to > Aquamacs and Slime and installed it again. Result: the same error... > The website says that the version of Slime available for download > works fine with OpenMCL... Well, not for me... > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From rme at clozure.com Fri May 8 12:49:56 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Fri, 8 May 2009 15:49:56 -0400 Subject: [Openmcl-devel] signedness issue in %ffcall on ppc In-Reply-To: <8986e60905071107g3d000522p646ab3c904c0aad0@mail.gmail.com> References: <8986e60905071107g3d000522p646ab3c904c0aad0@mail.gmail.com> Message-ID: On May 7, 2009, at 2:07 PM, Julian Squires wrote: > Given the following example: > > (asdf:oos 'asdf:load-op :cffi) > (cffi:defcfun "srandom" :void (seed :unsigned-int)) > (srandom #x80000000) (#_srandom #x80000000) also showed the same behavior. > with Clozure Common Lisp Version 1.3-r11936 (LinuxPPC32) I receive > the following error: > >> Error: value 2147483648 is not of the expected type (SIGNED-BYTE 32). >> While executing: %FF-CALL, in process listener(1). > > The attached patch (to level-0/PPC/ppc-def.lisp) appears to correct > this issue. Thanks. This bug should be fixed in both the trunk and in the 1.3 release branch as of r12019. From gb at clozure.com Fri May 8 12:51:17 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 8 May 2009 13:51:17 -0600 (MDT) Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> Message-ID: <20090508132630.A51110@abq.clozure.com> I don't use Aquamacs or Slime regularly, but I just downloaded what seemed to be the latest Aquamacs (1.7) from aquamacs.org, did M-: (setq inferior-lisp-program "/path/to/ccl64") and M-x slime , and it told me that it had no idea what slime was. I looked around inside the application bundle and didn't see anything that looked like it was part of slime, which suggests that Aquamacs is (no longer ?) bundling slime. Daniel's message (which arrived as I was typing this) suggests that he uses a slime checked out from the slime project's CVS (or whatever they use) tree. If you're still getting the same error you were getting before and slime isn't part of Aquamacs, that suggests that you still have an old (and perhaps buggy) version of slime on Aquamacs' load path somewhere. IIRC, you may be able to do something like M-x find-load-file slime to have Emacs tell you where it's finding the slime that it's finding. On Fri, 8 May 2009, Manuel Weikert wrote: > 2009/5/8 David Reitter : > >> >> So you want to use the latest Aquamacs release along with a recent build of >> SLIME, both available as point-and-click installers from >> http://aquamacs.org. >> > > Hmmm... I have brand new versions of Aquamacs and Slime. Both > downloaded from aquamacs.org a few days ago. But I had an older > Version running before, so I erased all available files belonging to > Aquamacs and Slime and installed it again. Result: the same error... > The website says that the version of Slime available for download > works fine with OpenMCL... Well, not for me... > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From rme at clozure.com Fri May 8 13:03:17 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Fri, 8 May 2009 16:03:17 -0400 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> Message-ID: <94C6FBF2-CBFC-4603-871D-2F396978BC91@clozure.com> On May 8, 2009, at 3:31 PM, Daniel Dickison wrote: > I have slime checked out to ~/src/slime, and I have this in my > Aquamacs Preferences.el file: > > (add-to-list 'load-path "~/src/slime") > (require 'slime) > (set-language-environment "UTF-8") > (setq slime-net-coding-system 'utf-8-unix) > (slime-setup '(slime-fancy slime-xref-browser)) > > > I normally start swank from the command line and connect to it from > Aquamacs, and the shell script I have for starting swank looks like: > > ccl -l "$HOME/src/slime/swank-loader.lisp" \ > -e '(swank-loader:init :load-contribs t)' \ > -e '(swank:create-server :coding-system "utf-8")' \ > $@ > > It took me a while to figure out the :load-contribs t thing, but it > seems to be necessary. In some circumstances, one might also need/want to specify -K utf-8 when starting up CCL. The default encoding is iso-8859-1. (This sets the encoding for *terminal-io*.) I'm kind of a SLIME caveman, so if anyone would care to improve the "how to install SLIME" on the Trac wiki, that'd be welcome. http://trac.clozure.com/openmcl/wiki/InstallingSlime From reitter at cmu.edu Fri May 8 13:23:27 2009 From: reitter at cmu.edu (David Reitter) Date: Fri, 8 May 2009 16:23:27 -0400 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: <20090508132630.A51110@abq.clozure.com> References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> <20090508132630.A51110@abq.clozure.com> Message-ID: On May 8, 2009, at 3:51 PM, Gary Byers wrote: > , and it told me that it had no idea what slime was. I looked > around inside the application bundle and didn't see anything > that looked like it was part of slime, which suggests that > Aquamacs is (no longer ?) bundling slime. That's correct, as SLIME developers refuse to offer stable releases and as SLIME seems to need constant massaging to fit the current versions of various Lisp implementations, it is no longer part of Aquamacs. Instead, we supply SLIME as a separate plugin which comes in a point-and-click installer and is built from the SLIME CVS every night. > If you're still getting the same error you were getting before > and slime isn't part of Aquamacs, that suggests that you still > have an old (and perhaps buggy) version of slime on Aquamacs' > load path somewhere. IIRC, you may be able to do something like > > M-x find-load-file slime > > to have Emacs tell you where it's finding the slime that it's > finding. What works for me is M-x locate-library RET slime RET. If it returns /Library/Application Support/Aquamacs Emacs/SLIME/slime.el, it is using the plugin. Btw, I use this with openmcl Version 1.2-r11300M (DarwinX8664) and I haven't had any problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2438 bytes Desc: not available URL: From john at mcaleely.com Fri May 8 13:42:17 2009 From: john at mcaleely.com (John McAleely) Date: Fri, 8 May 2009 21:42:17 +0100 Subject: [Openmcl-devel] wiki editing In-Reply-To: <94C6FBF2-CBFC-4603-871D-2F396978BC91@clozure.com> References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> <94C6FBF2-CBFC-4603-871D-2F396978BC91@clozure.com> Message-ID: <08AB57CD-2257-4BCF-9AC4-CE081C0291DB@mcaleely.com> > I'm kind of a SLIME caveman, so if anyone would care to improve the > "how to install SLIME" on the Trac wiki, that'd be welcome. Is the wiki open to anyone to edit? I've tried to open/register an account a couple of times and not had any indication of success. J From ron at awun.net Fri May 8 14:00:24 2009 From: ron at awun.net (Ron Garret) Date: Fri, 8 May 2009 14:00:24 -0700 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: <87prejbxma.fsf@gmail.com> References: <87prejbxma.fsf@gmail.com> Message-ID: On May 8, 2009, at 5:14 AM, Stas Boukarev wrote: > Your slime is too old. Now there is a comment which, taken out of context, should strike fear into the hear of any newcomer. ;-) ;-) ;-) rg From rme at clozure.com Fri May 8 14:04:49 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Fri, 8 May 2009 17:04:49 -0400 Subject: [Openmcl-devel] wiki editing In-Reply-To: <08AB57CD-2257-4BCF-9AC4-CE081C0291DB@mcaleely.com> References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> <94C6FBF2-CBFC-4603-871D-2F396978BC91@clozure.com> <08AB57CD-2257-4BCF-9AC4-CE081C0291DB@mcaleely.com> Message-ID: On May 8, 2009, at 4:42 PM, John McAleely wrote: >> I'm kind of a SLIME caveman, so if anyone would care to improve the >> "how to install SLIME" on the Trac wiki, that'd be welcome. > > Is the wiki open to anyone to edit? I've tried to open/register an > account a couple of times and not had any indication of success. To edit wiki pages or make tickets, you have to register. Registration is open to everyone interested in CCL; the registration requirement is only there to try to keep the legions of spammers at bay. To register, just click on the Register link, fill it out, and submit it. You won't get a confirmation email or anything. You now have a Trac account. Click the Login link, sign in, and edit away. From john at mcaleely.com Fri May 8 14:23:02 2009 From: john at mcaleely.com (John McAleely) Date: Fri, 8 May 2009 22:23:02 +0100 Subject: [Openmcl-devel] wiki editing In-Reply-To: References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> <94C6FBF2-CBFC-4603-871D-2F396978BC91@clozure.com> <08AB57CD-2257-4BCF-9AC4-CE081C0291DB@mcaleely.com> Message-ID: <7AB99A5E-A461-4959-8433-C667BAA0FDD0@mcaleely.com> On 8 May 2009, at 22:04, R. Matthew Emerson wrote: > To edit wiki pages or make tickets, you have to register. > Registration is open to everyone interested in CCL; the > registration requirement is only there to try to keep the legions of > spammers at bay. > > To register, just click on the Register link, fill it out, and > submit it. You won't get a confirmation email or anything. You now > have a Trac account. Click the Login link, sign in, and edit away. My brain was clearly in need of a wetware upgrade on previous occasions. That just worked like a charm. Thank you. J From manuel.weikert at googlemail.com Fri May 8 15:09:07 2009 From: manuel.weikert at googlemail.com (Manuel Weikert) Date: Sat, 9 May 2009 00:09:07 +0200 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> Message-ID: 2009/5/8 Daniel Dickison : > I have slime checked out to ~/src/slime, and I have this in my Aquamacs > Preferences.el file: > > (add-to-list 'load-path "~/src/slime") > (require 'slime) > (set-language-environment "UTF-8") > (setq slime-net-coding-system 'utf-8-unix) > (slime-setup '(slime-fancy slime-xref-browser)) > Well, this seems to work fine. THANKS! Believe it or not, the only thing I changed in my setup was the last line. *wtf* ?!? So - no more errors, but I still have this package problem. (find-package :easygui-user) returns NIL. Manu From danieldickison at gmail.com Fri May 8 15:15:13 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Fri, 8 May 2009 18:15:13 -0400 Subject: [Openmcl-devel] Using OpenMCL with Aquamacs + Slime doesn't work In-Reply-To: References: <87prejbxma.fsf@gmail.com> <61ADDF17-7E37-433D-B8D8-18372D7CE946@cmu.edu> <2B5D1CF3-B746-460B-B6EB-764297896DDB@gmail.com> Message-ID: <726EFB31-0176-4136-94F8-94CE1C930C88@gmail.com> I don't follow slime development, but it seems like there has been a tendency to move functionality into contrib optional modules. I've occasionally had to add items to the list of modules to load to keep things working. Sent from my iPhone On May 8, 2009, at 18:09, Manuel Weikert wrote: > 2009/5/8 Daniel Dickison : > >> I have slime checked out to ~/src/slime, and I have this in my >> Aquamacs >> Preferences.el file: >> >> (add-to-list 'load-path "~/src/slime") >> (require 'slime) >> (set-language-environment "UTF-8") >> (setq slime-net-coding-system 'utf-8-unix) >> (slime-setup '(slime-fancy slime-xref-browser)) >> > > Well, this seems to work fine. THANKS! Believe it or not, the only > thing I changed in my setup was the last line. *wtf* ?!? > > So - no more errors, but I still have this package problem. > (find-package :easygui-user) returns NIL. > > Manu > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From lisp at clairvaux.org Fri May 8 15:19:06 2009 From: lisp at clairvaux.org (Glen Foy) Date: Fri, 8 May 2009 18:19:06 -0400 Subject: [Openmcl-devel] debugging debugging In-Reply-To: References: <8F45A1EE-CB6A-447E-B46A-313222045B2A@cs.colorado.edu> <20090507151509.B41243@abq.clozure.com> Message-ID: <359FC6AE-B023-4A01-BF00-5ECA72CA578B@clairvaux.org> On May 7, 2009, at 8:51 PM, Glen Foy wrote: > > On May 7, 2009, at 8:00 PM, Andrew Shalit wrote: > >> It would still run as a separate application, but it could >> communicate >> with the CCL via something akin to a Slime/Swank protocol, and it >> could present things like backtraces and inspector windows in nice >> Macintosh windows. It would even be theoretically possible to reuse >> some of the CCL IDE code for this purpose. (I'm not familiar with >> that code enough to know whether that's a practical approach.) > > Possibly just launch a second CCL image with a customized menu for > debugging? > > The two could communicate via a socket as in Slime/Swank. Here's a possible approach: Instead of launching another CCL Image in the event of an error, make the IDE a separate application from the start. It would include Hemlock, the Backtrace dialog, the Inspector and various other tools. The IDE would never run code itself. It would communicate with a separate Lisp process using something like the Slime/Swank protocol. It the event of an error the Lisp doing the work could sit happily in its break loop, while the IDE managed events and displayed the debugging tools. And there is no reason for the IDE to be strictly CCL. It could, in fact, be a Cocoa based Slime, supporting various Lisps and even Schemes. From sky at viridian-project.de Sun May 10 13:56:04 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 10 May 2009 22:56:04 +0200 (CEST) Subject: [Openmcl-devel] (#_ _exit 0) on triple EOD Message-ID: This seems a bit crude; there are multiple ways that CCL may exit, but this way the user application cannot easily (portably) set up hooks for it. I seems as if triple EOD was meant to be an emergency exit, but personally I use it all the time as a convenient manner of quitting, which is also in line with EOD's usual connotations. FWIW, SBCL handles EOD gracefully (calling its exit hooks) and instead provides a :RECKLESSLY-P arg to its QUIT function that makes it possible to force an immediate exit. Leslie -- http://www.linkedin.com/in/polzer From rme at clozure.com Sun May 10 17:19:10 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Sun, 10 May 2009 20:19:10 -0400 Subject: [Openmcl-devel] (#_ _exit 0) on triple EOD In-Reply-To: References: Message-ID: On May 10, 2009, at 4:56 PM, Leslie P. Polzer wrote: > This seems a bit crude; there are multiple ways that CCL may exit, > but this way the user application cannot easily (portably) > set up hooks for it. > > I seems as if triple EOD was meant to be an emergency exit, but > personally I use it all the time as a convenient manner of > quitting, which is also in line with EOD's usual connotations. > > FWIW, SBCL handles EOD gracefully (calling its exit hooks) > and instead provides a :RECKLESSLY-P arg to its QUIT function > that makes it possible to force an immediate exit. If you like to use ^D as a way to quit the lisp, you can do that by setting ccl:*quit-on-eof* to T in your ccl-init.lisp file. The "quit on triple eof" is there to try to keep this lisp from going berserk in certain circumstances; see http://trac.clozure.com/openmcl/changeset/11594 From sky at viridian-project.de Mon May 11 00:37:36 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Mon, 11 May 2009 09:37:36 +0200 (CEST) Subject: [Openmcl-devel] (#_ _exit 0) on triple EOD In-Reply-To: References: Message-ID: <70511f19d3ac3e81ac21cf6f1af9bd41.squirrel@mail.stardawn.org> R. Matthew Emerson wrote: > If you like to use ^D as a way to quit the lisp, you can do that by > setting ccl:*quit-on-eof* to T in your ccl-init.lisp file. Yes, I am aware of that tweak switch; however this time I'm more concerned about the reliability of exit hooks as they are used in two of the libraries I'm working on. > The "quit on triple eof" is there to try to keep this lisp from going > berserk in certain circumstances; see > > http://trac.clozure.com/openmcl/changeset/11594 But why does it have to use _exit? Or, as an alternative approach: can't the IDE set *quit-on-eof* to NIL, with the default being T? Leslie -- http://www.linkedin.com/in/polzer From steve.nunez at illation.com.sg Mon May 11 01:40:16 2009 From: steve.nunez at illation.com.sg (Steve =?ISO-8859-1?B?TvrxZXo=?=) Date: Mon, 11 May 2009 18:40:16 +1000 Subject: [Openmcl-devel] AppleScript Message-ID: G?Day Gentlemen, What?s the ?state of the art? for interfacing with Carbon applications exposing only an AppleScript interface? I found one possibility mentioned here: http://www.clozure.com/pipermail/openmcl-devel/2008-October/008618.html But this seems applicable only to Cocoa applications. There?s also cl-applescript: http://common-lisp.net/project/cl-applescript/ But that project appears to have been abandoned. I?m trying to determine the feasibility of heavily customising MS Entourage, and would like to use CCL for most of the heavy lifting. Regards, - Steve -- Level 31 6 Battery Road Singapore 049909 Phone: ?+65 6321 9115 Mobile: +65 9679 8360 http://illation.com.sg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.gif Type: image/gif Size: 945 bytes Desc: not available URL: From danieldickison at gmail.com Mon May 11 07:00:29 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Mon, 11 May 2009 10:00:29 -0400 Subject: [Openmcl-devel] AppleScript In-Reply-To: References: Message-ID: I'm the author of cl-applescript, and you're right that it has been pretty much abandoned (the project I had originally wrote that library for went defunct). However, I believe it still works if you only have simple AppleScript needs, with the following caveats: 1. All AS is executed using the osascript command line interface, which means: a. You can't construct AppleEvents programatically (you need to construct script strings). b. Every call has to compile the AppleScript from scratch, which is slow. c. The entire return value is stored as a string before parsing, so you wouldn't want to do huge queries. 2. Parsing dictionaries hasn't been implemented. The patch for CCL bug 216 should no longer be necessary if you're using CCL 1.3 (I should update that page). If you would like to use the library but you need dictionary parsing, I think it should be pretty easy to implement and I'll be happy to help you with that. That said, Scripting Bridge is probably the way to go. You'll be writing Cocoa code (presumably via the Clozure Objective-C bridge), but I believe you can use it to script any application, regardless of whether it's Cocoa or Carbon. Daniel On May 11, 2009, at 4:40 AM, Steve N??ez wrote: > G?Day Gentlemen, > > What?s the ?state of the art? for interfacing with Carbon > applications exposing only an AppleScript interface? I found one > possibility mentioned here: > > http://www.clozure.com/pipermail/openmcl-devel/2008-October/ > 008618.html > > But this seems applicable only to Cocoa applications. There?s also > cl-applescript: > > http://common-lisp.net/project/cl-applescript/ > > But that project appears to have been abandoned. I?m trying to > determine the feasibility of heavily customising MS Entourage, and > would like to use CCL for most of the heavy lifting. > > Regards, > - Steve > > -- > > Level 31 > 6 Battery Road > Singapore 049909 > > Phone: +65 6321 9115 > Mobile: +65 9679 8360 > http://illation.com.sg > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From steve.nunez at illation.com.sg Mon May 11 15:17:17 2009 From: steve.nunez at illation.com.sg (Steve =?ISO-8859-1?B?TvrxZXo=?=) Date: Tue, 12 May 2009 08:17:17 +1000 Subject: [Openmcl-devel] AppleScript In-Reply-To: Message-ID: Thanks. Has anyone looked at F-Script? I discovered it while looking around for ways I might script this application. I don't have any experience with it, but it looks interesting: http://www.fscript.org/ - Steve On 12/05/09 12:00 AM, "Daniel Dickison" wrote: > I'm the author of cl-applescript, and you're right that it has been > pretty much abandoned (the project I had originally wrote that library > for went defunct). However, I believe it still works if you only have > simple AppleScript needs, with the following caveats: > 1. All AS is executed using the osascript command line interface, > which means: > a. You can't construct AppleEvents programatically (you need to > construct script strings). > b. Every call has to compile the AppleScript from scratch, which is > slow. > c. The entire return value is stored as a string before parsing, so > you wouldn't want to do huge queries. > 2. Parsing dictionaries hasn't been implemented. > > The patch for CCL bug 216 should no longer be necessary if you're > using CCL 1.3 (I should update that page). If you would like to use > the library but you need dictionary parsing, I think it should be > pretty easy to implement and I'll be happy to help you with that. > > That said, Scripting Bridge is probably the way to go. You'll be > writing Cocoa code (presumably via the Clozure Objective-C bridge), > but I believe you can use it to script any application, regardless of > whether it's Cocoa or Carbon. > > Daniel > > > On May 11, 2009, at 4:40 AM, Steve N??ez wrote: > >> G?Day Gentlemen, >> >> What?s the ?state of the art? for interfacing with Carbon >> applications exposing only an AppleScript interface? I found one >> possibility mentioned here: >> >> http://www.clozure.com/pipermail/openmcl-devel/2008-October/ >> 008618.html >> >> But this seems applicable only to Cocoa applications. There?s also >> cl-applescript: >> >> http://common-lisp.net/project/cl-applescript/ >> >> But that project appears to have been abandoned. I?m trying to >> determine the feasibility of heavily customising MS Entourage, and >> would like to use CCL for most of the heavy lifting. >> >> Regards, >> - Steve >> >> -- >> >> Level 31 >> 6 Battery Road >> Singapore 049909 >> >> Phone: +65 6321 9115 >> Mobile: +65 9679 8360 >> http://illation.com.sg >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > -- Level 31 6 Battery Road Singapore 049909 Phone: ?+65 6321 9115 Mobile: +65 9679 8360 http://illation.com.sg From raffaelcavallaro at mac.com Mon May 11 23:08:17 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Tue, 12 May 2009 02:08:17 -0400 Subject: [Openmcl-devel] AppleScript In-Reply-To: References: Message-ID: <94601215-1F13-4708-9141-A214052F0C1C@mac.com> On May 11, 2009, at 6:17 PM, Steve N??ez wrote: > Has anyone looked at F-Script? I discovered it while looking around > for ways > I might script this application. I don't have any experience with > it, but it > looks interesting: It's useful in the same way AppleScript is - it lets you hook into existing Cocoa applications from the inside. Other than that though, the last time I used it it was pretty slow for anything compute intensive. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From arthur.cater at ucd.ie Tue May 12 04:02:05 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Tue, 12 May 2009 12:02:05 +0100 Subject: [Openmcl-devel] Cocoa IDE and :RETURN-FROM-FRAME debugger command Message-ID: Hello, I do not understand here how (in Cocoa IDE, Alt-Console debug session) there does and yet does not seem to be a function :RETURN-FROM-FRAME I've never used that command before, hence some syntactic fumbling, but this seems very odd and I wonder if anyone can shed light on a) how I should use it b) how come it is undefined yet knows how many args it expects Arthur 1 > (:return-from-frame 1 nil) > Error: Undefined function CCL::RETURN-FROM-FRAME called with arguments (-65822028 NIL) . > While executing: CCL::CHECK-TOPLEVEL-COMMAND, in process Eval-Queue(7). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Retry applying CCL::RETURN-FROM-FRAME to (-65822028 NIL). > Type :? for other options. 2 > :pop 1 > :return-from-frame > Error: Too few arguments in call to #: > ? ? ? ?0 arguments provided, at least 1 required.? > While executing: CCL::RETURN-FROM-FRAME, in process Eval-Queue(7). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 2 > :pop 1 > :return-from-frame 1 nil > Error: Undefined function CCL::RETURN-FROM-FRAME called with arguments (-65822028 NIL) . > While executing: CCL::CHECK-TOPLEVEL-COMMAND, in process Eval-Queue(7). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Retry applying CCL::RETURN-FROM-FRAME to (-65822028 NIL). > Type :? for other options. 2 >? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dherring at tentpost.com Tue May 12 05:32:17 2009 From: dherring at tentpost.com (dherring at tentpost.com) Date: Tue, 12 May 2009 08:32:17 -0400 (EDT) Subject: [Openmcl-devel] wx86cl on international systems Message-ID: <6406ba82311f2d36c2755c14d4388fa8.squirrel@webmail.tentpost.com> FWIW, clozure is very unhappy if installed in a path containing non-ascii characters. In cmd.exe, I cd to c:\cclㅁ (c:\cclM where M is the square Korean character; any Korean characters in the path have this effect) and run C:\cclㅁ>wx86cl.exe > log.txt The head of log.txt follows, with a very large number of recursive-lock errors elided. > Error: value NIL is not of the expected type (OR STRING PATHNAME STREAM). > While executing: PATHNAME-DIRECTORY, in process Initial(0). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Skip (possibly crucial) startup function CCL::INIT-LOGICAL-DIRECTORIES. > Type :? for other options. > Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK. > While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0). > Type :POP to abort, :R for a list of available restarts. > Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK. > While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0). > Type :POP to abort, :R for a list of available restarts. ... This is the 1.3 release tarball running on a Korean Windows XP system. Later, Daniel From gb at clozure.com Tue May 12 08:19:04 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 12 May 2009 09:19:04 -0600 (MDT) Subject: [Openmcl-devel] AppleScript In-Reply-To: References: Message-ID: <20090511192210.C66933@abq.clozure.com> There was an F-Script<->OpenMCL interface once upon a time: There was also a way of compiling and executing AppleScript (without running an external program.) I suspect that the stuff that I'm thinking about is what's described at: I don't think that there was ever any kind of high-level interface to this in CCL (at least none that I know of), but IIRC it wasn't -that- bad to just use the FFI (for some value of "not bad".) On Tue, 12 May 2009, Steve N??ez wrote: > Thanks. > > Has anyone looked at F-Script? I discovered it while looking around for ways > I might script this application. I don't have any experience with it, but it > looks interesting: > > http://www.fscript.org/ > > - Steve > > On 12/05/09 12:00 AM, "Daniel Dickison" wrote: > >> I'm the author of cl-applescript, and you're right that it has been >> pretty much abandoned (the project I had originally wrote that library >> for went defunct). However, I believe it still works if you only have >> simple AppleScript needs, with the following caveats: >> 1. All AS is executed using the osascript command line interface, >> which means: >> a. You can't construct AppleEvents programatically (you need to >> construct script strings). >> b. Every call has to compile the AppleScript from scratch, which is >> slow. >> c. The entire return value is stored as a string before parsing, so >> you wouldn't want to do huge queries. >> 2. Parsing dictionaries hasn't been implemented. >> >> The patch for CCL bug 216 should no longer be necessary if you're >> using CCL 1.3 (I should update that page). If you would like to use >> the library but you need dictionary parsing, I think it should be >> pretty easy to implement and I'll be happy to help you with that. >> >> That said, Scripting Bridge is probably the way to go. You'll be >> writing Cocoa code (presumably via the Clozure Objective-C bridge), >> but I believe you can use it to script any application, regardless of >> whether it's Cocoa or Carbon. >> >> Daniel >> >> >> On May 11, 2009, at 4:40 AM, Steve N??ez wrote: >> >>> G?Day Gentlemen, >>> >>> What?s the ?state of the art? for interfacing with Carbon >>> applications exposing only an AppleScript interface? I found one >>> possibility mentioned here: >>> >>> http://www.clozure.com/pipermail/openmcl-devel/2008-October/ >>> 008618.html >>> >>> But this seems applicable only to Cocoa applications. There?s also >>> cl-applescript: >>> >>> http://common-lisp.net/project/cl-applescript/ >>> >>> But that project appears to have been abandoned. I?m trying to >>> determine the feasibility of heavily customising MS Entourage, and >>> would like to use CCL for most of the heavy lifting. >>> >>> Regards, >>> - Steve >>> >>> -- >>> >>> Level 31 >>> 6 Battery Road >>> Singapore 049909 >>> >>> Phone: +65 6321 9115 >>> Mobile: +65 9679 8360 >>> http://illation.com.sg >>> >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> > > -- > > Level 31 > 6 Battery Road > Singapore 049909 > > Phone: ?+65 6321 9115 > Mobile: +65 9679 8360 > http://illation.com.sg > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From gb at clozure.com Tue May 12 10:51:26 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 12 May 2009 11:51:26 -0600 (MDT) Subject: [Openmcl-devel] Cocoa IDE and :RETURN-FROM-FRAME debugger command In-Reply-To: References: Message-ID: <20090512092139.O66933@abq.clozure.com> None of this has anything to do with Cocoa or the IDE; it does have to do with RETURN-FROM-FRAME not being globally defined on the PPC. On Tue, 12 May 2009, Arthur W Cater wrote: > Hello, > I do not understand here how (in Cocoa IDE, Alt-Console debug session) there does and > yet does not seem to be a function :RETURN-FROM-FRAME > I've never used that command before, hence some syntactic fumbling, but this seems very odd > and I wonder if anyone can shed light on > a) how I should use it If it was up to me, I'd say "don't". :RETURN-FROM-FRAME is supposed to allow you to transfer control from a break loop to some arbitrary point in program execution that likely never expected to have arbitrary code transfer control to it. Once in a while, that might work (and might be worth a try, if the alternative was to abandon a long-running computation because of some silly error.) > b) how come it is undefined yet knows how many args it expects The function that implements the :RETURN-FROM-FRAME break loop command happens to have a FUNCTION-NAME of RETURN-FROM-FRAME; that function is not the global function definition of CCL::RETURN-FROM-FRAME (on the PPC, there isn't such a thing) and so it prints as # That non-global function tries to call (via APPLY) the global function named RETURN-FROM-FRAME; we really should have gotten a compiler warning when compiling that on the PPC, since CCL::RETURN-FROM-FRAME isn't defined there. > > Arthur > > 1 > (:return-from-frame 1 nil) >> Error: Undefined function CCL::RETURN-FROM-FRAME called with arguments (-65822028 NIL) . >> While executing: CCL::CHECK-TOPLEVEL-COMMAND, in process Eval-Queue(7). >> Type :GO to continue, :POP to abort, :R for a list of available restarts. >> If continued: Retry applying CCL::RETURN-FROM-FRAME to (-65822028 NIL). >> Type :? for other options. > 2 > :pop > > 1 > :return-from-frame >> Error: Too few arguments in call to #: >> ? ? ? ?0 arguments provided, at least 1 required.? >> While executing: CCL::RETURN-FROM-FRAME, in process Eval-Queue(7). >> Type :POP to abort, :R for a list of available restarts. >> Type :? for other options. > 2 > :pop > > 1 > :return-from-frame 1 nil >> Error: Undefined function CCL::RETURN-FROM-FRAME called with arguments (-65822028 NIL) . >> While executing: CCL::CHECK-TOPLEVEL-COMMAND, in process Eval-Queue(7). >> Type :GO to continue, :POP to abort, :R for a list of available restarts. >> If continued: Retry applying CCL::RETURN-FROM-FRAME to (-65822028 NIL). >> Type :? for other options. > 2 >? > From kdj at sanger.ac.uk Tue May 12 13:39:55 2009 From: kdj at sanger.ac.uk (Keith James) Date: Tue, 12 May 2009 21:39:55 +0100 Subject: [Openmcl-devel] Error when setting a value in a matrix unless safety 3 Message-ID: Hi, I'm porting some of my libraries that were developed on SBCL and LispWorks. I'm experiencing an error that I can't explain when setting a value (a single-float) into a type-declared matrix of single floats. I've discovered that I can avoid the error by setting safety 3. The error message is value -5.0 is not of the expected type (SIMPLE-ARRAY DOUBLE-FLOAT (* *)) As the algorithm is very compute intensive (Smith-Waterman alignment), I would like to optimize for speed and slightly reduced safety. I have extracted the smallest self-contained example that I can, illustrating the problem. Most of the code has been macroexpanded, hence the odd variable names. I've commented the exact point of the error. Any suggestions would be much appreciated. I'm using Version 1.3-r11936 (LinuxX8664). Thanks! ;; Run (test-alignment "AACGTTTAATGTAC" "CGTTTGTAA" #'simple-dna-subst ;; -5.0f0 -1.0f0) (deftype array-index () "Array index type." '(and fixnum (integer 0 *))) (deftype path-pointer () "Dynamic programming backtrace pointer." '(unsigned-byte 2)) (defconstant +insertx+ 1 "Dynamic programming backtrace delete pointer.") (defconstant +inserty+ 2 "Dynamic programming backtrace insert pointer.") (defconstant +match+ 3 "Dynamic programming backtrace match pointer.") (defconstant +none+ 0 "Dynamic programming backtrace null pointer.") (defvar *simple-dna-matrix* (make-array '(5 5) :element-type 'single-float :initial-contents '(( 5.0f0 -4.0f0 -4.0f0 -4.0f0 -1.0f0) (-4.0f0 5.0f0 -4.0f0 -4.0f0 -1.0f0) (-4.0f0 -4.0f0 5.0f0 -4.0f0 -1.0f0) (-4.0f0 -4.0f0 -4.0f0 5.0f0 -1.0f0) (-1.0f0 -1.0f0 -1.0f0 -1.0f0 -1.0f0))) "A DNA substitution matrix for sequences containing the bases A, C, G, T and N.") (defun simple-dna-index (value) (declare (optimize (speed 3) (safety 1))) (declare (type base-char value)) (cond ((char= value #\A) 0) ((char= value #\C) 1) ((char= value #\G) 2) ((char= value #\T) 3) ((char= value #\N) 4) (t (error "invalid base ~a." value)))) (defun simple-dna-subst (x y) (aref *simple-dna-matrix* (simple-dna-index x) (simple-dna-index y))) (defun test-alignment (vecm vecn subst-fn gap-open gap-extend) ;; (declare (optimize (safety 3))) ; Success (declare (optimize (safety 2))) ; Fail ;; local fn to avoid boxing of returned floats (flet ((subn (x y) (funcall subst-fn x y))) (let ((m (length vecm)) (n (length vecn))) (let ((sc (make-array (list (1+ m) (1+ n)) :element-type 'single-float :initial-element 0.0)) (ix (make-array (list (1+ m) (1+ n)) :element-type 'single-float :initial-element 0.0)) (iy (make-array (list (1+ m) (1+ n)) :element-type 'single-float :initial-element 0.0)) (bt (make-array (list (1+ m) (1+ n)) :element-type 'path-pointer :initial-element 0))) (declare (type (simple-array single-float (* *)) sc ix iy) (type (simple-array path-pointer (* *)) bt)) (let ((var-g0 (array-dimension sc 0)) (var-g1 (array-dimension sc 1)) (max-score 0.0) (max-row 0) (max-col 0)) (loop for row of-type array-index from 1 below var-g0 for prev-row of-type array-index = (1- row) do (loop for col of-type array-index from 1 below var-g1 for prev-col of-type array-index = (1- col) do (let ((var-g4 (the single-float (subn (aref vecm prev-row) (aref vecn prev-col))))) (let ((var-g5 (+ (aref sc row prev-col) gap-open)) (var-g6 (+ (aref ix row prev-col) gap-extend)) (var-g7 (+ (aref iy row prev-col) gap-open)) (var-g8 (+ (aref sc prev-row col) gap-open)) (var-g9 (+ (aref iy prev-row col) gap-extend)) (var-g10 (+ (aref ix prev-row col) gap-open)) (var-g11 (+ (aref sc prev-row prev-col) var-g4)) (var-g12 (+ (aref ix prev-row prev-col) var-g4)) (var-g13 (+ (aref iy prev-row prev-col) var-g4))) (let ((var-g2 (if (= 1 col) var-g5 (max var-g5 var-g6 var-g7))) (var-g3 (if (= 1 row) var-g8 (max var-g8 var-g9 var-g10))) (cell-score (max 0.0 var-g11 var-g12 var-g13))) ;; vvv error here vvv (setf (aref ix row col) var-g2 (aref iy row col) var-g3 (aref sc row col) cell-score) ;; ^^^ ^^^ (let ((var-g14 (max cell-score var-g2 var-g3))) (setf (aref bt row col) (cond ((= var-g14 var-g2) +insertx+) ((= var-g14 var-g3) +inserty+) (t +match+)))) (when (> cell-score max-score) (setf max-score cell-score max-row row max-col col))))))) (values max-score max-row max-col)))))) -- - Keith James - Wellcome Trust Sanger Institute, UK - -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From stassats at gmail.com Tue May 12 15:45:04 2009 From: stassats at gmail.com (Stas Boukarev) Date: Wed, 13 May 2009 02:45:04 +0400 Subject: [Openmcl-devel] Error when setting a value in a matrix unless safety 3 In-Reply-To: (Keith James's message of "Tue, 12 May 2009 21:39:55 +0100") References: Message-ID: <87tz3qq6tr.fsf@gmail.com> Keith James writes: > Hi, > > I'm porting some of my libraries that were developed on SBCL and > LispWorks. I'm experiencing an error that I can't explain when setting > a value (a single-float) into a type-declared matrix of single > floats. I've discovered that I can avoid the error by setting safety 3. > > The error message is > > value -5.0 is not of the expected type (SIMPLE-ARRAY DOUBLE-FLOAT (* *)) > > As the algorithm is very compute intensive (Smith-Waterman alignment), > I would like to optimize for speed and slightly reduced safety. I have > extracted the smallest self-contained example that I can, illustrating > the problem. > > Most of the code has been macroexpanded, hence the odd variable > names. I've commented the exact point of the error. Any suggestions > would be much appreciated. > > I'm using Version 1.3-r11936 (LinuxX8664). I was able to reduce to the following: (defun test () (let ((array (make-array '(1 1) :initial-element 2.0 :element-type 'single-float)) (var 1.0)) (setf (aref array 0 0) var var nil))) And it doesn't trigger on LinuxX8632. -- With best regards, Stas. From info at joakimsandgren.com Tue May 12 16:09:20 2009 From: info at joakimsandgren.com (Joakim Sandgren) Date: Wed, 13 May 2009 01:09:20 +0200 Subject: [Openmcl-devel] open file problem Message-ID: Hi, and thank you for all help this far. I have a strange error - I get the alt-console when I open this file. I tried and open it with textwrangler, i copied all text and pasted it into a new ccl file. but the opening error are still there. I have treated (toaken away accents) a lot of documents in my project now, and all of a sudden I have this error. does the file contain signs that are not allowed or something?... what am I missing? SIncerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: obtenir_profils.lisp Type: application/octet-stream Size: 7457 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Tue May 12 16:24:12 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 12 May 2009 17:24:12 -0600 (MDT) Subject: [Openmcl-devel] open file problem In-Reply-To: References: Message-ID: <20090512171719.H94994@abq.clozure.com> It would be easier to say something about why you get an error opening that file if you mentioned what the error was. On Wed, 13 May 2009, Joakim Sandgren wrote: > Hi, and thank you for all help this far. > I have a strange error - I get the alt-console when I open this file. > I tried and open it with textwrangler, i copied all text and pasted it into a > new ccl file. but the opening error are still there. > I have treated (toaken away accents) a lot of documents in my project now, > and all of a sudden I have this error. > does the file contain signs that are not allowed or something?... > what am I missing? > > > > > SIncerely > > Joakim > > > Joakim Sandgren > joakim sandgren musik > 42, rue de Maubeuge > 75009 Paris > France > +33 (0)1 45 26 43 90 > info at joakimsandgren.com > http://www.joakimsandgren.com > From terje at in-progress.com Tue May 12 22:02:41 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Tue, 12 May 2009 22:02:41 -0700 Subject: [Openmcl-devel] AppleScript In-Reply-To: <20090511192210.C66933@abq.clozure.com> References: <20090511192210.C66933@abq.clozure.com> Message-ID: <73DE82F7-F9EE-4C23-810E-55A342C35E53@in-progress.com> On May 12, 2009, at 8:19 AM, Gary Byers wrote: > There was an F-Script<->OpenMCL interface once upon a time: > > 004561.html> > > There was also a way of compiling and executing AppleScript > (without running > an external program.) I suspect that the stuff that I'm thinking > about > is what's described at: > > Open_Scripti_Architecture/Reference/reference.html> > > I don't think that there was ever any kind of high-level interface > to this > in CCL (at least none that I know of), but IIRC it wasn't -that- > bad to just > use the FFI (for some value of "not bad".) MCL has several contributions supporting Applescript, including compiling and/or executing scripts from Common LISP. Perhaps these can be ported or used as a starting point? I have several related MCL contributions myself at that makes MCL and its application OSA scriptable and recordable by implementing the classes and event handlers of the standard AppleEvent suites. -- Terje Norderhaug > On Tue, 12 May 2009, Steve N??ez wrote: >> Thanks. >> >> Has anyone looked at F-Script? I discovered it while looking >> around for ways >> I might script this application. I don't have any experience with >> it, but it >> looks interesting: >> >> http://www.fscript.org/ >> >> - Steve >> >> On 12/05/09 12:00 AM, "Daniel Dickison" >> wrote: >> >>> I'm the author of cl-applescript, and you're right that it has been >>> pretty much abandoned (the project I had originally wrote that >>> library >>> for went defunct). However, I believe it still works if you only >>> have >>> simple AppleScript needs, with the following caveats: >>> 1. All AS is executed using the osascript command line interface, >>> which means: >>> a. You can't construct AppleEvents programatically (you need to >>> construct script strings). >>> b. Every call has to compile the AppleScript from scratch, which is >>> slow. >>> c. The entire return value is stored as a string before parsing, so >>> you wouldn't want to do huge queries. >>> 2. Parsing dictionaries hasn't been implemented. >>> >>> The patch for CCL bug 216 should no longer be necessary if you're >>> using CCL 1.3 (I should update that page). If you would like to use >>> the library but you need dictionary parsing, I think it should be >>> pretty easy to implement and I'll be happy to help you with that. >>> >>> That said, Scripting Bridge is probably the way to go. You'll be >>> writing Cocoa code (presumably via the Clozure Objective-C bridge), >>> but I believe you can use it to script any application, >>> regardless of >>> whether it's Cocoa or Carbon. >>> >>> Daniel >>> >>> >>> On May 11, 2009, at 4:40 AM, Steve N??ez wrote: >>> >>>> G?Day Gentlemen, >>>> >>>> What?s the ?state of the art? for interfacing with Carbon >>>> applications exposing only an AppleScript interface? I found one >>>> possibility mentioned here: >>>> >>>> http://www.clozure.com/pipermail/openmcl-devel/2008-October/ >>>> 008618.html >>>> >>>> But this seems applicable only to Cocoa applications. There?s also >>>> cl-applescript: >>>> >>>> http://common-lisp.net/project/cl-applescript/ >>>> >>>> But that project appears to have been abandoned. I?m trying to >>>> determine the feasibility of heavily customising MS Entourage, and >>>> would like to use CCL for most of the heavy lifting. >>>> >>>> Regards, >>>> - Steve >>>> >>>> -- >>>> >>>> Level 31 >>>> 6 Battery Road >>>> Singapore 049909 >>>> >>>> Phone: +65 6321 9115 >>>> Mobile: +65 9679 8360 >>>> http://illation.com.sg >>>> >>>> >>>> _______________________________________________ >>>> Openmcl-devel mailing list >>>> Openmcl-devel at clozure.com >>>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >> >> -- >> >> Level 31 >> 6 Battery Road >> Singapore 049909 >> >> Phone: +65 6321 9115 >> Mobile: +65 9679 8360 >> http://illation.com.sg >> >> >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From gb at clozure.com Wed May 13 11:02:26 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 13 May 2009 12:02:26 -0600 (MDT) Subject: [Openmcl-devel] Error when setting a value in a matrix unless safety 3 In-Reply-To: <87tz3qq6tr.fsf@gmail.com> References: <87tz3qq6tr.fsf@gmail.com> Message-ID: <20090512164731.H66933@abq.clozure.com> On Wed, 13 May 2009, Stas Boukarev wrote: > Keith James writes: > >> Hi, >> >> I'm porting some of my libraries that were developed on SBCL and >> LispWorks. I'm experiencing an error that I can't explain when setting >> a value (a single-float) into a type-declared matrix of single >> floats. I've discovered that I can avoid the error by setting safety 3. >> >> The error message is >> >> value -5.0 is not of the expected type (SIMPLE-ARRAY DOUBLE-FLOAT (* *)) >> >> As the algorithm is very compute intensive (Smith-Waterman alignment), >> I would like to optimize for speed and slightly reduced safety. I have >> extracted the smallest self-contained example that I can, illustrating >> the problem. >> >> Most of the code has been macroexpanded, hence the odd variable >> names. I've commented the exact point of the error. Any suggestions >> would be much appreciated. >> >> I'm using Version 1.3-r11936 (LinuxX8664). > > I was able to reduce to the following: > > (defun test () > (let ((array (make-array '(1 1) :initial-element 2.0 > :element-type 'single-float)) > (var 1.0)) > (setf (aref array 0 0) var > var nil))) > > And it doesn't trigger on LinuxX8632. > The bug has to do with the compiler trying to keep two different things in the same register at the same time. (No matter how often it tries that, it never works ...) The x8632 cleverly minimizes the possibility of bugs like this by ... well, by being seriously register-starved. I think that it's fixed in the trunk now; once I'm pretty confident that it's indeed fixed (and that the fix didn't break anything), I'll move it to the 1.3 svn tree. > -- > With best regards, Stas. > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From herodoug at gmail.com Thu May 14 00:57:58 2009 From: herodoug at gmail.com (Douglas Brunner) Date: Thu, 14 May 2009 15:57:58 +0800 Subject: [Openmcl-devel] Running CCL as a CGI process is failing, the image can't be loaded Message-ID: I've tried to set up CCL to run as a CGI process to do some web development. I compiled a very simple program which just displays a header and a test string. Running the executable as myself, and as www-data (apache user) from the terminal work as expected, but when running it through the browser Apache always reports an error saying that the image can't be loaded. I'm wondering where I should be looking, at Apache, or at CCL. I've brought this up at a forum (http://lispforum.com/viewtopic.php?f=2&t=342), there's more info about the problem there. Thanks for any help. From kdj at sanger.ac.uk Thu May 14 01:50:18 2009 From: kdj at sanger.ac.uk (Keith James) Date: Thu, 14 May 2009 09:50:18 +0100 Subject: [Openmcl-devel] Error when setting a value in a matrix unless safety 3 In-Reply-To: <20090512164731.H66933@abq.clozure.com> References: <87tz3qq6tr.fsf@gmail.com> <20090512164731.H66933@abq.clozure.com> Message-ID: >>>>> "Gary" == Gary Byers writes: [..] Gary> I think that it's fixed in the trunk now; once I'm pretty Gary> confident that it's indeed fixed (and that the fix didn't Gary> break anything), I'll move it to the 1.3 svn tree. Thanks for your help. I've run my code on the trunk. Now that I can use a more aggressive optimize setting, I see a 3x speed increase and no errors. -- - Keith James - Wellcome Trust Sanger Institute, UK - -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From john at mcaleely.com Thu May 14 02:15:47 2009 From: john at mcaleely.com (John McAleely) Date: Thu, 14 May 2009 11:15:47 +0200 Subject: [Openmcl-devel] Running CCL as a CGI process is failing, the image can't be loaded In-Reply-To: References: Message-ID: <25E2B788-5BD4-4653-87C0-3609A562DDDF@mcaleely.com> That forum appears to have a tediously strict policy about contributions, so my suggestion appears to have disappeared, despite me completing their registration dance, apparently successfully. From what is written in the thread, and the absence of .cgi from the error message, I wonder what happens if you remove the .cgi extension, and rename your image to 'image' rather than 'image.cgi'? J On 14 May 2009, at 09:57, Douglas Brunner wrote: > I've tried to set up CCL to run as a CGI process to do some web > development. I compiled a very simple program which just displays a > header and a test string. Running the executable as myself, and as > www-data (apache user) from the terminal work as expected, but when > running it through the browser Apache always reports an error saying > that the image can't be loaded. > > I'm wondering where I should be looking, at Apache, or at CCL. > > I've brought this up at a forum > (http://lispforum.com/viewtopic.php?f=2&t=342), there's more info > about the problem there. > > Thanks for any help. > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From joakim at joakimsandgren.com Thu May 14 03:35:25 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Thu, 14 May 2009 12:35:25 +0200 Subject: [Openmcl-devel] documents Message-ID: <7824EF62-FF7C-4D8F-8ACA-EE5C77F8FD40@joakimsandgren.com> Hi, I have these strange errors just to open some documents in my project, that have hundreds of files, and now I have a bunch of files that I can't open in ccl 1.3 mac intel. Does these files contains caract?res that is not handles by ccl? heres are three consoles: Sincerely Joakim ***************************************************************************************************************************************************************************************************** ***************************************************************************************************************************************************************************************************** ***************************************************************************************************************************************************************************************************** THE FIRST *** Error in event process: Array index 136 out of bounds for "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ (342C74) : 0 (FUNCALL #'#<(:INTERNAL GUI::|-[HemlockEditorDocument setFileURL:]|)> #) 151 (#:G27705) #:G27705: # #:COMPILER-VAR: (NIL) #:G27702: # (342C88) : 1 (SIGNAL #) 903 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) CCL::TAG: (CONDITION #) CCL::HANDLERS: (CONDITION #) CCL::FN: # (342CB0) : 2 (%ERROR # (136 "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: (136 "buffer mark ringsp /users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ CCL::ERROR-POINTER: 854833 (342CC4) : 3 (FUNCALL #'#<(:INTERNAL CCL::ARE CCL::STRING-START- END)> "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ (CCL::A CCL::I) CCL::A: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ CCL::I: 136 (342CD4) : 4 (STRING-START-END "buffer mark ringsp /users/js/ejs/ projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/ cadence/t_4/ (STRING CCL::START CCL::END) STRING: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ CCL::START: 0 CCL::END: 136 CCL::LEN: 128 (342CEC) : 5 (STRING-CMP "buffer mark ringsp /users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ (CCL::STRING1 CCL::START1 CCL::END1 CCL::STRING2 CCL::START2 CCL::END2) CCL::STRING1: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ CCL::START1: 0 CCL::END1: 136 CCL::STRING2: "echo area 3" CCL::START2: 0 CCL::END2: 11 CCL::ISTART1: 0 (342D14) : 6 (STRING/= "buffer mark ringsp /users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ (CCL::STRING1 CCL::STRING2 &KEY :START1 :END1 :START2 :END2) CCL::STRING1: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ CCL::STRING2: "echo area 3" CCL::START1: 0 CCL::END1: 136 CCL::START2: 0 CCL::END2: 11 (342D48) : 7 (STRING-COMPARE "buffer mark ringsp /users/js/ejs/ projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/ cadence/t_4/ (HI::S1 HI::S2 &KEY :START1 :END1 :START2 :END2) HI::S1: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ HI::S2: "echo area 3" HI::START1: 0 HI::END1: 136 HI::START2: 0 HI::END2: NIL HI::END1: 136 HI::END2: 11 (342D80) : 8 (BI-SVPOSITION "buffer mark ringsp /users/js/ejs/ projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/ cadence/t_4//_ecrire_champ/amp_point_4/"> ...) # :START 0 :END 13 :KEY #) 319 (HI::ITEM VECTOR HI::TEST &KEY :START :END :KEY) HI::ITEM: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ VECTOR: #( ...) HI::TEST: # HI::START: 0 HI::END: 13 HI::KEY: # HI::LOW: 0 HI::HIGH: 13 HI::MID: 6 HI::ARRAY-ITEM: HI::TEST-ITEM: "echo area 3" (342DC0) : 9 (GETSTRING "obtenir_profils.lisp /Users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/obtenir_profils.o/" #) 527 (STRING HI:STRING-TABLE) STRING: "obtenir_profils.lisp /Users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/" HI:STRING-TABLE: # HI::FOLDED: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ HI::LEN: 136 HI::NODES: #( ...) HI::NUM-NODES: 14 (342DE4) : 10 (%SET-BUFFER-NAME # "obtenir_profils.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/") 79 (HI:BUFFER HI::NAME) HI:BUFFER: # HI::NAME: "obtenir_profils.lisp /Users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/" (342DF8) : 11 (FUNCALL #'# -268436350) 1095 (#:G27701) #:G27701: -268436350 #:G27717: # #:G27702: # #:COMPILER-VAR: (NIL) #:G27707: # #:G27718: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) GUI::SELF: # (#x96F600)> GUI::_CMD: # GUI::URL: # GUI::BUFFER: # GUI::NEW-PATHNAME: "/Users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/obtenir_profils.lisp" (342E38) : 12 (%PASCAL-FUNCTIONS% 115 -268436350) 343 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 115 CCL::ARGS-PTR-FIXNUM: -268436350 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (342E80) : 14 (FUNCALL #'# # # #) 391 (#:G4511 #:G4512 CCL::ARG0) #:G4511: # #:G4512: # CCL::ARG0: # (342E94) : 15 (%CALL-NEXT-OBJC-METHOD # (#x813C00)> # # (:VOID :ID) #) 1191 (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) CCL::SELF: # (#x813C00)> CLASS: # CCL::SELECTOR: # CCL::SIG: (:VOID :ID) CCL::ARGS: (#) CCL::S: # CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE (:VOID :ID) :FUNCTION # ...) FUNCTION: # #:G2643: # #:G2644: -268435942 (342EE4) : 16 (FUNCALL #'# -268435882) 1039 (#:G5202) #:G5202: -268435882 #:G5218: # #:G5203: # #:COMPILER-VAR: (NIL) #:G5208: # #:G5219: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) GUI::SELF: # (#x813C00)> GUI::_CMD: # GUI::E: # CCL::ARGS: (#) (342F20) : 17 (%PASCAL-FUNCTIONS% 14 -268435882) 343 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 14 CCL::ARGS-PTR-FIXNUM: -268435882 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (342F68) : 19 (FUNCALL #'# # (#x813C00)> #S(CCL::OBJC- SELECTOR :NAME "run" :%SEL #)) 199 (#:G3061 #:G3062) #:G3061: # (#x813C00)> #:G3062: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) ********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************** ***************************************************************************************************************************************************************************************************** THE SECOND: *** Error in event process: Array index 129 out of bounds for "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ ecrires_et_obtenirs.o/obtenir.o/ (342C74) : 0 (FUNCALL #'#<(:INTERNAL GUI::|-[HemlockEditorDocument setFileURL:]|)> #) 151 (#:G27705) #:G27705: # #:COMPILER-VAR: (NIL) #:G27702: # (342C88) : 1 (SIGNAL #) 903 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) CCL::TAG: (CONDITION #) CCL::HANDLERS: (CONDITION #) CCL::FN: # (342CB0) : 2 (%ERROR # (129 "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ ecrires_et_obtenirs.o/obtenir.o/ (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: (129 "buffer mark rings/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ CCL::ERROR-POINTER: 854833 (342CC4) : 3 (FUNCALL #'#<(:INTERNAL CCL::ARE CCL::STRING-START- END)> "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ (CCL::A CCL::I) CCL::A: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ CCL::I: 129 (342CD4) : 4 (STRING-START-END "buffer mark rings/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/ (STRING CCL::START CCL::END) STRING: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ CCL::START: 0 CCL::END: 129 CCL::LEN: 128 (342CEC) : 5 (STRING-CMP "buffer mark rings/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/ (CCL::STRING1 CCL::START1 CCL::END1 CCL::STRING2 CCL::START2 CCL::END2) CCL::STRING1: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ CCL::START1: 0 CCL::END1: 129 CCL::STRING2: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" CCL::START2: 0 CCL::END2: 108 CCL::ISTART1: 0 (342D14) : 6 (STRING/= "buffer mark rings/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ (CCL::STRING1 CCL::STRING2 &KEY :START1 :END1 :START2 :END2) CCL::STRING1: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ CCL::STRING2: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" CCL::START1: 0 CCL::END1: 129 CCL::START2: 0 CCL::END2: 108 (342D48) : 7 (STRING-COMPARE "buffer mark rings/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/ (HI::S1 HI::S2 &KEY :START1 :END1 :START2 :END2) HI::S1: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ HI::S2: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" HI::START1: 0 HI::END1: 129 HI::START2: 0 HI::END2: NIL HI::END1: 129 HI::END2: 108 (342D80) : 8 (BI-SVPOSITION "buffer mark rings/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/ (HI::ITEM VECTOR HI::TEST &KEY :START :END :KEY) HI::ITEM: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ VECTOR: #( ...) HI::TEST: # HI::START: 0 HI::END: 11 HI::KEY: # HI::LOW: 0 HI::HIGH: 11 HI::MID: 5 HI::ARRAY-ITEM: HI::TEST-ITEM: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" (342DC0) : 9 (GETSTRING "obtenir_instances_dune_ins.lisp /Users/js/ ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ ecrires_et_obtenirs.o/obtenir.o/" #) 527 (STRING HI:STRING-TABLE) STRING: "obtenir_instances_dune_ins.lisp /Users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/" HI:STRING-TABLE: # HI::FOLDED: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ HI::LEN: 129 HI::NODES: #( ...) HI::NUM-NODES: 12 (342DE4) : 10 (%SET-BUFFER-NAME # "obtenir_instances_dune_ins.lisp /Users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/") 79 (HI:BUFFER HI::NAME) HI:BUFFER: # HI::NAME: "obtenir_instances_dune_ins.lisp /Users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/" (342DF8) : 11 (FUNCALL #'# -268436350) 1095 (#:G27701) #:G27701: -268436350 #:G27717: # #:G27702: # #:COMPILER-VAR: (NIL) #:G27707: # #:G27718: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) GUI::SELF: # (#x932800)> GUI::_CMD: # GUI::URL: # GUI::BUFFER: # GUI::NEW-PATHNAME: "/Users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_instances_dune_ins.lisp" (342E38) : 12 (%PASCAL-FUNCTIONS% 115 -268436350) 343 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 115 CCL::ARGS-PTR-FIXNUM: -268436350 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (342E80) : 14 (FUNCALL #'# # # #) 391 (#:G4511 #:G4512 CCL::ARG0) #:G4511: # #:G4512: # CCL::ARG0: # (342E94) : 15 (%CALL-NEXT-OBJC-METHOD # (#x813C00)> # # (:VOID :ID) #) 1191 (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) CCL::SELF: # (#x813C00)> CLASS: # CCL::SELECTOR: # CCL::SIG: (:VOID :ID) CCL::ARGS: (#) CCL::S: # CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE (:VOID :ID) :FUNCTION # ...) FUNCTION: # #:G2643: # #:G2644: -268435942 (342EE4) : 16 (FUNCALL #'# -268435882) 1039 (#:G5202) #:G5202: -268435882 #:G5218: # #:G5203: # #:COMPILER-VAR: (NIL) #:G5208: # #:G5219: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) GUI::SELF: # (#x813C00)> GUI::_CMD: # GUI::E: # CCL::ARGS: (#) (342F20) : 17 (%PASCAL-FUNCTIONS% 14 -268435882) 343 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 14 CCL::ARGS-PTR-FIXNUM: -268435882 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (342F68) : 19 (FUNCALL #'# # (#x813C00)> #S(CCL::OBJC- SELECTOR :NAME "run" :%SEL #)) 199 (#:G3061 #:G3062) #:G3061: # (#x813C00)> #:G3062: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) ***************************************************************************************************************************************************************************************************** ********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************** THE THIRD *** Error in event process: Array index 135 out of bounds for "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ ecrires_et_obtenirs.o/ecrire.o/". (342C74) : 0 (FUNCALL #'#<(:INTERNAL GUI::|-[HemlockEditorDocument setFileURL:]|)> #) 151 (#:G27705) #:G27705: # #:COMPILER-VAR: (NIL) #:G27702: # (342C88) : 1 (SIGNAL #) 903 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) CCL::TAG: (CONDITION #) CCL::HANDLERS: (CONDITION #) CCL::FN: # (342CB0) : 2 (%ERROR # (135 "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ ecrires_et_obtenirs.o/ecrire.o/") 854833) 119 (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: (135 "buffer mark ringrs/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/") CCL::ERROR-POINTER: 854833 (342CC4) : 3 (FUNCALL #'#<(:INTERNAL CCL::ARE CCL::STRING-START- END)> "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" 135) 47 (CCL::A CCL::I) CCL::A: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" CCL::I: 135 (342CD4) : 4 (STRING-START-END "buffer mark ringrs/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" 0 135) 159 (STRING CCL::START CCL::END) STRING: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" CCL::START: 0 CCL::END: 135 CCL::LEN: 128 (342CEC) : 5 (STRING-CMP "buffer mark ringrs/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" 0 135 "ecrire.lisp /users/js/ejs/ projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ ecrires_et_obtenirs.o/ecrire.o/" 0 108) 151 (CCL::STRING1 CCL::START1 CCL::END1 CCL::STRING2 CCL::START2 CCL::END2) CCL::STRING1: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" CCL::START1: 0 CCL::END1: 135 CCL::STRING2: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" CCL::START2: 0 CCL::END2: 108 CCL::ISTART1: 0 (342D14) : 6 (STRING/= "buffer mark ringrs/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" "ecrire.lisp /users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" :START1 0 :END1 135 :START2 0 :END2 108) 127 (CCL::STRING1 CCL::STRING2 &KEY :START1 :END1 :START2 :END2) CCL::STRING1: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" CCL::STRING2: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" CCL::START1: 0 CCL::END1: 135 CCL::START2: 0 CCL::END2: 108 (342D48) : 7 (STRING-COMPARE "buffer mark ringrs/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" "ecrire.lisp /users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" :START1 0 :END1 135 :START2 0 :END2 NIL) 247 (HI::S1 HI::S2 &KEY :START1 :END1 :START2 :END2) HI::S1: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" HI::S2: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" HI::START1: 0 HI::END1: 135 HI::START2: 0 HI::END2: NIL HI::END1: 135 HI::END2: 108 (342D80) : 8 (BI-SVPOSITION "buffer mark ringrs/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" #( ...) # :START 0 :END 5 :KEY #) 319 (HI::ITEM VECTOR HI::TEST &KEY :START :END :KEY) HI::ITEM: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" VECTOR: #( ...) HI::TEST: # HI::START: 0 HI::END: 5 HI::KEY: # HI::LOW: 0 HI::HIGH: 5 HI::MID: 2 HI::ARRAY-ITEM: HI::TEST-ITEM: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" (342DC0) : 9 (GETSTRING "%obtenir_champ.lisp /Users/js/ejs/projects/ ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ obtenir.o/obtenir_profils.o/" #) 527 (STRING HI:STRING-TABLE) STRING: "%obtenir_champ.lisp /Users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/" HI:STRING-TABLE: # HI::FOLDED: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/ ecrire.o/" HI::LEN: 135 HI::NODES: #( ...) HI::NUM-NODES: 6 (342DE4) : 10 (%SET-BUFFER-NAME # "%obtenir_champ.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/") 79 (HI:BUFFER HI::NAME) HI:BUFFER: # HI::NAME: "%obtenir_champ.lisp /Users/js/ejs/projects/ejs37.0.o/ forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/" (342DF8) : 11 (FUNCALL #'# -268436350) 1095 (#:G27701) #:G27701: -268436350 #:G27717: # #:G27702: # #:COMPILER-VAR: (NIL) #:G27707: # #:G27718: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) GUI::SELF: # (#x8F7800)> GUI::_CMD: # GUI::URL: # GUI::BUFFER: # GUI::NEW-PATHNAME: "/Users/js/ejs/projects/ejs37.0.o/forme.o/ forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ obtenir_profils.o/%obtenir_champ.lisp" (342E38) : 12 (%PASCAL-FUNCTIONS% 115 -268436350) 343 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 115 CCL::ARGS-PTR-FIXNUM: -268436350 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (342E80) : 14 (FUNCALL #'# # # #) 391 (#:G4511 #:G4512 CCL::ARG0) #:G4511: # #:G4512: # CCL::ARG0: # (342E94) : 15 (%CALL-NEXT-OBJC-METHOD # (#x813600)> # # (:VOID :ID) #) 1191 (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) CCL::SELF: # (#x813600)> CLASS: # CCL::SELECTOR: # CCL::SIG: (:VOID :ID) CCL::ARGS: (#) CCL::S: # CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE (:VOID :ID) :FUNCTION # ...) FUNCTION: # #:G2643: # #:G2644: -268435942 (342EE4) : 16 (FUNCALL #'# -268435882) 1039 (#:G5202) #:G5202: -268435882 #:G5218: # #:G5203: # #:COMPILER-VAR: (NIL) #:G5208: # #:G5219: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) GUI::SELF: # (#x813600)> GUI::_CMD: # GUI::E: # CCL::ARGS: (#) (342F20) : 17 (%PASCAL-FUNCTIONS% 14 -268435882) 343 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 14 CCL::ARGS-PTR-FIXNUM: -268435882 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (342F68) : 19 (FUNCALL #'# # (#x813600)> #S(CCL::OBJC- SELECTOR :NAME "run" :%SEL #)) 199 (#:G3061 #:G3062) #:G3061: # (#x813600)> #:G3062: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Thu May 14 03:58:38 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Thu, 14 May 2009 12:58:38 +0200 Subject: [Openmcl-devel] right arrow on selection Message-ID: <49CAF22D-21E8-4549-9A0E-6276DD1B0C5A@joakimsandgren.com> Hi, I also have a question about 2 behaviors from the same action: this is in ccl 1.3 mac intel. if I double click and mark (make "blue") one word and the hit the right arrow the cursor go to one position to the right of the last element in the selection. if i double click and mark something in parenthesis and hit the right arrow, the cursor goes to the position one step to the right of the first element in the selection. normally, in a mac application if you select some text and then hit the right arrow the cursos goes to the position just after the last element of the selection. Very Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gz at clozure.com Thu May 14 04:15:56 2009 From: gz at clozure.com (Gail Zacharias) Date: Thu, 14 May 2009 07:15:56 -0400 Subject: [Openmcl-devel] right arrow on selection In-Reply-To: <49CAF22D-21E8-4549-9A0E-6276DD1B0C5A@joakimsandgren.com> References: <49CAF22D-21E8-4549-9A0E-6276DD1B0C5A@joakimsandgren.com> Message-ID: <200905141117.PWB61372@mr02.lnh.mail.rcn.net> An HTML attachment was scrubbed... URL: From gz at clozure.com Thu May 14 04:43:57 2009 From: gz at clozure.com (Gail Zacharias) Date: Thu, 14 May 2009 07:43:57 -0400 Subject: [Openmcl-devel] documents In-Reply-To: <7824EF62-FF7C-4D8F-8ACA-EE5C77F8FD40@joakimsandgren.com> References: <7824EF62-FF7C-4D8F-8ACA-EE5C77F8FD40@joakimsandgren.com> Message-ID: <200905141145.PWB67015@mr02.lnh.mail.rcn.net> An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Thu May 14 05:23:16 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Thu, 14 May 2009 14:23:16 +0200 Subject: [Openmcl-devel] documents In-Reply-To: <200905141145.PWB67015@mr02.lnh.mail.rcn.net> References: <7824EF62-FF7C-4D8F-8ACA-EE5C77F8FD40@joakimsandgren.com> <200905141145.PWB67015@mr02.lnh.mail.rcn.net> Message-ID: <678B5F31-464F-476B-AFB3-765993094742@joakimsandgren.com> Thanks, I just had the idea that it is the total loading path that is out of bound.. When I shorten the name of the folder where the file is i could open it. seems the tha it isnt even in the file but perhaps a array that is full somewhere?... Very Sincerely Joakim Le 14 mai 09 ? 13:43, Gail Zacharias a ?crit : > The problem seems to be with characters in the file name, not in the > file itself. It triggers some hemlock bug when trying to use the > file name as the buffer name. As a workaround until we fix this, > you could rename the file to only have ascii characters. > > > At 5/14/2009 06:35 AM, Joakim Sandgren wrote: >> Hi, >> I have these strange errors just to open some documents in my >> project, that have hundreds of files, and now I have a bunch of >> files that I can't open in ccl 1.3 mac intel. >> Does these files contains caract?res that is not handles by ccl? >> >> heres are three consoles: >> >> Sincerely >> Joakim >> >> ***************************************************************************************************************************************************************************************************** >> ***************************************************************************************************************************************************************************************************** >> ***************************************************************************************************************************************************************************************************** >> THE FIRST >> >> *** Error in event process: Array index 136 out of bounds for >> "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> >> (342C74) : 0 (FUNCALL #'#<(:INTERNAL GUI::|-[HemlockEditorDocument >> setFileURL:]|)> #) 151 >> (#:G27705) >> #:G27705: # >> >> #:COMPILER-VAR: (NIL) >> #:G27702: # >> >> (342C88) : 1 (SIGNAL #) 903 >> (CONDITION &REST CCL::ARGS) >> CONDITION: # >> CCL::ARGS: NIL >> >> CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) >> CCL::TAG: (CONDITION #) >> CCL::HANDLERS: (CONDITION #) >> CCL::FN: #> [HemlockEditorDocument setFileURL:]|) #xCBD8E> >> >> (342CB0) : 2 (%ERROR # (136 "buffer mark >> ringsp /users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >> CONDITION: # >> CCL::ARGS: (136 "buffer mark ringsp /users/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> CCL::ERROR-POINTER: 854833 >> >> >> >> (342CC4) : 3 (FUNCALL #'#<(:INTERNAL CCL::ARE CCL::STRING-START- >> END)> "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> (CCL::A CCL::I) >> CCL::A: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> CCL::I: 136 >> >> >> >> (342CD4) : 4 (STRING-START-END "buffer mark ringsp /users/js/ejs/ >> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/ >> cadence/t_4/ >> (STRING CCL::START CCL::END) >> STRING: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> CCL::START: 0 >> CCL::END: 136 >> >> CCL::LEN: 128 >> >> (342CEC) : 5 (STRING-CMP "buffer mark ringsp /users/js/ejs/ >> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/ >> cadence/t_4/ >> (CCL::STRING1 CCL::START1 CCL::END1 CCL::STRING2 CCL::START2 >> CCL::END2) >> CCL::STRING1: "buffer mark ringsp /users/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> CCL::START1: 0 >> CCL::END1: 136 >> CCL::STRING2: "echo area 3" >> CCL::START2: 0 >> CCL::END2: 11 >> >> CCL::ISTART1: 0 >> >> (342D14) : 6 (STRING/= "buffer mark ringsp /users/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> (CCL::STRING1 CCL::STRING2 &KEY :START1 :END1 :START2 :END2) >> CCL::STRING1: "buffer mark ringsp /users/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> CCL::STRING2: "echo area 3" >> CCL::START1: 0 >> CCL::END1: 136 >> CCL::START2: 0 >> CCL::END2: 11 >> >> >> >> (342D48) : 7 (STRING-COMPARE "buffer mark ringsp /users/js/ejs/ >> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/ >> cadence/t_4/ >> (HI::S1 HI::S2 &KEY :START1 :END1 :START2 :END2) >> HI::S1: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> HI::S2: "echo area 3" >> HI::START1: 0 >> HI::END1: 136 >> HI::START2: 0 >> HI::END2: NIL >> >> HI::END1: 136 >> HI::END2: 11 >> >> (342D80) : 8 (BI-SVPOSITION "buffer mark ringsp /users/js/ejs/ >> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/ >> cadence/t_4//_ecrire_champ/amp_point_4/"> > "_ecr_val_pol.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/cadence/"> > Area 1"> ...) #> INTERFACE:GETSTRING) #x91780DE> :START 0 :END 13 :KEY #> Function #x8CFEBAE>) 319 >> (HI::ITEM VECTOR HI::TEST &KEY :START :END :KEY) >> HI::ITEM: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> VECTOR: #(> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/"> >> > forme_proportionnelle.o/_ecrire_champ/amp_point_2/"> > "_ecr_val_pol.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/amp_point_4/"> > "_ecr_val_pol.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/cadence/"> > Area 1"> ...) >> HI::TEST: #> INTERFACE:GETSTRING) #x91780DE> >> HI::START: 0 >> HI::END: 13 >> HI::KEY: # >> >> HI::LOW: 0 >> HI::HIGH: 13 >> HI::MID: 6 >> HI::ARRAY-ITEM: >> HI::TEST-ITEM: "echo area 3" >> >> (342DC0) : 9 (GETSTRING "obtenir_profils.lisp /Users/js/ejs/ >> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ >> ecrires_et_obtenirs.o/obtenir.o/obtenir_profils.o/" #> Table>) 527 >> (STRING HI:STRING-TABLE) >> STRING: "obtenir_profils.lisp /Users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/" >> HI:STRING-TABLE: # >> >> HI::FOLDED: "buffer mark ringsp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/_ecrire_champ/cadence/t_4/ >> HI::LEN: 136 >> HI::NODES: #(> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/_ecrire_champ/"> >> > forme_proportionnelle.o/_ecrire_champ/amp_point_2/"> > "_ecr_val_pol.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/amp_point_4/"> > "_ecr_val_pol.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/_ecrire_champ/cadence/"> > Area 1"> ...) >> HI::NUM-NODES: 14 >> >> (342DE4) : 10 (%SET-BUFFER-NAME # >> "obtenir_profils.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/") 79 >> (HI:BUFFER HI::NAME) >> HI:BUFFER: # >> HI::NAME: "obtenir_profils.lisp /Users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/" >> >> >> >> (342DF8) : 11 (FUNCALL #'#> setFileURL:]|> -268436350) 1095 >> (#:G27701) >> #:G27701: -268436350 >> >> #:G27717: # >> #:G27702: # >> #:COMPILER-VAR: (NIL) >> #:G27707: #> [HemlockEditorDocument setFileURL:]|) #xCBD8E> >> #:G27718: (CONDITION #) >> CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) >> GUI::SELF: #> 0x96f600> (#x96F600)> >> GUI::_CMD: # >> GUI::URL: #> (#x3892A90)> >> GUI::BUFFER: # >> GUI::NEW-PATHNAME: "/Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/obtenir_profils.lisp" >> >> (342E38) : 12 (%PASCAL-FUNCTIONS% 115 -268436350) 343 >> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >> CCL::INDEX: 115 >> CCL::ARGS-PTR-FIXNUM: -268436350 >> >> CCL::LISP-FUNCTION: #> [HemlockEditorDocument setFileURL:]| (Non-Global) #x8E68F4E> >> WITHOUT-INTERRUPTS: NIL >> CCL::*CALLBACK-TRACE-P*: NIL >> >> (342E80) : 14 (FUNCALL #'# #> Foreign Pointer [stack-allocated] (:* #) #xBFFFF900> #> Pointer #x966204B8> #> time=95745.0 flags=0x100110 win=0x0 winNum=31894 ctxt=0x10bc7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x38BFEC0)>) 391 >> (#:G4511 #:G4512 CCL::ARG0) >> #:G4511: # >> #:G4512: # >> CCL::ARG0: #> time=95745.0 flags=0x100110 win=0x0 winNum=31894 ctxt=0x10bc7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x38BFEC0)> >> >> >> >> (342E94) : 15 (%CALL-NEXT-OBJC-METHOD #> (#x813C00)> #> APPLICATION (#x113F20)> # (:VOID :ID) >> #> flags=0x100110 win=0x0 winNum=31894 ctxt=0x10bc7 chars="o" >> unmodchars="o" repeat=0 keyCode=31 (#x38BFEC0)>) 1191 >> (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) >> CCL::SELF: # >> (#x813C00)> >> CLASS: # >> CCL::SELECTOR: # >> CCL::SIG: (:VOID :ID) >> CCL::ARGS: (#> time=95745.0 flags=0x100110 win=0x0 winNum=31894 ctxt=0x10bc7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x38BFEC0)>) >> >> CCL::S: # >> CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE >> (:VOID :ID) :FUNCTION # ...) >> FUNCTION: # >> #:G2643: # >> #:G2644: -268435942 >> >> (342EE4) : 16 (FUNCALL #'# >> -268435882) 1039 >> (#:G5202) >> #:G5202: -268435882 >> >> #:G5218: # >> #:G5203: # >> #:COMPILER-VAR: (NIL) >> #:G5208: #> [LispApplication sendEvent:]|) #xCBEAE> >> #:G5219: (CONDITION #) >> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >> GUI::SELF: # >> (#x813C00)> >> GUI::_CMD: # >> GUI::E: #> flags=0x100110 win=0x0 winNum=31894 ctxt=0x10bc7 chars="o" >> unmodchars="o" repeat=0 keyCode=31 (#x38BFEC0)> >> CCL::ARGS: (#> time=95745.0 flags=0x100110 win=0x0 winNum=31894 ctxt=0x10bc7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x38BFEC0)>) >> >> (342F20) : 17 (%PASCAL-FUNCTIONS% 14 -268435882) 343 >> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >> CCL::INDEX: 14 >> CCL::ARGS-PTR-FIXNUM: -268435882 >> >> CCL::LISP-FUNCTION: #> sendEvent:]| (Non-Global) #x8BF8136> >> WITHOUT-INTERRUPTS: NIL >> CCL::*CALLBACK-TRACE-P*: NIL >> >> (342F68) : 19 (FUNCALL #'# #> APPLICATION (#x813C00)> #S(CCL::OBJC- >> SELECTOR :NAME "run" :%SEL #)) 199 >> (#:G3061 #:G3062) >> #:G3061: # >> (#x813C00)> >> #:G3062: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #> Pointer #x966CAA24>) >> >> >> ********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************** >> ***************************************************************************************************************************************************************************************************** >> THE SECOND: >> >> >> >> >> *** Error in event process: Array index 129 out of bounds for >> "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> >> (342C74) : 0 (FUNCALL #'#<(:INTERNAL GUI::|-[HemlockEditorDocument >> setFileURL:]|)> #) 151 >> (#:G27705) >> #:G27705: # >> >> #:COMPILER-VAR: (NIL) >> #:G27702: # >> >> (342C88) : 1 (SIGNAL #) 903 >> (CONDITION &REST CCL::ARGS) >> CONDITION: # >> CCL::ARGS: NIL >> >> CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) >> CCL::TAG: (CONDITION #) >> CCL::HANDLERS: (CONDITION #) >> CCL::FN: #> [HemlockEditorDocument setFileURL:]|) #xCBD8E> >> >> (342CB0) : 2 (%ERROR # (129 "buffer mark >> rings/js/ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ >> ecrires_et_obtenirs.o/obtenir.o/ >> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >> CONDITION: # >> CCL::ARGS: (129 "buffer mark rings/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> CCL::ERROR-POINTER: 854833 >> >> >> >> (342CC4) : 3 (FUNCALL #'#<(:INTERNAL CCL::ARE CCL::STRING-START- >> END)> "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> (CCL::A CCL::I) >> CCL::A: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> CCL::I: 129 >> >> >> >> (342CD4) : 4 (STRING-START-END "buffer mark rings/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> obtenir.o/ >> (STRING CCL::START CCL::END) >> STRING: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> CCL::START: 0 >> CCL::END: 129 >> >> CCL::LEN: 128 >> >> (342CEC) : 5 (STRING-CMP "buffer mark rings/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> obtenir.o/ >> (CCL::STRING1 CCL::START1 CCL::END1 CCL::STRING2 CCL::START2 >> CCL::END2) >> CCL::STRING1: "buffer mark rings/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> CCL::START1: 0 >> CCL::END1: 129 >> CCL::STRING2: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" >> CCL::START2: 0 >> CCL::END2: 108 >> >> CCL::ISTART1: 0 >> >> (342D14) : 6 (STRING/= "buffer mark rings/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> obtenir.o/ >> (CCL::STRING1 CCL::STRING2 &KEY :START1 :END1 :START2 :END2) >> CCL::STRING1: "buffer mark rings/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> CCL::STRING2: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" >> CCL::START1: 0 >> CCL::END1: 129 >> CCL::START2: 0 >> CCL::END2: 108 >> >> >> >> (342D48) : 7 (STRING-COMPARE "buffer mark rings/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> obtenir.o/ >> (HI::S1 HI::S2 &KEY :START1 :END1 :START2 :END2) >> HI::S1: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> HI::S2: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" >> HI::START1: 0 >> HI::END1: 129 >> HI::START2: 0 >> HI::END2: NIL >> >> HI::END1: 129 >> HI::END2: 108 >> >> (342D80) : 8 (BI-SVPOSITION "buffer mark rings/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> obtenir.o/ >> (HI::ITEM VECTOR HI::TEST &KEY :START :END :KEY) >> HI::ITEM: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> VECTOR: #( >> > "Echo Area 5"> ...) >> HI::TEST: #> INTERFACE:GETSTRING) #x9156476> >> HI::START: 0 >> HI::END: 11 >> HI::KEY: # >> >> HI::LOW: 0 >> HI::HIGH: 11 >> HI::MID: 5 >> HI::ARRAY-ITEM: > ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> obtenir.o/"> >> HI::TEST-ITEM: "ladda.lisp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/" >> >> (342DC0) : 9 (GETSTRING "obtenir_instances_dune_ins.lisp /Users/js/ >> ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ >> ecrires_et_obtenirs.o/obtenir.o/" #) 527 >> (STRING HI:STRING-TABLE) >> STRING: "obtenir_instances_dune_ins.lisp /Users/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> obtenir.o/" >> HI:STRING-TABLE: # >> >> HI::FOLDED: "buffer mark rings/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> HI::LEN: 129 >> HI::NODES: #( > 2"> > Node "Echo Area 5"> ...) >> HI::NUM-NODES: 12 >> >> (342DE4) : 10 (%SET-BUFFER-NAME # >> "obtenir_instances_dune_ins.lisp /Users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/") 79 >> (HI:BUFFER HI::NAME) >> HI:BUFFER: # >> HI::NAME: "obtenir_instances_dune_ins.lisp /Users/js/ejs/ >> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ >> ecrires_et_obtenirs.o/obtenir.o/" >> >> >> >> (342DF8) : 11 (FUNCALL #'#> setFileURL:]|> -268436350) 1095 >> (#:G27701) >> #:G27701: -268436350 >> >> #:G27717: # >> #:G27702: # >> #:COMPILER-VAR: (NIL) >> #:G27707: #> [HemlockEditorDocument setFileURL:]|) #xCBD8E> >> #:G27718: (CONDITION #) >> CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) >> GUI::SELF: #> 0x932800> (#x932800)> >> GUI::_CMD: # >> GUI::URL: #> (#x3AB7EF0)> >> GUI::BUFFER: # >> GUI::NEW-PATHNAME: "/Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_instances_dune_ins.lisp" >> >> (342E38) : 12 (%PASCAL-FUNCTIONS% 115 -268436350) 343 >> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >> CCL::INDEX: 115 >> CCL::ARGS-PTR-FIXNUM: -268436350 >> >> CCL::LISP-FUNCTION: #> [HemlockEditorDocument setFileURL:]| (Non-Global) #x8E68F4E> >> WITHOUT-INTERRUPTS: NIL >> CCL::*CALLBACK-TRACE-P*: NIL >> >> (342E80) : 14 (FUNCALL #'# #> Foreign Pointer [stack-allocated] (:* #) #xBFFFF900> #> Pointer #x966204B8> #> time=95659.2 flags=0x100110 win=0x0 winNum=31852 ctxt=0x126c7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x1E8DB0)>) 391 >> (#:G4511 #:G4512 CCL::ARG0) >> #:G4511: # >> #:G4512: # >> CCL::ARG0: #> time=95659.2 flags=0x100110 win=0x0 winNum=31852 ctxt=0x126c7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x1E8DB0)> >> >> >> >> (342E94) : 15 (%CALL-NEXT-OBJC-METHOD #> (#x813C00)> #> APPLICATION (#x113ED0)> # (:VOID :ID) >> #> flags=0x100110 win=0x0 winNum=31852 ctxt=0x126c7 chars="o" >> unmodchars="o" repeat=0 keyCode=31 (#x1E8DB0)>) 1191 >> (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) >> CCL::SELF: # >> (#x813C00)> >> CLASS: # >> CCL::SELECTOR: # >> CCL::SIG: (:VOID :ID) >> CCL::ARGS: (#> time=95659.2 flags=0x100110 win=0x0 winNum=31852 ctxt=0x126c7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x1E8DB0)>) >> >> CCL::S: # >> CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE >> (:VOID :ID) :FUNCTION # ...) >> FUNCTION: # >> #:G2643: # >> #:G2644: -268435942 >> >> (342EE4) : 16 (FUNCALL #'# >> -268435882) 1039 >> (#:G5202) >> #:G5202: -268435882 >> >> #:G5218: # >> #:G5203: # >> #:COMPILER-VAR: (NIL) >> #:G5208: #> [LispApplication sendEvent:]|) #xCBEAE> >> #:G5219: (CONDITION #) >> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >> GUI::SELF: # >> (#x813C00)> >> GUI::_CMD: # >> GUI::E: #> flags=0x100110 win=0x0 winNum=31852 ctxt=0x126c7 chars="o" >> unmodchars="o" repeat=0 keyCode=31 (#x1E8DB0)> >> CCL::ARGS: (#> time=95659.2 flags=0x100110 win=0x0 winNum=31852 ctxt=0x126c7 >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x1E8DB0)>) >> >> (342F20) : 17 (%PASCAL-FUNCTIONS% 14 -268435882) 343 >> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >> CCL::INDEX: 14 >> CCL::ARGS-PTR-FIXNUM: -268435882 >> >> CCL::LISP-FUNCTION: #> sendEvent:]| (Non-Global) #x8BF8136> >> WITHOUT-INTERRUPTS: NIL >> CCL::*CALLBACK-TRACE-P*: NIL >> >> (342F68) : 19 (FUNCALL #'# #> APPLICATION (#x813C00)> #S(CCL::OBJC- >> SELECTOR :NAME "run" :%SEL #)) 199 >> (#:G3061 #:G3062) >> #:G3061: # >> (#x813C00)> >> #:G3062: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #> Pointer #x966CAA24>) >> >> >> ***************************************************************************************************************************************************************************************************** >> ********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************** >> THE THIRD >> >> >> >> *** Error in event process: Array index 135 out of bounds for >> "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/". >> >> (342C74) : 0 (FUNCALL #'#<(:INTERNAL GUI::|-[HemlockEditorDocument >> setFileURL:]|)> #) 151 >> (#:G27705) >> #:G27705: # >> >> #:COMPILER-VAR: (NIL) >> #:G27702: # >> >> (342C88) : 1 (SIGNAL #) 903 >> (CONDITION &REST CCL::ARGS) >> CONDITION: # >> CCL::ARGS: NIL >> >> CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) >> CCL::TAG: (CONDITION #) >> CCL::HANDLERS: (CONDITION #) >> CCL::FN: #> [HemlockEditorDocument setFileURL:]|) #xCBD8E> >> >> (342CB0) : 2 (%ERROR # (135 "buffer mark >> ringrs/js/ejs/projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ >> ecrires_et_obtenirs.o/ecrire.o/") 854833) 119 >> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >> CONDITION: # >> CCL::ARGS: (135 "buffer mark ringrs/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/") >> CCL::ERROR-POINTER: 854833 >> >> >> >> (342CC4) : 3 (FUNCALL #'#<(:INTERNAL CCL::ARE CCL::STRING-START- >> END)> "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" 135) 47 >> (CCL::A CCL::I) >> CCL::A: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> CCL::I: 135 >> >> >> >> (342CD4) : 4 (STRING-START-END "buffer mark ringrs/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> ecrire.o/" 0 135) 159 >> (STRING CCL::START CCL::END) >> STRING: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> CCL::START: 0 >> CCL::END: 135 >> >> CCL::LEN: 128 >> >> (342CEC) : 5 (STRING-CMP "buffer mark ringrs/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> ecrire.o/" 0 135 "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" 0 >> 108) 151 >> (CCL::STRING1 CCL::START1 CCL::END1 CCL::STRING2 CCL::START2 >> CCL::END2) >> CCL::STRING1: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> CCL::START1: 0 >> CCL::END1: 135 >> CCL::STRING2: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> CCL::START2: 0 >> CCL::END2: 108 >> >> CCL::ISTART1: 0 >> >> (342D14) : 6 (STRING/= "buffer mark ringrs/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> ecrire.o/" "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" :START1 >> 0 :END1 135 :START2 0 :END2 108) 127 >> (CCL::STRING1 CCL::STRING2 &KEY :START1 :END1 :START2 :END2) >> CCL::STRING1: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> CCL::STRING2: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> CCL::START1: 0 >> CCL::END1: 135 >> CCL::START2: 0 >> CCL::END2: 108 >> >> >> >> (342D48) : 7 (STRING-COMPARE "buffer mark ringrs/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> ecrire.o/" "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" :START1 >> 0 :END1 135 :START2 0 :END2 NIL) 247 >> (HI::S1 HI::S2 &KEY :START1 :END1 :START2 :END2) >> HI::S1: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> HI::S2: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> HI::START1: 0 >> HI::END1: 135 >> HI::START2: 0 >> HI::END2: NIL >> >> HI::END1: 135 >> HI::END2: 108 >> >> (342D80) : 8 (BI-SVPOSITION "buffer mark ringrs/js/ejs/projects/ >> ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> ecrire.o/" #( >> > forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/"> > Node "Listener"> ...) #> CLOSURE (:INTERNAL HEMLOCK-INTERFACE:GETSTRING) #x913980E> :START >> 0 :END 5 :KEY #) 319 >> (HI::ITEM VECTOR HI::TEST &KEY :START :END :KEY) >> HI::ITEM: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> VECTOR: #( >> > forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/"> > Node "Listener"> ...) >> HI::TEST: #> INTERFACE:GETSTRING) #x913980E> >> HI::START: 0 >> HI::END: 5 >> HI::KEY: # >> >> HI::LOW: 0 >> HI::HIGH: 5 >> HI::MID: 2 >> HI::ARRAY-ITEM: > ejs37.0.o/forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ >> ecrire.o/"> >> HI::TEST-ITEM: "ecrire.lisp /users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> >> (342DC0) : 9 (GETSTRING "%obtenir_champ.lisp /Users/js/ejs/ >> projects/ejs37.0.o/forme.o/forme_proportionnelle.o/ >> ecrires_et_obtenirs.o/obtenir.o/obtenir_profils.o/" #> Table>) 527 >> (STRING HI:STRING-TABLE) >> STRING: "%obtenir_champ.lisp /Users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/" >> HI:STRING-TABLE: # >> >> HI::FOLDED: "buffer mark ringrs/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/" >> HI::LEN: 135 >> HI::NODES: #( > 2"> > forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/ecrire.o/"> >> ...) >> HI::NUM-NODES: 6 >> >> (342DE4) : 10 (%SET-BUFFER-NAME # >> "%obtenir_champ.lisp /Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/") 79 >> (HI:BUFFER HI::NAME) >> HI:BUFFER: # >> HI::NAME: "%obtenir_champ.lisp /Users/js/ejs/projects/ejs37.0.o/ >> forme.o/forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/" >> >> >> >> (342DF8) : 11 (FUNCALL #'#> setFileURL:]|> -268436350) 1095 >> (#:G27701) >> #:G27701: -268436350 >> >> #:G27717: # >> #:G27702: # >> #:COMPILER-VAR: (NIL) >> #:G27707: #> [HemlockEditorDocument setFileURL:]|) #xCBD8E> >> #:G27718: (CONDITION #) >> CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) >> GUI::SELF: #> 0x8f7800> (#x8F7800)> >> GUI::_CMD: # >> GUI::URL: #> (#x3893970)> >> GUI::BUFFER: # >> GUI::NEW-PATHNAME: "/Users/js/ejs/projects/ejs37.0.o/forme.o/ >> forme_proportionnelle.o/ecrires_et_obtenirs.o/obtenir.o/ >> obtenir_profils.o/%obtenir_champ.lisp" >> >> (342E38) : 12 (%PASCAL-FUNCTIONS% 115 -268436350) 343 >> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >> CCL::INDEX: 115 >> CCL::ARGS-PTR-FIXNUM: -268436350 >> >> CCL::LISP-FUNCTION: #> [HemlockEditorDocument setFileURL:]| (Non-Global) #x8E68F4E> >> WITHOUT-INTERRUPTS: NIL >> CCL::*CALLBACK-TRACE-P*: NIL >> >> (342E80) : 14 (FUNCALL #'# #> Foreign Pointer [stack-allocated] (:* #) #xBFFFF900> #> Pointer #x966204B8> #> time=96021.4 flags=0x100110 win=0x0 winNum=31951 ctxt=0x12e5f >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x387D760)>) 391 >> (#:G4511 #:G4512 CCL::ARG0) >> #:G4511: # >> #:G4512: # >> CCL::ARG0: #> time=96021.4 flags=0x100110 win=0x0 winNum=31951 ctxt=0x12e5f >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x387D760)> >> >> >> >> (342E94) : 15 (%CALL-NEXT-OBJC-METHOD #> (#x813600)> #> APPLICATION (#x113F20)> # (:VOID :ID) >> #> flags=0x100110 win=0x0 winNum=31951 ctxt=0x12e5f chars="o" >> unmodchars="o" repeat=0 keyCode=31 (#x387D760)>) 1191 >> (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) >> CCL::SELF: # >> (#x813600)> >> CLASS: # >> CCL::SELECTOR: # >> CCL::SIG: (:VOID :ID) >> CCL::ARGS: (#> time=96021.4 flags=0x100110 win=0x0 winNum=31951 ctxt=0x12e5f >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x387D760)>) >> >> CCL::S: # >> CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE >> (:VOID :ID) :FUNCTION # ...) >> FUNCTION: # >> #:G2643: # >> #:G2644: -268435942 >> >> (342EE4) : 16 (FUNCALL #'# >> -268435882) 1039 >> (#:G5202) >> #:G5202: -268435882 >> >> #:G5218: # >> #:G5203: # >> #:COMPILER-VAR: (NIL) >> #:G5208: #> [LispApplication sendEvent:]|) #xCBEAE> >> #:G5219: (CONDITION #) >> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >> GUI::SELF: # >> (#x813600)> >> GUI::_CMD: # >> GUI::E: #> flags=0x100110 win=0x0 winNum=31951 ctxt=0x12e5f chars="o" >> unmodchars="o" repeat=0 keyCode=31 (#x387D760)> >> CCL::ARGS: (#> time=96021.4 flags=0x100110 win=0x0 winNum=31951 ctxt=0x12e5f >> chars="o" unmodchars="o" repeat=0 keyCode=31 (#x387D760)>) >> >> (342F20) : 17 (%PASCAL-FUNCTIONS% 14 -268435882) 343 >> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >> CCL::INDEX: 14 >> CCL::ARGS-PTR-FIXNUM: -268435882 >> >> CCL::LISP-FUNCTION: #> sendEvent:]| (Non-Global) #x8BF8136> >> WITHOUT-INTERRUPTS: NIL >> CCL::*CALLBACK-TRACE-P*: NIL >> >> (342F68) : 19 (FUNCALL #'# #> APPLICATION (#x813600)> #S(CCL::OBJC- >> SELECTOR :NAME "run" :%SEL #)) 199 >> (#:G3061 #:G3062) >> #:G3061: # >> (#x813600)> >> #:G3062: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #> Pointer #x966CAA24>) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Joakim Sandgren >> joakim sandgren musik >> 42, rue de Maubeuge >> 75009 Paris >> France >> +33 (0)1 45 26 43 90 >> info at joakimsandgren.com >> http://www.joakimsandgren.com >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Thu May 14 05:26:59 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Thu, 14 May 2009 14:26:59 +0200 Subject: [Openmcl-devel] array Message-ID: <4ACCEC9C-A3A0-4B51-95DB-512E7EDA65BF@joakimsandgren.com> Hi, So this is the first error *** Error in event process: Array index 129 out of bounds for "buffer mark ringont regionteranding tabs ". seems that the array is the 128 long. if I take away one letter from the file name or the folder name it opens... is it possible to have a longer array ?? Very Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Thu May 14 10:30:57 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 14 May 2009 11:30:57 -0600 (MDT) Subject: [Openmcl-devel] Running CCL as a CGI process is failing, the image can't be loaded In-Reply-To: References: Message-ID: <20090514102715.E22891@abq.clozure.com> When the CCL kernel is run with no arguments, it tries to load its default heap image by 1) determining its own pathname 2) On Windows, removing the ".exe" suffix from the kernel's pathname 3) appending ".image" The last 1 or two steps are pretty simple, but the first step can be surprisingly difficult. A Unix process is usually started when the parent process does a "fork" system call (creating a copy of itself) and the copy/child process does some flavor of "exec" system call. There are usually several variants of "exec" (differing in such things as whether the PATH environment variable is searched and in how the environment is handled), but those variants usually all take arguments that include the path to the executable file and a C array of C strings ("argv") used to provide arguments to the process. (That array -or a copy of it - is accessable as an argument to the C 'main()' function in the new process.) Usually, the 0th element of the argv array is the same as the path to the executable file, but this is just a convention. (Shells usually follow that convention, but I'd be willing to bet that the CGI code that's trying to start CCL isn't doing so.) On Linux, it's possible for a process to reliably determine the path to its own executable file (by looking at kernel information maintained in the /proc psuedo-filesystem.) On other platforms, it either isn't possible or I don't know how to do this. (Darwin offers something called "_NSGetExecutablePath()", but I'm not sure that it really does anything besides look at argv[0] for you.) In the absence of something more reliable, about all that the lisp kernel can do is to look at the 0th element of the argv vector that its main function got as an argument in order to determine its own pathname (step 1 above). If that doesn't return an accurate answer, then the image name returned in step 3 won't be correct, either. I suppose that there are other things (symbolic links and whether they are or aren't being followed) that can confuse the issue, but if the lisp kernel that the CGI mechanism is exec'ing and the heap image that it should load by default are in the same directory and the heap image isn't being found, then it seems most likely that that failure is due to the fact that the kernel can't reliably determine its own pathname, quite possibly because the exec() call that starts the process doesn't set the 0th element of the argv vector to the executable file's pathname. If the CGI mechanism lets you pass arguments to the process, then passing the image file as an argument would be one workaround; if it doesn't, then executing a shell script that passes those arguments would be another.) If this is indeed the problem, then I'd blame neither CCL nor Apache for it, but instead blame "most Unices, for not offering a reliable way for a process to determine its exectable's filename", or "me, for not knowing how to do that on whatever platform you're using." On Thu, 14 May 2009, Douglas Brunner wrote: > I've tried to set up CCL to run as a CGI process to do some web > development. I compiled a very simple program which just displays a > header and a test string. Running the executable as myself, and as > www-data (apache user) from the terminal work as expected, but when > running it through the browser Apache always reports an error saying > that the image can't be loaded. > > I'm wondering where I should be looking, at Apache, or at CCL. > > I've brought this up at a forum > (http://lispforum.com/viewtopic.php?f=2&t=342), there's more info > about the problem there. > > Thanks for any help. > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From rme at clozure.com Thu May 14 18:15:08 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 14 May 2009 21:15:08 -0400 Subject: [Openmcl-devel] documents In-Reply-To: <678B5F31-464F-476B-AFB3-765993094742@joakimsandgren.com> References: <7824EF62-FF7C-4D8F-8ACA-EE5C77F8FD40@joakimsandgren.com> <200905141145.PWB67015@mr02.lnh.mail.rcn.net> <678B5F31-464F-476B-AFB3-765993094742@joakimsandgren.com> Message-ID: On May 14, 2009, at 8:23 AM, Joakim Sandgren wrote: > I just had the idea that it is the total loading path that is out of > bound.. > When I shorten the name of the folder where the file is i could open > it. seems the tha it isnt even in the file but perhaps a array that > is full somewhere?... This should be corrected in both 1.3 and the trunk as of r12064. From rme at clozure.com Thu May 14 20:30:55 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 14 May 2009 23:30:55 -0400 Subject: [Openmcl-devel] wx86cl on international systems In-Reply-To: <6406ba82311f2d36c2755c14d4388fa8.squirrel@webmail.tentpost.com> References: <6406ba82311f2d36c2755c14d4388fa8.squirrel@webmail.tentpost.com> Message-ID: On May 12, 2009, at 8:32 AM, dherring at tentpost.com wrote: > FWIW, clozure is very unhappy if installed in a path containing non- > ascii > characters. > > In cmd.exe, I cd to c:\cclㅁ (c:\cclM where M is the square > Korean > character; any Korean characters in the path have this effect) and run > C:\cclㅁ>wx86cl.exe > log.txt > > The head of log.txt follows, with a very large number of recursive- > lock > errors elided. I believe this is because the lisp kernel (a C program) is responsible for figuring out the path to the CCL directory. The lisp deals well with the UTF-16 encoded pathnames that Windows uses, but the lisp kernel, well, not so much. It looks like we'd need to use GetCommandLineW and CommandLineToArgvW to convert the command line arguments to unicode-style strings, and then change the argument processing and image path name derivation code to use wchar_t functions. I'll open a ticket for this. > > >> Error: value NIL is not of the expected type (OR STRING PATHNAME >> STREAM). >> While executing: PATHNAME-DIRECTORY, in process Initial(0). >> Type :GO to continue, :POP to abort, :R for a list of available >> restarts. >> If continued: Skip (possibly crucial) startup function > CCL::INIT-LOGICAL-DIRECTORIES. >> Type :? for other options. >> Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK. >> While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0). >> Type :POP to abort, :R for a list of available restarts. >> Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK. >> While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0). >> Type :POP to abort, :R for a list of available restarts. > ... > > This is the 1.3 release tarball running on a Korean Windows XP system. > > Later, > Daniel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From gb at clozure.com Thu May 14 21:21:55 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 14 May 2009 22:21:55 -0600 (MDT) Subject: [Openmcl-devel] wx86cl on international systems In-Reply-To: References: <6406ba82311f2d36c2755c14d4388fa8.squirrel@webmail.tentpost.com> Message-ID: <20090514213239.P23990@abq.clozure.com> It'd be interesting to know whether or not passing the heap image name explicitly makes things better, e.g.: cmd prompt> cd C:\cclㅁ cmd prompt> wx86cl wx86cl.image If that isn't provided, then the heap image name is something derived from the kernel name in argv[0], which is likely a full pathname encoded in some 8-bit Windows encoding. open() can presumably handle that encoding, but we wind up putting that 8-bit encoded string somewhere where the code that initializes *HEAP-IMAGE-NAME* would find it (and probably treat it as an ISO-8859-1-encoded C string.) We wind up using the TRUENAME of *HEAP-IMAGE-NAME* to initialize the CCL logical host's translations, and that's where we seem to be dying. If the heap image name is passed on the command line as a relative pathname, TRUENAME winds up prepending the current directory to that, and that happens to use Unicode-aware primitives and should therefore do the right thing. I think you (Matt) are right that we have to at least ensure that the strings that come from the command-line and are passed to the lisp (and used to intialize *HEAP-IMAGE-NAME* and *COMMAND-LINE-ARGUMENT-LIST*) are encoded in some way that we can consistently decode without loss of information. An incompatible change would be to always decode them into native-endian UTF-32 in the kernel and let the lisp side of things deal with that one case. On Thu, 14 May 2009, R. Matthew Emerson wrote: > > On May 12, 2009, at 8:32 AM, dherring at tentpost.com wrote: > >> FWIW, clozure is very unhappy if installed in a path containing non- >> ascii >> characters. >> >> In cmd.exe, I cd to c:\cclㅁ (c:\cclM where M is the square >> Korean >> character; any Korean characters in the path have this effect) and run >> C:\cclㅁ>wx86cl.exe > log.txt >> >> The head of log.txt follows, with a very large number of recursive- >> lock >> errors elided. > > I believe this is because the lisp kernel (a C program) is responsible > for figuring out the path to the CCL directory. The lisp deals well > with the UTF-16 encoded pathnames that Windows uses, but the lisp > kernel, well, not so much. > > It looks like we'd need to use GetCommandLineW and CommandLineToArgvW > to convert the command line arguments to unicode-style strings, and > then change the argument processing and image path name derivation > code to use wchar_t functions. > > I'll open a ticket for this. > > >> >> >>> Error: value NIL is not of the expected type (OR STRING PATHNAME >>> STREAM). >>> While executing: PATHNAME-DIRECTORY, in process Initial(0). >>> Type :GO to continue, :POP to abort, :R for a list of available >>> restarts. >>> If continued: Skip (possibly crucial) startup function >> CCL::INIT-LOGICAL-DIRECTORIES. >>> Type :? for other options. >>> Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK. >>> While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0). >>> Type :POP to abort, :R for a list of available restarts. >>> Error: value NIL is not of the expected type CCL::RECURSIVE-LOCK. >>> While executing: CCL::RECURSIVE-LOCK-PTR, in process Initial(0). >>> Type :POP to abort, :R for a list of available restarts. >> ... >> >> This is the 1.3 release tarball running on a Korean Windows XP system. >> >> Later, >> Daniel >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From herodoug at gmail.com Fri May 15 02:29:17 2009 From: herodoug at gmail.com (Douglas Brunner) Date: Fri, 15 May 2009 17:29:17 +0800 Subject: [Openmcl-devel] Problems using CCL through the CGI protocol Message-ID: At this location (http://www.lispforum.com/viewtopic.php?f=2&t=342) there is a discussion about the difficulties I've had when trying to use CCL for CGI programming. We've mostly identified it as a problem with Apache, and a solution was found for my work computer; but now the exact same issue has popped up on my personal computer. I'm hoping to get to the bottom of the problem because I'd like to use this implementation. Note: the OS on both computers are the same, but the hardware is different. Compiling this program and saving it produces an error (Both listed below). I can't even save the program with a prepended kernel. :The Program (defun test() (format t "Content-type: text/html~%~%") (format t "this is a test")0) :The Error > Error: value NIL is not of the expected type REAL. > While executing: CCL::<-2, in process Initial(0). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > The other problem I have, is that just saving the image and passing it to the kernel also produces an error. :The program (defun test() (format t "Content-type: text/html~%~%") (format t "this is a test")0) (ccl:save-application "app.image") :The error $ /home/doug/Software/ccl/ccl -I /home/doug/trunk/htdocs/app.image Couldn't load lisp heap image from /home/doug/trunk/htdocs/app.image Here is a bit of info about my PC. core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Thanks for any help From gb at clozure.com Fri May 15 03:43:32 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 15 May 2009 04:43:32 -0600 (MDT) Subject: [Openmcl-devel] Problems using CCL through the CGI protocol In-Reply-To: References: Message-ID: <20090515035205.S32196@abq.clozure.com> On Fri, 15 May 2009, Douglas Brunner wrote: > At this location (http://www.lispforum.com/viewtopic.php?f=2&t=342) > there is a discussion about the difficulties I've had when trying to > use CCL for CGI programming. I read both pages of that thread and still don't know what version of CCL you're running. Someone in that thread said something about Ubuntu; if that was you, it might be possible to conclude that you're running under Linux. Both pieces of information are often very useful; when in doubt about whether to provide them, it's generally better to err on the side of doing so: it's easier to ignore the information if it's not relevant than to have to guess if it might be. > > We've mostly identified it as a problem with Apache, and a solution > was found for my work computer; but now the exact same issue has > popped up on my personal computer. I'm hoping to get to the bottom of > the problem because I'd like to use this implementation. > > Note: the OS on both computers are the same, but the hardware is different. > > Compiling this program and saving it produces an error (Both listed > below). I can't even save the program with a prepended kernel. > > :The Program > > (defun test() > (format t "Content-type: text/html~%~%") > (format t "this is a test")0) > > > :The Error > >> Error: value NIL is not of the expected type REAL. >> While executing: CCL::<-2, in process Initial(0). >> Type :POP to abort, :R for a list of available restarts. >> Type :? for other options. > 1 > > It's very hard to know what the problem is without knowing anything about the execution context in which that error occurred. Generating a backtrace at the break loop prompt (and including that output in a bug report) can provide helpful context information. Without that, all that anyone can do is agree that NIL isn't of type REAL and shouldn't have been passed as an argument to CCL::<-2 (which is the function that implements the two-argument case of #'<), but it'd be more interesting why something's calling that function with NIL as an argument. > > The other problem I have, is that just saving the image and passing it > to the kernel also produces an error. How is this different from "saving the program" which led to the error above ? > > :The program > > (defun test() > (format t "Content-type: text/html~%~%") > (format t "this is a test")0) > > (ccl:save-application "app.image") > > :The error > > $ /home/doug/Software/ccl/ccl -I /home/doug/trunk/htdocs/app.image > Couldn't load lisp heap image from /home/doug/trunk/htdocs/app.image Does: $ ls -l /home/doug/trunk/htdocs/app.image show that the "app.image" file to be about the same size as the distributed default image file (whose name I could refer to if I knew what version of the lisp you were running and on what platform ?) Does that show anything else unusual about the file or its permissions ? There are certainly other things that can go wrong (and the image loader could afford to say something more helpful about them), but the terse "Can't load lisp heap image ..." message almost always means one of: 1) the file doesn't exist 2) the file can't be opened for reading 3) the file can be opened for reading but doesn't contain the expected signature bytes that identify it as a heap image file. Other things that could cause a failure to load the file - I/O errors, memory-management things - will generally do a better job of describing the failure. From joakim at joakimsandgren.com Fri May 15 04:23:47 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 15 May 2009 13:23:47 +0200 Subject: [Openmcl-devel] documents In-Reply-To: References: <7824EF62-FF7C-4D8F-8ACA-EE5C77F8FD40@joakimsandgren.com> <200905141145.PWB67015@mr02.lnh.mail.rcn.net> <678B5F31-464F-476B-AFB3-765993094742@joakimsandgren.com> Message-ID: <00A62B65-1C1F-4CCD-A026-9E79FA75EF9A@joakimsandgren.com> oh, I had this in 1.3-r11936. the downloadable diskimage... Joakim Le 15 mai 09 ? 03:15, R. Matthew Emerson a ?crit : > > On May 14, 2009, at 8:23 AM, Joakim Sandgren wrote: > >> I just had the idea that it is the total loading path that is out >> of bound.. >> When I shorten the name of the folder where the file is i could >> open it. seems the tha it isnt even in the file but perhaps a >> array that is full somewhere?... > > This should be corrected in both 1.3 and the trunk as of r12064. > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Fri May 15 09:40:05 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 15 May 2009 18:40:05 +0200 Subject: [Openmcl-devel] list of commands Message-ID: <4CAC3495-6014-495B-90C2-E2DFCECC8AD2@joakimsandgren.com> Hi, I'm sorry, someone send me a very good list of commands (in mcl lispworks, ccl what worked in all, only ccl only lispworks etc etc. Super. But I can't find again. Could someone show me where it is? I am looking for commands in the inspector window in the diskimage 1.3 on mac intel. SIncerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaj at clozure.com Fri May 15 09:49:59 2009 From: jaj at clozure.com (Jeremy Jones) Date: Fri, 15 May 2009 12:49:59 -0400 Subject: [Openmcl-devel] list of commands In-Reply-To: <4CAC3495-6014-495B-90C2-E2DFCECC8AD2@joakimsandgren.com> References: <4CAC3495-6014-495B-90C2-E2DFCECC8AD2@joakimsandgren.com> Message-ID: You can find it here: http://trac.clozure.com/openmcl/wiki/CocoaIde/KeyBindingsComparison On Fri, May 15, 2009 at 12:40 PM, Joakim Sandgren wrote: > Hi, > I'm sorry, someone send me a very good list of commands (in mcl lispworks, > ccl what worked in all, only ccl only lispworks etc etc. Super. > But I can't find again. Could someone show me where it is? > I am looking for commands in the inspector window in the diskimage 1.3 on > mac intel. > SIncerely > Joakim > > > > Joakim Sandgren > joakim sandgren musik > 42, rue de Maubeuge > 75009 Paris > France > +33 (0)1 45 26 43 90 > info at joakimsandgren.com > http://www.joakimsandgren.com > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From joakim at joakimsandgren.com Fri May 15 09:51:10 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 15 May 2009 18:51:10 +0200 Subject: [Openmcl-devel] list of commands In-Reply-To: References: <4CAC3495-6014-495B-90C2-E2DFCECC8AD2@joakimsandgren.com> Message-ID: <5778CF02-EB07-4088-8FDC-1A43674256BF@joakimsandgren.com> Super! Thank You! Joakim Le 15 mai 09 ? 18:47, Jeremy Jones a ?crit : > You can find it here: > http://trac.clozure.com/openmcl/wiki/CocoaIde/KeyBindingsComparison > > On Fri, May 15, 2009 at 12:40 PM, Joakim Sandgren > wrote: >> Hi, >> I'm sorry, someone send me a very good list of commands (in mcl >> lispworks, >> ccl what worked in all, only ccl only lispworks etc etc. Super. >> But I can't find again. Could someone show me where it is? >> I am looking for commands in the inspector window in the diskimage >> 1.3 on >> mac intel. >> SIncerely >> Joakim >> >> >> >> Joakim Sandgren >> joakim sandgren musik >> 42, rue de Maubeuge >> 75009 Paris >> France >> +33 (0)1 45 26 43 90 >> info at joakimsandgren.com >> http://www.joakimsandgren.com >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at joakimsandgren.com Fri May 15 09:55:18 2009 From: info at joakimsandgren.com (Joakim Sandgren) Date: Fri, 15 May 2009 18:55:18 +0200 Subject: [Openmcl-devel] windows Message-ID: <2583A6BF-549B-43A9-A26C-C7809CD96167@joakimsandgren.com> Hi, Is it very far until we have "remember window positions"? I think this is really really important to be able to dispose your windows as you want. and to find them like that when you return. to just start to work again. I think this is almost more important than syntax-coloring (that is also very important!) Is this very difficult to do? Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lisp at clairvaux.org Fri May 15 11:08:05 2009 From: lisp at clairvaux.org (Glen Foy) Date: Fri, 15 May 2009 14:08:05 -0400 Subject: [Openmcl-devel] windows In-Reply-To: <2583A6BF-549B-43A9-A26C-C7809CD96167@joakimsandgren.com> References: <2583A6BF-549B-43A9-A26C-C7809CD96167@joakimsandgren.com> Message-ID: <65567907-5C0E-484C-B510-12E118F54E0E@clairvaux.org> On May 15, 2009, at 12:55 PM, Joakim Sandgren wrote: > Hi, > Is it very far until we have "remember window positions"? > I think this is really really important to be able to dispose your > windows as you want. and to find them like that when you return. to > just start to work again. > > I think this is almost more important than syntax-coloring (that is > also very important!) Window positioning is important to me also. It seems half my life is spent moving and resizing windows. I have some old MCL code that lets you define "parking spots" for you editor windows. Every time you open a window it is automatically sized and placed in one of these parking spots. If all your parking spots are full, the least recently opened window is closed and placed on a file history list. You can move your file around with function keys, get access to the file history list through a popup menu, etc. There is also a positions history list, and both of these lists are saved and reloaded at the start of each session. I will eventually port this to CCL. No more manually sizing and moving window. Right now I'm working on porting some Fred syntax styling code, your second request. It's not fun debugging code that has to run in the Cocoa event thread. We really need a solution for this, and I feel sure we will get a solution before long. Either Gary will do something dazzling with threads, and events, and break loops, or maybe a Cocoa based Slime would be good solution. Currently debugging callback code is a bit like root canal. Not something you'd want to do everyday. The syntax styling code is ready for full font support. As soon as we get persistent text attributes, it will be ready to go. -Glen From joakim at joakimsandgren.com Fri May 15 13:11:48 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 15 May 2009 22:11:48 +0200 Subject: [Openmcl-devel] windows In-Reply-To: <65567907-5C0E-484C-B510-12E118F54E0E@clairvaux.org> References: <2583A6BF-549B-43A9-A26C-C7809CD96167@joakimsandgren.com> <65567907-5C0E-484C-B510-12E118F54E0E@clairvaux.org> Message-ID: <99B77C22-0799-4124-9B4F-6564458962BA@joakimsandgren.com> thank you for infos! hope you can do something with the mcl-code. that'll be really super when it comes! and the coloring also... can't wait ;-) I was starting to believe that you where supposed to do this in cocoa- bridge-ccl nswindow yourself... so your mcl-solution sounds good... Sincerely Joakim Le 15 mai 09 ? 20:08, Glen Foy a ?crit : > > On May 15, 2009, at 12:55 PM, Joakim Sandgren wrote: > >> Hi, >> Is it very far until we have "remember window positions"? >> I think this is really really important to be able to dispose your >> windows as you want. and to find them like that when you return. to >> just start to work again. >> >> I think this is almost more important than syntax-coloring (that is >> also very important!) > > Window positioning is important to me also. It seems half my life is > spent moving and resizing windows. > > I have some old MCL code that lets you define "parking spots" for you > editor windows. Every time you open a window it is automatically > sized and placed in one of these parking spots. If all your parking > spots are full, the least recently opened window is closed and placed > on a file history list. > > You can move your file around with function keys, get access to the > file history list through a popup menu, etc. There is also a > positions history list, and both of these lists are saved and reloaded > at the start of each session. > > I will eventually port this to CCL. No more manually sizing and > moving window. > > Right now I'm working on porting some Fred syntax styling code, your > second request. It's not fun debugging code that has to run in the > Cocoa event thread. We really need a solution for this, and I feel > sure we will get a solution before long. Either Gary will do > something dazzling with threads, and events, and break loops, or maybe > a Cocoa based Slime would be good solution. Currently debugging > callback code is a bit like root canal. Not something you'd want to > do everyday. > > The syntax styling code is ready for full font support. As soon as we > get persistent text attributes, it will be ready to go. > > -Glen > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Fri May 15 22:56:13 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Fri, 15 May 2009 23:56:13 -0600 Subject: [Openmcl-devel] time travel Message-ID: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> In some animations I found irregularities which I traced back to some strange behavior of mach_absolute_time This loop should produce no output. On PPCs it works but on my Intel- Mac (with CCL 32) I get some output indicating that once in a while my computer appears to travel back in time for about 4 seconds (dotimes (i 1000) (let ((t1 (#_mach_absolute_time))) (sleep 0.01) (let ((t2 (#_mach_absolute_time))) (when (> t1 t2) (print (- t2 t1)))))) -4284773073 -4284777830 -4284869530 Can anybody reproduce this and is there any explanation, work around for this kind of madness? Alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Sat May 16 00:31:17 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Sat, 16 May 2009 01:31:17 -0600 Subject: [Openmcl-devel] XMLisp application in Google Code Message-ID: <5ACE1EFA-9509-4FEF-9650-9A7B1A328432@cs.colorado.edu> This is still mostly an experiment in making OpenGL and GUI components as accessible as possible. You can find ready to go apps at Google Code including a number of 3D + 2D examples: http://code.google.com/p/xmlisp/downloads/list Hemlock is extended with anticipatory symbol completion and OpenGL redbook syntax support The app may want to load your ccl-init.lisp file. An :init-file keyword would be nice to control that a little better. See if you can translate some of the NeHe tutorials: http://nehe.gamedev.net/ happy 3D hacking, Alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Sat May 16 05:23:58 2009 From: gb at clozure.com (Gary Byers) Date: Sat, 16 May 2009 06:23:58 -0600 (MDT) Subject: [Openmcl-devel] time travel In-Reply-To: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> References: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> Message-ID: <20090516000547.I35368@abq.clozure.com> AFAIK, mach_absolute_time() is implemented in terms of the "rdtsc" (Read Time Stamp Counter") instruction, which returns the value of a 64-bit on-chip counter that increments once every machine cycle. There are a few things that can make it difficult to use the value returned by rdtsc for high-resolution timing. 1) the time-stamp counters are per-cpu, which generally means that unless the OS takes steps to get and keep the TSCs of all CPU cores in sync, the value returned by a rdtsc executed on CPU B may be less than a value returned on CPU A. As far as I know, OSX deals with this pretty well. 2) CPUs (especially those used in laptops and many consumer machines) don't always run at the same clock rate these days; they'll often switch into low-power states where the number of machine cycles per second is less then the maximum. On a Core2-Quad desktop machine running Linux $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 2394000 1596000 which says that a machine marketed as having a 2.4GHz CPU can also run at a bit under 1.6GHz. Things like mach_absolute_time() have to be able to account for the fact that the CPU frequency is dynamic (and therefore the values returned by rdtsc have to be scaled by different amounts depending on the CPU frequency.) I'm sure that mach_absolute_time() does deal with this, but I remember looking at the code once and thinking that it was a lot more complicated than I would have guessed. 3) [Even fuzzier.] 'rdtsc' instructions can be virtualized (meaning that things like VMWare and Parallels can detect their use by at least some programs.) I don't know enough about the technology involved to know whether this means that a 'hypervisor' (or whatever they call it) can affect the results returned by rdtsc to host-OS programs. Both the result of the rdtsc instruction and the 64-bit integer returned by mach_absolute_time() are returned as a pair of 32-bit integers (containing the low and high 32 bits of the result.) I find it awfully suspicious that the absolute value of difference between t2 and t1 in the cases where time travel occurred is as close as it is to 2^32 (as if some code in mach_absolute_time() neglected to add a carry bit out of the low half into the high half. CCL just takes those 2 32-bit halves of mach_absolute_time()'s result and makes a lisp integer (almost always a bignum in the 32-bit lisp) out of them. (There -is- a bug here, in that 64-bit return values from foreign function calls aren't handled correctly in the x8632 CCL when the argument and return-value processing occur out of line; in your DOTIMES loop, that'd all happen in compiled code unless DEBUG or SAFETY optimize settings are cranked up, and I don't think that there's a problem when they aren't. So yes, I can think of a few explanations. I have no idea if any of them is correct, or what the workaround would be. FWIW, I can't get the DOTIMES loop below to fail unless I add a "(DECLARE (OPTIMIZE (SAFETY 3)))"; when it fails in that case, it's confused about the sign bit of the low 32 bits of the result (bit 31), and you're seeing apparent confusion about the value of the low bit of the high 32 bits (bit 32). On Fri, 15 May 2009, Alexander Repenning wrote: > In some animations I found irregularities which I traced back to some strange > behavior of mach_absolute_time > > This loop should produce no output. On PPCs it works but on my Intel-Mac > (with CCL 32) I get some output indicating that once in a while my computer > appears to travel back in time for about 4 seconds > > (dotimes (i 1000) > (let ((t1 (#_mach_absolute_time))) > (sleep 0.01) > (let ((t2 (#_mach_absolute_time))) > (when (> t1 t2) (print (- t2 t1)))))) > > -4284773073 > -4284777830 > -4284869530 > > Can anybody reproduce this and is there any explanation, work around for this > kind of madness? > > Alex > > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > From ralex at cs.colorado.edu Sat May 16 08:31:00 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Sat, 16 May 2009 09:31:00 -0600 Subject: [Openmcl-devel] time travel In-Reply-To: <20090516000547.I35368@abq.clozure.com> References: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> <20090516000547.I35368@abq.clozure.com> Message-ID: <13C049BA-5671-42E4-A5F1-2FBE29A1E3B2@cs.colorado.edu> thanks Gary, I think you are right that the reported time warps are just suspiciously close to 2^32 nano seconds (~4.3 seconds) and the frequency of these time drift events is also matching, i.e., in the 10 second loop the problem appears 2-3 times on average. I did add the less than max safety and it does appear to do the trick but just leaves me worried a bit that the "less save" code works better than the save one. (defun warp () (declare (optimize (safety 2))) (dotimes (i 1000) (let ((t1 (#_mach_absolute_time))) (sleep 0.01) (let ((t2 (#_mach_absolute_time))) (when (> t1 t2) (print (- t2 t1))))))) In CCL intel 64 the problem never seems to manifest itself. For now I can get by with this solution. Is there any reason to think why this could change in the future again or could (declare (optimize (safety 2))) have any negative consequences in CCL 64? alex On May 16, 2009, at 6:23 AM, Gary Byers wrote: > AFAIK, mach_absolute_time() is implemented in terms of the > "rdtsc" (Read Time > Stamp Counter") instruction, which returns the value of a 64-bit on- > chip > counter that increments once every machine cycle. > > There are a few things that can make it difficult to use the value > returned > by rdtsc for high-resolution timing. > > 1) the time-stamp counters are per-cpu, which generally means that > unless the > OS takes steps to get and keep the TSCs of all CPU cores in sync, > the value > returned by a rdtsc executed on CPU B may be less than a value > returned on > CPU A. As far as I know, OSX deals with this pretty well. > > 2) CPUs (especially those used in laptops and many consumer machines) > don't always run at the same clock rate these days; they'll often > switch into low-power states where the number of machine cycles per > second > is less then the maximum. On a Core2-Quad desktop machine running > Linux > > $ cat /sys/devices/system/cpu/cpu0/cpufreq/ > scaling_available_frequencies 2394000 1596000 > > which says that a machine marketed as having a 2.4GHz CPU can also > run at > a bit under 1.6GHz. > > Things like mach_absolute_time() have to be able to account for the > fact that > the CPU frequency is dynamic (and therefore the values returned by > rdtsc have > to be scaled by different amounts depending on the CPU frequency.) > I'm sure > that mach_absolute_time() does deal with this, but I remember > looking at the > code once and thinking that it was a lot more complicated than I > would have > guessed. > > 3) [Even fuzzier.] 'rdtsc' instructions can be virtualized (meaning > that things > like VMWare and Parallels can detect their use by at least some > programs.) I > don't know enough about the technology involved to know whether this > means that > a 'hypervisor' (or whatever they call it) can affect the results > returned by > rdtsc to host-OS programs. > > Both the result of the rdtsc instruction and the 64-bit integer > returned by mach_absolute_time() are returned as a pair of 32-bit > integers (containing the low and high 32 bits of the result.) I find > it awfully suspicious that the absolute value of difference between t2 > and t1 in the cases where time travel occurred is as close as it is to > 2^32 (as if some code in mach_absolute_time() neglected to add a carry > bit out of the low half into the high half. > > CCL just takes those 2 32-bit halves of mach_absolute_time()'s result > and makes a lisp integer (almost always a bignum in the 32-bit lisp) > out of them. (There -is- a bug here, in that 64-bit return values from > foreign function calls aren't handled correctly in the x8632 CCL when > the argument and return-value processing occur out of line; in your > DOTIMES loop, that'd all happen in compiled code unless DEBUG or > SAFETY > optimize settings are cranked up, and I don't think that there's a > problem > when they aren't. > > So yes, I can think of a few explanations. I have no idea if any of > them > is correct, or what the workaround would be. > > FWIW, I can't get the DOTIMES loop below to fail unless I add a > "(DECLARE (OPTIMIZE (SAFETY 3)))"; when it fails in that case, it's > confused about the sign bit of the low 32 bits of the result (bit 31), > and you're seeing apparent confusion about the value of the low bit of > the high 32 bits (bit 32). > > > On Fri, 15 May 2009, Alexander Repenning wrote: > >> In some animations I found irregularities which I traced back to >> some strange behavior of mach_absolute_time >> >> This loop should produce no output. On PPCs it works but on my >> Intel-Mac (with CCL 32) I get some output indicating that once in a >> while my computer appears to travel back in time for about 4 seconds >> >> (dotimes (i 1000) >> (let ((t1 (#_mach_absolute_time))) >> (sleep 0.01) >> (let ((t2 (#_mach_absolute_time))) >> (when (> t1 t2) (print (- t2 t1)))))) >> >> -4284773073 >> -4284777830 >> -4284869530 >> >> Can anybody reproduce this and is there any explanation, work >> around for this kind of madness? >> >> Alex >> >> >> Prof. Alexander Repenning >> >> University of Colorado >> Computer Science Department >> Boulder, CO 80309-430 >> >> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> >> > Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Sat May 16 20:03:51 2009 From: gb at clozure.com (Gary Byers) Date: Sat, 16 May 2009 21:03:51 -0600 (MDT) Subject: [Openmcl-devel] time travel In-Reply-To: <13C049BA-5671-42E4-A5F1-2FBE29A1E3B2@cs.colorado.edu> References: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> <20090516000547.I35368@abq.clozure.com> <13C049BA-5671-42E4-A5F1-2FBE29A1E3B2@cs.colorado.edu> Message-ID: <20090516143625.E35368@abq.clozure.com> On Sat, 16 May 2009, Alexander Repenning wrote: > thanks Gary, > > I think you are right that the reported time warps are just suspiciously > close to 2^32 nano seconds (~4.3 seconds) and the frequency of these time > drift events is also matching, i.e., in the 10 second loop the problem > appears 2-3 times on average. > > I did add the less than max safety and it does appear to do the trick but > just leaves me worried a bit that the "less save" code works better than the > save one. There's a function named CL:CDR. There isn't much to it: it checks that it gets exactly one argument, checks that that argument is a LIST, and edoes a simple memory reference and returns the result. The function #'CL:CDR exists; we can call it from the REPL, pass #'CL:CDR as an argument to mapping functions, etc., but we hardly ever actually call #'CL:CDR at runtime: the compiler can usually perform the number-of-args check at compile-time, and generating the typecheck (in safe code) and the memory reference inline is a lot faster (and no less safe in most cases) than actually calling #'CL:CDR would be, and the only real costs of open-coding calls to CDR are: 1) you can't use things like TRACE to observe calls to CDR, since no actual function call occurs. 2) the compiler may interpret whatever combination of TYPE and OPTIMIZE declarations are in effect as a request to skip the typecheck. Code compiled with an (OPTIMIZE (SAFETY 3) ...) declaration in effect has to be as safe as the implementation can make it. Rather than looking at every primitive operation that the compiler knows about and ensuring that potentially unsafe optimizations were inhibited when SAFETY 3 is in effect, CCL basically tries to avoid open-coding calls to any functions (including primitive things like CDR and AREF and + ...). That's generally correct, but it imposes a huge performance hit in some cases, in exchange for what may be little or no actual gain in safety. (Rather than ensuring that all calls to CDR were maximally safe by compiling a function call to #'CDR, the compiler could continue to open-code CDR but simply refuse to omit the type-check when SAFETY 3 was in effect.) Suppose (just to strain credibility a little) that rather than being "rarely actually called", #'CDR was "almost never actually called", and that because of a cut-and-paste mishap it returned the CAR of its argument rather then the CDR. That would mean that calls to CDR from code generated with SAFETY 3 (the way that CCL currently implements SAFETY 3) in effect return the wrong answer; that'd expose a bug in CDR, but that'd be ... a bug in CDR, not a safety issue (assuming that the buggy CDR function was "safe" - checked that it received one arg of type LIST - but returned the wrong answer.) CCL::%FF-CALL is a function (used to do foreign function calls); it takes a strange argument list (consisting of alternating keywords that denote foreign argument types and values to be used for the coresponding argument, an optional keyword denoting the foreign type of the result, and maybe some nightmarish platform-specific gunk that describes how to deal with ABI arcana. The function has to interpret these arguments, reserve space for the argument values (somewhere where the foreign code can find them), store the unboxed equivalent of each argument in the right place in that reserved space (according to ABI details), arrange to call the foreign code, and return a lisp representation of the foreign result. That's all incredibly complicated, and it has to be done each time that CCL::%FF-CALL is actually called. Fortunately, most uses of CCL::%FF-CALL are the results of macroexpanding whatever the #_ reader macro generates (or of macroexpanding CCL:EXTERNAL-CALL or CCL:FF-CALL) and the keywords that describe the foreign arg and result types are usually constants, which means that the compiler can open-code calls to CCL::%FF-CALL, knowing how much space will be required for the argument values, knowing the foreign type of each argument and therefore how it's to be unboxed and passed to the foreign code, knowing the foreign type of the result, and knowing how to deal with any platform-specific arcana. It's still very complicated, but most of the complexity happens at compile-time, and the compiler mostly just generates code to reserve N bytes of foreign argument space, store M values into precomputed locations in that reserved space, etc. That code's pretty heavily exercised, and any outright bugs in it are probably pretty obscure. There still needs to be a #'CCL::%FF-CALL function (for the same reason that there needs to be a #'CL:CDR). (For a long time in MCL and possibly for some time in CCL, the implementation of #'CCL::%FF-CALL called the compiler at runtime and then FUNCALLed the result.) These days in CCL, #'CCL::%FF-CALL is implemented as a hairy, platform-specific mixture of low-level lisp and LAP code. It generally works, but it's not exercised nearly as much as the open-coded case is. (Someone found a bug in the PPC32 version a week or so ago; that bug's probably been there for 10 years or so.) It's relatively rare for foreign functions on 32-bit platfroms to return 64-bit integer values (and when they do so, they do so somewhat awkwardly, in two 32-bit pieces.) The x8632 version of #'CCL::%FF-CALL didn't handle this correctly (Matt checked in a fix a few hours ago), so calls to #_mach_absolute_time were returning an incorrect value. So, it's possible for code compiled with SAFETY 3 to encounter bugs that aren't encountered at other SAFETY levels, and the same may be true of other optimization settings.. The wrong value was returned not because #'CCL::%FF-CALL was "unsafe", but because it didn't handle 64-bit return values correctly. From ron at awun.net Sat May 16 23:20:33 2009 From: ron at awun.net (Ron Garret) Date: Sat, 16 May 2009 23:20:33 -0700 Subject: [Openmcl-devel] Automating the build In-Reply-To: <13C049BA-5671-42E4-A5F1-2FBE29A1E3B2@cs.colorado.edu> References: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> <20090516000547.I35368@abq.clozure.com> <13C049BA-5671-42E4-A5F1-2FBE29A1E3B2@cs.colorado.edu> Message-ID: <62EEDEC9-C070-4CC4-98AD-4D9012D04CF9@awun.net> I wrote myself a little script that automatically does an SVN update and rebuilds CCL. That script includes the following line: ./dx86cl64 -n -e "(require 'cocoa-application)" When I try to execute this, it mostly works, that is, it does rebuild the IDE, but before it finishes it pops up a window that says, "The file "(require 'cocoa-application)" could not be found" which has to be manually dismissed before the script will finish. Is this a bug? A feature? Is there a workaround? Thanks, rg From gb at clozure.com Sun May 17 00:41:29 2009 From: gb at clozure.com (Gary Byers) Date: Sun, 17 May 2009 01:41:29 -0600 (MDT) Subject: [Openmcl-devel] Automating the build In-Reply-To: <62EEDEC9-C070-4CC4-98AD-4D9012D04CF9@awun.net> References: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> <20090516000547.I35368@abq.clozure.com> <13C049BA-5671-42E4-A5F1-2FBE29A1E3B2@cs.colorado.edu> <62EEDEC9-C070-4CC4-98AD-4D9012D04CF9@awun.net> Message-ID: <20090517012237.N45383@abq.clozure.com> Doing (require "COCOA-APPLICATION") briefly initializes the IDE, then PROCESS-INTERRUPTs the event thread, telling it to save an image. The event thread gets far enough to run NSApplication's #/finishLaunching method, which is documented as being something which: "Activates the receiver, opens any files specified by the NSOpen user default, and unhighlights the application's icon." I have a hunch that that description hasn't been changed since the NeXT, where phrases like "the NSOpen user default" may have had more meaning. What the method currently tries to do is to look at the command line arguments, not really understand what it sees, and conclude that the argument "(require 'cocoa-application)" must be a file that needs to be opened. Wackiness ensues. I don't think that it's really necessary to start the event loop in response to (REQUIRE "COCOA-APPLICATION"). Unless/until that's changed, you can probably avoid this by doing echo "(require 'cocoa-application)" | ./dx86cl64 -n On Sat, 16 May 2009, Ron Garret wrote: > I wrote myself a little script that automatically does an SVN update > and rebuilds CCL. That script includes the following line: > > ./dx86cl64 -n -e "(require 'cocoa-application)" > > When I try to execute this, it mostly works, that is, it does rebuild > the IDE, but before it finishes it pops up a window that says, "The > file "(require 'cocoa-application)" could not be found" which has to > be manually dismissed before the script will finish. > > Is this a bug? A feature? Is there a workaround? > > Thanks, > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From ron at awun.net Sun May 17 00:50:19 2009 From: ron at awun.net (Ron Garret) Date: Sun, 17 May 2009 00:50:19 -0700 Subject: [Openmcl-devel] Automating the build In-Reply-To: <20090517012237.N45383@abq.clozure.com> References: <154A8D5A-BD16-49F3-A6C5-8B0D28C49AA5@cs.colorado.edu> <20090516000547.I35368@abq.clozure.com> <13C049BA-5671-42E4-A5F1-2FBE29A1E3B2@cs.colorado.edu> <62EEDEC9-C070-4CC4-98AD-4D9012D04CF9@awun.net> <20090517012237.N45383@abq.clozure.com> Message-ID: Thanks! BTW, I've just now had a chance to try version 1.3 for the first time. It looks really great! rg On May 17, 2009, at 12:41 AM, Gary Byers wrote: > Doing (require "COCOA-APPLICATION") briefly initializes the IDE, > then PROCESS-INTERRUPTs the event thread, telling it to save > an image. > > The event thread gets far enough to run NSApplication's #/ > finishLaunching > method, which is documented as being something which: > > "Activates the receiver, opens any files specified by the NSOpen user > default, and unhighlights the application's icon." > > I have a hunch that that description hasn't been changed since the > NeXT, where phrases like "the NSOpen user default" may have had more > meaning. What the method currently tries to do is to look at the > command line arguments, not really understand what it sees, and > conclude > that the argument "(require 'cocoa-application)" must be a file that > needs to be opened. Wackiness ensues. > > I don't think that it's really necessary to start the event loop > in response to (REQUIRE "COCOA-APPLICATION"). Unless/until that's > changed, you can probably avoid this by doing > > echo "(require 'cocoa-application)" | ./dx86cl64 -n > > > > On Sat, 16 May 2009, Ron Garret wrote: > >> I wrote myself a little script that automatically does an SVN update >> and rebuilds CCL. That script includes the following line: >> >> ./dx86cl64 -n -e "(require 'cocoa-application)" >> >> When I try to execute this, it mostly works, that is, it does rebuild >> the IDE, but before it finishes it pops up a window that says, "The >> file "(require 'cocoa-application)" could not be found" which has to >> be manually dismissed before the script will finish. >> >> Is this a bug? A feature? Is there a workaround? >> >> Thanks, >> rg >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> From ron at awun.net Sun May 17 09:57:01 2009 From: ron at awun.net (Ron Garret) Date: Sun, 17 May 2009 09:57:01 -0700 Subject: [Openmcl-devel] Loading compiled version of CL+SSL hangs the IDE Message-ID: Subject line pretty much says it all. The problem is in the file bio.lisp. Loading bio.dx64fsl causes the IDE to hang (SBBOD). Loading bio.lisp works fine, as does loading bio.dx64fsl into CCL without the IDE. The file doesn't actually do anything except define CFFI functions and callbacks, so I'm stumped. This is a clean checkout and build of CCL 1.3. rg From ron at awun.net Sun May 17 11:40:01 2009 From: ron at awun.net (Ron Garret) Date: Sun, 17 May 2009 11:40:01 -0700 Subject: [Openmcl-devel] IDE laundry list Message-ID: Finally got around to trying out 1.3 and all in all I have to say it is much improved, good enough that I may actually go back to using Lisp for a real project for the first time after many years of wandering in the Python desert. There are, however, a few things that I consider, um, annoying deviations from the behavior that I came to know and love under Fred. I'm putting them in an email because most of these don't really qualify as bugs (but a few do) and are largely a matter of taste. So I'm posting this to the list to see if other people feel the same way I do. 1. This one actually qualifies as a bug, and I believe there's a long- standing ticket open on it: When you double-click on a close-paren that is at the end of a buffer, the corresponding S-expression does not get selected. Instead, what happens depends on the character immediately to the left of the close-paren. If that character is itself a close-paren, then the S-expression corresponding to *that* close-paren is selected, otherwise the final close-parent character itself is selected. 2. In my old MCL environment I had a function key bound to a function that pretty-printed the macroexpansion of the current sexpr. I used that almost as much as meta-point, maybe more, and I really miss it. I get the feeling that if I dug deeply enough I could figure out how to add this myself, but I would really like to see it be a standard part of CCL. 3. Selection collapsing is not done properly. (I believe someone else mentioned this here not too long ago, but I'm including it on my list for completeness.) Apple's UI guidelines are very specific on what happens when you hit various keys while there is an active selection. The behavior of the CCL GUI doesn't seem to follow any of them. In fact, it is hard to figure out exactly what the actual behavior even *is*. As near as I can tell, if the current selection is a sexpr, then the cursor goes to the beginning of the selection, plus or minus one character depending on whether the selection was collapsed with the left or right arrow. If the selection was not a sexpr then the same thing happens except the cursor goes to the end of the selection instead of the beginning. This is annoyingly random. Also, if the selection is collapsed with the return key, the current selection should be replaced by a newline, but instead the selection is collapsed before inserting a newline. (This one should be really easy to fix because the behavior for regular characters seems to be correct.) 4. The behavior of the return key in the listener is also annoying. Hemlock seems to make a stronger distinction between input and non- input areas of the listener than Fred did. If the cursor is in an input area, then the contents of that input area replaces the contents of the bottommost input area, regardless of whether or not there is a current selection. If the cursor is in a non-input area then it simply returns to the end of the buffer. And if there is a current selection in a non-input area then it extends the current selection to the end of the buffer (!). The Right Behavior, IMO, is something closer to what Fred did: regardless of whether the cursor (or current selection) is in an input area or non-input area, when you hit the return key, the current selection (if there is one) or current sexpr (if there isn't) should be ADDED to the current input at the end of the buffer, not replace it. 5. The new way of balancing parens is not bad, a vast improvement over the way it was before, but it would be nice to be able to customize the highlighting. In particular, I'd like to be able to change the color. That cyan doesn't resonate well with me for some reason. Even better, I'd like to be able to change both the background color *and* the color and style of the glyph (in which case I'd probably choose for the background color to be white, and highlight matching parens by making them bold, but that's just me). That last one is a pretty minor nit though. If all these things -- or even just the first four -- were fixed then I would be a very happy hacker indeed. rg From joakim at joakimsandgren.com Sun May 17 13:34:12 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sun, 17 May 2009 22:34:12 +0200 Subject: [Openmcl-devel] svn Message-ID: <841DADE9-1A5F-4490-9DD3-AEACF34D6D66@joakimsandgren.com> Hi, I'm sorry for this low level question: someone showed me the terminal line to download on svn the trunk... and I dont find it again... someone? Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Sun May 17 13:35:15 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sun, 17 May 2009 22:35:15 +0200 Subject: [Openmcl-devel] svn Message-ID: <85F61A83-3A16-4082-BEBA-7A30E733E047@joakimsandgren.com> Found it! sorry Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lisp at clairvaux.org Sun May 17 13:58:40 2009 From: lisp at clairvaux.org (Glen Foy) Date: Sun, 17 May 2009 16:58:40 -0400 Subject: [Openmcl-devel] scrolling-hemlock-view In-Reply-To: <65567907-5C0E-484C-B510-12E118F54E0E@clairvaux.org> References: <2583A6BF-549B-43A9-A26C-C7809CD96167@joakimsandgren.com> <65567907-5C0E-484C-B510-12E118F54E0E@clairvaux.org> Message-ID: <49F4D328-D60E-4F38-8062-4350DE84D391@clairvaux.org> Has anyone packaged Hemlock in manner similar to scrolling-fred-view? From joakim at joakimsandgren.com Sun May 17 14:19:48 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sun, 17 May 2009 23:19:48 +0200 Subject: [Openmcl-devel] inspector window Message-ID: Hi, Why are the inspector window not active when it shows up ? As it is now you always have to click in it once to start to use it. Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Sun May 17 14:42:12 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sun, 17 May 2009 23:42:12 +0200 Subject: [Openmcl-devel] list - vector Message-ID: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> Hi, It seems to me that the speed relations list/simple-vector has changed in ccl in comparison with mcl. in mcl, the list was always faster until you wanted a element quite deep into a long list. now, in ccl I did a dotimes test where I took the 100s element of a list using nth and the 100 element of a simple-vector using svref. The vector was much faster. This was the normal relation in mcl too. Then I took the 4th element in the same list (still with nth) and the 4th element of the same vector with svref and the vector is still clearly faster!! This is new to me. Should I abandon lists? And start to do everything in vectors? Sometime in my project code I have some "heavy" searching fetching elements with search criteria in many quite long lists. And this do take some time sometimes. Again, should I start to use vectors, in ccl?... Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Sun May 17 15:45:58 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Sun, 17 May 2009 16:45:58 -0600 Subject: [Openmcl-devel] IDE laundry list In-Reply-To: References: Message-ID: On May 17, 2009, at 12:40 PM, Ron Garret wrote: > 1. This one actually qualifies as a bug, and I believe there's a > long- > standing ticket open on it: When you double-click on a close-paren > that is at the end of a buffer, the corresponding S-expression does > not get selected. Instead, what happens depends on the character > immediately to the left of the close-paren. If that character is > itself a close-paren, then the S-expression corresponding to *that* > close-paren is selected, otherwise the final close-parent character > itself is selected. > that is annoying. Related to that: if you put cursor at end of sexpr Command-E, execute selection, is neither working nor enabled. Strictly speaking there is no selection but that did not bother MCL and quite frankly Command E is very handy. Notice, one could use the enter key instead but one the new, shabby, apple keyboards there is no direct enter key. You need to press the fn key. Not good. Please give me back the "if there is no selection do the same as enter" behavior of Command E. > 2. In my old MCL environment I had a function key bound to a function > that pretty-printed the macroexpansion of the current sexpr. I used > that almost as much as meta-point, maybe more, and I really miss it. > I get the feeling that if I dug deeply enough I could figure out how > to add this myself, but I would really like to see it be a standard > part of CCL. yup, used that a lot too.. > > > 5. The new way of balancing parens is not bad, a vast improvement > over the way it was before, but it would be nice to be able to > customize the highlighting. In particular, I'd like to be able to > change the color. That cyan doesn't resonate well with me for some > reason. Even better, I'd like to be able to change both the > background color *and* the color and style of the glyph (in which case > I'd probably choose for the background color to be white, and > highlight matching parens by making them bold, but that's just me). partial solution: (setq gui::*paren-highlight-background-color* (#/retain (#/colorWithCalibratedRed:green:blue:alpha: ns:ns- color 0.9 0.8 0.8 1.0))) I would add another one. I like to have a way to find the keyboard bindings a bit more efficiently. The page that Jeremy send a link out to looks good. How about just adding that as bookmark to the CCL Help menu? Alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From lisp at clairvaux.org Sun May 17 17:34:05 2009 From: lisp at clairvaux.org (Glen Foy) Date: Sun, 17 May 2009 20:34:05 -0400 Subject: [Openmcl-devel] IDE laundry list In-Reply-To: References: Message-ID: <47693F0D-951F-4055-BAC7-35E3FED9D940@clairvaux.org> On May 17, 2009, at 2:40 PM, Ron Garret wrote: > 2. In my old MCL environment I had a function key bound to a function > that pretty-printed the macroexpansion of the current sexpr. I used > that almost as much as meta-point, maybe more, and I really miss it. > I get the feeling that if I dug deeply enough I could figure out how > to add this myself, but I would really like to see it be a standard > part of CCL. Do you just need function key bindings for the existing Hemlock commands? (hi::bind-key "Editor Macroexpand-1 Expression" #k"F1") (hi::bind-key "Editor Macroexpand Expression" #k"F2") If you need to hack that code in some way, it's in listener.lisp. From ron at awun.net Sun May 17 18:12:11 2009 From: ron at awun.net (Ron Garret) Date: Sun, 17 May 2009 18:12:11 -0700 Subject: [Openmcl-devel] IDE laundry list In-Reply-To: <47693F0D-951F-4055-BAC7-35E3FED9D940@clairvaux.org> References: <47693F0D-951F-4055-BAC7-35E3FED9D940@clairvaux.org> Message-ID: On May 17, 2009, at 5:34 PM, Glen Foy wrote: > > On May 17, 2009, at 2:40 PM, Ron Garret wrote: > >> 2. In my old MCL environment I had a function key bound to a >> function >> that pretty-printed the macroexpansion of the current sexpr. I used >> that almost as much as meta-point, maybe more, and I really miss it. >> I get the feeling that if I dug deeply enough I could figure out how >> to add this myself, but I would really like to see it be a standard >> part of CCL. > > Do you just need function key bindings for the existing Hemlock > commands? > > (hi::bind-key "Editor Macroexpand-1 Expression" #k"F1") > (hi::bind-key "Editor Macroexpand Expression" #k"F2") That's a good start. It's not quite what I want: it seems to require an active selection -- just having the cursor on a close paren doesn't work. But I can't imagine that will be too hard to fix. > > If you need to hack that code in some way, it's in listener.lisp. Will try that. Thanks! rg From ralex at cs.colorado.edu Sun May 17 18:19:46 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Sun, 17 May 2009 19:19:46 -0600 Subject: [Openmcl-devel] inspector window In-Reply-To: References: Message-ID: <8D8AED8B-3805-4522-8E37-4CAD40275DB4@cs.colorado.edu> .... and while you're at it: please make the Backtrace window a regular application window (with drop shadow). I don't think I have ever seen this type of window in any OS X application. This looks simply broken. Alex On May 17, 2009, at 3:19 PM, Joakim Sandgren wrote: > Hi, > Why are the inspector window not active when it shows up ? As it is > now you always have to click in it once to start to use it. > > Sincerely > > Joakim > > > > Joakim Sandgren > joakim sandgren musik > 42, rue de Maubeuge > 75009 Paris > France > +33 (0)1 45 26 43 90 > info at joakimsandgren.com > http://www.joakimsandgren.com > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Sun May 17 19:15:39 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Sun, 17 May 2009 20:15:39 -0600 Subject: [Openmcl-devel] Lisp versus JavaScript (was: list - vector) In-Reply-To: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> References: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> Message-ID: Computational complexity. Random array access is done in constant time whereas random list access is done in linear time. If you need random access then lists are generally a bad idea. Of course, that constant time can vary a lot. svref can be pretty fast but aref is a notoriously slow access function for multidimensional arrays compared to, say, C. So far, that did not bug me too much, but recently, but thanks to some Apple involvement, even the "slow" scripting languages such as JavaScript are getting amazingly fast. For instance, I was really quite shocked to see the performance of JavaScript in game of life here: http://o3d-life.googlecode.com/svn/trunk/life.html You need to have the newest JavaScript engines, e.g. the one in Safari 4 to get the full speed. I wondered if Lisp (CCL) can still match this. I intentionally did not use any declarations and optimizations to roughly approximate the JavaScript. You can find the result as "game of life.lisp" XMLisp example here: http://code.google.com/p/xmlisp/ At any rate, Lisp had a very hard hard time to match the JavaScript performance. The COUNT-LIFE function including many Aref array accesses is the main bottleneck. If you replace the call to (count- life Self i j) with (random 9) the frame rate shoots up 4x. This is not surprising but the fact that JavaScript can about match the Lisp performance is. Alex On May 17, 2009, at 3:42 PM, Joakim Sandgren wrote: > Hi, > It seems to me that the speed relations list/simple-vector has > changed in ccl in comparison with mcl. > > in mcl, the list was always faster until you wanted a element quite > deep into a long list. > > now, in ccl I did a dotimes test where I took the 100s element of a > list using nth > and the 100 element of a simple-vector using svref. > The vector was much faster. > This was the normal relation in mcl too. > > Then I took the 4th element in the same list (still with nth) > and the 4th element of the same vector with svref > and the vector is still clearly faster!! > This is new to me. > > Should I abandon lists? And start to do everything in vectors? > Sometime in my project code I have some "heavy" searching fetching > elements with search criteria in many quite long lists. > And this do take some time sometimes. > Again, should I start to use vectors, in ccl?... > > Sincerely > Joakim > > > > > Joakim Sandgren > joakim sandgren musik > 42, rue de Maubeuge > 75009 Paris > France > +33 (0)1 45 26 43 90 > info at joakimsandgren.com > http://www.joakimsandgren.com > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf From lisp at clairvaux.org Mon May 18 07:13:52 2009 From: lisp at clairvaux.org (Glen Foy) Date: Mon, 18 May 2009 10:13:52 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors Message-ID: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> I was browsing comp.compilers today and came across this: " The thing that differentiates multiple cores within the same processor die with multiple processors is their use of a common cache and possibly pipelines and also the fact that communication from core to core within the same processor die is faster than across processor dies. Previously, communication overhead used to significantly hamper scheduling parts of a program across processors, and this is lower for cores within the same processor. ... Most of the activity has been on adapting sequential programs to take advantage of multi-core architectures because Moore's law is being hit i.e. processor speeds are not doubling and so manufacturers are forced to expand sideways and add more cores instead of increasing clock frequency. But the sequential programs once written will not show an improvement in speed unless the additional cores are utilized and that is where compiler writers are trying to find ways to show performance gain. " My ignorance of compiler design is breathtaking, but could multi-core compiler techniques be used to compensate for Intel's register-starved architecture? (Apologies if this makes it to the list twice.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at mastenbrook.net Mon May 18 07:45:40 2009 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Mon, 18 May 2009 09:45:40 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> Message-ID: <1242657940.3605.41.camel@hp64> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: > My ignorance of compiler design is breathtaking, but could multi-core > compiler techniques be used to compensate for Intel's register-starved > architecture? In a word, no. The problem with Intel's register-starved architecture is that as a compiler author it's difficult to work with a very small set of registers without overflowing to locations on the stack. Dealing with temporaries on the stack, while usually quite performant due to register renaming at the hardware level, gets quite difficult to juggle especially if your compiler was originally developed on an architecture where there are enough registers to always leave a few open for temporaries. Talking about "multi-core compiler techniques" is a bit like "alchemy" right now. Nobody's really quite sure what works, especially when it comes to languages that mere mortals can write. There's also quite a bit of tension between the desire for functional programming as a means to save ourselves from mutable shared state and the intrinsic dependency of garbage collection on same. The relationship between multi-core and the register-poor x86 architecture isn't great, except that it probably increases the number of things you've got to keep in a register and thus exacerbates the issue. For what it's worth, x86-64 isn't all that register-starved, which is why some programs show a great improvement when compiled for 64-bit even when you'd expect only a performance loss due to the increase in pointer width. It's not quite like working on PowerPC or SPARC, but it isn't half bad. As a practical matter, it's probably safe to assume that any system with more than two cores (real or virtual hyper-threaded) is 64-bit; all of Intel's existing CPUs certainly hold to this pattern. -- Brian Mastenbrook brian at mastenbrook.net http://brian.mastenbrook.net/ From lisp at clairvaux.org Mon May 18 08:50:02 2009 From: lisp at clairvaux.org (Glen Foy) Date: Mon, 18 May 2009 11:50:02 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <1242657940.3605.41.camel@hp64> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> Message-ID: <1D783A0A-0E6D-4936-932B-7CAEA5ACD7A5@clairvaux.org> On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: > On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: > >> My ignorance of compiler design is breathtaking, but could multi-core >> compiler techniques be used to compensate for Intel's register- >> starved >> architecture? > > In a word, no. > > The problem with Intel's register-starved architecture is that as a > compiler author it's difficult to work with a very small set of > registers without overflowing to locations on the stack. Dealing with > temporaries on the stack, while usually quite performant due to > register > renaming at the hardware level, gets quite difficult to juggle > especially if your compiler was originally developed on an > architecture > where there are enough registers to always leave a few open for > temporaries. > > Talking about "multi-core compiler techniques" is a bit like "alchemy" > right now. Nobody's really quite sure what works, especially when it > comes to languages that mere mortals can write. There's also quite a > bit > of tension between the desire for functional programming as a means to > save ourselves from mutable shared state and the intrinsic > dependency of > garbage collection on same. > > The relationship between multi-core and the register-poor x86 > architecture isn't great, except that it probably increases the number > of things you've got to keep in a register and thus exacerbates the > issue. > > For what it's worth, x86-64 isn't all that register-starved, which is > why some programs show a great improvement when compiled for 64-bit > even > when you'd expect only a performance loss due to the increase in > pointer > width. It's not quite like working on PowerPC or SPARC, but it isn't > half bad. As a practical matter, it's probably safe to assume that any > system with more than two cores (real or virtual hyper-threaded) is > 64-bit; all of Intel's existing CPUs certainly hold to this pattern. Thanks for the info. The quality of the responses on this list is really quite remarkable. From maciej at pasternacki.net Mon May 18 10:08:42 2009 From: maciej at pasternacki.net (Maciej Pasternacki) Date: Mon, 18 May 2009 19:08:42 +0200 Subject: [Openmcl-devel] patch: ability to create socket for given file descriptor number In-Reply-To: <5ACDF50B-3C80-4495-8296-ECD2864BAC4F@pasternacki.net> References: <5ACDF50B-3C80-4495-8296-ECD2864BAC4F@pasternacki.net> Message-ID: <9F1B8725-677C-46B3-A04C-9CA61800C346@pasternacki.net> On 2009-05-08, at 12:04, Maciej Pasternacki wrote: > Patch adds FD as an accepted keyword argument to CCL:MAKE-SOCKET, > and changes FD from auxilliary variable to a keyword argument in all > downstream functions. Downstream functions call c_socket only when > FD argument wasn't supplied, otherwise trusting caller that given > file descriptor is a descriptor for right kind of socket, and using > it to create socket structure. > > Patch is made against SVN trunk. Is there something wrong with my patch, or with the way I am sending it? Should I open a bug in Trac rather than directing my issues to the list? I supposed it is better to discuss the issue and proposed solution before opening the bug, to keep informations in the bugtracker as relevant as possible, but if that's not the proper order, please tell me. Proper way of sending patches was not described in current manual, and I could not find any directions at Wiki other than this list address. Anyway, due to mess in my SVN checkouts (for which I apologize) the patch in my original post was actually against 1.2 release. I attach correct version of patch, which applies cleanly to 1.3 release and to the trunk. Regards, Maciej. -------------- next part -------------- A non-text attachment was scrubbed... Name: ccl-fdsocket-13.diff Type: application/octet-stream Size: 2359 bytes Desc: not available URL: -------------- next part -------------- -- Maciej Pasternacki -><- http://www.pasternacki.net/ -><- http://www.3ofcoins.net/ From info at joakimsandgren.com Mon May 18 13:08:26 2009 From: info at joakimsandgren.com (Joakim Sandgren) Date: Mon, 18 May 2009 22:08:26 +0200 Subject: [Openmcl-devel] encodings Message-ID: <626E1D82-6D3F-4247-8671-E81B4A8A46DE@joakimsandgren.com> Hi, You showed me how to set the *default-file-character-encoding* and also the *default-external-format*... As Gary showed me the Macintosh encoding works well for my accents and it does. So I put Macintosh as my default encoding. If I want to open a file, the Macintosh is preselected. If I open a Macintosh encoded file and the take save as, the Macintosh encoding are pre-selected in that dialog. If I do a new file it has the encoding "automatic". When I save this new document for the first time it is "Automatic" encoding that is preselected. There I choose Macintosh, and I save this document as a Macintosh encoded file. When I open it, it is still Macintosh encoded. I can evaluate, selected parts of the file with enter. But not I cannot use the Execute all... command in the menu or load the file with Load File.. in the menu. If I load this file by using Load File... or Execute All I have : > Error: "MACINTOSH" is not the name of a known characer encoding. > While executing: MAKE-EXTERNAL-FORMAT, in process Listener(15). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > I tried to put the external format to MACOS but it didn't have any effect... Could someone enlighten me how to do? Very Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Mon May 18 13:20:24 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Mon, 18 May 2009 22:20:24 +0200 Subject: [Openmcl-devel] window positions Message-ID: <9222806E-0CA2-49E5-B374-0B4C3FC343A8@joakimsandgren.com> I just noticed that the remeber window positions works in the trunk!! Super! Super! Really Really Good! It is just possible to fix a position for the Listener also? Always new demands... sorry:-) Thank You a Lot Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at awun.net Mon May 18 13:42:23 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 13:42:23 -0700 Subject: [Openmcl-devel] Trouble in paradise Message-ID: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> Over the weekend I reported that my initial experience with 1.3 was favorable. Unfortunately, subsequent explorations have not been so good. In particular, I've now run up half a dozen SBOD hangs. And I wasn't actually doing anything except playing around with the editor. In one case, the system hung while I was editing in the listener with no other threads running. The reason I'm posting this here is to find out if other people are having the same experience. Is everyone seeing these hangs, or is it just me? What's the prognosis for getting this fixed? It's pretty much a show-stopper for me. BTW, I also identified two more items for my laundry list: 6. Sometimes (I have not yet identified the exact circumstances under which this happens -- it seems to be random) deleting characters causes those characters to replace the contents of the clipboard. 7. Because Hemlock makes such a strong operational distinction between input and non-input areas of the buffer, it would be nice to have the input areas colorized. For the record, I know it's not entirely appropriate for me to post this kind of thing to the NG. I'm only doing it to get feedback (maybe there's already a known fix?) before opening a ticket. rg From alms at clozure.com Mon May 18 13:47:22 2009 From: alms at clozure.com (Andrew Shalit) Date: Mon, 18 May 2009 16:47:22 -0400 Subject: [Openmcl-devel] Trouble in paradise In-Reply-To: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> Message-ID: On May 18, 2009, at 4:42 PM, Ron Garret wrote: > > For the record, I know it's not entirely appropriate for me to post > this kind of thing to the NG. I'm only doing it to get feedback > (maybe there's already a known fix?) before opening a ticket. Speaking only for myself and in no official capacity, I think it's fine to post stuff like this here. Getting the IDE to gel is a group endeavor. From ron at awun.net Mon May 18 14:30:45 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 14:30:45 -0700 Subject: [Openmcl-devel] Trouble in paradise In-Reply-To: References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> Message-ID: On May 18, 2009, at 1:47 PM, Andrew Shalit wrote: > > On May 18, 2009, at 4:42 PM, Ron Garret wrote: > >> >> For the record, I know it's not entirely appropriate for me to post >> this kind of thing to the NG. I'm only doing it to get feedback >> (maybe there's already a known fix?) before opening a ticket. > > Speaking only for myself and in no official capacity, I think it's > fine to post stuff like this here. Getting the IDE to gel is a > group endeavor. OK, good to know. Thanks. rg From rme at clozure.com Mon May 18 14:33:44 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 18 May 2009 17:33:44 -0400 Subject: [Openmcl-devel] backtrace window In-Reply-To: <8D8AED8B-3805-4522-8E37-4CAD40275DB4@cs.colorado.edu> References: <8D8AED8B-3805-4522-8E37-4CAD40275DB4@cs.colorado.edu> Message-ID: On May 17, 2009, at 9:19 PM, Alexander Repenning wrote: > .... and while you're at it: please make the Backtrace window a > regular application window (with drop shadow). I don't think I have > ever seen this type of window in any OS X application. This looks > simply broken. You're right; that looks quite odd. r12080 in the trunk corrects the window appearance. From ron at awun.net Mon May 18 14:38:19 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 14:38:19 -0700 Subject: [Openmcl-devel] Hemlock clipboard bug In-Reply-To: References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> Message-ID: <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> On May 18, 2009, at 1:47 PM, Andrew Shalit wrote: > > Speaking only for myself and in no official capacity, I think it's > fine to post stuff like this here. Getting the IDE to gel is a > group endeavor. Along those lines, I have found a reliable way to reproduce the clipboard corruption problem: 1. Open a listener. 2. Type "12345", select and copy it 3. Paste. This should work. 4. Hit delete three times. You should have deleted "345". Fewer deletes don't seem to produce the problem. 5. Paste. This should still work, i.e. you should have pasted "12345" again. Your command line should now read "123451212345" 6. Repeat steps 4 and 5. On my machine, the contents of the clipboard are now "5345" instead of "12345". I'd love to know if other people are able to reproduce this. rg From greg at clozure.com Mon May 18 15:11:46 2009 From: greg at clozure.com (Greg Pfeil) Date: Mon, 18 May 2009 18:11:46 -0400 Subject: [Openmcl-devel] Hemlock clipboard bug In-Reply-To: <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> Message-ID: <39CCD8EF-4165-4C93-B41D-23755EBE957A@clozure.com> On 18 May 2009, at 17:38, Ron Garret wrote: > Along those lines, I have found a reliable way to reproduce the > clipboard corruption problem: > > 1. Open a listener. ? > 6. Repeat steps 4 and 5. On my machine, the contents of the > clipboard are now "5345" instead of "12345". > > I'd love to know if other people are able to reproduce this. Yep, I see the same behavior (1.3-dev-r11987M-trunk DarwinX8664) From raffaelcavallaro at mac.com Mon May 18 15:06:19 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Mon, 18 May 2009 18:06:19 -0400 Subject: [Openmcl-devel] Hemlock clipboard bug In-Reply-To: <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> Message-ID: On May 18, 2009, at 5:38 PM, Ron Garret wrote: > I'd love to know if other people are able to reproduce this. yes regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From rme at clozure.com Mon May 18 15:21:09 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 18 May 2009 18:21:09 -0400 Subject: [Openmcl-devel] Hemlock clipboard bug In-Reply-To: <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> Message-ID: On May 18, 2009, at 5:38 PM, Ron Garret wrote: > Along those lines, I have found a reliable way to reproduce the > clipboard corruption problem: > > 1. Open a listener. > > 2. Type "12345", select and copy it > > 3. Paste. This should work. > > 4. Hit delete three times. You should have deleted "345". Fewer > deletes don't seem to produce the problem. > > 5. Paste. This should still work, i.e. you should have pasted > "12345" again. Your command line should now read "123451212345" > > 6. Repeat steps 4 and 5. On my machine, the contents of the > clipboard are now "5345" instead of "12345". > > I'd love to know if other people are able to reproduce this. I see the same thing; clearly a bug. I'm taking a look at it now. If Hemlock sees more than Character Deletion Threshold (default 5) characters get killed consecutively, it saves them on the kill ring. The act of pasting a string from the Mac OS clipboard doesn't appear to do anything about resetting this notion, so after you press delete 5 times, Hemlock saves the characters onto the kill ring, and hence, onto the clipboard. From ron at awun.net Mon May 18 16:20:56 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 16:20:56 -0700 Subject: [Openmcl-devel] Hemlock clipboard bug In-Reply-To: References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> Message-ID: On May 18, 2009, at 3:21 PM, R. Matthew Emerson wrote: > > On May 18, 2009, at 5:38 PM, Ron Garret wrote: > >> Along those lines, I have found a reliable way to reproduce the >> clipboard corruption problem: >> >> 1. Open a listener. >> >> 2. Type "12345", select and copy it >> >> 3. Paste. This should work. >> >> 4. Hit delete three times. You should have deleted "345". Fewer >> deletes don't seem to produce the problem. >> >> 5. Paste. This should still work, i.e. you should have pasted >> "12345" again. Your command line should now read "123451212345" >> >> 6. Repeat steps 4 and 5. On my machine, the contents of the >> clipboard are now "5345" instead of "12345". >> >> I'd love to know if other people are able to reproduce this. > > I see the same thing; clearly a bug. I'm taking a look at it now. > > If Hemlock sees more than Character Deletion Threshold (default 5) > characters get killed consecutively, it saves them on the kill ring. > > The act of pasting a string from the Mac OS clipboard doesn't appear > to do anything about resetting this notion, so after you press > delete 5 times, Hemlock saves the characters onto the kill ring, and > hence, onto the clipboard. I don't think this is the problem. If I set HEMLOCK::CHARACTER- DELETION-THRESHOLD to max-positive-fixnum (which is the only proper value for this parameter IMNSHO) the behavior persists. Moreover, it actually *doesn't* save all the deleted characters, only some of them. For example, if I type "123456789", then hit delete nine times, then cmd-V, I end up with "6789". rg From ron at awun.net Mon May 18 16:49:14 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 16:49:14 -0700 Subject: [Openmcl-devel] Hemlock clipboard bug In-Reply-To: References: <0ADF5424-2F64-43DC-B91D-889EC634FD62@awun.net> <3CD48D48-EEBA-4281-B9EC-6F727F21B3D1@awun.net> Message-ID: On May 18, 2009, at 4:20 PM, Ron Garret wrote: > > On May 18, 2009, at 3:21 PM, R. Matthew Emerson wrote: > >> >> On May 18, 2009, at 5:38 PM, Ron Garret wrote: >> >>> Along those lines, I have found a reliable way to reproduce the >>> clipboard corruption problem: >>> >>> 1. Open a listener. >>> >>> 2. Type "12345", select and copy it >>> >>> 3. Paste. This should work. >>> >>> 4. Hit delete three times. You should have deleted "345". Fewer >>> deletes don't seem to produce the problem. >>> >>> 5. Paste. This should still work, i.e. you should have pasted >>> "12345" again. Your command line should now read "123451212345" >>> >>> 6. Repeat steps 4 and 5. On my machine, the contents of the >>> clipboard are now "5345" instead of "12345". >>> >>> I'd love to know if other people are able to reproduce this. >> >> I see the same thing; clearly a bug. I'm taking a look at it now. >> >> If Hemlock sees more than Character Deletion Threshold (default 5) >> characters get killed consecutively, it saves them on the kill ring. >> >> The act of pasting a string from the Mac OS clipboard doesn't appear >> to do anything about resetting this notion, so after you press >> delete 5 times, Hemlock saves the characters onto the kill ring, and >> hence, onto the clipboard. > > I don't think this is the problem. If I set HEMLOCK::CHARACTER- > DELETION-THRESHOLD to max-positive-fixnum Doh, never mind. You have to do (setf (hemlock::value hemlock::character-deletion-threshold) ...) Are there any Hemlock authors on this list? The urge to write something sarcastic here is getting difficult to contain. rg From ron at awun.net Mon May 18 17:13:27 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 17:13:27 -0700 Subject: [Openmcl-devel] What is the right way to tell if you're running the IDE? Message-ID: <0B84E8D1-BCB4-448D-A313-62E94EB0F0BE@awun.net> Versions <1.3 had two different init files, ccl-init.lisp and ccl- cocoa-init.lisp. It appears empirically that ccl-cocoa-init.lisp has been deprecated. Is there now a recommended way to tell if you're running under the IDE or not? It's easy to find a hack (e.g. (find- package :gui)) but it would be nice if there were a published test that we could rely on remaining stable. rg From ron at awun.net Mon May 18 18:07:27 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 18:07:27 -0700 Subject: [Openmcl-devel] RFC (request for clue): where is the mouse click event handling code? Message-ID: Subject line pretty much says it all. I want to try to fix the Hemlock double-click-doesn't-work-at-end-of-buffer bug, which is driving me absolutely bananas, but I can't find the code that handles click events. The obvious things like grepping for "click" and "mouse" in hemlock/src didn't lead to anything recognizable (at least to me) as event handling code. Thanks, rg From gb at clozure.com Mon May 18 19:08:46 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 18 May 2009 20:08:46 -0600 (MDT) Subject: [Openmcl-devel] Lisp versus JavaScript (was: list - vector) In-Reply-To: References: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> Message-ID: <20090518013157.C72709@abq.clozure.com> On Sun, 17 May 2009, Alexander Repenning wrote: > Computational complexity. Random array access is done in constant time > whereas random list access is done in linear time. If you need random > access then lists are generally a bad idea. Of course, that constant > time can vary a lot. svref can be pretty fast but aref is a > notoriously slow access function for multidimensional arrays compared > to, say, C. Among the reasons that SVREF tends to be faster than AREF are: - it asserts that the array in question is SIMPLE (not displaced, not adjustable, etc.) - it asserts that the array in question has an element type of T (not BIT, not CHARACTER, not some subtype of FLOAT or INTEGER ...) A fully safe SVREF can basically validate these assertions (which in this case amount to checking that its first argument is a SIMPLE-VECTOR) and validate the implicit assertion that its second argument is a valid vector index for the first arg, then execute a simple LOAD instruction. In most CL implementations, (defun foo (a i) (svref a i)) (defun bar (a i) (declare (type simple-vector a)) (aref a i)) will compile to exactly the same code (and that code will test the implicit and explict assertions about A and I and then do a simple LOAD instruction.) A third case: (defun baz (a i) (aref a i)) will have to discover (at runtime) whether or not A is some sort of vector or not (since that's all that's being asserted), whether or not it's "simple" or not (and what this means is somewhat implementation dependent), what it's element-type is, and what sort of LOAD instruction ("load word", "load byte", "load bit", "load signed byte", "load single-float", ...) needs to be executed. If BAZ's A argument is in fact a SIMPLE-VECTOR, we'll wind up executing the same simple LOAD instruction as in the other cases (where that's asserted), but it'll take us a while to realize that. ("a while" is probably "a few times the cost of the LOAD" in this case.) If CL had only a single array type (say, something like a SIMPLE-VECTOR, but possibly with a single level of displacement to support "growing", and with vectors of vectors used to simulate multidimensional arrays), then AREF would always be a simple, easily-inlined operation whose naive use would offer C-like performance. (Unfortunately, we'd all be stuck with nothing but Javascript-like arrays in that case.) The traditional way of trying to optimize things like AREF (when nothing much is known about the array) is to cache information about the array (outside of a loop, for instance) and transform the AREF into someting simpler that uses that cached information. (I believe that the Lisp Machines did this and called the cache an "array register"; Fortran implementations (Fortran arrays tend to be much higher-level things than C arrays) often call the cache a "dope vector." Hiding some of the details, the idea would be to transform something like: (let* ((sum 0)) (dotimes (i (length a)) (incf sum (aref a i)))) into something like (let* ((sum 0) (f (%get-1d-aref-function-for a))) (dotimes (i (length a)) (incf sum (funcall f a i)))) If A turns out at runtime to be a SIMPLE-VECTOR, then %GET-1D-AREF-FUNCTION-FOR might return something like SVREF; if it's a SIMPLE-STRING, then a simple version of SCHAR may be returned (and the "function" might be something that's not quite a full-blown lisp function, called by something not quite as general as FUNCALL.) Whether and how much this wins depends (on things like what type of array A actually turns out to be, on how many times the loop actually executes, and other things.) If it does win (compared to just a naive AREF), it's still not likely to produce code that's nearly as good as that in which the compiler's involved a bit more (e.g., where there are declarations about the array's simplicity and element-type.) This (the cache/dope-vector/array-register idea) is certainly worth exploring (as are similar things which remove redundant operations from loops.) There are probably limits to how much better you can make things when the compiler's not aware of the array's element-type (at least.) The general way in which one makes calls to AREF faster in CL is to let the compiler transform those calls into something simpler (SVREF or SCHAR or SBIT or %SIMPLE-UNSIGNED-BYTE-16-REF or %SIMPLE-DOUBLE-FLOAT-REF or ...), and doing that transformation at compile-time (on the basis of declarations and/or inferred type information) is preferable to doing it at runtime (and obviously better than doing it repeatedly at runtime, in the middle of a loop.) CCL does a fairly good job of getting to and sometimes beyond that starting point if AREF's first argument is declared to be a SIMPLE-ARRAY of specified element-type (and I'd like to be able to do some things involving arrays not explicitly declared to be SIMPLE arrays in the next version.) If you're starting from the assumption that #'CL:AREF (without any compile-time assertions) is somehow analogous (performance-wise or otherwise) to an array-reference operator in a language with one array type, you probably won't get very far very fast; that's simply not a reasonable assumption. In my mind, this is the sort of thing that every serious CL programmer should know (though I admit to not being entirely clear on how this knowledge is to be acquired; I imagine that most of what's written about it tends to be excruciatingly implementation- dependent.) I don't think that anyone who's programmed in CL thinks that #'CL:+ is directly analogous to C's addition operator (on explicitly typed operands), and CL programmers somehow learn that declaring the types of CL:+'s operands (and in some cases the type of the result) can greatly improve performance (especially when the type in question is FIXNUM.) If people honestly don't realize that there are similar issues with AREF, that's certainly surprising. > > So far, that did not bug me too much, but recently, but thanks to some > Apple involvement, even the "slow" scripting languages such as > JavaScript are getting amazingly fast. For instance, I was really > quite shocked to see the performance of JavaScript in game of life here: > > http://o3d-life.googlecode.com/svn/trunk/life.html > > You need to have the newest JavaScript engines, e.g. the one in Safari > 4 to get the full speed. > > I wondered if Lisp (CCL) can still match this. I intentionally did not > use any declarations and optimizations to roughly approximate the > JavaScript. You can find the result as "game of life.lisp" XMLisp > example here: http://code.google.com/p/xmlisp/ > > At any rate, Lisp had a very hard hard time to match the JavaScript > performance. The COUNT-LIFE function including many Aref array > accesses is the main bottleneck. If you replace the call to (count- > life Self i j) with (random 9) the frame rate shoots up 4x. This is > not surprising but the fact that JavaScript can about match the Lisp > performance is. > > Alex > > > > On May 17, 2009, at 3:42 PM, Joakim Sandgren wrote: > >> Hi, >> It seems to me that the speed relations list/simple-vector has >> changed in ccl in comparison with mcl. >> >> in mcl, the list was always faster until you wanted a element quite >> deep into a long list. >> >> now, in ccl I did a dotimes test where I took the 100s element of a >> list using nth >> and the 100 element of a simple-vector using svref. >> The vector was much faster. >> This was the normal relation in mcl too. >> >> Then I took the 4th element in the same list (still with nth) >> and the 4th element of the same vector with svref >> and the vector is still clearly faster!! >> This is new to me. >> >> Should I abandon lists? And start to do everything in vectors? >> Sometime in my project code I have some "heavy" searching fetching >> elements with search criteria in many quite long lists. >> And this do take some time sometimes. >> Again, should I start to use vectors, in ccl?... >> >> Sincerely >> Joakim >> >> >> >> >> Joakim Sandgren >> joakim sandgren musik >> 42, rue de Maubeuge >> 75009 Paris >> France >> +33 (0)1 45 26 43 90 >> info at joakimsandgren.com >> http://www.joakimsandgren.com >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From gb at clozure.com Mon May 18 19:19:47 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 18 May 2009 20:19:47 -0600 (MDT) Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <1D783A0A-0E6D-4936-932B-7CAEA5ACD7A5@clairvaux.org> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <1D783A0A-0E6D-4936-932B-7CAEA5ACD7A5@clairvaux.org> Message-ID: <20090518201116.F72709@abq.clozure.com> Matt gave a short talk at this year's ILC, describing how the lack of general-purpose registers on x8632 affected the implementation of CCL on that platform (over and above the usual problems.) An abstract of that talk and the slides that he used are in: On Mon, 18 May 2009, Glen Foy wrote: > > On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: > >> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >> >>> My ignorance of compiler design is breathtaking, but could multi-core >>> compiler techniques be used to compensate for Intel's register- >>> starved >>> architecture? >> >> In a word, no. >> >> The problem with Intel's register-starved architecture is that as a >> compiler author it's difficult to work with a very small set of >> registers without overflowing to locations on the stack. Dealing with >> temporaries on the stack, while usually quite performant due to >> register >> renaming at the hardware level, gets quite difficult to juggle >> especially if your compiler was originally developed on an >> architecture >> where there are enough registers to always leave a few open for >> temporaries. >> >> Talking about "multi-core compiler techniques" is a bit like "alchemy" >> right now. Nobody's really quite sure what works, especially when it >> comes to languages that mere mortals can write. There's also quite a >> bit >> of tension between the desire for functional programming as a means to >> save ourselves from mutable shared state and the intrinsic >> dependency of >> garbage collection on same. >> >> The relationship between multi-core and the register-poor x86 >> architecture isn't great, except that it probably increases the number >> of things you've got to keep in a register and thus exacerbates the >> issue. >> >> For what it's worth, x86-64 isn't all that register-starved, which is >> why some programs show a great improvement when compiled for 64-bit >> even >> when you'd expect only a performance loss due to the increase in >> pointer >> width. It's not quite like working on PowerPC or SPARC, but it isn't >> half bad. As a practical matter, it's probably safe to assume that any >> system with more than two cores (real or virtual hyper-threaded) is >> 64-bit; all of Intel's existing CPUs certainly hold to this pattern. > > Thanks for the info. > > The quality of the responses on this list is really quite remarkable. > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From rme at clozure.com Mon May 18 19:22:12 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 18 May 2009 22:22:12 -0400 Subject: [Openmcl-devel] RFC (request for clue): where is the mouse click event handling code? In-Reply-To: References: Message-ID: <4FDED1DC-C5DF-4169-B316-BCB8AE9080DA@clozure.com> On May 18, 2009, at 9:07 PM, Ron Garret wrote: > Subject line pretty much says it all. I want to try to fix the > Hemlock double-click-doesn't-work-at-end-of-buffer bug, which is > driving me absolutely bananas, but I can't find the code that handles > click events. The obvious things like grepping for "click" and > "mouse" in hemlock/src didn't lead to anything recognizable (at least > to me) as event handling code. There's a fix for this in the trunk, which I just merged to the 1.3 branch. http://trac.clozure.com/ccl/changeset/11967 The IDE is currently using the Cocoa text system for handing text display and input. On the one hand, we get an amazing amount of stuff "for free" by doing this. On the other hand, it can be a real pain trying to keep Hemlock's and Cocoa's view of things in sync... From gb at clozure.com Mon May 18 19:37:35 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 18 May 2009 20:37:35 -0600 (MDT) Subject: [Openmcl-devel] What is the right way to tell if you're running the IDE? In-Reply-To: <0B84E8D1-BCB4-448D-A313-62E94EB0F0BE@awun.net> References: <0B84E8D1-BCB4-448D-A313-62E94EB0F0BE@awun.net> Message-ID: <20090518202513.X72709@abq.clozure.com> I don't believe that anything called "ccl-cocoa-init.lisp" has ever been loaded by any version of the IDE; we've had a longstanding ticket to the effect that an IDE-specific init file should be loaded, but I just started to address that in the trunk a week or so ago and haven't closed the ticket. There are several ad hoc ways to tell (somewhat reliably) if you're running in the IDE or not, but you're right that there should be a single, reliable, advertised way. Note that it'd still be awkward to say (in your ~/ccl-init.lisp file) (if (reliable-way-of-determining-if-running-under-IDE) (progn (hi:: ...) (gui:...))) and you'd have to do something like (EVAL (READ-FROM-STRING "(HI::...")). On Mon, 18 May 2009, Ron Garret wrote: > Versions <1.3 had two different init files, ccl-init.lisp and ccl- > cocoa-init.lisp. It appears empirically that ccl-cocoa-init.lisp has > been deprecated. Is there now a recommended way to tell if you're > running under the IDE or not? It's easy to find a hack (e.g. (find- > package :gui)) but it would be nice if there were a published test > that we could rely on remaining stable. > > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From greg at clozure.com Mon May 18 20:36:50 2009 From: greg at clozure.com (Greg Pfeil) Date: Mon, 18 May 2009 23:36:50 -0400 Subject: [Openmcl-devel] What is the right way to tell if you're running the IDE? In-Reply-To: <20090518202513.X72709@abq.clozure.com> References: <0B84E8D1-BCB4-448D-A313-62E94EB0F0BE@awun.net> <20090518202513.X72709@abq.clozure.com> Message-ID: <42564028-4502-4221-98CD-443B4AA41013@clozure.com> On 18 May 2009, at 22:37, Gary Byers wrote: > There are several ad hoc ways to tell (somewhat reliably) if you're > running in the IDE or not, but you're right that there should be a > single, reliable, advertised way. Note that it'd still be awkward > to say (in your ~/ccl-init.lisp file) > > (if (reliable-way-of-determining-if-running-under-IDE) > (progn > (hi:: ...) > (gui:...))) > > and you'd have to do something like (EVAL (READ-FROM-STRING > "(HI::...")). Seems to call for :CCL-IDE in *FEATURES*. From alms at clozure.com Mon May 18 20:51:23 2009 From: alms at clozure.com (Andrew Shalit) Date: Mon, 18 May 2009 23:51:23 -0400 Subject: [Openmcl-devel] Lisp versus JavaScript (was: list - vector) In-Reply-To: <20090518013157.C72709@abq.clozure.com> References: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> <20090518013157.C72709@abq.clozure.com> Message-ID: On May 18, 2009, at 10:08 PM, Gary Byers wrote: > If you're starting from the assumption that #'CL:AREF (without any > compile-time assertions) is somehow analogous (performance-wise or > otherwise) to an array-reference operator in a language with one array > type, you probably won't get very far very fast; that's simply not > a reasonable assumption. In my mind, this is the sort of thing that > every serious CL programmer should know (though I admit to not being > entirely clear on how this knowledge is to be acquired; I imagine that > most of what's written about it tends to be excruciatingly > implementation- > dependent.) I don't think that anyone who's programmed in CL thinks > that #'CL:+ is directly analogous to C's addition operator (on > explicitly > typed operands), and CL programmers somehow learn that declaring the > types of CL:+'s operands (and in some cases the type of the result) > can > greatly improve performance (especially when the type in question is > FIXNUM.) > > If people honestly don't realize that there are similar issues with > AREF, > that's certainly surprising. That brings us to the class line: "Lisp programmers know the value of everything and the cost of nothing." Perhaps we could add, Lisp implementors know the cost of everything, but Lisp documenters haven't been able to make that sufficiently obvious to other Lisp programmers. But every little bit helps. From rme at clozure.com Mon May 18 21:46:07 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 19 May 2009 00:46:07 -0400 Subject: [Openmcl-devel] Lisp versus JavaScript (was: list - vector) In-Reply-To: References: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> <20090518013157.C72709@abq.clozure.com> Message-ID: On May 18, 2009, at 11:51 PM, Andrew Shalit wrote: > > On May 18, 2009, at 10:08 PM, Gary Byers wrote: > >> If you're starting from the assumption that #'CL:AREF (without any >> compile-time assertions) is somehow analogous (performance-wise or >> otherwise) to an array-reference operator in a language with one >> array >> type, you probably won't get very far very fast; that's simply not >> a reasonable assumption. In my mind, this is the sort of thing that >> every serious CL programmer should know (though I admit to not being >> entirely clear on how this knowledge is to be acquired; I imagine >> that >> most of what's written about it tends to be excruciatingly >> implementation- >> dependent.) > That brings us to the class line: "Lisp programmers know the value of > everything and the cost of nothing." > > Perhaps we could add, Lisp implementors know the cost of everything, > but Lisp documenters haven't been able to make that sufficiently > obvious to other Lisp programmers. But every little bit helps. Norvig has a couple of chapters about efficiency in PAIP: http://norvig.com/paip.html http://www.amazon.com/dp/1558601910 Chapter 10, "Low-level efficiency issues," is an interesting and informative read. The whole book is good, for that matter. The AI problems are primarily a vehicle for demonstrating advanced Common Lisp programming techniques, so don't be turned off by the "artificial intelligence" in the title if AI is not your thing. From ron at awun.net Mon May 18 23:32:04 2009 From: ron at awun.net (Ron Garret) Date: Mon, 18 May 2009 23:32:04 -0700 Subject: [Openmcl-devel] RFC (request for clue): where is the mouse click event handling code? In-Reply-To: <4FDED1DC-C5DF-4169-B316-BCB8AE9080DA@clozure.com> References: <4FDED1DC-C5DF-4169-B316-BCB8AE9080DA@clozure.com> Message-ID: On May 18, 2009, at 7:22 PM, R. Matthew Emerson wrote: > > On May 18, 2009, at 9:07 PM, Ron Garret wrote: > >> Subject line pretty much says it all. I want to try to fix the >> Hemlock double-click-doesn't-work-at-end-of-buffer bug, which is >> driving me absolutely bananas, but I can't find the code that handles >> click events. The obvious things like grepping for "click" and >> "mouse" in hemlock/src didn't lead to anything recognizable (at least >> to me) as event handling code. > > There's a fix for this in the trunk, which I just merged to the 1.3 > branch. > > http://trac.clozure.com/ccl/changeset/11967 > > The IDE is currently using the Cocoa text system for handing text > display and input. On the one hand, we get an amazing amount of > stuff "for free" by doing this. On the other hand, it can be a real > pain trying to keep Hemlock's and Cocoa's view of things in sync... Woohoo! Thanks! rg From mevins at mac.com Mon May 18 23:33:54 2009 From: mevins at mac.com (mikel evins) Date: Tue, 19 May 2009 01:33:54 -0500 Subject: [Openmcl-devel] Lisp versus JavaScript (was: list - vector) In-Reply-To: References: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> <20090518013157.C72709@abq.clozure.com> Message-ID: <2EF9F3CD-9BA3-4D1E-BC1D-63EA124E27A0@mac.com> On May 18, 2009, at 11:46 PM, R. Matthew Emerson wrote: > > On May 18, 2009, at 11:51 PM, Andrew Shalit wrote: > >> >> On May 18, 2009, at 10:08 PM, Gary Byers wrote: >> >>> If you're starting from the assumption that #'CL:AREF (without any >>> compile-time assertions) is somehow analogous (performance-wise or >>> otherwise) to an array-reference operator in a language with one >>> array >>> type, you probably won't get very far very fast; that's simply not >>> a reasonable assumption. In my mind, this is the sort of thing that >>> every serious CL programmer should know (though I admit to not being >>> entirely clear on how this knowledge is to be acquired; I imagine >>> that >>> most of what's written about it tends to be excruciatingly >>> implementation- >>> dependent.) >> That brings us to the class line: "Lisp programmers know the value of >> everything and the cost of nothing." >> >> Perhaps we could add, Lisp implementors know the cost of everything, >> but Lisp documenters haven't been able to make that sufficiently >> obvious to other Lisp programmers. But every little bit helps. > > Norvig has a couple of chapters about efficiency in PAIP: > > http://norvig.com/paip.html > http://www.amazon.com/dp/1558601910 > > Chapter 10, "Low-level efficiency issues," is an interesting and > informative read. > > The whole book is good, for that matter. The AI problems are > primarily a vehicle for demonstrating advanced Common Lisp programming > techniques, so don't be turned off by the "artificial intelligence" in > the title if AI is not your thing. I agree. I learned what I know about compilers and interpreters (which is not so very much) mainly from transcribing and modifying the compilers and interpreters in SICP and PAIP. --me From gb at clozure.com Tue May 19 01:06:08 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 19 May 2009 02:06:08 -0600 (MDT) Subject: [Openmcl-devel] patch: ability to create socket for given file descriptor number In-Reply-To: <9F1B8725-677C-46B3-A04C-9CA61800C346@pasternacki.net> References: <5ACDF50B-3C80-4495-8296-ECD2864BAC4F@pasternacki.net> <9F1B8725-677C-46B3-A04C-9CA61800C346@pasternacki.net> Message-ID: <20090519011652.Y72709@abq.clozure.com> Sorry; stuff tends to slip through the cracks and scroll off the top of mail readers. Sometimes, it's better to open a ticket in Trac instead of or as well as sending email to this list (since that helps to avoid the "scrolling off into yesterday's mail" problem.) I looked at your first patch and aside from being mildly appalled at the situation you're trying to address (where a process is created with fd 0 set to something that can't be read from) didn't see an obvious problem. We probably need to be careful to document the new :FD argument as being something that should be used with some caution. As far as patches go: I don't think that we've ever rejected a patch because of formatting or style issues, but formatting issues (especially) can make patches harder to apply than they need to be. I'd say that "svn diff" output (against the trunk or release and identified as such) is ideal (since that output mentions the revisions involved), and when sending patches via email, it's much, much better to send them as enclosures (as you have) than in the body of the message. Among other things, mail programs tend to wrap long lines and otherwise modify the message body, and it can be hard to undo those modifications before applying the patch. I'll try to check this patch into the trunk in a minute and, assuming that no one using the trunk experiences any problems (I wouldn't think that they would, your changes looked pretty straightforward) propagate it into 1.3 after a few days. Thanks and sorry for not responding to the earlier message. On Mon, 18 May 2009, Maciej Pasternacki wrote: > On 2009-05-08, at 12:04, Maciej Pasternacki wrote: > >> Patch adds FD as an accepted keyword argument to CCL:MAKE-SOCKET, and >> changes FD from auxilliary variable to a keyword argument in all downstream >> functions. Downstream functions call c_socket only when FD argument wasn't >> supplied, otherwise trusting caller that given file descriptor is a >> descriptor for right kind of socket, and using it to create socket >> structure. >> >> Patch is made against SVN trunk. > > > Is there something wrong with my patch, or with the way I am sending it? > Should I open a bug in Trac rather than directing my issues to the list? I > supposed it is better to discuss the issue and proposed solution before > opening the bug, to keep informations in the bugtracker as relevant as > possible, but if that's not the proper order, please tell me. Proper way of > sending patches was not described in current manual, and I could not find any > directions at Wiki other than this list address. > > Anyway, due to mess in my SVN checkouts (for which I apologize) the patch in > my original post was actually against 1.2 release. I attach correct version > of patch, which applies cleanly to 1.3 release and to the trunk. > > Regards, > Maciej. From joakim at joakimsandgren.com Tue May 19 01:25:03 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Tue, 19 May 2009 10:25:03 +0200 Subject: [Openmcl-devel] Lisp versus JavaScript (was: list - vector) In-Reply-To: <20090518013157.C72709@abq.clozure.com> References: <6B386F03-3C77-4A1E-B7BC-711AE804A67E@joakimsandgren.com> <20090518013157.C72709@abq.clozure.com> Message-ID: <021EEF29-CC7C-47BE-8AD1-58C799CF741A@joakimsandgren.com> I just wanted to say that I just made a new mailbox in mail to keep these kind of answers from Gary. That is like having a master jedi answering with a lecture to your own little stupid question empiriquement found in the try and error world... I will do some other "try's" and will come back on this to know more... Very Sincerely Joakim Le 19 mai 09 ? 04:08, Gary Byers a ?crit : > > > On Sun, 17 May 2009, Alexander Repenning wrote: > >> Computational complexity. Random array access is done in constant >> time >> whereas random list access is done in linear time. If you need random >> access then lists are generally a bad idea. Of course, that constant >> time can vary a lot. svref can be pretty fast but aref is a >> notoriously slow access function for multidimensional arrays compared >> to, say, C. > > Among the reasons that SVREF tends to be faster than AREF are: > > - it asserts that the array in question is SIMPLE (not displaced, > not > adjustable, etc.) > > - it asserts that the array in question has an element type of T > (not > BIT, not CHARACTER, not some subtype of FLOAT or INTEGER ...) > > A fully safe SVREF can basically validate these assertions (which > in this > case amount to checking that its first argument is a SIMPLE-VECTOR) > and > validate the implicit assertion that its second argument is a valid > vector > index for the first arg, then execute a simple LOAD instruction. > In most > CL implementations, > > (defun foo (a i) > (svref a i)) > > (defun bar (a i) > (declare (type simple-vector a)) > (aref a i)) > > will compile to exactly the same code (and that code will test the > implicit and explict assertions about A and I and then do a simple > LOAD instruction.) > > A third case: > > (defun baz (a i) > (aref a i)) > > will have to discover (at runtime) whether or not A is some sort of > vector or not (since that's all that's being asserted), whether or not > it's "simple" or not (and what this means is somewhat implementation > dependent), what it's element-type is, and what sort of LOAD > instruction ("load word", "load byte", "load bit", "load signed byte", > "load single-float", ...) needs to be executed. If BAZ's A argument > is in fact a SIMPLE-VECTOR, we'll wind up executing the same simple > LOAD instruction as in the other cases (where that's asserted), but > it'll take us a while to realize that. ("a while" is probably "a few > times the cost of the LOAD" in this case.) > > If CL had only a single array type (say, something like a > SIMPLE-VECTOR, but possibly with a single level of displacement to > support "growing", and with vectors of vectors used to simulate > multidimensional arrays), then AREF would always be a simple, > easily-inlined operation whose naive use would offer C-like > performance. (Unfortunately, we'd all be stuck with nothing > but Javascript-like arrays in that case.) > > The traditional way of trying to optimize things like AREF (when > nothing much is known about the array) is to cache information > about the array (outside of a loop, for instance) and transform > the AREF into someting simpler that uses that cached information. > (I believe that the Lisp Machines did this and called the cache > an "array register"; Fortran implementations (Fortran arrays tend > to be much higher-level things than C arrays) often call the cache > a "dope vector." Hiding some of the details, the idea would be to > transform something like: > > (let* ((sum 0)) > (dotimes (i (length a)) (incf sum (aref a i)))) > > into something like > > (let* ((sum 0) > (f (%get-1d-aref-function-for a))) > (dotimes (i (length a)) (incf sum (funcall f a i)))) > > If A turns out at runtime to be a SIMPLE-VECTOR, then > %GET-1D-AREF-FUNCTION-FOR might return something like SVREF; if it's a > SIMPLE-STRING, then a simple version of SCHAR may be returned (and the > "function" might be something that's not quite a full-blown lisp > function, called by something not quite as general as FUNCALL.) > > Whether and how much this wins depends (on things like what type of > array A actually turns out to be, on how many times the loop actually > executes, and other things.) If it does win (compared to just a naive > AREF), it's still not likely to produce code that's nearly as good as > that in which the compiler's involved a bit more (e.g., where there > are declarations about the array's simplicity and element-type.) > > This (the cache/dope-vector/array-register idea) is certainly worth > exploring (as are similar things which remove redundant operations > from > loops.) There are probably limits to how much better you can make > things > when the compiler's not aware of the array's element-type (at least.) > > The general way in which one makes calls to AREF faster in CL is to > let the compiler transform those calls into something simpler (SVREF > or SCHAR or SBIT or %SIMPLE-UNSIGNED-BYTE-16-REF or > %SIMPLE-DOUBLE-FLOAT-REF or ...), and doing that transformation at > compile-time (on the basis of declarations and/or inferred type > information) is preferable to doing it at runtime (and obviously > better than doing it repeatedly at runtime, in the middle of a loop.) > CCL does a fairly good job of getting to and sometimes beyond that > starting point if AREF's first argument is declared to be a > SIMPLE-ARRAY of specified element-type (and I'd like to be able to do > some things involving arrays not explicitly declared to be SIMPLE > arrays in the next version.) > > If you're starting from the assumption that #'CL:AREF (without any > compile-time assertions) is somehow analogous (performance-wise or > otherwise) to an array-reference operator in a language with one array > type, you probably won't get very far very fast; that's simply not > a reasonable assumption. In my mind, this is the sort of thing that > every serious CL programmer should know (though I admit to not being > entirely clear on how this knowledge is to be acquired; I imagine that > most of what's written about it tends to be excruciatingly > implementation- > dependent.) I don't think that anyone who's programmed in CL thinks > that #'CL:+ is directly analogous to C's addition operator (on > explicitly > typed operands), and CL programmers somehow learn that declaring the > types of CL:+'s operands (and in some cases the type of the result) > can > greatly improve performance (especially when the type in question is > FIXNUM.) > > If people honestly don't realize that there are similar issues with > AREF, > that's certainly surprising. > > >> >> So far, that did not bug me too much, but recently, but thanks to >> some >> Apple involvement, even the "slow" scripting languages such as >> JavaScript are getting amazingly fast. For instance, I was really >> quite shocked to see the performance of JavaScript in game of life >> here: >> >> http://o3d-life.googlecode.com/svn/trunk/life.html >> >> You need to have the newest JavaScript engines, e.g. the one in >> Safari >> 4 to get the full speed. >> >> I wondered if Lisp (CCL) can still match this. I intentionally did >> not >> use any declarations and optimizations to roughly approximate the >> JavaScript. You can find the result as "game of life.lisp" XMLisp >> example here: http://code.google.com/p/xmlisp/ >> >> At any rate, Lisp had a very hard hard time to match the JavaScript >> performance. The COUNT-LIFE function including many Aref array >> accesses is the main bottleneck. If you replace the call to (count- >> life Self i j) with (random 9) the frame rate shoots up 4x. This is >> not surprising but the fact that JavaScript can about match the Lisp >> performance is. >> >> Alex >> >> >> >> On May 17, 2009, at 3:42 PM, Joakim Sandgren wrote: >> >>> Hi, >>> It seems to me that the speed relations list/simple-vector has >>> changed in ccl in comparison with mcl. >>> >>> in mcl, the list was always faster until you wanted a element quite >>> deep into a long list. >>> >>> now, in ccl I did a dotimes test where I took the 100s element of a >>> list using nth >>> and the 100 element of a simple-vector using svref. >>> The vector was much faster. >>> This was the normal relation in mcl too. >>> >>> Then I took the 4th element in the same list (still with nth) >>> and the 4th element of the same vector with svref >>> and the vector is still clearly faster!! >>> This is new to me. >>> >>> Should I abandon lists? And start to do everything in vectors? >>> Sometime in my project code I have some "heavy" searching fetching >>> elements with search criteria in many quite long lists. >>> And this do take some time sometimes. >>> Again, should I start to use vectors, in ccl?... >>> >>> Sincerely >>> Joakim >>> >>> >>> >>> >>> Joakim Sandgren >>> joakim sandgren musik >>> 42, rue de Maubeuge >>> 75009 Paris >>> France >>> +33 (0)1 45 26 43 90 >>> info at joakimsandgren.com >>> http://www.joakimsandgren.com >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> >> Prof. Alexander Repenning >> >> University of Colorado >> Computer Science Department >> Boulder, CO 80309-430 >> >> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hebisch at math.uni.wroc.pl Tue May 19 02:24:05 2009 From: hebisch at math.uni.wroc.pl (Waldek Hebisch) Date: Tue, 19 May 2009 11:24:05 +0200 (CEST) Subject: [Openmcl-devel] What is the right way to tell if you're running the IDE? In-Reply-To: <42564028-4502-4221-98CD-443B4AA41013@clozure.com> Message-ID: Greg Pfeil wrote: > On 18 May 2009, at 22:37, Gary Byers wrote: > > > There are several ad hoc ways to tell (somewhat reliably) if you're > > running in the IDE or not, but you're right that there should be a > > single, reliable, advertised way. Note that it'd still be awkward > > to say (in your ~/ccl-init.lisp file) > > > > (if (reliable-way-of-determining-if-running-under-IDE) > > (progn > > (hi:: ...) > > (gui:...))) > > > > and you'd have to do something like (EVAL (READ-FROM-STRING > > "(HI::...")). > > Seems to call for :CCL-IDE in *FEATURES*. Once you are at this please remember that beeing able to run GUI and running GUI are different thing. I certainly expect that I can build GUI capable program in non-GUI environment. And I would expect single binary to either use GUI or text interface based on what is available (and what is requested by user). -- Waldek Hebisch hebisch at math.uni.wroc.pl From ralex at cs.colorado.edu Tue May 19 05:05:25 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Tue, 19 May 2009 08:05:25 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <1242657940.3605.41.camel@hp64> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> Message-ID: <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> not so fast ;-) The "how can we make use of multiple cores" is currently on the the hottest funding topics supported by NSF, DOE, Microsoft, ..... Perhaps it is the Lisp way to look at architectures such as the x86 and see mostly limitations when indeed there are plenty of opportunities. This is not about registers but about enabling end user programmers such as scientists to make use of parallelism. The big question is how to reconceptualize programming. One of the main problems is the need to overcome bad algorithmic assumptions especially the use of unnecessary loops. For instance, in Bioinformatics textbooks are full of loop based implementations of algorithms dealing with huge data structures such as gene sequences. In many cases one could replace sequential loops with parallel execution. Zoom out of the low level view of things. What could multi core Lisp do? Look at the computational challenges that users are dealing with. Try to come up with new computational paradigms that could help. Lisp could be a great platform to explore these issues. Careful: if you can contribute to this you may actually receive funding. alex On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: > On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: > >> My ignorance of compiler design is breathtaking, but could multi-core >> compiler techniques be used to compensate for Intel's register- >> starved >> architecture? > > In a word, no. Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From lisp at clairvaux.org Tue May 19 06:13:43 2009 From: lisp at clairvaux.org (Glen Foy) Date: Tue, 19 May 2009 09:13:43 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: This is a fascinating area and clearly the wave of the future. We could have processors with 512 cores ten years from now. That power has to be utilized. A Lisp that focused on parallel execution would be an amazing tool. New worlds to conquer ... -Glen On May 19, 2009, at 8:05 AM, Alexander Repenning wrote: > not so fast ;-) > > The "how can we make use of multiple cores" is currently on the the > hottest funding topics supported by NSF, DOE, Microsoft, ..... > > Perhaps it is the Lisp way to look at architectures such as the x86 > and see mostly limitations when indeed there are plenty of > opportunities. This is not about registers but about enabling end > user programmers such as scientists to make use of parallelism. The > big question is how to reconceptualize programming. One of the main > problems is the need to overcome bad algorithmic assumptions > especially the use of unnecessary loops. For instance, in > Bioinformatics textbooks are full of loop based implementations of > algorithms dealing with huge data structures such as gene sequences. > In many cases one could replace sequential loops with parallel > execution. > > Zoom out of the low level view of things. What could multi core Lisp > do? Look at the computational challenges that users are dealing > with. Try to come up with new computational paradigms that could > help. Lisp could be a great platform to explore these issues. > Careful: if you can contribute to this you may actually receive > funding. > > alex > > > > On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: > >> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >> >>> My ignorance of compiler design is breathtaking, but could multi- >>> core >>> compiler techniques be used to compensate for Intel's register- >>> starved >>> architecture? >> >> In a word, no. > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From plkrueger at comcast.net Tue May 19 06:37:38 2009 From: plkrueger at comcast.net (Paul Krueger) Date: Tue, 19 May 2009 08:37:38 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: <31E07E76-2E04-46DD-9C90-E064EE4EF926@comcast.net> I completely agree with this. Before I retired from Cray last summer I was primarily investigating alternative computational paradigms for both massively multi-threaded and multi-core architectures. A couple of years ago, as Cray's representative, I attended a small NSF- sponsored conference of about 6 industry and 6 university representatives to discuss what sorts of research should be done to be ready for the multi-core architectures that we are beginning to see now. Microsoft's representative (Burton Smith, who was previously the architect of Cray's multi-threaded supercomputers) called this the preeminent current challenge for the software industry. Subsequently I identified a number of potential applications and computational approaches that are (or could be made to be) consistent with massively multi-threaded and/or multi-core architectures. These approaches included graph algorithms, genetic algorithms, fuzzy logic, memory-resident databases, and several others. Most of these would require quite a bit of software infrastructure development before they would be easy to use. These research/development suggestions got an enthusiastic reception from the technical community within Cray, but they couldn't stand up to a business-case analysis. There is a chicken- and-egg problem for Cray (and presumably for most vendors other than Intel and Microsoft) in that they can't afford to invest in this until there is sufficient demand; and there won't be much demand until users have a chance to try out and discover good uses for the new paradigms. I toyed with the idea of trying to promote a CCL port to Cray's multi- threaded architecture, but initial discussion with other senior management convinced me that it would never fly for lack of current demand. I briefly had visions of having access to the world's largest and fastest lisp machine; oh well ... NSF and DARPA will undoubtedly fund research in this area and they are known to take some chances on new ideas. But given how I saw them being pulled by influential industry and university factions, I expect that much of the funding will be used for small extensions to current paradigms rather than doing anything too radical. I hope I'm wrong about that. So the hope that I still have is that people such as those who subscribe to this newsgroup will continue to push the boundaries on their own; that CCL will turn into a really good multi-core tool to facilitate such research, and that eventually others will see the value too. Good luck to you all! Paul On May 19, 2009, at 7:05 AM, Alexander Repenning wrote: > not so fast ;-) > > The "how can we make use of multiple cores" is currently on the the > hottest funding topics supported by NSF, DOE, Microsoft, ..... > > Perhaps it is the Lisp way to look at architectures such as the x86 > and see mostly limitations when indeed there are plenty of > opportunities. This is not about registers but about enabling end > user programmers such as scientists to make use of parallelism. The > big question is how to reconceptualize programming. One of the main > problems is the need to overcome bad algorithmic assumptions > especially the use of unnecessary loops. For instance, in > Bioinformatics textbooks are full of loop based implementations of > algorithms dealing with huge data structures such as gene sequences. > In many cases one could replace sequential loops with parallel > execution. > > Zoom out of the low level view of things. What could multi core Lisp > do? Look at the computational challenges that users are dealing > with. Try to come up with new computational paradigms that could > help. Lisp could be a great platform to explore these issues. > Careful: if you can contribute to this you may actually receive > funding. > > alex > > > > On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: > >> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >> >>> My ignorance of compiler design is breathtaking, but could multi- >>> core >>> compiler techniques be used to compensate for Intel's register- >>> starved >>> architecture? >> >> In a word, no. > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Tue May 19 06:55:22 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Tue, 19 May 2009 15:55:22 +0200 Subject: [Openmcl-devel] encodings... Message-ID: Hi, So, I have finally the encodings :macintosh etc working. Still, the shift-alt-\ to have the source code doesn't recognize the ? ? ? etc. Same is for the search-file. That window do not find anything with an accent in it... I also had some problems with package names with accents. I can define them. But the in the document if I try to evaluate for example (in-package forme_r?elle) he says that there is no package with the name forme_r. if I use a nickname without accent in it, it works... Do I still miss something?.. Very Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From za at naa.att.ne.jp Tue May 19 09:16:43 2009 From: za at naa.att.ne.jp (Zoran Aleksic) Date: Wed, 20 May 2009 01:16:43 +0900 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: >not so fast ;-) > >The "how can we make use of multiple cores" is currently on the >the hottest funding topics supported by NSF, DOE, Microsoft, ..... > >Perhaps it is the Lisp way to look at architectures such as the x86 >and see mostly limitations when indeed there are plenty of >opportunities. This is not about registers but about enabling end >user programmers such as scientists to make use of parallelism. The >big question is how to reconceptualize programming. One of the main >problems is the need to overcome bad algorithmic assumptions >especially the use of unnecessary loops. For instance, in >Bioinformatics textbooks are full of loop based implementations of >algorithms dealing with huge data structures such as gene sequences. >In many cases one could replace sequential loops with parallel >execution. > >Zoom out of the low level view of things. What could multi core Lisp >do? Look at the computational challenges that users are dealing >with. Try to come up with new computational paradigms that could >help. Lisp could be a great platform to explore these >issues. Careful: if you can contribute to this you may actually >receive funding. > When concurrent (parallel) programing was a hot topics the last time, some 30 - 20 years ago, there were even a few concurrent Lisp dialects / implementations, for example QLisp or *Lisp (Star Lisp) ... za From ron at awun.net Tue May 19 09:44:39 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 09:44:39 -0700 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: Didn't the Lisp community already solve this problem with *Lisp on the Connection Machine? On May 19, 2009, at 6:13 AM, Glen Foy wrote: > This is a fascinating area and clearly the wave of the future. We > could have processors with 512 cores ten years from now. That power > has to be utilized. > > A Lisp that focused on parallel execution would be an amazing tool. > New worlds to conquer ... > > -Glen > > > > On May 19, 2009, at 8:05 AM, Alexander Repenning wrote: > >> not so fast ;-) >> >> The "how can we make use of multiple cores" is currently on the the >> hottest funding topics supported by NSF, DOE, Microsoft, ..... >> >> Perhaps it is the Lisp way to look at architectures such as the x86 >> and see mostly limitations when indeed there are plenty of >> opportunities. This is not about registers but about enabling end >> user programmers such as scientists to make use of parallelism. The >> big question is how to reconceptualize programming. One of the main >> problems is the need to overcome bad algorithmic assumptions >> especially the use of unnecessary loops. For instance, in >> Bioinformatics textbooks are full of loop based implementations of >> algorithms dealing with huge data structures such as gene >> sequences. In many cases one could replace sequential loops with >> parallel execution. >> >> Zoom out of the low level view of things. What could multi core >> Lisp do? Look at the computational challenges that users are >> dealing with. Try to come up with new computational paradigms that >> could help. Lisp could be a great platform to explore these issues. >> Careful: if you can contribute to this you may actually receive >> funding. >> >> alex >> >> >> >> On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: >> >>> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >>> >>>> My ignorance of compiler design is breathtaking, but could multi- >>>> core >>>> compiler techniques be used to compensate for Intel's register- >>>> starved >>>> architecture? >>> >>> In a word, no. >> >> Prof. Alexander Repenning >> >> University of Colorado >> Computer Science Department >> Boulder, CO 80309-430 >> >> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> >> > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Tue May 19 10:58:51 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Tue, 19 May 2009 13:58:51 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: <013AF232-BE29-416D-8A3A-A91627499B74@cs.colorado.edu> When I came to the University of Colorado that was my first job to program the connection machine (up to 65536 CPUs) in Lisp. Needless to say, the 12 dimensional hypercube architecture did not work out. Back then parallelism was super expensive. Now, probably the machine that you are reading this email on has at least two cores. Here is a slide comparing performance and price. Notice the price/GFlop ratio change: Having scientists with Fortran background write code in StarLisp for the CM2 was not a good idea at the time. The SIMD architecture was too limiting. But some of that work is ready to go on multi cores. For instance, if are interested in optimization and pathfinding you may find this interesting: http://www.cs.colorado.edu/~ralex/papers/PDF/OOPSLA06antiobjects.pdf Alex On May 19, 2009, at 12:44 PM, Ron Garret wrote: > Didn't the Lisp community already solve this problem with *Lisp on > the Connection Machine? > > On May 19, 2009, at 6:13 AM, Glen Foy wrote: > >> This is a fascinating area and clearly the wave of the future. We >> could have processors with 512 cores ten years from now. That >> power has to be utilized. >> >> A Lisp that focused on parallel execution would be an amazing >> tool. New worlds to conquer ... >> >> -Glen >> >> >> >> On May 19, 2009, at 8:05 AM, Alexander Repenning wrote: >> >>> not so fast ;-) >>> >>> The "how can we make use of multiple cores" is currently on the >>> the hottest funding topics supported by NSF, DOE, Microsoft, ..... >>> >>> Perhaps it is the Lisp way to look at architectures such as the >>> x86 and see mostly limitations when indeed there are plenty of >>> opportunities. This is not about registers but about enabling end >>> user programmers such as scientists to make use of parallelism. >>> The big question is how to reconceptualize programming. One of the >>> main problems is the need to overcome bad algorithmic assumptions >>> especially the use of unnecessary loops. For instance, in >>> Bioinformatics textbooks are full of loop based implementations of >>> algorithms dealing with huge data structures such as gene >>> sequences. In many cases one could replace sequential loops with >>> parallel execution. >>> >>> Zoom out of the low level view of things. What could multi core >>> Lisp do? Look at the computational challenges that users are >>> dealing with. Try to come up with new computational paradigms that >>> could help. Lisp could be a great platform to explore these >>> issues. Careful: if you can contribute to this you may actually >>> receive funding. >>> >>> alex >>> >>> >>> >>> On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: >>> >>>> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >>>> >>>>> My ignorance of compiler design is breathtaking, but could multi- >>>>> core >>>>> compiler techniques be used to compensate for Intel's register- >>>>> starved >>>>> architecture? >>>> >>>> In a word, no. >>> >>> Prof. Alexander Repenning >>> >>> University of Colorado >>> Computer Science Department >>> Boulder, CO 80309-430 >>> >>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >>> >>> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.jpg Type: image/jpeg Size: 331278 bytes Desc: not available URL: From lisp at clairvaux.org Tue May 19 11:00:37 2009 From: lisp at clairvaux.org (Glen Foy) Date: Tue, 19 May 2009 14:00:37 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: <8F98D8A8-5ABC-4085-929B-52A0DB1EC48D@clairvaux.org> Here's an interesting thread about the Connection Machine: http://lambda-the-ultimate.org/node/87 I think Paul Krueger's post is on target. Not only do we need a Lisp that facilitates parallel execution (CM), we need a Lisp that facilitates a parallel programming paradigm, genetic algorithms, neural nets, etc. Since Lisp is the "programmable programing language" and extremely good for developing embedded languages it is a natural choice. As Lisp hackers we can go ahead and place orders for those new BMWs ... :-) On May 19, 2009, at 12:44 PM, Ron Garret wrote: > Didn't the Lisp community already solve this problem with *Lisp on > the Connection Machine? > > On May 19, 2009, at 6:13 AM, Glen Foy wrote: > >> This is a fascinating area and clearly the wave of the future. We >> could have processors with 512 cores ten years from now. That >> power has to be utilized. >> >> A Lisp that focused on parallel execution would be an amazing >> tool. New worlds to conquer ... >> >> -Glen >> >> >> >> On May 19, 2009, at 8:05 AM, Alexander Repenning wrote: >> >>> not so fast ;-) >>> >>> The "how can we make use of multiple cores" is currently on the >>> the hottest funding topics supported by NSF, DOE, Microsoft, ..... >>> >>> Perhaps it is the Lisp way to look at architectures such as the >>> x86 and see mostly limitations when indeed there are plenty of >>> opportunities. This is not about registers but about enabling end >>> user programmers such as scientists to make use of parallelism. >>> The big question is how to reconceptualize programming. One of the >>> main problems is the need to overcome bad algorithmic assumptions >>> especially the use of unnecessary loops. For instance, in >>> Bioinformatics textbooks are full of loop based implementations of >>> algorithms dealing with huge data structures such as gene >>> sequences. In many cases one could replace sequential loops with >>> parallel execution. >>> >>> Zoom out of the low level view of things. What could multi core >>> Lisp do? Look at the computational challenges that users are >>> dealing with. Try to come up with new computational paradigms that >>> could help. Lisp could be a great platform to explore these >>> issues. Careful: if you can contribute to this you may actually >>> receive funding. >>> >>> alex >>> >>> >>> >>> On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: >>> >>>> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >>>> >>>>> My ignorance of compiler design is breathtaking, but could multi- >>>>> core >>>>> compiler techniques be used to compensate for Intel's register- >>>>> starved >>>>> architecture? >>>> >>>> In a word, no. >>> >>> Prof. Alexander Repenning >>> >>> University of Colorado >>> Computer Science Department >>> Boulder, CO 80309-430 >>> >>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >>> >>> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Tue May 19 11:12:49 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Tue, 19 May 2009 14:12:49 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: <4A12F6A1.9040503@itasoftware.com> Alexander Repenning wrote: > not so fast ;-) > > The "how can we make use of multiple cores" is currently on the > the hottest funding topics supported by NSF, DOE, Microsoft, ..... > For some applications, it's very easy to take advantage of all those cores. The airline reservation system we're building at ITA has its "core" (business tier) model written in Common Lisp. We get lots and lots of requests coming in, which are distributed to a load balancer to a lot (maybe 20?) of boxes, each of which has 8 cores and 32GB of memory. On each one, we run 8 CCL processes, and each one has a single request-handling thread. Voila, all the cores are being used. But, of course, you're talking about situations where a single program wants to use lots of cores. The approach being taken by many new languages is (1) do as much as possible with no side effects, so that nobody is writing anything, and therefore no two threads have conflicts, and (2) when you do have two threads reading and/or writing the same memory, use transactions. Guy Steele said that it's quite amazing how many new languages work this way. His own new language, Fortress is one of them, and he named several others. Anders Hejlsberg, the C# inventor at Microsoft, is also talking about this approach (I've seen him discuss it in two videos that I found on the web). And you know what other language works this way? Clojure, a very promising new dialect of Lisp. -- Dan > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From jaj at clozure.com Tue May 19 11:39:17 2009 From: jaj at clozure.com (Jeremy Jones) Date: Tue, 19 May 2009 14:39:17 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A12F6A1.9040503@itasoftware.com> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <4A12F6A1.9040503@itasoftware.com> Message-ID: On Tue, May 19, 2009 at 2:12 PM, Dan Weinreb wrote: > ... > And you know what other language works this way? > Clojure, a very promising new dialect of Lisp. > > -- Dan I'd like to endorse the approach taken by Clojure (the other Closure) too. It is a dialect of Lisp that where a central design decision was to make almost all data structures immutable. This obviates most of the need for locking, a common performance issue for multi-threaded programs. It is easy to write programs that rarely use shared, mutable data structures. And when you do need shared, mutable data structures, the locking is explicit. Take a look at a http://clojure.blip.tv/file/1313398/ for an introduction to Clojure for Lisp programmers. I wasn't expecting much, but it's really good. Someone could define a version of Common Lisp with these characteristics... From ron at awun.net Tue May 19 11:45:18 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 11:45:18 -0700 Subject: [Openmcl-devel] My beach balls runneth over Message-ID: I regret to report that CCL 1.3 seems to still have some pretty serious bugs. The UI is much improved, pretty much usable at this point. But as soon as I lean on it (i.e. try to run some of Alexander Repenning's demos) it hangs with the dreaded SBOD. Sometimes it hangs without my even having to lean on it, just playing around with Hemlock (and by "playing around" I mean just editing, not hacking the Hemlock code). On one occasion I ended up in the CCL Kernel debugger. I have not yet played around enough to see if I can find a reliable way to reproduce the problem. Many of the demos do work, but I have yet to go more than about 10 minutes at a time without a crash. My questions are: 1. Is anyone else seeing this behavior or is it just me? I can't imagine how Alexander was able to write this code if he was having the same experience I am. 2. If this is a known problem, what's the prognosis for getting it fixed? 3. Is there anything I can do when I encounter the SBOD to extract useful debugging information? Thanks, rg From alms at clozure.com Tue May 19 11:51:36 2009 From: alms at clozure.com (Andrew Shalit) Date: Tue, 19 May 2009 14:51:36 -0400 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: References: Message-ID: <19FD0165-BAFC-439F-93E0-25522491586B@clozure.com> For those not up on the lingo (like me), SBOD = "Spinning Beachball of Doom". i.e. it's a Mac thing. On May 19, 2009, at 2:45 PM, Ron Garret wrote: > I regret to report that CCL 1.3 seems to still have some pretty > serious bugs. The UI is much improved, pretty much usable at this > point. But as soon as I lean on it (i.e. try to run some of Alexander > Repenning's demos) it hangs with the dreaded SBOD. Sometimes it > hangs without my even having to lean on it, just playing around with > Hemlock (and by "playing around" I mean just editing, not hacking the > Hemlock code). On one occasion I ended up in the CCL Kernel > debugger. I have not yet played around enough to see if I can find a > reliable way to reproduce the problem. Many of the demos do work, but > I have yet to go more than about 10 minutes at a time without a crash. > > My questions are: > > 1. Is anyone else seeing this behavior or is it just me? I can't > imagine how Alexander was able to write this code if he was having the > same experience I am. > > 2. If this is a known problem, what's the prognosis for getting it > fixed? > > 3. Is there anything I can do when I encounter the SBOD to extract > useful debugging information? > > Thanks, > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From j-anthony at comcast.net Tue May 19 13:13:55 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Tue, 19 May 2009 16:13:55 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: <1242764035.2419.198.camel@sirius> On Tue, 2009-05-19 at 09:13 -0400, Glen Foy wrote: > This is a fascinating area and clearly the wave of the future. We > could have processors with 512 cores ten years from now. That power > has to be utilized. > > > A Lisp that focused on parallel execution would be an amazing tool. > New worlds to conquer ... Have a look at this: http://clojure.org/concurrent_programming I think this is a very interesting and promising approach which will win in most cases. /Jon From j-anthony at comcast.net Tue May 19 13:15:11 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Tue, 19 May 2009 16:15:11 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A12F6A1.9040503@itasoftware.com> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <4A12F6A1.9040503@itasoftware.com> Message-ID: <1242764111.2419.201.camel@sirius> > And you know what other language works this way? > Clojure, a very promising new dialect of Lisp. Dang - you beat me to it - I just replied about Clojure in this respect... /Jon From rme at clozure.com Tue May 19 13:05:45 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 19 May 2009 16:05:45 -0400 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: References: Message-ID: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> On May 19, 2009, at 2:45 PM, Ron Garret wrote: > I regret to report that CCL 1.3 seems to still have some pretty > serious bugs. The UI is much improved, pretty much usable at this > point. But as soon as I lean on it (i.e. try to run some of Alexander > Repenning's demos) it hangs with the dreaded SBOD. Sometimes it > hangs without my even having to lean on it, just playing around with > Hemlock (and by "playing around" I mean just editing, not hacking the > Hemlock code). On one occasion I ended up in the CCL Kernel > debugger. I have not yet played around enough to see if I can find a > reliable way to reproduce the problem. Many of the demos do work, but > I have yet to go more than about 10 minutes at a time without a crash. > > My questions are: > > 1. Is anyone else seeing this behavior or is it just me? I can't > imagine how Alexander was able to write this code if he was having the > same experience I am. I've been using the IDE full-time for the past few weeks, and although I've crashed it from time to time, this is usually due to me screwing up when calling foreign code. Certainly I can use it to edit code for more than 10 minutes at a time without having it fall over. I am running the trunk, so if you're running the 1.3 branch, you might try running the trunk too. If anyone were to ask my opinion on whether to run 1.3 or the trunk, I'd normally recommend 1.3. On the other hand, there is IDE work is happening in the trunk, and I don't quite know how or if that work should end up in 1.3. So, it might not be such a bad idea for IDE users to run the trunk for now. > 2. If this is a known problem, what's the prognosis for getting it > fixed? I know it can be a lot of work, and you may not want to bother, but if you can come up with cases that demonstrate bugs, I'll (try to) fix those bugs > 3. Is there anything I can do when I encounter the SBOD to extract > useful debugging information? I start up CCL in a terminal, and then do (require 'cocoa). If the event thread goes out to lunch (which is typically what a spinning beach ball indicates), it should at least show some sort of backtrace in the terminal. This may or may not point to the problem, but it's better (though not much better) than nothing. From gb at clozure.com Tue May 19 13:36:32 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 19 May 2009 14:36:32 -0600 (MDT) Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: References: Message-ID: <20090519125152.G72709@abq.clozure.com> Without a reliable way to reproduce the problem(s), it's very difficult to have any idea of what the problem is or how to fix it. If you wind up in the kernel debugger and don't know why, trying to figure out how you got there ("b" generates a backtrace that at least shows the lisp stack up to the last foreign function call, "r" shows machine register values. If running under the standlone IDE, output from those commands goes to the window maintained by the AltConsole application; that windows's contents can be saved to a text file. Many library functions write diagnostic messages to system logfiles; /Applications/Utilities/Console.app can be used to view these logfiles. It's possible that some messages might mention problems that lead up to the SBOD. The beachball cursor generally means that the thread which waits for and processes events hasn't tried to fetch an event in a while (I think that "a while" is "about 1 second.") There can be any number of reasons for this; among the more mundane reasons are cases where the event thread is sitting in the kernel debugger or a break loop (waiting for input in the AltConsole window.) On Tue, 19 May 2009, Ron Garret wrote: > I regret to report that CCL 1.3 seems to still have some pretty > serious bugs. The UI is much improved, pretty much usable at this > point. But as soon as I lean on it (i.e. try to run some of Alexander > Repenning's demos) it hangs with the dreaded SBOD. Sometimes it > hangs without my even having to lean on it, just playing around with > Hemlock (and by "playing around" I mean just editing, not hacking the > Hemlock code). On one occasion I ended up in the CCL Kernel > debugger. I have not yet played around enough to see if I can find a > reliable way to reproduce the problem. Many of the demos do work, but > I have yet to go more than about 10 minutes at a time without a crash. > > My questions are: > > 1. Is anyone else seeing this behavior or is it just me? I can't > imagine how Alexander was able to write this code if he was having the > same experience I am. > > 2. If this is a known problem, what's the prognosis for getting it > fixed? > > 3. Is there anything I can do when I encounter the SBOD to extract > useful debugging information? > > Thanks, > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From ron at awun.net Tue May 19 13:47:34 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 13:47:34 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> Message-ID: <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> On May 19, 2009, at 1:05 PM, R. Matthew Emerson wrote: > I know it can be a lot of work, and you may not want to bother, but > if you can come up with cases that demonstrate bugs, I'll (try to) > fix those bugs No problem. The following seems to be pretty reproducible: 1. Load Alexander Repenning's LUI package. 2. Run the following code: (in-package :xlui) 3. (Optional) Marvel at the seamless integration of XML syntax into Lisp. 4. Slide one of the sliders. The AltConsole should start up and display a bunch of output. Close the window and slide the slider again. The result should be the SBOD until you manually re-open the AltConsole. That should unwedge it. However... 5. Observe that your listener window is now scrolling veeeeerrrryyyy slooooowwwwlllly. 6. Close the listener and open a new one. Observe that the previous slowness is gone. (In the past this step as also sometimes landed me in the kernel debugger, but right now I can't reproduce that.) rg From gb at clozure.com Tue May 19 13:54:05 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 19 May 2009 14:54:05 -0600 (MDT) Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> Message-ID: <20090519145036.N72709@abq.clozure.com> On Tue, 19 May 2009, Ron Garret wrote: > > On May 19, 2009, at 1:05 PM, R. Matthew Emerson wrote: > >> I know it can be a lot of work, and you may not want to bother, but >> if you can come up with cases that demonstrate bugs, I'll (try to) >> fix those bugs > > No problem. The following seems to be pretty reproducible: > > 1. Load Alexander Repenning's LUI package. > > 2. Run the following code: > > (in-package :xlui) > > > > > > > > > > 3. (Optional) Marvel at the seamless integration of XML syntax into > Lisp. > > 4. Slide one of the sliders. The AltConsole should start up and > display a bunch of output. AKA "backtraces and error messages." It's almost like something's trying to communicate with us ... From ron at awun.net Tue May 19 14:04:27 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 14:04:27 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <20090519145036.N72709@abq.clozure.com> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <20090519145036.N72709@abq.clozure.com> Message-ID: On May 19, 2009, at 1:54 PM, Gary Byers wrote: > > > On Tue, 19 May 2009, Ron Garret wrote: > >> >> On May 19, 2009, at 1:05 PM, R. Matthew Emerson wrote: >> >>> I know it can be a lot of work, and you may not want to bother, but >>> if you can come up with cases that demonstrate bugs, I'll (try to) >>> fix those bugs >> >> No problem. The following seems to be pretty reproducible: >> >> 1. Load Alexander Repenning's LUI package. >> >> 2. Run the following code: >> >> (in-package :xlui) >> >> >> >> >> >> >> >> >> >> 3. (Optional) Marvel at the seamless integration of XML syntax into >> Lisp. >> >> 4. Slide one of the sliders. The AltConsole should start up and >> display a bunch of output. > > AKA "backtraces and error messages." It's almost like something's > trying to communicate with us ... Normally perhaps, but in this case it appears to be diagnostic output generated by the LUI code. There are no actual errors being generated. Here's a small sample: , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= control default action: window= , target= From ron at awun.net Tue May 19 14:08:52 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 14:08:52 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> Message-ID: On May 19, 2009, at 1:47 PM, Ron Garret wrote: > > 6. Close the listener and open a new one. Observe that the previous > slowness is gone. (In the past this step as also sometimes landed me > in the kernel debugger, but right now I can't reproduce that.) Doh! There it goes (after running a few more examples -- I'll try to find a reliable sequence). In the meantime, here's the backtrace: Exception occurred while executing foreign code at objc_msgSend + 63 ? for help [4937] Clozure CL kernel debugger: b current thread: tcr = 0x10400920, native thread ID = 0x29907, interrupts enabled (#x000000001095BCF8) #x0000300041307F5C : # + 653 (#x000000001095BD30) #x0000300040F4C1F4 : # + 501 (#x000000001095BD70) #x0000300041A6A594 : # + 1701 (#x000000001095BDA0) #x0000300041A6B674 : # + 149 (#x000000001095BDF8) #x0000300041A7AF44 : # + 1301 (#x000000001095BE98) #x0000300041A7B7DC : # + 61 (#x000000001095BEB8) #x00003000404AB95C : # + 717 (#x000000001095BF48) #x00003000404AC3A4 : # + 389 (#x000000001095BF98) #x000030004048D40C : # + 301 [4937] Clozure CL kernel debugger: From gb at clozure.com Tue May 19 14:13:02 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 19 May 2009 15:13:02 -0600 (MDT) Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <20090519145036.N72709@abq.clozure.com> Message-ID: <20090519150738.Q72709@abq.clozure.com> If there's a way to suppress that diagnostic output, it'd be interesting to see whether or not that affects behavior (and if there -is- ever any other kind of output being generated, it might be easier to see.) In the meantime, when the application beachballs, is this sort of output still being generated, or has everything gone eerily quiet ? On Tue, 19 May 2009, Ron Garret wrote: > > On May 19, 2009, at 1:54 PM, Gary Byers wrote: > >> >> >> On Tue, 19 May 2009, Ron Garret wrote: >> >>> >>> On May 19, 2009, at 1:05 PM, R. Matthew Emerson wrote: >>> >>>> I know it can be a lot of work, and you may not want to bother, but >>>> if you can come up with cases that demonstrate bugs, I'll (try to) >>>> fix those bugs >>> >>> No problem. The following seems to be pretty reproducible: >>> >>> 1. Load Alexander Repenning's LUI package. >>> >>> 2. Run the following code: >>> >>> (in-package :xlui) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 3. (Optional) Marvel at the seamless integration of XML syntax into >>> Lisp. >>> >>> 4. Slide one of the sliders. The AltConsole should start up and >>> display a bunch of output. >> >> AKA "backtraces and error messages." It's almost like something's >> trying to communicate with us ... > > Normally perhaps, but in this case it appears to be diagnostic output > generated by the LUI code. There are no actual errors being generated. > Here's a small sample: > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > control default action: window= width="340" height="180"> > valign="DISTRIBUTE"> > > > > > , target= > From raffaelcavallaro at mac.com Tue May 19 14:16:30 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Tue, 19 May 2009 17:16:30 -0400 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> Message-ID: <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> On May 19, 2009, at 4:47 PM, Ron Garret wrote: > 1. Load Alexander Repenning's LUI package. > > 2. Run the following code: > > (in-package :xlui) > > > > > > > > > > 3. (Optional) Marvel at the seamless integration of XML syntax into > Lisp. > > 4. Slide one of the sliders. The AltConsole should start up and > display a bunch of output. With you so far > Close the window and slide the slider > again. The result should be the SBOD until you manually re-open the > AltConsole. That should unwedge it. However... > > 5. Observe that your listener window is now scrolling veeeeerrrryyyy > slooooowwwwlllly. > > 6. Close the listener and open a new one. Observe that the previous > slowness is gone. (In the past this step as also sometimes landed me > in the kernel debugger, but right now I can't reproduce that.) I don't see any of this. I'm running trunk though. Maybe you should switch? regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From ron at awun.net Tue May 19 14:24:32 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 14:24:32 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <20090519150738.Q72709@abq.clozure.com> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <20090519145036.N72709@abq.clozure.com> <20090519150738.Q72709@abq.clozure.com> Message-ID: <423C425C-67F0-4563-9585-7576E7CFF3BB@awun.net> Hard to say because it only hangs when the AltConsole is hidden. When it hangs the slider stops responding and so presumably is no longer producing output. If you bring up the AltConsole to see what's going on, it unhangs, dumps a bunch of (presumably buffered) output and then stops. It feels to me like a deadlock. rg On May 19, 2009, at 2:13 PM, Gary Byers wrote: > If there's a way to suppress that diagnostic output, it'd be > interesting to see whether or not that affects behavior (and > if there -is- ever any other kind of output being generated, > it might be easier to see.) > > In the meantime, when the application beachballs, is this > sort of output still being generated, or has everything > gone eerily quiet ? > > On Tue, 19 May 2009, Ron Garret wrote: > >> >> On May 19, 2009, at 1:54 PM, Gary Byers wrote: >> >>> On Tue, 19 May 2009, Ron Garret wrote: >>>> On May 19, 2009, at 1:05 PM, R. Matthew Emerson wrote: >>>>> I know it can be a lot of work, and you may not want to bother, >>>>> but >>>>> if you can come up with cases that demonstrate bugs, I'll (try to) >>>>> fix those bugs >>>> No problem. The following seems to be pretty reproducible: >>>> 1. Load Alexander Repenning's LUI package. >>>> 2. Run the following code: >>>> (in-package :xlui) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 3. (Optional) Marvel at the seamless integration of XML syntax >>>> into >>>> Lisp. >>>> 4. Slide one of the sliders. The AltConsole should start up and >>>> display a bunch of output. >>> AKA "backtraces and error messages." It's almost like something's >>> trying to communicate with us ... >> >> Normally perhaps, but in this case it appears to be diagnostic >> output generated by the LUI code. There are no actual errors being >> generated. Here's a small sample: >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> control default action: window=> width="340" height="180"> >> > valign="DISTRIBUTE"> >> >> >> >> >> , target= >> From ron at awun.net Tue May 19 14:40:27 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 14:40:27 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> Message-ID: <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: > I don't see any of this. I'm running trunk though. Maybe you should > switch? > Trying that now. For the record, the version I was running came from the instructions on http://trac.clozure.com/openmcl: The preferred way to get Clozure CL is via Subversion. For example, to get Clozure CL 1.3 for Darwin/x86, you'd type (where the $ is the shell prompt): $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl If people should be running the trunk this probably ought to be changed or I'm not going to be the only one having these problems. Also for the record, I can tolerate a certain amount of instability at the moment if problems like this are being fixed relatively quickly (like hours to days rather than weeks to months). I'm not doing anything mission-critical right now, so it's actually a good time for me to be a guinea pig. rg -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at awun.net Tue May 19 14:47:27 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 14:47:27 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> Message-ID: <8765D5CE-0C11-4B33-B974-111C7EC640F2@awun.net> On May 19, 2009, at 2:40 PM, Ron Garret wrote: > > On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: > > >> I don't see any of this. I'm running trunk though. Maybe you should >> switch? >> > > Trying that now. I tried this version: svn co http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl and got the same results. I noticed on the about window that it says this: Clozure Common Lisp version 0.1 (12092M-trunk) so I'm not 100% sure that I'm really running what I should be running. I'm running OS X 10.5.7 if that makes any difference. rg From ron at awun.net Tue May 19 14:53:24 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 14:53:24 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> Message-ID: On May 19, 2009, at 2:40 PM, Ron Garret wrote: > > On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: > > >> I don't see any of this. I'm running trunk though. Maybe you should >> switch? >> > > Trying that now. For the record, the version I was running came > from the instructions on http://trac.clozure.com/openmcl: > > The preferred way to get Clozure CL is via Subversion. For example, > to get Clozure CL 1.3 for Darwin/x86, you'd type (where the $ is the > shell prompt): > > $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl > > If people should be running the trunk this probably ought to be > changed or I'm not going to be the only one having these problems. > > Also for the record, I can tolerate a certain amount of instability > at the moment if problems like this are being fixed relatively > quickly (like hours to days rather than weeks to months). I'm not > doing anything mission-critical right now, so it's actually a good > time for me to be a guinea pig. > Youch! Brain wedgie. Of course, the trunk *is* the bleeding edge. rg -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at mcaleely.com Tue May 19 15:07:32 2009 From: john at mcaleely.com (John McAleely) Date: Tue, 19 May 2009 23:07:32 +0100 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> Message-ID: <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> I've held off from responding on this thread for a while, but your description of using the IDE and finding it very unstable is exactly the experience I had a couple of months ago. I would have been using 1.2, so when you reported 1.3 was similar, I was assuming the work in trunk might make my experience irrelevant. However, now that it seems that some users of trunk can use it successfully, while you see instability means I do at least want to observe that I saw the same sort of problems you see. My usage was a Saturday spent prototyping non critical (and very newbie) code. I resolved not to touch the IDE again until the current work package was concluded. (My production use of CCL is all via the command line). I assumed all IDE users experienced the same problems, and that my lack of experience would reduce the value of bug reports, given that more experienced people would also find these. If that is not the case, I am inclined to find some time to play a little more in my setup and see if I can create reproducible bugs, rather than simply a long winded 'me too' posting on this list. J On 19 May 2009, at 22:53, Ron Garret wrote: > > On May 19, 2009, at 2:40 PM, Ron Garret wrote: > >> >> On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: >> >> >>> I don't see any of this. I'm running trunk though. Maybe you >>> should switch? >>> >> >> Trying that now. For the record, the version I was running came >> from the instructions on http://trac.clozure.com/openmcl: >> >> The preferred way to get Clozure CL is via Subversion. For example, >> to get Clozure CL 1.3 for Darwin/x86, you'd type (where the $ is >> the shell prompt): >> >> $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl >> >> If people should be running the trunk this probably ought to be >> changed or I'm not going to be the only one having these problems. >> >> Also for the record, I can tolerate a certain amount of instability >> at the moment if problems like this are being fixed relatively >> quickly (like hours to days rather than weeks to months). I'm not >> doing anything mission-critical right now, so it's actually a good >> time for me to be a guinea pig. >> > > Youch! Brain wedgie. Of course, the trunk *is* the bleeding edge. > > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mevins at mac.com Tue May 19 16:37:30 2009 From: mevins at mac.com (mikel evins) Date: Tue, 19 May 2009 18:37:30 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A12F6A1.9040503@itasoftware.com> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <4A12F6A1.9040503@itasoftware.com> Message-ID: <323EE725-7F6B-48F6-9578-70AC20EC6C6F@mac.com> On May 19, 2009, at 1:12 PM, Dan Weinreb wrote: > > > Alexander Repenning wrote: >> not so fast ;-) >> >> The "how can we make use of multiple cores" is currently on the >> the hottest funding topics supported by NSF, DOE, Microsoft, ..... >> > For some applications, it's very easy to take advantage of all those > cores. The airline reservation system we're building at ITA > has its "core" (business tier) model written in Common Lisp. > We get lots and lots of requests coming in, which are distributed > to a load balancer to a lot (maybe 20?) of boxes, each of > which has 8 cores and 32GB of memory. On each one, > we run 8 CCL processes, and each one has a single > request-handling thread. Voila, all the cores are > being used. > > But, of course, you're talking about situations where a single > program wants to use lots of cores. > > The approach being taken by many new languages is > (1) do as much as possible with no side effects, so > that nobody is writing anything, and therefore > no two threads have conflicts, and (2) when you do > have two threads reading and/or writing the same > memory, use transactions. > > Guy Steele said that it's quite amazing how many new > languages work this way. His own new language, > Fortress is one of them, and he named several > others. Anders Hejlsberg, the C# inventor at > Microsoft, is also talking about this approach (I've > seen him discuss it in two videos that I found on > the web). > > And you know what other language works this way? > Clojure, a very promising new dialect of Lisp. Yup. It works pretty well. I've used it a lot for about eight months. You can't get something that works as well simply by adding Clojure's concurrency features to Common Lisp. Clojure *forbids* simple assignment; you can't do it. There are four data types that support assignment, and none of them supports simple assignment. All four use transactional assignment that is safe under concurrent use, but significantly more expensive than simple assignment. Clojure's basic data structures are also different from Common Lisp's, despite looking familiar. Its List, Vector, and Map types, for example, look like CL's lists, vectors, and hashtables, but are fundamentally different data structures under the covers, in order to support both immutability and efficient updates. (They are implemented using Bagwell's ideal hash tries, which provide an efficient way to implement "inserts" as newly- created data structures that refer to unaltered old ones). Clojure forbids simple assignment because all it takes to destroy its safety guarantees under concurrency is a single SETQ in the wrong context. Presumably, this is why some of the approaches it uses, such as Software Transactional Memory, are widely used in languages like Haskell and not widely used in languages like C and Common Lisp: because all your safety guarantees go out the window in the presence of simple assignment. Clojure and Haskell solve that problem by making simple assignment impossible. (Actually, Clojure doesn't; because it runs on the JVM and provides a seamless integration with Java, you can still do simple assignment using the Java features. If you do that, though All Bets Are Off). --me From mevins at mac.com Tue May 19 16:39:07 2009 From: mevins at mac.com (mikel evins) Date: Tue, 19 May 2009 18:39:07 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <4A12F6A1.9040503@itasoftware.com> Message-ID: On May 19, 2009, at 1:39 PM, Jeremy Jones wrote: > On Tue, May 19, 2009 at 2:12 PM, Dan Weinreb > wrote: >> ... >> And you know what other language works this way? >> Clojure, a very promising new dialect of Lisp. >> >> -- Dan > > I'd like to endorse the approach taken by Clojure (the other Closure) > too. It is a dialect of Lisp that where a central design decision was > to make almost all data structures immutable. This obviates most of > the need for locking, a common performance issue for multi-threaded > programs. It is easy to write programs that rarely use shared, > mutable data structures. And when you do need shared, mutable data > structures, the locking is explicit. Take a look at a > http://clojure.blip.tv/file/1313398/ for an introduction to Clojure > for Lisp programmers. I wasn't expecting much, but it's really good. > > Someone could define a version of Common Lisp with these > characteristics... It wouldn't be Common Lisp, or, if it was still Common Lisp, the Clojure features wouldn't buy you much. See my other message on the subject. In order to get Clojure's benefits for concurrency, you have to say goodbye to SETQ. --me From gb at clozure.com Tue May 19 17:03:02 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 19 May 2009 18:03:02 -0600 (MDT) Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> Message-ID: <20090519170547.O72709@abq.clozure.com> Is this a fair characterization of what we know so far: - when using third-party code under the IDE, the system becomes periodically unresponsive in ways that may have something to do with the fact that that code generates (possibly large amounts of) diagnostic output and with AltConsole's ability to keep up with it ? FWIW, I tried modifying the #/sendEvent: method (in cocoa-ide/cocoa-utils.lisp) so that it did: (apropos "NX" "CCL") at the beginning of its body. On a ~3GHz iMac, that was enough extra work for the event thread that scroll-bar tracking was unreliable but the system rarely beachballed; if I changed that to: (apropos "" "CCL") I couldn't get a word in edgewise: the event thread was so busy either generating output or blocking waiting for previously buffered output to be read that it was unable to process events. Both cases probably involve more output being generated than what you're seeing, but the different behavior and the fact that some other people have difficulty reproducing what you see suggests that what happens here may have to do with processor speed and system load; I can think of some ways to speed this up, but it's generally not a good idea to do potentially blocking I/O operations in event handlers. Doing (loop) in an event handler is a very bad idea. - when using the same third-party code under the IDE, you crashed into the kernel debugger, apparently in some code having to do with anticipatory symbol completion ? I remember thinking that the code described in: was trying to do drawing from a secondary thread without taking appropriate precautions before doing so. (See the examples in for more information about this.) If I'm correct in thinking that that was a problem that caused the anticipatory symbol completion code to sometimes work and sometimes crash, I'm not sure that anyone ever followed up on it; if I'm misremembering ... never mind. It's certainly possible that general IDE instability is responsible for or contributes to these problems, but it also seems possible that neither of these things is anything that we have any direct control over, and it seems premature to conclude anything about general IDE [in]stability based on these examples. Does anyone disagree with this ? On Tue, 19 May 2009, Ron Garret wrote: > > On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: > > >> I don't see any of this. I'm running trunk though. Maybe you should switch? >> > > Trying that now. For the record, the version I was running came from the > instructions on http://trac.clozure.com/openmcl: > > The preferred way to get Clozure CL is via Subversion. For example, to get > Clozure CL 1.3 for Darwin/x86, you'd type (where the $ is the shell prompt): > > $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl > > If people should be running the trunk this probably ought to be changed or > I'm not going to be the only one having these problems. > > Also for the record, I can tolerate a certain amount of instability at the > moment if problems like this are being fixed relatively quickly (like hours > to days rather than weeks to months). I'm not doing anything > mission-critical right now, so it's actually a good time for me to be a > guinea pig. > > rg > From ron at awun.net Tue May 19 17:38:27 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 17:38:27 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <20090519170547.O72709@abq.clozure.com> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> <20090519170547.O72709@abq.clozure.com> Message-ID: I think it's actually much simpler than this. I'm able to reproduce part of the problem simply by doing: (dotimes (i 1000000) (print i ccl::*stdout*) (print i)) and then closing the AltConsole window. It's not beach-balled in this case, but CPU usage is zero, and attempting to open a new listener hangs with a "Lock wait for recursive lock" message in the mini- buffer. Re-opening the AltConsole makes it start up again. Hm, turns out I can actually interrupt execution while it's hung in this case and verify that the counter is not incrementing. The break is invariably in CCL::FD-WRITE, which is not surprising. So what seems to be happening is that when the AltConsole window is closed, the AltConsole buffer backs up to the point where attempts to write to the AltConsole will block. If while in this state the event- handling thread attempts to write to the AltConsole, it will block and you're wedged. This does not explain why I sometimes end up in the kernel debugger, but it's possible we're dealing with two separate problems here. rg On May 19, 2009, at 5:03 PM, Gary Byers wrote: > Is this a fair characterization of what we know so far: > > - when using third-party code under the IDE, the system becomes > periodically > unresponsive in ways that may have something to do with the fact > that that > code generates (possibly large amounts of) diagnostic output and with > AltConsole's ability to keep up with it ? > > FWIW, I tried modifying the #/sendEvent: method (in cocoa-ide/cocoa- > utils.lisp) > so that it did: > > (apropos "NX" "CCL") > > at the beginning of its body. On a ~3GHz iMac, that was enough > extra work > for the event thread that scroll-bar tracking was unreliable but > the system > rarely beachballed; if I changed that to: > > (apropos "" "CCL") > > I couldn't get a word in edgewise: the event thread was so busy > either generating > output or blocking waiting for previously buffered output to be > read that it > was unable to process events. > > Both cases probably involve more output being generated than what > you're seeing, > but the different behavior and the fact that some other people have > difficulty > reproducing what you see suggests that what happens here may have > to do with > processor speed and system load; I can think of some ways to speed > this up, > but it's generally not a good idea to do potentially blocking I/O > operations > in event handlers. Doing > > (loop) > > in an event handler is a very bad idea. > > - when using the same third-party code under the IDE, you crashed > into the > kernel debugger, apparently in some code having to do with > anticipatory > symbol completion ? > > I remember thinking that the code described in: > > > > was trying to do drawing from a secondary thread without taking > appropriate precautions before doing so. (See the examples in > for more > information > about this.) > > If I'm correct in thinking that that was a problem that caused > the anticipatory symbol completion code to sometimes work and > sometimes > crash, I'm not sure that anyone ever followed up on it; if I'm > misremembering ... never mind. > > It's certainly possible that general IDE instability is responsible > for > or contributes to these problems, but it also seems possible that > neither > of these things is anything that we have any direct control over, and > it seems premature to conclude anything about general IDE > [in]stability > based on these examples. > > Does anyone disagree with this ? > > > > > On Tue, 19 May 2009, Ron Garret wrote: > >> >> On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: >> >> >>> I don't see any of this. I'm running trunk though. Maybe you >>> should switch? >> >> Trying that now. For the record, the version I was running came >> from the instructions on http://trac.clozure.com/openmcl: >> >> The preferred way to get Clozure CL is via Subversion. For example, >> to get Clozure CL 1.3 for Darwin/x86, you'd type (where the $ is >> the shell prompt): >> >> $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl >> >> If people should be running the trunk this probably ought to be >> changed or I'm not going to be the only one having these problems. >> >> Also for the record, I can tolerate a certain amount of instability >> at the moment if problems like this are being fixed relatively >> quickly (like hours to days rather than weeks to months). I'm not >> doing anything mission-critical right now, so it's actually a good >> time for me to be a guinea pig. >> >> rg >> From ron at awun.net Tue May 19 17:46:48 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 17:46:48 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> Message-ID: <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> I think "very unstable" is putting it much too harshly. I've encountered what appears at the moment to be two problems, one of which I think is well on the way to being solved, and neither of which seems to be affecting anybody but me. My impression is that the IDE is very nearly ready for prime time, at least for my needs. I'm pretty close to going back to CCL as my primary development platform. rg On May 19, 2009, at 3:07 PM, John McAleely wrote: > I've held off from responding on this thread for a while, but your > description of using the IDE and finding it very unstable is exactly > the experience I had a couple of months ago. > > I would have been using 1.2, so when you reported 1.3 was similar, I > was assuming the work in trunk might make my experience irrelevant. > However, now that it seems that some users of trunk can use it > successfully, while you see instability means I do at least want to > observe that I saw the same sort of problems you see. > > My usage was a Saturday spent prototyping non critical (and very > newbie) code. I resolved not to touch the IDE again until the > current work package was concluded. (My production use of CCL is all > via the command line). > > I assumed all IDE users experienced the same problems, and that my > lack of experience would reduce the value of bug reports, given that > more experienced people would also find these. If that is not the > case, I am inclined to find some time to play a little more in my > setup and see if I can create reproducible bugs, rather than simply > a long winded 'me too' posting on this list. > > J > > > On 19 May 2009, at 22:53, Ron Garret wrote: > >> >> On May 19, 2009, at 2:40 PM, Ron Garret wrote: >> >>> >>> On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: >>> >>> >>>> I don't see any of this. I'm running trunk though. Maybe you >>>> should switch? >>>> >>> >>> Trying that now. For the record, the version I was running came >>> from the instructions on http://trac.clozure.com/openmcl: >>> >>> The preferred way to get Clozure CL is via Subversion. For >>> example, to get Clozure CL 1.3 for Darwin/x86, you'd type (where >>> the $ is the shell prompt): >>> >>> $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl >>> >>> If people should be running the trunk this probably ought to be >>> changed or I'm not going to be the only one having these problems. >>> >>> Also for the record, I can tolerate a certain amount of >>> instability at the moment if problems like this are being fixed >>> relatively quickly (like hours to days rather than weeks to >>> months). I'm not doing anything mission-critical right now, so >>> it's actually a good time for me to be a guinea pig. >>> >> >> Youch! Brain wedgie. Of course, the trunk *is* the bleeding edge. >> >> rg >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Tue May 19 18:41:47 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Tue, 19 May 2009 21:41:47 -0400 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> Message-ID: I have spent quite a bit of time with the CCL 1.3 IDE. While there are some occasional glitches overall the IDE is pretty usable. Closing the AltConsole window has been a problem in most cases. Basically, I never close it. A clear output button would be nice. Alex On May 19, 2009, at 8:46 PM, Ron Garret wrote: > I think "very unstable" is putting it much too harshly. I've > encountered what appears at the moment to be two problems, one of > which I think is well on the way to being solved, and neither of > which seems to be affecting anybody but me. My impression is that > the IDE is very nearly ready for prime time, at least for my needs. > I'm pretty close to going back to CCL as my primary development > platform. > > rg > > On May 19, 2009, at 3:07 PM, John McAleely wrote: > >> I've held off from responding on this thread for a while, but your >> description of using the IDE and finding it very unstable is >> exactly the experience I had a couple of months ago. >> >> I would have been using 1.2, so when you reported 1.3 was similar, >> I was assuming the work in trunk might make my experience >> irrelevant. However, now that it seems that some users of trunk can >> use it successfully, while you see instability means I do at least >> want to observe that I saw the same sort of problems you see. >> >> My usage was a Saturday spent prototyping non critical (and very >> newbie) code. I resolved not to touch the IDE again until the >> current work package was concluded. (My production use of CCL is >> all via the command line). >> >> I assumed all IDE users experienced the same problems, and that my >> lack of experience would reduce the value of bug reports, given >> that more experienced people would also find these. If that is not >> the case, I am inclined to find some time to play a little more in >> my setup and see if I can create reproducible bugs, rather than >> simply a long winded 'me too' posting on this list. >> >> J >> >> >> On 19 May 2009, at 22:53, Ron Garret wrote: >> >>> >>> On May 19, 2009, at 2:40 PM, Ron Garret wrote: >>> >>>> >>>> On May 19, 2009, at 2:16 PM, Raffael Cavallaro wrote: >>>> >>>> >>>>> I don't see any of this. I'm running trunk though. Maybe you >>>>> should switch? >>>>> >>>> >>>> Trying that now. For the record, the version I was running came >>>> from the instructions on http://trac.clozure.com/openmcl: >>>> >>>> The preferred way to get Clozure CL is via Subversion. For >>>> example, to get Clozure CL 1.3 for Darwin/x86, you'd type (where >>>> the $ is the shell prompt): >>>> >>>> $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl >>>> >>>> If people should be running the trunk this probably ought to be >>>> changed or I'm not going to be the only one having these problems. >>>> >>>> Also for the record, I can tolerate a certain amount of >>>> instability at the moment if problems like this are being fixed >>>> relatively quickly (like hours to days rather than weeks to >>>> months). I'm not doing anything mission-critical right now, so >>>> it's actually a good time for me to be a guinea pig. >>>> >>> >>> Youch! Brain wedgie. Of course, the trunk *is* the bleeding edge. >>> >>> rg >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From rme at clozure.com Tue May 19 20:03:08 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 19 May 2009 23:03:08 -0400 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> Message-ID: <8669BA3F-8037-4C9D-B64C-B7C8DEC72550@clozure.com> On May 19, 2009, at 9:41 PM, Alexander Repenning wrote: > I have spent quite a bit of time with the CCL 1.3 IDE. While there > are some occasional glitches overall the IDE is pretty usable. > Closing the AltConsole window has been a problem in most cases. > Basically, I never close it. A clear output button would be nice. I added a clear output button to the altconsole window in r12097 (trunk). I stole the broom icon from Console.app. http://trac.clozure.com/openmcl/changeset/12097 Please svn update and evaluate (require 'cocoa-application) to generate a new Clozure CL.app that will include the updated altconsole.app. From ron at awun.net Tue May 19 23:43:22 2009 From: ron at awun.net (Ron Garret) Date: Tue, 19 May 2009 23:43:22 -0700 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> Message-ID: On May 19, 2009, at 6:41 PM, Alexander Repenning wrote: > I have spent quite a bit of time with the CCL 1.3 IDE. While there > are some occasional glitches overall the IDE is pretty usable. > Closing the AltConsole window has been a problem in most cases. > Basically, I never close it. Ah. That would explain why you don't have this problem :-) rg From joswig at lisp.de Wed May 20 01:45:01 2009 From: joswig at lisp.de (Rainer Joswig) Date: Wed, 20 May 2009 10:45:01 +0200 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> Message-ID: <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> Some thoughts... There was quite a lot research about this at the end of the 80s and beginning of the 90s. There are several books published about parallel programming models in Lisp. To exploit parallelism in popular hardware one can see several competing areas: 1) SIMD multimedia engines (Altivec, SSE, ...). Lisp in general mostly missed this. There were some assembler-based approaches and some Lisps are using SSE for FP computation. Problem: different CPUs offfer different types of engines or none at all. Btw., the first Connection Machines (CM1, CM2) were a giant SIMD co-processor. The host (a Vax, SUN, Symbolics) was running a Lisp, too - controlling the Connection Machine. 2) Multiple cores/processors running concurrent threads. Research, experiments and some products in Lisp. Due to 'Hyper-Threading' more than one thread may run on a core. Currently we have laptops with two native threads (two cores). Desktop computers already are offering 16 native threads (8 cores with two threads each / Hyper- Threading) -> Mac Pro. CPUs may offer more threads in the coming years -> 64, 256. Existing examples are SUN's UltraSPARC T2 with up to 64 threads. The BBN Butterfly ( http://en.wikipedia.org/wiki/BBN_Butterfly_computers ) computer ran a concurrent Scheme and on top of this a Common Lisp was implemented. 3) GPUs. The LARGEST source of compute power for parallel computation in desktop computers and even many laptops: Graphic Processing Units. Apple works on that with OpenCL ( http://en.wikipedia.org/wiki/OpenCL ), a language for programming CPUs, GPUs and DSPs based on C. The idea is that GPUs can be used for general purpose computing (GPGPU) ( http://en.wikipedia.org/wiki/GPGPU ). Some GPUs now offer more than 1000 GFlops (ATI Radeon 4890: 1360 GFLOPS). Then you may put more than one GPU card in your desktop PC. Compare that to current CPUs offering in the range of 5 to 50 GFlops. Glen Foy mentioned 512 cores in ten years from now. The GPU is here today. Can't remember Lisp mentioned in the area of GPGPU. Definitely computing with GPUs is very attractive for scientific processing: processing of images, videos, sound, etc. Problem: this area is a moving target with rapidly changing products. Apple's Mac OS X 10.6 (Snow Leopard) will provide the foundations in the Mac area. I guess for the Desktop and Laptop user it may bring very interesting speed increases in the coming years, especially in computing with multimedia data. Conversions of video formats will run on the GPU. All kinds of video effects will run on the GPU. Music applications will render sounds on the GPU. Encryption, physics computation, rendering, etc. 4) Distributed computing: Clusters, P2P, code mobility, ... Only some research and some experiments in Lisp. Erlang as programming language and runtime is notable in that area. For some computing tasks it might not be enough to offer support for multiple concurrent threads on a CPU, when the GPU approach beats it by a factor of ten or even hundred. Most rendering, multimedia processing, etc. will move to GPUs, I'd guess. Larger experiments are running on clusters - similar to what Dan Weinreb reports from their architectures at ITA. Where does the multi-core-computing fit in? I'd say it is necessary to support it, but for many applications I would see other approaches to have advantages. Many network-applications and in the Lisp area many symbolic applications will benefit from concurrent threads. More about 2) Clozure CL currently offers some support for 2), running threads on multiple cores/processors. There hasn't been much discussion lately of the problems of Common Lisp running on multiple cores. Again, one could identify several levels of support for multi-core computing: a) being able to run (native) threads on different cores. CCL does this. b) the Common Lisp implementation is thread safe. Say, if LOAD, DEFCLASS, COMPILE, are not reentrant, it is assured that only one can run at any one time. There is more to it, though. c) Common Lisp constructs are thread safe and reentrant. Example: You could run multiple DEFCLASS (mostly) in parallel in one Lisp. d) Common Lisp supports special programming facilities: futures, queues, stm, data parallelism, etc. A special challenge is the garbage collector. Today we have few concurrent threads. In the near future one may have 64 concurrent threads running on a desktop computer CPU. That means when all 64 threads are busy, they may produce garbage 64 times as fast as a single thread. So it might be not that clever to run the garbage generator with 64 threads and the garbage collector with only one thread (while halting other Lisp computation). It would also be interesting to identify general issues with Common Lisp with respect to implementing it with multiple concurrent threads - for example to compare implementations and to identify areas where implementations need to do something. A useful 'conservative' approach is to advance the capabilities for programming with concurrent threads. But if a user's application domain offers chances for parallel computation, concurrent threads might not be the best answer. For the average user, the GPU approach could make a big difference in user experience in the next years - my guess. Regards, Rainer Joswig Am 19.05.2009 um 14:05 schrieb Alexander Repenning: > not so fast ;-) > > The "how can we make use of multiple cores" is currently on the the > hottest funding topics supported by NSF, DOE, Microsoft, ..... > > Perhaps it is the Lisp way to look at architectures such as the x86 > and see mostly limitations when indeed there are plenty of > opportunities. This is not about registers but about enabling end > user programmers such as scientists to make use of parallelism. The > big question is how to reconceptualize programming. One of the main > problems is the need to overcome bad algorithmic assumptions > especially the use of unnecessary loops. For instance, in > Bioinformatics textbooks are full of loop based implementations of > algorithms dealing with huge data structures such as gene sequences. > In many cases one could replace sequential loops with parallel > execution. > > Zoom out of the low level view of things. What could multi core Lisp > do? Look at the computational challenges that users are dealing > with. Try to come up with new computational paradigms that could > help. Lisp could be a great platform to explore these issues. > Careful: if you can contribute to this you may actually receive > funding. > > alex > > > > On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: > >> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >> >>> My ignorance of compiler design is breathtaking, but could multi- >>> core >>> compiler techniques be used to compensate for Intel's register- >>> starved >>> architecture? >> >> In a word, no. > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at mcaleely.com Wed May 20 02:04:04 2009 From: john at mcaleely.com (John McAleely) Date: Wed, 20 May 2009 10:04:04 +0100 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> Message-ID: On 20 May 2009, at 01:46, Ron Garret wrote: > I think "very unstable" is putting it much too harshly. I've > encountered what appears at the moment to be two problems, one of That's good. My lack of experience in parsing the technical contents of this list makes it easy for me to make mistakes. Inspired by this, I've pulled down trunk onto my mac, and resolved to use it for a day or so of real development. I'll post some problems I found separately. They do seem much less severe than the ones I encountered a few months ago, so much good work appears to have been done. J From john at mcaleely.com Wed May 20 02:13:27 2009 From: john at mcaleely.com (John McAleely) Date: Wed, 20 May 2009 10:13:27 +0100 Subject: [Openmcl-devel] 'Check for updates' in the IDE dies Message-ID: <3240766D-62F1-4D59-B4EA-CFE952F98B41@mcaleely.com> All, I recently pulled down trunk, rebuilt it and then used (require :cocoa- application) to get the IDE. I then opened the IDE by double clicking in the finder, and executed the 'lisp | check for updates' menu command. The alt console opened, and the output below was displayed. The Clozure CL app had a grey quit menu option in the 'Clozure CL menu', and a normal 'quit' option in the dock icon's menu. Using the 'quit' menu option from the dock didn't work. The app had to be Force Quit, although it was responsive in other windows (eg the already open listener). - Welcome to Clozure Common Lisp Version 1.3-dev-r12094M-trunk (DarwinX8664)! - Mac OS X 10.5.7 J *** Error in event process: Unexpected end of file on #, near position 0, within "" (442AF8) : 0 (FUNCALL #'#<(:INTERNAL CCL::|-[LispApplicationDelegate updateCCL:]|)> #) 149 (#:G36337) #:G36337: # #:COMPILER-VAR: (NIL) #:G36334: # (442B20) : 1 (SIGNAL #) 981 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (ERROR)) CCL::TAG: # CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* CCL::FN: # (442B78) : 2 (%ERROR # (:STREAM #) 558452) 117 (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: (:STREAM #) CCL::ERROR-POINTER: 558452 (442BA0) : 3 (%READ-FORM # 0 NIL) 501 (STREAM CCL::ARG CCL::EOF-VAL) STREAM: # CCL::ARG: 0 CCL::EOF-VAL: NIL CCL::CH: NIL (442BE8) : 4 (READ-INTERNAL # T NIL NIL) 253 (STREAM CCL::EOF-ERROR-P CCL::EOF-VALUE CCL::RECURSIVE-P) STREAM: # CCL::EOF-ERROR-P: T CCL::EOF-VALUE: NIL CCL::RECURSIVE-P: NIL CCL::%READ-OBJECTS%: NIL CCL::%KEEP-WHITESPACE%: NIL (442C68) : 5 (READ # T NIL NIL) 157 (&OPTIONAL STREAM CCL::EOF-ERROR-P CCL::EOF-VALUE CCL::RECURSIVE-P) STREAM: # CCL::EOF-ERROR-P: T CCL::EOF-VALUE: NIL CCL::RECURSIVE-P: NIL (442CB8) : 6 (READ-FROM-STRING "" T NIL :START 0 :END NIL :PRESERVE- WHITESPACE NIL) 413 (STRING &OPTIONAL CCL::EOF-ERROR-P CCL::EOF-VALUE &KEY :START :END :PRESERVE-WHITESPACE) STRING: "" CCL::EOF-ERROR-P: T CCL::EOF-VALUE: NIL CCL::START: 0 CCL::END: NIL CCL::PRESERVE-WHITESPACE: NIL CCL::IDX: NIL STREAM: # (442D60) : 7 (SVN-UPDATE-AVAILABLE-P) 117 NIL CCL::CCL-DIR: #P"/Applications/ccl/" (442D78) : 8 (FUNCALL #'# 17591849974992) 1445 (#:G36333) #:G36333: 17591849974992 #:G36349: # #:G36334: # #:COMPILER-VAR: (NIL) #:G36339: # #:G36350: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) CCL::SELF: # (#x1EF170)> CCL::_CMD: # CCL::SENDER: # (#x1D0EB0)> GUI::NSTITLE: # GUI::NSMESSAGE: # GUI::WINDOW: # (#xC211180)> GUI::PROGRESS-BAR: # (#xC2102E0)> GUI::MESSAGE-FIELD: # (#xC210750)> GUI::MODAL-SESSION: # (442E48) : 9 (%PASCAL-FUNCTIONS% 247 17591849974992) 397 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 247 CCL::ARGS-PTR-FIXNUM: 17591849974992 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (442F08) : 11 (FUNCALL #'# # (#x1BE9F0)> #S(CCL::OBJC- SELECTOR :NAME "run" :%SEL #)) 205 (#:G3078 #:G3079) #:G3078: # (#x1BE9F0)> #:G3079: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) (442F28) : 12 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # (#x1BE9F0)>) 501 (CCL::RECEIVER &REST CCL::ARGS) CCL::RECEIVER: # (#x1BE9F0)> CCL::ARGS: NIL CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) FUNCTION: # (442F68) : 13 (EVENT-LOOP NIL) 413 (&OPTIONAL GUI::END-TEST) GUI::END-TEST: NIL GUI::APP: # (#x1BE9F0)> *BREAK-ON-ERRORS*: NIL #:G7603: (ERROR) CCL::%HANDLERS%: ((ERROR)) GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#) From john at mcaleely.com Wed May 20 02:43:23 2009 From: john at mcaleely.com (John McAleely) Date: Wed, 20 May 2009 10:43:23 +0100 Subject: [Openmcl-devel] Visual Bugs in the IDE Message-ID: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> All, I recently pulled down trunk, rebuilt and used (require :cocoa- application) to build the IDE .app I then opened the app from the finder. I wish to observe several minor bugs, which have the effect for me of detracting from the otherwise 'solid' feel of the IDE in the few hours I used it this morning. Thanks for all the work to get it this far! - The icon in the finder and the dock differ. In the dock it has a shaded cyan background behind the red (CCL) logo. In the finder, only the (CCL) logo appears, with no cyan backdrop. - The AltConsole window appears with an incredibly chunky border, unlike any other displayed by CCL infrastructure. The text is red for reasons I can't intuit. I would have expected this to look similar to a listener window. - Opening the file 'md5.lisp' (sourced from the internet some time ago, attached), and scrolling it with the mouse/vertical scroll bar, resulted in the syntax colouring inverting from time to time (code became blue, strings black). I could not reproduce this with other files, but it was very reliable with md5.lisp across multiple invocations of the IDE. This occurs as the function 'md5sum-stream' is in the visible area, near the center of the window. - Cmd-right arrow appears to do nothing to move the cursor. My muscle memory expects it to move the cursor to the end of the line. - The bottom of a code window looks visually ugly until a horizontal scroll bar is required and un-greys. No other mac app windows on my screen have this 'look', sharing a 'flat' horizontal scroll bar with a 3d status line. - Clicking with the mouse multiple times to influence the selected area appears to sometimes work to extend the selection area from the cursor position to the enclosing s-expr, and sometimes to the enclosing text line. I could not infer a rule to predict this behaviour. In this email editor (mail.app), a double click on the cursor position selects the enclosing word, and a triple click selects the enclosing paragraph. I suppose working to the enclosing s-expr, unless in space between s-expr's in a file, would be what I would expect. - Within the preferences menu option, all of the buttons/widgets on the tab 'encodings' are entirely grey, and consequently appear to offer no functionality. - Welcome to Clozure Common Lisp Version 1.3-dev-r12094M-trunk (DarwinX8664)! - Mac OS X 10.5.7 J -------------- next part -------------- A non-text attachment was scrubbed... Name: md5.lisp Type: application/octet-stream Size: 30525 bytes Desc: not available URL: -------------- next part -------------- From raffaelcavallaro at mac.com Wed May 20 06:13:07 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 20 May 2009 09:13:07 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> Message-ID: On May 20, 2009, at 4:45 AM, Rainer Joswig wrote: > 3) GPUs. The LARGEST source of compute power for parallel > computation in desktop computers and even many laptops: > Graphic Processing Units. tomshardware.com ran this a couple of days ago: It's a summary of real-world results from apps using Nvidia's CUDA. For certain things, like video encoding, they're seeing a 4x speedup using the GPU over using the CPU. In addition, when they use the GPU, it leaves the CPU free for other tasks. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From jaj at clozure.com Wed May 20 06:35:06 2009 From: jaj at clozure.com (Jeremy Jones) Date: Wed, 20 May 2009 09:35:06 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> Message-ID: On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro wrote: > tomshardware.com ran this a couple of days ago: > > > > It's a summary of real-world results from apps using Nvidia's CUDA. > For certain things, like video encoding, they're seeing a 4x speedup > using the GPU over using the CPU. In addition, when they use the GPU, > it leaves the CPU free for other tasks. Why don't we just throw out the main CPU and fill our computers with graphics cards? (Once CCL is ported to GPUs of course) Seriously though, what does a CPU have that a GPU doesn't, besides a different instruction set? More memory? Better i/o? Is the GPU instruction set too specialized? I bet the answer is mainly software, like OSes and device drivers. I remember in the old days it was common to have a separate processor to handle i/o. Maybe that's what the main CPU should be relegated to. OTOH, if the software is good enough, it should just be distributed to whatever computing resources are appropriate and available. Just thinking out loud. From ralex at cs.colorado.edu Wed May 20 08:05:38 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Wed, 20 May 2009 11:05:38 -0400 Subject: [Openmcl-devel] My beach balls runneth over In-Reply-To: <8669BA3F-8037-4C9D-B64C-B7C8DEC72550@clozure.com> References: <67157F67-B9B7-4608-8878-7A4F62AC4FF9@clozure.com> <17B7F2F5-C938-4BFF-9550-171FDA85075B@awun.net> <87EFBEAD-5557-421A-8876-E0992F284506@mac.com> <75DA5D05-963C-4E32-81DA-48DFCEB9F60B@awun.net> <6B4459B3-A156-44DA-B489-50E6C8046672@mcaleely.com> <0AB1AC4F-3151-400A-B583-70E01DC47FF6@awun.net> <8669BA3F-8037-4C9D-B64C-B7C8DEC72550@clozure.com> Message-ID: <0AB97D01-293E-4C1D-BC97-17E7B2DA1276@cs.colorado.edu> excellent! Thanks On May 19, 2009, at 11:03 PM, R. Matthew Emerson wrote: > > On May 19, 2009, at 9:41 PM, Alexander Repenning wrote: > >> I have spent quite a bit of time with the CCL 1.3 IDE. While there >> are some occasional glitches overall the IDE is pretty usable. >> Closing the AltConsole window has been a problem in most cases. >> Basically, I never close it. A clear output button would be nice. > > I added a clear output button to the altconsole window in r12097 > (trunk). I stole the broom icon from Console.app. > > http://trac.clozure.com/openmcl/changeset/12097 > > Please svn update and evaluate (require 'cocoa-application) to > generate a new Clozure CL.app that will include the updated > altconsole.app. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Wed May 20 10:57:37 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Wed, 20 May 2009 13:57:37 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> Message-ID: <4A144491.9010507@itasoftware.com> Rainer Joswig wrote: > > sm, etc. > > A special challenge is the garbage collector. Today we have few > concurrent threads. In the near future one > may have 64 concurrent threads running on a desktop computer CPU. That > means when all 64 threads are > busy, they may produce garbage 64 times as fast as a single thread. So > it might be not that clever > to run the garbage generator with 64 threads and the garbage collector > with only one thread (while halting other > Lisp computation). There's been a lot of interesting work done in that area, too. The JRockit implementation of the Java Virtual Machine has both "concurrent" and "parallel" GC technology, which I believe has been published by the people who did it. (The company is in, I think, Sweden, and was bought by BEA (when I worked there), which in turn was bought by Oracle. You can still get it for free from Oracle, I'm pretty sure.) > > It would also be interesting to identify general issues with Common > Lisp with respect to implementing it with multiple concurrent threads > - for example to compare implementations and to identify areas where > implementations need to do something. I once asked Gary Byers about how CCL deals with the issue that the Java people refer to as the "memory model". He sent me an answer that I didn't quite grasp, and then I dropped the conversation, but I'm still interested. The Java Language Spec had a number of rules intended to make sure everything was well-defined in the face of complicated cache coherency, not to mention compilers that re-order operations, and so on. The original memory model was found to have some bad properties, and William Pugh of U. Delaware (I think) discovered these problems and figured out how to fix them. I don't know what's happened since then. -- Dan > > A useful 'conservative' approach is to advance the capabilities for > programming with concurrent threads. But if a user's application > domain offers chances for parallel computation, concurrent threads > might not be the best answer. For the average user, the GPU approach > could make a big difference in user experience in the next years - my > guess. > > Regards, > > Rainer Joswig > > > Am 19.05.2009 um 14:05 schrieb Alexander Repenning: > >> not so fast ;-) >> >> The "how can we make use of multiple cores" is currently on the >> the hottest funding topics supported by NSF, DOE, Microsoft, ..... >> >> Perhaps it is the Lisp way to look at architectures such as the x86 >> and see mostly limitations when indeed there are plenty of >> opportunities. This is not about registers but about enabling end >> user programmers such as scientists to make use of parallelism. The >> big question is how to reconceptualize programming. One of the main >> problems is the need to overcome bad algorithmic assumptions >> especially the use of unnecessary loops. For instance, in >> Bioinformatics textbooks are full of loop based implementations of >> algorithms dealing with huge data structures such as gene sequences. >> In many cases one could replace sequential loops with parallel execution. >> >> Zoom out of the low level view of things. What could multi core Lisp >> do? Look at the computational challenges that users are dealing with. >> Try to come up with new computational paradigms that could help. Lisp >> could be a great platform to explore these issues. Careful: if you >> can contribute to this you may actually receive funding. >> >> alex >> >> >> >> On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: >> >>> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >>> >>>> My ignorance of compiler design is breathtaking, but could multi-core >>>> compiler techniques be used to compensate for Intel's register-starved >>>> architecture? >>> >>> In a word, no. >> >> Prof. Alexander Repenning >> >> University of Colorado >> Computer Science Department >> Boulder, CO 80309-430 >> >> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > Rainer Joswig, Hamburg, Germany > http://lispm.dyndns.org/ > mailto:joswig at lisp.de > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Wed May 20 11:06:08 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Wed, 20 May 2009 14:06:08 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> Message-ID: <4A144690.7050708@itasoftware.com> The instruction set is very restricted, and the communication paths aren't there, as you suggested. GPGPU is especially good for highly compute-intensive operations over not all that much data. An FFT is an obvious example but there are many, many good examples. (Not that I'm an expert, but I do know that much.) There are CUDA-compatible devices that don't even have a video connection, i.e. for GPGPU only. The NVidia Tesla, called a "computing processor" (weird name). 240 cores per board, and you can chain together four of them. (My officemates are getting this info and telling to me faster than I can type it in. Thanks, Andrew and Scott.) -- Dan Jeremy Jones wrote: > On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro > wrote: > >> tomshardware.com ran this a couple of days ago: >> >> >> >> It's a summary of real-world results from apps using Nvidia's CUDA. >> For certain things, like video encoding, they're seeing a 4x speedup >> using the GPU over using the CPU. In addition, when they use the GPU, >> it leaves the CPU free for other tasks. >> > > > Why don't we just throw out the main CPU and fill our computers with > graphics cards? (Once CCL is ported to GPUs of course) > > Seriously though, what does a CPU have that a GPU doesn't, besides a > different instruction set? More memory? Better i/o? Is the GPU > instruction set too specialized? I bet the answer is mainly software, > like OSes and device drivers. I remember in the old days it was > common to have a separate processor to handle i/o. Maybe that's what > the main CPU should be relegated to. OTOH, if the software is good > enough, it should just be distributed to whatever computing resources > are appropriate and available. Just thinking out loud. > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Wed May 20 11:12:36 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Wed, 20 May 2009 14:12:36 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A144491.9010507@itasoftware.com> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> <4A144491.9010507@itasoftware.com> Message-ID: <4A144814.6010207@itasoftware.com> One source says that CUDA can do anything you can do in C other than function pointers and recursion. Probably this means no stack, locals are allocated at fixed addresses just like globals, each procedure has one global cell as a return address, etc. Dan Weinreb wrote: > > > Rainer Joswig wrote: >> >> sm, etc. >> >> A special challenge is the garbage collector. Today we have few >> concurrent threads. In the near future one >> may have 64 concurrent threads running on a desktop computer CPU. >> That means when all 64 threads are >> busy, they may produce garbage 64 times as fast as a single thread. >> So it might be not that clever >> to run the garbage generator with 64 threads and the garbage >> collector with only one thread (while halting other >> Lisp computation). > There's been a lot of interesting work done in that area, too. The > JRockit > implementation of the Java Virtual Machine has both "concurrent" and > "parallel" GC technology, which I believe has been published by the > people who did it. (The company is in, I think, Sweden, and was > bought by BEA (when I worked there), which in turn was bought > by Oracle. You can still get it for free from Oracle, I'm pretty sure.) >> >> It would also be interesting to identify general issues with Common >> Lisp with respect to implementing it with multiple concurrent threads >> - for example to compare implementations and to identify areas where >> implementations need to do something. > I once asked Gary Byers about how CCL deals with the issue that > the Java people refer to as the "memory model". He sent me an > answer that I didn't quite grasp, and then I dropped the conversation, > but I'm still interested. The Java Language Spec had a number of > rules intended to make sure everything was well-defined in the > face of complicated cache coherency, not to mention compilers > that re-order operations, and so on. The original memory model > was found to have some bad properties, and William Pugh of > U. Delaware (I think) discovered these problems and figured > out how to fix them. I don't know what's happened since > then. > > -- Dan >> >> A useful 'conservative' approach is to advance the capabilities for >> programming with concurrent threads. But if a user's application >> domain offers chances for parallel computation, concurrent threads >> might not be the best answer. For the average user, the GPU approach >> could make a big difference in user experience in the next years - my >> guess. >> >> Regards, >> >> Rainer Joswig >> >> >> Am 19.05.2009 um 14:05 schrieb Alexander Repenning: >> >>> not so fast ;-) >>> >>> The "how can we make use of multiple cores" is currently on the >>> the hottest funding topics supported by NSF, DOE, Microsoft, ..... >>> >>> Perhaps it is the Lisp way to look at architectures such as the x86 >>> and see mostly limitations when indeed there are plenty of >>> opportunities. This is not about registers but about enabling end >>> user programmers such as scientists to make use of parallelism. The >>> big question is how to reconceptualize programming. One of the main >>> problems is the need to overcome bad algorithmic assumptions >>> especially the use of unnecessary loops. For instance, in >>> Bioinformatics textbooks are full of loop based implementations of >>> algorithms dealing with huge data structures such as gene sequences. >>> In many cases one could replace sequential loops with parallel >>> execution. >>> >>> Zoom out of the low level view of things. What could multi core Lisp >>> do? Look at the computational challenges that users are dealing >>> with. Try to come up with new computational paradigms that could >>> help. Lisp could be a great platform to explore these >>> issues. Careful: if you can contribute to this you may actually >>> receive funding. >>> >>> alex >>> >>> >>> >>> On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote: >>> >>>> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote: >>>> >>>>> My ignorance of compiler design is breathtaking, but could multi-core >>>>> compiler techniques be used to compensate for Intel's register-starved >>>>> architecture? >>>> >>>> In a word, no. >>> >>> Prof. Alexander Repenning >>> >>> University of Colorado >>> Computer Science Department >>> Boulder, CO 80309-430 >>> >>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >>> >>> >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> >> Rainer Joswig, Hamburg, Germany >> http://lispm.dyndns.org/ >> mailto:joswig at lisp.de >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> > ------------------------------------------------------------------------ > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rme at clozure.com Wed May 20 11:21:11 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Wed, 20 May 2009 14:21:11 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> Message-ID: <9090946E-A516-4B6D-AF8C-8C562A2FF1C4@clozure.com> On May 20, 2009, at 9:35 AM, Jeremy Jones wrote: > On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro > wrote: >> tomshardware.com ran this a couple of days ago: >> >> >> >> It's a summary of real-world results from apps using Nvidia's CUDA. >> For certain things, like video encoding, they're seeing a 4x speedup >> using the GPU over using the CPU. In addition, when they use the GPU, >> it leaves the CPU free for other tasks. > > > Why don't we just throw out the main CPU and fill our computers with > graphics cards? (Once CCL is ported to GPUs of course) > > Seriously though, what does a CPU have that a GPU doesn't, besides a > different instruction set? More memory? Better i/o? Is the GPU > instruction set too specialized? I bet the answer is mainly software, > like OSes and device drivers. I remember in the old days it was > common to have a separate processor to handle i/o. Maybe that's what > the main CPU should be relegated to. OTOH, if the software is good > enough, it should just be distributed to whatever computing resources > are appropriate and available. Just thinking out loud. Back in the late 1960's, Myer and Sutherland encountered this situation (GPU turning into a CPU): "The flexibility and power needed in the channel for a computer display are considered. To work efficiently, such a channel must have a sufficient number of instruction that it is best understood as a small processor rather than a powerful channel. As it was found that successive improvements to the display processor design lie on a circular path, by making improvements one can return to the original simple design plus one new general purpose computer for each trip around. The degree of physical separation between display and parent computer is a key factor in display processor design." http://portal.acm.org/citation.cfm?id=363347.363368 http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf From raffaelcavallaro at mac.com Wed May 20 12:04:32 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 20 May 2009 15:04:32 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A144814.6010207@itasoftware.com> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> <4A144491.9010507@itasoftware.com> <4A144814.6010207@itasoftware.com> Message-ID: <32999334-D48F-4773-87B4-D071DF11ADFF@mac.com> On May 20, 2009, at 2:12 PM, Dan Weinreb wrote: > One source says that CUDA can do anything you can do in C > other than function pointers and recursion. Probably this > means no stack, locals are allocated at fixed addresses > just like globals, each procedure has one global cell > as a return address, etc. Here's an overview of OpenCL (Nvidia has OpenCL drivers, Apple are including OpenCL in Snow Leopard, and Intel, AMD, IBM, ARM, Sony, etc. are all signed on as well). Here's a quick refererence to the api: Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From ron at awun.net Wed May 20 12:44:21 2009 From: ron at awun.net (Ron Garret) Date: Wed, 20 May 2009 12:44:21 -0700 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> Message-ID: <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> On May 20, 2009, at 2:43 AM, John McAleely wrote: > > - Opening the file 'md5.lisp' (sourced from the internet some time > ago, attached), and scrolling it with the mouse/vertical scroll bar, > resulted in the syntax colouring inverting from time to time (code > became blue, strings black). I could not reproduce this with other > files, but it was very reliable with md5.lisp across multiple > invocations of the IDE. This occurs as the function 'md5sum-stream' > is in the visible area, near the center of the window. > I've produced what I believe to be a minimal reproduction of this bug (file enclosed). You can *add* just about anything to this minimal file and still produce the bug, but removing any of the characters in the file seems to make the problem go away. Note that the file contains a long run of blank lines. Those are necessary. The bug depends on the size of the window in which the file is being displayed. The more blank lines (actually they don't have to be blank, but the carriage returns have to be there) the larger the window can be and still manifest the problem. In the course of investigating this I discovered the following charming behavior: if you type a string into the listener that consists of a carriage return, an open-paren, and then a long run of carriage returns (60 or so), the listener will become unresponsive (i.e. subsequent forms will fail to be evaluated). It's been a fun morning. rg -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.lisp Type: application/octet-stream Size: 153 bytes Desc: not available URL: -------------- next part -------------- From raffaelcavallaro at mac.com Wed May 20 13:10:19 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 20 May 2009 16:10:19 -0400 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> Message-ID: On May 20, 2009, at 3:44 PM, Ron Garret wrote: > I've produced what I believe to be a minimal reproduction of this > bug (file enclosed). You can *add* just about anything to this > minimal file and still produce the bug, but removing any of the > characters in the file seems to make the problem go away. I don't see this bug in 1.3-dev-r12100M-trunk DarwinX8632 or DarwinX8664. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From ron at awun.net Wed May 20 13:25:30 2009 From: ron at awun.net (Ron Garret) Date: Wed, 20 May 2009 13:25:30 -0700 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> Message-ID: <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> On May 20, 2009, at 1:10 PM, Raffael Cavallaro wrote: > > On May 20, 2009, at 3:44 PM, Ron Garret wrote: > >> I've produced what I believe to be a minimal reproduction of this >> bug (file enclosed). You can *add* just about anything to this >> minimal file and still produce the bug, but removing any of the >> characters in the file seems to make the problem go away. > > > I don't see this bug in 1.3-dev-r12100M-trunk DarwinX8632 or > DarwinX8664. I'll be darned, it does seem to have been fixed. Now *that* is good customer service! rg From lw at mt.net Wed May 20 13:25:30 2009 From: lw at mt.net (Laughing Water) Date: Wed, 20 May 2009 14:25:30 -0600 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> Message-ID: Sorry, but I just can't resist - In picturing what might lead you to type a long run of carriage returns, I have this image of you sleeping and drooling on the keyboard. Sorry again! Laughing Water On May 20, 2009, at 1:44 PM, Ron Garret wrote: > > On May 20, 2009, at 2:43 AM, John McAleely wrote: > >> >> - Opening the file 'md5.lisp' (sourced from the internet some time >> ago, attached), and scrolling it with the mouse/vertical scroll >> bar, resulted in the syntax colouring inverting from time to time >> (code became blue, strings black). I could not reproduce this with >> other files, but it was very reliable with md5.lisp across multiple >> invocations of the IDE. This occurs as the function 'md5sum-stream' >> is in the visible area, near the center of the window. >> > > I've produced what I believe to be a minimal reproduction of this > bug (file enclosed). You can *add* just about anything to this > minimal file and still produce the bug, but removing any of the > characters in the file seems to make the problem go away. > > Note that the file contains a long run of blank lines. Those are > necessary. The bug depends on the size of the window in which the > file is being displayed. The more blank lines (actually they don't > have to be blank, but the carriage returns have to be there) the > larger the window can be and still manifest the problem. > > In the course of investigating this I discovered the following > charming behavior: if you type a string into the listener that > consists of a carriage return, an open-paren, and then a long run of > carriage returns (60 or so), the listener will become unresponsive > (i.e. subsequent forms will fail to be evaluated). > > It's been a fun morning. > > rg > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Wed May 20 13:28:29 2009 From: ron at awun.net (Ron Garret) Date: Wed, 20 May 2009 13:28:29 -0700 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> Message-ID: For those who are wondering, what led me to discover this odd behavior (which seems to have been fixed already) was trying to count how many carriage returns were needed to reproduce the syntax-coloring bug (which also seems to have been fixed) by copying the string into the listener and calling (length *). rg On May 20, 2009, at 1:25 PM, Laughing Water wrote: > Sorry, but I just can't resist - > > In picturing what might lead you to type a long run of carriage > returns, I have this image of you sleeping and drooling on the > keyboard. > > Sorry again! > > Laughing Water > > > On May 20, 2009, at 1:44 PM, Ron Garret wrote: > >> >> On May 20, 2009, at 2:43 AM, John McAleely wrote: >> >>> >>> - Opening the file 'md5.lisp' (sourced from the internet some time >>> ago, attached), and scrolling it with the mouse/vertical scroll >>> bar, resulted in the syntax colouring inverting from time to time >>> (code became blue, strings black). I could not reproduce this with >>> other files, but it was very reliable with md5.lisp across >>> multiple invocations of the IDE. This occurs as the function >>> 'md5sum-stream' is in the visible area, near the center of the >>> window. >>> >> >> I've produced what I believe to be a minimal reproduction of this >> bug (file enclosed). You can *add* just about anything to this >> minimal file and still produce the bug, but removing any of the >> characters in the file seems to make the problem go away. >> >> Note that the file contains a long run of blank lines. Those are >> necessary. The bug depends on the size of the window in which the >> file is being displayed. The more blank lines (actually they don't >> have to be blank, but the carriage returns have to be there) the >> larger the window can be and still manifest the problem. >> >> In the course of investigating this I discovered the following >> charming behavior: if you type a string into the listener that >> consists of a carriage return, an open-paren, and then a long run >> of carriage returns (60 or so), the listener will become >> unresponsive (i.e. subsequent forms will fail to be evaluated). >> >> It's been a fun morning. >> >> rg >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Wed May 20 13:29:56 2009 From: ron at awun.net (Ron Garret) Date: Wed, 20 May 2009 13:29:56 -0700 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> Message-ID: <369C3341-3B72-4B6A-AD4B-6721C3339127@awun.net> On May 20, 2009, at 1:25 PM, Ron Garret wrote: > > On May 20, 2009, at 1:10 PM, Raffael Cavallaro wrote: > >> >> On May 20, 2009, at 3:44 PM, Ron Garret wrote: >> >>> I've produced what I believe to be a minimal reproduction of this >>> bug (file enclosed). You can *add* just about anything to this >>> minimal file and still produce the bug, but removing any of the >>> characters in the file seems to make the problem go away. >> >> >> I don't see this bug in 1.3-dev-r12100M-trunk DarwinX8632 or >> DarwinX8664. > > I'll be darned, it does seem to have been fixed. Now *that* is good > customer service! Check-for-updates seems to be working now too! rg From ww.s2 at ukonline.co.uk Wed May 20 14:32:14 2009 From: ww.s2 at ukonline.co.uk (wws2) Date: Wed, 20 May 2009 15:32:14 -0600 Subject: [Openmcl-devel] Evaluating empty Buffer region Hangs IDE Message-ID: <99115C61-654B-43E1-8B53-09D52974FD27@ukonline.co.uk> Just starting to explore CCL (the 1.3dmg version). One of my first impressions was discovering that evaluating empty selections cause the listener to disappear. I first discovered this evaluating regions with compiler flags that result in an empty expression, for example (select between the quote marks not including them) " #+:ccl-5.2 4 " causes the listener to disappear. But if it has " #+:ccl-5.2 4 7 " the listener shows 7. But in fact select any empty buffer area " " and evaluate the selection and this also occurs. ;;;;;;;;;;;;;;;;;;;; Separately, I cannot decipher the messages on this list (or the documentation) related to whether CCL runs COCOA in 64 bit mode on a PPC (iMac G5) under osx4.11. I get the impression that the answer is no, certainly when I try to load cocoa I get a message saying the library is the wrong version. Is there some combination of libraries and/osx version that would allow me to explore the 64 bit version? I would like to port some MCL code to CCL in part to take advantage of the larger datasets that would allow me to run. ;;;;;;;;;;;;;;;;;;;; Finally, it would be nice to have some guidance on things like the initial mode line. This may exist somewhere on the web pages, but the bits I have found do not seem to explain things like that, and I have run across two issues. To start, (a) in MCL one can have the package name in a list on the mode line (ie ";-*- mode: lisp; Package: (:DATA) -*-") and that means create the package if it does not exit. That exact and useful convention does not work in CCL, but is there some alternate convention? (b) I have noticed is that if I click in a buffer that does have a (defpackage ) at the top, I cannot then load the buffer because it complains the package is not defined, but if I just open and load it (from the menu) everything goes fine. I surmise that by clicking in the buffer a "buffer mark" to use FRED terminology, is established below the (defpackage ) position, and so in some sense the subsequent loading of the buffer does not start at the top, but somehow starts at the click point and complains that the package is not defined. Surely loading the buffer should use or move a buffer mark at the top and start from there. Thanks for your help and guidance, From gb at clozure.com Wed May 20 15:10:19 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 20 May 2009 16:10:19 -0600 (MDT) Subject: [Openmcl-devel] Evaluating empty Buffer region Hangs IDE In-Reply-To: <99115C61-654B-43E1-8B53-09D52974FD27@ukonline.co.uk> References: <99115C61-654B-43E1-8B53-09D52974FD27@ukonline.co.uk> Message-ID: <20090520154552.X34117@abq.clozure.com> On Wed, 20 May 2009, wws2 wrote: > > Separately, I cannot decipher the messages on this list (or the > documentation) related to whether CCL runs COCOA in 64 bit mode on a > PPC (iMac G5) under osx4.11. I get the impression that the answer is > no, certainly when I try to load cocoa I get a message saying the > library is the wrong version. Is there some combination of libraries > and/osx version that would allow me to explore the 64 bit version? I > would like to port some MCL code to CCL in part to take advantage of > the larger datasets that would allow me to run. Apple didn't provide 64-bit versions of any GUI libraries until 10.5. Bugs in late developer releases of 10.5 (from WWDC 2007 until a few months before the final 10.5) completely broke CCL on PPC64, and (even though it's a year and half later) that's my excuse for not getting the ObjC bridge working on PPC64. A few months ago I got a lot of it working, but the parts that're known not to work are fairly important; they have to do with ensuring that the lisp runtime can handle ObjC exceptions and that the ObjC runtime sees lisp errors as exceptions; even if "handle" in both cases means nothing more than "unwind the stack back to the next point of transition between Lisp and ObjC code." It'd probably take a few days of quality time with GDB to get that working, and there's always been something of higher priority. > > > ;;;;;;;;;;;;;;;;;;;; > > Finally, it would be nice to have some guidance on things like the > initial mode line. This may exist somewhere on the web pages, but > the bits I have found do not seem to explain things like that, and I > have run across two issues. > > To start, (a) in MCL one can have the package name in a list on the > mode line (ie ";-*- mode: lisp; Package: (:DATA) -*-") and that means > create the package if it does not exit. That exact and useful > convention does not work in CCL, but is there some alternate convention? > > (b) I have noticed is that if I click in a buffer that does have a > (defpackage ) at the top, I cannot then load the buffer because it > complains the package is not defined, but if I just open and load it > (from the menu) everything goes fine. I surmise that by clicking in > the buffer a "buffer mark" to use FRED terminology, is established > below the (defpackage ) position, and so in some sense the subsequent > loading of the buffer does not start at the top, but somehow starts > at the click point and complains that the package is not defined. > Surely loading the buffer should use or move a buffer mark at the top > and start from there. > No, but you're right that the LispM-style package specifications on the attributes line were handy and it'd be good to support them. > > Thanks for your help and guidance, > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From jgrant at imagine27.com Wed May 20 15:42:45 2009 From: jgrant at imagine27.com (Justin Grant) Date: Wed, 20 May 2009 15:42:45 -0700 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> Message-ID: <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> > Someone could define a version of Common Lisp with these characteristics... >> >> ... hopefully that never happens ! Patronizing assumptions on the part of language implementors have mostly been avoided in CL up until now. There's a reason hackers choose CL to design/implement their systems : they are willing to take responsibility for their own code. For the opposite case think Java. Java's StringBuffer class came about due to flawed assumptions that had to be handled after the fact. The world that is modeled in software is not as cut and dried as we would all like it to be : resources are not infinite. That being said, I really do like some of the features that I've seen in Clojure (speaking from actual experience using Clojure and CL). Forcing immutable data structures on users to simplify the language implementation issues or to make concurrent programming 'easier' is neither of them. The one thing I would change in Clojure is this very thing. Even Haskell has it's monads and Lisp allows for functional and imperative styles to be mixed. There may be an important lesson here ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at mcaleely.com Wed May 20 15:54:19 2009 From: john at mcaleely.com (John McAleely) Date: Wed, 20 May 2009 23:54:19 +0100 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> Message-ID: >> I don't see this bug in 1.3-dev-r12100M-trunk DarwinX8632 or >> DarwinX8664. > > I'll be darned, it does seem to have been fixed. Now *that* is good > customer service! > > rg Yup! Thank you! I also like the new look of the alt-console window :-) Is there a reason why the text in it is red, and not black like every other window? J From john at mcaleely.com Wed May 20 15:55:54 2009 From: john at mcaleely.com (John McAleely) Date: Wed, 20 May 2009 23:55:54 +0100 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> Message-ID: > - Cmd-right arrow appears to do nothing to move the cursor. My > muscle memory expects it to move the cursor to the end of the line. - Mac OS X 10.5.7 - Welcome to Clozure Common Lisp Version 1.3-dev-r12100M-trunk (DarwinX8664)! A new one. Open a source window and triple click to select a line (has the attempt to select an s-expr been removed?). cmd-right arrow will output this in alt-console: *** Error in event process: Too few arguments in call to #: 2 arguments provided, at least 3 required. (442950) : 0 (FUNCALL #'#<(:INTERNAL GUI::|- [HemlockTextstorageTextView keyDown:]|)> #) 149 (#:G25318) #:G25318: # #:COMPILER-VAR: (NIL) #:G25315: # (442978) : 1 (SIGNAL #) 981 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) CCL::TAG: # CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* CCL::FN: # (4429D0) : 2 (%ERROR # (:NARGS 2 :FN #) 558440) 117 (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: (:NARGS 2 :FN #) CCL::ERROR-POINTER: 558440 (4429F8) : 3 (FUNCALL #'#<(:INTERNAL CCL::%XERR-DISP)>) 1885 NIL CCL::FRAME-PTR: 558440 CCL::FN: # CCL::OP0: 205 CCL::OP1: 194 CCL::OP2: 0 CCL::SKIP: -1 CCL::FLAGS: 66195 CCL::NARGS: 2 CCL::CARRY-BIT: T CCL::XP: # CCL::XCF: # (442A60) : 4 (FUNCALL-WITH-ERROR-REENTRY-DETECTION #) 181 (CCL::THUNK) CCL::THUNK: # COUNT: 0 CCL::*ERROR-REENTRY-COUNT*: 0 (442AA0) : 5 (FUNCALL #'# 17591849975064) 493 (#:G131181) #:G131181: 17591849975064 #:G131191: # CCL::XP: # CCL::XCF: # #:G131192: # (442AD8) : 6 (%PASCAL-FUNCTIONS% 2 17591849975064) 397 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 2 CCL::ARGS-PTR-FIXNUM: 17591849975064 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL *(442B40) : 8 (FUNCALL #'# # #) 7 (#:G4831 #:G4832 CCL::ARG0) (442B98) : 9 (%CALL-NEXT-OBJC-METHOD # Frame = {{0.00, 0.00}, {570.00, 336.00}}, Bounds = {{0.00, 0.00}, {570.00, 336.00}} Horizontally resizable: YES, Vertically resizable: YES MinSize = {570.00, 336.00}, MaxSize = {10000000.00, 10000000.00} (#xA98ADF0)> # # (:VOID :ID)) 837 (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) CCL::SELF: # Frame = {{0.00, 0.00}, {570.00, 336.00}}, Bounds = {{0.00, 0.00}, {570.00, 336.00}} Horizontally resizable: YES, Vertically resizable: YES MinSize = {570.00, 336.00}, MaxSize = {10000000.00, 10000000.00} (#xA98ADF0)> CLASS: # CCL::SELECTOR: # CCL::SIG: (:VOID :ID) CCL::ARGS: NIL CCL::S: # CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE (:VOID :ID) :FUNCTION # ...) FUNCTION: # (442BF8) : 10 (FUNCALL #'# 17591849975428) 2173 (#:G25314) #:G25314: 17591849975428 #:G25330: # #:G25315: # #:COMPILER-VAR: (NIL) #:G25320: # #:G25331: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) GUI::SELF: # Frame = {{0.00, 0.00}, {570.00, 336.00}}, Bounds = {{0.00, 0.00}, {570.00, 336.00}} Horizontally resizable: YES, Vertically resizable: YES MinSize = {570.00, 336.00}, MaxSize = {10000000.00, 10000000.00} (#xA98ADF0)> GUI::_CMD: # GUI::EVENT: # GUI::VIEW: # GUI::QUOTE-P: NIL GUI::FLAGS: 11534600 GUI::HEMLOCK-KEY: NIL (442C88) : 11 (%PASCAL-FUNCTIONS% 72 17591849975428) 397 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 72 CCL::ARGS-PTR-FIXNUM: 17591849975428 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (442D48) : 13 (FUNCALL #'# # # #) 397 (#:G4831 #:G4832 CCL::ARG0) #:G4831: # #:G4832: # CCL::ARG0: # (442D70) : 14 (%CALL-NEXT-OBJC-METHOD # (#x1BF200)> # # (:VOID :ID) #) 837 (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) CCL::SELF: # (#x1BF200)> CLASS: # CCL::SELECTOR: # CCL::SIG: (:VOID :ID) CCL::ARGS: (#) CCL::S: # CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE (:VOID :ID) :FUNCTION # ...) FUNCTION: # (442DD0) : 15 (FUNCALL #'# 17591849975608) 1141 (#:G5538) #:G5538: 17591849975608 #:G5554: # #:G5539: # #:COMPILER-VAR: (NIL) #:G5544: # #:G5555: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) GUI::SELF: # (#x1BF200)> GUI::_CMD: # GUI::E: # CCL::ARGS: (#) (442E48) : 16 (%PASCAL-FUNCTIONS% 14 17591849975608) 397 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 14 CCL::ARGS-PTR-FIXNUM: 17591849975608 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (442F08) : 18 (FUNCALL #'# # (#x1BF200)> #S(CCL::OBJC- SELECTOR :NAME "run" :%SEL #)) 205 (#:G3078 #:G3079) #:G3078: # (#x1BF200)> #:G3079: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) (442F28) : 19 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # (#x1BF200)>) 501 (CCL::RECEIVER &REST CCL::ARGS) CCL::RECEIVER: # (#x1BF200)> CCL::ARGS: NIL CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) FUNCTION: # From gb at clozure.com Wed May 20 16:08:07 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 20 May 2009 17:08:07 -0600 (MDT) Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> Message-ID: <20090520165700.C36697@abq.clozure.com> On Wed, 20 May 2009, John McAleely wrote: >>> I don't see this bug in 1.3-dev-r12100M-trunk DarwinX8632 or >>> DarwinX8664. >> >> I'll be darned, it does seem to have been fixed. Now *that* is good >> customer service! >> >> rg > > Yup! Thank you! I also like the new look of the alt-console window :-) > > Is there a reason why the text in it is red, and not black like every > other window? Because it's not like every other window ? AltConsole is a (small) separate application; it's supposed to provide a primitive terminal-like interface to GUI applications that don't ordinarily have such an interface. If its window appears, there's a good chance that that's because of something anomalous and that something probably requires user or developer attention. There might be better ways of attracting that attention than to use red text on a white background, but trying to "blend in" isn't really the point here ... > > J > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From mevins at mac.com Wed May 20 16:12:47 2009 From: mevins at mac.com (mikel evins) Date: Wed, 20 May 2009 18:12:47 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> Message-ID: <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> On May 20, 2009, at 5:42 PM, Justin Grant wrote: > > Someone could define a version of Common Lisp with these > characteristics... > > > ... hopefully that never happens ! > > Patronizing assumptions on the part of language implementors have > mostly been avoided in CL up until now. > There's a reason hackers choose CL to design/implement their > systems : they are willing to take responsibility for their own > code. For the opposite case think Java. Java's StringBuffer class > came about due to flawed assumptions that had to be handled after > the fact. The world that is modeled in software is not as cut and > dried as we would all like it to be : resources are not infinite. > > That being said, I really do like some of the features that I've > seen in Clojure (speaking from actual experience using Clojure and > CL). Forcing immutable data structures on users to simplify the > language implementation issues or to make concurrent programming > 'easier' is neither of them. The one thing I would change in Clojure > is this very thing. Even Haskell has it's monads and Lisp allows for > functional and imperative styles to be mixed. > > There may be an important lesson here ... Haskell is more restrictive than Clojure, not less. The language defined by Haskell 98 has no way whatsoever to perform assignment. Monads provide a way to *simulate* assignment, but what they actually do is not assignment (much less simple assignment). Clojure takes the same approach to managing threads that Common Lisp does to managing memory allocation. If Clojure's design in this area represents "patronizing assumptions", then so does Common Lisp's memory-management design. Common Lisp does not give you malloc and free because in a Lisp with those functions, there are a zillion ways to lose and very few ways to win. Clojure doesn't give you locks and simple assignment for the same reason. Common Lisp is designed to make winning easy in the area of memory management. Clojure takes that design as a given, and in addition is designed to make winning easy in the area of concurrent programming. If you really want malloc and free, don't use Common Lisp. If you really want locks and simple assignment, don't use Clojure. From gb at clozure.com Wed May 20 16:13:04 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 20 May 2009 17:13:04 -0600 (MDT) Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> Message-ID: <20090520170954.S36697@abq.clozure.com> What we clearly need is an svn client in the IDE; I'd fixed this in the IDE but hadn't saved the buffer, then checked in the unsaved buffer from Emacs. Fixed now. On Wed, 20 May 2009, John McAleely wrote: >> - Cmd-right arrow appears to do nothing to move the cursor. My >> muscle memory expects it to move the cursor to the end of the line. > > - Mac OS X 10.5.7 > - Welcome to Clozure Common Lisp Version 1.3-dev-r12100M-trunk > (DarwinX8664)! > > A new one. Open a source window and triple click to select a line (has > the attempt to select an s-expr been removed?). cmd-right arrow will > output this in alt-console: > > > > *** Error in event process: Too few arguments in call to # Function #x3000412CA29F>: > 2 arguments provided, at least 3 required. > > (442950) : 0 (FUNCALL #'#<(:INTERNAL GUI::|- > [HemlockTextstorageTextView keyDown:]|)> # #x300041D3238D>) 149 > (#:G25318) > #:G25318: # > > #:COMPILER-VAR: (NIL) > #:G25315: # > > (442978) : 1 (SIGNAL #) 981 > (CONDITION &REST CCL::ARGS) > CONDITION: # > CCL::ARGS: NIL > > CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) > CCL::TAG: # > CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > CCL::FN: # [HemlockTextstorageTextView keyDown:]|) #x493C2F> > > (4429D0) : 2 (%ERROR # > (:NARGS 2 :FN #) 558440) 117 > (CONDITION CCL::ARGS CCL::ERROR-POINTER) > CONDITION: # > CCL::ARGS: (:NARGS 2 :FN #) > CCL::ERROR-POINTER: 558440 > > > > (4429F8) : 3 (FUNCALL #'#<(:INTERNAL CCL::%XERR-DISP)>) 1885 > NIL > > CCL::FRAME-PTR: 558440 > CCL::FN: # > CCL::OP0: 205 > CCL::OP1: 194 > CCL::OP2: 0 > CCL::SKIP: -1 > CCL::FLAGS: 66195 > CCL::NARGS: 2 > CCL::CARRY-BIT: T > CCL::XP: # > CCL::XCF: # > > (442A60) : 4 (FUNCALL-WITH-ERROR-REENTRY-DETECTION # LEXICAL-CLOSURE (:INTERNAL CCL::%XERR-DISP) #x493B6F>) 181 > (CCL::THUNK) > CCL::THUNK: # #x493B6F> > > COUNT: 0 > CCL::*ERROR-REENTRY-COUNT*: 0 > > (442AA0) : 5 (FUNCALL #'# 17591849975064) 493 > (#:G131181) > #:G131181: 17591849975064 > > #:G131191: # > CCL::XP: # > CCL::XCF: # > #:G131192: # #x493B6F> > > (442AD8) : 6 (%PASCAL-FUNCTIONS% 2 17591849975064) 397 > (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > CCL::INDEX: 2 > CCL::ARGS-PTR-FIXNUM: 17591849975064 > > CCL::LISP-FUNCTION: # Global) #x3000405E7DAF> > WITHOUT-INTERRUPTS: NIL > CCL::*CALLBACK-TRACE-P*: NIL > > *(442B40) : 8 (FUNCALL #'# # Foreign Pointer [stack-allocated] (:* (:STRUCT :OBJC_SUPER)) > #x7FFF5FBFF330> #) 7 > (#:G4831 #:G4832 CCL::ARG0) > > > > (442B98) : 9 (%CALL-NEXT-OBJC-METHOD # > Frame = {{0.00, 0.00}, {570.00, 336.00}}, Bounds = {{0.00, 0.00}, > {570.00, 336.00}} > Horizontally resizable: YES, Vertically resizable: YES > MinSize = {570.00, 336.00}, MaxSize = {10000000.00, 10000000.00} > (#xA98ADF0)> # (#x136A50)> # (:VOID :ID)) 837 > (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) > CCL::SELF: # > Frame = {{0.00, 0.00}, {570.00, 336.00}}, Bounds = {{0.00, 0.00}, > {570.00, 336.00}} > Horizontally resizable: YES, Vertically resizable: YES > MinSize = {570.00, 336.00}, MaxSize = {10000000.00, 10000000.00} > (#xA98ADF0)> > CLASS: # (#x136A50)> > CCL::SELECTOR: # > CCL::SIG: (:VOID :ID) > CCL::ARGS: NIL > > CCL::S: # > CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE > (:VOID :ID) :FUNCTION # ...) > FUNCTION: # > > (442BF8) : 10 (FUNCALL #'# keyDown:]|> 17591849975428) 2173 > (#:G25314) > #:G25314: 17591849975428 > > #:G25330: # > #:G25315: # > #:COMPILER-VAR: (NIL) > #:G25320: # [HemlockTextstorageTextView keyDown:]|) #x493C2F> > #:G25331: (CONDITION #) > CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) > GUI::SELF: # > Frame = {{0.00, 0.00}, {570.00, 336.00}}, Bounds = {{0.00, 0.00}, > {570.00, 336.00}} > Horizontally resizable: YES, Vertically resizable: YES > MinSize = {570.00, 336.00}, MaxSize = {10000000.00, 10000000.00} > (#xA98ADF0)> > GUI::_CMD: # > GUI::EVENT: # time=206156.2 flags=0xb00108 win=0x0 winNum=54432 ctxt=0x0 chars="" > unmodchars="" repeat=0 keyCode=124 (#xA997E50)> > GUI::VIEW: # > GUI::QUOTE-P: NIL > GUI::FLAGS: 11534600 > GUI::HEMLOCK-KEY: NIL > > (442C88) : 11 (%PASCAL-FUNCTIONS% 72 17591849975428) 397 > (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > CCL::INDEX: 72 > CCL::ARGS-PTR-FIXNUM: 17591849975428 > > CCL::LISP-FUNCTION: # [HemlockTextstorageTextView keyDown:]| (Non-Global) #x300041678D9F> > WITHOUT-INTERRUPTS: NIL > CCL::*CALLBACK-TRACE-P*: NIL > > (442D48) : 13 (FUNCALL #'# # Foreign Pointer [stack-allocated] (:* #) #x7FFF5FBFF8D0> # Pointer #x7FFF81CCDD48> # time=206156.2 flags=0xb00108 win=0x0 winNum=54432 ctxt=0x0 chars="" > unmodchars="" repeat=0 keyCode=124 (#xA997E50)>) 397 > (#:G4831 #:G4832 CCL::ARG0) > #:G4831: # #x7FFF5FBFF8D0> > #:G4832: # > CCL::ARG0: # time=206156.2 flags=0xb00108 win=0x0 winNum=54432 ctxt=0x0 chars="" > unmodchars="" repeat=0 keyCode=124 (#xA997E50)> > > > > (442D70) : 14 (%CALL-NEXT-OBJC-METHOD # (#x1BF200)> # APPLICATION (#x1349D0)> # > (:VOID :ID) # flags=0xb00108 win=0x0 winNum=54432 ctxt=0x0 chars="" unmodchars="" > repeat=0 keyCode=124 (#xA997E50)>) 837 > (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) > CCL::SELF: # > (#x1BF200)> > CLASS: # > CCL::SELECTOR: # > CCL::SIG: (:VOID :ID) > CCL::ARGS: (# time=206156.2 flags=0xb00108 win=0x0 winNum=54432 ctxt=0x0 chars="" > unmodchars="" repeat=0 keyCode=124 (#xA997E50)>) > > CCL::S: # > CCL::SIGINFO: #S(CCL::OBJC-METHOD-SIGNATURE-INFO :TYPE-SIGNATURE > (:VOID :ID) :FUNCTION # ...) > FUNCTION: # > > (442DD0) : 15 (FUNCALL #'# > 17591849975608) 1141 > (#:G5538) > #:G5538: 17591849975608 > > #:G5554: # > #:G5539: # > #:COMPILER-VAR: (NIL) > #:G5544: # [LispApplication sendEvent:]|) #x493DBF> > #:G5555: (CONDITION #) > CCL::%HANDLERS%: ((CONDITION #) (ERROR)) > GUI::SELF: # (#x1BF200)> > GUI::_CMD: # > GUI::E: # flags=0xb00108 win=0x0 winNum=54432 ctxt=0x0 chars="" unmodchars="" > repeat=0 keyCode=124 (#xA997E50)> > CCL::ARGS: (# time=206156.2 flags=0xb00108 win=0x0 winNum=54432 ctxt=0x0 chars="" > unmodchars="" repeat=0 keyCode=124 (#xA997E50)>) > > (442E48) : 16 (%PASCAL-FUNCTIONS% 14 17591849975608) 397 > (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > CCL::INDEX: 14 > CCL::ARGS-PTR-FIXNUM: 17591849975608 > > CCL::LISP-FUNCTION: # sendEvent:]| (Non-Global) #x3000412F8E0F> > WITHOUT-INTERRUPTS: NIL > CCL::*CALLBACK-TRACE-P*: NIL > > (442F08) : 18 (FUNCALL #'# # APPLICATION (#x1BF200)> #S(CCL::OBJC- > SELECTOR :NAME "run" :%SEL #)) 205 > (#:G3078 #:G3079) > #:G3078: # (#x1BF200)> > #:G3079: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF81D84D68>) > > > > (442F28) : 19 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE > (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # APPLICATION (#x1BF200)>) 501 > (CCL::RECEIVER &REST CCL::ARGS) > CCL::RECEIVER: # > (#x1BF200)> > CCL::ARGS: NIL > > CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF81D84D68>) > FUNCTION: # > > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From john at mcaleely.com Wed May 20 16:43:59 2009 From: john at mcaleely.com (John McAleely) Date: Thu, 21 May 2009 00:43:59 +0100 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <20090520165700.C36697@abq.clozure.com> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <20090520165700.C36697@abq.clozure.com> Message-ID: <64213ADE-D19B-4BC4-89FA-BCE636977F39@mcaleely.com> >> Is there a reason why the text in it is red, and not black like every >> other window? > > Because it's not like every other window ? > > AltConsole is a (small) separate application; it's supposed to provide > a primitive terminal-like interface to GUI applications that don't > ordinarily have such an interface. If its window appears, there's > a good chance that that's because of something anomalous and that > something probably requires user or developer attention. I understand the special status of this application window, and I empathise with the attempt to draw attention to it. However, the text is marginally harder to read, and I fail to believe colouring it red provides any meaningful extra information to a developer or user. I feel it also manages to look surprisingly like some sort of bug itself. J From ron at awun.net Wed May 20 17:25:00 2009 From: ron at awun.net (Ron Garret) Date: Wed, 20 May 2009 17:25:00 -0700 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <20090520165700.C36697@abq.clozure.com> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <20090520165700.C36697@abq.clozure.com> Message-ID: <425AE175-227E-4C73-9899-04407C637673@awun.net> On May 20, 2009, at 4:08 PM, Gary Byers wrote: > > > On Wed, 20 May 2009, John McAleely wrote: > >>>> I don't see this bug in 1.3-dev-r12100M-trunk DarwinX8632 or >>>> DarwinX8664. >>> >>> I'll be darned, it does seem to have been fixed. Now *that* is good >>> customer service! >>> >>> rg >> >> Yup! Thank you! I also like the new look of the alt-console >> window :-) >> >> Is there a reason why the text in it is red, and not black like every >> other window? > > Because it's not like every other window ? > > AltConsole is a (small) separate application; it's supposed to provide > a primitive terminal-like interface to GUI applications that don't > ordinarily have such an interface. If its window appears, there's > a good chance that that's because of something anomalous and that > something probably requires user or developer attention. > > There might be better ways of attracting that attention than to > use red text on a white background, but trying to "blend in" isn't > really the point here ... FWIW, simply appearing as the front window is enough to get my attention. The red text doesn't really add any value for me in this regard. Also, I think AltConsole will very likely prove to be more generally useful than just indicating anomalies. Alexander Repenning's LUI code, for example, already uses it for routine diagnostic output from interactive UI controls. rg From jgrant at imagine27.com Wed May 20 17:43:01 2009 From: jgrant at imagine27.com (Justin Grant) Date: Wed, 20 May 2009 17:43:01 -0700 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> Message-ID: <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> > Haskell is more restrictive than Clojure, not less. The language defined by > Haskell 98 has no way whatsoever to perform assignment. Monads provide a way > to *simulate* assignment, but what they actually do is not assignment (much > less simple assignment). Yes, Haskell is a 'purely' functional language so it may 'appear' more restrictive than Clojure but that is not the case at all. Let's not get hung up on semantics : both references and arrays can live in state monads or the IO monad. These are two methods of structuring imperative effects in Haskell. Haskell has many mutable data structures too (as does Clojure, it's built on Java). Haskell also has variable binding (as does Clojure). Refs and Agents in Clojure are fine if that's your thing. I'd argue that other languages do a much nicer job of this. Also, Haskell being a 'purely' functional language has nothing to do with it's concurrency features. For that 'Concurrent Haskell' has been put forward by SPJ etc. but this is an explicit extension to the language that allows atomically-mutable state in concurrent applications. It's arguable that Haskell has been through years of trying to be 'purely' functional with hardly much success. Clojure takes the same approach to managing threads that Common Lisp does to > managing memory allocation. If Clojure's design in this area represents > "patronizing assumptions", then so does Common Lisp's memory-management > design. Memory-management is a completely different problem that requires a different solution than does concurrent programming. Memory allocation is always required by any program. Any language designer making that assumption is always correct. The same assumption cannot be made by a language designer about concurrency. Who's to say that the user will always be writing concurrent programs ? 'Everything looking like a nail' and all that. This problem exists at another level and is best handled by the programmer. Sure it's nice to make such an assumption at a language design level if you must but make it optional and in doing so allow the programmer more power. Common Lisp is designed to make winning easy in the area of memory > management. Clojure takes that design as a given, and in addition is > designed to make winning easy in the area of concurrent programming. If you > really want malloc and free, don't use Common Lisp. If you really want locks > and simple assignment, don't use Clojure. > Clojure has intentionally ignored many approaches taken in CL (not a judgment, just an observation). Many choices were made because of Clojure's foundation (the JVM) and this shows through when programming in the language beyond any trivial examples. Customer approved platforms, existing investments and the 'industry standard' all factored heavily in Clojure's design at some cost to giving the user more power (it's all on the Clojure website). This makes for Clojure being the 'industry standard' Lisp, for better or worse. Clueless managers may end up praising it the way they did Java after reading about it in some magazine. That's all fine, but another problem that Clojure faces is the marriage of a language trying to be 'purely' functional on top of a platform(including libraries) that will always be imperative. Java was never just a language, it's always been a language, the jvm and the libraries. Clojure inherits the legacy of all this because of it's design. The magnitude and scope of these problems is yet to be discovered by the Java/Clojure community when they get into building real systems and extending current systems on the JVM with existing libraries. My bet is that you'll probably see lots of users effectively programming in Java (but using s-exps) when they realize that using the language with existing Java libs is a complete impedance mismatch. You'll likely hear the more experienced Clojure users suggest wrapping these problems up in macros or something. Who wants that job ? Good luck ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Wed May 20 18:59:15 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Wed, 20 May 2009 21:59:15 -0400 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <64213ADE-D19B-4BC4-89FA-BCE636977F39@mcaleely.com> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <20090520165700.C36697@abq.clozure.com> <64213ADE-D19B-4BC4-89FA-BCE636977F39@mcaleely.com> Message-ID: you have my vote too for the black text color. I don't mind the console looking different but the red font does look a tad disturbing. When running our event code in LUI we do produce output which always ends up in the AltConsole. At any rate this should not be hard to "fix". I suggest to include a config file for the console, e.g., textColor = "000000" /* black This way everybody can have it their way. Here is a harder problem that we face: The console is fine for developer mode but in end-user mode, i.e., when using CCL to create a complete app without listener and with custom menus we absolutely cannot have the Altconsole. In MCL this was not exactly trivial to achieve either. We had to create a pretty complex conditions handler case that would catch all the conditions, present them in a standard dialog, e.g., simple-condition: division-by-zero "OK" and continue in some meaningful way, e.g., stop simulation, adjust controls such as run/stop/step buttons, and restart the event loop. Using native threads I can already anticipate tricky challenges but if CCL is to be used to build "real" applications this kind of functionality is rather crucial. What to do? Alex On May 20, 2009, at 7:43 PM, John McAleely wrote: >>> Is there a reason why the text in it is red, and not black like >>> every >>> other window? >> >> Because it's not like every other window ? >> >> AltConsole is a (small) separate application; it's supposed to >> provide >> a primitive terminal-like interface to GUI applications that don't >> ordinarily have such an interface. If its window appears, there's >> a good chance that that's because of something anomalous and that >> something probably requires user or developer attention. > > I understand the special status of this application window, and I > empathise with the attempt to draw attention to it. > > However, the text is marginally harder to read, and I fail to believe > colouring it red provides any meaningful extra information to a > developer or user. I feel it also manages to look surprisingly like > some sort of bug itself. > > J > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From alms at clozure.com Wed May 20 19:19:49 2009 From: alms at clozure.com (Andrew Shalit) Date: Wed, 20 May 2009 22:19:49 -0400 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <20090520165700.C36697@abq.clozure.com> <64213ADE-D19B-4BC4-89FA-BCE636977F39@mcaleely.com> Message-ID: <1414ED4B-CA1A-46CB-A4B6-F3C9510C8FE0@clozure.com> Do you want your end users to see these messages? Many "real" Macintosh applications send to the system log files. Most Mac users never see these messages, but if you look at the log files they're there. I wouldn't think it would be hard for CCL to do the same, rather than sending output to the Alt Console. But of course, it won't be visible to the user then. On May 20, 2009, at 9:59 PM, Alexander Repenning wrote: > you have my vote too for the black text color. I don't mind the > console looking different but the red font does look a tad > disturbing. When running our event code in LUI we do produce output > which always ends up in the AltConsole. At any rate this should not > be hard to "fix". I suggest to include a config file for the > console, e.g., > > textColor = "000000" /* black > > This way everybody can have it their way. > > Here is a harder problem that we face: The console is fine for > developer mode but in end-user mode, i.e., when using CCL to create > a complete app without listener and with custom menus we absolutely > cannot have the Altconsole. In MCL this was not exactly trivial to > achieve either. We had to create a pretty complex conditions handler > case that would catch all the conditions, present them in a standard > dialog, e.g., simple-condition: division-by-zero "OK" and continue > in some meaningful way, e.g., stop simulation, adjust controls such > as run/stop/step buttons, and restart the event loop. Using native > threads I can already anticipate tricky challenges but if CCL is to > be used to build "real" applications this kind of functionality is > rather crucial. > > What to do? > > Alex > > > > On May 20, 2009, at 7:43 PM, John McAleely wrote: > >>>> Is there a reason why the text in it is red, and not black like >>>> every >>>> other window? >>> >>> Because it's not like every other window ? >>> >>> AltConsole is a (small) separate application; it's supposed to >>> provide >>> a primitive terminal-like interface to GUI applications that don't >>> ordinarily have such an interface. If its window appears, there's >>> a good chance that that's because of something anomalous and that >>> something probably requires user or developer attention. >> >> I understand the special status of this application window, and I >> empathise with the attempt to draw attention to it. >> >> However, the text is marginally harder to read, and I fail to believe >> colouring it red provides any meaningful extra information to a >> developer or user. I feel it also manages to look surprisingly like >> some sort of bug itself. >> >> J >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Wed May 20 21:30:04 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 20 May 2009 22:30:04 -0600 (MDT) Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <1414ED4B-CA1A-46CB-A4B6-F3C9510C8FE0@clozure.com> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <20090520165700.C36697@abq.clozure.com> <64213ADE-D19B-4BC4-89FA-BCE636977F39@mcaleely.com> <1414ED4B-CA1A-46CB-A4B6-F3C9510C8FE0@clozure.com> Message-ID: <20090520203409.H36697@abq.clozure.com> In most cases, it should also be possible to display a modal dialog if an error occurs during event processing, and it shouldn't be necessary to saturate application-level code with condition-handling code in order to achieve that much. What we've generally been doing when an error occurs on the event thread is to print a few pages of backtrace info and the error message to the process-wide standard output and then transfer control to a handler in the main event lopp; transferring control to that handler should give intervening lisp and ObjC code the opportunity to run UNWIND-PROTECT cleanup forms (which may be @finally clauses in ObjC.) Popping up some sort of modal dialog that reports the condition isn't conceptually a lot different from spitting out the backtrace and neither's ideal for interactive debugging, but the general idea of abandoning processing of an event that generates an error and waiting for the next event seems to work reasobably well. One case where this may not work as well - I don't know - is when the error occurs during a #/drawRect: method. Some global (at least thread-wide) graphics state gets set up before #/drawRect: is called and I don't know exactly what happens if we just throw out of the #/drawRect: (or if additional Bad Things would happen if we popped up a window while we were supposed to be drawing a view.) The first part of this has to do with whether there's an ObjC UNWIND-PROTECT (@try/@finally) that does whatever graphics state cleanup is necessary. In MCL, it could be very difficult to recover from an error that occurred during a callback: you generally didn't know what state the calling foreign code had set up and didn't know how to clean up anything that needed to be cleaned up. Similarly, if foreign code used setjmp/longjmp to do some sort of control transfer (not too common, but it could happen), that transfer wouldn't run intervening lisp UNWIND-PROTECT cleanup forms. ObjC offers a much more reasonable exception-handling mechanism, Cocoa uses it extensively, and the ObjC bridge does a pretty good job of making the ObjC and Lisp stack-unwinding mechanisms cooperate. On Wed, 20 May 2009, Andrew Shalit wrote: > Do you want your end users to see these messages? > > Many "real" Macintosh applications send to the system log files. Most Mac > users never see these messages, but if you look at the log files they're > there. I wouldn't think it would be hard for CCL to do the same, rather than > sending output to the Alt Console. But of course, it won't be visible to the > user then. > > > > On May 20, 2009, at 9:59 PM, Alexander Repenning wrote: > >> you have my vote too for the black text color. I don't mind the console >> looking different but the red font does look a tad disturbing. When running >> our event code in LUI we do produce output which always ends up in the >> AltConsole. At any rate this should not be hard to "fix". I suggest to >> include a config file for the console, e.g., >> >> textColor = "000000" /* black >> >> This way everybody can have it their way. >> >> Here is a harder problem that we face: The console is fine for developer >> mode but in end-user mode, i.e., when using CCL to create a complete app >> without listener and with custom menus we absolutely cannot have the >> Altconsole. In MCL this was not exactly trivial to achieve either. We had >> to create a pretty complex conditions handler case that would catch all the >> conditions, present them in a standard dialog, e.g., simple-condition: >> division-by-zero "OK" and continue in some meaningful way, e.g., stop >> simulation, adjust controls such as run/stop/step buttons, and restart the >> event loop. Using native threads I can already anticipate tricky challenges >> but if CCL is to be used to build "real" applications this kind of >> functionality is rather crucial. >> >> What to do? >> >> Alex >> >> >> >> On May 20, 2009, at 7:43 PM, John McAleely wrote: >> >>>>> Is there a reason why the text in it is red, and not black like every >>>>> other window? >>>> >>>> Because it's not like every other window ? >>>> >>>> AltConsole is a (small) separate application; it's supposed to provide >>>> a primitive terminal-like interface to GUI applications that don't >>>> ordinarily have such an interface. If its window appears, there's >>>> a good chance that that's because of something anomalous and that >>>> something probably requires user or developer attention. >>> >>> I understand the special status of this application window, and I >>> empathise with the attempt to draw attention to it. >>> >>> However, the text is marginally harder to read, and I fail to believe >>> colouring it red provides any meaningful extra information to a >>> developer or user. I feel it also manages to look surprisingly like >>> some sort of bug itself. >>> >>> J >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >> >> Prof. Alexander Repenning >> >> University of Colorado >> Computer Science Department >> Boulder, CO 80309-430 >> >> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > From mevins at mac.com Wed May 20 23:37:20 2009 From: mevins at mac.com (mikel evins) Date: Thu, 21 May 2009 01:37:20 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> Message-ID: <9596318D-D232-4104-84F0-8C9D76A73C52@mac.com> On May 20, 2009, at 7:43 PM, Justin Grant wrote: > Yes, Haskell is a 'purely' functional language so it may 'appear' > more restrictive than Clojure but that is not the case at all. No, it is actually more restrictive in the area under discussion, which is assignment. Clojure provides assignment; Haskell does not. You cite state monads and the IO monad, but they're not examples of assignment in Haskell; they're examples of lambda binding with a layer of syntax crafted to resemble the assignment forms in other languages. That's a dubious design decision, if it leads to people confusing what they do with assignment. For examples of assignment in Haskell, we have to turn to FFI extensions; but once we do that, we can then also talk about Clojure's support for unrestricted assignment, and Common Lisp's support for malloc and free and pointer-bashing. > Haskell being a 'purely' functional language has nothing to do with > it's concurrency features. That's beside the point, which is that Haskell's restrictions make certain solutions workable that wouldn't be, otherwise. STM (Software Transactional Memory) is one example of such a solution, an example that also happens to be relevant because it's useful for concurrent programming, as well as because Clojure supports it, too. Clojure and Common Lisp both do the same thing that Haskell does: they take away certain facilities because their absence makes certain solutions workable. Concurrency is different from memory management in this respect only because multiple cores have become cheap and widespread long after large memories did. GC is a solution to the robustness and productivity problems caused by manual memory management. STM is a solution (one of several) to the robustness and productivity problems caused by manual concurrency management. There are certainly many programs that don't involve a lot of concurrency, but Moore's law is over, and chipmakers are giving us more cores now instead of faster ones. Sure, some people will always want to manage their threads manually, just as some people will always want malloc and free. But some like GC, because it makes a bunch of headaches go away, and the cost of giving up malloc and free goes down all the time. As cores multiply, the same thing will happen for facilities that do for concurrency what GC does for memory management. Of course, no one has to give up manual concurrency management, just as no one has to give up malloc and free. If you want malloc and free, use tools that offer them. > Clojure has intentionally ignored many approaches taken in CL (not a > judgment, just an observation). > Many choices were made because of Clojure's foundation (the JVM) and > this shows through when programming in the language beyond any > trivial examples. Some were; Rich Hickey has been pretty forthcoming and explicit about exactly which decisions those were. Some of them may actually be important; certainly I find some of them annoying. Jeremy suggested that someone could implement a Common Lisp designed around Clojure's concurrency features. You said you hoped not; I don't think you have anything to worry about. I don't think bolting Clojure's concurrency features onto Common Lisp buys much. Clojure's concurrency features work well because they're part of a package deal. I think it's pretty hard to fit that package deal into Common Lisp. I can imagine a Lisp other than Clojure that would fit it, but it wouldn't be Common Lisp. > That's all fine, but another problem that Clojure faces is the > marriage of a language trying to be 'purely' functional on top of a > platform(including libraries) that will always be imperative. Clojure is not a purely functional language and has never been intended to be one. If it were, using the JVM as a platform is no more a barrier than using a Von Neumann architecture as a platform is a barrier to Haskell. > My bet is that you'll probably see lots of users effectively > programming in Java (but using s-exps) when they realize that using > the language with existing Java libs is a complete impedance mismatch. That's not what we see so far, and I haven't seen any sign that it will be in the future. I have my quibbles with Clojure, but this is not one of them. --me From danielgackle at gmail.com Wed May 20 23:44:25 2009 From: danielgackle at gmail.com (Daniel Gackle) Date: Thu, 21 May 2009 00:44:25 -0600 Subject: [Openmcl-devel] =?iso-8859-7?q?Macro_named_=EB_won=27t_expand_in_?= =?iso-8859-7?q?Slime_REPL?= Message-ID: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> We defined a macro named ? (Greek lambda character, in case this email isn't Unicode-friendly) to expand into a lambda form, partly to save typing and partly to add a couple extra features our system needs. This works fine when you compile files, but not in a Slime REPL or when using the command slime-compile-defun. For example, (defun foo () (? (x) (1+ x))) works the way you'd expect if you compile the file it's in. But in the REPL bad things happen: (defun foo () (? (x) (1+ x))) ;Compiler warnings : ; In FOO: Undefined function ? ; In FOO: Undefined function X ; In FOO: Undeclared free variable X => FOO (foo) => Undefined function X called with arguments () . [Condition of type CCL::UNDEFINED-FUNCTION-CALL] (macroexpand '(? (x) (1+ x))) => (? (X) (1+ X)) And if you use slime-compile-defun on the (defun foo...) form, the following occurs: While compiling FOO : #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) . [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR] I'm posting this here because none of the above errors happen in SBCL, so there would seem to be something specific about the combination of Slime and CCL that doesn't like this macro. Does anyone have any ideas or suggestions? Thank you, Daniel Gackle -------------- next part -------------- An HTML attachment was scrubbed... URL: From stassats at gmail.com Wed May 20 23:53:38 2009 From: stassats at gmail.com (Stas Boukarev) Date: Thu, 21 May 2009 10:53:38 +0400 Subject: [Openmcl-devel] =?utf-8?q?Macro_named_=CE=BB_won=27t_expand_in_Sl?= =?utf-8?q?ime_REPL?= In-Reply-To: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> (Daniel Gackle's message of "Thu, 21 May 2009 00:44:25 -0600") References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> Message-ID: <87my97x7yl.fsf@gmail.com> Daniel Gackle writes: > We defined a macro named ? (Greek lambda character, in case this email isn't Unicode-friendly) to expand into a lambda form, partly to > save typing and partly to add a couple extra features our system needs. This works fine when you compile files, but not in a Slime REPL or > when using the command slime-compile-defun. For example, > > (defun foo () > ? (? (x) (1+ x))) > > works the way you'd expect if you compile the file it's in. But in the REPL bad things happen: > > (defun foo () > ?? (? (x) (1+ x))) > ;Compiler warnings : > ;?? In FOO: Undefined function ? > ;?? In FOO: Undefined function X > ;?? In FOO: Undeclared free variable X > => FOO > > (foo) > => Undefined function X called with arguments () . > ?? [Condition of type CCL::UNDEFINED-FUNCTION-CALL] > > (macroexpand '(? (x) (1+ x))) > ?=> (? (X) (1+ X)) > > And if you use slime-compile-defun on the (defun foo...) form, the following occurs: > > While compiling FOO : > #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) . > ?? [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR] > > I'm posting this here because none of the above errors happen in SBCL, so there would seem to be something specific about the combination > of Slime and CCL that doesn't like this macro. Does anyone have any ideas or suggestions? > > Thank you, > > Daniel Gackle > Are you sure that your macro is defined? (defmacro ? (arguments &body body) `(lambda ,arguments , at body)) (funcall (? (x) (+ x 1)) 5) => 6 Works fine here. -- With best regards, Stas. From rme at clozure.com Thu May 21 00:12:20 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 21 May 2009 03:12:20 -0400 Subject: [Openmcl-devel] =?utf-8?q?Macro_named_=CE=BB_won=27t_expand_in_Sl?= =?utf-8?q?ime_REPL?= In-Reply-To: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> Message-ID: On May 21, 2009, at 2:44 AM, Daniel Gackle wrote: > We defined a macro named ? (Greek lambda character, in case this > email isn't Unicode-friendly) to expand into a lambda form, partly > to save typing and partly to add a couple extra features our system > needs. This works fine when you compile files, but not in a Slime > REPL or when using the command slime-compile-defun. For example, > > (defun foo () > (? (x) (1+ x))) > > works the way you'd expect if you compile the file it's in. But in > the REPL bad things happen: > > (defun foo () > (? (x) (1+ x))) > ;Compiler warnings : > ; In FOO: Undefined function ? > ; In FOO: Undefined function X > ; In FOO: Undeclared free variable X > => FOO Did you LOAD the file that contains your macro definition? In SBCL, if you run compile-file on a file that defines a macro, that macro definition appears to get added to the global environment as a side-effect. This doesn't happen in CCL (that's a feature). For example, create /tmp/foo.lisp: (in-package "CL-USER") (defmacro junk (arg) `(format t "~s" ,arg)) In SBCL: * (compile-file "/tmp/foo") ; compiling file "/tmp/foo.lisp" (written 21 MAY 2009 02:59:24 AM): ; compiling (IN-PACKAGE "CL-USER") ; compiling (DEFMACRO JUNK ...) ; /tmp/foo.fasl written ; compilation finished in 0:00:00 #P"/tmp/foo.fasl" NIL NIL * (macroexpand '(junk 12)) (FORMAT T "~s" 12) T * In CCL: ? (compile-file "/tmp/foo") #P"/private/tmp/foo.dx32fsl" NIL NIL ? (macroexpand '(junk 12)) (JUNK 12) NIL ? (load "/tmp/foo") #P"/private/tmp/foo.dx32fsl" ? (macroexpand '(junk 12)) (FORMAT T "~s" 12) T ? > (foo) > => Undefined function X called with arguments () . > [Condition of type CCL::UNDEFINED-FUNCTION-CALL] > > (macroexpand '(? (x) (1+ x))) > => (? (X) (1+ X)) > > And if you use slime-compile-defun on the (defun foo...) form, the > following occurs: > > While compiling FOO : > #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) . > [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR] > > I'm posting this here because none of the above errors happen in > SBCL, so there would seem to be something specific about the > combination of Slime and CCL that doesn't like this macro. Does > anyone have any ideas or suggestions? From danielgackle at gmail.com Thu May 21 00:29:52 2009 From: danielgackle at gmail.com (Daniel Gackle) Date: Thu, 21 May 2009 01:29:52 -0600 Subject: [Openmcl-devel] =?iso-8859-7?q?Macro_named_=EB_won=27t_expand_in_?= =?iso-8859-7?q?Slime_REPL?= In-Reply-To: References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> Message-ID: <57952f8b0905210029l6421e7a6x1b8543442887f747@mail.gmail.com> < Did you LOAD the file that contains your macro definition? > Yes, along with a bunch of files that use the macro, all of which work fine. It's only the REPL access that's problematic (plus C-c C-c to compile an individual defun), as I described. Perhaps I should mention that there are other macros defined in the same file, none of which exhibit the symptoms of the ? one; they all macroexpand properly in the REPL and so on. And if I change the name of the troublesome macro from ? to something like FOO, it too becomes well-behaved. Daniel On Thu, May 21, 2009 at 1:12 AM, R. Matthew Emerson wrote: > > On May 21, 2009, at 2:44 AM, Daniel Gackle wrote: > > We defined a macro named ? (Greek lambda character, in case this email >> isn't Unicode-friendly) to expand into a lambda form, partly to save typing >> and partly to add a couple extra features our system needs. This works fine >> when you compile files, but not in a Slime REPL or when using the command >> slime-compile-defun. For example, >> >> (defun foo () >> (? (x) (1+ x))) >> >> works the way you'd expect if you compile the file it's in. But in the >> REPL bad things happen: >> >> (defun foo () >> (? (x) (1+ x))) >> ;Compiler warnings : >> ; In FOO: Undefined function ? >> ; In FOO: Undefined function X >> ; In FOO: Undeclared free variable X >> => FOO >> > > Did you LOAD the file that contains your macro definition? > > In SBCL, if you run compile-file on a file that defines a macro, that macro > definition appears to get added to the global environment as a side-effect. > This doesn't happen in CCL (that's a feature). > > For example, create /tmp/foo.lisp: > > (in-package "CL-USER") > > (defmacro junk (arg) > `(format t "~s" ,arg)) > > In SBCL: > > * (compile-file "/tmp/foo") > > ; compiling file "/tmp/foo.lisp" (written 21 MAY 2009 02:59:24 AM): > ; compiling (IN-PACKAGE "CL-USER") > ; compiling (DEFMACRO JUNK ...) > > ; /tmp/foo.fasl written > ; compilation finished in 0:00:00 > #P"/tmp/foo.fasl" > NIL > NIL > * (macroexpand '(junk 12)) > > (FORMAT T "~s" 12) > T > * > > In CCL: > ? (compile-file "/tmp/foo") > #P"/private/tmp/foo.dx32fsl" > NIL > NIL > ? (macroexpand '(junk 12)) > (JUNK 12) > NIL > ? (load "/tmp/foo") > #P"/private/tmp/foo.dx32fsl" > ? (macroexpand '(junk 12)) > (FORMAT T "~s" 12) > T > > ? > > > (foo) >> => Undefined function X called with arguments () . >> [Condition of type CCL::UNDEFINED-FUNCTION-CALL] >> >> (macroexpand '(? (x) (1+ x))) >> => (? (X) (1+ X)) >> >> And if you use slime-compile-defun on the (defun foo...) form, the >> following occurs: >> >> While compiling FOO : >> #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) . >> [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR] >> >> I'm posting this here because none of the above errors happen in SBCL, so >> there would seem to be something specific about the combination of Slime and >> CCL that doesn't like this macro. Does anyone have any ideas or suggestions? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielgackle at gmail.com Thu May 21 00:35:08 2009 From: danielgackle at gmail.com (Daniel Gackle) Date: Thu, 21 May 2009 01:35:08 -0600 Subject: [Openmcl-devel] =?iso-8859-7?q?Macro_named_=EB_won=27t_expand_in_?= =?iso-8859-7?q?Slime_REPL?= In-Reply-To: <87my97x7yl.fsf@gmail.com> References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> <87my97x7yl.fsf@gmail.com> Message-ID: <57952f8b0905210035h3c89f4bdqfa29858545ddb565@mail.gmail.com> Perhaps you are evaluating the (defmacro ?...) form in the REPL? That works for me too. What doesn't work is loading a *file* with the (defmacro ?...) and then trying to macroexpand a usage of ? in the REPL. Sorry I didn't make that clear. Also, as I mentioned in replying to Matthew, the whole problem goes away if we use a more normal name than ?. But ? is a nice name and we haven't come up with anything better (FN seemed like a good candidate, but turned out not to be). Daniel On Thu, May 21, 2009 at 12:53 AM, Stas Boukarev wrote: > Daniel Gackle writes: > > > We defined a macro named ? (Greek lambda character, in case this email > isn't Unicode-friendly) to expand into a lambda form, partly to > > save typing and partly to add a couple extra features our system needs. > This works fine when you compile files, but not in a Slime REPL or > > when using the command slime-compile-defun. For example, > > > > (defun foo () > > (? (x) (1+ x))) > > > > works the way you'd expect if you compile the file it's in. But in the > REPL bad things happen: > > > > (defun foo () > > (? (x) (1+ x))) > > ;Compiler warnings : > > ; In FOO: Undefined function ? > > ; In FOO: Undefined function X > > ; In FOO: Undeclared free variable X > > => FOO > > > > (foo) > > => Undefined function X called with arguments () . > > [Condition of type CCL::UNDEFINED-FUNCTION-CALL] > > > > (macroexpand '(? (x) (1+ x))) > > => (? (X) (1+ X)) > > > > And if you use slime-compile-defun on the (defun foo...) form, the > following occurs: > > > > While compiling FOO : > > #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) . > > [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR] > > > > I'm posting this here because none of the above errors happen in SBCL, so > there would seem to be something specific about the combination > > of Slime and CCL that doesn't like this macro. Does anyone have any ideas > or suggestions? > > > > Thank you, > > > > Daniel Gackle > > > Are you sure that your macro is defined? > (defmacro ? (arguments &body body) `(lambda ,arguments , at body)) > > (funcall (? (x) (+ x 1)) 5) => 6 > > Works fine here. > > -- > With best regards, Stas. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Thu May 21 01:47:49 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 21 May 2009 02:47:49 -0600 (MDT) Subject: [Openmcl-devel] =?iso-8859-7?q?Macro_named_=EB_won=27t_expand_in_?= =?iso-8859-7?q?Slime_REPL?= In-Reply-To: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> Message-ID: <20090521004539.N37996@abq.clozure.com> What character encoding is Slime using to talk to the lisp ? If you do: SLIME-PROMPT> (defvar *string* "") where is a single #\u+03bb character, what do: SLIME-PROMPT> (length *string*) ; should be 1 and SLIME-PROMPT> (char-code (schar *string* 0)) ; should be #x3bb = 955. return ? If Slime thinks that the stream used to talk to CCL is UTF-8 encoded and CCL thinks that it's encoded in ISO-8859-1, Slime would send two bytes (#xce #xbb), which the lisp would interpret as two 8-bit ISO-8859-1 character codes (for the characters #\Latin_Capital_Letter_I_With_Circumflex and #\Right-Pointing_Double_Angle_Quotation_Mark.) After starting to write this reply, I looked at your message in a mail client that's more Unicode-aware than the one that I usually use. It looked like the lisp had uppercased the lambda character at some point, which suggests that the lisp and Slime agree on the character encoding. If the problem here isn't something more mundane (like the symbol whose name is the LAMBDA character not being visible in the REPL's package), I wonder if something similar happened when the file containing the macro definition was compiled. E.g., the lambda character would be encoded in those two bytes in a UTF-8-encoded file, but if the file was compiled with a default :EXTERNAL-FORMAT of :ISO-8859-1, a two-character symbol name would have been read and interned and defined as a macro. (That would have happened consistently, so calls to the macro in the file(s) would appear to work as expected.) If this or something like it turns out to be the problem, I vote that the entire world stop using 8-bit character encodings and immediately encode all existing and future files, web pages, email messages, etc. in UTF-32 whose endianness matches whatever computer I'm using at the moment. CCL's reader treats (almost) all non-ASCII characters as "constituents" (characters that can form symbols) and this shouldn't be sensitive to what kind of stream the characters are being read from. (The character encoding of that stream affects the sequence of characters that the reader sees, and this sounds like it may be a case where an encoding was incorrectly specified.) On Thu, 21 May 2009, Daniel Gackle wrote: > We defined a macro named ? (Greek lambda character, in case this email isn't > Unicode-friendly) to expand into a lambda form, partly to save typing and > partly to add a couple extra features our system needs. This works fine when > you compile files, but not in a Slime REPL or when using the command > slime-compile-defun. For example, > > (defun foo () > (? (x) (1+ x))) > > works the way you'd expect if you compile the file it's in. But in the REPL > bad things happen: > > (defun foo () > (? (x) (1+ x))) > ;Compiler warnings : > ; In FOO: Undefined function ? > ; In FOO: Undefined function X > ; In FOO: Undeclared free variable X > => FOO > > (foo) > => Undefined function X called with arguments () . > [Condition of type CCL::UNDEFINED-FUNCTION-CALL] > > (macroexpand '(? (x) (1+ x))) > => (? (X) (1+ X)) > > And if you use slime-compile-defun on the (defun foo...) form, the following > occurs: > > While compiling FOO : > #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) . > [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR] > > I'm posting this here because none of the above errors happen in SBCL, so > there would seem to be something specific about the combination of Slime and > CCL that doesn't like this macro. Does anyone have any ideas or suggestions? > > Thank you, > > Daniel Gackle > From john at mcaleely.com Thu May 21 03:29:05 2009 From: john at mcaleely.com (John McAleely) Date: Thu, 21 May 2009 11:29:05 +0100 Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: <369C3341-3B72-4B6A-AD4B-6721C3339127@awun.net> References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <369C3341-3B72-4B6A-AD4B-6721C3339127@awun.net> Message-ID: On 20 May 2009, at 21:29, Ron Garret wrote: >> > > Check-for-updates seems to be working now too! > > rg > Not for me :-( Still outputs a lot of chat to the AltConsole: *** Error in event process: value NIL is not of the expected type ARRAY. (442BC0) : 0 (FUNCALL #'#<(:INTERNAL CCL::|-[LispApplicationDelegate updateCCL:]|)> #) 149 (#:G36316) #:G36316: # #:COMPILER-VAR: (NIL) #:G36313: # (442BE8) : 1 (SIGNAL #) 981 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (ERROR)) CCL::TAG: # CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* CCL::FN: # (442C40) : 2 (%ERROR # NIL 558477) 117 (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: NIL CCL::ERROR-POINTER: 558477 (442C68) : 3 (ARRAY-DATA-AND-OFFSET NIL) 85 (ARRAY) ARRAY: NIL CCL::TYPECODE: 3 (442C88) : 4 (MAKE-STRING-INPUT-STREAM NIL 0 0) 189 (STRING &OPTIONAL CCL::START CCL::END) STRING: NIL CCL::START: 0 CCL::END: 0 (442CE8) : 5 (READ-FROM-STRING NIL T NIL :START 0 :END NIL :PRESERVE- WHITESPACE NIL) 245 (STRING &OPTIONAL CCL::EOF-ERROR-P CCL::EOF-VALUE &KEY :START :END :PRESERVE-WHITESPACE) STRING: NIL CCL::EOF-ERROR-P: T CCL::EOF-VALUE: NIL CCL::START: 0 CCL::END: NIL CCL::PRESERVE-WHITESPACE: NIL CCL::IDX: NIL (442D60) : 6 (SVN-UPDATE-AVAILABLE-P) 117 NIL CCL::CCL-DIR: #P"/Applications/ccl/" (442D78) : 7 (FUNCALL #'# 17591849974992) 1445 (#:G36312) #:G36312: 17591849974992 #:G36328: # #:G36313: # #:COMPILER-VAR: (NIL) #:G36318: # #:G36329: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) CCL::SELF: # (#x1EFF20)> CCL::_CMD: # CCL::SENDER: # (#x1D1C30)> GUI::NSTITLE: # GUI::NSMESSAGE: # GUI::WINDOW: # (#xC472E80)> GUI::PROGRESS-BAR: # (#xC471A60)> GUI::MESSAGE-FIELD: # (#xC471F50)> GUI::MODAL-SESSION: # (442E48) : 8 (%PASCAL-FUNCTIONS% 247 17591849974992) 397 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 247 CCL::ARGS-PTR-FIXNUM: 17591849974992 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (442F08) : 10 (FUNCALL #'# # (#x1BF750)> #S(CCL::OBJC- SELECTOR :NAME "run" :%SEL #)) 205 (#:G3078 #:G3079) #:G3078: # (#x1BF750)> #:G3079: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # (#x1BF750)>) 501 (CCL::RECEIVER &REST CCL::ARGS) CCL::RECEIVER: # (#x1BF750)> CCL::ARGS: NIL CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) FUNCTION: # (442F68) : 12 (EVENT-LOOP NIL) 413 (&OPTIONAL GUI::END-TEST) GUI::END-TEST: NIL GUI::APP: # (#x1BF750)> *BREAK-ON-ERRORS*: NIL #:G7603: (ERROR) CCL::%HANDLERS%: ((ERROR)) GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#) From john at mcaleely.com Thu May 21 03:37:00 2009 From: john at mcaleely.com (John McAleely) Date: Thu, 21 May 2009 11:37:00 +0100 Subject: [Openmcl-devel] check-for-updates not functioning In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <369C3341-3B72-4B6A-AD4B-6721C3339127@awun.net> Message-ID: Doh. forgot to mention: Mac OS X 10.5.7, Clozure Common Lisp version 0.1 (12103M-trunk) On 21 May 2009, at 11:29, John McAleely wrote: > > On 20 May 2009, at 21:29, Ron Garret wrote: >>> >> >> Check-for-updates seems to be working now too! >> >> rg >> > > Not for me :-( Still outputs a lot of chat to the AltConsole: > > > > *** Error in event process: value NIL is not of the expected type > ARRAY. > > (442BC0) : 0 (FUNCALL #'#<(:INTERNAL CCL::|-[LispApplicationDelegate > updateCCL:]|)> #) 149 > (#:G36316) > #:G36316: # > > #:COMPILER-VAR: (NIL) > #:G36313: # > > (442BE8) : 1 (SIGNAL #) 981 > (CONDITION &REST CCL::ARGS) > CONDITION: # > CCL::ARGS: NIL > > CCL::%HANDLERS%: ((ERROR) (ERROR)) > CCL::TAG: # > CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > CCL::FN: # [LispApplicationDelegate updateCCL:]|) #x493DBF> > > (442C40) : 2 (%ERROR # NIL 558477) 117 > (CONDITION CCL::ARGS CCL::ERROR-POINTER) > CONDITION: # > CCL::ARGS: NIL > CCL::ERROR-POINTER: 558477 > > > > (442C68) : 3 (ARRAY-DATA-AND-OFFSET NIL) 85 > (ARRAY) > ARRAY: NIL > > CCL::TYPECODE: 3 > > (442C88) : 4 (MAKE-STRING-INPUT-STREAM NIL 0 0) 189 > (STRING &OPTIONAL CCL::START CCL::END) > STRING: NIL > CCL::START: 0 > CCL::END: 0 > > > > (442CE8) : 5 (READ-FROM-STRING NIL T NIL :START 0 :END NIL :PRESERVE- > WHITESPACE NIL) 245 > (STRING &OPTIONAL CCL::EOF-ERROR-P CCL::EOF-VALUE > &KEY :START :END :PRESERVE-WHITESPACE) > STRING: NIL > CCL::EOF-ERROR-P: T > CCL::EOF-VALUE: NIL > CCL::START: 0 > CCL::END: NIL > CCL::PRESERVE-WHITESPACE: NIL > > CCL::IDX: NIL > > (442D60) : 6 (SVN-UPDATE-AVAILABLE-P) 117 > NIL > > CCL::CCL-DIR: #P"/Applications/ccl/" > > (442D78) : 7 (FUNCALL #'# updateCCL:]|> 17591849974992) 1445 > (#:G36312) > #:G36312: 17591849974992 > > #:G36328: # > #:G36313: # > #:COMPILER-VAR: (NIL) > #:G36318: # [LispApplicationDelegate updateCCL:]|) #x493DBF> > #:G36329: (CONDITION #) > CCL::%HANDLERS%: ((CONDITION #) (ERROR)) > CCL::SELF: # 0x1eff20> (#x1EFF20)> > CCL::_CMD: # > CCL::SENDER: # Updates...> (#x1D1C30)> > GUI::NSTITLE: # Updates..." (#xC42CDD0)> > GUI::NSMESSAGE: # changes..." (#xC4685B0)> > GUI::WINDOW: # (#xC472E80)> > GUI::PROGRESS-BAR: # 0xc471a60> (#xC471A60)> > GUI::MESSAGE-FIELD: # > (#xC471F50)> > GUI::MODAL-SESSION: # > > (442E48) : 8 (%PASCAL-FUNCTIONS% 247 17591849974992) 397 > (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > CCL::INDEX: 247 > CCL::ARGS-PTR-FIXNUM: 17591849974992 > > CCL::LISP-FUNCTION: # [LispApplicationDelegate updateCCL:]| (Non-Global) #x3000417F327F> > WITHOUT-INTERRUPTS: NIL > CCL::*CALLBACK-TRACE-P*: NIL > > (442F08) : 10 (FUNCALL #'# # APPLICATION (#x1BF750)> #S(CCL::OBJC- > SELECTOR :NAME "run" :%SEL #)) 205 > (#:G3078 #:G3079) > #:G3078: # (#x1BF750)> > #:G3079: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF81D84D68>) > > > > (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE > (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # APPLICATION (#x1BF750)>) 501 > (CCL::RECEIVER &REST CCL::ARGS) > CCL::RECEIVER: # > (#x1BF750)> > CCL::ARGS: NIL > > CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF81D84D68>) > FUNCTION: # > > (442F68) : 12 (EVENT-LOOP NIL) 413 > (&OPTIONAL GUI::END-TEST) > GUI::END-TEST: NIL > > GUI::APP: # (#x1BF750)> > *BREAK-ON-ERRORS*: NIL > #:G7603: (ERROR) > CCL::%HANDLERS%: ((ERROR)) > GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (# #x300041DDB60D>) > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From tcr at freebits.de Thu May 21 03:45:34 2009 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Thu, 21 May 2009 12:45:34 +0200 Subject: [Openmcl-devel] =?utf-8?q?Macro_named_=CE=BB_won=27t_expand_in_Sl?= =?utf-8?q?ime_REPL?= References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> <20090521004539.N37996@abq.clozure.com> Message-ID: <87fxeyohtd.fsf@freebits.de> Gary Byers writes: > If Slime thinks that the stream used to talk to CCL is UTF-8 encoded > and CCL thinks that it's encoded in ISO-8859-1, ... The problem is not that the network stream is in the wrong encoding because the encoding, usually, comes from Emacs. That's also the reason that it'll work when you type in everything at the REPL. I think, the problem is that the file is encoded in utf8, but an :EXTERNAL-FORMAT of :DEFAULT in COMPILE-FILE is not utf8 in CCL as far as I can see. (In SBCL :DEFAULT is utf8 if unicode-enabled.) Perhaps Slime should send the buffer's coding-system with each request, and we should pass that over to COMPILE-FILE. Helmut, are you reading this list? -T. From gb at clozure.com Thu May 21 04:00:17 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 21 May 2009 05:00:17 -0600 (MDT) Subject: [Openmcl-devel] Visual Bugs in the IDE In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <369C3341-3B72-4B6A-AD4B-6721C3339127@awun.net> Message-ID: Please try: ? (run-program "svn" (list "info" "/Applications/ccl/") :output t) Does that generate several lines of output (lines starting with "Path:", "URL:", etc.) ? Does the EXTERNAL-PROCESS that's returned exit with an exit status of 0 (its printed representation would contain '(EXITED : 0)' in that case ? Calling: ? (getenv "PATH") will (not surprisingly) return the value of the PATH environment variable; for a GUI application (which is ultimately a descendant of the "LoginWindow" process, IIRC"), that's often something a good deal more ... spartan than what one sees in the shell: /usr/bin:/bin:/usr/sbin:/sbin" On Leopard, svn is usually installed in /usr/bin; if you're running Leopard and svn is installed there, then I don't have a good idea of why this doesn't work. If svn isn't installed in some directory that's on the IDE process's PATH, then things would likely behave as you describe. On Thu, 21 May 2009, John McAleely wrote: > > On 20 May 2009, at 21:29, Ron Garret wrote: >>> >> >> Check-for-updates seems to be working now too! >> >> rg >> > > Not for me :-( Still outputs a lot of chat to the AltConsole: > > > > *** Error in event process: value NIL is not of the expected type ARRAY. > > (442BC0) : 0 (FUNCALL #'#<(:INTERNAL CCL::|-[LispApplicationDelegate > updateCCL:]|)> #) 149 > (#:G36316) > #:G36316: # > > #:COMPILER-VAR: (NIL) > #:G36313: # > > (442BE8) : 1 (SIGNAL #) 981 > (CONDITION &REST CCL::ARGS) > CONDITION: # > CCL::ARGS: NIL > > CCL::%HANDLERS%: ((ERROR) (ERROR)) > CCL::TAG: # > CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > CCL::FN: # [LispApplicationDelegate updateCCL:]|) #x493DBF> > > (442C40) : 2 (%ERROR # NIL 558477) 117 > (CONDITION CCL::ARGS CCL::ERROR-POINTER) > CONDITION: # > CCL::ARGS: NIL > CCL::ERROR-POINTER: 558477 > > > > (442C68) : 3 (ARRAY-DATA-AND-OFFSET NIL) 85 > (ARRAY) > ARRAY: NIL > > CCL::TYPECODE: 3 > > (442C88) : 4 (MAKE-STRING-INPUT-STREAM NIL 0 0) 189 > (STRING &OPTIONAL CCL::START CCL::END) > STRING: NIL > CCL::START: 0 > CCL::END: 0 > > > > (442CE8) : 5 (READ-FROM-STRING NIL T NIL :START 0 :END NIL :PRESERVE- > WHITESPACE NIL) 245 > (STRING &OPTIONAL CCL::EOF-ERROR-P CCL::EOF-VALUE > &KEY :START :END :PRESERVE-WHITESPACE) > STRING: NIL > CCL::EOF-ERROR-P: T > CCL::EOF-VALUE: NIL > CCL::START: 0 > CCL::END: NIL > CCL::PRESERVE-WHITESPACE: NIL > > CCL::IDX: NIL > > (442D60) : 6 (SVN-UPDATE-AVAILABLE-P) 117 > NIL > > CCL::CCL-DIR: #P"/Applications/ccl/" > > (442D78) : 7 (FUNCALL #'# updateCCL:]|> 17591849974992) 1445 > (#:G36312) > #:G36312: 17591849974992 > > #:G36328: # > #:G36313: # > #:COMPILER-VAR: (NIL) > #:G36318: # [LispApplicationDelegate updateCCL:]|) #x493DBF> > #:G36329: (CONDITION #) > CCL::%HANDLERS%: ((CONDITION #) (ERROR)) > CCL::SELF: # 0x1eff20> (#x1EFF20)> > CCL::_CMD: # > CCL::SENDER: # Updates...> (#x1D1C30)> > GUI::NSTITLE: # Updates..." (#xC42CDD0)> > GUI::NSMESSAGE: # changes..." (#xC4685B0)> > GUI::WINDOW: # (#xC472E80)> > GUI::PROGRESS-BAR: # 0xc471a60> (#xC471A60)> > GUI::MESSAGE-FIELD: # > (#xC471F50)> > GUI::MODAL-SESSION: # > > (442E48) : 8 (%PASCAL-FUNCTIONS% 247 17591849974992) 397 > (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > CCL::INDEX: 247 > CCL::ARGS-PTR-FIXNUM: 17591849974992 > > CCL::LISP-FUNCTION: # [LispApplicationDelegate updateCCL:]| (Non-Global) #x3000417F327F> > WITHOUT-INTERRUPTS: NIL > CCL::*CALLBACK-TRACE-P*: NIL > > (442F08) : 10 (FUNCALL #'# # APPLICATION (#x1BF750)> #S(CCL::OBJC- > SELECTOR :NAME "run" :%SEL #)) 205 > (#:G3078 #:G3079) > #:G3078: # (#x1BF750)> > #:G3079: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF81D84D68>) > > > > (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE > (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # APPLICATION (#x1BF750)>) 501 > (CCL::RECEIVER &REST CCL::ARGS) > CCL::RECEIVER: # > (#x1BF750)> > CCL::ARGS: NIL > > CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF81D84D68>) > FUNCTION: # > > (442F68) : 12 (EVENT-LOOP NIL) 413 > (&OPTIONAL GUI::END-TEST) > GUI::END-TEST: NIL > > GUI::APP: # (#x1BF750)> > *BREAK-ON-ERRORS*: NIL > #:G7603: (ERROR) > CCL::%HANDLERS%: ((ERROR)) > GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (# #x300041DDB60D>) > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From john at mcaleely.com Thu May 21 04:15:25 2009 From: john at mcaleely.com (John McAleely) Date: Thu, 21 May 2009 12:15:25 +0100 Subject: [Openmcl-devel] check-for-updates not functioning (was Visual bugs in the IDE) In-Reply-To: References: <4C02AE52-B19D-462A-B814-F8087565D8B9@mcaleely.com> <4D4CE9A4-F90A-463B-A5B4-706B8E88AFA4@awun.net> <915B4BC6-69E7-49BC-A843-F519AC149789@awun.net> <369C3341-3B72-4B6A-AD4B-6721C3339127@awun.net> Message-ID: <1F328028-4BD7-4119-97E3-10775F775D73@mcaleely.com> > ? (run-program "svn" (list "info" "/Applications/ccl/") :output t) I evaluated this at the listener in the IDE and got: # and no other output. (getenv "PATH") produces: "/usr/bin:/bin:/usr/sbin:/sbin" Typing svn info at the console inside /Applications/ccl produces: Path: . URL: http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl Repository Root: http://svn.clozure.com/publicsvn/openmcl Repository UUID: 8bdb8f1d-59ce-db11-9e41-0016172a54ae Revision: 12103 Node Kind: directory Schedule: normal Last Changed Author: gb Last Changed Rev: 11870 Last Changed Date: 2009-03-31 11:54:52 +0100 (Tue, 31 Mar 2009) and 'which svn' reveals that it is not on the path noted above: /usr/local/bin/svn I've certainly installed newer versions of svn on this machine than come with OSX, and I'm aware that a bazaar plugin has probably installed (or depends on) some other version of svn on this machine. J > > > Does that generate several lines of output (lines starting with > "Path:", "URL:", etc.) ? Does the EXTERNAL-PROCESS that's returned > exit with an exit status of 0 (its printed representation would > contain > '(EXITED : 0)' in that case ? > > Calling: > > ? (getenv "PATH") > > will (not surprisingly) return the value of the PATH environment > variable; for a GUI application (which is ultimately a descendant > of the "LoginWindow" process, IIRC"), that's often something > a good deal more ... spartan than what one sees in the shell: > > /usr/bin:/bin:/usr/sbin:/sbin" > > On Leopard, svn is usually installed in /usr/bin; if you're > running Leopard and svn is installed there, then I don't have > a good idea of why this doesn't work. If svn isn't installed > in some directory that's on the IDE process's PATH, then things > would likely behave as you describe. > >> > From gb at clozure.com Thu May 21 04:34:56 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 21 May 2009 05:34:56 -0600 (MDT) Subject: [Openmcl-devel] =?iso-8859-7?q?Macro_named_=EB_won=27t_expand_in_?= =?iso-8859-7?q?Slime_REPL?= In-Reply-To: <87fxeyohtd.fsf@freebits.de> References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> <20090521004539.N37996@abq.clozure.com> <87fxeyohtd.fsf@freebits.de> Message-ID: On Thu, 21 May 2009, Tobias C. Rittweiler wrote: > Gary Byers writes: > >> If Slime thinks that the stream used to talk to CCL is UTF-8 encoded >> and CCL thinks that it's encoded in ISO-8859-1, ... > > The problem is not that the network stream is in the wrong encoding > because the encoding, usually, comes from Emacs. That's also the reason > that it'll work when you type in everything at the REPL. Daniel actually said that his code didn't work in the REPL, but as noted later in my reply the fact that the lisp uppercased the lambda character suggests that Slime and CCL agree on the encoding of the network stream. He said that it worked as expected when he compiled and loaded a file containing the macro definition, but this may have worked correctly while misinterpeting the two octets used to encode the lambda character as two ISO-8859-1 character codes. (Or something like that: some discrepancy between the file's actual encoding and the :EXTERNAL-FORMAT used by COMPILE-FILE.) > > I think, the problem is that the file is encoded in utf8, but an > :EXTERNAL-FORMAT of :DEFAULT in COMPILE-FILE is not utf8 in CCL as far > as I can see. (In SBCL :DEFAULT is utf8 if unicode-enabled.) In CCL, :DEFAULT uses a user-settable value that's initially equivalent to :ISO-8859-1; since it's user-settable, passing an explicit :EXTERNAL-FORMAT as you suggest seems wise. > > Perhaps Slime should send the buffer's coding-system with each request, > and we should pass that over to COMPILE-FILE. > > Helmut, are you reading this list? > > -T. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From joakim at joakimsandgren.com Thu May 21 05:33:04 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Thu, 21 May 2009 14:33:04 +0200 Subject: [Openmcl-devel] accents... Message-ID: <24234347-3C86-4A4C-B811-D8B405582FE5@joakimsandgren.com> Hi, I'm coming back to you with some accent behaviors... Apropos.. If you go to Apropos... in the menu and then search for a function and apropos finds it and then you double click on that function in the list to go to the source code : if that function is in a file that is not saved yet, it crashes. if that function is in a file that is saved without .lisp at the end, it crashes. If that function have a accentuated letter in its name (like fran?ais) it goes to the document but do not find the function - that is it do not go to the function putting the cursor in the beginning of it. Search Files... If you use Search Files... in the menu you do not have the choise to search non .lisp-files so that is logic. If you search for accentuated function it - like fran?ais - the search files... do not find anything. alt-shift-period (find the source code command) if I, in the call for the function "fran?ais" put the cursor after the ?, I have "No known definitions for AIS" if I, in the call for the function "fran?ais" put the cursor before the ?, I have "No known definitions for FRAN" Search Files... Window And, when I choose the search files.. in the menu, the first time I have to klick in the window to make it active to start to use it. After that the window is active when it comes up. Apropos... If I go to Apropos... in the menu, this window Is active when it comes up - if I search for a function that is not yet evaluated, the apropos... do not find anything (normal) if I then do evaluate that function and then go to apropos..., apropos... Still do not find anything... Inspector The Inspector window is everytime it is called for Not active then it shows. You always have to click in it to start to use it. Is it very complicated to implement some arrow commands to be able to navigate in the inspector without the mouse? Listener Is it very complicated to be able to fix a position for a Listener Window? I also think that in a vague and lointain future it could be good to simply put inspector window fonts, positions and font size etc in the preferences... The same for Listener window and its position and the normal windows default positions And perhaps be able to chose to stack next window or Not... the functions I used: (defun fran?ais () (print 'fran?ais)) (fran?ais) (defun french () (print 'french)) (french) I Thank You all very much for all the fixes that has been done so far.!!! Very Sincerely Joakim Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianbredin at gmail.com Thu May 21 06:23:00 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Thu, 21 May 2009 15:23:00 +0200 Subject: [Openmcl-devel] A few minor requests for the IDE Message-ID: Hi! I have a few minor requests for the ongoing development (and tweaking) of the IDE. 1. I'd like to be able to Command-Option-click on a function name, and then be brought to the definition (as in MCL). Option-. works, but I prefer the click version. The cursor should preferably not turn into a crosshair either, but rather remain as it is (= a vertical bar). 2. I'd like the text in an editor window to stay in the same scrolling position when I alter the size of the window. This does work when the scrollbar is at the top, but I'd also like this to be true when the scrollbar is in other positions. This typically happens when I go to a definition via 1. above. The editor window is usually quite small (if I haven't opened it before) and the enclosing parens of the sexp is hilighted. Then I move the window to the top and drag the bottom-right corner to resize it. When I release the mouse, the sexp pops to a new position. I suspect that this is a feature, but I'd prefer it to be as I write in the first sentence of this paragraph. 3. There's also a slightly irritating detail regarding horizontal scroll position. When the cursor is at the beginning of a buffer (as it is initially when opening an existing source file) and you drag the bottom-right corner horizontally (either to the left or to the right), the window scrolls horizontally a tiny bit. 4. I'd like editor windows to have exactly the same size and position when I reopen them. This is almost true, but if the window is as tall as the screen (in my case 1050 pixels minus the menubar) it leaves a small gap above and below the window, the next time I open it. 5. It would be nice if the Apropos window could have two text input areas (as in MCL). It's quite often that I remember two separate fractional parts of a symbol name, but not the exact order. 6. The symbol column of the search result area of the Apropos window is a bit narrow. I find myself dragging the separator to the right everytime I restart CCL. I would be nice if this could be remembered between sessions. Best Regards, Kristian Bredin From kristianbredin at gmail.com Thu May 21 06:29:37 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Thu, 21 May 2009 15:29:37 +0200 Subject: [Openmcl-devel] A few minor requests for the IDE In-Reply-To: References: Message-ID: Hi again! Sorry, just to make things clear: I'm using 1.3-dev-r12100M-trunk (DarwinPPC32) Kristian 21 maj 2009 kl. 15.23 skrev Kristian Bredin: > Hi! > > I have a few minor requests for the ongoing development (and > tweaking) of the IDE. > > > 1. I'd like to be able to Command-Option-click on a function name, > and then be brought to the definition (as in MCL). Option-. works, > but I prefer the click version. The cursor should preferably not > turn into a crosshair either, but rather remain as it is (= a > vertical bar). > > 2. I'd like the text in an editor window to stay in the same > scrolling position when I alter the size of the window. This does > work when the scrollbar is at the top, but I'd also like this to be > true when the scrollbar is in other positions. This typically > happens when I go to a definition via 1. above. The editor window > is usually quite small (if I haven't opened it before) and the > enclosing parens of the sexp is hilighted. Then I move the window > to the top and drag the bottom-right corner to resize it. When I > release the mouse, the sexp pops to a new position. I suspect that > this is a feature, but I'd prefer it to be as I write in the first > sentence of this paragraph. > > 3. There's also a slightly irritating detail regarding horizontal > scroll position. When the cursor is at the beginning of a buffer > (as it is initially when opening an existing source file) and you > drag the bottom-right corner horizontally (either to the left or to > the right), the window scrolls horizontally a tiny bit. > > 4. I'd like editor windows to have exactly the same size and > position when I reopen them. This is almost true, but if the window > is as tall as the screen (in my case 1050 pixels minus the menubar) > it leaves a small gap above and below the window, the next time I > open it. > > 5. It would be nice if the Apropos window could have two text input > areas (as in MCL). It's quite often that I remember two separate > fractional parts of a symbol name, but not the exact order. > > 6. The symbol column of the search result area of the Apropos > window is a bit narrow. I find myself dragging the separator to the > right everytime I restart CCL. I would be nice if this could be > remembered between sessions. > > > Best Regards, > Kristian Bredin From plkrueger at comcast.net Thu May 21 07:55:05 2009 From: plkrueger at comcast.net (Paul Krueger) Date: Thu, 21 May 2009 09:55:05 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A144690.7050708@itasoftware.com> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> <4A144690.7050708@itasoftware.com> Message-ID: You can't emphasize these points enough. GPGPU technology has its place, but it's not perfect for everything. If you have an application where data can be partitioned up neatly and distributed to separate processing elements which tend to do the same limited things over and over (FFT's are a good example), then GPGPU's may be appropriate (as are FPGA's for similar reasons, although there are certainly other factors there). If you have an application where each processing thread may dynamically determine that it needs data from an arbitrary location within a very large block of memory or needs to do frequent updates within large data blocks in arbitrary ways, then GPGPU's are not appropriate because the communication and synchronization costs will typically kill you. That's especially true on any larger distributed memory architecture, but even on smaller systems you might overwhelm the memory subsystem. Many of the sorts of AI, graph, and intelligent applications that I am personally more interested in fall into the second category, so GPGPU's will likely not be of much help. Paul On May 20, 2009, at 1:06 PM, Dan Weinreb wrote: > The instruction set is very restricted, and the communication > paths aren't there, as you suggested. GPGPU is especially > good for highly compute-intensive operations over not > all that much data. An FFT is an obvious example but > there are many, many good examples. (Not that I'm an > expert, but I do know that much.) > > There are CUDA-compatible devices that don't even > have a video connection, i.e. for GPGPU only. > The NVidia Tesla, called a "computing processor" > (weird name). 240 cores per board, and you can > chain together four of them. > > (My officemates are getting this info and telling to > me faster than I can type it in. Thanks, Andrew > and Scott.) > > -- Dan > > Jeremy Jones wrote: >> >> On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro >> wrote: >> >>> tomshardware.com ran this a couple of days ago: >>> >>> >>> >>> It's a summary of real-world results from apps using Nvidia's CUDA. >>> For certain things, like video encoding, they're seeing a 4x speedup >>> using the GPU over using the CPU. In addition, when they use the >>> GPU, >>> it leaves the CPU free for other tasks. >>> >> >> Why don't we just throw out the main CPU and fill our computers with >> graphics cards? (Once CCL is ported to GPUs of course) >> >> Seriously though, what does a CPU have that a GPU doesn't, besides a >> different instruction set? More memory? Better i/o? Is the GPU >> instruction set too specialized? I bet the answer is mainly >> software, >> like OSes and device drivers. I remember in the old days it was >> common to have a separate processor to handle i/o. Maybe that's what >> the main CPU should be relegated to. OTOH, if the software is good >> enough, it should just be distributed to whatever computing resources >> are appropriate and available. Just thinking out loud. >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From n2kra at yahoo.com Thu May 21 08:05:08 2009 From: n2kra at yahoo.com (n2kra) Date: Thu, 21 May 2009 15:05:08 +0000 (UTC) Subject: [Openmcl-devel] Mac 1 user perms Was: 'Check for updates' in the IDE dies References: <3240766D-62F1-4D59-B4EA-CFE952F98B41@mcaleely.com> Message-ID: John McAleely mcaleely.com> writes: > All, > > I recently pulled down trunk, rebuilt it and then used (require :cocoa- I started from x8632 v1.3, (first Intel mini Core, not Core2) But, installed as another user. When I went to go update, as a different user, it failed. ls -ld /Applications/ccl drwxr-xr-x@ 25 admin I thought about chmod g+w and chgrp, or o+w, But then wasn't sure what would get reverted by svn (/usr/bin/svn on 10.5) From dlw at itasoftware.com Thu May 21 08:55:16 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Thu, 21 May 2009 11:55:16 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> Message-ID: <4A157964.3030009@itasoftware.com> Justin, Justin Grant wrote: > > That being said, I really do like some of the features that I've seen > in Clojure (speaking from actual experience using Clojure and CL). > Forcing immutable data structures on users to simplify the language > implementation issues I would say that the immutable data structure make the language implementation more difficult, not easier. The point is for the language to make things easier for the programmer, by taking on hard jobs (such as efficient GC, optimization of generated code, etc). > or to make concurrent programming 'easier' I don't see the reason for the quotation marks around "easier". Here at ITA, we had a big debate about whether each Lisp process should have multiple request-handling threads, or each just one. Many pros and cons were identified. But one of the major points made (by some extremely experienced programmers) is that using concurrent threads was much too dangerous. In a complex system that uses shared mutable data structures, you need to get the concurrency control absolutely right. For example, we might have each Lisp process maintain some kind of cache. Rather than having N copies of the cache, one for each thread, we might want to save both memory (only one copy) and time (fewer fetches) by sharing the cache between threads. Other things would be shared as well. It also hurts that Common Lisp does not define thread-safety on various operations, since Common Lisp's spec is written as if there were only ever one thread. This is one of the main reasons we decided to create a whole Lisp process for each request-handling thread. In contrast, database management systems do NOT get into trouble when applications use concurrency. This is because their concurrency control is based on a transaction model. True ACID transactions are very easy to think about and reason about. It is much more easy to "prove" correctness. (By "prove", I mean "convince yourself for sure that it works".) We know now that the wonderful concept of transactions can be adopted from the DBMS world into the programming language world. I consider this a truly major breakthrough in the progress of modern computer language technology. Of course, not every language will find this appropriate, but it's quite impressive how many of the new languages that are currently being created have adopted the same paradigm: mostly use immutable objects and also provide transactions. Given the choice of being "forced" to use this to do concurrent programming, versus being given the "power" to do any old kind of locking I want, I'll gladly take the former, just as I am happy to give up the ability to write my own malloc, and I am happy to pay the cost of having my array bounds checked automatically. > is neither of them. The one thing I would change in Clojure is this > very thing. Even Haskell has it's monads You can do monads in Clojure. Monad in Haskell are just a library, not part of the very heart of the language. It's a design pattern, and Clojure has all the fundamental power needed to implement that pattern. (There was discussion of this at the Int'l Lisp Conference. I am not quite familiar enough with this all to defend what I just said, but ask Ravi Nanatavi of Bluespec who writes actual product code in Haskell every day.) > and Lisp allows for functional and imperative styles to be mixed. Those words can be used in various ways, so I won't try to address this question at a direct level. But the greater points are: Clojure does give you a wide variety of ways to program. But if Clojure's "mostly immutable with transactions" paradigm does limit me, that's OK, particularly if the job at hand calls for close and relatively complex concurrency needs. That's not to say that Clojure is the Right Language for All Problems. Here at ITA, we do plenty of Java, and we use C/C++ in several places where it's the most appropriate tool for the job. > > There may be an important lesson here ... At the very least, I think discussing these issues can be enlightening and educational for all of us, including me of course. -- Dan > > ------------------------------------------------------------------------ > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielgackle at gmail.com Thu May 21 09:43:55 2009 From: danielgackle at gmail.com (Daniel Gackle) Date: Thu, 21 May 2009 10:43:55 -0600 Subject: [Openmcl-devel] =?iso-8859-7?q?Macro_named_=EB_won=27t_expand_in_?= =?iso-8859-7?q?Slime_REPL?= In-Reply-To: <20090521004539.N37996@abq.clozure.com> References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> <20090521004539.N37996@abq.clozure.com> Message-ID: <57952f8b0905210943y300c752br96716869de2a4190@mail.gmail.com> Thanks to everyone who responded. We fixed the problem by putting the following in .ccl-init.lisp: (setf ccl:*default-external-format* (ccl:make-external-format :character-encoding :utf-8)) I believe Gary's explanation was correct: "the lambda character [was] encoded in ... two bytes in a UTF-8-encoded file, but if the file was compiled with a default :EXTERNAL-FORMAT of :ISO-8859-1, a two-character symbol name would have been read and interned and defined as a macro. (That would have happened consistently, so calls to the macro in the file(s) would appear to work as expected.)" It's worth mentioning that *default-external-format* has to be set before starting Slime, which makes me think that Tobias' suggestion is a good idea: "Perhaps Slime should send the buffer's coding-system with each request, and we should pass that over to COMPILE-FILE." Thanks again, Daniel On Thu, May 21, 2009 at 2:47 AM, Gary Byers wrote: > What character encoding is Slime using to talk to the lisp ? > > If you do: > > SLIME-PROMPT> (defvar *string* "") > > where is a single #\u+03bb character, what do: > > SLIME-PROMPT> (length *string*) ; should be 1 > > and > > SLIME-PROMPT> (char-code (schar *string* 0)) ; should be #x3bb = 955. > > return ? > > If Slime thinks that the stream used to talk to CCL is UTF-8 encoded > and CCL thinks that it's encoded in ISO-8859-1, Slime would send two > bytes (#xce #xbb), which the lisp would interpret as two 8-bit > ISO-8859-1 character codes (for the characters > #\Latin_Capital_Letter_I_With_Circumflex and > #\Right-Pointing_Double_Angle_Quotation_Mark.) > > After starting to write this reply, I looked at your message in a mail > client that's more Unicode-aware than the one that I usually use. It > looked like the lisp had uppercased the lambda character at some point, > which suggests that the lisp and Slime agree on the character encoding. > > If the problem here isn't something more mundane (like the symbol whose > name is the LAMBDA character not being visible in the REPL's package), > I wonder if something similar happened when the file containing the > macro definition was compiled. E.g., the lambda character would be > encoded in those two bytes in a UTF-8-encoded file, but if the file was > compiled with a default :EXTERNAL-FORMAT of :ISO-8859-1, a two-character > symbol name would have been read and interned and defined as a macro. > (That would have happened consistently, so calls to the macro in the > file(s) would appear to work as expected.) > > If this or something like it turns out to be the problem, I vote that > the entire world stop using 8-bit character encodings and immediately > encode all existing and future files, web pages, email messages, etc. > in UTF-32 whose endianness matches whatever computer I'm using at the > moment. > > CCL's reader treats (almost) all non-ASCII characters as "constituents" > (characters that can form symbols) and this shouldn't be sensitive to > what kind of stream the characters are being read from. (The character > encoding of that stream affects the sequence of characters that the > reader sees, and this sounds like it may be a case where an encoding > was incorrectly specified.) > > On Thu, 21 May 2009, Daniel Gackle wrote: > > We defined a macro named ? (Greek lambda character, in case this email >> isn't >> Unicode-friendly) to expand into a lambda form, partly to save typing and >> partly to add a couple extra features our system needs. This works fine >> when >> you compile files, but not in a Slime REPL or when using the command >> slime-compile-defun. For example, >> >> (defun foo () >> (? (x) (1+ x))) >> >> works the way you'd expect if you compile the file it's in. But in the >> REPL >> bad things happen: >> >> (defun foo () >> (? (x) (1+ x))) >> ;Compiler warnings : >> ; In FOO: Undefined function ? >> ; In FOO: Undefined function X >> ; In FOO: Undeclared free variable X >> => FOO >> >> (foo) >> => Undefined function X called with arguments () . >> [Condition of type CCL::UNDEFINED-FUNCTION-CALL] >> >> (macroexpand '(? (x) (1+ x))) >> => (? (X) (1+ X)) >> >> And if you use slime-compile-defun on the (defun foo...) form, the >> following >> occurs: >> >> While compiling FOO : >> #1=(X) is not a symbol or lambda expression in the form (#1# (1+ X)) . >> [Condition of type CCL::COMPILE-TIME-PROGRAM-ERROR] >> >> I'm posting this here because none of the above errors happen in SBCL, so >> there would seem to be something specific about the combination of Slime >> and >> CCL that doesn't like this macro. Does anyone have any ideas or >> suggestions? >> >> > > Thank you, >> >> Daniel Gackle >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Thu May 21 10:27:56 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Thu, 21 May 2009 13:27:56 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> Message-ID: <4A158F1C.3090506@itasoftware.com> Justin Grant wrote: > > Haskell has many mutable data structures too It does? I didn't know that; I thought it didn't. (I'm only up to chapter 9 in "Real World Haskell".) > (as does Clojure, it's built on Java). In my previous mail, when I discussed Clojure, I wasn't including the "arbitrary calls into Java" part of Clojure. In fact, I'm looking forward to see how Clojure sews together its approach with the use of Java libraries. > > Memory-management is a completely different problem that requires a > different solution than does concurrent programming. Memory allocation > is always required by any program. Well, actually, the way that GPGPUs and DSM chips are programmed does not use malloc/free, as I understand it. It's just a question of the right tool for the job. > Who's to say that the user will always be writing concurrent programs ? Sure, I agree. On the other hand, soon nearly every personal computer (assuming that that continues to have a meaning!) will have multiple cores. In fact, we're pretty close to that now. Sometimes it's easy to keep cores busy simply because there are many background processes, but the number of cores continues to rise. I recently was shopping for a new desktop and found that there are consumer computers using the Intel i7 with 8 cores. So it seems not unreasonable to assume that there will be more and more need for languages that handle concurrency. As you say, not every job needs to worry about that kind of close concurrency; but more and more jobs are going to. At least, many people think that's what's coming. > 'Everything looking like a nail' and all that. > This problem exists at another level and is best handled by the > programmer. Sure it's nice to make such an assumption at a language > design level if you must but make it optional and in doing so allow > the programmer more power. There is always a tradeoff between giving an application, or a subsystem, more, or less, power. Here's a simple example. Our Lisp system at ITA has many configuration parameters. What we used to do (we have not quite gotten rid of this yet) is to create named configurations, which worked by having a file full of Lisp forms that was loaded. That's a lot of power; a config file could do anything doable from Lisp. But for many reasons, we've decided that a declarative form of configuration has a lot of advantages, and we now use structured configuration files, e.g. each line has a key, a colon, and a value (but a bit more complicated than that, JSON in some cases). We reduce the power, but now programs can interpret config files and do various useful operations on them. In my experience, I've seen this kind of architectural tradeoff come up over and over again. More power is not necessarily better; it depends on a lot of things. > > Clojure has intentionally ignored many approaches taken in CL (not a > judgment, just an observation). > Many choices were made because of Clojure's foundation (the JVM) and > this shows through when programming in the language beyond any trivial > examples. Customer approved platforms, existing investments and the > 'industry standard' all factored heavily in Clojure's design at some > cost to giving the user more power (it's all on the Clojure website). Yes, that's quite true. > This makes for Clojure being the 'industry standard' Lisp, for better > or worse. Clueless managers may end up praising it the way they did > Java after reading about it in some magazine. Well, I'm not sure that's very important. There are extremely good reasons to build a Lisp on top of a JVM, and additional extremely good reasons to expose that as part of the language definition. It's not what you'd do if you were designing a new language in a vacuum, but these days it's no longer realistic to do that. The ability to take advantage of the existing, and always improving, JIT compiler and garbage collector technology, the portability, and the ability to tie into the huge number of both general and highly specialized JVM libraries, has enormous practical value. The idea that we'd ever get enough firepower behind Lisp that we could replicate all of that is entirely impractical. I had been advocating this kind of approach for at least a year before I ever heard of Clojure! > > That's all fine, but another problem that Clojure faces is the > marriage of a language trying to be 'purely' functional on top of a > platform(including libraries) that will always be imperative. > Java was never just a language, it's always been a language, the jvm > and the libraries. > Clojure inherits the legacy of all this because of it's design. > The magnitude and scope of these problems is yet to be discovered by > the Java/Clojure community when they get into building real systems > and extending current systems on the JVM with existing libraries. I agree with all of that. Although there are an impressive number of users (given that it's so new and it's based on Lisp and so on) of Clojure, I agree with you that the issues you mention above have probably not been explored sufficiently that we can come to a very clear judgement about how it all works out or doesn't and what to do about it. > My bet is that you'll probably see lots of users effectively > programming in Java (but using s-exps) when they realize that using > the language with existing Java libs is a complete impedance mismatch. > You'll likely hear the more experienced Clojure users suggest wrapping > these problems up in macros or something. Who wants that job ? I guess I'm more optimistic than you are, but only time will tell. -- Dan > > Good luck ... > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Thu May 21 10:33:32 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Thu, 21 May 2009 13:33:32 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <9596318D-D232-4104-84F0-8C9D76A73C52@mac.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <9596318D-D232-4104-84F0-8C9D76A73C52@mac.com> Message-ID: <4A15906C.2080705@itasoftware.com> mikel evins wrote: > > Clojure and Common Lisp both do the same thing that Haskell does: they > take away certain facilities because their absence makes certain > solutions workable. > Indeed, and what's more, practical Common Lisp programmers are even more restrictive than that. For example, we rarely use "eval" and we very, very rarely write self-modifying code. You'd be surprised how many people out there, who have had a bit of exposure to Lisp but not any real exposure, don't know that, and assume that Lisp cannot be compiled, etc. > Concurrency is different from memory management in this respect only > because multiple cores have become cheap and widespread long after > large memories did. GC is a solution to the robustness and > productivity problems caused by manual memory management. STM is a > solution (one of several) to the robustness and productivity problems > caused by manual concurrency management. > Yes, exactly. > There are certainly many programs that don't involve a lot of > concurrency, but Moore's law is over, and chipmakers are giving us > more cores now instead of faster ones. Sure, some people will always > want to manage their threads manually, just as some people will always > want malloc and free. But some like GC, because it makes a bunch of > headaches go away, and the cost of giving up malloc and free goes down > all the time. As cores multiply, the same thing will happen for > facilities that do for concurrency what GC does for memory management. > In all fairness, there are some programs that are extremely easy to parallelize, and you hardly need any locks or transactions or anything. Our system at ITA just runs 8 Lisp processes on a 8-core machine, and none of those processes treats any of the other 7 differently than it treats the other members of the cluster running on separate boxes. But there are other programs that do want to use closely-coupled algorithms on multiple cores, and those are the ones we've been talking about. > > Jeremy suggested that someone could implement a Common Lisp designed > around Clojure's concurrency features. You said you hoped not; I don't > think you have anything to worry about. I don't think bolting > Clojure's concurrency features onto Common Lisp buys much. Clojure's > concurrency features work well because they're part of a package deal. > I think it's pretty hard to fit that package deal into Common Lisp. I > can imagine a Lisp other than Clojure that would fit it, but it > wouldn't be Common Lisp. > I agree completely. > - Dan > > --me > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From joswig at lisp.de Thu May 21 10:48:19 2009 From: joswig at lisp.de (Rainer Joswig) Date: Thu, 21 May 2009 19:48:19 +0200 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> <4A144690.7050708@itasoftware.com> Message-ID: <18BB6FBB-C6C2-4171-8F62-2C625D5B8499@lisp.de> Am 21.05.2009 um 16:55 schrieb Paul Krueger: > You can't emphasize these points enough. GPGPU technology has its > place, but it's not perfect for everything. If you have an > application where data can be partitioned up neatly and distributed > to separate processing elements which tend to do the same limited > things over and over (FFT's are a good example), then GPGPU's may be > appropriate (as are FPGA's for similar reasons, although there are > certainly other factors there). If you have an application where > each processing thread may dynamically determine that it needs data > from an arbitrary location within a very large block of memory or > needs to do frequent updates within large data blocks in arbitrary > ways, then GPGPU's are not appropriate because the communication and > synchronization costs will typically kill you. That's especially > true on any larger distributed memory architecture, but even on > smaller systems you might overwhelm the memory subsystem. Many of > the sorts of AI, graph, and intelligent applications that I am > personally more interested in fall into the second category, so > GPGPU's will likely not be of much help. The appeal of the GPU is that it has lots of computing elements (originally designed for 3d rendering tasks). The trend is that these computing elements are getting more flexible and numeric computations are getting more accurate. Now we are at a point where the first programming languages appear that will allow writing portable algorithms that are able to run on the GPU: CUDA, OpenCL, ... The typical applications the average user will see are about manipulating large amounts of multimedia data. Think using FinalCut Pro to render visual effects, to convert video formats etc. Think iPhoto/Aperture plugins that manipulate large 'raw' images (dust filters, sharpeners, ...). At the same time scientists working with such kind of data will find its uses, too. If you look back at the SIMD Connection Machine it was thought that there are graph applications that are able to run in parallel on such a machine. The graph was mapped to compute elements which could communicate efficiently with nearby elements. A somewhat typical application domain was also querying data collections. Spread those data collections across a huge number of compute elements and run MAP/ REDUCE operations. An outcome was the WAIS protocol and a document query engine running on the connection machine ( http://en.wikipedia.org/wiki/Wide_area_information_server ) For Lisp users it might be interesting to run numeric matrix operations in applications like Maxima on the GPU. Image understanding applications like Freedius ( http://www.ai.sri.com/project/FREEDIUS ) could benefit from it. But there it would be probably written in the C/ OpenCL side and used from Lisp via FFI. CAD applications, too. I could even imagine that a large Triple Store ( http://en.wikipedia.org/wiki/Triple_Store ) has algorithms in the query domain that could benefit from GPU / SIMD support. Also think about blackboards that have some dimensions as matrices mapped to the GPU (example of a blackboard system in Lisp: http://gbbopen.org/ ). As an example see this GBBOpen function: map-instances-on-space- instances http://gbbopen.org/hyperdoc/ref-map-instances-on-space-instances.html ' Apply a function once to each unit instance on space instances, optionally selected by a retrieval pattern. ' Then see FIND-INSTANCES: http://gbbopen.org/hyperdoc/ref-find-instances.html I could imagine that SOME uses of these function could be speed up a lot by running in parallel on a GPU with, say, 256 compute elements. But that is just speculation on my side. It really depends if users really have such application problems and they can be mapped to GPUs. Regards, Rainer Joswig > > Paul > > On May 20, 2009, at 1:06 PM, Dan Weinreb wrote: > >> The instruction set is very restricted, and the communication >> paths aren't there, as you suggested. GPGPU is especially >> good for highly compute-intensive operations over not >> all that much data. An FFT is an obvious example but >> there are many, many good examples. (Not that I'm an >> expert, but I do know that much.) >> >> There are CUDA-compatible devices that don't even >> have a video connection, i.e. for GPGPU only. >> The NVidia Tesla, called a "computing processor" >> (weird name). 240 cores per board, and you can >> chain together four of them. >> >> (My officemates are getting this info and telling to >> me faster than I can type it in. Thanks, Andrew >> and Scott.) >> >> -- Dan >> >> Jeremy Jones wrote: >>> >>> On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro >>> wrote: >>> >>>> tomshardware.com ran this a couple of days ago: >>>> >>>> >>>> >>>> It's a summary of real-world results from apps using Nvidia's CUDA. >>>> For certain things, like video encoding, they're seeing a 4x >>>> speedup >>>> using the GPU over using the CPU. In addition, when they use the >>>> GPU, >>>> it leaves the CPU free for other tasks. >>>> >>> >>> Why don't we just throw out the main CPU and fill our computers with >>> graphics cards? (Once CCL is ported to GPUs of course) >>> >>> Seriously though, what does a CPU have that a GPU doesn't, besides a >>> different instruction set? More memory? Better i/o? Is the GPU >>> instruction set too specialized? I bet the answer is mainly >>> software, >>> like OSes and device drivers. I remember in the old days it was >>> common to have a separate processor to handle i/o. Maybe that's >>> what >>> the main CPU should be relegated to. OTOH, if the software is good >>> enough, it should just be distributed to whatever computing >>> resources >>> are appropriate and available. Just thinking out loud. >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgrant at imagine27.com Thu May 21 11:48:11 2009 From: jgrant at imagine27.com (Justin Grant) Date: Thu, 21 May 2009 11:48:11 -0700 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A158F1C.3090506@itasoftware.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <4A158F1C.3090506@itasoftware.com> Message-ID: <561d14600905211148l4cfbe8e7hfb7569054367ceb0@mail.gmail.com> Thanks for the responses Dan, Mikel : > > Haskell has many mutable data structures too > > It does? I didn't know that; I thought it didn't. (I'm only up > to chapter 9 in "Real World Haskell".) > You're ahead of me in RWH but what a great read hey ? > Who's to say that the user will always be writing concurrent programs ? > > Sure, I agree. > > On the other hand, soon nearly every personal computer (assuming > that that continues to have a meaning!) will have multiple cores. > In fact, we're pretty close to that now. Sometimes it's easy > to keep cores busy simply because there are many background > processes, but the number of cores continues to rise. I recently > was shopping for a new desktop and found that there are > consumer computers using the Intel i7 with 8 cores. So > it seems not unreasonable to assume that there will be more > and more need for languages that handle concurrency. > As you say, not every job needs to worry about that kind > of close concurrency; but more and more jobs are going > to. At least, many people think that's what's coming. > I agree that this is coming (and are already here to a certain degree). I'd love to get an 8 or 16 way machine under my desk ! Haskell already seems to do an awesome job of utilizing all cores in a machine or allowing the programmer to configure explicitly how the cores will be used (affinity etc.). Annotating code for concurrent behaviour is fairly easy in Haskell too : http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core Haskell is also flexible, there are a few options available for concurrent programming (including software transactional memory) : http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/26#no-headaches > > This makes for Clojure being the 'industry standard' Lisp, for better or > worse. Clueless managers may end up praising it the way they did Java after > reading about it in some magazine. > > Well, I'm not sure that's very important. There are extremely > good reasons to build a Lisp on top of a JVM, and additional > extremely good reasons to expose that as part of the language > definition. It's not what you'd do if you were designing a > new language in a vacuum, but these days it's no longer > realistic to do that. The ability to take advantage of the existing, > and always improving, JIT compiler and garbage collector > technology, the portability, and the ability to tie into the > huge number of both general and highly specialized > JVM libraries, has enormous practical value. The idea > that we'd ever get enough firepower behind Lisp that > we could replicate all of that is entirely impractical. > I had been advocating this kind of approach for at > least a year before I ever heard of Clojure! > I agree that it's important to build a Lisp on top of a JVM in spite of the potential issues that I mention. I'm a fan of the JVM too, not as much the language Java or some of it's libraries but hey "worse is better" and I use those when necessary. Pragmatism often overrides my desire to write beautiful code in a more beautiful language. For all my playing devil's advocate regarding Clojure I really do appreciate all the work that's gone into it. It's one of the best Lisp's on the JVM to date. I alternate between thinking I could use Clojure for a few years happily to actually being turned off by some of it's design, not to mention the issue of multiple layers of types which the user has to juggle in their heads (Java types vs. Clojure types etc.) which I believe Mikel has pointed out elsewhere. I worked on a project over a year ago where we implemented a prototype(very solid actually) search server(in Clojure) that used the Lucene Java libs. It was interesting because this prototype made use of the concurrent features of Clojure and every step of the way we were benchmarking the performance so that we could gauge just how scalable the service could be. We wanted to use all cores in our server. This what at a time before Clojure was really very popular and even now I have not heard of anyone else that's built something like this (they may have). We also built a similar prototype in CL and in C. The C version obviously took a very long time to build compared with the CL and Clojure versions. It also was more difficult to make changes to. The interop in Clojure with the Java libs felt really clumsy at times and the language itself seemed to get in the way in places. The Clojure version was comparable to CL in performance and lines of code. The end result though was that Clojure was rock solid in performance and scaled very well for our needs. In the end we didn't see any compelling reason to choose Clojure over CL, in fact CL had more power to offer in the language, so we stuck with it. We also got bored(didn't see the point) with mapping all the commonly known names in CL to their Clojure equivalents. I may just make the source code for the Clojure version available at some point. I'll need to check and see if that's ok. -Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From corkill at cs.umass.edu Thu May 21 11:49:03 2009 From: corkill at cs.umass.edu (Dan Corkill) Date: Thu, 21 May 2009 14:49:03 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <18BB6FBB-C6C2-4171-8F62-2C625D5B8499@lisp.de> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> <4A144690.7050708@itasoftware.com> <18BB6FBB-C6C2-4171-8F62-2C625D5B8499@lisp.de> Message-ID: Ranier wrote: > Also think about blackboards that have some dimensions as matrices > mapped to the GPU (example of a blackboard system in Lisp: http://gbbopen.org/ > ). > > As an example see this GBBopen function: map-instances-on-space- > instances > > http://gbbopen.org/hyperdoc/ref-map-instances-on-space- > instances.html > > ' Apply a function once to each unit instance on space instances, > optionally selected by a retrieval pattern. ' > > Then see FIND-INSTANCES: http://gbbopen.org/hyperdoc/ref-find-instances.html > > I could imagine that SOME uses of these function could be speed up a > lot by running in parallel on a GPU with, say, 256 compute elements. Indeed. Beyond nearly uncoupled large-grained computations (such as DanW has been describing) and obviously vectorize-able computations, providing application-specific higher order operators that are implemented to take advantage of these computing elements will become the norm. (An CL is so very good at providing application-specific language constructs!) As for parallel/distributed AI blackboard systems, I'll shamelessly plug my old book chapter as a good read: Design Alternatives for Parallel and Distributed Blackboard Systems, Daniel D. Corkill. In V. Jagannathan, Rajendra Dodhiawala, and Lawrence S. Baum, editors, Blackboard Architectures and Applications, pages 99-136. Academic Press, 1989. which is on-line at http://dancorkill.home.comcast.net/~dancorkill/pubs/parallel-distributed-chapter.pdf An important take away from this AI work in the late 80s is that using parallelism to perform concurrent, speculative search was less advantageous than using finer-grained parallelism to make the individual steps faster. This surprised some, but in hindsight it seems obvious that obtaining information to refine/invalidate search threads sooner (by having faster operators) would win over a less- informed shotgun search. It was fairly easy to write large-grained loosely coupled parallel programs and it was also fairly easy to write more fine-grained parallel application-specific operators. Writing general parallel programs that worked somewhere between these two extremes was where things became much harder. With parallel blackboard systems, using parallelism to make individual knowledge-source (KS) executions faster was always preferable to running multiple KS executions concurrently. From dlw at itasoftware.com Thu May 21 12:38:04 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Thu, 21 May 2009 15:38:04 -0400 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <561d14600905211148l4cfbe8e7hfb7569054367ceb0@mail.gmail.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <4A158F1C.3090506@itasoftware.com> <561d14600905211148l4cfbe8e7hfb7569054367ceb0@mail.gmail.com> Message-ID: <4A15AD9C.9050506@itasoftware.com> Justin Grant wrote: > Thanks for the responses Dan, Mikel : > >> >> Haskell has many mutable data structures too > It does? I didn't know that; I thought it didn't. (I'm only up > to chapter 9 in "Real World Haskell".) > > > You're ahead of me in RWH but what a great read hey ? Yes! If anyone wants to learn Haskell, I strongly recommend this book. > > >> Who's to say that the user will always be writing concurrent >> programs ? > Sure, I agree. > > On the other hand, soon nearly every personal computer (assuming > that that continues to have a meaning!) will have multiple cores. > In fact, we're pretty close to that now. Sometimes it's easy > to keep cores busy simply because there are many background > processes, but the number of cores continues to rise. I recently > was shopping for a new desktop and found that there are > consumer computers using the Intel i7 with 8 cores. So > it seems not unreasonable to assume that there will be more > and more need for languages that handle concurrency. > As you say, not every job needs to worry about that kind > of close concurrency; but more and more jobs are going > to. At least, many people think that's what's coming. > > > I agree that this is coming (and are already here to a certain degree). > I'd love to get an 8 or 16 way machine under my desk ! > > > I agree that it's important to build a Lisp on top of a JVM in spite > of the potential issues that I mention. > I'm a fan of the JVM too, not as much the language Java or some of > it's libraries but hey "worse is better" and I use those when > necessary. Pragmatism often overrides my desire to write beautiful > code in a more beautiful language. There is work going to to improve the JVM for non-Java languages, especially languages with dynamic typing. There was a "JVM summit" for various people implementing non-Java languages on the JVM. Rich says that real tail-calling is something everyone wants. (I don't know if we'll ever get full Scheme call/cc etc.) > > For all my playing devil's advocate regarding Clojure I really do > appreciate all the work that's gone into it. > It's one of the best Lisp's on the JVM to date. Has anyone here tried out ABCL (Armed Bear Common Lisp)? It runs on the JVM and is supposed to be Common Lisp. > > > I worked on a project over a year ago where That's very interesting! -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From heller at common-lisp.net Thu May 21 12:26:34 2009 From: heller at common-lisp.net (Helmut Eller) Date: Thu, 21 May 2009 21:26:34 +0200 Subject: [Openmcl-devel] =?iso-8859-1?q?Macro_named_=BB_won=27t_expand_in_?= =?iso-8859-1?q?Slime_REPL?= References: <57952f8b0905202344p4146329dq61a1fb7e7797b1ac@mail.gmail.com> <20090521004539.N37996@abq.clozure.com> <87fxeyohtd.fsf@freebits.de> Message-ID: * Tobias C. Rittweiler [2009-05-21 12:45+0200] writes: >> If Slime thinks that the stream used to talk to CCL is UTF-8 encoded >> and CCL thinks that it's encoded in ISO-8859-1, ... > > The problem is not that the network stream is in the wrong encoding > because the encoding, usually, comes from Emacs. That's also the reason > that it'll work when you type in everything at the REPL. > > I think, the problem is that the file is encoded in utf8, but an > :EXTERNAL-FORMAT of :DEFAULT in COMPILE-FILE is not utf8 in CCL as far > as I can see. (In SBCL :DEFAULT is utf8 if unicode-enabled.) > > Perhaps Slime should send the buffer's coding-system with each request, > and we should pass that over to COMPILE-FILE. > > Helmut, are you reading this list? Yep, I'm reading. Yes, in the regular setup Emacs tells CCL which encoding to use for the network stream. The default is ISO-8859-1 and Emacs should bark if the user tries to transmit a character that is not encodable. I guess that Daniel Gackle changed the encoding to utf-8 by setting slime-net-coding-system and that the network encoding is alright for him. slime-compile-defun (C-c C-c) writes a string to a temporary file and calls COMPILE-FILE on it. We use the default encoding for the tempfile but we can use utf8 just to be save. We don't need to use the buffer's coding-system because we know the "correct" content of the string and are sure that WRITE-FILE and COMPILE-FILE use the same encoding. slime-compile-file (C-c C-k) looks for Emacs-style -*- coding: ... -*- variables in the file and uses that as argument to COMPILE-FILE. If the file has no such marker we fall back the :default external-format. Well, at least that's the theory. Until a few days ago the CCL SWANK backend always used the default encoding but I suspect Daniel didn't use -*- ... -*- markers anyway. SLIME could use the buffer-coding-system in this case, but I think it's stylisticly preferable to mention the encoding in the file than to rely on Emacs. If the encoding is written in the file, ASDF and similar tools have a fair chance to pick it up without the need of Emacs. The best and simplest solution is to configure Emacs and CCL so that both use the same default encoding. I think we should encourage that instead of making it easier to use strange configurations. SLIME could compare the default encodings and issue a warning if different. That could be done at startup or when compiling a file (or ASDF system). Helmut. From mevins at mac.com Thu May 21 14:16:58 2009 From: mevins at mac.com (mikel evins) Date: Thu, 21 May 2009 16:16:58 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A15AD9C.9050506@itasoftware.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <4A158F1C.3090506@itasoftware.com> <561d14600905211148l4cfbe8e7hfb7569054367ceb0@mail.gmail.com> <4A15AD9C.9050506@itasoftware.com> Message-ID: <1ADE5EF9-C31B-4797-8B16-5B62B7C62991@mac.com> On May 21, 2009, at 2:38 PM, Dan Weinreb wrote: > > > Justin Grant wrote: >> >> Thanks for the responses Dan, Mikel : >>> >>> Haskell has many mutable data structures too >> It does? I didn't know that; I thought it didn't. (I'm only up >> to chapter 9 in "Real World Haskell".) >> >> You're ahead of me in RWH but what a great read hey ? > Yes! If anyone wants to learn Haskell, I strongly > recommend this book. I guess I should say that there are some valid criticisms of it, in that in several places it glosses over some details about its examples where you'd really like them to explain more. "real world" and "practical" treatments of programming topics have to strike the right balance between giving enough information to make sense of the examples, and being parsimonious enough that the reader's eyes don't glaze over, and the book doesn't break the table you lay it on. RWH maybe errs on the side of parsimony. That said, it's still good. Two other introductions I'd recommend are "Learn You A Haskell For Great Good!" http://learnyouahaskell.com/chapters and "Haskell For C Programmers": http://www.haskell.org/~pairwise/intro/intro.html >> >> For all my playing devil's advocate regarding Clojure I really do >> appreciate all the work that's gone into it. >> It's one of the best Lisp's on the JVM to date. > Has anyone here tried out ABCL (Armed Bear Common Lisp)? It runs > on the JVM and is supposed to be Common Lisp. I used it a good bit a couple of years ago. It's not bad, but at the time I ended up switching to Scala after a while, despite liking Lisp better, because it was just easier to get god results with Scala. I think it's easier to get good results with Clojure than with Scala, and more fun, too. More Joy is Good. --me From ralex at cs.colorado.edu Thu May 21 14:35:27 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Thu, 21 May 2009 15:35:27 -0600 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> <4A144690.7050708@itasoftware.com> Message-ID: <49F58547-2C4A-4EE9-BBAB-304E4407CA02@cs.colorado.edu> In some cases you can apply the antiobjects idea to find a completely different solution that WILL work nicely with GPGPU frameworks. Say, if you do pathfinding then A* is usually the way to go. Because of the problems you mentioned A* will not work well with CPUs, i.e., A* is neither easily parallelizable and nor incremental. Collaborative Diffusion solves the same problem in a completely different way that is parallelizable and incremental. In essence you are running some kind of cellular automata computing diffusion equations. I think there would be many more applications like this. Alex On May 21, 2009, at 8:55 AM, Paul Krueger wrote: > You can't emphasize these points enough. GPGPU technology has its > place, but it's not perfect for everything. If you have an > application where data can be partitioned up neatly and distributed > to separate processing elements which tend to do the same limited > things over and over (FFT's are a good example), then GPGPU's may be > appropriate (as are FPGA's for similar reasons, although there are > certainly other factors there). If you have an application where > each processing thread may dynamically determine that it needs data > from an arbitrary location within a very large block of memory or > needs to do frequent updates within large data blocks in arbitrary > ways, then GPGPU's are not appropriate because the communication and > synchronization costs will typically kill you. That's especially > true on any larger distributed memory architecture, but even on > smaller systems you might overwhelm the memory subsystem. Many of > the sorts of AI, graph, and intelligent applications that I am > personally more interested in fall into the second category, so > GPGPU's will likely not be of much help. > > Paul > > On May 20, 2009, at 1:06 PM, Dan Weinreb wrote: > >> The instruction set is very restricted, and the communication >> paths aren't there, as you suggested. GPGPU is especially >> good for highly compute-intensive operations over not >> all that much data. An FFT is an obvious example but >> there are many, many good examples. (Not that I'm an >> expert, but I do know that much.) >> >> There are CUDA-compatible devices that don't even >> have a video connection, i.e. for GPGPU only. >> The NVidia Tesla, called a "computing processor" >> (weird name). 240 cores per board, and you can >> chain together four of them. >> >> (My officemates are getting this info and telling to >> me faster than I can type it in. Thanks, Andrew >> and Scott.) >> >> -- Dan >> >> Jeremy Jones wrote: >>> >>> On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro >>> wrote: >>> >>>> tomshardware.com ran this a couple of days ago: >>>> >>>> >>>> >>>> It's a summary of real-world results from apps using Nvidia's CUDA. >>>> For certain things, like video encoding, they're seeing a 4x >>>> speedup >>>> using the GPU over using the CPU. In addition, when they use the >>>> GPU, >>>> it leaves the CPU free for other tasks. >>>> >>> >>> Why don't we just throw out the main CPU and fill our computers with >>> graphics cards? (Once CCL is ported to GPUs of course) >>> >>> Seriously though, what does a CPU have that a GPU doesn't, besides a >>> different instruction set? More memory? Better i/o? Is the GPU >>> instruction set too specialized? I bet the answer is mainly >>> software, >>> like OSes and device drivers. I remember in the old days it was >>> common to have a separate processor to handle i/o. Maybe that's >>> what >>> the main CPU should be relegated to. OTOH, if the software is good >>> enough, it should just be distributed to whatever computing >>> resources >>> are appropriate and available. Just thinking out loud. >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Thu May 21 14:40:56 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Thu, 21 May 2009 15:40:56 -0600 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A15906C.2080705@itasoftware.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <9596318D-D232-4104-84F0-8C9D76A73C52@mac.com> <4A15906C.2080705@itasoftware.com> Message-ID: <42F481C2-28AF-4D2F-8B60-8B69AE263624@cs.colorado.edu> Most of data parallelism, including web servers, fall into this nice but oddly named category of "embarrassingly parallel problems" On May 21, 2009, at 11:33 AM, Dan Weinreb wrote: > In all fairness, there are some programs that are extremely > easy to parallelize, and you hardly need any locks or > transactions or anything. Our system at ITA just runs > 8 Lisp processes on a 8-core machine, and none of > those processes treats any of the other 7 differently > than it treats the other members of the cluster running > on separate boxes. Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf From plkrueger at comcast.net Thu May 21 16:02:37 2009 From: plkrueger at comcast.net (Paul Krueger) Date: Thu, 21 May 2009 18:02:37 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <18BB6FBB-C6C2-4171-8F62-2C625D5B8499@lisp.de> References: <55AD5750-2830-4B96-8D66-77D0B0FA057D@clairvaux.org> <1242657940.3605.41.camel@hp64> <4486AB0D-5A2D-4711-80C8-A5B5D86F1B87@cs.colorado.edu> <7B388FAC-4AC2-4E2D-8BF1-F2C442DB8706@lisp.de> <4A144690.7050708@itasoftware.com> <18BB6FBB-C6C2-4171-8F62-2C625D5B8499@lisp.de> Message-ID: Sure, I agree with you that there are lots of interesting things you can do with GPUs; I hope I didn't leave the impression that I thought they were useless. Anything that can be decomposed into a large number of independent computations on small independent data sets is a good candidate for GPGPU processing. In the HPC world these are called "embarrassingly parallel applications". As you noted, anything for which a map/reduce paradigm works, is also a candidate for using lots of GPU's, as are things like rendering and large matrix computations. But there are interesting things that you can't do with GPUs too. They are fast because they are limited in certain ways. They don't typically have cache, so if you begin to need a lot of off-chip memory references (assuming such are even allowed by the chip; often some external control structure is required to move data in and out) then it idles while waiting for that data. They typically have a very limited ability to communicate externally. So if any sort of global synchronization is required, you would require some external service to do that for you. If you need a bunch of separate processes crawling around examining dynamically determined arbitrary locations within the same large data set (e.g. for certain kinds of searches), then current GPU configurations are not going to work well for you. [Note I just saw Alex R.'s response as I was preparing to send this and agree that alternative algorithms can *sometimes* be found to take better advantage of GPUs. This is an interesting research area, but I remain a sceptic that this will always work and in any event will likely require yet another computational language/paradigm that will need to be developed, propagated to the community, and learned by developers. I.E. GPUs are not an automatic immediate solution to every problem.] Even conventional multi-core processors can have problems with that sort of application although things like shared caches, large locally accessible memories, and fast inter-processor communication channels can help. That's why multi-threading chips (e.g Sun's Niagara and offspring and others; also see: http://en.wikipedia.org/wiki/Multithreading_(computer_hardware)) also have a place. Typically they can fire off a memory reference and switch to another thread in a single cycle so that they are rarely idle. Of course you need the right application to take advantage of a large number of threads as well as a memory subsystem that can keep up with that load. The connection machine was a very interesting creature and it would be fun to have an updated version of it around, but I wouldn't equate the connection machine to current incarnations of GPU's. The latter simply don't have the external communication and synchronization capabilities that connection machine processors had. A few years back I was talking with a developer of FPGA applications. He was perplexed by the fact that he wasn't seeing the sort of speedup in his application that he expected (relative to running on a conventional processor). In fact it was slower when run on the FPGAs. As I explained to him then, the cost of moving data into and out of the FPGA's was completely dominating the execution time. He was doing data transfers fairly frequently so the FPGA was more idle than it was busy while this was going on. The board that he was using coupled FPGA's to the processor in much the same way that GPUs are coupled to processors today, so I expect that some GPU developers will see similar effects with their applications. Just a cautionary note ... We live in interesting times. There is a wealth of technology around and new variations every day it seems. I expect to see new types of GPUs that are easier to use for more conventional processing and I expect to see conventional processors that are extended to add more multi-threading capabilities as Sun and others have done. We may see streaming processors too, who knows (ala the work done at Stanford: see http://en.wikipedia.org/wiki/Stream_processing). Each type has its proper place, but as near as I can tell no one of them is applicable to all problems. Perhaps the only thing I can predict with some confidence is that there will be an awful lot of software work required to support them. Regards, Paul On May 21, 2009, at 12:48 PM, Rainer Joswig wrote: > > Am 21.05.2009 um 16:55 schrieb Paul Krueger: > >> You can't emphasize these points enough. GPGPU technology has its >> place, but it's not perfect for everything. If you have an >> application where data can be partitioned up neatly and distributed >> to separate processing elements which tend to do the same limited >> things over and over (FFT's are a good example), then GPGPU's may >> be appropriate (as are FPGA's for similar reasons, although there >> are certainly other factors there). If you have an application >> where each processing thread may dynamically determine that it >> needs data from an arbitrary location within a very large block of >> memory or needs to do frequent updates within large data blocks in >> arbitrary ways, then GPGPU's are not appropriate because the >> communication and synchronization costs will typically kill you. >> That's especially true on any larger distributed memory >> architecture, but even on smaller systems you might overwhelm the >> memory subsystem. Many of the sorts of AI, graph, and intelligent >> applications that I am personally more interested in fall into the >> second category, so GPGPU's will likely not be of much help. > > The appeal of the GPU is that it has lots of computing elements > (originally designed for 3d rendering tasks). The trend is that > these computing elements are getting more flexible and numeric > computations are getting more accurate. Now we are at a point where > the first programming languages appear that will allow writing > portable algorithms that are able to run on the GPU: CUDA, OpenCL, ... > > The typical applications the average user will see are about > manipulating large amounts of multimedia data. Think using FinalCut > Pro to render visual effects, to convert video formats etc. Think > iPhoto/Aperture plugins that manipulate large 'raw' images (dust > filters, sharpeners, ...). At the same time scientists working with > such kind of data will find its uses, too. > > If you look back at the SIMD Connection Machine it was thought that > there are graph applications that are able to run in parallel on > such a machine. The graph was mapped to compute elements which could > communicate efficiently with nearby elements. A somewhat typical > application domain was also querying data collections. Spread those > data collections across a huge number of compute elements and run > MAP/REDUCE operations. An outcome was the WAIS protocol and a > document query engine running on the connection machine ( http://en.wikipedia.org/wiki/Wide_area_information_server > ) > > For Lisp users it might be interesting to run numeric matrix > operations in applications like Maxima on the GPU. Image > understanding applications like Freedius ( http://www.ai.sri.com/project/FREEDIUS > ) could benefit from it. But there it would be probably written in > the C/OpenCL side and used from Lisp via FFI. CAD applications, too. > I could even imagine that a large Triple Store ( http://en.wikipedia.org/wiki/Triple_Store > ) has algorithms in the query domain that could benefit from GPU / > SIMD support. Also think about blackboards that have some dimensions > as matrices mapped to the GPU (example of a blackboard system in > Lisp: http://gbbopen.org/ ). > > As an example see this GBBOpen function: map-instances-on-space- > instances > > http://gbbopen.org/hyperdoc/ref-map-instances-on-space- > instances.html > > ' Apply a function once to each unit instance on space instances, > optionally selected by a retrieval pattern. ' > > Then see FIND-INSTANCES: http://gbbopen.org/hyperdoc/ref-find-instances.html > > I could imagine that SOME uses of these function could be speed up a > lot by running in parallel on a GPU with, say, 256 compute elements. > > But that is just speculation on my side. It really depends if users > really have such application problems and they can be mapped to GPUs. > > Regards, > > Rainer Joswig > > >> >> Paul >> >> On May 20, 2009, at 1:06 PM, Dan Weinreb wrote: >> >>> The instruction set is very restricted, and the communication >>> paths aren't there, as you suggested. GPGPU is especially >>> good for highly compute-intensive operations over not >>> all that much data. An FFT is an obvious example but >>> there are many, many good examples. (Not that I'm an >>> expert, but I do know that much.) >>> >>> There are CUDA-compatible devices that don't even >>> have a video connection, i.e. for GPGPU only. >>> The NVidia Tesla, called a "computing processor" >>> (weird name). 240 cores per board, and you can >>> chain together four of them. >>> >>> (My officemates are getting this info and telling to >>> me faster than I can type it in. Thanks, Andrew >>> and Scott.) >>> >>> -- Dan >>> >>> Jeremy Jones wrote: >>>> >>>> On Wed, May 20, 2009 at 9:13 AM, Raffael Cavallaro >>>> wrote: >>>> >>>>> tomshardware.com ran this a couple of days ago: >>>>> >>>>> >>>>> >>>>> It's a summary of real-world results from apps using Nvidia's >>>>> CUDA. >>>>> For certain things, like video encoding, they're seeing a 4x >>>>> speedup >>>>> using the GPU over using the CPU. In addition, when they use the >>>>> GPU, >>>>> it leaves the CPU free for other tasks. >>>>> >>>> Why don't we just throw out the main CPU and fill our computers >>>> with >>>> graphics cards? (Once CCL is ported to GPUs of course) >>>> >>>> Seriously though, what does a CPU have that a GPU doesn't, >>>> besides a >>>> different instruction set? More memory? Better i/o? Is the GPU >>>> instruction set too specialized? I bet the answer is mainly >>>> software, >>>> like OSes and device drivers. I remember in the old days it was >>>> common to have a separate processor to handle i/o. Maybe that's >>>> what >>>> the main CPU should be relegated to. OTOH, if the software is good >>>> enough, it should just be distributed to whatever computing >>>> resources >>>> are appropriate and available. Just thinking out loud. >>>> _______________________________________________ >>>> Openmcl-devel mailing list >>>> Openmcl-devel at clozure.com >>>> http://clozure.com/mailman/listinfo/openmcl-devel >>>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > Rainer Joswig, Hamburg, Germany > http://lispm.dyndns.org/ > mailto:joswig at lisp.de > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rme at clozure.com Thu May 21 18:34:29 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 21 May 2009 21:34:29 -0400 Subject: [Openmcl-devel] bug reports and suggestions Message-ID: <20CD40B2-9B16-4E56-B202-85E4F49F1BE6@clozure.com> I encourage everyone to consider creating Trac tickets for bugs and feature suggestions. I know it's extra bother, but it's easy (at least for me) to lose track of issues reported or good suggestions made in mail, especially at times when there's greater than usual activity on the mailing list. If you don't have a Trac login, you'll need to register in order to create tickets. To register, go to http://trac.clozure.com/openmcl/ and click on the "Register" link. (It's on the top-right corner of the page, right under the "Search" button.) If you supply your email address, you'll be notified when tickets you originate or comment on are updated. There's no confirmation email process (for now, anyway). After filling out the registration form, just click the "Login" link to log in, and then click on "New Ticket". If you think something might warrant a ticket but aren't completely sure, please go ahead and create the ticket anyway. It's no big deal to resolve the ticket as "invalid" or "duplicate" or whatever. If you're willing to search the existing tickets for your bug or enhancement request before creating a new one, so much the better. Feel free to add comments onto existing tickets if you think that would be helpful. (A Trac tip: the timeline view at http://trac.clozure.com/openmcl/timeline is available as an RSS feed, if you want to the gory details of every commit. Scroll down to the very bottom of the page and you'll see an "RSS Feed" link.) From steve.nunez at illation.com.sg Thu May 21 23:14:55 2009 From: steve.nunez at illation.com.sg (Steve =?ISO-8859-1?B?TvrxZXo=?=) Date: Fri, 22 May 2009 16:14:55 +1000 Subject: [Openmcl-devel] CXML Message-ID: Greetings all, Can anyone confirm that 1.3 works with CXML? I?ve spent the better part of a day trying to get this to work, but no joy. It very well may be user error (it?s been some years since I was into lisp), but before tearing any more hair out want to make certain this is still working. Regards, - Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.nunez at illation.com.sg Thu May 21 23:46:49 2009 From: steve.nunez at illation.com.sg (Steve =?ISO-8859-1?B?TvrxZXo=?=) Date: Fri, 22 May 2009 16:46:49 +1000 Subject: [Openmcl-devel] CXML In-Reply-To: Message-ID: Following up to my own message, this is exactly what I?m getting. As you can see, asdf recognizes that it?s installed, but refuses to load it. ? (asdf-install:install 'cxml) Install where? 1) System-wide install: System in /usr/local/asdf-install/site-systems/ Files in /usr/local/asdf-install/site/ 2) Personal installation: System in /Users/nunez/.asdf-install-dir/systems/ Files in /Users/nunez/.asdf-install-dir/site/ 0) Abort installation. --> 2 ;;; ASDF-INSTALL: Downloading 223222 bytes from http://common-lisp.net/project/cxml/download/cxml.tar.gz to /Users/nunez/asdf-install-0.asdf-install-tmp ... ;;; ASDF-INSTALL: Installing CXML in /Users/nunez/.asdf-install-dir/site/, /Users/nunez/.asdf-install-dir/systems/ "ln -s \"/Users/nunez/.asdf-install-dir/site/cxml-2008-11-30/cxml.asd\" \"/Users/nunez/.asdf-install-dir/systems/cxml.asd\"" ;;; ASDF-INSTALL: Found system definition: /Users/nunez/.asdf-install-dir/site/cxml-2008-11-30/cxml.asd ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::CXML via ASDF. ; loading system definition from /Users/nunez/.asdf-install-dir/site/cxml-2008-11-30/cxml.asd into # > Error: :VERSION is an invalid initarg to INITIALIZE-INSTANCE for #. > Valid initargs: (:REQUIRES :PARENT :REQUIRED-BY). > While executing: CCL::CHECK-INITARGS, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > On 22/05/09 4:14 PM, "Steven N??ez" wrote: > Greetings all, > > Can anyone confirm that 1.3 works with CXML? I?ve spent the better part of a > day trying to get this to work, but no joy. It very well may be user error > (it?s been some years since I was into lisp), but before tearing any more hair > out want to make certain this is still working. > > Regards, > - Steve > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -- Level 31 6 Battery Road Singapore 049909 Phone: ?+65 6321 9115 Mobile: +65 9679 8360 http://illation.com.sg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.gif Type: image/gif Size: 945 bytes Desc: not available URL: From david at lichteblau.com Thu May 21 23:59:16 2009 From: david at lichteblau.com (David Lichteblau) Date: Fri, 22 May 2009 08:59:16 +0200 Subject: [Openmcl-devel] CXML In-Reply-To: References: Message-ID: <20090522065916.GF3321@radon> Quoting Steve N??ez (steve.nunez at illation.com.sg): > /Users/nunez/.asdf-install-dir/site/cxml-2008-11-30/cxml.asd into # "ASDF0"> > > Error: :VERSION is an invalid initarg to INITIALIZE-INSTANCE for > #. > > Valid initargs: (:REQUIRES :PARENT :REQUIRED-BY). > > While executing: CCL::CHECK-INITARGS, in process listener(1). > > Type :POP to abort, :R for a list of available restarts. > > Type :? for other options. This is a compatibility issue between CCL's version of ASDF, and a hack in cxml.asd that tries to make it work with asdf-install. The solution is to install cxml's dependency closure-common explicitly before installing cxml. Alternatively, don't use asdf-install in the first place (use clbuild or download cxml's dependencies manually). It would probably also work to grab a recent copy of ASDF from SBCL CVS or CCLAN CVS and drop it into tools/, but I haven't tested that. The answer to your original question is that CXML and its add-ons CXML-STP, closure-common, and Closure HTML should work on CCL 1.3. Its add-ons CXML-RNG, Plexippus XPath, and Xuriella XSLT don't work on CCL at this point. d. From steve.nunez at illation.com.sg Fri May 22 01:12:05 2009 From: steve.nunez at illation.com.sg (Steve =?ISO-8859-1?B?TvrxZXo=?=) Date: Fri, 22 May 2009 18:12:05 +1000 Subject: [Openmcl-devel] CXML In-Reply-To: <20090522065916.GF3321@radon> Message-ID: Thanks. That worked (explicitly loading closure-common first), however I'm experiencing trouble in running the first example of the QuickStart guide: (cxml:with-xml-output (cxml:make-octet-stream-sink test-sequence-file :indentation 2 :canonical nil) (cxml:with-element "foo" (cxml:attribute "xyz" "abc") (cxml:with-element "bar" (cxml:attribute "blub" "bla")) (cxml:text "Hi there."))) Produces an error: "value 60 is not of the expected type CHARACTER." I suspect this might be related to character encoding, as the backtrace (below) mentions two encodings, UTF-8 and ISO-8859-1. 0: ((:INTERNAL CCL::%XERR-DISP)) 1: (CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION #) 2: (CCL::%XERR-DISP 371959430) 3: (CCL::%PASCAL-FUNCTIONS% 2 371959430) 4: (CCL::%PRIVATE-IOBLOCK-WRITE-CHAR #S(CCL::FILE-IOBLOCK :STREAM # :UNTYI-CHAR NIL :INBUF ...) 60) 5: (WRITE-CHAR 1 #) 6: (# # #(60 ..) 7: (CCL::%CALL-NEXT-METHOD (NIL # . 5245624)) 8: (CCL::%%STANDARD-COMBINED-METHOD-DCODE (# ..))) 9: (WRITE-SEQUENCE #(60 63 120 109 108 32 ...) # :START 0 :END 93) 10: (# #S(RUNES::OCTET-STREAM-YSTREAM :ENCODING :UTF-8 :COLUMN 6 :IN-PTR ...)) 11: (CCL::%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE (NIL # . 5245673)) 12: (CCL::%%STANDARD-COMBINED-METHOD-DCODE ((#) NIL #) 5245673) 13: (CXML::INVOKE-WITH-XML-OUTPUT # #) 14: (GENERATE-TEST-SEQUENCE "banking.xml") 15: (CCL::CALL-CHECK-REGS GENERATE-TEST-SEQUENCE "banking.xml") The entire function is: (defun generate-test-sequence (file-name) (with-open-file (test-sequence-file file-name :direction :output :if-exists :supersede) (cxml:with-xml-output (cxml:make-octet-stream-sink test-sequence-file :indentation 2 :canonical nil) (cxml:with-element "foo" (cxml:attribute "xyz" "abc") (cxml:with-element "bar" (cxml:attribute "blub" "bla")) (cxml:text "Hi there."))))) Cheers, - SteveN On 22/05/09 4:59 PM, "David Lichteblau" wrote: > Quoting Steve N??ez (steve.nunez at illation.com.sg): >> /Users/nunez/.asdf-install-dir/site/cxml-2008-11-30/cxml.asd into #> "ASDF0"> >>> Error: :VERSION is an invalid initarg to INITIALIZE-INSTANCE for >> #. >>> Valid initargs: (:REQUIRES :PARENT :REQUIRED-BY). >>> While executing: CCL::CHECK-INITARGS, in process listener(1). >>> Type :POP to abort, :R for a list of available restarts. >>> Type :? for other options. > > This is a compatibility issue between CCL's version of ASDF, and a hack > in cxml.asd that tries to make it work with asdf-install. > > The solution is to install cxml's dependency closure-common explicitly > before installing cxml. > > Alternatively, don't use asdf-install in the first place (use clbuild or > download cxml's dependencies manually). > > It would probably also work to grab a recent copy of ASDF from SBCL CVS > or CCLAN CVS and drop it into tools/, but I haven't tested that. > > > The answer to your original question is that CXML and its add-ons > CXML-STP, closure-common, and Closure HTML should work on CCL 1.3. > > Its add-ons CXML-RNG, Plexippus XPath, and Xuriella XSLT don't work on > CCL at this point. > > > d. -- Level 31 6 Battery Road Singapore 049909 Phone: ?+65 6321 9115 Mobile: +65 9679 8360 http://illation.com.sg From david at lichteblau.com Fri May 22 01:27:47 2009 From: david at lichteblau.com (David Lichteblau) Date: Fri, 22 May 2009 10:27:47 +0200 Subject: [Openmcl-devel] CXML In-Reply-To: References: <20090522065916.GF3321@radon> Message-ID: <20090522082747.GG3321@radon> Hi Steve, Quoting Steve N??ez (steve.nunez at illation.com.sg): [...] > (defun generate-test-sequence (file-name) > (with-open-file (test-sequence-file file-name > :direction :output > :if-exists :supersede) > (cxml:with-xml-output (cxml:make-octet-stream-sink test-sequence-file Add :element-type '(unsigned-byte 8) to the WITH-OPEN-FILE to make it work with an octet stream sink. d. (I suggest taking further cxml questions to cxml-devel rather than openmcl-devel.) From kristianbredin at gmail.com Fri May 22 10:13:11 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Fri, 22 May 2009 19:13:11 +0200 Subject: [Openmcl-devel] bug reports and suggestions In-Reply-To: <20CD40B2-9B16-4E56-B202-85E4F49F1BE6@clozure.com> References: <20CD40B2-9B16-4E56-B202-85E4F49F1BE6@clozure.com> Message-ID: Point taken. :) Kristian 22 maj 2009 kl. 03.34 skrev R. Matthew Emerson: > I encourage everyone to consider creating Trac tickets for bugs and > feature suggestions. > > I know it's extra bother, but it's easy (at least for me) to lose > track of issues reported or good suggestions made in mail, especially > at times when there's greater than usual activity on the mailing list. > > If you don't have a Trac login, you'll need to register in order to > create tickets. To register, go to http://trac.clozure.com/openmcl/ > and click on the "Register" link. (It's on the top-right corner of > the page, right under the "Search" button.) If you supply your email > address, you'll be notified when tickets you originate or comment on > are updated. > > There's no confirmation email process (for now, anyway). After > filling out the registration form, just click the "Login" link to log > in, and then click on "New Ticket". > > If you think something might warrant a ticket but aren't completely > sure, please go ahead and create the ticket anyway. It's no big deal > to resolve the ticket as "invalid" or "duplicate" or whatever. If > you're willing to search the existing tickets for your bug or > enhancement request before creating a new one, so much the better. > Feel free to add comments onto existing tickets if you think that > would be helpful. > > (A Trac tip: the timeline view at http://trac.clozure.com/openmcl/ > timeline > is available as an RSS feed, if you want to the gory details of > every commit. Scroll down to the very bottom of the page and you'll > see an "RSS Feed" link.) > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ehuels at gmail.com Fri May 22 13:52:09 2009 From: ehuels at gmail.com (Erik Huelsmann) Date: Fri, 22 May 2009 22:52:09 +0200 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A15AD9C.9050506@itasoftware.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <4A158F1C.3090506@itasoftware.com> <561d14600905211148l4cfbe8e7hfb7569054367ceb0@mail.gmail.com> <4A15AD9C.9050506@itasoftware.com> Message-ID: > For all my playing devil's advocate regarding Clojure I really do appreciate > all the work that's gone into it. > It's one of the best Lisp's on the JVM to date. > > Has anyone here tried out ABCL (Armed Bear Common Lisp)?? It runs > on the JVM and is supposed to be Common Lisp. Yes, I did (Peter Graves invited me to take over it's maintenance last august, which I did). It works very well for me (I use it for a commercial desktop application; my users don't really know it's Lisp) and a number of others, years already for some. Recent work has improved it quite a bit: last October the Maxima test suite failed over 1400 tests (of ca 4500), now it only fails 75. The reduction in ANSI tests is less spectacular, but in the next release (0.15, to be released at the beginning of June) only 34 failures will have remained; about half of them related to the pretty printer. Hope that adds to the discussion. Bye, Erik. From ds26gte at yahoo.com Fri May 22 14:08:36 2009 From: ds26gte at yahoo.com (Dorai Sitaram) Date: Fri, 22 May 2009 14:08:36 -0700 (PDT) Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <4A15AD9C.9050506@itasoftware.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <4A158F1C.3090506@itasoftware.com> <561d14600905211148l4cfbe8e7hfb7569054367ceb0@mail.gmail.com> <4A15AD9C.9050506@itasoftware.com> Message-ID: <753353.37961.qm@web52103.mail.re2.yahoo.com> ________________________________ From: Dan Weinreb >Has anyone here tried out ABCL (Armed Bear Common Lisp)? It runs >on the JVM and is supposed to be Common Lisp. It's a conventional, no-surprises Common Lisp, very usable, about 6 to 8 times slower than SBCL on my smallish programs tex2page and club3. It might be much slower for larger applications. I didn't see much by way of documentation, so I don't know if offers any nifty stuff beyond Ansi CL. From mevins at mac.com Fri May 22 17:19:02 2009 From: mevins at mac.com (mikel evins) Date: Fri, 22 May 2009 19:19:02 -0500 Subject: [Openmcl-devel] Speed, compilers and multi-core processors In-Reply-To: <753353.37961.qm@web52103.mail.re2.yahoo.com> References: <9E8658DC-C6FD-4EAD-9BF4-2A261AFF9923@play.org> <561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com> <097AB21F-6C56-482B-9115-8618234F3ABC@mac.com> <561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com> <4A158F1C.3090506@itasoftware.com> <561d14600905211148l4cfbe8e7hfb7569054367ceb0@mail.gmail.com> <4A15AD9C.9050506@itasoftware.com> <753353.37961.qm@web52103.mail.re2.yahoo.com> Message-ID: <1CAA3FD0-6AB1-449A-BDDA-CB1A2C962974@mac.com> On May 22, 2009, at 4:08 PM, Dorai Sitaram wrote: > > > ________________________________ > From: Dan Weinreb > >> Has anyone here tried out ABCL (Armed Bear Common Lisp)? It runs >> on the JVM and is supposed to be Common Lisp. > > > It's a conventional, no-surprises Common Lisp, very usable, about 6 > to 8 times > slower than SBCL on my smallish programs tex2page and club3. It > might be much > slower for larger applications. I didn't see much by way of > documentation, so I > > don't know if offers any nifty stuff beyond Ansi CL. It's also possible that it would be faster for large apps, depending on how they're organized. The performance profile of the JVM tends to bias benchmarks results against short-running programs and in favor of long-running ones, especially when using it with the -server flag. --me From joswig at lisp.de Sat May 23 01:24:50 2009 From: joswig at lisp.de (Rainer Joswig) Date: Sat, 23 May 2009 10:24:50 +0200 Subject: [Openmcl-devel] CCL 1.3 IDE: DEFPACKAGE / IN-PACKAGE and loading a buffer Message-ID: Hi, CCL 1.3 when I create a new editor window and type some stuff, I can't use the menu item Lisp>Load Buffer . It is deactivated. I suspect that it really does not load the buffer, but the file associated with the buffer? Does it? Now I put the following into the buffer: --- (defpackage "FOO" (:use "CL")) (in-package "FOO") (defun foo () 'bar) --- Save the buffer to a file and now I'm using the 'Load Buffer' menu item. In the listener I get the following error. ? > Error: There is no package named "FOO" . > While executing: #, in process Listener(6). I find it a bit unfortunate that this is an error. It is quite common to have files where the package is defined on top and then used in the rest of the file. Loading the file with LOAD works fine, though. Regards, Rainer Joswig Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de From ralex at cs.colorado.edu Mon May 25 12:56:54 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Mon, 25 May 2009 13:56:54 -0600 Subject: [Openmcl-devel] World's "Fastest" Small Web Server Released, Based On LISP Message-ID: <0E045834-FB0D-414C-B7DC-F31839D387F3@cs.colorado.edu> but does it run in CCL? http://tech.slashdot.org/article.pl?sid=09/05/25/1553220&art_pos=4 Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgrant at imagine27.com Mon May 25 12:59:37 2009 From: jgrant at imagine27.com (Justin Grant) Date: Mon, 25 May 2009 12:59:37 -0700 Subject: [Openmcl-devel] World's "Fastest" Small Web Server Released, Based On LISP In-Reply-To: <0E045834-FB0D-414C-B7DC-F31839D387F3@cs.colorado.edu> References: <0E045834-FB0D-414C-B7DC-F31839D387F3@cs.colorado.edu> Message-ID: <4A1AF8A9.9050605@imagine27.com> Apparently it runs on SBCL and CCL. Alexander Repenning wrote: > but does it run in CCL? > > http://tech.slashdot.org/article.pl?sid=09/05/25/1553220&art_pos=4 > > > > Prof. Alexander Repenning > > > University of Colorado > > Computer Science Department > > Boulder, CO 80309-430 > > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stassats at gmail.com Mon May 25 13:01:51 2009 From: stassats at gmail.com (Stas Boukarev) Date: Tue, 26 May 2009 00:01:51 +0400 Subject: [Openmcl-devel] World's "Fastest" Small Web Server Released, Based On LISP In-Reply-To: <0E045834-FB0D-414C-B7DC-F31839D387F3@cs.colorado.edu> (Alexander Repenning's message of "Mon, 25 May 2009 13:56:54 -0600") References: <0E045834-FB0D-414C-B7DC-F31839D387F3@cs.colorado.edu> Message-ID: <87skitar4g.fsf@gmail.com> Alexander Repenning writes: > but does it run in CCL? > > http://tech.slashdot.org/article.pl?sid=09/05/25/1553220&art_pos=4 > You shoulde've visited the link in that article, which says that it does. -- With best regards, Stas. From wws at clozure.com Mon May 25 13:13:28 2009 From: wws at clozure.com (Bill St. Clair) Date: Mon, 25 May 2009 16:13:28 -0400 Subject: [Openmcl-devel] World's "Fastest" Small Web Server Released, Based On LISP In-Reply-To: <87skitar4g.fsf@gmail.com> References: <0E045834-FB0D-414C-B7DC-F31839D387F3@cs.colorado.edu> <87skitar4g.fsf@gmail.com> Message-ID: <8fbe874a0905251313q7131c62s12efc781e1cdacc9@mail.gmail.com> On Mon, May 25, 2009 at 4:01 PM, Stas Boukarev wrote: > Alexander Repenning writes: > >> but does it run in CCL? >> >> http://tech.slashdot.org/article.pl?sid=09/05/25/1553220&art_pos=4 >> > You shoulde've visited the link in that article, which says that it does. Unfortunately, it appears that his blog, which is advertised as an example, is slashdotted. Or just down. -Bill From sshenoy at gol.com Mon May 25 18:46:26 2009 From: sshenoy at gol.com (Sudhir Shenoy) Date: Tue, 26 May 2009 10:46:26 +0900 Subject: [Openmcl-devel] Type declaration question Message-ID: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> Can anyone tell me what the proper declaration for a 64 bit unsigned integer is? I was using "(declare ((unsigned-byte 64) foo))" which I am fairly sure worked prior to CCL 1.3 but now I get a compilation warning and the fasl is not generated. I checked the CLHS and there doesn't seem to be an upper bound on the number of bits in the unsigned-byte declaration. I have this in some low level i/o conversion (reading in a IEEE float value of 8 bytes and converting to a Lisp number) code where I use (ldb (byte 1 63) foo) to extract the sign-bit, for example. Is there a better way to do this? Thanks Sudhir From sshenoy at gol.com Mon May 25 19:03:39 2009 From: sshenoy at gol.com (Sudhir Shenoy) Date: Tue, 26 May 2009 11:03:39 +0900 Subject: [Openmcl-devel] Type declaration question In-Reply-To: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> Message-ID: <5CB1EAD5-E67A-4252-B6C5-B126971AE5BA@gol.com> Sorry for the noise --- I discovered that "(declare (type (unsigned- byte 64) foo))" works. But according to CLHS, just "type-specifier var" should work as well as "type type-specifier var". Is this a bug in CCL 1.3? Cheers Sudhir On May 26, 2009, at 10:46 AM, Sudhir Shenoy wrote: > Can anyone tell me what the proper declaration for a 64 bit unsigned > integer is? I was using "(declare ((unsigned-byte 64) foo))" which I > am fairly sure worked prior to CCL 1.3 but now I get a compilation > warning and the fasl is not generated. I checked the CLHS and there > doesn't seem to be an upper bound on the number of bits in the > unsigned-byte declaration. > > I have this in some low level i/o conversion (reading in a IEEE float > value of 8 bytes and converting to a Lisp number) code where I use > (ldb (byte 1 63) foo) to extract the sign-bit, for example. Is there a > better way to do this? > > Thanks > Sudhir From gb at clozure.com Mon May 25 19:20:30 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 25 May 2009 20:20:30 -0600 (MDT) Subject: [Openmcl-devel] Type declaration question In-Reply-To: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> Message-ID: <20090525195113.W72709@abq.clozure.com> "(DECLARE (TYPE (UNSIGNED-BYTE 64) FOO))" says that FOO is of type (UNSIGNED-BYTE 64) within the scope of that declaration. In some cases, the TYPE declaration specifier can be omitted; "(DECLARE (FIXNUM FOO)) is shorthand for "(DECLARE (TYPE FIXNUM FOO)". The spec may be a little unclear about which cases allow this shorthand; section 3.3.2 describes a declaration as being something whose CAR is a "declaration identifier", and the glossary defines a "declaration identifier" to be one of a predefined set of symbols or a symbol which specifies a type; it doesn't seem to allow compound type specifiers (like (UNSIGNED-BYTE 64)) to be used as declaration identifiers, though other passages in the spec suggest that they should be allowed here. (See ). I don't think that CCL has ever allowed compound type specifiers to be used as declaration identifiers. Prior to some changes that Gail made in the trunk a few weeks ago, it tended to quietly ignore declarations that it couldn't make sense of (and that would include cases where a compound type specifier was being used as shorthand for a TYPE declaration); a warning is now signaled in that case. On Tue, 26 May 2009, Sudhir Shenoy wrote: > Can anyone tell me what the proper declaration for a 64 bit unsigned > integer is? I was using "(declare ((unsigned-byte 64) foo))" which I > am fairly sure worked prior to CCL 1.3 but now I get a compilation > warning and the fasl is not generated. I checked the CLHS and there > doesn't seem to be an upper bound on the number of bits in the > unsigned-byte declaration. > > I have this in some low level i/o conversion (reading in a IEEE float > value of 8 bytes and converting to a Lisp number) code where I use > (ldb (byte 1 63) foo) to extract the sign-bit, for example. Is there a > better way to do this? > > Thanks > Sudhir > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From sshenoy at gol.com Mon May 25 19:32:25 2009 From: sshenoy at gol.com (Sudhir Shenoy) Date: Tue, 26 May 2009 11:32:25 +0900 Subject: [Openmcl-devel] Type declaration question In-Reply-To: <20090525195113.W72709@abq.clozure.com> References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> <20090525195113.W72709@abq.clozure.com> Message-ID: Hi Gary, Thanks for that (as always) detailed reply. So, I guess the declaration was being silently ignored prior to this. However, in the Hyperspec (under the section on Declaration TYPE, i.e., Body/d_type.htm), it is explicitly stated (in Notes) that "(typespec var*) is an abbreviation for (type typespec var*)". I don't know if this applies to compound type specifiers but in any case it is no biggie since I can simply use the longer form everywhere. Many thanks Sudhir On May 26, 2009, at 11:20 AM, Gary Byers wrote: > "(DECLARE (TYPE (UNSIGNED-BYTE 64) FOO))" says that FOO is of type > (UNSIGNED-BYTE 64) within the scope of that declaration. > > In some cases, the TYPE declaration specifier can be omitted; > "(DECLARE (FIXNUM FOO)) is shorthand for "(DECLARE (TYPE FIXNUM FOO)". > The spec may be a little unclear about which cases allow this > shorthand; > section 3.3.2 describes a declaration as being something whose CAR > is a "declaration identifier", and the glossary defines a "declaration > identifier" to be one of a predefined set of symbols or a symbol which > specifies a type; it doesn't seem to allow compound type specifiers > (like (UNSIGNED-BYTE 64)) to be used as declaration identifiers, > though > other passages in the spec suggest that they should be allowed here. > (See ). > > I don't think that CCL has ever allowed compound type specifiers to > be used as declaration identifiers. Prior to some changes that Gail > made in the trunk a few weeks ago, it tended to quietly ignore > declarations > that it couldn't make sense of (and that would include cases where a > compound type specifier was being used as shorthand for a TYPE > declaration); > a warning is now signaled in that case. > > On Tue, 26 May 2009, Sudhir Shenoy wrote: > >> Can anyone tell me what the proper declaration for a 64 bit unsigned >> integer is? I was using "(declare ((unsigned-byte 64) foo))" which I >> am fairly sure worked prior to CCL 1.3 but now I get a compilation >> warning and the fasl is not generated. I checked the CLHS and there >> doesn't seem to be an upper bound on the number of bits in the >> unsigned-byte declaration. >> >> I have this in some low level i/o conversion (reading in a IEEE float >> value of 8 bytes and converting to a Lisp number) code where I use >> (ldb (byte 1 63) foo) to extract the sign-bit, for example. Is >> there a >> better way to do this? >> >> Thanks >> Sudhir >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> From jgrant at imagine27.com Tue May 26 09:15:25 2009 From: jgrant at imagine27.com (Justin Grant) Date: Tue, 26 May 2009 09:15:25 -0700 Subject: [Openmcl-devel] World's "Fastest" Small Web Server Released, Based On LISP In-Reply-To: <8fbe874a0905251313q7131c62s12efc781e1cdacc9@mail.gmail.com> References: <0E045834-FB0D-414C-B7DC-F31839D387F3@cs.colorado.edu> <87skitar4g.fsf@gmail.com> <8fbe874a0905251313q7131c62s12efc781e1cdacc9@mail.gmail.com> Message-ID: <561d14600905260915s55f1fdb2j693acfa617a3f99c@mail.gmail.com> He fixed the bug. Apparently it was a small typing issue : http://github.com/vii/teepeedee2/commit/1186386abe57d0cbfbd775201d11b7f3a7b9f8e8 Otherwise, this looks like the 'real thing' .... On Mon, May 25, 2009 at 1:13 PM, Bill St. Clair wrote: > On Mon, May 25, 2009 at 4:01 PM, Stas Boukarev wrote: > > Alexander Repenning writes: > > > >> but does it run in CCL? > >> > >> http://tech.slashdot.org/article.pl?sid=09/05/25/1553220&art_pos=4 > >> > > You shoulde've visited the link in that article, which says that it does. > > Unfortunately, it appears that his blog, which is advertised as an > example, is slashdotted. Or just down. > > -Bill > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw at itasoftware.com Tue May 26 12:50:35 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Tue, 26 May 2009 15:50:35 -0400 Subject: [Openmcl-devel] Type declaration question In-Reply-To: References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> <20090525195113.W72709@abq.clozure.com> Message-ID: <4A1C480B.4040402@itasoftware.com> [CC'ing Kent Pitman, just in case he's interested, even though it's "not his job" any more. Kent, start at the bottom of this mail, as usual...] Sudhir Shenoy wrote: > Hi Gary, > > Thanks for that (as always) detailed reply. So, I guess the > declaration was being silently ignored prior to this. > > However, in the Hyperspec (under the section on Declaration TYPE, > i.e., Body/d_type.htm), it is explicitly stated (in Notes) that > "(typespec var*) is an abbreviation for (type typespec var*)". Indeed, it does, and that's inconsistent with section 3.3.2, so we have a problem. > I don't > know if this applies to compound type specifiers but in any case it is > no biggie since I can simply use the longer form everywhere. > Yes, I think that's a good idea. > Many thanks > Sudhir > > On May 26, 2009, at 11:20 AM, Gary Byers wrote: > > >> "(DECLARE (TYPE (UNSIGNED-BYTE 64) FOO))" says that FOO is of type >> (UNSIGNED-BYTE 64) within the scope of that declaration. >> >> In some cases, the TYPE declaration specifier can be omitted; >> "(DECLARE (FIXNUM FOO)) is shorthand for "(DECLARE (TYPE FIXNUM FOO)". >> The spec may be a little unclear about which cases allow this >> shorthand; >> section 3.3.2 describes a declaration as being something whose CAR >> is a "declaration identifier", and the glossary defines a "declaration >> identifier" to be one of a predefined set of symbols or a symbol which >> specifies a type; it doesn't seem to allow compound type specifiers >> (like (UNSIGNED-BYTE 64)) to be used as declaration identifiers, >> though >> other passages in the spec suggest that they should be allowed here. >> (See ). >> >> I don't think that CCL has ever allowed compound type specifiers to >> be used as declaration identifiers. Prior to some changes that Gail >> made in the trunk a few weeks ago, it tended to quietly ignore >> declarations >> that it couldn't make sense of (and that would include cases where a >> compound type specifier was being used as shorthand for a TYPE >> declaration); >> a warning is now signaled in that case. >> >> On Tue, 26 May 2009, Sudhir Shenoy wrote: >> >> >>> Can anyone tell me what the proper declaration for a 64 bit unsigned >>> integer is? I was using "(declare ((unsigned-byte 64) foo))" which I >>> am fairly sure worked prior to CCL 1.3 but now I get a compilation >>> warning and the fasl is not generated. I checked the CLHS and there >>> doesn't seem to be an upper bound on the number of bits in the >>> unsigned-byte declaration. >>> >>> I have this in some low level i/o conversion (reading in a IEEE float >>> value of 8 bytes and converting to a Lisp number) code where I use >>> (ldb (byte 1 63) foo) to extract the sign-bit, for example. Is >>> there a >>> better way to do this? >>> >>> Thanks >>> Sudhir >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >>> >>> > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Tue May 26 18:45:30 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Tue, 26 May 2009 19:45:30 -0600 Subject: [Openmcl-devel] CCL is a mess Message-ID: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> do not shoot the messenger. This is comment on CCL and its IDE collected here: http://code.google.com/p/xmlisp/downloads/list Reported by zos156, May 22 (4 days ago) > CCL is a mess and should not be used to deliver anything > resembling an end-user application, much less used to teach > newbies opengl/and-or lisp. This is exactly the sort of app > that turns people away from Lisp alltogether. If you can not > do it right, its better not to do it at all. > > Detailed issues: 80% of the examples do not run as condition > is thrown about TITLE missing. It would be good if the example code > within the examples was uncommented and ran on 'compile and load > file'. > > The IDE is abysmally bad to the point of becoming a mockery of Lisp. > Extremelly unstable, beach balls all the time seemingly for no > reason at > all, lack of customization, stupid defaults, alien look & feel with no > relevance to Apple HIG. Most importantly: It does not inspire > confidence > for someone to make the investment and learn/use lisp. The one comment about an error (XMLisp related) is something that we cannot reproduce. Perhaps somebody else can? Maybe this is an issue with running CCL on OS X < 10.5 Regarding IDE, I would like to hear from zos156, whoever you are, what kind of IDE would you like? alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikodemus at random-state.net Tue May 26 19:42:28 2009 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Wed, 27 May 2009 05:42:28 +0300 Subject: [Openmcl-devel] Type declaration question In-Reply-To: <4A1C480B.4040402@itasoftware.com> References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> <20090525195113.W72709@abq.clozure.com> <4A1C480B.4040402@itasoftware.com> Message-ID: <633d72b0905261942t3a3b0492wf7f71b135ecb458f@mail.gmail.com> 2009/5/26 Dan Weinreb : > However, in the Hyperspec (under the section on Declaration TYPE, > i.e., Body/d_type.htm), it is explicitly stated (in Notes) that > "(typespec var*) is an abbreviation for (type typespec var*)". > > Indeed, it does, and that's inconsistent with section 3.3.2, so we have > a problem. FWIW, SBCL currently always accepts the "typespec var*" version, but that interpretation is not particularly religiously held. Certainly restricting "typespec var*" to standardized non-compound type specifiers makes it considerably easier to write source transformations in the absence of portable environment access. Not that that has to be a concern, but... Cheers, -- Nikodemus From jsnell at iki.fi Tue May 26 20:39:57 2009 From: jsnell at iki.fi (Juho Snellman) Date: 27 May 2009 06:39:57 +0300 Subject: [Openmcl-devel] Type declaration question References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> <20090525195113.W72709@abq.clozure.com> <4A1C480B.4040402@itasoftware.com> <633d72b0905261942t3a3b0492wf7f71b135ecb458f@mail.gmail.com> Message-ID: <87zlcznrhu.fsf@vasara.proghammer.com> Nikodemus Siivola writes: > 2009/5/26 Dan Weinreb : > > > However, in the Hyperspec (under the section on Declaration TYPE, > > i.e., Body/d_type.htm), it is explicitly stated (in Notes) that > > "(typespec var*) is an abbreviation for (type typespec var*)". > > > > Indeed, it does, and that's inconsistent with section 3.3.2, so we have > > a problem. Not a problem. Examples and notes aren't normative, the glossary (which 3.3.2 refers to) is. > FWIW, SBCL currently always accepts the "typespec var*" version, but > that interpretation is not particularly religiously held. IIRC there's an explicit ansi test for complex type specifiers working as the CAR of a declaration. I don't remember what pfdietz's argument for that was. -- Juho Snellman From tcr at freebits.de Tue May 26 23:14:04 2009 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Wed, 27 May 2009 08:14:04 +0200 Subject: [Openmcl-devel] Type declaration question References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> <20090525195113.W72709@abq.clozure.com> <4A1C480B.4040402@itasoftware.com> <633d72b0905261942t3a3b0492wf7f71b135ecb458f@mail.gmail.com> Message-ID: <87iqjn2hub.fsf@freebits.de> Nikodemus Siivola writes: > 2009/5/26 Dan Weinreb : > >> However, in the Hyperspec (under the section on Declaration TYPE, >> i.e., Body/d_type.htm), it is explicitly stated (in Notes) that >> "(typespec var*) is an abbreviation for (type typespec var*)". >> >> Indeed, it does, and that's inconsistent with section 3.3.2, so we have >> a problem. > > FWIW, SBCL currently always accepts the "typespec var*" version, but > that interpretation is not particularly religiously held. > > Certainly restricting "typespec var*" to standardized non-compound > type specifiers makes it considerably easier to write source > transformations in the absence of portable environment access. Not > that that has to be a concern, but... FWIW, parse-declarations accepts compound typespecs as declaration identifiers, and will even normalize them. Because of the vagueness in CLHS, the library comes with its own glossary which specifies ``declaration identifier'' to be the CAR of a declaration specifier, be it symbol or cons. -T. PS. http://common-lisp.net/project/parse-declarations/manual/html_node/Glossary.html From joakim at joakimsandgren.com Wed May 27 01:22:51 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Wed, 27 May 2009 10:22:51 +0200 Subject: [Openmcl-devel] trunk Message-ID: Hi, I have a strange error . I cant update ccl. In the terminal I put : svn co http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl this works fine, and after downloading it says : Checked out revision 12135. then I launch the dx86cl unix file (the 64bits give the same result) and then in the terminal I have : Welcome to Clozure Common Lisp Version 1.3-dev-r11866M-trunk (DarwinX8632)! (!!) and then I (rebuild-ccl :full t) i (quit) then (require 'cocoa-application) but i'm still stuck in the r11866-trunk! How Come? What am I missing again ?! Sincerely /Eagertoseeallthefixes Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joakim at joakimsandgren.com Wed May 27 03:28:30 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Wed, 27 May 2009 12:28:30 +0200 Subject: [Openmcl-devel] trunk In-Reply-To: References: Message-ID: <642DAB01-97BA-4268-AA5B-6A6D4184A2C5@joakimsandgren.com> Hi Peter, Thank you for advice!! I tried this at once but I am still in the Welcome to Clozure Common Lisp Version 1.3-dev-r11866M-trunk (DarwinX8632)! but I think that I do have control over my directories and before I sent the mail I did a new /trunk directory. but no difference. I also thewed away the preferences... I rebooted,// Hrm, I can't think of anything else to do...! argh /Joakim Le 27 mai 09 ? 11:52, peter a ?crit : > Hi Joakim, > I had this when I forgot to specify into what directory (cd) I > wanted the download to go. so I mistakenly created another new ccl > directory inside my mail ccl directory. so that was updated, but my > main directory was not. > Solution: svn co >http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl ~/ > yourccldir > > Peter > > At 10:22 AM +0200 09/05/27, Joakim Sandgren wrote: >> Hi, >> I have a strange error . >> I cant update ccl. >> In the terminal I put : >> svn co > ccl>http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl >> >> this works fine, and after downloading it says : >> >> Checked out revision 12135. >> >> >> then I launch the dx86cl unix file (the 64bits give the same >> result) and then in the terminal I have : >> >> Welcome to Clozure Common Lisp Version 1.3-dev-r11866M-trunk >> (DarwinX8632)! (!!) >> >> and then I (rebuild-ccl :full t) i (quit) >> then (require 'cocoa-application) >> >> but i'm still stuck in the r11866-trunk! >> >> How Come? >> >> What am I missing again ?! >> >> Sincerely >> /Eagertoseeallthefixes >> >> >> >> >> Joakim Sandgren >> joakim sandgren musik >> 42, rue de Maubeuge >> 75009 Paris >> France >> +33 (0)1 45 26 43 90 >> info at joakimsandgren.com >> http://www.joakimsandgren.com >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cavandusen at gmail.com Wed May 27 03:47:08 2009 From: cavandusen at gmail.com (Chris Van Dusen) Date: Wed, 27 May 2009 05:47:08 -0500 Subject: [Openmcl-devel] trunk In-Reply-To: <642DAB01-97BA-4268-AA5B-6A6D4184A2C5@joakimsandgren.com> References: <642DAB01-97BA-4268-AA5B-6A6D4184A2C5@joakimsandgren.com> Message-ID: <54922A72-2788-40BD-A8B2-C950CBE237C7@gmail.com> Is this message from the command line or the IDE? I had this happen in the IDE a couple of days ago after checking out trunk, but didn't run the command line to see if the issue was there, as well. What I did: check out trunk run ccl64 (it's in my $PATH) (ccl:rebuild-ccl :full t) (require "cocoa-application") (quit) start the IDE, and noted the older revision in the Welcome quit IDE run ccl64 (require "cocoa-application") (quit) started the IDE, and saw that the revision had been updated At the time, I took it to be some user error in the first require, but it sounds similar to your issue. hth, Chris. On May 27, 2009, at 5:28 AM, Joakim Sandgren wrote: > Hi Peter, > Thank you for advice!! > I tried this at once but I am still in the > Welcome to Clozure Common Lisp Version 1.3-dev-r11866M-trunk > (DarwinX8632)! > > but I think that I do have control over my directories and before I > sent the mail I did a new /trunk directory. but no difference. > I also thewed away the preferences... > I rebooted,// > Hrm, I can't think of anything else to do...! > > argh > > /Joakim > > Le 27 mai 09 ? 11:52, peter a ?crit : > >> Hi Joakim, >> I had this when I forgot to specify into what directory (cd) I >> wanted the download to go. so I mistakenly created another new ccl >> directory inside my mail ccl directory. so that was updated, but >> my main directory was not. >> Solution: svn co > >http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl ~/ >> yourccldir >> >> Peter >> >> At 10:22 AM +0200 09/05/27, Joakim Sandgren wrote: >>> Hi, >>> I have a strange error . >>> I cant update ccl. >>> In the terminal I put : >>> svn co >> ccl>http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl >>> >>> this works fine, and after downloading it says : >>> >>> Checked out revision 12135. >>> >>> >>> then I launch the dx86cl unix file (the 64bits give the same >>> result) and then in the terminal I have : >>> >>> Welcome to Clozure Common Lisp Version 1.3-dev-r11866M-trunk >>> (DarwinX8632)! (!!) >>> >>> and then I (rebuild-ccl :full t) i (quit) >>> then (require 'cocoa-application) >>> >>> but i'm still stuck in the r11866-trunk! >>> >>> How Come? >>> >>> What am I missing again ?! >>> >>> Sincerely >>> /Eagertoseeallthefixes >>> >>> >>> >>> >>> Joakim Sandgren >>> joakim sandgren musik >>> 42, rue de Maubeuge >>> 75009 Paris >>> France >>> +33 (0)1 45 26 43 90 >>> info at joakimsandgren.com >>> http://www.joakimsandgren.com >>> >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> > > > > > Joakim Sandgren > joakim sandgren musik > 42, rue de Maubeuge > 75009 Paris > France > +33 (0)1 45 26 43 90 > info at joakimsandgren.com > http://www.joakimsandgren.com > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelcavallaro at mac.com Wed May 27 05:17:42 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 27 May 2009 08:17:42 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> Message-ID: <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> On May 26, 2009, at 9:45 PM, Alexander Repenning wrote: >> >> >> >> Detailed issues: 80% of the examples do not run as condition >> is thrown about TITLE missing. It would be good if the example code >> within the examples was uncommented and ran on 'compile and load >> file'. With respect, these defects are particular to xlui and its example code (which is commented out, and which often throws errors when executed complaining of TITLE missing). They have nothing to do with CCL itself. >> The IDE is abysmally bad to the point of becoming a mockery of >> Lisp. Extremelly unstable, beach balls all the time seemingly for >> no reason at all, lack of customization, stupid defaults, alien >> look & feel with no relevance to Apple HIG. Most importantly: It >> does not inspire confidence for someone to make the investment and >> learn/use lisp. And these are, at base, really all about Hemlock. I've felt similar things myself at times. In just about every case, I could trace the instability to Hemlock, not CCL itself. That said, I think the CCL maintainers (i.e., Clozure) could do themselves a big favor in terms of perception if they either replaced Hemlock entirely, or reviewed its code closely. It's filled with bugs whose affects are glaringly obvious to casual users, and which give the false impression that all of CCL is as unstable as Hemlock. Recently an "interesting" behavior has appeared in trunk: a Cmd-V paste will do nothing for over a full second, then the pasted text will suddenly appear. I suppose this is better than having it paste the wrong text as it formerly did, but it makes CCL look much lamer than it actually is. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From raffaelcavallaro at mac.com Wed May 27 07:19:24 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 27 May 2009 10:19:24 -0400 Subject: [Openmcl-devel] trunk In-Reply-To: <54922A72-2788-40BD-A8B2-C950CBE237C7@gmail.com> References: <642DAB01-97BA-4268-AA5B-6A6D4184A2C5@joakimsandgren.com> <54922A72-2788-40BD-A8B2-C950CBE237C7@gmail.com> Message-ID: On May 27, 2009, at 6:47 AM, Chris Van Dusen wrote: > check out trunk > run ccl64 (it's in my $PATH) > (ccl:rebuild-ccl :full t) > (require "cocoa-application") > (quit) > start the IDE, and noted the older revision in the Welcome > quit IDE > run ccl64 > (require "cocoa-application") > (quit) > started the IDE, and saw that the revision had been updated I've done both an svn update and a complete new checkout. In both instances svn shows that I'm at the current version, but evan after rebuilding ccl, I am stuck at my most recent updated version. IOW, svn shows my source is at 12136, but the last sucessful rebuild was at 1.3-dev-r12125M-trunk and no amount of svn updating or ccl- rebuild will change this. (lisp-implementation-version) also shows I'm stuck at 12125. If I do a full new checkout, I get the same sort of thing, but I'm stuck at 1.3-dev-r11866M-trunk. This problem appeared sometime between about midnight last night, and around 9:00 eastern this morning. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From lisp at clairvaux.org Wed May 27 07:32:31 2009 From: lisp at clairvaux.org (Glen Foy) Date: Wed, 27 May 2009 10:32:31 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> Message-ID: <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> On May 27, 2009, at 8:17 AM, Raffael Cavallaro wrote: > That said, I think the CCL maintainers (i.e., Clozure) could do > themselves a big favor in terms of perception if they either replaced > Hemlock entirely, or reviewed its code closely. It's filled with bugs > whose affects are glaringly obvious to casual users, and which give > the false impression that all of CCL is as unstable as Hemlock. I've been working with Hemlock a lot lately, and it is professionally written code. Any problems that we are currently having are more likely the result of the integration of Cocoa and Hemlock, not with Hemlock itself. What would be Hemlock's replacement? Fred? I like Fred, and it was my first choice, but porting Fred would not be trivial. Initially there would be similar bugs. The problem, as I see, is a matter of PERCEPTION. The IDE, including the Cocoa port of Hemlock, is a work in progress. It is not ready for the casual user. It is not ready for someone trying out Lisp for the first time. It should be advertised as such. There is nothing wrong with being a work in progress. What's wrong here is the framing. CCL will eventually have a terrific, world class IDE to match the world class compiler. No question. Patience -- From raffaelcavallaro at mac.com Wed May 27 08:10:37 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 27 May 2009 11:10:37 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> Message-ID: On May 27, 2009, at 10:32 AM, Glen Foy wrote: > I've been working with Hemlock a lot lately, and it is professionally > written code. Any problems that we are currently having are more > likely the result of the integration of Cocoa and Hemlock, not with > Hemlock itself. Then it should either be properly integrated or discarded. > The problem, as I see, is a matter of PERCEPTION. The IDE, including > the Cocoa port of Hemlock, is a work in progress. It has been a work in progress for a number of years already. One would think that basic text editing functionality such as copy and paste would be working properly by now. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From ralex at cs.colorado.edu Wed May 27 08:20:40 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Wed, 27 May 2009 09:20:40 -0600 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> Message-ID: <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> On May 27, 2009, at 6:17 AM, Raffael Cavallaro wrote: > > On May 26, 2009, at 9:45 PM, Alexander Repenning wrote: > >>> >>> >>> >>> Detailed issues: 80% of the examples do not run as condition >>> is thrown about TITLE missing. It would be good if the example code >>> within the examples was uncommented and ran on 'compile and load >>> file'. > > With respect, these defects are particular to xlui and its example > code (which is commented out, and which often throws errors when > executed complaining of TITLE missing). They have nothing to do with > CCL itself. yes, completely true. I just dumped the entire comment into the email. That specific "bug" is about not having evaluated the class definitions in the example code before. The suggestion of uncommenting is probably a good one. Will do for the next release. > >>> The IDE is abysmally bad to the point of becoming a mockery of >>> Lisp. Extremelly unstable, beach balls all the time seemingly for >>> no reason at all, lack of customization, stupid defaults, alien >>> look & feel with no relevance to Apple HIG. Most importantly: It >>> does not inspire confidence for someone to make the investment and >>> learn/use lisp. > > And these are, at base, really all about Hemlock. I've felt similar > things myself at times. In just about every case, I could trace the > instability to Hemlock, not CCL itself. > > That said, I think the CCL maintainers (i.e., Clozure) could do > themselves a big favor in terms of perception if they either replaced > Hemlock entirely, or reviewed its code closely. It's filled with bugs > whose affects are glaringly obvious to casual users, and which give > the false impression that all of CCL is as unstable as Hemlock. > Recently an "interesting" behavior has appeared in trunk: a Cmd-V > paste will do nothing for over a full second, then the pasted text > will suddenly appear. I suppose this is better than having it paste > the wrong text as it formerly did, but it makes CCL look much lamer > than it actually is. > > I agree, the curb appeal of the CCL/IDE is not great right now. I wonder if the person making the comment actually does like any of the existing Lisp IDEs such as LispWork or Allegro. I am guessing he/she would not like them either. Even the Mac version of LispWorks does not really try to deal with Apple's HIG. I actually think CCL does already a better job at that. With some more work the instability will hopefully go away but some of the other issues raised would probably require a much more significant redesign. Incidentally, I noticed that Lisp sources in Google code do get some (must be pre CLOS) Lisp syntax coloring. Have a look at this (not the actual content) and notice how Google code marks the code up in some interesting ways: http://code.google.com/p/xmlisp/source/browse/trunk/XMLisp/sources/Lisp%20User%20Interface/Camera.lisp When the code comes up you may initially see the black and white versions for a split second before the colorization does its work. Have a look at the HTML source of that page. alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From mevins at mac.com Wed May 27 08:32:44 2009 From: mevins at mac.com (mikel evins) Date: Wed, 27 May 2009 10:32:44 -0500 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> Message-ID: <426E916E-B44F-401C-8229-8E2FDC7F65B6@mac.com> On May 27, 2009, at 10:10 AM, Raffael Cavallaro wrote: > > On May 27, 2009, at 10:32 AM, Glen Foy wrote: > >> I've been working with Hemlock a lot lately, and it is professionally >> written code. Any problems that we are currently having are more >> likely the result of the integration of Cocoa and Hemlock, not with >> Hemlock itself. > > Then it should either be properly integrated or discarded. > >> The problem, as I see, is a matter of PERCEPTION. The IDE, including >> the Cocoa port of Hemlock, is a work in progress. > > > It has been a work in progress for a number of years already. That seems a perverse reason for complaint. The existing app began as an experiment in using the FFI to make API calls into Cocoa, and it hasn't been much more than that for most of its existence. Every so often someone would, when not overwhelmed by other responsibilities that someone was paying for, add a few features, fix a few bugs, or update a few bits of stale code. Eventually, in tiny increments, it became featureful enough for people to start complaining about it. Now there are actual scheduled resources being brought to bear on the Cocoa app. Saying what one would like to see done is likely right now to yield actual improvements in the app. Lobbing brickbats at the people working on those improvements isn't. --me From lisp at clairvaux.org Wed May 27 08:51:48 2009 From: lisp at clairvaux.org (Glen Foy) Date: Wed, 27 May 2009 11:51:48 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> Message-ID: <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> On May 27, 2009, at 11:10 AM, Raffael Cavallaro wrote: >> >> I've been working with Hemlock a lot lately, and it is professionally >> written code. Any problems that we are currently having are more >> likely the result of the integration of Cocoa and Hemlock, not with >> Hemlock itself. > > Then it should either be properly integrated or discarded. Yes, Cavallaro, why don't we discard it. Then we will have NO editor. Good thinking! From gz at clozure.com Wed May 27 09:06:34 2009 From: gz at clozure.com (Gail Zacharias) Date: Wed, 27 May 2009 12:06:34 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> Message-ID: <200905271608.PXQ07886@mr02.lnh.mail.rcn.net> >>>> alien look & feel with no relevance to Apple HIG. I would be interested in hearing more about this aspect. The IDE has its problems, and I thought that at this point for the most part we know what they are. But as far as look & feel, I could use some help because as a mac old-timer, I don't see the problem. It looks and feels pretty mac-like to me. What are some of the issues? What do you hear from students? Is the emacs-like echo area/modeline at the bottom of the window is one of them? What would be a better look (given that we do still want to provide emacs functionality in some form)? From raffaelcavallaro at mac.com Wed May 27 09:56:28 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 27 May 2009 12:56:28 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> Message-ID: On May 27, 2009, at 11:51 AM, Glen Foy wrote: >> >> Then it should either be properly integrated or discarded. > > Yes, Cavallaro, why don't we discard it. > > Then we will have NO editor. Good thinking! Clearly I meant properly integrate it with cocoa, or replace it with a cocoa-based editor, not have an IDE with no editor at all. Construing my meaning in the most brain damaged fashion possible will not change the fact that the editor still doesn't do some pretty basic text editing operations properly, operations that come for free with cocoa. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From gb at clozure.com Wed May 27 09:57:27 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 27 May 2009 10:57:27 -0600 (MDT) Subject: [Openmcl-devel] trunk In-Reply-To: <54922A72-2788-40BD-A8B2-C950CBE237C7@gmail.com> References: <642DAB01-97BA-4268-AA5B-6A6D4184A2C5@joakimsandgren.com> <54922A72-2788-40BD-A8B2-C950CBE237C7@gmail.com> Message-ID: <20090527105058.S72709@abq.clozure.com> Ahem. I broke SAVE-APPLICATION in the trunk a few days ago. It should be fixed now. On Wed, 27 May 2009, Chris Van Dusen wrote: > Is this message from the command line or the IDE? > > I had this happen in the IDE a couple of days ago after checking out trunk, > but didn't run the command line to see if the issue was there, as well. > > What I did: > > check out trunk > run ccl64 (it's in my $PATH) > (ccl:rebuild-ccl :full t) > (require "cocoa-application") > (quit) > start the IDE, and noted the older revision in the Welcome > quit IDE > run ccl64 > (require "cocoa-application") > (quit) > started the IDE, and saw that the revision had been updated > > At the time, I took it to be some user error in the first require, but it > sounds similar to your issue. > > hth, > Chris. > > On May 27, 2009, at 5:28 AM, Joakim Sandgren wrote: > >> Hi Peter, >> Thank you for advice!! >> I tried this at once but I am still in the >> Welcome to Clozure Common Lisp Version 1.3-dev-r11866M-trunk (DarwinX8632)! >> >> but I think that I do have control over my directories and before I sent >> the mail I did a new /trunk directory. but no difference. >> I also thewed away the preferences... >> I rebooted,// >> Hrm, I can't think of anything else to do...! >> argh >> >> /Joakim >> >> Le 27 mai 09 ? 11:52, peter a ?crit : >> >>> Hi Joakim, >>> I had this when I forgot to specify into what directory (cd) I wanted the >>> download to go. so I mistakenly created another new ccl directory inside >>> my mail ccl directory. so that was updated, but my main directory was >>> not. >>> Solution: svn co >>> http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl >>> ~/yourccldir >>> >>> Peter >>> >>> At 10:22 AM +0200 09/05/27, Joakim Sandgren wrote: >>>> Hi, >>>> I have a strange error . >>>> I cant update ccl. >>>> In the terminal I put : >>>> svn co >>>> http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl >>>> >>>> this works fine, and after downloading it says : >>>> >>>> Checked out revision 12135. >>>> >>>> >>>> then I launch the dx86cl unix file (the 64bits give the same result) and >>>> then in the terminal I have : >>>> >>>> Welcome to Clozure Common Lisp Version 1.3-dev-r11866M-trunk >>>> (DarwinX8632)! (!!) >>>> >>>> and then I (rebuild-ccl :full t) i (quit) >>>> then (require 'cocoa-application) >>>> >>>> but i'm still stuck in the r11866-trunk! >>>> >>>> How Come? >>>> >>>> What am I missing again ?! >>>> >>>> Sincerely >>>> /Eagertoseeallthefixes >>>> >>>> >>>> >>>> >>>> Joakim Sandgren >>>> joakim sandgren musik >>>> 42, rue de Maubeuge >>>> 75009 Paris >>>> France >>>> +33 (0)1 45 26 43 90 >>>> info at joakimsandgren.com >>>> http://www.joakimsandgren.com >>>> >>>> >>>> _______________________________________________ >>>> Openmcl-devel mailing list >>>> Openmcl-devel at clozure.com >>>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >> >> >> >> >> Joakim Sandgren >> joakim sandgren musik >> 42, rue de Maubeuge >> 75009 Paris >> France >> +33 (0)1 45 26 43 90 >> info at joakimsandgren.com >> http://www.joakimsandgren.com >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > From joswig at lisp.de Wed May 27 09:59:41 2009 From: joswig at lisp.de (Rainer Joswig) Date: Wed, 27 May 2009 18:59:41 +0200 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> Message-ID: <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> Am 27.05.2009 um 17:20 schrieb Alexander Repenning: > > I agree, the curb appeal of the CCL/IDE is not great right now. I > wonder if the person making the comment actually does like any of > the existing Lisp IDEs such as LispWork or Allegro. I am guessing he/ > she would not like them either. Even the Mac version of LispWorks > does not really try to deal with Apple's HIG. I actually think CCL > does already a better job at that. With some more work the > instability will hopefully go away but some of the other issues > raised would probably require a much more significant redesign. Personally I never liked the later implementation of FRED that much. It was mixed with lots of platform specific code - that's also the reason it is difficult to extract it from MCL (incl. Carbon aka Toolbox). It was tweaked a lot, but it dies with the platform it was written for. It also never provided a special foundation to edit different types of text (C, Lisp, Text, ...). The most useful thing was that FRED could also be used in views - but that was also not clearly 'engineered' - more grown and optimized around whatever Apple did do with the Toolbox/Carbon. Also remembered that the original MCL user interface was written in Object Lisp (and not CLOS which did not exist at that time). We should also remember that MCL was having quite a bit more usage in the area of GUI apps - including from Apple. CCL is far from that usage level and level of bug fixing / enhancing in the GUI area. CMUCL has a Hemlock user and implementors manual. The Hemlock in CCL is stripped down and lacks various modes and commands. When I edit an editor command, I use M-x Edit Command and then edit the command. That's quick. CCL doesn't have that command active. Generally I think the core of Hemlock is better than some people seem to think. http://www.cons.org/cmucl/hemlock/ Question to the UI experts: is there an agreed way to use Cocoa from a multi-threaded language/implementation (like CCL), in an interactive development environment and in a robust way? Is that even possible? That's a real question - it is not clear to me. What good is a Lisp development environment if I can't really debug the main thread interactively or when it is easy to screw up the main thread which the whole IDE depends on - assuming Cocoa? Everybody who has ever written a non-trivial GUI app knows that the 'test department' has an easy target. It is really really hard to make a GUI application robust against 'normal' users. Here we have a development tool, with hairy error handling, probably faulty code during development, endless loops, errors popping up, incremental modifications, etc. I'd guess that it takes quite a bit effort to get that right with lots of testing and fixing. Then we have the issue that the development environment and the application(s) under development are running in the same Lisp application. That also adds to instability. In Eclipse one creates an app that gets started and debugged externally. Same for Emacs/SLIME/CCL. Apple HIG. For me the issue is not that CCL looks or feels different. The largest issue is that it is far from exploiting the facilities offered by Cocoa. The natural way for CCL is to implement the development tools GUI based. The editor is just one tool. The inspector, debugger, class browser, etc. would not be (or already are not) editor based. CCL can exploit Cocoa if that's what the IDE is based on (and if supporting Windows, Gnome, KDE, ... is not a goal). The next question is 'user expectation'. What kind of IDE are users expecting? * Eclipse-like, because the users are students and know mostly Eclipse? An MCL-like IDE will not do it for them. They want windows full of widgets, wizards, tiled windows, large preference dialogues, lots of XML configuration files, ... * MCL-like, because the users are homeless ex-MCL users? * XCode-like, because the CCL IDE users are on the Mac anyway? * Somehow integrating with Xcode and some of its tools (Interface Builder, ...)? * Emacs/SLIME-like? * Something new? * None? Because they use Emacs/SLIME or Eclipse with Lisp support? The expectation of the average Java user (say, a student with Java experience) would be that one edits a while, interacts with repositories, checks out, deploys, runs a test suite, merges in code, edits more, ... The original Lisp model of development (think MCL) of interactively and incrementally modifying the app from within the app is strange for them ('how do you move ALL the changes made in a listener to the files in the repository?'). If we move away from that, why use Lisp? If we keep this model how is it explained so that new users can unlearn Eclipse/Netbeans/Jbuilder/Visual Studio/..., can understand why there is a difference and can be made productive? Regards, Rainer Joswig Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelcavallaro at mac.com Wed May 27 10:13:14 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 27 May 2009 13:13:14 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <200905271608.PXQ07886@mr02.lnh.mail.rcn.net> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> <200905271608.PXQ07886@mr02.lnh.mail.rcn.net> Message-ID: <91BEA3B3-B15D-497B-814C-56B172056797@mac.com> On May 27, 2009, at 12:06 PM, Gail Zacharias wrote: > What are some of the issues? What do you hear from students? Is the > emacs-like echo area/modeline at the bottom of the window is one of > them? I can see one issue here; the echo area/modeline doesn't extend the full width of the window. Currently it only extends 3/4 of the window width leaving what looks like a thumbless horizontal scroll bar to its right. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro at mac.com From lisp at clairvaux.org Wed May 27 10:13:32 2009 From: lisp at clairvaux.org (Glen Foy) Date: Wed, 27 May 2009 13:13:32 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> Message-ID: On May 27, 2009, at 12:56 PM, Raffael Cavallaro wrote: > Construing > my meaning in the most brain damaged fashion possible will not change > the fact that the editor still doesn't do some pretty basic text > editing operations Why don't you go dust off your constantly advertised Ph.D From danieldickison at gmail.com Wed May 27 10:15:41 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Wed, 27 May 2009 13:15:41 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> Message-ID: On May 27, 2009, at 12:59 PM, Rainer Joswig wrote: > > The next question is 'user expectation'. What kind of IDE are users > expecting? > > * Eclipse-like, because the users are students and know mostly > Eclipse? An MCL-like IDE will not do it for them. They want windows > full of widgets, wizards, tiled windows, large preference dialogues, > lots of XML configuration files, ... > > * MCL-like, because the users are homeless ex-MCL users? > > * XCode-like, because the CCL IDE users are on the Mac anyway? > > * Somehow integrating with Xcode and some of its tools (Interface > Builder, ...)? > > * Emacs/SLIME-like? > > * Something new? > > * None? Because they use Emacs/SLIME or Eclipse with Lisp support? I would think something Xcode-like would be ideal, especially with integrated support for Interface Builder. I don't see emulating Emacs as a benefit, since, if you want Emacs, you could always use Aquamacs and SLIME instead. From mevins at mac.com Wed May 27 10:25:11 2009 From: mevins at mac.com (mikel evins) Date: Wed, 27 May 2009 12:25:11 -0500 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> Message-ID: On May 27, 2009, at 11:59 AM, Rainer Joswig wrote: > Question to the UI experts: is there an agreed way to use Cocoa from > a multi-threaded language/implementation (like CCL), in an > interactive development environment and in a robust way? Is that > even possible? That's a real question - it is not clear to me. What > good is a Lisp development environment if I can't really debug the > main thread interactively or when it is easy to screw up the main > thread which the whole IDE depends on - assuming Cocoa? You've hit the nail on the head here. There is exactly one thread per app under Mac OS X that handles all events for that app. If you're accustomed to Lisp development, then you're probably thinking that what happens when there's an error is that you drop into a backtrace. But what if that error is on the Cocoa event thread? Well, then, dropping into a backtrace stops all event-processing (because that thread is busy being stopped in the backtrace, rather than handling events), so all you're going to see from the Cocoa app at that point is the spinning beachball of death. It's kind of a hard problem to solve well. It's being worked on. --me From dlw at itasoftware.com Wed May 27 10:59:47 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Wed, 27 May 2009 13:59:47 -0400 Subject: [Openmcl-devel] Type declaration question In-Reply-To: <00e401c9de3c$253d05d0$1502a8c0@howard> References: <8849E2AB-BC20-4411-9199-BF246109F0B0@gol.com> <20090525195113.W72709@abq.clozure.com> <4A1C480B.4040402@itasoftware.com> <00e401c9de3c$253d05d0$1502a8c0@howard> Message-ID: <4A1D7F93.2030205@itasoftware.com> OK. The only issue is that the Hyperspec is internally inconsistent. I think we agree that the following is just a mistake: "(typespec var*) is an abbreviation for (type typespec var*)". So what CCL is doing is correct. -- Dan Kent M Pitman wrote: > > I didn't go back and research what I wrote, but in my mind I think > (/typespec/ /var/*) is only usable for a restricted set of names > (mostly legacy names like fixnum, etc. just as for many [but maybe not > the exact same set] of those names there are type predicates by name > rather than the TYPEP function) and that the only generally safe thing > to do in type declarations is (TYPE /typespec/ /var/*). It is true > that for all valid (/typespec/ /var/*) it means (TYPE /typespec/ > /_var_/*), but maybe there is a passage that has this restriction > which is just hidden, hard to find, or exists only in my mind. J > > > > ------------------------------------------------------------------------ > > *From:* Dan Weinreb [mailto:dlw at itasoftware.com] > *Sent:* Tuesday, May 26, 2009 3:51 PM > *To:* Sudhir Shenoy > *Cc:* Gary Byers; Openmcl-devel Devel; Kent Pitman > *Subject:* Re: [Openmcl-devel] Type declaration question > > > > [CC'ing Kent Pitman, just in case he's interested, even > though it's "not his job" any more. Kent, start at the > bottom of this mail, as usual...] > > Sudhir Shenoy wrote: > > Hi Gary, > > Thanks for that (as always) detailed reply. So, I guess the > declaration was being silently ignored prior to this. > > However, in the Hyperspec (under the section on Declaration TYPE, > i.e., Body/d_type.htm), it is explicitly stated (in Notes) that > "(typespec var*) is an abbreviation for (type typespec var*)". > > Indeed, it does, and that's inconsistent with section 3.3.2, so we have > a problem. > > I don't > know if this applies to compound type specifiers but in any case it is > no biggie since I can simply use the longer form everywhere. > > > Yes, I think that's a good idea. > > > Many thanks > Sudhir > > On May 26, 2009, at 11:20 AM, Gary Byers wrote: > > >> "(DECLARE (TYPE (UNSIGNED-BYTE 64) FOO))" says that FOO is of type >> (UNSIGNED-BYTE 64) within the scope of that declaration. >> >> In some cases, the TYPE declaration specifier can be omitted; >> "(DECLARE (FIXNUM FOO)) is shorthand for "(DECLARE (TYPE FIXNUM FOO)". >> The spec may be a little unclear about which cases allow this >> shorthand; >> section 3.3.2 describes a declaration as being something whose CAR >> is a "declaration identifier", and the glossary defines a "declaration >> identifier" to be one of a predefined set of symbols or a symbol which >> specifies a type; it doesn't seem to allow compound type specifiers >> (like (UNSIGNED-BYTE 64)) to be used as declaration identifiers, >> though >> other passages in the spec suggest that they should be allowed here. >> (See ). >> >> I don't think that CCL has ever allowed compound type specifiers to >> be used as declaration identifiers. Prior to some changes that Gail >> made in the trunk a few weeks ago, it tended to quietly ignore >> declarations >> that it couldn't make sense of (and that would include cases where a >> compound type specifier was being used as shorthand for a TYPE >> declaration); >> a warning is now signaled in that case. >> >> On Tue, 26 May 2009, Sudhir Shenoy wrote: >> >> >>> Can anyone tell me what the proper declaration for a 64 bit unsigned >>> integer is? I was using "(declare ((unsigned-byte 64) foo))" which I >>> am fairly sure worked prior to CCL 1.3 but now I get a compilation >>> warning and the fasl is not generated. I checked the CLHS and there >>> doesn't seem to be an upper bound on the number of bits in the >>> unsigned-byte declaration. >>> >>> I have this in some low level i/o conversion (reading in a IEEE float >>> value of 8 bytes and converting to a Lisp number) code where I use >>> (ldb (byte 1 63) foo) to extract the sign-bit, for example. Is >>> there a >>> better way to do this? >>> >>> Thanks >>> Sudhir >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >>> >>> > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lisp at clairvaux.org Wed May 27 11:35:15 2009 From: lisp at clairvaux.org (Glen Foy) Date: Wed, 27 May 2009 14:35:15 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> Message-ID: <18DE78E3-3779-4E7E-B79C-82B2F67CE794@clairvaux.org> On May 27, 2009, at 12:59 PM, Rainer Joswig wrote: > The next question is 'user expectation'. What kind of IDE are users > expecting? > > * Eclipse-like, because the users are students and know mostly > Eclipse? An MCL-like IDE will not do it for them. They want windows > full of widgets, wizards, tiled windows, large preference dialogues, > lots of XML configuration files, ... > > * MCL-like, because the users are homeless ex-MCL users? > > * XCode-like, because the CCL IDE users are on the Mac anyway? > > * Somehow integrating with Xcode and some of its tools (Interface > Builder, ...)? > > * Emacs/SLIME-like? > > * Something new? > > * None? Because they use Emacs/SLIME or Eclipse with Lisp support? Clozure has just announced a Rosette port of MCL on Intel! We have another possible model for a CCL IDE: Terje Norderhaug has done some interesting preliminary work using MCL as a generic Lisp IDE. MCL handles events and displays tools while a separate Lisp process runs the code. It uses the Slime/Swank protocol. Now I would prefer a version of CCL doing the same thing, but if Terje's code is in good shape, we can do a proof of concept right now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From terje at in-progress.com Wed May 27 12:43:12 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Wed, 27 May 2009 12:43:12 -0700 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <18DE78E3-3779-4E7E-B79C-82B2F67CE794@clairvaux.org> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <4614467A-2E62-45D9-B396-E173FCF7E429@cs.colorado.edu> <7DE0C59D-85E1-489D-BDFD-F688DC6F6316@lisp.de> <18DE78E3-3779-4E7E-B79C-82B2F67CE794@clairvaux.org> Message-ID: <97D96835-B0BF-4F84-A8C4-92A1566D48F5@in-progress.com> On May 27, 2009, at 11:35 AM, Glen Foy wrote: > On May 27, 2009, at 12:59 PM, Rainer Joswig wrote: > >> The next question is 'user expectation'. What kind of IDE are >> users expecting? >> >> * Eclipse-like, because the users are students and know mostly >> Eclipse? An MCL-like IDE will not do it for them. They want >> windows full of widgets, wizards, tiled windows, large preference >> dialogues, lots of XML configuration files, ... >> >> * MCL-like, because the users are homeless ex-MCL users? >> >> * XCode-like, because the CCL IDE users are on the Mac anyway? >> >> * Somehow integrating with Xcode and some of its tools (Interface >> Builder, ...)? >> >> * Emacs/SLIME-like? >> >> * Something new? >> >> * None? Because they use Emacs/SLIME or Eclipse with Lisp support? > > > Clozure has just announced a Rosette port of MCL on Intel! We have > another possible model for a CCL IDE: > > Terje Norderhaug has done some interesting preliminary work using > MCL as a generic Lisp IDE. MCL handles events and displays tools > while a separate Lisp process runs the code. It uses the Slime/ > Swank protocol. > > Now I would prefer a version of CCL doing the same thing, but if > Terje's code is in good shape, we can do a proof of concept right now. Coming right up! Well, give me a little time, but with the Rosetta support, this has my full attention. -- Terje Norderhaug From ron at awun.net Wed May 27 16:19:19 2009 From: ron at awun.net (Ron Garret) Date: Wed, 27 May 2009 16:19:19 -0700 Subject: [Openmcl-devel] PDFKit crashes Message-ID: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> Trying to open and display a PDF file crashes CCL in various ways. Using this code: (in-package "CL-USER") (require :cocoa) (objc:load-framework "Quartz" :quartz) (defun nsstr (s) (make-instance 'gui::ns-lisp-string :string s)) (defun pdf-from-file (filename) (#/initWithData: (#/alloc ns:pdf-document) (#/dataWithContentsOfFile: ns:ns-data filename))) (defun pdf-from-url (url) (#/initWithUrl: (#/alloc ns:pdf-document) (#/URLWithString: ns:ns-url url))) #| (setf p1 (pdf-from-file #@"/Users/ron/Desktop/test.pdf")) (setf p2 (pdf-from-url #@"http://www.flownet.com/ron/test.pdf")) (setf v (#/alloc ns:pdf-view)) (#/setDocument: v sce) |# I can open the PDF as a file, but not as a URL. When I try, I get a hard crash: Unhandled exception 10 at 0xc49847a, context->regs at #xb0525e50 Exception occurred while executing foreign code at .objc_category_name_NSColor_PDFColorUtilities + 99450 ? for help [24137] Clozure CL kernel debugger: b current thread: tcr = 0xa7eeba0, native thread ID = 0x1a703, interrupts enabled (#x000000000BF9AC38) #x0000300040F6D204 : # + 213 (#x000000000BF9AC58) #x0000300040F602D4 : # + 501 (#x000000000BF9AC98) #x00003000412CC5E4 : # + 165 (#x000000000BF9ACF0) #x0000300040EAE96C : # + 109 (#x000000000BF9AD30) #x00003000404D18F4 : # + 293 (#x000000000BF9AD78) #x0000300040EAE764 : # + 277 (#x000000000BF9ADA8) #x00003000401A305C : # + 1069 (#x000000000BF9AE28) #x00003000401A5A64 : # + 773 (#x000000000BF9AEA0) #x00003000404D405C : # + 173 (#x000000000BF9AF20) #x00003000404D579C : # + 845 (#x000000000BF9AF80) #x00003000404EEABC : # + 301 (#x000000000BF9AFD8) #x00003000404D2E54 : # + 181 (#x000000000BF9B010) #x00003000401A305C : # + 1069 (#x000000000BF9B090) #x00003000401A5A64 : # + 773 (#x000000000BF9B108) #x00003000404D405C : # + 173 (#x000000000BF9B188) #x00003000404D579C : # + 845 (#x000000000BF9B1E8) #x00003000404E1A1C : # + 541 (#x000000000BF9B218) #x00003000404DED34 : # + 133 (#x000000000BF9B258) #x0000300040A81E3C : # + 189 (#x000000000BF9B2A8) #x00003000405A629C : # + 2397 (#x000000000BF9B350) #x0000300040A931FC : # + 157 (#x000000000BF9B370) #x0000300040D3EE7C : # + 221 (#x000000000BF9B3F0) #x0000300040D1C4FC : # + 349 (#x000000000BF9B478) #x0000300040D1CCC4 : # + 53 (#x000000000BF9B4A0) #x0000300040D1D37C : # + 573 (#x000000000BF9B520) #x0000300040A943FC : # + 1693 (#x000000000BF9B5C8) #x0000300040541C3C : # + 813 (#x000000000BF9B780) #x0000300040543554 : # + 517 (#x000000000BF9B7D8) #x00003000405E3DC4 : # + 357 (#x000000000BF9B800) #x0000300040591FDC : # + 2013 (#x000000000BF9B8B8) #x00003000405E8D54 : # + 197 (#x000000000BF9B8E8) #x00003000405E793C : # + 2445 (#x000000000BF9B938) #x000030004053F374 : # + 181 (#x000000000BF9B978) #x00003000405E87DC : # + 493 (#x000000000BF9B9B0) #x000030004013D92C : # + 397 (#x000000000BF9BA18) #x0000000000000000 : # + ?? (#x000000000BF9BA78) #x0000300040529CD4 : # + 229 (#x000000000BF9BAB0) #x000030004052BF64 : # + 1861 (#x000000000BF9BB10) #x000030004054589C : # + 733 (#x000000000BF9BBB0) #x0000300040547D34 : # + 2053 (#x000000000BF9BDF0) #x000030004052973C : # + 109 (#x000000000BF9BE20) #x00003000405EC094 : # + 645 (#x000000000BF9BEB8) #x00003000404C4C3C : # + 717 (#x000000000BF9BF48) #x00003000404C5844 : # + 389 (#x000000000BF9BF98) #x00003000404A777C : # + 301 [24137] Clozure CL kernel debugger: Similar problem when I try to stick the PDF from the file into a PDF- view: Unhandled exception 10 at 0xc483919, context->regs at #xb0526970 Exception occurred while executing foreign code at .objc_category_name_NSColor_PDFColorUtilities + 14617 ? for help [24131] Clozure CL kernel debugger: b current thread: tcr = 0xa7eead0, native thread ID = 0x1a703, interrupts enabled (#x000000000BF9BA70) #x00003000412CBE2C : # + 429 (#x000000000BF9BA98) #x0000300040F602D4 : # + 501 (#x000000000BF9BAD8) #x0000300040529CD4 : # + 229 (#x000000000BF9BB10) #x000030004054589C : # + 733 (#x000000000BF9BBB0) #x0000300040547D34 : # + 2053 (#x000000000BF9BDF0) #x000030004052973C : # + 109 (#x000000000BF9BE20) #x00003000405EC094 : # + 645 (#x000000000BF9BEB8) #x00003000404C4C3C : # + 717 (#x000000000BF9BF48) #x00003000404C5844 : # + 389 (#x000000000BF9BF98) #x00003000404A777C : # + 301 [24131] Clozure CL kernel debugger: This seems to be a problem with the ObjC object-printing code, and not PDFKit per se. But I thought I'd ask if this was a known problem, or if I'm doing something obviously stupid, before filing a ticket. This is running on a clean build of the trunk as of about 3PM PDT. Thanks, rg From ron at awun.net Wed May 27 18:20:48 2009 From: ron at awun.net (Ron Garret) Date: Wed, 27 May 2009 18:20:48 -0700 Subject: [Openmcl-devel] PDFKit crashes In-Reply-To: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> References: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> Message-ID: On May 27, 2009, at 4:19 PM, Ron Garret wrote: > Trying to open and display a PDF file crashes CCL in various ways. > > Using this code: > > (in-package "CL-USER") > > (require :cocoa) > (objc:load-framework "Quartz" :quartz) > (defun nsstr (s) (make-instance 'gui::ns-lisp-string :string s)) > > (defun pdf-from-file (filename) > (#/initWithData: (#/alloc ns:pdf-document) > (#/dataWithContentsOfFile: ns:ns-data filename))) > > (defun pdf-from-url (url) > (#/initWithUrl: (#/alloc ns:pdf-document) > (#/URLWithString: ns:ns-url url))) > So it turns out that this problem is due to misspelling initWithURL as initWithUrl. Still, it would be good if the result of this were not a hard crash. Still puzzling over the second problem. rg From lw at mt.net Wed May 27 19:07:59 2009 From: lw at mt.net (Laughing Water) Date: Wed, 27 May 2009 20:07:59 -0600 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> Message-ID: <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> I feel disgusted when I read comments of this sort. I would appreciate it if participants would make the effort to understand the points others are trying to make. And if you disagree, please do so respectfully. LW On May 27, 2009, at 11:13 AM, Glen Foy wrote: > > On May 27, 2009, at 12:56 PM, Raffael Cavallaro wrote: > >> Construing >> my meaning in the most brain damaged fashion possible will not change >> the fact that the editor still doesn't do some pretty basic text >> editing operations > > Why don't you go dust off your constantly advertised Ph.D > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From gb at clozure.com Wed May 27 20:13:24 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 27 May 2009 21:13:24 -0600 (MDT) Subject: [Openmcl-devel] PDFKit crashes In-Reply-To: References: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> Message-ID: <20090527192231.M72709@abq.clozure.com> T On Wed, 27 May 2009, Ron Garret wrote: > > On May 27, 2009, at 4:19 PM, Ron Garret wrote: > >> Trying to open and display a PDF file crashes CCL in various ways. >> >> Using this code: >> >> (in-package "CL-USER") >> >> (require :cocoa) >> (objc:load-framework "Quartz" :quartz) >> (defun nsstr (s) (make-instance 'gui::ns-lisp-string :string s)) >> >> (defun pdf-from-file (filename) >> (#/initWithData: (#/alloc ns:pdf-document) >> (#/dataWithContentsOfFile: ns:ns-data filename))) >> >> (defun pdf-from-url (url) >> (#/initWithUrl: (#/alloc ns:pdf-document) >> (#/URLWithString: ns:ns-url url))) >> > > So it turns out that this problem is due to misspelling initWithURL as > initWithUrl. Still, it would be good if the result of this were not a > hard crash. An ObjC message named #/description is applicable to all NSObjects; it returns an NSString which ... um, describes the object: ? (#/description (#/init (#/alloc ns:ns-object))) #" (#x12943380)> There isn't too much to say about a direct instance of NS:NS-OBJECT, but for instances of other classes there's often quite a bit of information in the #/description string. The default PRINT-OBJECT method for NS:NS-OBJECTs invokes #/description, obtains a lisp string from the ns-string, and uses the resulting string (all of it ...) in its output. (As I was typing this, I saw a message suggesting that this output observe *PRINT-LENGTH*; that isn't relevant to the printing of strings, but truncating the string to some reasonable length would probably be reasonable.) In most cases, the existing #/description methods are remarkably robust, but in at least some cases - most of which seem to involve objects that have been allocated but not yet initialized - they leap before looking and try to print uninitialized slots in the object: ? (#/description (#/alloc ns::pdf-document)) Unhandled exception 10 at 0x1451647a, context->regs at #xb029b970 Exception occurred while executing foreign code at .objc_category_name_NSColor_PDFColorUtilities + 99450 which looks kind of familiar. So yes, you should have gotten a runtime when trying to call a misspelled ObjC method name (which was warned about) and in fact you did. The system started to enter a break loop (the good news: on the event thread in the context in which the error occurred; the bad news: using AltConsole, until something better comes along) but crashed trying to print the (uninitialized) NS:NS-PDF-DOCUMENT object by printing the string returned by its #/description method. (Look at the backtrace.) I don't know how to tell in general whether or not it's safe to call a #/description method on an arbitrary NSObject (it certainly seems to be in the vast majority of cases, but it may be hard to recover from the cases where it isn't.) Until this point, I'd been fairly impressed at how robust #/description methods are, but that enthusiasm is certainly tempered by cases like this. At the very least, in cases where the output is unsolicited (error messages), it'd likely be wiser to not call #/description when printing an NSObject unless we're more sure than we can be in general that that won't sail off into the ozone. > > Still puzzling over the second problem. Both your earlier email message and the bug report seem to contain references to something named "sce", which doesn't seem to be defined anywhere. In the code that I can see, you seem to be calling #/setDocument: on an NS:PDF-VIEW that's been allocated but not initialized. Doing ? (allocate-instance 'some-standard-clos-class) returns (in the general case) an instance of the specified class where all of the instance's slots are unbound; that's likely not to be as useful an object as the result of MAKE-INSTANCE would have been. Similarly, the NSObject returned by a call to #/alloc on its class isn't yet initialized and is unlikely to behave itself; you generally don't want to do anything with the result of a call to #/alloc but immediately call some flavor of #/init... on it.) ObjC's #/alloc and #/init are similar to ALLOCATE-INSTANCE and INITIALIZE-INSTANCE, but differ in some subtle ways (an #/init method may deallocate its argument and return some other instance.) It's often saner to avoid this gunk and simply use MAKE-INSTANCE: (make-instance some-objc-class) is equivalent to (#/init (#/alloc some-objc-class)) ; all NSObjects respond to #/init and (make-instance some-objc-class :with-x x :and-y y) is equivalent to (#/initWithX:andY: (#/alloc some-objc-class) x y) but may be less error-prone. > > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From ron at awun.net Wed May 27 23:06:08 2009 From: ron at awun.net (Ron Garret) Date: Wed, 27 May 2009 23:06:08 -0700 Subject: [Openmcl-devel] PDFKit crashes In-Reply-To: <20090527192231.M72709@abq.clozure.com> References: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> <20090527192231.M72709@abq.clozure.com> Message-ID: <49452D51-3FDC-44C5-B9F2-E65B81F1BBA4@awun.net> Thanks! It actually turns out that it's the pdf-view that needed to be initialized. It turns out that I've been forgetting to #/init things all over the place but things still mostly work for me. Am I just getting lucky? Should #/init always be called when #/alloc is called? If not, how do you know when you need to call #/init? (Feel free to treat those as rhetorical questions. I'm sure there's a Cocoa memory management primer somewhere that I can go read.) Just for the record, SCE is supposed to be P1. The document I was using to test with originally was called sce.pdf (because it was a scanned electricity bill from Southern California Edison). I intended to rename it to be more generic to avoid confusion and ended up creating more confusion. Sorry about that. Also for the record, I think calling #/description for printing is fine despite the potential fragility. The extra functionality is very useful, and the right way IMO to make it less fragile is with a wrapper layer that handles all the initialization and memory management. rg On May 27, 2009, at 8:13 PM, Gary Byers wrote: > T > > On Wed, 27 May 2009, Ron Garret wrote: > >> >> On May 27, 2009, at 4:19 PM, Ron Garret wrote: >> >>> Trying to open and display a PDF file crashes CCL in various ways. >>> >>> Using this code: >>> >>> (in-package "CL-USER") >>> >>> (require :cocoa) >>> (objc:load-framework "Quartz" :quartz) >>> (defun nsstr (s) (make-instance 'gui::ns-lisp-string :string s)) >>> >>> (defun pdf-from-file (filename) >>> (#/initWithData: (#/alloc ns:pdf-document) >>> (#/dataWithContentsOfFile: ns:ns-data filename))) >>> >>> (defun pdf-from-url (url) >>> (#/initWithUrl: (#/alloc ns:pdf-document) >>> (#/URLWithString: ns:ns-url url))) >>> >> >> So it turns out that this problem is due to misspelling initWithURL >> as >> initWithUrl. Still, it would be good if the result of this were >> not a >> hard crash. > > An ObjC message named #/description is applicable to all NSObjects; it > returns an NSString which ... um, describes the object: > > ? (#/description (#/init (#/alloc ns:ns-object))) > #" (#x12943380)> > > There isn't too much to say about a direct instance of NS:NS-OBJECT, > but > for instances of other classes there's often quite a bit of > information > in the #/description string. The default PRINT-OBJECT method for > NS:NS-OBJECTs > invokes #/description, obtains a lisp string from the ns-string, and > uses > the resulting string (all of it ...) in its output. (As I was typing > this, I saw a message suggesting that this output observe *PRINT- > LENGTH*; > that isn't relevant to the printing of strings, but truncating the > string to some reasonable length would probably be reasonable.) > > In most cases, the existing #/description methods are remarkably > robust, > but in at least some cases - most of which seem to involve objects > that > have been allocated but not yet initialized - they leap before looking > and try to print uninitialized slots in the object: > > ? (#/description (#/alloc ns::pdf-document)) > Unhandled exception 10 at 0x1451647a, context->regs at #xb029b970 > Exception occurred while executing foreign code > at .objc_category_name_NSColor_PDFColorUtilities + 99450 > > > > which looks kind of familiar. So yes, you should have gotten a > runtime > when trying to call a misspelled ObjC method name (which was warned > about) > and in fact you did. The system started to enter a break loop (the > good > news: on the event thread in the context in which the error > occurred; the > bad news: using AltConsole, until something better comes along) but > crashed > trying to print the (uninitialized) NS:NS-PDF-DOCUMENT object by > printing > the string returned by its #/description method. (Look at the > backtrace.) > > I don't know how to tell in general whether or not it's safe to call a > #/description method on an arbitrary NSObject (it certainly seems to > be in the vast majority of cases, but it may be hard to recover from > the cases where it isn't.) Until this point, I'd been fairly > impressed at how robust #/description methods are, but that enthusiasm > is certainly tempered by cases like this. At the very least, in cases > where the output is unsolicited (error messages), it'd likely be wiser > to not call #/description when printing an NSObject unless we're more > sure than we can be in general that that won't sail off into the > ozone. > > >> >> Still puzzling over the second problem. > > Both your earlier email message and the bug report seem to contain > references to something named "sce", which doesn't seem to be defined > anywhere. > > In the code that I can see, you seem to be calling #/setDocument: on > an NS:PDF-VIEW that's been allocated but not initialized. > > Doing > > ? (allocate-instance 'some-standard-clos-class) > > returns (in the general case) an instance of the specified class where > all of the instance's slots are unbound; that's likely not to be as > useful an object as the result of MAKE-INSTANCE would have been. > > Similarly, the NSObject returned by a call to #/alloc on its class > isn't yet initialized and is unlikely to behave itself; you generally > don't want to do anything with the result of a call to #/alloc but > immediately call some flavor of #/init... on it.) ObjC's #/alloc > and #/init are similar to ALLOCATE-INSTANCE and INITIALIZE-INSTANCE, > but differ in some subtle ways (an #/init method may deallocate its > argument and return some other instance.) It's often saner to > avoid this gunk and simply use MAKE-INSTANCE: > > (make-instance some-objc-class) > > is equivalent to > > (#/init (#/alloc some-objc-class)) ; all NSObjects respond to #/init > > and > > (make-instance some-objc-class :with-x x :and-y y) > > is equivalent to > > (#/initWithX:andY: (#/alloc some-objc-class) x y) > > but may be less error-prone. > >> >> rg >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> From rme at clozure.com Wed May 27 23:43:10 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 28 May 2009 02:43:10 -0400 Subject: [Openmcl-devel] PDFKit crashes In-Reply-To: <49452D51-3FDC-44C5-B9F2-E65B81F1BBA4@awun.net> References: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> <20090527192231.M72709@abq.clozure.com> <49452D51-3FDC-44C5-B9F2-E65B81F1BBA4@awun.net> Message-ID: <19FC59BC-2BFE-47D2-A91F-C393E5696046@clozure.com> On May 28, 2009, at 2:06 AM, Ron Garret wrote: > It turns out that I've been forgetting to #/init things all over the > place but things still mostly work for me. Am I just getting lucky? > Should #/init always be called when #/alloc is called? Yes, either #/init or some more specific initializer, e.g. #/ initWithFrame:, etc. There's also the #/new method, which combines #/alloc and #/init into one, but using it is apparently not considered stylish any more. > If not, how do > you know when you need to call #/init? (Feel free to treat those as > rhetorical questions. I'm sure there's a Cocoa memory management > primer somewhere that I can go read.) From gb at clozure.com Thu May 28 00:15:10 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 28 May 2009 01:15:10 -0600 (MDT) Subject: [Openmcl-devel] PDFKit crashes In-Reply-To: <19FC59BC-2BFE-47D2-A91F-C393E5696046@clozure.com> References: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> <20090527192231.M72709@abq.clozure.com> <49452D51-3FDC-44C5-B9F2-E65B81F1BBA4@awun.net> <19FC59BC-2BFE-47D2-A91F-C393E5696046@clozure.com> Message-ID: <20090528004627.M72709@abq.clozure.com> On Thu, 28 May 2009, R. Matthew Emerson wrote: > > On May 28, 2009, at 2:06 AM, Ron Garret wrote: > >> It turns out that I've been forgetting to #/init things all over the >> place but things still mostly work for me. Am I just getting lucky? >> Should #/init always be called when #/alloc is called? > > Yes, either #/init or some more specific initializer, e.g. #/ > initWithFrame:, etc. > > There's also the #/new method, which combines #/alloc and #/init into > one, but using it is apparently not considered stylish any more. I personally consider MAKE-INSTANCE to be at least somewhat stylish. (MAKE-INSTANCE class) == (#/new class) == (#/init (#/alloc class)) (MAKE-INSTANCE class {:with-pseudo-initarg-keyword value}+) uses the provided set of keywords to construct an #/init... function name (there's some caching involved ...) and does (#/thatInitFunction: (#/alloc class) , at values) It's not as high-level as it might look - a set of keywords that map to an init function name have to all be present and present in the canonical order for this to work - but things like: (make-instance window-class :with-content-rect rect :style-mask style-mask :backing backing-type :defer nil) may (or may not) look more readable than: (#/initWithContentRect:styleMask:backing:defer: (#/alloc window-class) rect style-mask backing-type nil) though (modulo typos) the two forms should have equivalent effect. > > >> If not, how do >> you know when you need to call #/init? (Feel free to treat those as >> rhetorical questions. I'm sure there's a Cocoa memory management >> primer somewhere that I can go read.) > > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From ron at awun.net Thu May 28 01:04:00 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 01:04:00 -0700 Subject: [Openmcl-devel] PDFKit crashes In-Reply-To: <20090528004627.M72709@abq.clozure.com> References: <63CD1172-40EB-4F71-9E7F-09E4F9E00241@awun.net> <20090527192231.M72709@abq.clozure.com> <49452D51-3FDC-44C5-B9F2-E65B81F1BBA4@awun.net> <19FC59BC-2BFE-47D2-A91F-C393E5696046@clozure.com> <20090528004627.M72709@abq.clozure.com> Message-ID: That's pretty slick, though I have to confess a certain dismay that there seem to be three different conventions for translating lisp symbol names into ObjC method names (corresponding roughly to some- objc-method, #/SomeOBJCMethod, and omeethod. I see in the docs where it describes how to use make-instance to instantiate ObjC classes it says: "In some special cases, such as loading an ns:ns-window-controller from a .nib file, it may be necessary for you to pass the instance itself as one of the parameters to the initialization method." Can you be a little more specific about the circumstances under which these special cases arise? And as long as I'm asking random ObjC bridge questions, the 1.3 release notes say: "The Objective-C bridge no longer converts lisp strings to NSString instances automatically." Why not? I thought that was a handy feature. Is it a memory management issue? rg On May 28, 2009, at 12:15 AM, Gary Byers wrote: > > > On Thu, 28 May 2009, R. Matthew Emerson wrote: > >> >> On May 28, 2009, at 2:06 AM, Ron Garret wrote: >> >>> It turns out that I've been forgetting to #/init things all over the >>> place but things still mostly work for me. Am I just getting lucky? >>> Should #/init always be called when #/alloc is called? >> >> Yes, either #/init or some more specific initializer, e.g. #/ >> initWithFrame:, etc. >> >> There's also the #/new method, which combines #/alloc and #/init into >> one, but using it is apparently not considered stylish any more. > > I personally consider MAKE-INSTANCE to be at least somewhat stylish. > > (MAKE-INSTANCE class) == (#/new class) == (#/init (#/alloc class)) > > (MAKE-INSTANCE class {:with-pseudo-initarg-keyword value}+) > > uses the provided set of keywords to construct an #/init... function > name (there's some caching involved ...) and does > > (#/thatInitFunction: (#/alloc class) , at values) > > It's not as high-level as it might look - a set of keywords that map > to an init function name have to all be present and present in the > canonical order for this to work - but things like: > > (make-instance window-class > :with-content-rect rect > :style-mask style-mask > :backing backing-type > :defer nil) > > may (or may not) look more readable than: > > (#/initWithContentRect:styleMask:backing:defer: (#/alloc window-class) > rect > style-mask > backing-type > nil) > > > though (modulo typos) the two forms should have equivalent effect. > >> >> >>> If not, how do >>> you know when you need to call #/init? (Feel free to treat those as >>> rhetorical questions. I'm sure there's a Cocoa memory management >>> primer somewhere that I can go read.) >> >> > /apple_ref/doc/uid/TP40002974-CH4-SW17 >> > >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at mcaleely.com Thu May 28 01:42:48 2009 From: john at mcaleely.com (John McAleely) Date: Thu, 28 May 2009 09:42:48 +0100 Subject: [Openmcl-devel] bug reports and suggestions In-Reply-To: <20CD40B2-9B16-4E56-B202-85E4F49F1BE6@clozure.com> References: <20CD40B2-9B16-4E56-B202-85E4F49F1BE6@clozure.com> Message-ID: Thanks - I've opened tickets for the remaining items in my 'Visual Bugs in the IDE' thread. I also finally got the chance to try the IDE again for some real coding. the effort failed about 10 lines in when I had to enter a # character. (ticket 511 'it is hard to type # on a uk keyboard') J On 22 May 2009, at 02:34, R. Matthew Emerson wrote: > I encourage everyone to consider creating Trac tickets for bugs and > feature suggestions. > From lisp at clairvaux.org Thu May 28 03:15:19 2009 From: lisp at clairvaux.org (Glen Foy) Date: Thu, 28 May 2009 06:15:19 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> Message-ID: <1DB44BC1-7E2F-4CCD-9332-9954A44140E7@clairvaux.org> On May 27, 2009, at 10:07 PM, Laughing Water wrote: > make the effort to understand the points others are trying to make. Cavallero had no point. He was merely bashing CCL. You have no point either. From info at mracpublishing.com Thu May 28 04:47:28 2009 From: info at mracpublishing.com (Janusz Podrazik) Date: Thu, 28 May 2009 13:47:28 +0200 Subject: [Openmcl-devel] window size & position Message-ID: is there any possibility to add to the preferences the functionality which is indicated but not implemented. i am talking about the size, position and memory of all windows, dialog boxes etc... i think would be very desirable to open CCL and see all the editors open were you left the CCL last. the 'Quit' by default should store all the information - with out extra 'snapshot' functionality. it is very time consuming and frustrating to live with out this functionality. any time soon? janusz podrazik From terje at in-progress.com Thu May 28 08:12:41 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Thu, 28 May 2009 08:12:41 -0700 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <1DB44BC1-7E2F-4CCD-9332-9954A44140E7@clairvaux.org> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> <1DB44BC1-7E2F-4CCD-9332-9954A44140E7@clairvaux.org> Message-ID: <5EED72D0-F190-49ED-BBBE-33E7B84CB778@in-progress.com> On May 28, 2009, at 3:15 AM, Glen Foy wrote: > On May 27, 2009, at 10:07 PM, Laughing Water wrote: > >> make the effort to understand the points others are trying to make. > > Cavallero had no point. He was merely bashing CCL. You have no point > either. I would like to point out that this debate is point-less... That's my point. At least I have one. ;-) Back to work! -- Terje From lisp at clairvaux.org Thu May 28 09:00:08 2009 From: lisp at clairvaux.org (Glen Foy) Date: Thu, 28 May 2009 12:00:08 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <5EED72D0-F190-49ED-BBBE-33E7B84CB778@in-progress.com> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> <1DB44BC1-7E2F-4CCD-9332-9954A44140E7@clairvaux.org> <5EED72D0-F190-49ED-BBBE-33E7B84CB778@in-progress.com> Message-ID: I have but one point. Criticisms are fine and even valuable, but they should be thoughtful, carefully framed and offered with encouragement, and useful alternatives. Saying we should chuck Hemlock when Clozure's hackers are hard at work making improvements does not help the discussion. That said, my snide remark was inappropriate. You have to expect occasional slips from "brain damaged" posters. On May 28, 2009, at 11:12 AM, Terje Norderhaug wrote: > On May 28, 2009, at 3:15 AM, Glen Foy wrote: >> On May 27, 2009, at 10:07 PM, Laughing Water wrote: >> >>> make the effort to understand the points others are trying to make. >> >> Cavallero had no point. He was merely bashing CCL. You have no >> point >> either. > > I would like to point out that this debate is point-less... > > That's my point. At least I have one. ;-) > > Back to work! > > -- Terje > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From lw at mt.net Thu May 28 09:20:54 2009 From: lw at mt.net (Laughing Water) Date: Thu, 28 May 2009 10:20:54 -0600 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> <1DB44BC1-7E2F-4CCD-9332-9954A44140E7@clairvaux.org> <5EED72D0-F190-49ED-BBBE-33E7B84CB778@in-progress.com> Message-ID: Thank you, Glen! LW On May 28, 2009, at 10:00 AM, Glen Foy wrote: > I have but one point. > > Criticisms are fine and even valuable, but they should be thoughtful, > carefully framed and offered with encouragement, and useful > alternatives. Saying we should chuck Hemlock when Clozure's hackers > are hard at work making improvements does not help the discussion. > > That said, my snide remark was inappropriate. You have to expect > occasional slips from "brain damaged" posters. > > > > > On May 28, 2009, at 11:12 AM, Terje Norderhaug wrote: > >> On May 28, 2009, at 3:15 AM, Glen Foy wrote: >>> On May 27, 2009, at 10:07 PM, Laughing Water wrote: >>> >>>> make the effort to understand the points others are trying to make. >>> >>> Cavallero had no point. He was merely bashing CCL. You have no >>> point >>> either. >> >> I would like to point out that this debate is point-less... >> >> That's my point. At least I have one. ;-) >> >> Back to work! >> >> -- Terje >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From raffaelcavallaro at mac.com Thu May 28 09:27:53 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Thu, 28 May 2009 12:27:53 -0400 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> <1DB44BC1-7E2F-4CCD-9332-9954A44140E7@clairvaux.org> <5EED72D0-F190-49ED-BBBE-33E7B84CB778@in-progress.com> Message-ID: <4758997B-7FA2-44AF-AD8F-A8114B7EF4C1@mac.com> On May 28, 2009, at 12:00 PM, Glen Foy wrote: > Criticisms are fine and even valuable, but they should be thoughtful, > carefully framed and offered with encouragement, and useful > alternatives. For my part I'm sorry if my comments here have made the Clozure developers feel unappreciated. I am sincerely grateful for all their hard work on CCL. regards, Ralph Raffael Cavallaro raffaelcavallaro at gmail.com From lw at mt.net Thu May 28 09:46:27 2009 From: lw at mt.net (Laughing Water) Date: Thu, 28 May 2009 10:46:27 -0600 Subject: [Openmcl-devel] CCL is a mess In-Reply-To: <4758997B-7FA2-44AF-AD8F-A8114B7EF4C1@mac.com> References: <698E7973-DC78-42D6-BE12-5C890C9EE5E4@cs.colorado.edu> <36923DB0-838C-46FB-A198-03094DD1A795@mac.com> <37E297B1-12E2-4E0C-A039-8A6CF8100221@clairvaux.org> <63DDD191-CB51-4A5F-B58B-0C1A83932381@clairvaux.org> <80A8E98C-72B2-43D8-A95F-4DCF106074A8@mt.net> <1DB44BC1-7E2F-4CCD-9332-9954A44140E7@clairvaux.org> <5EED72D0-F190-49ED-BBBE-33E7B84CB778@in-progress.com> <4758997B-7FA2-44AF-AD8F-A8114B7EF4C1@mac.com> Message-ID: <94B6AB67-4F3C-4F20-9E5A-D3C112987700@mt.net> And thank you, Ralph! You and Glen both have a lot to contribute and both had something worth saying. I apologize to anyone who thinks this is off-subject, but computer programming, CCL and this discussion group are all forms of communication. We will succeed to the extent that they are high- quality forms of communication. LW On May 28, 2009, at 10:27 AM, Raffael Cavallaro wrote: > > On May 28, 2009, at 12:00 PM, Glen Foy wrote: > >> Criticisms are fine and even valuable, but they should be thoughtful, >> carefully framed and offered with encouragement, and useful >> alternatives. > > For my part I'm sorry if my comments here have made the Clozure > developers feel unappreciated. I am sincerely grateful for all their > hard work on CCL. > > regards, > > Ralph > > > Raffael Cavallaro > raffaelcavallaro at gmail.com > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Thu May 28 10:42:24 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 10:42:24 -0700 Subject: [Openmcl-devel] Hemlock to Cocoa interface docs? In-Reply-To: References: Message-ID: <06AD81A6-456D-432D-B841-1E3C9A4C5E6E@awun.net> Is there any documentation about how Hemlock interfaces to Cocoa? I'm trying to do some editor customization by moving buffer marks around using the published Hemlock interface commands, but that seems to produce a disconnect between the apparent state of the Hemlock buffer and the display. For example, if I do this: (hi::form-offset (hi::buffer-point some-buffer) 1) that will move the buffer point forward by one sexpr, but the cursor is still displayed in its old position until after the next keystroke. Thanks, rg From gb at clozure.com Thu May 28 11:19:12 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 28 May 2009 12:19:12 -0600 (MDT) Subject: [Openmcl-devel] window size & position In-Reply-To: References: Message-ID: <20090528110452.H72709@abq.clozure.com> We've been using the builtin Cocoa facilities for keeping track of window size and position across sessions in the trunk version of the IDE for a few weeks now. That's not quite the same as saving and restoring the whole state of the world between sessions, but it does mean that named editor documents and listeners open with the size and position that they had when they were last closed. There aren't too many things that can go wrong there. Cocoa just writes the window's bounds rectangle and the screen's to the preferences file, and I assume that if you change monitors or screen resolutions between sessions it'll try to do something reasonable to adjust to that. (I haven't tried this, and don't know how reasonable its behavior is.) Someone has said (somewhere) that if a saved window's height is exactly the same as the screen height it's restored to slightly smaller dimensions; if that's true, I don't know why or what should be done about it, but I'm willing to say that the scheme works out-of-the-box in 99% of all cases, AFAIK. Nothing in that scheme knows or cares if the file's contents have changed between sessions; we're just saying that "/path/to/foo.lisp" has a certain frame rectangle associated with it, and that whenever "/path/to/foo.lisp" is opened, it should use the size and position specified by that rectangle. Some of the other things that people say they want are more sensitive to whether or not the file's externally modified (by a source code control system, by editing it in emacs, ...) between sessions. (For instance, keeping track of the selection in some externalizable format - integers representing offset and length - would be Really Neat if the file isn't externally modified between sessions and could be Really Stupid if such an external modification occurred and was undetected. Those aren't necessarily insurmountable problems, but I'm not sure whether it's desirable for an editor to act like it's the only thing that could modify a text file and to treat violations of that assumption as being exceptional in some way; that doesn't seem to have much to do with the real world. On Thu, 28 May 2009, Janusz Podrazik wrote: > is there any possibility to add to the preferences the functionality > which is indicated but not implemented. > i am talking about the size, position and memory of all windows, > dialog boxes etc... > i think would be very desirable to open CCL and see all the editors > open were you left the CCL last. > the 'Quit' by default should store all the information - with out > extra 'snapshot' functionality. > it is very time consuming and frustrating to live with out this functionality. > > any time soon? > > janusz podrazik > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From mevins at mac.com Thu May 28 11:24:14 2009 From: mevins at mac.com (mikel evins) Date: Thu, 28 May 2009 13:24:14 -0500 Subject: [Openmcl-devel] window size & position In-Reply-To: <20090528110452.H72709@abq.clozure.com> References: <20090528110452.H72709@abq.clozure.com> Message-ID: <5FF85E39-E0B3-456B-A28C-506398F54CB9@mac.com> On May 28, 2009, at 1:19 PM, Gary Byers wrote: > There aren't too many things that can go wrong there. Cocoa just > writes the window's bounds rectangle and the screen's to the > preferences file, and I assume that if you change monitors or screen > resolutions between sessions it'll try to do something reasonable to > adjust to that. (I haven't tried this, and don't know how reasonable > its behavior is.) If the remembered window is entirely offscreen, then the Window Manager nudges it toward the screen until a grabbable hunk of window is on the screen. --me From info at mracpublishing.com Thu May 28 12:14:41 2009 From: info at mracpublishing.com (Janusz Podrazik) Date: Thu, 28 May 2009 21:14:41 +0200 Subject: [Openmcl-devel] window size & position In-Reply-To: <20090528110452.H72709@abq.clozure.com> References: <20090528110452.H72709@abq.clozure.com> Message-ID: On Thu, May 28, 2009 at 20:19, Gary Byers wrote: > We've been using the builtin Cocoa facilities for keeping track of > window size and position across sessions in the trunk version of the > IDE for a few weeks now. ?That's not quite the same as saving and > restoring the whole state of the world between sessions, but it does > mean that named editor documents and listeners open with the size > and position that they had when they were last closed. > is not working on/with Clozure CL-x8664 (Welcome to Clozure Common Lisp Version 1.3-r12149M (DarwinX8664) !) no position or size of any window, listener or editor is restored to the position or size you are have save/close the window or quit the CCL. good example for getting back were you have left it off is VisualWorks. most of the time my work is 'in progress', hardly ever completed. returning to you work were you left off is essential in my mind. it is essay to star new one then restore each time the previous one which may include many files, ref docs etc... the productivity and piece of mind is apparent. we are talking about a preferences option - and useful option too. > There aren't too many things that can go wrong there. ?Cocoa just > writes the window's bounds rectangle and the screen's to the > preferences file, and I assume that if you change monitors or screen > resolutions between sessions it'll try to do something reasonable to > adjust to that. ?(I haven't tried this, and don't know how reasonable > its behavior is.) ?Someone has said (somewhere) that if a saved > window's height is exactly the same as the screen height it's restored > to slightly smaller dimensions; if that's true, I don't know why or > what should be done about it, but I'm willing to say that the scheme > works out-of-the-box in 99% of all cases, AFAIK. if we take all possibile scenarios in account (and we often try to do that - i do and fall many times :-) ) we never would finish or make any useful/time essential decisions. i think many of use - i assume - would welcome this functionally. > > Nothing in that scheme knows or cares if the file's contents have > changed between sessions; we're just saying that "/path/to/foo.lisp" > has a certain frame rectangle associated with it, and that whenever > "/path/to/foo.lisp" is opened, it should use the size and position > specified by that rectangle. > > Some of the other things that people say they want are more sensitive > to whether or not the file's externally modified (by a source code > control system, by editing it in emacs, ...) between sessions. ?(For > instance, keeping track of the selection in some externalizable format - > integers representing offset and length - would be Really Neat if the > file isn't externally modified between sessions and could be Really > Stupid if such an external modification occurred and was undetected. > > Those aren't necessarily insurmountable problems, but I'm not sure > whether it's desirable for an editor to act like it's the only thing > that could modify a text file and to treat violations of that > assumption as being exceptional in some way; that doesn't seem to > have much to do with the real world. > > On Thu, 28 May 2009, Janusz Podrazik wrote: > >> is there any possibility to add to the preferences the functionality >> which is indicated but not implemented. >> i am talking about the size, position and memory of all windows, >> dialog boxes etc... >> i think would be very desirable to open CCL and see all the editors >> open were you left the CCL last. >> the 'Quit' by default should store all the information - with out >> extra 'snapshot' functionality. >> it is very time consuming and frustrating to live with out this >> functionality. >> >> any time soon? >> >> janusz podrazik >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> > From ron at awun.net Thu May 28 13:11:14 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 13:11:14 -0700 Subject: [Openmcl-devel] Handling mouse events In-Reply-To: References: <20090528110452.H72709@abq.clozure.com> Message-ID: <47800A75-6C8C-498C-AE2D-7ADFA9824D2D@awun.net> Before I go reinventing the wheel, does anyone have any demo code that handles mouse events, like maybe a little scribble window or something like that? Thanks, rg From gb at clozure.com Thu May 28 13:32:10 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 28 May 2009 14:32:10 -0600 (MDT) Subject: [Openmcl-devel] window size & position In-Reply-To: References: <20090528110452.H72709@abq.clozure.com> Message-ID: <20090528142633.K72709@abq.clozure.com> On Thu, 28 May 2009, Janusz Podrazik wrote: > On Thu, May 28, 2009 at 20:19, Gary Byers wrote: >> We've been using the builtin Cocoa facilities for keeping track of >> window size and position across sessions in the trunk version of the >> IDE for a few weeks now. ?That's not quite the same as saving and >> restoring the whole state of the world between sessions, but it does >> mean that named editor documents and listeners open with the size >> and position that they had when they were last closed. >> > > is not working on/with Clozure CL-x8664 (Welcome to Clozure Common > Lisp Version 1.3-r12149M (DarwinX8664) !) > no position or size of any window, listener or editor is restored to > the position or size you are have save/close the window or quit the > CCL. No, it isn't; that's not the trunk. See: From rme at clozure.com Thu May 28 13:57:19 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 28 May 2009 16:57:19 -0400 Subject: [Openmcl-devel] Cocoa IDE support on Tiger Message-ID: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X 10.4). There are, however, features in Leopard that I'd like to use, and I was wondering what the general reaction would be to the idea of making the Cocoa IDE require Leopard. From ron at awun.net Thu May 28 14:07:38 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 14:07:38 -0700 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: Fine with me. On May 28, 2009, at 1:57 PM, R. Matthew Emerson wrote: > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Thu May 28 14:52:17 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 14:52:17 -0700 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) Message-ID: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> Still trying to display PDF files. It's mostly working, but I've encountered another weird (to me) problem. I can display multiple PDF files in multiple windows, but if I try to move a PDF file from one window to a different one I get crashes. The two weird things are that the crashes are pretty reliable, but not 100% reproducible. Every now and then I get a session where the crash seems to not happen. And also the crash is set up by moving a PDF from one window to another, but it doesn't actually happen until you try to scroll or resize the window. Demo code follows. I've already checked the obvious things like the reference counts on the PDF files dropping to zero and everything seems OK. Thanks, rg --- (in-package "CL-USER") (objc:load-framework "Quartz" :quartz) (defun nsstr (s) (make-instance 'gui::ns-lisp-string :string s)) (defun pdf-from-url (url) (make-instance ns:pdf-document :init-with-url (make-instance ns:ns-url :init-with-string url))) (defun make-ns-window (x y &optional (title "Untitled")) (let ((nsw (make-instance 'ns:ns-window :with-content-rect (ns:make-ns-rect 0 0 x y) :style-mask 15 :backing #$NSBackingStoreBuffered :defer t))) (#/setTitle: nsw (nsstr title)) (#/setReleasedWhenClosed: nsw nil) (#/center nsw) (#/orderFront: nsw nil) nsw)) (setf p1 (pdf-from-url #@"http://www.flownet.com/ron/test.pdf")) (setf v1 (#/init (#/alloc ns:pdf-view))) (setf w1 (make-ns-window 400 600 "W1")) (#/setContentView: w1 v1) (setf p2 (pdf-from-url #@"http://www.flownet.com/ron/specials.pdf")) (setf v2 (#/init (#/alloc ns:pdf-view))) (setf w2 (make-ns-window 400 600 "W2")) (#/setContentView: w2 v2) (#/setDocument: v1 p1) (#/setDocument: v2 p2) (#/setDocument: v1 nil) (#/setDocument: v1 p1) (#/setDocument: v2 nil) (#/setDocument: v2 p2) ; Stop here and try scrolling and resizing the windows. It should still work. (#/setDocument: v1 nil) (#/setDocument: v2 nil) (#/setDocument: v1 p2) (#/setDocument: v2 p1) ; Scrolling and resizing at this point should cause CCL to crash From arthur.cater at ucd.ie Thu May 28 15:02:05 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Thu, 28 May 2009 23:02:05 +0100 Subject: [Openmcl-devel] Handling mouse events In-Reply-To: <47800A75-6C8C-498C-AE2D-7ADFA9824D2D@awun.net> References: <20090528110452.H72709@abq.clozure.com> <47800A75-6C8C-498C-AE2D-7ADFA9824D2D@awun.net> Message-ID: Sorry I have no demo code for that, but I can tell you that instances of easygui::drawing-view can be created with keyword arguments :mouse-enter ? :mouse-exit ? :mouse-move ?? :mouse-down ?and ? :mouse-up. There's also :mouse-dragged. The values should be functions that like being called with?an easygui::view and further keyword arguments, notably :event. I have myself used :mouse-enter :mouse-exit and :mouse-down only. The code (in ccl/examples/cocoa/easygui/views.lisp) could do with further improvement, feel free! There is demo code in ccl/examples/cocoa/easygui/example/extended-demo.lisp which creates various nested easygui views, one of which is a drawing-view with a :mouse-down initarg. Maybe that is a tiny help, I hope so. Arthur ----- Original Message ----- From: Ron Garret Date: Thursday, May 28, 2009 9:14 pm Subject: [Openmcl-devel] Handling mouse events To: Openmcl-devel Devel > Before I go reinventing the wheel, does anyone have any demo > code that? > handles mouse events, like maybe a little scribble window or > something? > like that? > > Thanks, > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at mcaleely.com Thu May 28 15:03:51 2009 From: john at mcaleely.com (John McAleely) Date: Thu, 28 May 2009 23:03:51 +0100 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <5777862D-BDC7-4CC8-A015-134B59CE9644@mcaleely.com> Given the imminent release of Snow Leopard, requiring Leopard seems a reasonable move. I'd be happy with that. J On 28 May 2009, at 21:57, R. Matthew Emerson wrote: > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From ron at awun.net Thu May 28 15:07:17 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 15:07:17 -0700 Subject: [Openmcl-devel] Handling mouse events In-Reply-To: References: <20090528110452.H72709@abq.clozure.com> <47800A75-6C8C-498C-AE2D-7ADFA9824D2D@awun.net> Message-ID: <22BF716E-AE2A-4D51-8950-5F38E96D6D65@awun.net> That's great, thanks! rg On May 28, 2009, at 3:02 PM, Arthur W Cater wrote: > Sorry I have no demo code for that, but I can tell you that > instances of easygui::drawing-view > can be created with keyword arguments :mouse-enter :mouse- > exit :mouse-move > :mouse-down and :mouse-up. There's also :mouse-dragged. > The values should be functions that like being called with an > easygui::view and further > keyword arguments, notably :event. > I have myself used :mouse-enter :mouse-exit and :mouse-down only. > The code (in ccl/examples/cocoa/easygui/views.lisp) could do with > further improvement, feel free! > There is demo code in ccl/examples/cocoa/easygui/example/extended- > demo.lisp which creates > various nested easygui views, one of which is a drawing-view with > a :mouse-down initarg. > Maybe that is a tiny help, I hope so. > > Arthur > > ----- Original Message ----- > From: Ron Garret > Date: Thursday, May 28, 2009 9:14 pm > Subject: [Openmcl-devel] Handling mouse events > To: Openmcl-devel Devel > > > Before I go reinventing the wheel, does anyone have any demo > > code that > > handles mouse events, like maybe a little scribble window or > > something > > like that? > > > > Thanks, > > rg > > > > _______________________________________________ > > Openmcl-devel mailing list > > Openmcl-devel at clozure.com > > http://clozure.com/mailman/listinfo/openmcl-devel From raffaelcavallaro at mac.com Thu May 28 15:48:51 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Thu, 28 May 2009 18:48:51 -0400 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <7B796004-B17B-49A2-B658-20ACCCC4F3C4@mac.com> On May 28, 2009, at 4:57 PM, R. Matthew Emerson wrote: > I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. works for me as well. regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From lw at mt.net Thu May 28 16:05:51 2009 From: lw at mt.net (Laughing Water) Date: Thu, 28 May 2009 17:05:51 -0600 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <2C5E5DAB-D1A7-4AE1-A95A-9A0DC6E59D95@mt.net> I'm not even a user yet; so don't give my needs much weight. But requiring Leopard would be fine with me. On May 28, 2009, at 2:57 PM, R. Matthew Emerson wrote: > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From raffaelcavallaro at mac.com Thu May 28 16:07:01 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Thu, 28 May 2009 19:07:01 -0400 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> Message-ID: On May 28, 2009, at 5:52 PM, Ron Garret wrote: > I've already checked the > obvious things like the reference counts on the PDF files dropping to > zero and everything seems OK. I don't see the effect you're seeing - I've tried several times already. However, I notice you're doing gui things without ensuring they happen on the main thread. Could this be it? Apple want you to use performSelectorOnMainThread:withObject:yadaYadaYada & co. FWIW, I use this for all calls that frob GUI entities - it accomplishes the same thing, but unlike the above Cocoa call, it isn't limited to a single parameter: (in-package :ccl) (defmacro gui-do (&body body) (let ((values-list (gensym "GUI-DO-VALUES-LIST")) (sem (gensym "GUI-DO-SEMAPHORE"))) `(if (eq *current-process* ccl::*initial-process*) (progn , at body) (let* ((,sem (make-semaphore)) (,values-list nil)) (process-interrupt ccl::*initial-process* (lambda () (setq ,values-list (multiple-value-list (progn , at body))) (signal-semaphore ,sem))) (wait-on-semaphore ,sem) (values-list ,values-list))))) I also have another version which doesn't wait for the return value(s) if you're interested. So calls to things like #/setContentView: I would wrap thus: (gui-do (#/setContentView: ... etc. just to ensure they happen on the main thread. Hopefully the Clozure crew will let me know if this is really wrongheaded. regards, Raffael Cavallaro raffaelcavallaro at me.com From danieldickison at gmail.com Thu May 28 16:19:51 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Thu, 28 May 2009 19:19:51 -0400 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <1E6A6457-8C69-4E5A-94A9-F5225098EAE0@gmail.com> Add another "fine with me" vote. AFAIK the people at my workplace who use ccl are already on leopard (including myself). It seems that there are few backwards compatibility issues with OS X updade so there's not much resistance to upgrading. Sent from my iPhone On May 28, 2009, at 16:57, "R. Matthew Emerson" wrote: > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From gz at clozure.com Thu May 28 16:28:31 2009 From: gz at clozure.com (Gail Zacharias) Date: Thu, 28 May 2009 19:28:31 -0400 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> Message-ID: <200905282330.KWY01660@mr08.lnh.mail.rcn.net> Yup. We have gui::execute-in-gui along the same lines. We don't have exports and documentation for the GUI package yet, but this will be one of the first things to export once we do.... At 5/28/2009 07:07 PM, Raffael Cavallaro wrote: >On May 28, 2009, at 5:52 PM, Ron Garret wrote: > > > I've already checked the > > obvious things like the reference counts on the PDF files dropping to > > zero and everything seems OK. > > >I don't see the effect you're seeing - I've tried several times >already. However, I notice you're doing gui things without ensuring >they happen on the main thread. Could this be it? Apple want you to >use performSelectorOnMainThread:withObject:yadaYadaYada & co. > >FWIW, I use this for all calls that frob GUI entities - it >accomplishes the same thing, but unlike the above Cocoa call, it isn't >limited to a single parameter: > >(in-package :ccl) > >(defmacro gui-do (&body body) > (let ((values-list (gensym "GUI-DO-VALUES-LIST")) > (sem (gensym "GUI-DO-SEMAPHORE"))) > `(if (eq *current-process* ccl::*initial-process*) > (progn , at body) > (let* ((,sem (make-semaphore)) > (,values-list nil)) > (process-interrupt > ccl::*initial-process* > (lambda () > (setq ,values-list (multiple-value-list (progn , at body))) > (signal-semaphore ,sem))) > (wait-on-semaphore ,sem) > (values-list ,values-list))))) > >I also have another version which doesn't wait for the return value(s) >if you're interested. > >So calls to things like #/setContentView: I would wrap thus: (gui-do >(#/setContentView: ... etc. just to ensure they happen on the main >thread. > >Hopefully the Clozure crew will let me know if this is really >wrongheaded. > >regards, > > > > > >Raffael Cavallaro >raffaelcavallaro at me.com > > > > > >_______________________________________________ >Openmcl-devel mailing list >Openmcl-devel at clozure.com >http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Thu May 28 16:40:53 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 16:40:53 -0700 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: <200905282330.KWY01660@mr08.lnh.mail.rcn.net> References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> <200905282330.KWY01660@mr08.lnh.mail.rcn.net> Message-ID: <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> I tried wrapping all the run-time calls in both gui::execute-in-gui and easygui::run-on-main-thread (not at the same time of course) and I still see the same behavior. BTW, it's a really hard crash. Sometimes it just quits without even bringing up the AltConsole. Sometimes it brings up the AltConsole and spews and endless stream of "Unhandled exception 10" messages there. rg On May 28, 2009, at 4:28 PM, Gail Zacharias wrote: > Yup. We have gui::execute-in-gui along the same lines. We don't > have exports and documentation for the GUI package yet, but this will > be one of the first things to export once we do.... > > > At 5/28/2009 07:07 PM, Raffael Cavallaro wrote: > >> On May 28, 2009, at 5:52 PM, Ron Garret wrote: >> >>> I've already checked the >>> obvious things like the reference counts on the PDF files dropping >>> to >>> zero and everything seems OK. >> >> >> I don't see the effect you're seeing - I've tried several times >> already. However, I notice you're doing gui things without ensuring >> they happen on the main thread. Could this be it? Apple want you to >> use performSelectorOnMainThread:withObject:yadaYadaYada & co. >> >> FWIW, I use this for all calls that frob GUI entities - it >> accomplishes the same thing, but unlike the above Cocoa call, it >> isn't >> limited to a single parameter: >> >> (in-package :ccl) >> >> (defmacro gui-do (&body body) >> (let ((values-list (gensym "GUI-DO-VALUES-LIST")) >> (sem (gensym "GUI-DO-SEMAPHORE"))) >> `(if (eq *current-process* ccl::*initial-process*) >> (progn , at body) >> (let* ((,sem (make-semaphore)) >> (,values-list nil)) >> (process-interrupt >> ccl::*initial-process* >> (lambda () >> (setq ,values-list (multiple-value-list (progn , at body))) >> (signal-semaphore ,sem))) >> (wait-on-semaphore ,sem) >> (values-list ,values-list))))) >> >> I also have another version which doesn't wait for the return >> value(s) >> if you're interested. >> >> So calls to things like #/setContentView: I would wrap thus: (gui-do >> (#/setContentView: ... etc. just to ensure they happen on the main >> thread. >> >> Hopefully the Clozure crew will let me know if this is really >> wrongheaded. >> >> regards, >> >> >> >> >> >> Raffael Cavallaro >> raffaelcavallaro at me.com >> >> >> >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Thu May 28 17:02:43 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 17:02:43 -0700 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> <200905282330.KWY01660@mr08.lnh.mail.rcn.net> <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> Message-ID: <08D8F9A3-AE5A-4D85-BA18-D23CD509EF79@awun.net> More info: 1. The circumstances under which the crash occurs are not completely reproducible. ~90% of the time it crashes when I try to switch a document to a new PDFView, but on a few occasions I do this and it doesn't crash, and on a few occasions it crashes without my having done this. 2. If anything, wrapping things in gui::execute-in-gui makes the situation worse, not better. 3. The behavior seems to be the same on the trunk and the 1.3 branch. 4. I'm running 10.5.7 5. My next step is try to reproduce this in pure ObjC. rg On May 28, 2009, at 4:40 PM, Ron Garret wrote: > I tried wrapping all the run-time calls in both gui::execute-in-gui > and easygui::run-on-main-thread (not at the same time of course) and I > still see the same behavior. > > BTW, it's a really hard crash. Sometimes it just quits without even > bringing up the AltConsole. Sometimes it brings up the AltConsole and > spews and endless stream of "Unhandled exception 10" messages there. > > rg > > On May 28, 2009, at 4:28 PM, Gail Zacharias wrote: > >> Yup. We have gui::execute-in-gui along the same lines. We don't >> have exports and documentation for the GUI package yet, but this will >> be one of the first things to export once we do.... >> >> >> At 5/28/2009 07:07 PM, Raffael Cavallaro wrote: >> >>> On May 28, 2009, at 5:52 PM, Ron Garret wrote: >>> >>>> I've already checked the >>>> obvious things like the reference counts on the PDF files dropping >>>> to >>>> zero and everything seems OK. >>> >>> >>> I don't see the effect you're seeing - I've tried several times >>> already. However, I notice you're doing gui things without ensuring >>> they happen on the main thread. Could this be it? Apple want you to >>> use performSelectorOnMainThread:withObject:yadaYadaYada & co. >>> >>> FWIW, I use this for all calls that frob GUI entities - it >>> accomplishes the same thing, but unlike the above Cocoa call, it >>> isn't >>> limited to a single parameter: >>> >>> (in-package :ccl) >>> >>> (defmacro gui-do (&body body) >>> (let ((values-list (gensym "GUI-DO-VALUES-LIST")) >>> (sem (gensym "GUI-DO-SEMAPHORE"))) >>> `(if (eq *current-process* ccl::*initial-process*) >>> (progn , at body) >>> (let* ((,sem (make-semaphore)) >>> (,values-list nil)) >>> (process-interrupt >>> ccl::*initial-process* >>> (lambda () >>> (setq ,values-list (multiple-value-list (progn , at body))) >>> (signal-semaphore ,sem))) >>> (wait-on-semaphore ,sem) >>> (values-list ,values-list))))) >>> >>> I also have another version which doesn't wait for the return >>> value(s) >>> if you're interested. >>> >>> So calls to things like #/setContentView: I would wrap thus: (gui-do >>> (#/setContentView: ... etc. just to ensure they happen on the main >>> thread. >>> >>> Hopefully the Clozure crew will let me know if this is really >>> wrongheaded. >>> >>> regards, >>> >>> >>> >>> >>> >>> Raffael Cavallaro >>> raffaelcavallaro at me.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From info at mracpublishing.com Thu May 28 17:41:50 2009 From: info at mracpublishing.com (Janusz Podrazik) Date: Fri, 29 May 2009 02:41:50 +0200 Subject: [Openmcl-devel] window size & position In-Reply-To: <20090528142633.K72709@abq.clozure.com> References: <20090528110452.H72709@abq.clozure.com> <20090528142633.K72709@abq.clozure.com> Message-ID: thanks, ccl dev is going well i would say :-) the size & position works well, and the menu too gets more functionality. maybe something like 'project' or 'workspace' function could solve the problem to which i refereed earlier. thanks again, janusz podrazik On Thu, May 28, 2009 at 22:32, Gary Byers wrote: > > > On Thu, 28 May 2009, Janusz Podrazik wrote: > >> On Thu, May 28, 2009 at 20:19, Gary Byers wrote: >>> >>> We've been using the builtin Cocoa facilities for keeping track of >>> window size and position across sessions in the trunk version of the >>> IDE for a few weeks now. ?That's not quite the same as saving and >>> restoring the whole state of the world between sessions, but it does >>> mean that named editor documents and listeners open with the size >>> and position that they had when they were last closed. >>> >> >> is not working on/with Clozure CL-x8664 (Welcome to Clozure Common >> Lisp Version 1.3-r12149M ?(DarwinX8664) !) >> no position or size of any window, listener or editor is restored to >> the position or size you are have save/close the window or quit the >> CCL. > > No, it isn't; that's not the trunk. ?See: > > > From ralex at cs.colorado.edu Thu May 28 18:44:25 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Thu, 28 May 2009 19:44:25 -0600 Subject: [Openmcl-devel] Handling mouse events In-Reply-To: References: <20090528110452.H72709@abq.clozure.com> <47800A75-6C8C-498C-AE2D-7ADFA9824D2D@awun.net> Message-ID: <37DCDB09-B042-4115-8256-88F3D27820E3@cs.colorado.edu> some code here: http://code.google.com/p/xmlisp/source/browse/trunk/XMLisp/sources/Lisp%20User%20Interface/specific/Mac%20CCL/LUI%20Cocoa.lisp alex On May 28, 2009, at 4:02 PM, Arthur W Cater wrote: > Sorry I have no demo code for that, but I can tell you that > instances of easygui::drawing-view > can be created with keyword arguments :mouse-enter :mouse- > exit :mouse-move > :mouse-down and :mouse-up. There's also :mouse-dragged. > The values should be functions that like being called with an > easygui::view and further > keyword arguments, notably :event. > I have myself used :mouse-enter :mouse-exit and :mouse-down only. > The code (in ccl/examples/cocoa/easygui/views.lisp) could do with > further improvement, feel free! > There is demo code in ccl/examples/cocoa/easygui/example/extended- > demo.lisp which creates > various nested easygui views, one of which is a drawing-view with > a :mouse-down initarg. > Maybe that is a tiny help, I hope so. > > Arthur > > ----- Original Message ----- > From: Ron Garret > Date: Thursday, May 28, 2009 9:14 pm > Subject: [Openmcl-devel] Handling mouse events > To: Openmcl-devel Devel > > > Before I go reinventing the wheel, does anyone have any demo > > code that > > handles mouse events, like maybe a little scribble window or > > something > > like that? > > > > Thanks, > > rg > > > > _______________________________________________ > > Openmcl-devel mailing list > > Openmcl-devel at clozure.com > > http://clozure.com/mailman/listinfo/openmcl-devel > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralex at cs.colorado.edu Thu May 28 23:30:06 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Fri, 29 May 2009 00:30:06 -0600 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: That would be fine with me but we work on educational software. Quite often schools are 1-2 versions, i.e., now using 10.4 and 10.3 behind. What kinds of features are you thinking of? alex On May 28, 2009, at 2:57 PM, R. Matthew Emerson wrote: > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at awun.net Thu May 28 23:48:52 2009 From: ron at awun.net (Ron Garret) Date: Thu, 28 May 2009 23:48:52 -0700 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: <08D8F9A3-AE5A-4D85-BA18-D23CD509EF79@awun.net> References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> <200905282330.KWY01660@mr08.lnh.mail.rcn.net> <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> <08D8F9A3-AE5A-4D85-BA18-D23CD509EF79@awun.net> Message-ID: On May 28, 2009, at 5:02 PM, Ron Garret wrote: > 5. My next step is try to reproduce this in pure ObjC. Nope, ObjC happily switches back and forth between two PDFs all day long. So this must be a CCL issue. rg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2407 bytes Desc: not available URL: From joakim at joakimsandgren.com Fri May 29 00:04:56 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 29 May 2009 09:04:56 +0200 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <4CBF8F3C-6A56-4947-8A2E-608085BA1554@joakimsandgren.com> fine with me. J Le 28 mai 09 ? 22:57, R. Matthew Emerson a ?crit : > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > Joakim Sandgren joakim sandgren musik 42, rue de Maubeuge 75009 Paris France +33 (0)1 45 26 43 90 info at joakimsandgren.com http://www.joakimsandgren.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Fri May 29 00:08:39 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 29 May 2009 01:08:39 -0600 (MDT) Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> <200905282330.KWY01660@mr08.lnh.mail.rcn.net> <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> <08D8F9A3-AE5A-4D85-BA18-D23CD509EF79@awun.net> Message-ID: You were able to create a separate thread and otherwise recreate a similar threading environment in ObjC, then ? Surprising that that'd work; I would have guessed that this was a threading issue. On Thu, 28 May 2009, Ron Garret wrote: > > On May 28, 2009, at 5:02 PM, Ron Garret wrote: > >> 5. My next step is try to reproduce this in pure ObjC. > > Nope, ObjC happily switches back and forth between two PDFs all day long. So > this must be a CCL issue. > > rg > From gb at clozure.com Fri May 29 01:01:33 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 29 May 2009 02:01:33 -0600 (MDT) Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> <200905282330.KWY01660@mr08.lnh.mail.rcn.net> <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> <08D8F9A3-AE5A-4D85-BA18-D23CD509EF79@awun.net> Message-ID: I was eventually able to get this to crash; when it did, it generated a Crash Reporter log file. I opened a ticket describing the little bit that we know so far and attached that crash report. It seems to show that two threads (the event thread and an NSThread created by some foreign code) were in the same place in #_malloc() (though presumably in different malloc "zones") and the foreign NSThread segfaulted. That's about all I know at this point. On Fri, 29 May 2009, Gary Byers wrote: > You were able to create a separate thread and otherwise recreate a > similar threading environment in ObjC, then ? > > Surprising that that'd work; I would have guessed that this was a > threading issue. > > On Thu, 28 May 2009, Ron Garret wrote: > >> >> On May 28, 2009, at 5:02 PM, Ron Garret wrote: >> >>> 5. My next step is try to reproduce this in pure ObjC. >> >> Nope, ObjC happily switches back and forth between two PDFs all day long. So >> this must be a CCL issue. >> >> rg >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From info at mracpublishing.com Fri May 29 01:30:08 2009 From: info at mracpublishing.com (Janusz Podrazik) Date: Fri, 29 May 2009 10:30:08 +0200 Subject: [Openmcl-devel] single compiled file Message-ID: how to concatenate the compiled components in a single compiled file. JP From arthur.cater at ucd.ie Fri May 29 01:43:47 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Fri, 29 May 2009 09:43:47 +0100 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: ok by me too Arthur > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X ? > 10.4). ?There are, however, features in Leopard that I'd like to use, ? > and I was wondering what the general reaction would be to the idea of ? > making the Cocoa IDE require Leopard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Fri May 29 02:08:58 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 29 May 2009 03:08:58 -0600 (MDT) Subject: [Openmcl-devel] single compiled file In-Reply-To: References: Message-ID: (CCL:FASL-CONCATENATE output-fasl-file list-of-input-fasl-files &key (if-exists :error)) will create a fasl file which, when loaded, will have the same effect as loading the individual input fasl files in the specified order. The single file might be easier to distribute or install, and loading it may be at least a little faster than loading the individual files (since it avoids the overhead of opening and closing each file in succession.) The PATHNAME-TYPE of the output file and of each input file defaults to the current platform's fasl file type (.dx64fsl or whatever.) If any of the input files has a different type/extension an error will be signaled, but it doesn't otherwise try too hard to verify that the input files are real fasl files for the current platform. On Fri, 29 May 2009, Janusz Podrazik wrote: > how to concatenate the compiled components in a single compiled file. > > JP > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From p2.edoc at googlemail.com Fri May 29 02:45:04 2009 From: p2.edoc at googlemail.com (peter) Date: Fri, 29 May 2009 10:45:04 +0100 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: Not to hold anyone back, but could you leave on server (and label) the last valid Tiger version. BTW, is it possible to illuminate what should we expect re. Snow Leopard, will CCL run as normal [sic] (I'm assuming Clozure or others are 10.6 beta testers)? At 4:57 PM -0400 09/05/28, R. Matthew Emerson wrote: >We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >10.4). There are, however, features in Leopard that I'd like to use, >and I was wondering what the general reaction would be to the idea of >making the Cocoa IDE require Leopard. From kristianbredin at gmail.com Fri May 29 03:33:02 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Fri, 29 May 2009 12:33:02 +0200 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <9BA9CFF4-FAFA-4C88-B1D1-096B05D8E2D2@gmail.com> Not fine with me. But I seem to belong to a minimal minority. Kristian 28 maj 2009 kl. 22.57 skrev R. Matthew Emerson: > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From gb at clozure.com Fri May 29 04:20:19 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 29 May 2009 05:20:19 -0600 (MDT) Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: On Fri, 29 May 2009, peter wrote: > Not to hold anyone back, but could you leave on server (and label) > the last valid Tiger version. > > BTW, is it possible to illuminate what should we expect re. Snow > Leopard, will CCL run as normal [sic] (I'm assuming Clozure or others > are 10.6 beta testers)? Apple's NDA prohibits discussing pre-release software. I can say that during the Leopard testing cycle everything was pretty uneventful - early Leopard releases seemed to be a set of incremental changes to Tiger - until the release that Apple gave to WWDC attendees; that release contained a large number of significant changes and introduced new bugs (one of which kept the ppc64 version of OpenMCL/CCL from running at all under Leopard.) This year's WWDC is coming up in a few weeks. Based on the Leopard experience, I'd say that even if I could say something about Snow Leopard, I wouldn't do so. (Yet.) As the release of Snow Leopard approaches, the constraints on discussing it will get more and more absurd. I can at least say that we are beta testers and that changes that're related to (beta versions of) Snow Leopard and its toolchain were made before the CCL 1.3 release and none have been made since, and I can say that none of those changes are user-visible (don't affect CL or Cocoa bridge code and are fairly obscure things deep in the lisp kernel and its makefiles.) I do understand that people will want as much advance notice as possible if any of this changes as the Snow Leopard release approaches (if the then-current CCL release won't work under SL, or if significant changes will be required to CL or CCL-specific user-level code.) The constraints of the NDA are real and Apple has lots of mean lawyers, so it seems wise to err on the side of caution and observe those constraints. The best compromise seems to be to agree to howl incoherently if any bad news develops between now and the final Snow Leopard release, but refuse to say anything about what we're howling about. (We would not be able to confirm or deny whether the phrase "Those idiots! How hard can it be to write a linker ?" - should it happen to appear in source comments or commit messages - is directed at Apple.) > > At 4:57 PM -0400 09/05/28, R. Matthew Emerson wrote: >> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >> 10.4). There are, however, features in Leopard that I'd like to use, >> and I was wondering what the general reaction would be to the idea of >> making the Cocoa IDE require Leopard. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From lisp at clairvaux.org Fri May 29 04:30:27 2009 From: lisp at clairvaux.org (Glen Foy) Date: Fri, 29 May 2009 07:30:27 -0400 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: If anyone is using older PPC hardware that allegedly can't run Leopard, there are hacks available: http://lowendmac.com/osx/leopard/unsupported.html On May 28, 2009, at 4:57 PM, R. Matthew Emerson wrote: > We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X > 10.4). There are, however, features in Leopard that I'd like to use, > and I was wondering what the general reaction would be to the idea of > making the Cocoa IDE require Leopard. From kristianbredin at gmail.com Fri May 29 04:55:39 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Fri, 29 May 2009 13:55:39 +0200 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> There could be other reasons for wanting to keep Tiger compatibility, such as "I just upgraded to Tiger" (which is true in my case -I'm a bit late mainly due to lack of cash). And I _still_ need Classic, because I can't upgrade to the recent version of app "x" and "y" because of...ahem...lack of cash... Any empty beer cans to spare, anyone? ;) Kristian 29 maj 2009 kl. 13.30 skrev Glen Foy: > If anyone is using older PPC hardware that allegedly can't run > Leopard, there are hacks available: > > http://lowendmac.com/osx/leopard/unsupported.html > > > > On May 28, 2009, at 4:57 PM, R. Matthew Emerson wrote: > >> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >> 10.4). There are, however, features in Leopard that I'd like to use, >> and I was wondering what the general reaction would be to the idea of >> making the Cocoa IDE require Leopard. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From lisp at clairvaux.org Fri May 29 05:14:43 2009 From: lisp at clairvaux.org (Glen Foy) Date: Fri, 29 May 2009 08:14:43 -0400 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> Message-ID: <1E59C880-2D00-45F8-9553-F90E536ECDE8@clairvaux.org> You might want to keep your Classic box (Classic is still useful to me too) and keep a eye on eBay mac minis. You can get a mini (PPC or Intel) running Leopard for surprisingly little. - good luck On May 29, 2009, at 7:55 AM, Kristian Bredin wrote: > There could be other reasons for wanting to keep Tiger compatibility, > such as "I just upgraded to Tiger" (which is true in my case -I'm a > bit late mainly due to lack of cash). And I _still_ need Classic, > because I can't upgrade to the recent version of app "x" and "y" > because of...ahem...lack of cash... > > Any empty beer cans to spare, anyone? ;) > > Kristian > > > 29 maj 2009 kl. 13.30 skrev Glen Foy: > >> If anyone is using older PPC hardware that allegedly can't run >> Leopard, there are hacks available: >> >> http://lowendmac.com/osx/leopard/unsupported.html >> >> >> >> On May 28, 2009, at 4:57 PM, R. Matthew Emerson wrote: >> >>> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >>> 10.4). There are, however, features in Leopard that I'd like to >>> use, >>> and I was wondering what the general reaction would be to the idea >>> of >>> making the Cocoa IDE require Leopard. >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From raffaelcavallaro at mac.com Fri May 29 05:41:57 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Fri, 29 May 2009 08:41:57 -0400 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <791B4DA3-16DD-44ED-AB34-7C8A338A95F3@mac.com> On May 29, 2009, at 7:20 AM, Gary Byers wrote: > The constraints of the NDA are real and Apple has lots of mean > lawyers, so it seems wise to err on the side of caution and observe > those constraints. Would there be any value in having those of us similarly under NDA build/run the current trunk under the most recent seed? regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From brian at mastenbrook.net Fri May 29 05:57:15 2009 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Fri, 29 May 2009 07:57:15 -0500 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> Message-ID: <93FC8870-45C6-44C0-BF4C-9640B4CD79AB@mastenbrook.net> On May 29, 2009, at 6:55 AM, Kristian Bredin wrote: > There could be other reasons for wanting to keep Tiger compatibility, > such as "I just upgraded to Tiger" (which is true in my case -I'm a > bit late mainly due to lack of cash). And I _still_ need Classic, > because I can't upgrade to the recent version of app "x" and "y" > because of...ahem...lack of cash... > > Any empty beer cans to spare, anyone? ;) > > Kristian I do hope you're not planning on connecting your Tiger system to the internet after the Snow Leopard release. Apple doesn't issue security updates for anything but the current and previous versions of the OS. There are some pretty significant issues with OS X security, especially in the browser, so it'd be a good idea to disconnect all Tiger systems upon 10.6's release. This also makes it reasonable to me to drop Tiger support when Snow Leopard arrives. And if the current trunk version of CCL is planned for stable release after the Snow Leopard release, it seems reasonable to me to drop Tiger support in trunk immediately. -- Brian Mastenbrook brian at mastenbrook.net http://brian.mastenbrook.net/ From ron at awun.net Fri May 29 09:15:06 2009 From: ron at awun.net (Ron Garret) Date: Fri, 29 May 2009 09:15:06 -0700 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> Message-ID: You should tell people the values of X and Y. You never know when someone might have a recent version that they are no longer using. rg On May 29, 2009, at 4:55 AM, Kristian Bredin wrote: > There could be other reasons for wanting to keep Tiger compatibility, > such as "I just upgraded to Tiger" (which is true in my case -I'm a > bit late mainly due to lack of cash). And I _still_ need Classic, > because I can't upgrade to the recent version of app "x" and "y" > because of...ahem...lack of cash... > > Any empty beer cans to spare, anyone? ;) > > Kristian > > > > > > > > 29 maj 2009 kl. 13.30 skrev Glen Foy: > >> If anyone is using older PPC hardware that allegedly can't run >> Leopard, there are hacks available: >> >> http://lowendmac.com/osx/leopard/unsupported.html >> >> >> >> On May 28, 2009, at 4:57 PM, R. Matthew Emerson wrote: >> >>> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >>> 10.4). There are, however, features in Leopard that I'd like to >>> use, >>> and I was wondering what the general reaction would be to the idea >>> of >>> making the Cocoa IDE require Leopard. >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2407 bytes Desc: not available URL: From ron at awun.net Fri May 29 09:55:06 2009 From: ron at awun.net (Ron Garret) Date: Fri, 29 May 2009 09:55:06 -0700 Subject: [Openmcl-devel] To send or not to send Message-ID: <9FD33130-CEFE-469A-9A99-8040F840D94F@awun.net> This is not a high priority issue for me, but I thought it might be of general interest. RME (whom I presume is Ralph Emerson) commented on a recent ticket of mine (#516): "I would recommend that you don't use SEND, which is basically obsolete. (Yes, the Objective-C bridge chapter in the manual is horribly out-of- date.)" I was disappointed by this because I kinda sorta like the send syntax better than the straight ObjC syntax. There are times when: (send foo ns::snoz :baz bar :bing boff) just feels cleaner than (#/snozBazBing: foo bar boff) especially when there are a lot of arguments. Why is send being deprecated? rg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2407 bytes Desc: not available URL: From ralex at cs.colorado.edu Fri May 29 10:18:31 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Fri, 29 May 2009 11:18:31 -0600 Subject: [Openmcl-devel] To send or not to send In-Reply-To: <9FD33130-CEFE-469A-9A99-8040F840D94F@awun.net> References: <9FD33130-CEFE-469A-9A99-8040F840D94F@awun.net> Message-ID: <4D58584D-2C57-4FEA-8866-EBD56797DDFE@cs.colorado.edu> this is somewhat subjective, I guess. I do not mind "send" being depreciated but I do share the concern about readability when there are many parameters, e.g., (#/compositeToPoint:fromRect:operation:fraction: Image Point Rect Op Fraction) does look a bit clumsy, in terms of readability, and less CL than perhaps (#/compositeToPoint: Image Point :fromRect Rect :operation Op :fraction Fraction) alex On May 29, 2009, at 10:55 AM, Ron Garret wrote: > I was disappointed by this because I kinda sorta like the send > syntax better than the straight ObjC syntax. There are times when: > > (send foo ns::snoz :baz bar :bing boff) > > just feels cleaner than > > (#/snozBazBing: foo bar boff) > > especially when there are a lot of arguments. Why is send being > deprecated? Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf From kristianbredin at gmail.com Fri May 29 14:02:44 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Fri, 29 May 2009 23:02:44 +0200 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> <3AF3F76C-B413-42D9-8787-FB7C8C65D36B@gmail.com> Message-ID: Thank you all, for good advice. :) Kristian 29 maj 2009 kl. 18.15 skrev Ron Garret: > You should tell people the values of X and Y. You never know when > someone might have a recent version that they are no longer using. > > rg > > On May 29, 2009, at 4:55 AM, Kristian Bredin wrote: > >> There could be other reasons for wanting to keep Tiger compatibility, >> such as "I just upgraded to Tiger" (which is true in my case -I'm a >> bit late mainly due to lack of cash). And I _still_ need Classic, >> because I can't upgrade to the recent version of app "x" and "y" >> because of...ahem...lack of cash... >> >> Any empty beer cans to spare, anyone? ;) >> >> Kristian >> >> >> >> >> >> >> >> 29 maj 2009 kl. 13.30 skrev Glen Foy: >> >>> If anyone is using older PPC hardware that allegedly can't run >>> Leopard, there are hacks available: >>> >>> http://lowendmac.com/osx/leopard/unsupported.html >>> >>> >>> >>> On May 28, 2009, at 4:57 PM, R. Matthew Emerson wrote: >>> >>>> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >>>> 10.4). There are, however, features in Leopard that I'd like to >>>> use, >>>> and I was wondering what the general reaction would be to the >>>> idea of >>>> making the Cocoa IDE require Leopard. >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > From gb at clozure.com Fri May 29 16:56:04 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 29 May 2009 17:56:04 -0600 (MDT) Subject: [Openmcl-devel] To send or not to send In-Reply-To: <9FD33130-CEFE-469A-9A99-8040F840D94F@awun.net> References: <9FD33130-CEFE-469A-9A99-8040F840D94F@awun.net> Message-ID: SEND is/was a macro; it macroexpanded into something like: (#_objc_msgSend (@selector "someObjcMessage:withArg:andOtherArg:") :id arg0 :int arg1 :id) or in some cases: (#_objc_msgSendStret ) depending on what information about the ObjC message's argument and return types was available at macroexpand time. The second case (assuming that I'm spelling the foreign function names correctly) was used when the ObjC method returned a structure (in all cases on PPC32 and in some cases on other architectures.) Cases that involved structure return in SEND (regardless of what runtime function actually implemented structure return) had to be treated differently and generally had to be embedded in an SLET form (or something equally awkward.) For the vast majority of ObjC messages defined in Cocoa (AppKit and Foundation), all methods defined on the message have the same foreign type signature (accept the same types of foreign arguments and return the same type of value.) There are a few exceptions to this (where the same message name is used for different methods in disjoint classes and those messages had different type signatures), and there's a section in the manual that describes how to provide hints which help resolve ambiguity. I'm not sure how well users dealt with this - sometimes type declarations were required in order to get a SEND macro call to compile, sometimes they weren't, and loading additional frameworks changed the rules. Loading additional frameworks could exposed different kinds of ambiguity. In AppKit and Foundation, there are 4 declared #/size methods, each of which returns an NSSize structure (and therefore had to be used inside an SLET or otherwise satisfy SEND's contstraints on structure-returning message sends.) Loading the WebKit framework defines a #/size method that returns a scalar value (I don't remember whether it's an integer or a float), and I think that SEND just threw up its hands and either refused to macroexpand (SEND x 'size) anymore or completely lost the ability to do so correctly. Users ran into this, and the precise details of the ways in which it failed and the bizarre workarounds that were necessary to avoid failure are presumably still in the openmcl-devel archives and not too hard to find. It might have been possible to fix SEND to better deal with this (rare) kind of ambiguity, but whatever the fix was would have likely required the user to provide even more declarative information and to be even more sensitive to the FFI-level details of how structure-returning calls differ from scalar-returning calls. There were other arguments for wanting to deprecate SEND in favor of #/. #/ returns a lisp symbol (although bizarrely named) that likely names a lisp function (although a somewhat unusual lisp function), and an invocation of an ObjC method via (#/messagename foo ..) is just a lisp function call (so the compiler can warn if the function is undefined or if the number of arguments is inappropriate). Meta-. doesn't do anything with methods named via #/, but you don't have to stretch too far to see the possibility that it could (and one of the things that could be done is to visit the .h file that defines the method when appropriate.) Perhaps most importantly, treating ObjC messages as lisp functions allowed those functions to deal with foreign type ambiguity and hide the details of that from the user, and to deal with structure-returning methods by treating structures as values that're returned just like other values are. Not to keep bashing SEND - which was contributed by a user named Randall Beer and which was a huge step up from the much more primitive things that'd existed before - but some people complained that the infix-y/mixed syntax felt too much like ObjC and too little like lisp. Different people will view that kind of thing differently, but one thing that most lisp programmers will likely agree on is that syntax is easy to change and often uninteresting. There are lots of problems (as enumerated above) with SEND macroepanding into an ff-call into the ObjC runtime, and many of those problems have to do with issues of foreign type ambiguity that can't be resolved at macroexpand time. If SEND instead macroexpanded into a function call to the function named by #/, those problems would go away. (E.g., if (send foo 'size) macroexpanded into the equivalent of (#/size foo) ; let #'#/size figure out whether to return a struct or scalar then there'd be far fewer reasons to want to deprecate it.) On Fri, 29 May 2009, Ron Garret wrote: > This is not a high priority issue for me, but I thought it might be of > general interest. > > RME (whom I presume is Ralph Emerson) commented on a recent ticket of mine > (#516): > > "I would recommend that you don't use SEND, which is basically obsolete. > (Yes, the Objective-C bridge chapter in the manual is horribly out-of- > date.)" > > I was disappointed by this because I kinda sorta like the send syntax better > than the straight ObjC syntax. There are times when: > > (send foo ns::snoz :baz bar :bing boff) > > just feels cleaner than > > (#/snozBazBing: foo bar boff) > > especially when there are a lot of arguments. Why is send being deprecated? > > rg > From ralex at cs.colorado.edu Fri May 29 18:24:30 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Fri, 29 May 2009 19:24:30 -0600 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 Message-ID: XMLisp 0.2 "A rich media programming environment for 3D/ 2D game and simulation applications" still in an early stage but many bugfixes and - scene graph agents - 3D selection, hovering/picking - more primitive agent classes including groups - speech support - source access here: http://code.google.com/p/xmlisp/ Please let me know if you have problems or better yet have some cool new examples. I would be curious to hear what kind of frame rates people get for the game of life. I got some pretty inconsistent results. Suddenly the frame rate is up to 120 fps on my Intel Mac. anyway, enjoy Alex Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XMLisp_screen.png Type: image/png Size: 130336 bytes Desc: not available URL: From neil.baylis at gmail.com Fri May 29 22:30:35 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Fri, 29 May 2009 22:30:35 -0700 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: References: Message-ID: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> > > > OK, this thing is really cool. You've been burning the midnight oil ;- I downloaded it a week or so back, and it was crashing and burning. Today it seems much more solid, all the demos seemed to work properly. This comes at a good time for me, as I'm just getting ready to start a new project. Really it only requires 2d graphics (I was planning to use Quartz 2d) but you've made the 3D very easy. I could probably do it with 3D without too much trouble. It's an application that places colored tiles from a collection into an on-screen rectangle, subject to constraints. Questions: Is there documentation, or do I just need to read the code in the source & examples? Is full-screen supported? Is Quartz 2D supported? (Quartz provides antialiased graphics on my Mac, but OpenGL does not) Can I use it with Emacs & Slime, or must I use the embedded IDE? (I hope the answers to these are 'yes', but none is a show stopper for me). Thanks for making this available, Neil Baylis -------------- next part -------------- An HTML attachment was scrubbed... URL: From rme at clozure.com Fri May 29 22:50:56 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Sat, 30 May 2009 01:50:56 -0400 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: <7C2300A6-FF04-4ADF-8D11-5F3DAEBD5771@clozure.com> On May 29, 2009, at 2:30 AM, Alexander Repenning wrote: > That would be fine with me but we work on educational software. > Quite often schools are 1-2 versions, i.e., now using 10.4 and 10.3 > behind. > > What kinds of features are you thinking of? The major thing I was thinking about is Core Text. There are also some visual glitches when trying to use newer controls on Tiger; if you look at the xapropos dialog from the Experiments menu on both Leopard and Tiger, you'll see what I mean: the arrow on the action button is in the wrong place, and the recessed buttons clip their content. It's possible to work around those glitches, but it takes extra effort. I also have my eye on NSRuleEditor and enhancements to NSTableView and NSOutlineView. > On May 28, 2009, at 2:57 PM, R. Matthew Emerson wrote: > >> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >> 10.4). There are, however, features in Leopard that I'd like to use, >> and I was wondering what the general reaction would be to the idea of >> making the Cocoa IDE require Leopard. >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> > > Prof. Alexander Repenning > > University of Colorado > Computer Science Department > Boulder, CO 80309-430 > > vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil.baylis at gmail.com Fri May 29 23:59:02 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Fri, 29 May 2009 23:59:02 -0700 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> References: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> Message-ID: <1e6b7d810905292359o26d2c5f8j3e5580c5bdf17d74@mail.gmail.com> Oh, forgot to mention: on an Intel Mac Mini. I see 101 frames per second on the game of life example. 2 GHz Dual Core, 2 GByte memory. Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From gb at clozure.com Sat May 30 02:01:28 2009 From: gb at clozure.com (Gary Byers) Date: Sat, 30 May 2009 03:01:28 -0600 (MDT) Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: <791B4DA3-16DD-44ED-AB34-7C8A338A95F3@mac.com> References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> <791B4DA3-16DD-44ED-AB34-7C8A338A95F3@mac.com> Message-ID: On Fri, 29 May 2009, Raffael Cavallaro wrote: > > On May 29, 2009, at 7:20 AM, Gary Byers wrote: > >> The constraints of the NDA are real and Apple has lots of mean >> lawyers, so it seems wise to err on the side of caution and observe >> those constraints. > > > Would there be any value in having those of us similarly under NDA > build/run the current trunk under the most recent seed? Yes, thanks. If anyone who goes to WWDC has a chance to try to run under the WWDC release, that'd also be very helpful. I think that I've seen public statements to the effect that the WWDC release of Snow Leopard is intended to be pretty close to feature-complete, and Apple sometimes waits until some time after WWDC to make WWDC releases generally available. > > regards, > > Ralph > > > > Raffael Cavallaro > raffaelcavallaro at me.com > > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From raffaelcavallaro at mac.com Sat May 30 05:27:42 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sat, 30 May 2009 08:27:42 -0400 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <1e6b7d810905292359o26d2c5f8j3e5580c5bdf17d74@mail.gmail.com> References: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> <1e6b7d810905292359o26d2c5f8j3e5580c5bdf17d74@mail.gmail.com> Message-ID: <45AE87A2-13ED-46D4-B4D1-94BE30BF14D1@mac.com> On May 30, 2009, at 2:59 AM, Neil Baylis wrote: > on an Intel Mac Mini. I see 101 frames per second on the game of > life example. > 2 GHz Dual Core, 2 GByte memory. 113 fps on a MBP Core 2 Duo, 2.4 GHz, 4 GB RAM, GeForce 8600M GT. Alex, are you planning on making the current source available? It would make it easier for us to integrate into our projects and still track the trunk. regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From raffaelcavallaro at mac.com Sat May 30 05:31:58 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sat, 30 May 2009 08:31:58 -0400 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <45AE87A2-13ED-46D4-B4D1-94BE30BF14D1@mac.com> References: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> <1e6b7d810905292359o26d2c5f8j3e5580c5bdf17d74@mail.gmail.com> <45AE87A2-13ED-46D4-B4D1-94BE30BF14D1@mac.com> Message-ID: <64515375-9ABB-4192-A4B9-D44C31CD9DE2@mac.com> On May 30, 2009, at 8:27 AM, Raffael Cavallaro wrote: > Alex, are you planning on making the current source available? It > would make it easier for us to integrate into our projects and still > track the trunk. oops, spoke too soon - the svn checkout is now working. warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From raffaelcavallaro at mac.com Sat May 30 06:48:29 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sat, 30 May 2009 09:48:29 -0400 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: References: Message-ID: <7869651A-ABF4-4966-B1DA-0D8546641CD7@mac.com> On May 29, 2009, at 9:24 PM, Alexander Repenning wrote: > XMLisp 0.2 "A rich media programming environment for 3D/ 2D game and > simulation applications" > > still in an early stage but many bugfixes and > - scene graph agents > - 3D selection, hovering/picking > - more primitive agent classes including groups > - speech support > - source Alex, hypothetically, if one were not completely in love with XML syntax, where would one start to do what you're doing in the examples, but using an s-expression syntax? for example, being able accomplish what we get with this: with something like this: (lui-window 'chatty-window :track-mouse t :title "Objects" :margin 0 :subviews ((lui-view 'agent-3d-view :name "scene" :agents (agent 'cube :texture "crate.png") (agent 'sphere :x 2.0) (agent 'sphere :x 3.0 :texture "earth.png") (agent 'cube :size 3.0 :z -3.5 :texture "crate.png") (agent 'sky-dome :pitch 90)))) warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From raffaelcavallaro at mac.com Sat May 30 07:19:04 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sat, 30 May 2009 10:19:04 -0400 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <8fbe874a0905300706s6ad8df7drae61d96cab61c001@mail.gmail.com> References: <7869651A-ABF4-4966-B1DA-0D8546641CD7@mac.com> <8fbe874a0905300706s6ad8df7drae61d96cab61c001@mail.gmail.com> Message-ID: <2FC7791D-9FAF-4F1B-9A61-B0698BCD9987@mac.com> On May 30, 2009, at 10:06 AM, Bill St. Clair wrote: > You could use cl-who: Nice. Is there a way to avoid quoting the non-string parameters (numbers and booleans?)? warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From wws at clozure.com Sat May 30 07:33:15 2009 From: wws at clozure.com (Bill St. Clair) Date: Sat, 30 May 2009 10:33:15 -0400 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <2FC7791D-9FAF-4F1B-9A61-B0698BCD9987@mac.com> References: <7869651A-ABF4-4966-B1DA-0D8546641CD7@mac.com> <8fbe874a0905300706s6ad8df7drae61d96cab61c001@mail.gmail.com> <2FC7791D-9FAF-4F1B-9A61-B0698BCD9987@mac.com> Message-ID: <8fbe874a0905300733u5c021da0tb3a57e1f97630ac@mail.gmail.com> [resend for the list] On Sat, May 30, 2009 at 10:19 AM, Raffael Cavallaro wrote: > > On May 30, 2009, at 10:06 AM, Bill St. Clair wrote: > >> You could use cl-who: >> >> CL-USER> (setq cl-who:*html-empty-tag-aware-p* nil) >> NIL >> CL-USER> (cl-who:with-html-output-to-string (s nil :indent t) >> (:chatty-window >> :track-mouse "true" :title "Objects" :margin "0" >> (:agent-3d-view >> :name "scene" >> (:cube :texture "crate.png") >> (:sphere :x "2.0") >> (:sphere :x "3.0" :texture "earth.png") >> (:cube :size "3.0" :z "-3.5" :texture "crate.png") >> (:cube :x "5" :roll "45.0") >> (:sky-dome :pitch "90")))) >> " >> >> >> >> >> >> >> >> >> >> " > > Nice. Is there a way to avoid quoting the non-string parameters > (numbers and booleans?)? Attribute parameters get evaluated and PRINC'd, so you don't need the quotes around the numbers: CL-USER: (cl-who:with-html-output-to-string (s nil :indent t) (:agent-3d-view :name "scene" (:cube :texture "crate.png") (:sphere :x 2.0) (:sphere :x 3.0 :texture "earth.png") (:cube :size 3.0 :z -3.5 :texture "crate.png") (:cube :x 5 :roll 45.0) (:sky-dome :pitch 90))) " " From raffaelcavallaro at mac.com Sat May 30 08:01:06 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sat, 30 May 2009 11:01:06 -0400 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <8fbe874a0905300731u6e7c164auc5e6d361904b4a06@mail.gmail.com> References: <7869651A-ABF4-4966-B1DA-0D8546641CD7@mac.com> <8fbe874a0905300706s6ad8df7drae61d96cab61c001@mail.gmail.com> <2FC7791D-9FAF-4F1B-9A61-B0698BCD9987@mac.com> <8fbe874a0905300731u6e7c164auc5e6d361904b4a06@mail.gmail.com> Message-ID: <41AC6F4E-031D-4A1E-B359-F1555CC57447@mac.com> On May 30, 2009, at 10:31 AM, Bill St. Clair wrote: > Attribute parameters get evaluated and PRINC'd, so you don't need the > quotes around the numbers: Thank you very much! This list is amazing. Here's what I have in case anyone else is interested in an s- expression syntax for Alex's work using Bill St. Clair's suggestion of cl-who. I've called the macro slui for s-expression lisp user interface: ;; after loading the xlui init file ;; and asdf-installing cl-who of course (in-package :xlui) (asdf:oos 'asdf:load-op :cl-who) (defmacro slui (s-expression) `(let* ((*read-eval* t) (cl-who:*html-empty-tag-aware-p* nil)) (read-from-string (cl-who:with-html-output-to-string (s nil :indent t) ,s-expression)))) ;; example usage after loading ;; XMLisp/sources/XLUI/examples/3D/agents/Who is Talking.lisp : #| (slui (:chatty-window :track-mouse t :title "Objects" :margin 0 (:agent-3d-view :name "scene" (:cube :texture "crate.png") (:sphere :x 2.0) (:sphere :x 3.0 :texture "earth.png") (:cube :size 3.0 :z -3.5 :texture "crate.png") (:cube :x 5 :roll 45.0) (:sky-dome :pitch 90)))) |# warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From ralex at cs.colorado.edu Sat May 30 10:04:11 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Sat, 30 May 2009 11:04:11 -0600 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> References: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> Message-ID: <32028895-F5F1-4F25-8EAF-94AA4F23DC88@cs.colorado.edu> On May 29, 2009, at 11:30 PM, Neil Baylis wrote: > > OK, this thing is really cool. You've been burning the midnight > oil ;- I downloaded it a week or so back, and it was crashing and > burning. Today it seems much more solid, all the demos seemed to > work properly. I am glad to hear that! Yes, a lot of midnight oil got burned... The CCL IDE has still some issues but we are pretty excited about the result. XMLisp is really part of AgentCubes which has been implemented with MCL and Allegro. The CCL version is already better then the MCL version (Carbon, non native threading) ever was. There has been a lot of discussion recently about things that are bad in CCL and some people pointed me to other Lisp implementation including PLT Scheme. I ran some benchmarks and the CCL version not only blew the doors off Scheme (running the same OpenGL demo 2x - 5x faster) but was also much more stable. Running multiple animations in different windows at the same time, resizing/moving window, changing the camera, running other stuff, ... no problem with CCL. OpenGL in Scheme, in contrast, fell completely apart. Doing just about anything using the mouse would slow the animation down or when moving or resizing any window stop the entire thing. Running even two animations at the same time: completely impossible. A huge thanks goes to Clozure. The IDE including some of the debugging tools may still be rough but the basic machinery is amazing. Native threading, incremental garbage collection, incremental compilation, 64bit, solid event handling will allow CCL to go where few, if any, Lisp implementations have gone before ;-) This is a powerful tool that not only does great compared to other Lisps but also in comparison to just about any programming language. I think Lisp programming is becoming fun again! > > This comes at a good time for me, as I'm just getting ready to start > a new project. Really it only requires 2d graphics (I was planning > to use Quartz 2d) but you've made the 3D very easy. I could probably > do it with 3D without too much trouble. It's an application that > places colored tiles from a collection into an on-screen rectangle, > subject to constraints. OpenGL is actually quite good for these kinds of 2D applications. Have a look at AgentCubes: http://www.cs.colorado.edu/~ralex/papers/PDF/AgentCubes_JVLC_article_inpress.pdf Lots of 2D > > Questions: > Is there documentation, or do I just need to read the code in the > source & examples? documentation is planned and has started but for now the best documentation are the examples. It would help to hear what kind of minimal documentation people need. > Is full-screen supported? not yet but the MCL version already had this. I think we will go the same simple route. It may sound like a hack but has many advantages. The MCL version hides the menu bar and resizes the window so that its content becomes the full-screen. This is slightly slower but keeps event handling simple (you need to handle full screen event differently) and allows for other window layers to be on top. We need this for transparent annotation windows and drag and drop. > Is Quartz 2D supported? (Quartz provides antialiased graphics on my > Mac, but OpenGL does not) Apple has a nice demo of mixing Quartz, as layer, and OpenGL. The problem for us with this idea is that we need to be cross platform. We are exploring options with Clozure to get LUI with OpenGL to work on windows as well. In OS X ultimately everything goes through OpenGL but certainly Quartz has some nice functions. Btw, OpenGL can do full scene antialiasing and XMLisp has that enabled by default. Are you not getting antialiased output? Some graphics cards need additional encouragement. > Can I use it with Emacs & Slime, or must I use the embedded IDE? I have not tried this but as long as you require :cocoa things should work. You probably need to replicate some startup code from the cocoa- application to get the event loop and other things initialized. > > (I hope the answers to these are 'yes', but none is a show stopper > for me). > > Thanks for making this available, sure thing! Alex > > Neil Baylis > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf From ron at awun.net Sat May 30 21:51:42 2009 From: ron at awun.net (Ron Garret) Date: Sat, 30 May 2009 21:51:42 -0700 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> <200905282330.KWY01660@mr08.lnh.mail.rcn.net> <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> <08D8F9A3-AE5A-4D85-BA18-D23CD509EF79@awun.net> Message-ID: <80979402-D11F-44AA-B345-AF77B2EBBB56@awun.net> For the record, Gary was able to figure out my PDF crash bug. It turns out to not be a CCL bug at all, but a bug in the 64-bit Quartz framework. I was unwittingly compiling my ObjC code in 32-bit mode (thinking that 64-bits was the default in Leopard), which is why I wasn't able to reproduce the bug in ObjC. Because this was not a CCL bug I'm buying a support ticket from Clozure to rebalance my chi. :-) Also, in the past two weeks I've leaned on CCL pretty hard and it has come through with flying colors. If anyone was undecided about diving in to CCL, I would say it's time to take the plunge. Come on in, the water's fine :-) rg From taoufik.dachraoui at wanadoo.fr Sun May 31 03:15:08 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Sun, 31 May 2009 12:15:08 +0200 Subject: [Openmcl-devel] eval-in-package Message-ID: <22A8AB56-3EB9-406D-873E-36287CC4CD0D@wanadoo.fr> Dear, I would like to write a function that evaluates a body in a given package Example: >> ccl >(make-package 'test) >(in-package 'test) >(defun f(n) (if (< n 2) 1 (* n (f (1- n))))) >(in-package 'common-lis-user) >(format t "factorial of ~d is ~d~%" 5 (eval-in-package (find-package 'test) (f 5))) => factorial of 5 is 120 I tried the follwoing but it does not work (eval uses null-lexical- bindings ?) >(defmacro eval-in-package (p f) `(let ((*package* ,p)) ,f)) >(eval-in-package (find-package 'test) (f 5)) The purpose of the eval-in-package is to evaluate functions dynamically generated and must be evaluated in a given package. Thank you in advance for your help Kind regards Taoufik Dachraoui From wws at clozure.com Sun May 31 04:31:50 2009 From: wws at clozure.com (Bill St. Clair) Date: Sun, 31 May 2009 07:31:50 -0400 Subject: [Openmcl-devel] Fwd: eval-in-package In-Reply-To: <8fbe874a0905310430o40a52745uaa379eee9a601a62@mail.gmail.com> References: <22A8AB56-3EB9-406D-873E-36287CC4CD0D@wanadoo.fr> <8fbe874a0905310430o40a52745uaa379eee9a601a62@mail.gmail.com> Message-ID: <8fbe874a0905310431t5d97890bobb5f32b462eb13c2@mail.gmail.com> [forgot to include the list] ---------- Forwarded message ---------- From: Bill St. Clair Date: Sun, May 31, 2009 at 7:30 AM Subject: Re: [Openmcl-devel] eval-in-package To: Taoufik Dachraoui On Sun, May 31, 2009 at 6:15 AM, Taoufik Dachraoui wrote: > Dear, > > I would like to write a function that evaluates a body in a given > package The current package is of interest only to functions, like READ, that convert strings to symbols. Hence, it is rare that EVAL cares about *PACKAGE*. So your question makes no sense. What's the problem you're trying to solve for which you're proposing that binding *PACKAGE* is the solution? -Bill From ron at awun.net Sun May 31 08:50:24 2009 From: ron at awun.net (Ron Garret) Date: Sun, 31 May 2009 08:50:24 -0700 Subject: [Openmcl-devel] eval-in-package In-Reply-To: <22A8AB56-3EB9-406D-873E-36287CC4CD0D@wanadoo.fr> References: <22A8AB56-3EB9-406D-873E-36287CC4CD0D@wanadoo.fr> Message-ID: <0E9CD043-516E-4B8A-AFC2-CB8ADFA6D0D6@awun.net> You'll want to read this: http://www.nhplace.com/kent/PS/Ambitious.html rg On May 31, 2009, at 3:15 AM, Taoufik Dachraoui wrote: > Dear, > > I would like to write a function that evaluates a body in a given > package > > Example: > >>> ccl >> (make-package 'test) >> (in-package 'test) >> (defun f(n) (if (< n 2) 1 (* n (f (1- n))))) >> (in-package 'common-lis-user) >> (format t "factorial of ~d is ~d~%" 5 (eval-in-package (find-package > 'test) (f 5))) > => factorial of 5 is 120 > > > I tried the follwoing but it does not work (eval uses null-lexical- > bindings ?) > >> (defmacro eval-in-package (p f) `(let ((*package* ,p)) ,f)) >> (eval-in-package (find-package 'test) (f 5)) > > The purpose of the eval-in-package is to evaluate functions > dynamically generated and must be evaluated in a given package. > > Thank you in advance for your help > > Kind regards > Taoufik Dachraoui > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From raffaelcavallaro at mac.com Sun May 31 09:02:06 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sun, 31 May 2009 12:02:06 -0400 Subject: [Openmcl-devel] YAWC (Yet Another Weird Crash) In-Reply-To: <80979402-D11F-44AA-B345-AF77B2EBBB56@awun.net> References: <829236A7-182E-4306-B66E-EEAEE923799A@awun.net> <200905282330.KWY01660@mr08.lnh.mail.rcn.net> <07621838-6F6B-4E1E-8759-0E92D7EFCDB0@awun.net> <08D8F9A3-AE5A-4D85-BA18-D23CD509EF79@awun.net> <80979402-D11F-44AA-B345-AF77B2EBBB56@awun.net> Message-ID: <88D9A21A-88C8-471C-B4BD-E90C7B8B08C2@mac.com> On May 31, 2009, at 12:51 AM, Ron Garret wrote: > For the record, Gary was able to figure out my PDF crash bug. It > turns out to not be a CCL bug at all, but a bug in the 64-bit Quartz > framework. I was unwittingly compiling my ObjC code in 32-bit mode > (thinking that 64-bits was the default in Leopard), which is why I > wasn't able to reproduce the bug in ObjC. Because this was not a CCL > bug I'm buying a support ticket from Clozure to rebalance my chi. :-) I had the exact same experience with a bug in the 64bit version of NSSpeechSynthesizer. I was also assuming that XCode defaults to 64-bit on 64-bit machines. Luckily Matthew Emerson suggested that I double check, and it became clear that it was a bug in the 64-bit AppKit, not CCL. > > Also, in the past two weeks I've leaned on CCL pretty hard and it has > come through with flying colors. If anyone was undecided about diving > in to CCL, I would say it's time to take the plunge. Come on in, the > water's fine :-) Same here - I've been using the IDE pretty heavily for 6 months and find it generally stable. warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From kristianbredin at gmail.com Sun May 31 10:44:52 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Sun, 31 May 2009 19:44:52 +0200 Subject: [Openmcl-devel] Cocoa IDE support on Tiger In-Reply-To: References: <49CEF4F5-49AB-41DD-968E-184F4FA374B0@clozure.com> Message-ID: I wonder (like peter) if the most recent Tiger compatible version of CCL could be kept available somewhere. I would appreciate it a lot. Could that be done? Likewise, could possibly a brief message go out on the list, just before the first piece of Leopard functionality is implemented in the trunk? (-Even if the answer to that question is: Now!) Kristian 29 maj 2009 kl. 11.45 skrev peter: > Not to hold anyone back, but could you leave on server (and label) > the last valid Tiger version. > > BTW, is it possible to illuminate what should we expect re. Snow > Leopard, will CCL run as normal [sic] (I'm assuming Clozure or others > are 10.6 beta testers)? > > At 4:57 PM -0400 09/05/28, R. Matthew Emerson wrote: >> We've been making sure that the Cocoa IDE runs on Tiger (Mac OS X >> 10.4). There are, however, features in Leopard that I'd like to use, >> and I was wondering what the general reaction would be to the idea of >> making the Cocoa IDE require Leopard. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From raffaelcavallaro at mac.com Sun May 31 17:48:49 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sun, 31 May 2009 20:48:49 -0400 Subject: [Openmcl-devel] 1.3-dev-r12166M-trunk launches with listener in Alt Console Message-ID: <12CF0ECF-E439-4138-BFBD-C051D946E193@mac.com> When 1.3-dev-r12166M-trunk launches, the IDE listener does not print a banner; instead, Alt Console opens with the banner and a listener prompt. IOW, the listener is in Alt Console. regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From gb at clozure.com Sun May 31 18:04:58 2009 From: gb at clozure.com (Gary Byers) Date: Sun, 31 May 2009 19:04:58 -0600 (MDT) Subject: [Openmcl-devel] 1.3-dev-r12166M-trunk launches with listener in Alt Console In-Reply-To: <12CF0ECF-E439-4138-BFBD-C051D946E193@mac.com> References: <12CF0ECF-E439-4138-BFBD-C051D946E193@mac.com> Message-ID: That is -so- r2166. On Sun, 31 May 2009, Raffael Cavallaro wrote: > When 1.3-dev-r12166M-trunk launches, the IDE listener does not print a > banner; instead, Alt Console opens with the banner and a listener > prompt. IOW, the listener is in Alt Console. > > regards, > > Ralph > > > Raffael Cavallaro > raffaelcavallaro at me.com > > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > >