From joakim at joakimsandgren.com Mon Jun 1 03:09:33 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Mon, 1 Jun 2009 12:09:33 +0200 Subject: [Openmcl-devel] lost word completion Message-ID: <0854CF3D-6995-430D-B1AE-FBCBCEB1BADF@joakimsandgren.com> Hi, The two latest trunks I have are r12148M and r12169M. In r12148M with the button "use option key as meta" back slash has functioned as a word completion. In r12148M without th button use option key as meta" back slash has been backslash. In r12148M backslash has given backslash with or without "use option key as meta" in the Apropos, Search File, and Find windows... In r12169 I now have only backslash as backslash, with ot without "use option key as meta" everywhere. Is this a bug, or have the word completion functionality been moved to another key? 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 Mon Jun 1 05:19:42 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 1 Jun 2009 06:19:42 -0600 (MDT) Subject: [Openmcl-devel] lost word completion In-Reply-To: <0854CF3D-6995-430D-B1AE-FBCBCEB1BADF@joakimsandgren.com> References: <0854CF3D-6995-430D-B1AE-FBCBCEB1BADF@joakimsandgren.com> Message-ID: On Mon, 1 Jun 2009, Joakim Sandgren wrote: > Hi,The two latest trunks I have are r12148M and r12169M. > > In r12148M with the button "use option key as meta" back slash has > functioned as a word completion. > In r12148M without th button use option key as meta" back slash has been > backslash. > In r12148M backslash has given backslash with or without "use option key as > meta" in the Apropos, Search File, and Find windows... > > In r12169 I now have only backslash as backslash, with ot without "use > option key as meta" everywhere. > Is this a bug, or have the word completion functionality been moved to > another key? > Word-completion functionality (the Hemlock command "Expand Dynamic Abbreviation") has alway been bound to the Hemlock key events "meta-/" and "meta-`". On a French keyboard, it doesn't seem possible to type a backquote with a single keystroke, and option-/ is the standard way of typing a backslash. r12169 changed the way that keystrokes in editor and listener windows are interpreted when "use option key as meta" is enabled and the option key is pressed; if that keystroke would produce a STANDARD-CHAR (in the CL sense) in the current keyboard layout, then the character is inserted as if "Quoted Insert" (c-q) was in effect; otherwise, a Hemlock key event with the meta modifier is generated. This change is intended to make it easier to type STANDARD-CHARs (like #\backslash) that may require use of the option key to generate them, but it also means that the option key can't be used to set the Hemlock meta modifier if it would have caused a STANDARD-CHAR to be generated. It's always possible to generate a Hemlock key event that has the meta modifier set by using the escape (ESC) key as a prefix: typing the ESC key followed by any key X is treated just as if you'd typed "meta-X" on a keyboard that had a meta key, so typing "esc-/" in an editor or listener window will ordinarily run the "Expand Dynamic Abbreviation" (lisp symbol completion) command. > 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 joakim at joakimsandgren.com Mon Jun 1 05:24:27 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Mon, 1 Jun 2009 14:24:27 +0200 Subject: [Openmcl-devel] Fwd: lost word completion References: <0854CF3D-6995-430D-B1AE-FBCBCEB1BADF@joakimsandgren.com> Message-ID: <48109EFF-43E9-4EBB-A6C6-1C84619F2223@joakimsandgren.com> the latest trunk I have where this option key as meta still works is 12165 and not 12148. and in 12169 this is broken. D?but du message r?exp?di? : > De : Joakim Sandgren > Date : 1 juin 2009 12:09:33 HAEC > ? : Openmcl-devel Devel > Objet : [Openmcl-devel] lost word completion > > Hi, > The two latest trunks I have are r12148M and r12169M. > > In r12148M with the button "use option key as meta" back slash has > functioned as a word completion. > In r12148M without th button use option key as meta" back slash has > been backslash. > In r12148M backslash has given backslash with or without "use option > key as meta" in the Apropos, Search File, and Find windows... > > In r12169 I now have only backslash as backslash, with ot without > "use option key as meta" everywhere. > Is this a bug, or have the word completion functionality been moved > to another key? > > 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 joakim at joakimsandgren.com Mon Jun 1 05:26:36 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Mon, 1 Jun 2009 14:26:36 +0200 Subject: [Openmcl-devel] trunk 12180 Message-ID: Hi, with trunk r12180M the (require 'cocoa-application) stalles at the last moment. the app trying to boot with a type (y: 0) to do something but I failed to have something happen... anyone have the same problem? 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 Jun 1 05:36:38 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Mon, 1 Jun 2009 14:36:38 +0200 Subject: [Openmcl-devel] lost word completion In-Reply-To: References: <0854CF3D-6995-430D-B1AE-FBCBCEB1BADF@joakimsandgren.com> Message-ID: Thank you Gary, Ok, please indicate me where and how to use esc-\ and I will try it immediately.. SIncerely Joakim Le 1 juin 09 ? 14:19, Gary Byers a ?crit : > > > On Mon, 1 Jun 2009, Joakim Sandgren wrote: > >> Hi,The two latest trunks I have are r12148M and r12169M. >> In r12148M with the button "use option key as meta" back slash has >> functioned as a word completion. In r12148M without th button use >> option key as meta" back slash has been >> backslash. >> In r12148M backslash has given backslash with or without "use >> option key as >> meta" in the Apropos, Search File, and Find windows... >> In r12169 I now have only backslash as backslash, with ot without >> "use >> option key as meta" everywhere. >> Is this a bug, or have the word completion functionality been moved >> to >> another key? >> > > Word-completion functionality (the Hemlock command "Expand Dynamic > Abbreviation") has alway been bound to the Hemlock key events "meta-/" > and "meta-`". On a French keyboard, it doesn't seem possible to type > a backquote with a single keystroke, and option-/ is the standard way > of typing a backslash. > > r12169 changed the way that keystrokes in editor and listener windows > are interpreted when "use option key as meta" is enabled and the > option key is pressed; if that keystroke would produce a STANDARD-CHAR > (in the CL sense) in the current keyboard layout, then the character > is inserted as if "Quoted Insert" (c-q) was in effect; otherwise, a > Hemlock key event with the meta modifier is generated. This change is > intended to make it easier to type STANDARD-CHARs (like #\backslash) > that may require use of the option key to generate them, but it also > means that the option key can't be used to set the Hemlock meta > modifier if it would have caused a STANDARD-CHAR to be generated. > > It's always possible to generate a Hemlock key event that has the meta > modifier set by using the escape (ESC) key as a prefix: typing the > ESC key followed by any key X is treated just as if you'd typed > "meta-X" on a keyboard that had a meta key, so typing "esc-/" in > an editor or listener window will ordinarily run the "Expand Dynamic > Abbreviation" (lisp symbol completion) command. > > > >> 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 >> > 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 Jun 1 06:14:33 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Mon, 1 Jun 2009 15:14:33 +0200 Subject: [Openmcl-devel] Fwd: lost word completion References: Message-ID: <3809155A-20E9-4CFD-AD3E-FDFB9BE37902@joakimsandgren.com> that is : could someone please show me how to do this? sincerely Joakim D?but du message r?exp?di? : > De : Joakim Sandgren > Date : 1 juin 2009 14:36:38 HAEC > ? : Gary Byers > Cc : Openmcl-devel Devel > Objet : R?p : [Openmcl-devel] lost word completion > > Thank you Gary, > Ok, please indicate me where and how to use esc-\ and I will try it > immediately.. > SIncerely > Joakim > Le 1 juin 09 ? 14:19, Gary Byers a ?crit : > >> >> >> On Mon, 1 Jun 2009, Joakim Sandgren wrote: >> >>> Hi,The two latest trunks I have are r12148M and r12169M. >>> In r12148M with the button "use option key as meta" back slash has >>> functioned as a word completion. In r12148M without th button use >>> option key as meta" back slash has been >>> backslash. >>> In r12148M backslash has given backslash with or without "use >>> option key as >>> meta" in the Apropos, Search File, and Find windows... >>> In r12169 I now have only backslash as backslash, with ot without >>> "use >>> option key as meta" everywhere. >>> Is this a bug, or have the word completion functionality been >>> moved to >>> another key? >>> >> >> Word-completion functionality (the Hemlock command "Expand Dynamic >> Abbreviation") has alway been bound to the Hemlock key events >> "meta-/" >> and "meta-`". On a French keyboard, it doesn't seem possible to type >> a backquote with a single keystroke, and option-/ is the standard way >> of typing a backslash. >> >> r12169 changed the way that keystrokes in editor and listener windows >> are interpreted when "use option key as meta" is enabled and the >> option key is pressed; if that keystroke would produce a STANDARD- >> CHAR >> (in the CL sense) in the current keyboard layout, then the character >> is inserted as if "Quoted Insert" (c-q) was in effect; otherwise, a >> Hemlock key event with the meta modifier is generated. This change >> is >> intended to make it easier to type STANDARD-CHARs (like #\backslash) >> that may require use of the option key to generate them, but it also >> means that the option key can't be used to set the Hemlock meta >> modifier if it would have caused a STANDARD-CHAR to be generated. >> >> It's always possible to generate a Hemlock key event that has the >> meta >> modifier set by using the escape (ESC) key as a prefix: typing the >> ESC key followed by any key X is treated just as if you'd typed >> "meta-X" on a keyboard that had a meta key, so typing "esc-/" in >> an editor or listener window will ordinarily run the "Expand Dynamic >> Abbreviation" (lisp symbol completion) command. >> >> >> >>> 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 >>> >> > > > > > 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 raffaelcavallaro at mac.com Mon Jun 1 07:16:03 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Mon, 01 Jun 2009 10:16:03 -0400 Subject: [Openmcl-devel] 1.4-dev-r12181M-trunk fails building 32-bit IDE Message-ID: <75799B15-8393-4EBF-98BA-C6BB52421A93@mac.com> 1.4-dev-r12181M-trunk builds the 64-bit IDE without incident, but fails building the 32-bit IDE: ;Loading #P"ccl:cocoa-ide;fasls;xinspector.dx32fsl.newest"... > Error: Undefined function NEXTSTEP-FUNCTIONS:| stringByReplacingOccurrencesOfString:withString:| called with arguments (# # #) . > While executing: (:INTERNAL GUI::|-[LispApplicationDelegate applicationWillFinishLaunching:]|), in process Initial(0). ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 0) to yield control to this thread. ;;; (:y 0) (* 3 3) ^C> Break: interrupt signal > While executing: %PROCESS-WAIT-ON-SEMAPHORE-PTR, in process listener(1). > Type cmd-/ to continue, cmd-/ to abort, cmd-\ for a list of available restarts. > If continued: Return from BREAK. > Type :? for other options. 1 > :r > Type (:C ) to invoke one of the following restarts: 0. Return to break level 1. 1. # 2. Return from BREAK. 3. Retry loading #P"/Users/raffaelc/ccl/cocoa-ide/cocoa- application.lisp" 4. Skip loading #P"/Users/raffaelc/ccl/cocoa-ide/cocoa-application.lisp" 5. Load other file instead of #P"/Users/raffaelc/ccl/cocoa-ide/cocoa- application.lisp" 6. Return to toplevel. 7. # 8. Reset this thread 9. Kill this thread 1 > :b (454B44) : 0 (%PROCESS-WAIT-ON-SEMAPHORE-PTR # 16777215 0 "semaphore wait" NIL) 255 (454B74) : 1 (WAIT-ON-SEMAPHORE # NIL "semaphore wait") 207 (454B90) : 2 (BUILD-IDE #P"ccl:Clozure CL32.app;") 167 (454B9C) : 3 (CALL-CHECK-REGS BUILD-IDE "ccl:Clozure CL32.app;") 247 (454BB8) : 4 (FUNCALL #'#<(:INTERNAL WITH-COMPILATION-UNIT-BODY LOAD- FROM-STREAM)>) 671 (454BF4) : 5 (CALL-WITH-COMPILATION-UNIT # :OVERRIDE NIL) 183 (454C18) : 6 (LOAD-FROM-STREAM # NIL) 335 (454C38) : 7 (%LOAD #P"/Users/raffaelc/ccl/cocoa-ide/cocoa- application.lisp" NIL NIL :ERROR :DEFAULT) 3159 (454CD8) : 8 (LOAD #P"/Users/raffaelc/ccl/cocoa-ide/cocoa- application.lisp" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT- EXIST :ERROR :EXTERNAL-FORMAT :DEFAULT) 911 (454D24) : 9 (MODULE-PROVIDE-SEARCH-PATH COMMON-LISP-USER::COCOA- APPLICATION) 207 (454D38) : 10 (SOME-XX-ONE 0 NIL # (MODULE-PROVIDE-SEARCH-PATH)) 511 (454D60) : 11 (REQUIRE COMMON-LISP-USER::COCOA-APPLICATION NIL) 791 (454D8C) : 12 (CALL-CHECK-REGS REQUIRE COMMON-LISP-USER::COCOA- APPLICATION) 247 (454DA8) : 13 (TOPLEVEL-EVAL (REQUIRE 'COMMON-LISP-USER::COCOA- APPLICATION) NIL) 751 (454DE8) : 14 (READ-LOOP :INPUT-STREAM # :OUTPUT-STREAM # :BREAK-LEVEL 0 :PROMPT-FUNCTION #) 1831 (454EFC) : 15 (TOPLEVEL-LOOP) 71 (454F04) : 16 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION (LISP- DEVELOPMENT-SYSTEM T)))>) 95 (454F14) : 17 (FUNCALL #'#<(:INTERNAL MAKE-MCL-LISTENER-PROCESS)>) 583 (454F60) : 18 (RUN-PROCESS-INITIAL-FORM # (#)) 671 (454FA4) : 19 (FUNCALL #'#<(:INTERNAL (%PROCESS-PRESET-INTERNAL (PROCESS)))> # (#)) 335 (454FCC) : 20 (FUNCALL #'#<(:INTERNAL THREAD-MAKE-STARTUP- FUNCTION)>) 279 1 > Raffael Cavallaro raffaelcavallaro at me.com From rme at clozure.com Mon Jun 1 12:01:34 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 1 Jun 2009 15:01:34 -0400 Subject: [Openmcl-devel] 1.4-dev-r12181M-trunk fails building 32-bit IDE In-Reply-To: <75799B15-8393-4EBF-98BA-C6BB52421A93@mac.com> References: <75799B15-8393-4EBF-98BA-C6BB52421A93@mac.com> Message-ID: <3BAF832F-9335-432C-8C33-4928255E25A2@clozure.com> On Jun 1, 2009, at 10:16 AM, Raffael Cavallaro wrote: > 1.4-dev-r12181M-trunk builds the 64-bit IDE without incident, but > fails building the 32-bit IDE: > > ;Loading #P"ccl:cocoa-ide;fasls;xinspector.dx32fsl.newest"... >> Error: Undefined function NEXTSTEP-FUNCTIONS:| > stringByReplacingOccurrencesOfString:withString:| called with > arguments (# # "Clozure CL" (#x12B2E0)> #) . stringByReplacingOccurrencesOfString:withString: is a new-with-Leopard method. Even if you're running Leopard, on 32-bit systems, we use an interface database built from Tiger include files; the 32-bit lisp (even when running on Leopard) therefore doesn't know about the new method. Anyway, should be fixed in r12182. From matt at mclaus.com Mon Jun 1 13:07:17 2009 From: matt at mclaus.com (Matthew Claus) Date: Mon, 1 Jun 2009 16:07:17 -0400 (EDT) Subject: [Openmcl-devel] win32 exception compatibility Message-ID: <1243886837.97598735@192.168.1.71> Hi all, let me first say thank you to everyone who has helped produce and make available such an outstanding tool. I'm having a lot of fun with it. I am a complete novice with Clozure CL, so please take this question in that context. I'm running on 32 bit Windows XP SP2, using both the release and trunk version from subversion. Is CCL fundamentally compatible with foreign C++ code (built with Microsoft Visual C++) that may internally use C++ exceptions? I am calling a function in a foreign library and ending up at the lisp kernel debugger. I believe this is because the Microsoft compiler implements C++ exceptions with windows structured exceptions and as such, any throw in foreign code results in the CCL vectored exception handler being called. In this case, the debugger is entered on x86-exceptions.c, line 1992. I found this article on MSDN (http://support.microsoft.com/kb/185294) which identifies the exception code used by the VC compiler in implementing C++ exceptions. I patched windows_arbstack_exception_handler like this: ? ? ?if ((current_sp >= cs->low) && ? ? ? ?(current_sp < cs->high)) { ? ? ?debug_show_registers(context, exception_pointers->ExceptionRecord, 0); --> ?if(code == 0xE06D7363){ --> ? ?return EXCEPTION_CONTINUE_SEARCH; --> } ? ? ?FBug(context, "Exception on foreign stack\n"); ? ? ?return EXCEPTION_CONTINUE_EXECUTION; ? ?} Now my application is working fine but I'm wondering if I'm simply doing something wrong in the first place, if there is a better approach to solving this problem, or if calling foreign C++ code that is internally using exceptions is not intended to work at this time. Thanks very much for your thoughts and assistance, Matt From taoufik.dachraoui at wanadoo.fr Mon Jun 1 13:31:20 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Mon, 1 Jun 2009 22:31:20 +0200 Subject: [Openmcl-devel] eval-in-package Message-ID: <06459138-3FAC-4118-A005-2474C6470FD1@wanadoo.fr> Hi I wrote 2 functions slightly different to evaluate a lisp body in a given package one is wrong and the other is correct at least for the test I run). The problem I could not understand why this is so, both functions looks correct as far as I can tell; (make-package 'here) (make-package 'there) (in-package 'here) (defun eval-in-package-1 (pkg) ; wrong (let ((req (read)) (*package* (find-package pkg))) (eval (read-from-string (format nil "~S" req))))) (defun eval-in-package-2 (pkg) ; correct (let ((req (format nil "~S" (read))) (*package* (find-package pkg))) (eval (read-from-string req)))) ? (eval-in-package-1 'there) (setq a 1) 1 ? ? (eval-in-package-2 'there) (setq b 1) 1 ? ? here::a ;;;;;;;;;; wrong; a must be defined in package there 1 ? here::b ;;;;; this correct, b is defined in package there > Error: Unbound variable: B > While executing: CCL::TOPLEVEL-EVAL, 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 B. > Type :? for other options. 1 > :pop ? there::a > Error: Unbound variable: THERE::A > While executing: CCL::TOPLEVEL-EVAL, 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 THERE::A. > Type :? for other options. 1 > :pop ? there::b ;; correct 1 ? Kind regards -Taoufik From gb at clozure.com Mon Jun 1 13:36:15 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 1 Jun 2009 14:36:15 -0600 (MDT) Subject: [Openmcl-devel] win32 exception compatibility In-Reply-To: <1243886837.97598735@192.168.1.71> References: <1243886837.97598735@192.168.1.71> Message-ID: I'd be shocked if this worked fully and generally, though the change that you made is likely a necessary first step. Suppose that some thread is executing a mixture of C[++] and lisp code (lisp code calls C code which calls back to lisp and calls out to C, etc.) For GC reasons, we actually execute lisp and foreign code on different stacks, but we can think of it as being a single stack with alternating lisp and foreign regions. If an exception (or lisp error) occurs and we need to transfer control to a handler (whether that's a lisp or foreign handler), we need to take care when unwinding the stack to ensure that both C and foreign stacks (or stack regions) are unwound safely (have the opportunity to run the moral equivalent of UNWIND-PROTECT cleanup forms in the right execution context, etc.) The same issue arises in the ObjC bridge on OSX, and we handle it (by hooking ourselves into the ObjC runtime's exception handling mechanisms and doing special things whenever we transition between ObjC and lisp code. It might or might not be possible to do similar things to get the CCL and MSVC++ runtimes to cooperate when exceptions occur, but there's no code in place in CCL that tries to make the right thing happen. If you call out to some foreign code, that code establishes an exception handler then does something that causes an exception without any lisp code between the point where the handler was established and the point where the exception occurred, that should work as expected (and your change is likely necessary to maje it work.) If there's lisp code (callbacks) "between" the handler and the point where the exception occurred, then any UNWIND-PROTECT cleanups in that lisp code wouldn't run and other things may misbehave. On Mon, 1 Jun 2009, Matthew Claus wrote: > Hi all, let me first say thank you to everyone who has helped produce > and make available such an outstanding tool. I'm having a lot of fun > with it. > > I am a complete novice with Clozure CL, so please take this question in > that context. I'm running on 32 bit Windows XP SP2, using both the > release and trunk version from subversion. > > Is CCL fundamentally compatible with foreign C++ code (built with > Microsoft Visual C++) that may internally use C++ exceptions? > > I am calling a function in a foreign library and ending up at the lisp > kernel debugger. I believe this is because the Microsoft compiler > implements C++ exceptions with windows structured exceptions and as > such, any throw in foreign code results in the CCL vectored > exception handler being called. In this case, the debugger is > entered on x86-exceptions.c, line 1992. > > I found this article on MSDN (http://support.microsoft.com/kb/185294) > which identifies the exception code used by the VC compiler in implementing C++ > exceptions. I patched windows_arbstack_exception_handler like this: > > if ((current_sp >= cs->low) && > (current_sp < cs->high)) { > debug_show_registers(context, exception_pointers->ExceptionRecord, 0); > > --> if(code == 0xE06D7363){ > --> return EXCEPTION_CONTINUE_SEARCH; > --> } > FBug(context, "Exception on foreign stack\n"); > return EXCEPTION_CONTINUE_EXECUTION; > } > > Now my application is working fine but I'm wondering if I'm simply > doing something wrong in the first place, if there is a better > approach to solving this problem, or if calling foreign C++ code that > is internally using exceptions is not intended to work at this time. > > Thanks very much for your thoughts and assistance, > > Matt > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From dlw at itasoftware.com Mon Jun 1 13:44:06 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Mon, 01 Jun 2009 16:44:06 -0400 Subject: [Openmcl-devel] eval-in-package In-Reply-To: <06459138-3FAC-4118-A005-2474C6470FD1@wanadoo.fr> References: <06459138-3FAC-4118-A005-2474C6470FD1@wanadoo.fr> Message-ID: <4A243D96.1080508@itasoftware.com> The difference is that the first one is printing in the context of "pkg" but the second is printing in the context of the current package. This is probably all educational for you, but you should know that no real Lisp program would do anything like this. Taoufik Dachraoui wrote: > Hi > > I wrote 2 functions slightly different to evaluate a lisp body in a > given package > one is wrong and the other is correct at least for the test I run). > > The problem I could not understand why this is so, both functions > looks correct > as far as I can tell; > > (make-package 'here) > (make-package 'there) > > (in-package 'here) > > (defun eval-in-package-1 (pkg) ; wrong > (let ((req (read)) > (*package* (find-package pkg))) > (eval (read-from-string (format nil "~S" req))))) > > (defun eval-in-package-2 (pkg) ; correct > (let ((req (format nil "~S" (read))) > (*package* (find-package pkg))) > (eval (read-from-string req)))) > > > ? (eval-in-package-1 'there) > (setq a 1) > > 1 > ? > ? (eval-in-package-2 'there) > (setq b 1) > > 1 > ? > ? here::a ;;;;;;;;;; wrong; a must be defined in package there > 1 > ? here::b ;;;;; this correct, b is defined in package there > > Error: Unbound variable: B > > While executing: CCL::TOPLEVEL-EVAL, 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 B. > > Type :? for other options. > 1 > :pop > > ? there::a > > Error: Unbound variable: THERE::A > > While executing: CCL::TOPLEVEL-EVAL, 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 THERE::A. > > Type :? for other options. > 1 > :pop > > ? there::b ;; correct > 1 > ? > > > > Kind regards > > -Taoufik > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From taoufik.dachraoui at wanadoo.fr Mon Jun 1 13:53:00 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Mon, 1 Jun 2009 22:53:00 +0200 Subject: [Openmcl-devel] eval-in-package In-Reply-To: <4A243D96.1080508@itasoftware.com> References: <06459138-3FAC-4118-A005-2474C6470FD1@wanadoo.fr> <4A243D96.1080508@itasoftware.com> Message-ID: I would like to have more details, I do not understand why there is a difference. If you look at (eval (read-from-string str)) form, in both functions read-from-string is supposed to read from a string and I think that at that point in both function the string is the same "(setq a 1)" so why ther eis a difference? thank you giving me more details. I am planning to use this in production for lisp server allowing many clients to connect to a lisp server and executes lisp commands. I will try to modify the reader so that no one can access internal symbols from any other package. (I am not sure about how yet) -Taoufik On Jun 1, 2009, at 10:44 PM, Dan Weinreb wrote: > > The difference is that the first one is printing > in the context of "pkg" but the second is > printing in the context of the current package. > > This is probably all educational for you, but > you should know that no real Lisp program > would do anything like this. > > > > Taoufik Dachraoui wrote: >> Hi >> >> I wrote 2 functions slightly different to evaluate a lisp body in >> a given package >> one is wrong and the other is correct at least for the test I run). >> >> The problem I could not understand why this is so, both functions >> looks correct >> as far as I can tell; >> >> (make-package 'here) >> (make-package 'there) >> >> (in-package 'here) >> >> (defun eval-in-package-1 (pkg) ; wrong >> (let ((req (read)) >> (*package* (find-package pkg))) >> (eval (read-from-string (format nil "~S" req))))) >> >> (defun eval-in-package-2 (pkg) ; correct >> (let ((req (format nil "~S" (read))) >> (*package* (find-package pkg))) >> (eval (read-from-string req)))) >> >> >> ? (eval-in-package-1 'there) >> (setq a 1) >> >> 1 >> ? >> ? (eval-in-package-2 'there) >> (setq b 1) >> >> 1 >> ? >> ? here::a ;;;;;;;;;; wrong; a must be defined in package there >> 1 >> ? here::b ;;;;; this correct, b is defined in package there >> > Error: Unbound variable: B >> > While executing: CCL::TOPLEVEL-EVAL, 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 B. >> > Type :? for other options. >> 1 > :pop >> >> ? there::a >> > Error: Unbound variable: THERE::A >> > While executing: CCL::TOPLEVEL-EVAL, 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 THERE::A. >> > Type :? for other options. >> 1 > :pop >> >> ? there::b ;; correct >> 1 >> ? >> >> >> >> Kind regards >> >> -Taoufik >> >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> > From danieldickison at gmail.com Mon Jun 1 14:03:53 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Mon, 1 Jun 2009 17:03:53 -0400 Subject: [Openmcl-devel] eval-in-package In-Reply-To: References: <06459138-3FAC-4118-A005-2474C6470FD1@wanadoo.fr> <4A243D96.1080508@itasoftware.com> Message-ID: <72DC2673-172F-4C18-AF9C-1D4A7CAF41B0@gmail.com> Let's say you type "here" when it waits on READ and you're currently in CL-USER... >>> (defun eval-in-package-1 (pkg) ; wrong >>> (let ((req (read)) At this point REQ holds CL-USER::HERE. >>> (*package* (find-package pkg))) >>> (eval (read-from-string (format nil "~S" req))))) The FORMAT returns "CL-USER::HERE", which gets read as a symbol in CL- USER. >>> (defun eval-in-package-2 (pkg) ; correct >>> (let ((req (format nil "~S" (read))) READ returns CL-USER::HERE, but FORMAT returns "HERE" (without the package prefix) since the current package is the same package as the symbol. >>> (*package* (find-package pkg))) >>> (eval (read-from-string req)))) Reading "HERE" returns a symbol in the current package, which is now the package that you have specified. Maybe this will help... ? (format t "~S" (read-from-string "FOO")) FOO NIL ? (format t "~S" (read-from-string "CCL::FOO")) CCL::FOO NIL (Hope I didn't offend if some of this was already obvious to you -- I could be mistaken exactly what you were confused with). Daniel On Jun 1, 2009, at 4:53 PM, Taoufik Dachraoui wrote: > I would like to have more details, I do not understand why there is a > difference. > > If you look at (eval (read-from-string str)) form, in both functions > read-from-string > is supposed to read from a string and I think that at that point in > both function the > string is the same "(setq a 1)" > > so why ther eis a difference? thank you giving me more details. > > I am planning to use this in production for lisp server allowing many > clients to connect to a lisp server and executes lisp commands. > > I will try to modify the reader so that no one can access internal > symbols > from any other package. (I am not sure about how yet) > > -Taoufik > > On Jun 1, 2009, at 10:44 PM, Dan Weinreb wrote: > >> >> The difference is that the first one is printing >> in the context of "pkg" but the second is >> printing in the context of the current package. >> >> This is probably all educational for you, but >> you should know that no real Lisp program >> would do anything like this. >> >> >> >> Taoufik Dachraoui wrote: >>> Hi >>> >>> I wrote 2 functions slightly different to evaluate a lisp body in >>> a given package >>> one is wrong and the other is correct at least for the test I run). >>> >>> The problem I could not understand why this is so, both functions >>> looks correct >>> as far as I can tell; >>> >>> (make-package 'here) >>> (make-package 'there) >>> >>> (in-package 'here) >>> >>> (defun eval-in-package-1 (pkg) ; wrong >>> (let ((req (read)) >>> (*package* (find-package pkg))) >>> (eval (read-from-string (format nil "~S" req))))) >>> >>> (defun eval-in-package-2 (pkg) ; correct >>> (let ((req (format nil "~S" (read))) >>> (*package* (find-package pkg))) >>> (eval (read-from-string req)))) >>> >>> >>> ? (eval-in-package-1 'there) >>> (setq a 1) >>> >>> 1 >>> ? >>> ? (eval-in-package-2 'there) >>> (setq b 1) >>> >>> 1 >>> ? >>> ? here::a ;;;;;;;;;; wrong; a must be defined in package >>> there >>> 1 >>> ? here::b ;;;;; this correct, b is defined in package there >>>> Error: Unbound variable: B >>>> While executing: CCL::TOPLEVEL-EVAL, 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 B. >>>> Type :? for other options. >>> 1 > :pop >>> >>> ? there::a >>>> Error: Unbound variable: THERE::A >>>> While executing: CCL::TOPLEVEL-EVAL, 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 THERE::A. >>>> Type :? for other options. >>> 1 > :pop >>> >>> ? there::b ;; correct >>> 1 >>> ? >>> >>> >>> >>> Kind regards >>> >>> -Taoufik >>> >>> >>> _______________________________________________ >>> 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 Mon Jun 1 14:07:09 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Mon, 01 Jun 2009 17:07:09 -0400 Subject: [Openmcl-devel] 1.4-dev-r12181M-trunk fails building 32-bit IDE In-Reply-To: <3BAF832F-9335-432C-8C33-4928255E25A2@clozure.com> References: <75799B15-8393-4EBF-98BA-C6BB52421A93@mac.com> <3BAF832F-9335-432C-8C33-4928255E25A2@clozure.com> Message-ID: On Jun 1, 2009, at 3:01 PM, R. Matthew Emerson wrote: > stringByReplacingOccurrencesOfString:withString: is a new-with- > Leopard method. > > Even if you're running Leopard, on 32-bit systems, we use an > interface database built from Tiger include files; the 32-bit lisp > (even when running on Leopard) therefore doesn't know about the new > method. > > Anyway, should be fixed in r12182. Thanks for the explanation, and the quick fix! warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From dlw at itasoftware.com Mon Jun 1 14:12:20 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Mon, 01 Jun 2009 17:12:20 -0400 Subject: [Openmcl-devel] eval-in-package In-Reply-To: References: <06459138-3FAC-4118-A005-2474C6470FD1@wanadoo.fr> <4A243D96.1080508@itasoftware.com> Message-ID: <4A244434.9030605@itasoftware.com> It's because the the order in which you (a) bind *package* and (b) call read-from-string. Taoufik Dachraoui wrote: > I would like to have more details, I do not understand why there is a > difference. > > If you look at (eval (read-from-string str)) form, in both functions > read-from-string > is supposed to read from a string and I think that at that point in > both function the > string is the same "(setq a 1)" > > so why ther eis a difference? thank you giving me more details. > > I am planning to use this in production for lisp server allowing many > clients to connect to a lisp server and executes lisp commands. If you want to write a server that allows a client to send the printed representations of Lisp forms (over the network), so that the server evaluates the forms, then what you should do is bind *package* to whatever value is ought to have, and then call the Lisp reader on the printed representation coming in from the client, to produce Lisp data, which you can then "eval". Usually it's not such a good idea to have a server that evaluates arbitrary Lisp forms, since by accident, or maliciously, the client can cause anything at all to happen. However, if that's what you want to do, go ahead... -- Dan > > I will try to modify the reader so that no one can access internal > symbols > from any other package. (I am not sure about how yet) > > -Taoufik > > On Jun 1, 2009, at 10:44 PM, Dan Weinreb wrote: > >> >> The difference is that the first one is printing >> in the context of "pkg" but the second is >> printing in the context of the current package. >> >> This is probably all educational for you, but >> you should know that no real Lisp program >> would do anything like this. >> >> >> >> Taoufik Dachraoui wrote: >>> Hi >>> >>> I wrote 2 functions slightly different to evaluate a lisp body in a >>> given package >>> one is wrong and the other is correct at least for the test I run). >>> >>> The problem I could not understand why this is so, both functions >>> looks correct >>> as far as I can tell; >>> >>> (make-package 'here) >>> (make-package 'there) >>> >>> (in-package 'here) >>> >>> (defun eval-in-package-1 (pkg) ; wrong >>> (let ((req (read)) >>> (*package* (find-package pkg))) >>> (eval (read-from-string (format nil "~S" req))))) >>> >>> (defun eval-in-package-2 (pkg) ; correct >>> (let ((req (format nil "~S" (read))) >>> (*package* (find-package pkg))) >>> (eval (read-from-string req)))) >>> >>> >>> ? (eval-in-package-1 'there) >>> (setq a 1) >>> >>> 1 >>> ? >>> ? (eval-in-package-2 'there) >>> (setq b 1) >>> >>> 1 >>> ? >>> ? here::a ;;;;;;;;;; wrong; a must be >>> defined in package there >>> 1 >>> ? here::b ;;;;; this correct, b is >>> defined in package there >>> > Error: Unbound variable: B >>> > While executing: CCL::TOPLEVEL-EVAL, 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 B. >>> > Type :? for other options. >>> 1 > :pop >>> >>> ? there::a >>> > Error: Unbound variable: THERE::A >>> > While executing: CCL::TOPLEVEL-EVAL, 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 THERE::A. >>> > Type :? for other options. >>> 1 > :pop >>> >>> ? there::b ;; correct >>> 1 >>> ? >>> >>> >>> >>> Kind regards >>> >>> -Taoufik >>> >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >> > > From info at joakimsandgren.com Mon Jun 1 14:27:36 2009 From: info at joakimsandgren.com (Joakim Sandgren) Date: Mon, 1 Jun 2009 23:27:36 +0200 Subject: [Openmcl-devel] hemlock commands Message-ID: <82B2E3EA-F36E-48EB-9795-1C42B1A4D33D@joakimsandgren.com> Hi, Well I have it working with esc as meta and then shift-slash. I admit it's a little awkward to have to do it in two steps... Are there a workaround for this beautiful french multi-keystroke backslash? Can I program hemlock myself? I still think this is starting to be a quite beautiful ide.. ! I am composing with it now. Next step for me are Windows.... with some simple graphics in to show me the graphs of my parameters... (it's better ;-)) Are there somebody out there thinking about some clos-y window- functions?... 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 matt at mclaus.com Mon Jun 1 14:30:10 2009 From: matt at mclaus.com (Matthew Claus) Date: Mon, 1 Jun 2009 17:30:10 -0400 (EDT) Subject: [Openmcl-devel] win32 exception compatibility In-Reply-To: References: <1243886837.97598735@192.168.1.71> Message-ID: <1243891810.905610971@192.168.1.71> Thanks for your quick and thoughtful response Gary, that makes it perfectly clear what should probably work with this change and what certainly will not. I will continue to experiment, better learn the code and try to identify further changes necessary for the more general cases. Regards, Matt -----Original Message----- From: "Gary Byers" Sent: Monday, June 1, 2009 4:36pm To: "Matthew Claus" Cc: openmcl-devel at clozure.com Subject: Re: [Openmcl-devel] win32 exception compatibility I'd be shocked if this worked fully and generally, though the change that you made is likely a necessary first step. Suppose that some thread is executing a mixture of C[++] and lisp code (lisp code calls C code which calls back to lisp and calls out to C, etc.) For GC reasons, we actually execute lisp and foreign code on different stacks, but we can think of it as being a single stack with alternating lisp and foreign regions. If an exception (or lisp error) occurs and we need to transfer control to a handler (whether that's a lisp or foreign handler), we need to take care when unwinding the stack to ensure that both C and foreign stacks (or stack regions) are unwound safely (have the opportunity to run the moral equivalent of UNWIND-PROTECT cleanup forms in the right execution context, etc.) The same issue arises in the ObjC bridge on OSX, and we handle it (by hooking ourselves into the ObjC runtime's exception handling mechanisms and doing special things whenever we transition between ObjC and lisp code. It might or might not be possible to do similar things to get the CCL and MSVC++ runtimes to cooperate when exceptions occur, but there's no code in place in CCL that tries to make the right thing happen. If you call out to some foreign code, that code establishes an exception handler then does something that causes an exception without any lisp code between the point where the handler was established and the point where the exception occurred, that should work as expected (and your change is likely necessary to maje it work.) If there's lisp code (callbacks) "between" the handler and the point where the exception occurred, then any UNWIND-PROTECT cleanups in that lisp code wouldn't run and other things may misbehave. On Mon, 1 Jun 2009, Matthew Claus wrote: > Hi all, let me first say thank you to everyone who has helped produce > and make available such an outstanding tool. I'm having a lot of fun > with it. > > I am a complete novice with Clozure CL, so please take this question in > that context. I'm running on 32 bit Windows XP SP2, using both the > release and trunk version from subversion. > > Is CCL fundamentally compatible with foreign C++ code (built with > Microsoft Visual C++) that may internally use C++ exceptions? > > I am calling a function in a foreign library and ending up at the lisp > kernel debugger. I believe this is because the Microsoft compiler > implements C++ exceptions with windows structured exceptions and as > such, any throw in foreign code results in the CCL vectored > exception handler being called. In this case, the debugger is > entered on x86-exceptions.c, line 1992. > > I found this article on MSDN (http://support.microsoft.com/kb/185294) > which identifies the exception code used by the VC compiler in implementing C++ > exceptions. I patched windows_arbstack_exception_handler like this: > > if ((current_sp >= cs->low) && > (current_sp < cs->high)) { > debug_show_registers(context, exception_pointers->ExceptionRecord, 0); > > --> if(code == 0xE06D7363){ > --> return EXCEPTION_CONTINUE_SEARCH; > --> } > FBug(context, "Exception on foreign stack\n"); > return EXCEPTION_CONTINUE_EXECUTION; > } > > Now my application is working fine but I'm wondering if I'm simply > doing something wrong in the first place, if there is a better > approach to solving this problem, or if calling foreign C++ code that > is internally using exceptions is not intended to work at this time. > > Thanks very much for your thoughts and assistance, > > Matt > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From rme at clozure.com Mon Jun 1 14:44:23 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 1 Jun 2009 17:44:23 -0400 Subject: [Openmcl-devel] hemlock commands In-Reply-To: <82B2E3EA-F36E-48EB-9795-1C42B1A4D33D@joakimsandgren.com> References: <82B2E3EA-F36E-48EB-9795-1C42B1A4D33D@joakimsandgren.com> Message-ID: On Jun 1, 2009, at 5:27 PM, Joakim Sandgren wrote: > Hi, > Well I have it working with esc as meta and then shift-slash. I > admit it's a little awkward to have to do it in two steps... > Are there a workaround for this beautiful french multi-keystroke > backslash? Can I program hemlock myself? > (hi:bind-key "Expand Dynamic Abbreviation" #k"meta-tab") Or whatever key is convenient, if you don't like meta-tab. From info at joakimsandgren.com Mon Jun 1 14:49:33 2009 From: info at joakimsandgren.com (Joakim Sandgren) Date: Mon, 1 Jun 2009 23:49:33 +0200 Subject: [Openmcl-devel] hemlock commands In-Reply-To: References: <82B2E3EA-F36E-48EB-9795-1C42B1A4D33D@joakimsandgren.com> Message-ID: Oh,Thank you so much ! I'm crying of joy! Yours Joakim Le 1 juin 09 ? 23:44, R. Matthew Emerson a ?crit : > > On Jun 1, 2009, at 5:27 PM, Joakim Sandgren wrote: > >> Hi, >> Well I have it working with esc as meta and then shift-slash. I >> admit it's a little awkward to have to do it in two steps... >> Are there a workaround for this beautiful french multi-keystroke >> backslash? Can I program hemlock myself? >> > > (hi:bind-key "Expand Dynamic Abbreviation" #k"meta-tab") > > Or whatever key is convenient, if you don't like meta-tab. > > 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 gwking at metabang.com Tue Jun 2 05:53:14 2009 From: gwking at metabang.com (Gary King) Date: Tue, 2 Jun 2009 08:53:14 -0400 Subject: [Openmcl-devel] getting asdf to the masses Message-ID: <56C2F0F7-A01C-4317-9D3A-F6BBF9A39DD7@metabang.com> Is there any current mechanism to get the latest (and therefore one hopes greatest) version of ASDF into SBCL / Allegro CL / Clozure CL, etc.? If not, I think there should be. What would it look like? thanks, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter From millejoh at mac.com Tue Jun 2 06:00:55 2009 From: millejoh at mac.com (John Miller) Date: Tue, 02 Jun 2009 08:00:55 -0500 Subject: [Openmcl-devel] Simple Agent-based Engine 0.2 In-Reply-To: <32028895-F5F1-4F25-8EAF-94AA4F23DC88@cs.colorado.edu> References: <1e6b7d810905292230k874521n95e016de025eaf83@mail.gmail.com> <32028895-F5F1-4F25-8EAF-94AA4F23DC88@cs.colorado.edu> Message-ID: I think there was a comment some time ago about doing the NeHe tutorials in Lisp. At the moment there is an attempt at http://code.google.com/p/dreaming-tree/ to do this. For the moment I am not using Xmlisp, but I hope to soon change this (as job and insistent 3-year olds allow, of course). There is also the beginning's of an FFI to the Chipmunk 2D physics package. Most of my interest is in 2D graphics (that's code for "can't think in 3D") and I picked Chipmunk mostly because it was written in C and has a reasonably clean and simple API. I am not at all proud of the code, but it is something and if a brave soul wants to play around with it a bit then, well, many kudos to you. For sure many thanks to the Clozure team for putting together such a powerful and advanced tool and releasing it for free to the greater community. I haven't had this much fun programming in some time, and as I am not a programmer by trade that means everything in the world. Regards, John On May 30, 2009, at 12:04 PM, Alexander Repenning wrote: > > 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 > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From nikodemus at random-state.net Tue Jun 2 07:39:14 2009 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Tue, 2 Jun 2009 17:39:14 +0300 Subject: [Openmcl-devel] [asdf-devel] getting asdf to the masses In-Reply-To: <56C2F0F7-A01C-4317-9D3A-F6BBF9A39DD7@metabang.com> References: <56C2F0F7-A01C-4317-9D3A-F6BBF9A39DD7@metabang.com> Message-ID: <633d72b0906020739q1eb3e7d2vb81db50755831fb1@mail.gmail.com> 2009/6/2 Gary King : > Is there any current mechanism to get the latest (and therefore one > hopes greatest) version of ASDF into SBCL / Allegro CL / Clozure CL, > etc.? If not, I think there should be. What would it look like? SBCL updates the version it comes with every once and a while -- so nothing ASDF as a project needs to worry about. (Since we didn't update it before the freeze I'm not going to update it now, but will do so for 1.0.29.something-early.) Don't know about the others. Cheers, -- Nikodemus From rwiker at gmail.com Tue Jun 2 08:20:36 2009 From: rwiker at gmail.com (Raymond Wiker) Date: Tue, 2 Jun 2009 17:20:36 +0200 Subject: [Openmcl-devel] Building trunk on Windows Message-ID: I tried building trunk today, using (ccl:rebuild-ccl). This failed: c:\devel\ccl>wx86cl.exe Welcome to Clozure Common Lisp Version 1.3-dev-r11877M-trunk (WindowsX8632)! ? (rebuild-ccl) ;Compiling "c:/devel/ccl/lib/dumplisp.lisp"... > Error: Unknown kernel global : KERNEL-PATH . > While executing: X8632::%KERNEL-GLOBAL, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > I'm guessing that the lisp kernel is too old to build current trunk... I'd rather avoid having to setup an environment for building the kernel, so would appreciate if some kind soul could upload a newer kernel. Doing the same exercise with release/1.3 (after doing svn update) worked fine. From ron at awun.net Tue Jun 2 09:41:23 2009 From: ron at awun.net (Ron Garret) Date: Tue, 2 Jun 2009 09:41:23 -0700 Subject: [Openmcl-devel] Calling STRETs without SEND Message-ID: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> Following an recent admonition that SEND is deprecated, I've been converting all my old code to call ObjC methods directly using the #/ reader macro. However, this doesn't seem to work for STRET calls, e.g.: (ccl::slet ((event-location (#/locationInWindow event)) ... gives me: > Error: Unrecognized STRET call in (NEXTSTEP-FUNCTIONS:| locationInWindow| EVENT) > While executing: CCL::SLETIFY, in process Listener(7). while: (ccl::slet ((event-location (send event 'location-In-Window)) ... works. The examples in the manual also use SEND. What is the proper way to call STRETs? rg From raffaelcavallaro at mac.com Tue Jun 2 09:49:06 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Tue, 02 Jun 2009 12:49:06 -0400 Subject: [Openmcl-devel] Calling STRETs without SEND In-Reply-To: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> References: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> Message-ID: <72FC7C84-A465-4B63-8378-9E9253C126B7@mac.com> On Jun 2, 2009, at 12:41 PM, Ron Garret wrote: > Following an recent admonition that SEND is deprecated, I've been > converting all my old code to call ObjC methods directly using the #/ > reader macro. However, this doesn't seem to work for STRET calls, > e.g.: > > (ccl::slet ((event-location (#/locationInWindow event)) ... > > gives me: > >> Error: Unrecognized STRET call in (NEXTSTEP-FUNCTIONS:| > locationInWindow| EVENT) >> While executing: CCL::SLETIFY, in process Listener(7). > > while: > > (ccl::slet ((event-location (send event 'location-In-Window)) ... > > works. > > The examples in the manual also use SEND. > > What is the proper way to call STRETs? I've just been converting these to ordinary let/let*: (let* ((bounds-rect (#/bounds view) ... The Clozure folks will let us know if this is inadvisable regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From ron at awun.net Tue Jun 2 10:06:30 2009 From: ron at awun.net (Ron Garret) Date: Tue, 2 Jun 2009 10:06:30 -0700 Subject: [Openmcl-devel] Calling STRETs without SEND In-Reply-To: <72FC7C84-A465-4B63-8378-9E9253C126B7@mac.com> References: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> <72FC7C84-A465-4B63-8378-9E9253C126B7@mac.com> Message-ID: <87036116-D03E-47F4-AACE-B11A1A220241@awun.net> On Jun 2, 2009, at 9:49 AM, Raffael Cavallaro wrote: > > On Jun 2, 2009, at 12:41 PM, Ron Garret wrote: > >> Following an recent admonition that SEND is deprecated, I've been >> converting all my old code to call ObjC methods directly using the #/ >> reader macro. However, this doesn't seem to work for STRET calls, >> e.g.: >> >> (ccl::slet ((event-location (#/locationInWindow event)) ... >> >> gives me: >> >>> Error: Unrecognized STRET call in (NEXTSTEP-FUNCTIONS:| >> locationInWindow| EVENT) >>> While executing: CCL::SLETIFY, in process Listener(7). >> >> while: >> >> (ccl::slet ((event-location (send event 'location-In-Window)) ... >> >> works. >> >> The examples in the manual also use SEND. >> >> What is the proper way to call STRETs? > > I've just been converting these to ordinary let/let*: > > (let* ((bounds-rect (#/bounds view) ... > > The Clozure folks will let us know if this is inadvisable Empirically this does seem to work, but section 13.4.2 of the CCL manual seems to imply that it shouldn't. So I'm a little hesitant to employ this technique without official blessing for fear of latent memory issues. rg From raffaelcavallaro at mac.com Tue Jun 2 11:43:16 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Tue, 02 Jun 2009 14:43:16 -0400 Subject: [Openmcl-devel] Calling STRETs without SEND In-Reply-To: <87036116-D03E-47F4-AACE-B11A1A220241@awun.net> References: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> <72FC7C84-A465-4B63-8378-9E9253C126B7@mac.com> <87036116-D03E-47F4-AACE-B11A1A220241@awun.net> Message-ID: On Jun 2, 2009, at 1:06 PM, Ron Garret wrote: > So I'm a little hesitant to > employ this technique without official blessing for fear of latent > memory issues. Same here, although a little rummaging around the source with meta-. seems to indicate that the #/ reader macro makes the bridge aware that the nextstep-function returns a structure. warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From rme at clozure.com Tue Jun 2 12:01:32 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 2 Jun 2009 15:01:32 -0400 Subject: [Openmcl-devel] Calling STRETs without SEND In-Reply-To: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> References: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> Message-ID: On Jun 2, 2009, at 12:41 PM, Ron Garret wrote: > Following an recent admonition that SEND is deprecated, I've been > converting all my old code to call ObjC methods directly using the #/ > reader macro. However, this doesn't seem to work for STRET calls, > e.g.: > > (ccl::slet ((event-location (#/locationInWindow event)) ... > > gives me: > >> Error: Unrecognized STRET call in (NEXTSTEP-FUNCTIONS:| > locationInWindow| EVENT) >> While executing: CCL::SLETIFY, in process Listener(7). > > while: > > (ccl::slet ((event-location (send event 'location-In-Window)) ... > > works. > > The examples in the manual also use SEND. > > What is the proper way to call STRETs? When using #/ notation, you don't need to make a distinction between methods that return a structure by value, and those that don't. So you can just say (let ((event-location (#/locationInWindow event))) ...) and forget about SLET entirely. There's some information about the use of the #/ reader macro in ccl:doc;release-notes-1.1.txt; here's an excerpt: ObjC methods that "return" structures return them as gcable pointers when called via dispatch functions. E.g., if "my-window" is an NS:NS-WINDOW instance, then (#/frame my-window) will return a gcable pointer to a structure that describes that window's frame rectangle. (The good news is that there's no need to use SLET or special structure-returning message send syntax; the bad news is that #_malloc, #_free, and the GC are all involved in the creation and eventual destruction of structure-typed return values. Unless and until those factors negatively affect performance, the advantages seem to outweigh the disadvantages.) Sorry that section 13 of the manual is so out-of-date. From ron at awun.net Tue Jun 2 12:04:23 2009 From: ron at awun.net (Ron Garret) Date: Tue, 2 Jun 2009 12:04:23 -0700 Subject: [Openmcl-devel] Calling STRETs without SEND In-Reply-To: References: <186624DB-D02E-4A12-9DEC-2188F05AAD10@awun.net> Message-ID: On Jun 2, 2009, at 12:01 PM, R. Matthew Emerson wrote: > > When using #/ notation, you don't need to make a distinction between > methods that return a structure by value, and those that don't. So > you can just say > > (let ((event-location (#/locationInWindow event))) > ...) > > and forget about SLET entirely. > Cool. > the bad news is > that #_malloc, #_free, and the GC are all involved in the creation > and eventual destruction of structure-typed return values. Unless > and until those factors negatively affect performance, the advantages > seem to outweigh the disadvantages.) Indeed. > > > Sorry that section 13 of the manual is so out-of-date. > No worries. Thanks for the info! rg From boyer at cs.utexas.edu Tue Jun 2 12:28:57 2009 From: boyer at cs.utexas.edu (Robert Boyer) Date: Tue, 2 Jun 2009 14:28:57 -0500 Subject: [Openmcl-devel] Using Lisp and many cores Message-ID: <200906021928.n52JSv7u001523@elgin.cs.utexas.edu> Matt Kaufmann (kaufmann at cs.utexas.edu) makes the normally hours-long ACL2 regression run with parallelism, effectively using as many as 8 cores simultaneously on a 12 core machine, an X86 Gnu-Linux running CCL. I suspect Matt can do the same thing on other cpu/lisp platforms. Matt's technique is to use the Gnu/Linux 'make' -j flag/option. The hundreds of Lisps jobs that are fired up read and write files written by one another, all organized in the usual 'make' style. Some might claim that this is not Lisp, or not parallelism, or cheating, or ... Maybe, but I now happily and very regularly use it, to the point that it has become a necessity rather than a novelty. Bob From ron at awun.net Tue Jun 2 13:23:51 2009 From: ron at awun.net (Ron Garret) Date: Tue, 2 Jun 2009 13:23:51 -0700 Subject: [Openmcl-devel] Autorelease question Message-ID: <37B8A693-EC7C-4ABC-8371-F7B8AD0385A7@awun.net> This question arises from ticket #526 (http://trac.clozure.com/ccl/ticket/526 ). I'm moving the discussion to the list because I thought this might be of general interest. I do this: (defclass scribble-view (ns:ns-view) ((path :initform (#/bezierPath ns:ns-bezier-path))) (:metaclass ns:+ns-object)) (defun make-scribble-window () (ccl::with-autorelease-pool (let* ((rect (ns:make-ns-rect 0 0 300 300)) (w (make-instance 'ns:ns-window :with-content-rect rect :style-mask (logior #$NSTitledWindowMask #$NSClosableWindowMask #$NSMiniaturizableWindowMask #$NSResizableWindowMask) :backing #$NSBackingStoreBuffered :defer t)) (v (make-instance 'scribble-view))) (#/setTitle: w #@"Scribble") (#/setContentView: w v) (#/center w) (#/orderFront: w nil) (print (slot-value v 'path)) v))) (slot-value (make-scribble-window) 'path) and the result is a bogus ObjC object. RME says this is because: "You are initializing the path slot in your scribble-view instance with an autoreleased NSBezierPath. The NSBezierPath instance will be released on the next trip through the event loop." But I don't understand why this should be the case. The NSBezierPath object was not allocated on the event loop thread, so why should it be (auto)released there? Doesn't every thread (and hence every listener) have its own autorelease pool? rg From rme at clozure.com Tue Jun 2 13:49:32 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 2 Jun 2009 16:49:32 -0400 Subject: [Openmcl-devel] Building trunk on Windows In-Reply-To: References: Message-ID: <8E5EC241-ADAD-4E34-883B-3B32EF3F7AAD@clozure.com> On Jun 2, 2009, at 11:20 AM, Raymond Wiker wrote: > c:\devel\ccl>wx86cl.exe > Welcome to Clozure Common Lisp Version 1.3-dev-r11877M-trunk > (WindowsX8632)! > ? (rebuild-ccl) > ;Compiling "c:/devel/ccl/lib/dumplisp.lisp"... >> Error: Unknown kernel global : KERNEL-PATH . >> While executing: X8632::%KERNEL-GLOBAL, in process listener(1). >> Type :POP to abort, :R for a list of available restarts. >> Type :? for other options. > 1 > > > I'm guessing that the lisp kernel is too old to build current trunk... > I'd rather avoid having to setup an environment for building the > kernel, so would appreciate if some kind soul could upload a newer > kernel. I checked updated lisp kernels for both 32- and 64-bit Windows into the trunk. From ron at awun.net Tue Jun 2 13:56:40 2009 From: ron at awun.net (Ron Garret) Date: Tue, 2 Jun 2009 13:56:40 -0700 Subject: [Openmcl-devel] Autorelease question In-Reply-To: <37B8A693-EC7C-4ABC-8371-F7B8AD0385A7@awun.net> References: <37B8A693-EC7C-4ABC-8371-F7B8AD0385A7@awun.net> Message-ID: <17FBFCC4-3524-4400-8853-89AD7FD37BD5@awun.net> Oh geez, never mind, I'm an idiot. There's a call to ccl::with- autorelease-pool in my code. Doh! rg On Jun 2, 2009, at 1:23 PM, Ron Garret wrote: > This question arises from ticket #526 (http://trac.clozure.com/ccl/ticket/526 > ). I'm moving the discussion to the list because I thought this might > be of general interest. > > I do this: > > (defclass scribble-view (ns:ns-view) > ((path :initform (#/bezierPath ns:ns-bezier-path))) > (:metaclass ns:+ns-object)) > > (defun make-scribble-window () > (ccl::with-autorelease-pool > (let* ((rect (ns:make-ns-rect 0 0 300 300)) > (w (make-instance 'ns:ns-window > :with-content-rect rect > :style-mask (logior #$NSTitledWindowMask > #$NSClosableWindowMask > #$NSMiniaturizableWindowMask > #$NSResizableWindowMask) > :backing #$NSBackingStoreBuffered > :defer t)) > (v (make-instance 'scribble-view))) > (#/setTitle: w #@"Scribble") > (#/setContentView: w v) > (#/center w) > (#/orderFront: w nil) > (print (slot-value v 'path)) > v))) > > (slot-value (make-scribble-window) 'path) > > and the result is a bogus ObjC object. RME says this is because: > > "You are initializing the path slot in your scribble-view instance > with an autoreleased NSBezierPath. The NSBezierPath instance will be > released on the next trip through the event loop." > > But I don't understand why this should be the case. The NSBezierPath > object was not allocated on the event loop thread, so why should it be > (auto)released there? Doesn't every thread (and hence every listener) > have its own autorelease pool? > > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From gb at clozure.com Tue Jun 2 14:15:29 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 2 Jun 2009 15:15:29 -0600 (MDT) Subject: [Openmcl-devel] Building trunk on Windows In-Reply-To: <8E5EC241-ADAD-4E34-883B-3B32EF3F7AAD@clozure.com> References: <8E5EC241-ADAD-4E34-883B-3B32EF3F7AAD@clozure.com> Message-ID: It's true that the kernel needs to be updated, but the reason for the error is that the lisp file that defines 'kernel-path' isn't getting compiled/loaded before another file that references it tries to do so. There can be any number of reasons for this, but the best solution is usually to have REBUILD-CCL delete all fasl files and force everything to be recompiled. ? (rebuild-ccl :clean t) ; on Windows or ? (rebuild-ccl :full t) ; on non-Windows systems will do that; the latter will also do a 'make clean; make' on the lisp kernel, but (since that would involve overwriting a running executable file) it doesn't work on Windows. Just ? (rebuild-ccl) will only recompile those source files whose corresponding fasl either doesn't exist or is older than the source. There are more things that can go wrong in that case (the fasl may have been compiled in a different session but not loaded into the current session, an svn client might think that it was doing you a favor by making your working copy have the same modified date it has on the server, etc.) that doing as full a rebuild as possible is strongly recommended. (I made the changes in question and do recognize that it's hard to setup a kernel build environment on Windows and usually/ often/sometimes check in Windows kernels when kernel sources change; sorry that I neglected to so so this time, but the error during recompile is a separate issue related to that set of changes.) On Tue, 2 Jun 2009, R. Matthew Emerson wrote: > > On Jun 2, 2009, at 11:20 AM, Raymond Wiker wrote: > >> c:\devel\ccl>wx86cl.exe >> Welcome to Clozure Common Lisp Version 1.3-dev-r11877M-trunk >> (WindowsX8632)! >> ? (rebuild-ccl) >> ;Compiling "c:/devel/ccl/lib/dumplisp.lisp"... >>> Error: Unknown kernel global : KERNEL-PATH . >>> While executing: X8632::%KERNEL-GLOBAL, in process listener(1). >>> Type :POP to abort, :R for a list of available restarts. >>> Type :? for other options. >> 1 > >> >> I'm guessing that the lisp kernel is too old to build current trunk... >> I'd rather avoid having to setup an environment for building the >> kernel, so would appreciate if some kind soul could upload a newer >> kernel. > > I checked updated lisp kernels for both 32- and 64-bit Windows into > the trunk. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From millejoh at mac.com Tue Jun 2 21:09:04 2009 From: millejoh at mac.com (John Miller) Date: Tue, 02 Jun 2009 23:09:04 -0500 Subject: [Openmcl-devel] Idiom for creating arrays of C structs Message-ID: <17A9F402-87E0-4A18-9F45-25523040ACB0@mac.com> Are there any conventions/best practices to follow when working with arrays of C structs that are passed back and forth from foreign code? Sorry if this has already been discussed in the past, but nothing jumped out at me while browsing through the group's archives. The code in the attached file seems to work on first appearance, creating an array of cpVect structures on a call to make-cpv-array. I can do something like (%get-ptr ptr-returned-from-make-cpv-array (* index size-of-cpv- struct)) and get a cpVect structure back. When I pass the MACPTR returned by make-cpv-array to foreign code, however, the block of memory apparently turns to mush. A copy of the C code I am calling with my make-cpv-array MACPTR is also in the attached file along with some interactions with the Listener. I guess that #ECT)) #x1EF61470> is not the same as a cpVect* verts, but I am at a loss to explain why and how to get the two to agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: struct-array.lisp Type: application/octet-stream Size: 2212 bytes Desc: not available URL: -------------- next part -------------- A little background: I am trying to write an FFI in CCL for the Chipmunk physics library. If any poor schmuck had actually downloaded the code that I prematurely uploaded to Google Code earlier they would have quickly found out that the demo with the square falling down the stairs doesn't work too realistically. I believe this issue with the passing around arrays of C structs to be the cause. Regards, John From rwiker at gmail.com Tue Jun 2 21:41:11 2009 From: rwiker at gmail.com (Raymond Wiker) Date: Wed, 3 Jun 2009 06:41:11 +0200 Subject: [Openmcl-devel] Building trunk on Windows In-Reply-To: References: <8E5EC241-ADAD-4E34-883B-3B32EF3F7AAD@clozure.com> Message-ID: On Jun 2, 2009, at 23:15 , Gary Byers wrote: > It's true that the kernel needs to be updated, but the reason for the > error is that the lisp file that defines 'kernel-path' isn't getting > compiled/loaded before another file that references it tries to do so. > There can be any number of reasons for this, but the best solution > is usually to have REBUILD-CCL delete all fasl files and force > everything > to be recompiled. > > ? (rebuild-ccl :clean t) ; on Windows I can confirm that (rebuild-ccl :clean t) worked in this case; thanks! Thanks also for uploading new kernels, and for making Clozure CL in the first place! Armed with CCL, it looks like I'll be able to turn my day job into a much more enjoyable experience :-) From neil.baylis at gmail.com Tue Jun 2 22:39:10 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Tue, 2 Jun 2009 22:39:10 -0700 Subject: [Openmcl-devel] tiny.lisp Message-ID: <1e6b7d810906022239u3e1d9f8ehe76a91b09f4a2653@mail.gmail.com> I'm trying to familiarize myself with the objective C bridge. I got the example "tiny.lisp" to run correctly, so I decided I'd alter it as an experiment. I immediately became lost. What I want to do is turn on the antialias mode for the window. I believe that to do this in Obj C, I would need to call - (void)setShouldAntialias:(BOOL)*antialias* which is an instance method of the class NSGraphicsContext. It's not clear to me how I would write that call in lisp. It's also not clear how I would obtain the graphics context from any of the objects present in tiny.lisp (probably the window or the view, but not sure). Any hints would be appreciated. Thanks, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at awun.net Tue Jun 2 23:35:59 2009 From: ron at awun.net (Ron Garret) Date: Tue, 2 Jun 2009 23:35:59 -0700 Subject: [Openmcl-devel] tiny.lisp In-Reply-To: <1e6b7d810906022239u3e1d9f8ehe76a91b09f4a2653@mail.gmail.com> References: <1e6b7d810906022239u3e1d9f8ehe76a91b09f4a2653@mail.gmail.com> Message-ID: I can't find tiny.lisp, but try: (#/setShouldAntialias: (#/currentContext ns:ns-graphics-context) #$YES) rg On Jun 2, 2009, at 10:39 PM, Neil Baylis wrote: > I'm trying to familiarize myself with the objective C bridge. I got > the example "tiny.lisp" to run correctly, so I decided I'd alter it > as an experiment. I immediately became lost. > > What I want to do is turn on the antialias mode for the window. > > I believe that to do this in Obj C, I would need to call > > - (void)setShouldAntialias:(BOOL)antialias > > which is an instance method of the class NSGraphicsContext. > > It's not clear to me how I would write that call in lisp. It's also > not clear how I would obtain the graphics context from any of the > objects present in tiny.lisp (probably the window or the view, but > not sure). > > Any hints would be appreciated. > > Thanks, > > Neil > _______________________________________________ > 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 ron at awun.net Tue Jun 2 23:41:30 2009 From: ron at awun.net (Ron Garret) Date: Tue, 2 Jun 2009 23:41:30 -0700 Subject: [Openmcl-devel] Scribble demo Message-ID: After much hair pulling and gnashing of teeth I finally got a bunch of basic demos working, including this one which implements a little scribble window. It's a useful example, I think, because it's very small, self-contained, and illustrates a lot of major UI concepts, including drawing and event handling. It's still rough, probably leaks a lot of memory, but it works. I can also happily report that although I became very intimate with the altConsole while working on this code, in the final analysis none of the problems I encountered turned out to be problems with CCL. It's not quite ready to unleash on newbies, but for semi-experienced coders I'd say CCL is ready for prime time. I'm probably switching from Python back to Lisp for my next project. Woohoo! rg -------------- next part -------------- A non-text attachment was scrubbed... Name: scribble.lisp Type: application/octet-stream Size: 2954 bytes Desc: not available URL: -------------- next part -------------- From gb at clozure.com Tue Jun 2 23:56:20 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 3 Jun 2009 00:56:20 -0600 (MDT) Subject: [Openmcl-devel] Idiom for creating arrays of C structs In-Reply-To: <17A9F402-87E0-4A18-9F45-25523040ACB0@mac.com> References: <17A9F402-87E0-4A18-9F45-25523040ACB0@mac.com> Message-ID: In C, a "vector of structs" is very different from "a vector of pointers to structs"; I'm pretty sure (from the parts of the code that I can see) that what we're dealing with here is "an array of cpv structs" rather than "an array of pointers to cpv structs." If P is a pointer to an array of cpv structs, then in order to access the I'th element of P by adding (* I ) to the address of P; the resulting pointer would be a pointer to the I'th struct. In CCL's FFI, that'd be: (%INC-PTR ptr-returned-from-make-cpv-array (* index size-of-cpv-struct)) And to access the value of the X component of the INDEX'th CPV struct, (pref (%INC-PTR ptr-returned-from-make-cpv-array (* index size-of-cpv-struct)) #>cpVect.x) ; or whatever. There's an internal, undocumented function named CCL::%COMPOSITE-POINTER-REF; it exists solely to allow SETF to work with some macros and allows things like "setting the I'th element of an array of structures to the value of another structure", which is pretty obscure. If you see calls to CCL::%COMPOSITE-POINTER-REF in some macroexpansions, they'd probably be best read as if they were %INC-PTR calls. There's a little bit of syntactic sugar (another thing that may be referenced in the old release notes in the doc directory but may not have made it into the manual) that can make this a little easier: (CCL:PAREF array-pointer array-foreign-type index) Hopefully, the other arguments are self-explanatory; somewhat strangely, PAREF expects the ARRAY-FOREIGN-TYPE argument to be the type of the array (a pointer to something), rather than the type of its elements. Given: ? (def-foreign-type nil (:struct example (x :double-float) (y :double-float))) NIL ? (ccl:macroexpand-all '(pref (paref p (:* (:struct :example)) 17) :example.x)) (%GET-DOUBLE-FLOAT (%COMPOSITE-POINTER-REF 16 P (/ (THE FIXNUM (* 128 (THE FIXNUM 17))) 8)) (/ 0 8)) which looks a lot scarier than it is. On Tue, 2 Jun 2009, John Miller wrote: > Are there any conventions/best practices to follow when working with arrays > of C structs that are passed back and forth from foreign code? Sorry if this > has already been discussed in the past, but nothing jumped out at me while > browsing through the group's archives. > > The code in the attached file seems to work on first appearance, creating an > array of cpVect structures on a call to make-cpv-array. I can do something > like > (%get-ptr ptr-returned-from-make-cpv-array (* index > size-of-cpv-struct)) > and get a cpVect structure back. When I pass the MACPTR returned by > make-cpv-array to foreign code, however, the block of memory apparently turns > to mush. A copy of the C code I am calling with my make-cpv-array MACPTR is > also in the attached file along with some interactions with the Listener. > > I guess that #ECT)) #x1EF61470> is not > the same as a cpVect* verts, but I am at a loss to explain why and how to get > the two to agree. > From raffaelcavallaro at mac.com Wed Jun 3 08:06:35 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 03 Jun 2009 11:06:35 -0400 Subject: [Openmcl-devel] Scribble demo In-Reply-To: References: Message-ID: On Jun 3, 2009, at 2:41 AM, Ron Garret wrote: > It's a useful example, I think, because it's very small, self- > contained, and illustrates a lot of major UI concepts, including > drawing and event handling. It's still rough, probably leaks a lot > of memory, but it works. One small comment; you may want to use makeKeyAndOrderFront: rather than orderFront: or your window will be on top, but not have focus (the title bar will be grayed, user will have to click on it to give it focus). Thanks for sharing this. warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From raffaelcavallaro at mac.com Wed Jun 3 08:26:30 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 03 Jun 2009 11:26:30 -0400 Subject: [Openmcl-devel] Scribble demo In-Reply-To: References: Message-ID: <7788F005-2457-4234-8F0F-ED5D8652C3D9@mac.com> On Jun 3, 2009, at 2:41 AM, Ron Garret wrote: > It's still rough, probably leaks a lot of memory, but it works. Your biggest memory leak is probably: (#/setReleasedWhenClosed: nsw nil) If you comment this out each new scribble-window will not leak memory since the default for NSWindow is releasedWhenClosed. Both in testing and looking at your event handling code, there is nothing that the Cocoa event handling system will call on your window once it gets a performClose (i.e., you don't have some other thread or input that is sending messages to your window which needs to be notified to stop doing so in a delegate's windowShouldClose: method). I've removed it and created and closed several hundred scribble-windows without leaking memory. If you keep it as is, you leak about 350k per scribble window (at least according to Activity Monitor's RSIZE figure). warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From raffaelcavallaro at mac.com Wed Jun 3 10:02:56 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 03 Jun 2009 13:02:56 -0400 Subject: [Openmcl-devel] Scribble demo In-Reply-To: References: Message-ID: <311B956D-5BBF-496D-86DE-697F7AC26C66@mac.com> On Jun 3, 2009, at 2:41 AM, Ron Garret wrote: > It's a useful example, I think, because it's very small, self- > contained, and illustrates a lot of major UI concepts, including > drawing and event handling. a few more minor notes: - use : for objective-c BOOL rather than :boolean and you'll avoid the warning about introducing the ambiguity wrt existing acceptsFirstResponder methods. - (declare (ignore for a couple of unused formal parameters. - a test method for memory leaks: (defun scribble-window-memory-test (n) (dotimes (x n) (let* ((w (gui::execute-in-gui (lambda () (make-scribble-window))))) (sleep (/ internal-time-units-per-second)) (gui::execute-in-gui (lambda () (#/close w)))))) with all these and previously suggested changes attached below. warmest regards, Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: scribble.lisp Type: application/octet-stream Size: 3297 bytes Desc: not available URL: -------------- next part -------------- Raffael Cavallaro raffaelcavallaro at me.com From j-anthony at comcast.net Wed Jun 3 11:26:41 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Wed, 03 Jun 2009 14:26:41 -0400 Subject: [Openmcl-devel] Timers... Message-ID: <1244053601.2420.131.camel@sirius> Hi, I'm porting a system to CCL and one bit I've come up to is a with-timer capability. Is something like this pretty much the "right" way to achieve this in CCL? I know about Dan Corkill's variant (in "portable-threads"), but this seems a bit better. Yes? No? #+ccl (defun interrupt-timer (interruptable-process semaphore duration func) (let ((work-done (ccl:timed-wait-on-semaphore semaphore duration))) (when (not work-done) (ccl:process-interrupt interruptable-process func)))) #+ccl (defmacro with-timer ((seconds-available &body timeout-forms) &body body) (with-gensyms (semaphore tag) `(let* ((,semaphore (ccl:make-semaphore)) (,tag (gensym))) (ccl:process-run-function "timer-proc" #'interrupt-timer ccl:*current-process* ,semaphore ,seconds-available #'(lambda () (throw ,tag (progn , at timeout-forms)))) (catch ,tag (unwind-protect (progn , at body) (ccl:signal-semaphore ,semaphore))) ))) From neil.baylis at gmail.com Wed Jun 3 12:47:16 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Wed, 3 Jun 2009 12:47:16 -0700 Subject: [Openmcl-devel] Scribble demo In-Reply-To: <311B956D-5BBF-496D-86DE-697F7AC26C66@mac.com> References: <311B956D-5BBF-496D-86DE-697F7AC26C66@mac.com> Message-ID: <1e6b7d810906031247g32d9492ajc6f2dc127f98afd4@mail.gmail.com> This is a very useful demo. Thanks Ron for making it available, and Ralph for cleaning it up. I hope it makes its way into the ccl examples. For newcomers, I think what works best is a number of small examples like this, rather than large examples that include too much, a problem I have with much of Apple's sample code. So, thanks guys. I think this is a CL question more than specifically CCL, but I'll ask here anyway: When I run the scribble demo from within Emacs/Slime, it works OK if I (load "scribble.lisp") at the slime REPL. But if I use C-c C-k, a.k.a. "compile and load file" it complains that there's no package named "GUI". I imagine this is because the meaning of (require :cocoa) is different when compiling vs loading. If I do (require :cocoa) before I do C-c C-k then it works OK. There's probably no bug here, I just don't understand exactly what's happening. Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From stassats at gmail.com Wed Jun 3 12:56:04 2009 From: stassats at gmail.com (Stas Boukarev) Date: Wed, 03 Jun 2009 23:56:04 +0400 Subject: [Openmcl-devel] Scribble demo In-Reply-To: <1e6b7d810906031247g32d9492ajc6f2dc127f98afd4@mail.gmail.com> (Neil Baylis's message of "Wed, 3 Jun 2009 12:47:16 -0700") References: <311B956D-5BBF-496D-86DE-697F7AC26C66@mac.com> <1e6b7d810906031247g32d9492ajc6f2dc127f98afd4@mail.gmail.com> Message-ID: <87y6s9ccrv.fsf@gmail.com> Neil Baylis writes: > I think this is a CL question more than specifically CCL, but I'll ask here anyway: When I run the scribble demo from within Emacs/Slime, > it works OK if I (load "scribble.lisp") at the slime REPL. But if I use C-c C-k, a.k.a. "compile and load file" it complains that there's > no package named "GUI". I imagine this is because the meaning of? (require :cocoa) is different when compiling vs loading. If I do > (require :cocoa) before I do C-c C-k then it works OK. There's probably no bug here, I just don't understand exactly what's happening. Symbols are read before compilation, and packages should exist before they are read. One way to do it is by putting #.(require :module) in the file. Load executes each form sequentially, so (require :module) is executed before other forms are read. -- With best regards, Stas. From taoufik.dachraoui at wanadoo.fr Wed Jun 3 13:34:41 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Wed, 3 Jun 2009 22:34:41 +0200 Subject: [Openmcl-devel] a function to create a symbol in a given package Message-ID: Hi I tried but could not find a way to create a function that creates a symbol in a given package. I woud appreciate if someone can helpp me write the following function: (defun crate-symbol-in-package (symbol value package) .....) example of use: ? *package* COMMON-LISP-USER ? (create-symbol-in-package 'client 'me 'world) WORLD:CLIENT ? world::client 'ME Kind regards -Taoufik From rpgoldman at sift.info Wed Jun 3 13:56:45 2009 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 03 Jun 2009 15:56:45 -0500 Subject: [Openmcl-devel] a function to create a symbol in a given package In-Reply-To: References: Message-ID: <4A26E38D.7020602@sift.info> Taoufik Dachraoui wrote: > Hi > > I tried but could not find a way to create a function that creates a > symbol in a given package. > > I woud appreciate if someone can helpp me write the following function: > > (defun crate-symbol-in-package (symbol value package) > .....) > > example of use: > > ? *package* > COMMON-LISP-USER > ? (create-symbol-in-package 'client 'me 'world) > WORLD:CLIENT > ? world::client > 'ME > > How about (intern "CLIENT" :world) (setf world::client 'me) or, for that matter (defvar world::client 'me) what is it that you are trying to achieve here? This create-symbol-in-package is so deeply unidiomatic, that I suspect if we looked at what you are trying to do in context, we will find that it can be achieved more easily in other ways. For what purpose do you believe you need this function? From taoufik.dachraoui at wanadoo.fr Wed Jun 3 14:12:03 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Wed, 3 Jun 2009 23:12:03 +0200 Subject: [Openmcl-devel] a function to create a symbol in a given package In-Reply-To: <4A26E38D.7020602@sift.info> References: <4A26E38D.7020602@sift.info> Message-ID: On Jun 3, 2009, at 10:56 PM, Robert Goldman wrote: > > Taoufik Dachraoui wrote: >> Hi >> >> I tried but could not find a way to create a function that creates a >> symbol in a given package. >> >> I woud appreciate if someone can helpp me write the following >> function: >> >> (defun crate-symbol-in-package (symbol value package) >> .....) >> >> example of use: >> >> ? *package* >> COMMON-LISP-USER >> ? (create-symbol-in-package 'client 'me 'world) >> WORLD:CLIENT >> ? world::client >> 'ME >> >> > > How about > > (intern "CLIENT" :world) > (setf world::client 'me) > > or, for that matter > > (defvar world::client 'me) > > what is it that you are trying to achieve here? This > create-symbol-in-package is so deeply unidiomatic, that I suspect if > we > looked at what you are trying to do in context, we will find that it > can > be achieved more easily in other ways. > > For what purpose do you believe you need this function? > I am writing a lisp server that accepts connections from clients; each client will be assigned a new package at connection. Each client package will inherit, depending on the client profile, symbols from other pre-existing packages (applications). The client will be able to send lisp commands to the server, and the server will execute the commands in the client's package (after checking that the commands are valid and do not access any data outside its assigned package). At client connection, the server need to save some data related to the client in the clients package. The pre-existing functions will be using these data defined by the server on connection. I am not sure I am using the right strategy, but I am trying my first ideas, and I hope I will gain more insights on the whole application to allow me to make better choices to implement this whole thing. Kind regards -Taoufik From gwking at metabang.com Wed Jun 3 14:40:31 2009 From: gwking at metabang.com (Gary King) Date: Wed, 3 Jun 2009 17:40:31 -0400 Subject: [Openmcl-devel] a function to create a symbol in a given package In-Reply-To: <4A26E38D.7020602@sift.info> References: <4A26E38D.7020602@sift.info> Message-ID: Hiya. Isn't #'intern the fuunction you want? You could also consider (serf symbol-value (intern )) ). -- Earth First (we'll take care of the other planets later) On Jun 3, 2009, at 4:56 PM, Robert Goldman wrote: > Taoufik Dachraoui wrote: >> Hi >> >> I tried but could not find a way to create a function that creates a >> symbol in a given package. >> >> I woud appreciate if someone can helpp me write the following >> function: >> >> (defun crate-symbol-in-package (symbol value package) >> .....) >> >> example of use: >> >> ? *package* >> COMMON-LISP-USER >> ? (create-symbol-in-package 'client 'me 'world) >> WORLD:CLIENT >> ? world::client >> 'ME >> >> > > How about > > (intern "CLIENT" :world) > (setf world::client 'me) > > or, for that matter > > (defvar world::client 'me) > > what is it that you are trying to achieve here? This > create-symbol-in-package is so deeply unidiomatic, that I suspect if > we > looked at what you are trying to do in context, we will find that it > can > be achieved more easily in other ways. > > For what purpose do you believe you need this function? > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Wed Jun 3 14:43:54 2009 From: ron at awun.net (Ron Garret) Date: Wed, 3 Jun 2009 14:43:54 -0700 Subject: [Openmcl-devel] Another demo: scalable image view Message-ID: <8E6B32DC-39CE-41A1-A90E-EB8C47F49456@awun.net> Since the scribble demo was so well received I'm sending out another one that I found kind of handy to refer back to. This one displays images that dynamically resize themselves with the containing window. This demo is not standalone, it relies fairly heavily on some of my private utilities, and in particular one called BB (for Binding Block), which in turn relies on a bunch of other stuff. The utilities file has a lot of old cruft in it. (I've been maintaining this file for my own personal use for over twenty years!) I tried to pull out a smaller subset of it to support this demo, but the dependency graph turned out to be pretty tangled and I decided it was more trouble than it was worth. One of these days I'll have my non-filesystem-based source control system up and running and this sort of thing will be handled automatically but for now if you want to use this demo you'll have to put up with my legacy code, or convert it to vanilla CL yourself. There is one bug in this code: sometimes the image does not appear right away and you have to resize the window to get it to show up. This is probably due to a missing call to performSelectorOnMainThread somewhere, but I can't figure out where at the moment. Feedback welcome. rg -------------- next part -------------- A non-text attachment was scrubbed... Name: image-view.lisp Type: application/octet-stream Size: 4820 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: utilities.lisp Type: application/octet-stream Size: 24436 bytes Desc: not available URL: From ron at awun.net Wed Jun 3 23:48:37 2009 From: ron at awun.net (Ron Garret) Date: Wed, 3 Jun 2009 23:48:37 -0700 Subject: [Openmcl-devel] CCL totally rocks! Message-ID: I just had one of those hacking moments that made all the frustration worthwhile. Rather than try to describe it, I'll just show you. Load the scribble demo, then do this: (objc:load-framework "Quartz" :quartz) (defun pdf-from-url (url) (make-instance ns:pdf-document :init-with-url (make-instance ns:ns-url :init-with-string url))) (setf pdf (pdf-from-url #@"http://www.flownet.com/ron/specials.pdf")) (setf pv (#/init (#/alloc ns:pdf-view))) (#/setDocument: pv pdf) (setf pw (make-ns-window 640 800 "PDF")) (#/setContentView: pw pv) ; This is the cool part: (setf cv (#/objectAtIndex: (#/subviews (#/objectAtIndex: (#/subviews pv) 0)) 0)) (#/addSubview: cv (make-instance 'scribble-view :init-with-frame (#/bounds (#/objectAtIndex: (#/ subviews cv) 0)))) Now scribble. Then scroll. (Note that you have to use 32-bit CCL to do this because there's a fatal bug in the 64-bit version of the Cocoa PDFView class.) rg From gb at clozure.com Thu Jun 4 00:49:14 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 4 Jun 2009 01:49:14 -0600 (MDT) Subject: [Openmcl-devel] Timers... In-Reply-To: <1244053601.2420.131.camel@sirius> References: <1244053601.2420.131.camel@sirius> Message-ID: This seems generally reasonable. There's always a chance that the semaphore would have been seen to b signaled if only the timeout had been slightly longer, so the target thread might complete its work, signal the semaphore, and then get an interrupt. Depending on the application, that may or may not be significant. On Wed, 3 Jun 2009, Jon S. Anthony wrote: > Hi, > > I'm porting a system to CCL and one bit I've come up to is a with-timer > capability. Is something like this pretty much the "right" way to > achieve this in CCL? I know about Dan Corkill's variant (in > "portable-threads"), but this seems a bit better. Yes? No? > > > #+ccl > (defun interrupt-timer (interruptable-process semaphore duration func) > (let ((work-done (ccl:timed-wait-on-semaphore semaphore duration))) > (when (not work-done) > (ccl:process-interrupt > interruptable-process > func)))) > > #+ccl > (defmacro with-timer ((seconds-available &body timeout-forms) &body > body) > (with-gensyms (semaphore tag) > `(let* ((,semaphore (ccl:make-semaphore)) > (,tag (gensym))) > (ccl:process-run-function > "timer-proc" > #'interrupt-timer > ccl:*current-process* > ,semaphore ,seconds-available > #'(lambda () (throw ,tag (progn , at timeout-forms)))) > (catch ,tag > (unwind-protect > (progn , at body) > (ccl:signal-semaphore ,semaphore))) ))) > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From p2.edoc at googlemail.com Thu Jun 4 01:35:05 2009 From: p2.edoc at googlemail.com (peter) Date: Thu, 4 Jun 2009 09:35:05 +0100 Subject: [Openmcl-devel] Scribble demo - handling missing definitions In-Reply-To: <311B956D-5BBF-496D-86DE-697F7AC26C66@mac.com> References: <311B956D-5BBF-496D-86DE-697F7AC26C66@mac.com> Message-ID: {context: 1.3-r12190M (DarwinPPC32) under 10.4.11 from Clozure CL-ppc32 boot} {and as no one else has commented, I'm beginning to wonder if I'm the only person leapfrogging from 10.4 to 10.6} (make-scribble-window) > Error: Objective-C runtime exception: > *** -[ScribbleView setAlphaValue:]: selector not recognized >[self = 0x3cc540] AppKiDo shows: "Applies windowAlpha to the entire window." "[...] Sending this message to a view that is not managing a Core Animation layer causes an exception. Available in Mac OS X v10.5 and later." So I imagine that perhaps setAlphaValue was applicable to the whole window pre-10.5, and from 10.5 on views (maybe Apple's developer documentation is a tad ambiguous). (defun make-scribble-window () (let ((w (make-ns-window 300 300 "Scribble")) (v (make-instance 'scribble-view))) (#/setAlphaValue: w 0.5) ;<= w (#/setContentView: w v) w)) works (as in no errors making window) though drawing (click/drag) in window only produces in AltConsole: > Error: # > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). But my point here is that the function seems to be known but also unknown (a Donald Rumsfeld moment): (describe (symbol-function 'nextstep-functions:|setAlphaValue:|)) # Class: # Wrapper: # Instance slots CCL::NAME: NEXTSTEP-FUNCTIONS:|setAlphaValue:| (arglist 'nextstep-functions:|setAlphaValue:|) (CCL::ARG-0 CCL::ARG-1) :ANALYSIS But [Tools] [Apropos...] setAlphaValue double-click the function: beachball hang or *** Error in event process: Failed assertion: (AND HI::*CURRENT-VIEW* (FIND-RESTART 'HI::EXIT-EVENT-HANDLER)) (BFFFDF80) : 0 (FUNCALL #'#<(:INTERNAL GUI::|-[AproposWindowController definitionForSelectedSymbol:]|)> #) 112 (#:G8268) #:G8268: # #:COMPILER-VAR: (NIL) #:G8265: # (BFFFDF90) : 1 (SIGNAL #) 528 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (CONDITION #) (ERROR)) CCL::TAG: (CONDITION #) CCL::HANDLERS: (CONDITION #) (BFFFDFA0) : 2 (%ERROR # NIL -268437512) 84 (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: NIL CCL::ERROR-POINTER: -268437512 (BFFFDFC0) : 4 (CERROR "test the assertion again." #) 496 (CCL::CONT-STRING CONDITION &REST CCL::ARGS) CCL::CONT-STRING: "test the assertion again." CONDITION: # CCL::ARGS: NIL CCL::FP: -268437512 #:G34821: # #:G34818: (#) CCL::%RESTARTS%: ((#<# # #xED5FE>)) #:G34819: # CCL::*CONDITION-RESTARTS*: ((#<# # #xED5FE> . #)) (BFFFDFE0) : 5 (%ASSERTION-FAILURE NIL (AND HI::*CURRENT-VIEW* (FIND-RESTART #)) NIL) 424 (CCL::SETF-PLACES-P CCL::TEST-FORM STRING &REST CCL::CONDITION-ARGS) CCL::SETF-PLACES-P: NIL CCL::TEST-FORM: (AND HI::*CURRENT-VIEW* (FIND-RESTART #)) STRING: NIL CCL::CONDITION-ARGS: NIL (BFFFDFF0) : 6 (ABORT-CURRENT-COMMAND "No known definitions for NEXTSTEP-FUNCTIONS:|setAlphaValue:|") 144 (&OPTIONAL HEMLOCK-INTERFACE:MESSAGE) HEMLOCK-INTERFACE:MESSAGE: "No known definitions for NEXTSTEP-FUNCTIONS:|setAlphaValue:|" (BFFFE000) : 7 (FUNCALL #'# -268437422) 732 (#:G8264) #:G8264: -268437422 #:G8271: # #:G8265: # #:COMPILER-VAR: (NIL) #:G8270: # #:G8272: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (CONDITION #) (ERROR)) GUI::SELF: # (#x189A200)> GUI::_CMD: # GUI::SENDER: # (#x3EDCD0)> GUI::ROW: 0 NUMBER: # GUI::I: 0 GUI::SYM: NEXTSTEP-FUNCTIONS:|setAlphaValue:| (BFFFE030) : 9 (%PASCAL-FUNCTIONS% 205 -268437422) 228 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 205 CCL::ARGS-PTR-FIXNUM: -268437422 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (BFFFF2F0) : 11 (FUNCALL #'# # # #) 288 (#:G1971 #:G1972 CCL::ARG0) #:G1971: # #:G1972: # CCL::ARG0: # (BFFFF310) : 13 (%CALL-NEXT-OBJC-METHOD # (#x1815600)> # # (:VOID :ID) #) 696 (CCL::SELF CLASS CCL::SELECTOR CCL::SIG &REST CCL::ARGS) CCL::SELF: # (#x1815600)> 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: # #:G1052: # #:G1053: -268436280 (BFFFF390) : 14 (FUNCALL #'# -268436170) 648 (#:G2182) #:G2182: -268436170 #:G2189: # #:G2183: # #:COMPILER-VAR: (NIL) #:G2188: # #:G2190: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) GUI::SELF: # (#x1815600)> GUI::_CMD: # GUI::E: # CCL::ARGS: (#) (BFFFF3C0) : 16 (%PASCAL-FUNCTIONS% 15 -268436170) 228 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 15 CCL::ARGS-PTR-FIXNUM: -268436170 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (BFFFFA10) : 18 (FUNCALL #'# # (#x1815600)> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #)) 132 (#:G1254 #:G1255) #:G1254: # (#x1815600)> #:G1255: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) From raffaelcavallaro at mac.com Thu Jun 4 03:45:44 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Thu, 04 Jun 2009 06:45:44 -0400 Subject: [Openmcl-devel] CCL totally rocks! In-Reply-To: References: Message-ID: <2AE98759-9155-4395-A686-75163CFDB1C3@mac.com> On Jun 4, 2009, at 2:48 AM, Ron Garret wrote: > Now scribble. Then scroll. Cool! warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From millejoh at mac.com Thu Jun 4 06:34:19 2009 From: millejoh at mac.com (John Miller) Date: Thu, 04 Jun 2009 08:34:19 -0500 Subject: [Openmcl-devel] Idiom for creating arrays of C structs In-Reply-To: References: <17A9F402-87E0-4A18-9F45-25523040ACB0@mac.com> Message-ID: Gary, Thank you! Everything works quite nicely now. If my brain hadn't filled up after reading the first few paragraphs of your explanation I am quite sure I would have learned a number of very interesting things. Warmest regards, John On Jun 3, 2009, at 1:56 AM, Gary Byers wrote: > In C, a "vector of structs" is very different from "a vector of > pointers > to structs"; I'm pretty sure (from the parts of the code that I can > see) > that what we're dealing with here is "an array of cpv structs" rather > than "an array of pointers to cpv structs." > > If P is a pointer to an array of cpv structs, then in order to access > the I'th element of P by adding (* I ) to the > address > of P; the resulting pointer would be a pointer to the I'th struct. > In CCL's FFI, that'd be: > > (%INC-PTR ptr-returned-from-make-cpv-array (* index size-of-cpv- > struct)) > > And to access the value of the X component of the INDEX'th CPV struct, > > (pref (%INC-PTR ptr-returned-from-make-cpv-array (* index size-of- > cpv-struct)) > #>cpVect.x) ; or whatever. > > There's an internal, undocumented function named CCL::%COMPOSITE- > POINTER-REF; > it exists solely to allow SETF to work with some macros and allows > things > like "setting the I'th element of an array of structures to the > value of > another structure", which is pretty obscure. If you see calls to > CCL::%COMPOSITE-POINTER-REF in some macroexpansions, they'd probably > be > best read as if they were %INC-PTR calls. > > There's a little bit of syntactic sugar (another thing that may be > referenced > in the old release notes in the doc directory but may not have made > it into > the manual) that can make this a little easier: > > (CCL:PAREF array-pointer array-foreign-type index) > > Hopefully, the other arguments are self-explanatory; somewhat > strangely, PAREF > expects the ARRAY-FOREIGN-TYPE argument to be the type of the array > (a pointer > to something), rather than the type of its elements. > > > Given: > > ? (def-foreign-type nil > (:struct example > (x :double-float) > (y :double-float))) > NIL > ? (ccl:macroexpand-all '(pref (paref p (:* (:struct :example)) > 17) :example.x)) > (%GET-DOUBLE-FLOAT (%COMPOSITE-POINTER-REF 16 P (/ (THE FIXNUM (* > 128 (THE FIXNUM 17))) 8)) (/ 0 8)) > > which looks a lot scarier than it is. > > > On Tue, 2 Jun 2009, John Miller wrote: > >> Are there any conventions/best practices to follow when working >> with arrays of C structs that are passed back and forth from >> foreign code? Sorry if this has already been discussed in the >> past, but nothing jumped out at me while browsing through the >> group's archives. >> >> The code in the attached file seems to work on first appearance, >> creating an array of cpVect structures on a call to make-cpv- >> array. I can do something like >> (%get-ptr ptr-returned-from-make-cpv-array (* index size-of-cpv- >> struct)) >> and get a cpVect structure back. When I pass the MACPTR returned >> by make-cpv-array to foreign code, however, the block of memory >> apparently turns to mush. A copy of the C code I am calling with >> my make-cpv-array MACPTR is also in the attached file along with >> some interactions with the Listener. >> >> I guess that #ECT)) >> #x1EF61470> is not the same as a cpVect* verts, but I am at a loss >> to explain why and how to get the two to agree. >> From ralex at cs.colorado.edu Thu Jun 4 06:40:25 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Thu, 4 Jun 2009 07:40:25 -0600 Subject: [Openmcl-devel] Scribble demo In-Reply-To: References: Message-ID: perhaps this is a version problem but my scribble window does not do anything: in listener: Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinPPC32)! ;Compiler warnings : ; In LABEL inside an anonymous lambda form: Unused lexical variable V ;Compiler warnings : ; In (VIEW-DRAW-CONTENTS (SCRIBBLE-VIEW)) inside an anonymous lambda form: Unused lexical variable RECT ; Warning: previously declared methods on #1="acceptsFirstResponder" all had the same type signature, but # introduces ambiguity ; While executing: CCL::%DECLARE-OBJC-METHOD, in process Listener(6). then when clicking in AltConsole: > Error: # > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). > Error: # > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). > Error: # > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). > Error: # > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). etc. Alex On Jun 3, 2009, at 12:41 AM, Ron Garret wrote: > After much hair pulling and gnashing of teeth I finally got a bunch > of basic demos working, including this one which implements a little > scribble window. It's a useful example, I think, because it's very > small, self-contained, and illustrates a lot of major UI concepts, > including drawing and event handling. It's still rough, probably > leaks a lot of memory, but it works. > > I can also happily report that although I became very intimate with > the altConsole while working on this code, in the final analysis > none of the problems I encountered turned out to be problems with > CCL. It's not quite ready to unleash on newbies, but for semi- > experienced coders I'd say CCL is ready for prime time. I'm > probably switching from Python back to Lisp for my next project. > Woohoo! > > rg > > > _______________________________________________ > 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 j-anthony at comcast.net Thu Jun 4 07:50:28 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Thu, 04 Jun 2009 10:50:28 -0400 Subject: [Openmcl-devel] Timers... In-Reply-To: References: <1244053601.2420.131.camel@sirius> Message-ID: <1244127028.2420.151.camel@sirius> Hi Gary, Thanks for the information. On another note, mostly just curious, is there any particular reason why CCL doesn't just supply an asynchronous transfer of control timer construct? It would seem that whatever machinery is used for the timed semaphore would be a natural for this. OK, I suppose I can just look this up in the code to see for myself... /Jon On Thu, 2009-06-04 at 01:49 -0600, Gary Byers wrote: > This seems generally reasonable. There's always a chance that the > semaphore would have been seen to b signaled if only the timeout had > been slightly longer, so the target thread might complete its work, > signal the semaphore, and then get an interrupt. Depending on the > application, that may or may not be significant. > > On Wed, 3 Jun 2009, Jon S. Anthony wrote: > > > Hi, > > > > I'm porting a system to CCL and one bit I've come up to is a with-timer > > capability. Is something like this pretty much the "right" way to > > achieve this in CCL? I know about Dan Corkill's variant (in > > "portable-threads"), but this seems a bit better. Yes? No? > > > > > > #+ccl > > (defun interrupt-timer (interruptable-process semaphore duration func) > > (let ((work-done (ccl:timed-wait-on-semaphore semaphore duration))) > > (when (not work-done) > > (ccl:process-interrupt > > interruptable-process > > func)))) > > > > #+ccl > > (defmacro with-timer ((seconds-available &body timeout-forms) &body > > body) > > (with-gensyms (semaphore tag) > > `(let* ((,semaphore (ccl:make-semaphore)) > > (,tag (gensym))) > > (ccl:process-run-function > > "timer-proc" > > #'interrupt-timer > > ccl:*current-process* > > ,semaphore ,seconds-available > > #'(lambda () (throw ,tag (progn , at timeout-forms)))) > > (catch ,tag > > (unwind-protect > > (progn , at body) > > (ccl:signal-semaphore ,semaphore))) ))) > > > > > > _______________________________________________ > > Openmcl-devel mailing list > > Openmcl-devel at clozure.com > > http://clozure.com/mailman/listinfo/openmcl-devel > > > > From ron at awun.net Thu Jun 4 07:38:58 2009 From: ron at awun.net (Ron Garret) Date: Thu, 4 Jun 2009 07:38:58 -0700 Subject: [Openmcl-devel] Scribble demo - handling missing definitions In-Reply-To: References: <311B956D-5BBF-496D-86DE-697F7AC26C66@mac.com> Message-ID: <6AC58AF7-06B3-42C0-ABC1-CF2AA6096EBD@awun.net> On Jun 4, 2009, at 1:35 AM, peter wrote: > {context: 1.3-r12190M (DarwinPPC32) under 10.4.11 from Clozure CL- > ppc32 boot} > {and as no one else has commented, I'm beginning to wonder if I'm the > only person leapfrogging from 10.4 to 10.6} > > (make-scribble-window) >> Error: Objective-C runtime exception: >> *** -[ScribbleView setAlphaValue:]: selector not recognized >> [self = 0x3cc540] That line shouldn't really be there at all. It's a leftover from an earlier failed experiment to make a scribble view that can be layered over other views. It turns out that setting an alpha value is not necessary, so you should just remove the call to setAlphaValue. rg From ron at awun.net Thu Jun 4 08:03:47 2009 From: ron at awun.net (Ron Garret) Date: Thu, 4 Jun 2009 08:03:47 -0700 Subject: [Openmcl-devel] Scribble demo In-Reply-To: References: Message-ID: <0C32832E-A977-4F13-8177-857843A85900@awun.net> Very weird. I can't reproduce this at all, but I've got 1.3-r12190M. You might want to try an svn update and rebuild, and also using Ralph's cleaned up version. rg On Jun 4, 2009, at 6:40 AM, Alexander Repenning wrote: > perhaps this is a version problem but my scribble window does not do > anything: > > in listener: > > Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinPPC32)! > > ;Compiler warnings : > ; In LABEL inside an anonymous lambda form: Unused lexical > variable V > ;Compiler warnings : > ; In (VIEW-DRAW-CONTENTS (SCRIBBLE-VIEW)) inside an anonymous > lambda form: Unused lexical variable RECT > ; Warning: previously declared methods on #1="acceptsFirstResponder" > all had the same type signature, but # [ScribbleView #1#] #x897DE96> introduces ambiguity > ; While executing: CCL::%DECLARE-OBJC-METHOD, in process Listener(6). > > > then when clicking in AltConsole: > > > Error: # > > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). > > Error: # > > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). > > Error: # > > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). > > Error: # > > While executing: CCL::CHECK-NS-EXCEPTION, in process Initial(0). > > etc. > > > Alex > > > On Jun 3, 2009, at 12:41 AM, Ron Garret wrote: > >> After much hair pulling and gnashing of teeth I finally got a bunch >> of basic demos working, including this one which implements a >> little scribble window. It's a useful example, I think, because >> it's very small, self-contained, and illustrates a lot of major UI >> concepts, including drawing and event handling. It's still rough, >> probably leaks a lot of memory, but it works. >> >> I can also happily report that although I became very intimate with >> the altConsole while working on this code, in the final analysis >> none of the problems I encountered turned out to be problems with >> CCL. It's not quite ready to unleash on newbies, but for semi- >> experienced coders I'd say CCL is ready for prime time. I'm >> probably switching from Python back to Lisp for my next project. >> Woohoo! >> >> rg >> >> >> _______________________________________________ >> 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 neil.baylis at gmail.com Thu Jun 4 10:49:08 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Thu, 4 Jun 2009 10:49:08 -0700 Subject: [Openmcl-devel] Scribble demo In-Reply-To: <0C32832E-A977-4F13-8177-857843A85900@awun.net> References: <0C32832E-A977-4F13-8177-857843A85900@awun.net> Message-ID: <1e6b7d810906041049mf36fcc5t8bad781b1e7c628d@mail.gmail.com> Maybe this is just a stylistic thing, or maybe something else I don't understand. In the scribble demo, there's a function "label' that just draws the label box inside the window. Why is it defined like this: (let* ((path (make-instance ns:ns-bezier-path))) (#/moveToPoint: path (ns:make-ns-point 10 10)) (#/lineToPoint: path (ns:make-ns-point 10 40)) (#/lineToPoint: path (ns:make-ns-point 90 40)) (#/lineToPoint: path (ns:make-ns-point 90 10)) (#/lineToPoint: path (ns:make-ns-point 10 10)) (defun label (v) (#/drawAtPoint:withAttributes: #@"Scribble" (ns:make-ns-point 15 15) +null-ptr+) (#/stroke path))) Instead of like this: (defun label (v) (let* ((path (make-instance ns:ns-bezier-path))) (#/moveToPoint: path (ns:make-ns-point 10 10)) (#/lineToPoint: path (ns:make-ns-point 10 40)) (#/lineToPoint: path (ns:make-ns-point 90 40)) (#/lineToPoint: path (ns:make-ns-point 90 10)) (#/lineToPoint: path (ns:make-ns-point 10 10)) (#/fill path) (#/drawAtPoint:withAttributes: #@"Scribble" (ns:make-ns-point 15 15) +null-ptr+) (#/stroke path))) Does putting the defun inside the let do something different than putting the let inside the defun? Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaelcavallaro at mac.com Thu Jun 4 11:12:01 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Thu, 04 Jun 2009 14:12:01 -0400 Subject: [Openmcl-devel] Scribble demo In-Reply-To: <1e6b7d810906041049mf36fcc5t8bad781b1e7c628d@mail.gmail.com> References: <0C32832E-A977-4F13-8177-857843A85900@awun.net> <1e6b7d810906041049mf36fcc5t8bad781b1e7c628d@mail.gmail.com> Message-ID: On Jun 4, 2009, at 1:49 PM, Neil Baylis wrote: > Does putting the defun inside the let do something different than > putting the let inside the defun? If the let is inside the defun you generate a new temporary NSBezierPath each time you call label. If you wrap the defun in the let, every call to label uses the same identical NSBezierPath to draw the label: ? (let ((a (list 1 2))) (defun foo () a)) FOO ? (foo) (1 2) ? (eq (foo) (foo)) T ? (defun bar () (let ((a (list 1 2))) a)) BAR ? (bar) (1 2) ? (eq (bar) (bar)) NIL ? warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From ron at awun.net Thu Jun 4 11:17:06 2009 From: ron at awun.net (Ron Garret) Date: Thu, 4 Jun 2009 11:17:06 -0700 Subject: [Openmcl-devel] Scribble demo In-Reply-To: <1e6b7d810906041049mf36fcc5t8bad781b1e7c628d@mail.gmail.com> References: <0C32832E-A977-4F13-8177-857843A85900@awun.net> <1e6b7d810906041049mf36fcc5t8bad781b1e7c628d@mail.gmail.com> Message-ID: Yes. Try this: (defun foo () (print "Calling foo") 1) (let ((x (foo))) (defun baz1 () x)) (defun baz2 () (let ((x (foo))) x)) Then compare what happens when you call BAZ1 and BAZ2. And if you want to take a deep dive, read: http://www.flownet.com/ron/specials.pdf rg On Jun 4, 2009, at 10:49 AM, Neil Baylis wrote: > Maybe this is just a stylistic thing, or maybe something else I > don't understand. In the scribble demo, there's a function "label' > that just draws the label box inside the window. > > Why is it defined like this: > > (let* ((path (make-instance ns:ns-bezier-path))) > (#/moveToPoint: path (ns:make-ns-point 10 10)) > (#/lineToPoint: path (ns:make-ns-point 10 40)) > (#/lineToPoint: path (ns:make-ns-point 90 40)) > (#/lineToPoint: path (ns:make-ns-point 90 10)) > (#/lineToPoint: path (ns:make-ns-point 10 10)) > (defun label (v) > (#/drawAtPoint:withAttributes: #@"Scribble" (ns:make-ns-point 15 > 15) +null-ptr+) > (#/stroke path))) > > > Instead of like this: > > (defun label (v) > (let* ((path (make-instance ns:ns-bezier-path))) > (#/moveToPoint: path (ns:make-ns-point 10 10)) > (#/lineToPoint: path (ns:make-ns-point 10 40)) > (#/lineToPoint: path (ns:make-ns-point 90 40)) > (#/lineToPoint: path (ns:make-ns-point 90 10)) > (#/lineToPoint: path (ns:make-ns-point 10 10)) > (#/fill path) > (#/drawAtPoint:withAttributes: #@"Scribble" (ns:make-ns-point 15 > 15) +null-ptr+) > (#/stroke path))) > > > Does putting the defun inside the let do something different than > putting the let inside the defun? > > Neil > _______________________________________________ > 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 ron at awun.net Thu Jun 4 12:33:27 2009 From: ron at awun.net (Ron Garret) Date: Thu, 4 Jun 2009 12:33:27 -0700 Subject: [Openmcl-devel] Pre-wheel-reinvention query: anyone written an FFI hookup to popen? Message-ID: Subject line says it all. I need to call popen. I'm sure it's not hard, which is why I thought I'd ask if it's already been done before diving in. Thanks, rg From neil.baylis at gmail.com Thu Jun 4 12:53:00 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Thu, 4 Jun 2009 12:53:00 -0700 Subject: [Openmcl-devel] Scribble demo In-Reply-To: References: <0C32832E-A977-4F13-8177-857843A85900@awun.net> <1e6b7d810906041049mf36fcc5t8bad781b1e7c628d@mail.gmail.com> Message-ID: <1e6b7d810906041253l29967548j9f95bc4adca5357e@mail.gmail.com> OK, I get it. I was confused by the fact that they both seem to work. But the version with let inside the defun needlessly recomputes the path every time it's called, and then the path immediately becomes garbage when the function exits. Ron, I've read your paper multiple times. I keep a copy of it in a handy place on my computer, along with my local copy of the hyperspec and other useful documents. I guess I need to read it a few more times yet. ;-) FWIW, I'm working on tool for experimenting with tiling patterns, such as the one attached. My previous CL project used ltk, and I didn't want to use that again. I figured I would use either Cocoa/Quartz or maybe Cairo. I'm also looking at XMLisp. Thanks everyone, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tiles-1.jpg Type: image/jpeg Size: 142179 bytes Desc: not available URL: From gb at clozure.com Thu Jun 4 16:29:48 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 4 Jun 2009 17:29:48 -0600 (MDT) Subject: [Openmcl-devel] Pre-wheel-reinvention query: anyone written an FFI hookup to popen? In-Reply-To: References: Message-ID: (defun popen (command mode) "command should be a string, passed to \"sh -c\". mode indicates whether the returned stdio stream will be open for reading (\"r\"), writing (\"w\"), or both (\"r+\"). Return value is a pointer to an stdio stream; if the pointer's NULL, an error occurred." (with-cstrs ((ccommand command) (cmode mode)) (let* ((stdio-stream (#_popen ccommand cmode))) (if (%null-ptr-p stdio-stream) (ccl::%errno-disp (ccl::%get-errno)) stdio-stream)))) The number of things that you can usefully do with a C "FILE *" pointer in CCL is pretty limited. You could pass that pointer to foreign code that wants a "FILE *", or if you were really trying to avoid use of CCL:RUN-PROGRAM for some reason you could write a Gray Stream wrapper around stdio streams, but it seems like it'd be simpler to just use RUN-PROGRAM. On Thu, 4 Jun 2009, Ron Garret wrote: > Subject line says it all. I need to call popen. I'm sure it's not > hard, which is why I thought I'd ask if it's already been done before > diving in. > > Thanks, > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From ron at awun.net Thu Jun 4 18:38:29 2009 From: ron at awun.net (Ron Garret) Date: Thu, 4 Jun 2009 18:38:29 -0700 Subject: [Openmcl-devel] Pre-wheel-reinvention query: anyone written an FFI hookup to popen? In-Reply-To: References: Message-ID: <85377B8F-CF9B-42D8-8E34-63EAD11F0F17@awun.net> On Jun 4, 2009, at 4:29 PM, Gary Byers wrote: > The number of things that you can usefully do with a C "FILE *" > pointer > in CCL is pretty limited. Yeah, I noticed that :-) It's damned annoying that popen "helpfully" returns a file pointer instead of an FD. > if you were really trying to avoid use of > CCL:RUN-PROGRAM for some reason Nope, just forgot it was there. Thanks for reminding me! rg From terje at in-progress.com Thu Jun 4 18:38:49 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Thu, 4 Jun 2009 18:38:49 -0700 Subject: [Openmcl-devel] Pre-wheel-reinvention query: anyone written an FFI hookup to popen? In-Reply-To: References: Message-ID: <6DF84756-6261-4B95-B990-32494E0B3EF3@in-progress.com> On Jun 4, 2009, at 12:33 PM, Ron Garret wrote: > Subject line says it all. I need to call popen. I'm sure it's > not hard, which is why I thought I'd ask if it's already been done > before diving in. I have written a FFI hookup to popen() that can execute a BSD command in a shell, with the meat of it being a kqueue based bidirectional stream to communicate with the external process from LISP. It's for MCL though, but perhaps you would still find it useful? -- Terje Norderhaug From ron at awun.net Thu Jun 4 18:58:02 2009 From: ron at awun.net (Ron Garret) Date: Thu, 4 Jun 2009 18:58:02 -0700 Subject: [Openmcl-devel] Pre-wheel-reinvention query: anyone written an FFI hookup to popen? In-Reply-To: <6DF84756-6261-4B95-B990-32494E0B3EF3@in-progress.com> References: <6DF84756-6261-4B95-B990-32494E0B3EF3@in-progress.com> Message-ID: <91485AA6-A093-4304-8331-5B7FF2154F7E@awun.net> On Jun 4, 2009, at 6:38 PM, Terje Norderhaug wrote: > On Jun 4, 2009, at 12:33 PM, Ron Garret wrote: >> Subject line says it all. I need to call popen. I'm sure it's >> not hard, which is why I thought I'd ask if it's already been done >> before diving in. > > I have written a FFI hookup to popen() that can execute a BSD command > in a shell, with the meat of it being a kqueue based bidirectional > stream to communicate with the external process from LISP. It's for > MCL though, but perhaps you would still find it useful? Thanks for the offer, but probably not. The MCL and CCL FFI's are pretty radically different if I recall. Besides, I think CCL's built- in run-program will do what I need. But thanks anyway. rg From neil.baylis at gmail.com Thu Jun 4 21:10:31 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Thu, 4 Jun 2009 21:10:31 -0700 Subject: [Openmcl-devel] Swank listener startup preference seems not to work Message-ID: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> I see the preference item for disabling the swank listener at launch, but it seems not to work. If I evaluate (require :cocoa) it always launches a new listener. When I do this from emacs/slime, I get a whole bunch of name conflicts for swank items. I'm using ccl Version 1.4-dev-r12199M-trunk which I got from SVN tonight. (Leopard/Intel). I'm assuming that if I successfully disable the swank listener startup, then I will stop seeing the swank name conflicts in emacs/slime. Maybe there's a simpler way to avoid them, in which case I'm all ears. Oh yeah, I'm attempting to set the preference while running the temp bundle32 application that launches when I evaluate (require :cocoa). Is that the right way? Thanks, Neil Baylis -------------- next part -------------- An HTML attachment was scrubbed... URL: From slepstein at mindspring.com Thu Jun 4 21:10:48 2009 From: slepstein at mindspring.com (slepstein at mindspring.com) Date: Fri, 5 Jun 2009 00:10:48 -0400 (GMT-04:00) Subject: [Openmcl-devel] declare Message-ID: <4159838.1244175048856.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> I believe in type checking, but the declare usage is puzzling me, and I think it has changed in the last 6 months or so? What (I think) used to work and was acceptable in MCL: (defun foo-1 (x) (declare (integer x y)) (let* ((y 3)) (+ x y))) ;Compiler warnings : ; In FOO-1: TYPE declaration for unknown variable Y This compiles without warnings: (defun foo-2 (x) (declare (integer x)) (let* ((y 3)) (declare (integer y)) (+ x y))) But this doesn?t: (defun foo-3 (x) (declare (integer x)) (let* ((y 3)) (z (+ x y))) (declare (integer y z)) (+ x y z))) Error: While compiling FOO-3 : DECLARE not expected in (DECLARE (INTEGER Y Z))., in process Listener(6). Nor does this: (defun foo-4 (x) (let* ((y 3)) (z (+ x y))) (declare (integer x y z)) (+ x y z)) > Error: While compiling FOO-4 : > DECLARE not expected in (DECLARE (INTEGER X Y Z))., in process Listener(6). It looks as if the declare has to come early, but how does one type z? Thanks for your help. From stassats at gmail.com Thu Jun 4 21:41:48 2009 From: stassats at gmail.com (Stas Boukarev) Date: Fri, 05 Jun 2009 08:41:48 +0400 Subject: [Openmcl-devel] declare In-Reply-To: <4159838.1244175048856.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> (slepstein@mindspring.com's message of "Fri, 5 Jun 2009 00:10:48 -0400 (GMT-04:00)") References: <4159838.1244175048856.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Message-ID: <877hzrpa0j.fsf@gmail.com> slepstein at mindspring.com writes: > I believe in type checking, but the declare usage is puzzling me, and I think it has changed in the last 6 months or so? > > What (I think) used to work and was acceptable in MCL: > (defun foo-1 (x) > (declare (integer x y)) > (let* ((y 3)) > (+ x y))) > ;Compiler warnings : > ; In FOO-1: TYPE declaration for unknown variable Y > > This compiles without warnings: > (defun foo-2 (x) > (declare (integer x)) > (let* ((y 3)) > (declare (integer y)) > (+ x y))) > > But this doesn?t: > (defun foo-3 (x) > (declare (integer x)) > (let* ((y 3)) > (z (+ x y))) > (declare (integer y z)) > (+ x y z))) > Error: While compiling FOO-3 : > DECLARE not expected in (DECLARE (INTEGER Y Z))., in process Listener(6). > > Nor does this: > (defun foo-4 (x) > (let* ((y 3)) > (z (+ x y))) > (declare (integer x y z)) > (+ x y z)) >> Error: While compiling FOO-4 : >> DECLARE not expected in (DECLARE (INTEGER X Y Z))., in process Listener(6). > > It looks as if the declare has to come early, but how does one type z? > Thanks for your help. Your paranthesis are wrongly balanced. (defun foo-3 (x) (declare (integer x)) (let* ((y 3) (z (+ x y))) (declare (integer y z)) (+ x y z))) (defun foo-4 (x) (let* ((y 3) (z (+ x y))) (declare (integer x y z)) (+ x y z))) -- With best regards, Stas. From gb at clozure.com Thu Jun 4 21:42:23 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 4 Jun 2009 22:42:23 -0600 (MDT) Subject: [Openmcl-devel] declare In-Reply-To: <4159838.1244175048856.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> References: <4159838.1244175048856.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Message-ID: On Fri, 5 Jun 2009, slepstein at mindspring.com wrote: > I believe in type checking, Many people also believe in indentation, which would make your code easier to read and make the problems in it more obvious. It's real, and worth believing in. but the declare usage is puzzling me, and I think it has changed in the last 6 months or so? Yes. > > What (I think) used to work and was acceptable in MCL: > (defun foo-1 (x) > (declare (integer x y)) At the point where the declaration appears, there is no binding of Y; the reference to Y in the DECLARE form has nothing to do with the Y in the inner LET*. MCL silently ignored malformed declarations, as did CCL until fairly recently. (I think that most of the changes having to do with this are in the trunk and not in the 1.3 release.) The changes that Gail made to warn about malformed or questionable declarations exposed several dozen such malformed declarations in the CCL sources, and fixing those cases makes the code at least somewhat "better" (safer, faster, or both.) > (let* ((y 3)) > (+ x y))) > ;Compiler warnings : > ; In FOO-1: TYPE declaration for unknown variable Y > > This compiles without warnings: > (defun foo-2 (x) > (declare (integer x)) > (let* ((y 3)) > (declare (integer y)) > (+ x y))) As it should: the declarations apply to variables which are in scope (or entering scope) at the point where the declarations appear. > > But this doesn?t: > (defun foo-3 (x) > (declare (integer x)) > (let* ((y 3)) > (z (+ x y))) > (declare (integer y z)) > (+ x y z))) > Error: While compiling FOO-3 : > DECLARE not expected in (DECLARE (INTEGER Y Z))., in process Listener(6). You have a LET* form that binds a single variable Y, and then a call to a function named Z (that you might have thought was a binding form for a variable named Z, but your code is misparenthesized if so. Declarations can generally only meaningfully appear at the beginning of the body of the containing form, before any executable forms. > > Nor does this: > (defun foo-4 (x) > (let* ((y 3)) > (z (+ x y))) > (declare (integer x y z)) > (+ x y z)) >> Error: While compiling FOO-4 : >> DECLARE not expected in (DECLARE (INTEGER X Y Z))., in process Listener(6). > > It looks as if the declare has to come early, but how does one type z? Actually, it comes too late, after the apparent call to a function named Z. > Thanks for your help. > Most CL-aware text editors and IDEs have facilities to help with paren-matching and indentation. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From gb at clozure.com Thu Jun 4 21:58:21 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 4 Jun 2009 22:58:21 -0600 (MDT) Subject: [Openmcl-devel] Swank listener startup preference seems not to work In-Reply-To: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> References: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> Message-ID: The code in the trunk IDE for setting up a swank listener is a work in progress; one of the primary goals of that work is to provide a way for the event thread to do I/O (for debugging) to something that's a little more lisp-aware and less clunky (and potentially more featureful) than the AltConsole window. That idea might or might not pan out (hopefully it will); until it does, whatever (perhaps preliminary) code is there to support that will likely change from day to day. Mikel Evins has been doing this work and would have a clearer understanding of where things stand than I do, but I believe that it's currently at or very near the point where there's no need to build Slime as part of the IDE build process. On Thu, 4 Jun 2009, Neil Baylis wrote: > I see the preference item for disabling the swank listener at launch, but it > seems not to work. If I evaluate (require :cocoa) it always launches a new > listener. When I do this from emacs/slime, I get a whole bunch of name > conflicts for swank items. > I'm using ccl Version 1.4-dev-r12199M-trunk which I got from SVN tonight. > (Leopard/Intel). > > I'm assuming that if I successfully disable the swank listener startup, then > I will stop seeing the swank name conflicts in emacs/slime. Maybe there's a > simpler way to avoid them, in which case I'm all ears. > > Oh yeah, I'm attempting to set the preference while running the temp > bundle32 application that launches when I evaluate (require :cocoa). Is that > the right way? > > Thanks, > > Neil Baylis > > From mevins at mac.com Thu Jun 4 23:16:34 2009 From: mevins at mac.com (mikel evins) Date: Fri, 05 Jun 2009 01:16:34 -0500 Subject: [Openmcl-devel] Swank listener startup preference seems not to work In-Reply-To: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> References: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> Message-ID: <2CE01F18-38F9-485D-9292-A31CDE1AAD21@mac.com> On Jun 4, 2009, at 11:10 PM, Neil Baylis wrote: > I see the preference item for disabling the swank listener at > launch, but it seems not to work. If I evaluate (require :cocoa) it > always launches a new listener. When I do this from emacs/slime, I > get a whole bunch of name conflicts for swank items. > > I'm using ccl Version 1.4-dev-r12199M-trunk which I got from SVN > tonight. (Leopard/Intel). > > I'm assuming that if I successfully disable the swank listener > startup, then I will stop seeing the swank name conflicts in emacs/ > slime. Maybe there's a simpler way to avoid them, in which case I'm > all ears. > > Oh yeah, I'm attempting to set the preference while running the temp > bundle32 application that launches when I evaluate (require :cocoa). > Is that the right way? As of the current version in the trunk, there should be no swank code building in CCL or the IDE. If you're seeing name conflicts or any other problems that seem related to SLIME or swank, I'd be interested in knowing about it. Here's how the swank listener works: When you start the IDE (which is built by evaluating (require :cocoa- application) at a CCL prompt), it checks user defaults for two values: whther to start the swank-listener, and what port to start it on. The swank-listener is not user-visible; it's a thread that opens a listener socket and waits for a connection from Emacs. If such a connection is made, followed by a request for swank, then the swank- listener process attempts to find the swank loader at the path supplied by Emacs. If the swank loader is where Emacs says it is, CCL loads it, then starts a swank server on the port requested by Emacs. Emacs then completes the handshake by opening a SLIME/swank connection to CCL. The idea is that the swank listener provides a way for CCL's IDE to start up a SLIME/swank connection without building any particular version of swank into the IDE, so that you can safely use whatever version of SLIME you happen to have. The Emacs-side code to start up the connection is in ccl/cocoa-ide/ swank-ccl-ide.el This is very new code. I've used it successfully a number of times now, but I'm still going over it, adding protections for various ways it can break. We haven't mentioned it publicly yet because it's probably a bit early for anyone to be using it with any seriousness. Still, if you're trying to use it and it breaks, I'd be interested in what went wrong. The widgets in the Preferences dialog enable you to tell CCL whether to try to start the swank-listener at launch, and if so, which port to use. The Start button attempts to start the swank listener immediately on the current port. Please note, once more, that the swank listener is NOT swank (CCL and the IDE build with no swank or SLIME code in them), and it's not a listener window. It's a thread on a listener socket that is waiting for Emacs to connect and say "hey, please load swank from this path I've given you, and then start it up on this port I;ve told you." --me From vebjorn at ljosa.com Fri Jun 5 04:34:56 2009 From: vebjorn at ljosa.com (Vebjorn Ljosa) Date: Fri, 5 Jun 2009 07:34:56 -0400 Subject: [Openmcl-devel] ccl:with-pointer-to-ivector for simple-arrays Message-ID: <00F39137-8DFA-478C-8F0C-F75EDEBC7399@ljosa.com> Hi I have been using ccl:with-pointer-to-ivector for some time to pass vector contents to foreign code. Now I would like to do the same with two- and three-dimensional simple-arrays of (unsigned-byte 8) and (unsigned-byte 16). (The arrays are images in cl-png.) I have found solutions for the other major CL implementations, but ClozureCL remains. Pretending that such arrays are laid out just like ivectors doesn't work: (let ((a (make-array (list 2 3) :element-type '(unsigned-byte 8)))) (dotimes (i 6) (setf (row-major-aref a i) i)) (ccl::without-gcing (ccl:with-macptrs ((p)) (ccl::%vect-data-to-macptr a p) (loop for i below 6 collect (cffi:mem-ref p :uint8 i))))) => (16 0 0 0 0 0) Could someone please explain how simple-arrays of unsigned-bytes are laid out in memory? Is there a pointer that I need to follow to data somewhere else? Thanks, Vebjorn From gz at clozure.com Fri Jun 5 05:27:31 2009 From: gz at clozure.com (Gail Zacharias) Date: Fri, 05 Jun 2009 08:27:31 -0400 Subject: [Openmcl-devel] Swank listener startup preference seems not to work In-Reply-To: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> References: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> Message-ID: <200906051226.PYH28785@mr02.lnh.mail.rcn.net> Did you remember to rebuild ccl after you got it from svn? At 6/5/2009 12:10 AM, Neil Baylis wrote: >I see the preference item for disabling the swank listener at >launch, but it seems not to work. If I evaluate (require :cocoa) it >always launches a new listener. When I do this from emacs/slime, I >get a whole bunch of name conflicts for swank items. > >I'm using ccl Version 1.4-dev-r12199M-trunk which I got from SVN >tonight. (Leopard/Intel). > >I'm assuming that if I successfully disable the swank listener >startup, then I will stop seeing the swank name conflicts in >emacs/slime. Maybe there's a simpler way to avoid them, in which >case I'm all ears. > >Oh yeah, I'm attempting to set the preference while running the temp >bundle32 application that launches when I evaluate (require :cocoa). >Is that the right way? > >Thanks, > >Neil Baylis >_______________________________________________ >Openmcl-devel mailing list >Openmcl-devel at clozure.com >http://clozure.com/mailman/listinfo/openmcl-devel From gb at clozure.com Fri Jun 5 05:39:27 2009 From: gb at clozure.com (Gary Byers) Date: Fri, 5 Jun 2009 06:39:27 -0600 (MDT) Subject: [Openmcl-devel] ccl:with-pointer-to-ivector for simple-arrays In-Reply-To: <00F39137-8DFA-478C-8F0C-F75EDEBC7399@ljosa.com> References: <00F39137-8DFA-478C-8F0C-F75EDEBC7399@ljosa.com> Message-ID: A multidimensional array in CCL is always (at least implicitly) displaced. Array displacement in CL can be transitive (an array A can be displaced to some other array B which can be displaced to a third array C ...); whatever's at the end of this chain of displacement in CCL is always a simple one-dimensional array. If a multidemensional array in CCL is a SIMPLE-ARRAY, then the multidemensional array is directly displaced to a simple one-dimensional array (the length of the chain of transitive displacement is exactly 1.) CL provides a function - ARRAY-DISPLACEMENT - which will portably return the non-null value of the :DISPLACED-TO argument to MAKE-ARRAY (or ADJUST-ARRAY), but which may return NIL if the displacement is implicit (and which does return a first value of NIL in this case in CCL.) An internal function - CCL::ARRAY-DATA-AND-OFFSET - which is based on something that someone proposed for inclusion in CL but was never adopted - will follow any transitive displacement chain associated with its array argument and return the underlying simple one-dimensional array (and the cumulative DISPLACED-INDEX-OFFSET as a second value.) ? (let* ((a (make-array (list 2 3) :element-type '(unsigned-byte 8)))) (dotimes (i 6) (setf (row-major-aref a i) i)) (ccl::array-data-and-offset a)) #(0 1 2 3 4 5) ; A is implicitly and "directly" displaced to this vector 0 ; cumulative displacement is always 0 in this case. ? (type-of *) (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (6)) A simple one-dimensional array with an "immediate" (number or character) element-type is called an IVECTOR (the term was used in Spice Lisp ~ 25 years ago), and it's meaningful use things like CCL:WITH-POINTER-TO-IVECTOR on any IVECTOR (and it might be reasonable of CCL:WITH-POINTER-TO-IVECTOR handled anything transitively displaced to an IVECTOR, or if something like it did.) On Fri, 5 Jun 2009, Vebjorn Ljosa wrote: > Hi > > I have been using ccl:with-pointer-to-ivector for some time to pass > vector contents to foreign code. Now I would like to do the same with > two- and three-dimensional simple-arrays of (unsigned-byte 8) and > (unsigned-byte 16). (The arrays are images in cl-png.) I have found > solutions for the other major CL implementations, but ClozureCL remains. > > Pretending that such arrays are laid out just like ivectors doesn't > work: > > (let ((a (make-array (list 2 3) :element-type '(unsigned-byte 8)))) > (dotimes (i 6) > (setf (row-major-aref a i) i)) > (ccl::without-gcing > (ccl:with-macptrs ((p)) > (ccl::%vect-data-to-macptr a p) > (loop > for i below 6 > collect (cffi:mem-ref p :uint8 i))))) > => (16 0 0 0 0 0) > > Could someone please explain how simple-arrays of unsigned-bytes are > laid out in memory? Is there a pointer that I need to follow to data > somewhere else? > > Thanks, > Vebjorn > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From vebjorn at ljosa.com Fri Jun 5 06:48:53 2009 From: vebjorn at ljosa.com (Vebjorn Ljosa) Date: Fri, 5 Jun 2009 09:48:53 -0400 Subject: [Openmcl-devel] ccl:with-pointer-to-ivector for simple-arrays In-Reply-To: References: <00F39137-8DFA-478C-8F0C-F75EDEBC7399@ljosa.com> Message-ID: <493FFF50-5778-4E6C-B5A4-9806B2FBE6E2@ljosa.com> On Jun 5, 2009, at 08:39, Gary Byers wrote: > A multidimensional array in CCL is always (at least implicitly) > displaced. > An internal function - CCL::ARRAY-DATA-AND-OFFSET - which is based on > something that someone proposed for inclusion in CL but was never > adopted - will follow any transitive displacement chain associated > with its array argument and return the underlying simple one- > dimensional > array (and the cumulative DISPLACED-INDEX-OFFSET as a second value.) Thank you so much! I got it to work now: #+ccl (defmacro with-pointer-to-array-data ((ptr-var array) &body body) (let ((v (gensym))) `(let ((,v (ccl::array-data-and-offset ,array))) (unless (typep ,v 'ccl::ivector) (ccl::report-bad-arg ,v 'ccl::ivector)) (ccl::without-gcing (ccl:with-macptrs ((,ptr-var)) (ccl::%vect-data-to-macptr ,v ,ptr-var) , at body))))) Vebjorn From taoufik.dachraoui at wanadoo.fr Fri Jun 5 07:15:44 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Fri, 5 Jun 2009 16:15:44 +0200 Subject: [Openmcl-devel] readtable Message-ID: Hi I created a new macro-character #\: to check and disallow access to not external symbols as follows: (defun check-columns (stream char) (let ((ch (peek-char nil stream t nil t))) (if (eql ch #\:) (error "access to internal symbols not allowed") (progn (unread-char #\: stream) (set-macro-character #\: nil) (let ((res (read stream t nil t))) (set-macro-character #\: #'check-columns) res) )))) (set-macro-character #\: #'check-columns) Note: according to the book ANSI Common Lisp by Paul Graham, unread- char cannot be done after a peek-char. But in my tests ccl did not complain. Now I would like to restore the standard readtable but failed. I tried the following: (set-macro-character #\: nil) Even if I quit ccl and launch a new image I still get the following message when I try to access a symbol using :: ? (make-package 'test) ? (setq test::x 1) > Error: access to internal symbols not allowed > While executing: MB::CHECK-COLUMNS, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > How do I restore the standard readtable Kind regards -Taoufik -------------- next part -------------- An HTML attachment was scrubbed... URL: From danieldickison at gmail.com Fri Jun 5 07:18:11 2009 From: danieldickison at gmail.com (Daniel Dickison) Date: Fri, 5 Jun 2009 10:18:11 -0400 Subject: [Openmcl-devel] readtable In-Reply-To: References: Message-ID: <51CAC3DC-1B3B-45DE-9105-C23DF3155D68@gmail.com> How about using with-standard-io-syntax? http://www.lispworks.com/documentation/HyperSpec/Body/m_w_std_.htm On Jun 5, 2009, at 10:15 AM, Taoufik Dachraoui wrote: > Hi > > I created a new macro-character #\: to check and disallow access to > not external symbols as follows: > > (defun check-columns (stream char) > (let ((ch (peek-char nil stream t nil t))) > (if (eql ch #\:) > (error "access to internal symbols not allowed") > (progn > (unread-char #\: stream) > (set-macro-character #\: nil) > (let ((res (read stream t nil t))) > (set-macro-character #\: #'check-columns) > res) > )))) > > (set-macro-character #\: #'check-columns) > > Note: according to the book ANSI Common Lisp by Paul Graham, unread- > char cannot be done > after a peek-char. But in my tests ccl did not complain. > > Now I would like to restore the standard readtable but failed. I > tried the following: > > (set-macro-character #\: nil) > > Even if I quit ccl and launch a new image I still get the following > message when I try to access a symbol using :: > > > ? (make-package 'test) > ? (setq test::x 1) > > > Error: access to internal symbols not allowed > > While executing: MB::CHECK-COLUMNS, in process listener(1). > > Type :POP to abort, :R for a list of available restarts. > > Type :? for other options. > 1 > > > > How do I restore the standard readtable > > Kind regards > > -Taoufik > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From stassats at gmail.com Fri Jun 5 07:27:58 2009 From: stassats at gmail.com (Stas Boukarev) Date: Fri, 05 Jun 2009 18:27:58 +0400 Subject: [Openmcl-devel] readtable In-Reply-To: (Taoufik Dachraoui's message of "Fri, 5 Jun 2009 16:15:44 +0200") References: Message-ID: <873aaepxg1.fsf@gmail.com> Taoufik Dachraoui writes: > Hi > > I created a new macro-character #\: to check and disallow access to not external symbols as follows: > > (defun check-columns (stream char) > (let ((ch (peek-char nil stream t nil t))) > (if (eql ch #\:) > (error "access to internal symbols not allowed") > (progn > (unread-char #\: stream) > (set-macro-character #\: nil) > (let ((res (read stream t nil t))) > (set-macro-character #\: #'check-columns) > res) > )))) > > (set-macro-character #\: #'check-columns) > > Note: according to the book ANSI Common Lisp by Paul Graham, unread-char cannot be done > after a peek-char. But in my tests ccl did not complain. > > Now I would like to restore the standard readtable but failed. I tried the following: > > (set-macro-character #\: nil) > > Even if I quit ccl and launch a new image I still get the following message when I try to access a symbol using :: > > ? (make-package 'test) > ? (setq test::x 1) > >> Error: access to internal symbols not allowed >> While executing: MB::CHECK-COLUMNS, in process listener(1). >> Type :POP to abort, :R for a list of available restarts. >> Type :? for other options. > 1 > > > How do I restore the standard readtable > (setf *readtable* (copy-readtable)) should restore standard readtable. -- With best regards, Stas. From taoufik.dachraoui at wanadoo.fr Fri Jun 5 07:56:32 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Fri, 5 Jun 2009 16:56:32 +0200 Subject: [Openmcl-devel] readtable In-Reply-To: <873aaepxg1.fsf@gmail.com> References: <873aaepxg1.fsf@gmail.com> Message-ID: <7B0131E1-1B2A-4F53-8EE3-E850B713A4BA@wanadoo.fr> On Jun 5, 2009, at 4:27 PM, Stas Boukarev wrote: > > Taoufik Dachraoui writes: > >> Hi >> >> I created a new macro-character #\: to check and disallow access to >> not external symbols as follows: >> >> (defun check-columns (stream char) >> (let ((ch (peek-char nil stream t nil t))) >> (if (eql ch #\:) >> (error "access to internal symbols not allowed") >> (progn >> (unread-char #\: stream) >> (set-macro-character #\: nil) >> (let ((res (read stream t nil t))) >> (set-macro-character #\: #'check-columns) >> res) >> )))) >> >> (set-macro-character #\: #'check-columns) >> >> Note: according to the book ANSI Common Lisp by Paul Graham, unread- >> char cannot be done >> after a peek-char. But in my tests ccl did not complain. >> >> Now I would like to restore the standard readtable but failed. I >> tried the following: >> >> (set-macro-character #\: nil) >> >> Even if I quit ccl and launch a new image I still get the following >> message when I try to access a symbol using :: >> >> ? (make-package 'test) >> ? (setq test::x 1) >> >>> Error: access to internal symbols not allowed >>> While executing: MB::CHECK-COLUMNS, in process listener(1). >>> Type :POP to abort, :R for a list of available restarts. >>> Type :? for other options. >> 1 > >> >> How do I restore the standard readtable >> > (setf *readtable* (copy-readtable)) should restore standard readtable. > > -- > With best regards, Stas. > I tried (setf *readtable* (copy-readtable)) but I still get the same message Even when I quit ccl and relaunch. -Taoufik From slepstein at mindspring.com Fri Jun 5 08:02:54 2009 From: slepstein at mindspring.com (slepstein at mindspring.com) Date: Fri, 5 Jun 2009 11:02:54 -0400 (EDT) Subject: [Openmcl-devel] declare in a loop Message-ID: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> It seems to me that the ability to declare the type of local variables within a loop might result in faster compiled code. For example, if one iterated through a list of objects as in (for i in whatever?) it would be nice to know what the type of i is. Is there syntax for this or a good reason not to have it? Thanks in advance. From taoufik.dachraoui at wanadoo.fr Fri Jun 5 08:07:07 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Fri, 5 Jun 2009 17:07:07 +0200 Subject: [Openmcl-devel] readtable In-Reply-To: <873aaepxg1.fsf@gmail.com> References: <873aaepxg1.fsf@gmail.com> Message-ID: On Jun 5, 2009, at 4:27 PM, Stas Boukarev wrote: > > Taoufik Dachraoui writes: > >> Hi >> >> I created a new macro-character #\: to check and disallow access to >> not external symbols as follows: >> >> (defun check-columns (stream char) >> (let ((ch (peek-char nil stream t nil t))) >> (if (eql ch #\:) >> (error "access to internal symbols not allowed") >> (progn >> (unread-char #\: stream) >> (set-macro-character #\: nil) >> (let ((res (read stream t nil t))) >> (set-macro-character #\: #'check-columns) >> res) >> )))) >> >> (set-macro-character #\: #'check-columns) >> >> Note: according to the book ANSI Common Lisp by Paul Graham, unread- >> char cannot be done >> after a peek-char. But in my tests ccl did not complain. >> >> Now I would like to restore the standard readtable but failed. I >> tried the following: >> >> (set-macro-character #\: nil) >> >> Even if I quit ccl and launch a new image I still get the following >> message when I try to access a symbol using :: >> >> ? (make-package 'test) >> ? (setq test::x 1) >> >>> Error: access to internal symbols not allowed >>> While executing: MB::CHECK-COLUMNS, in process listener(1). >>> Type :POP to abort, :R for a list of available restarts. >>> Type :? for other options. >> 1 > >> >> How do I restore the standard readtable >> > (setf *readtable* (copy-readtable)) should restore standard readtable. > > -- > With best regards, Stas. > Sorry, I solved the problem. It was my fault, the set-macro-character was defined in .ccl-init.lisp file -Taoufik From stassats at gmail.com Fri Jun 5 08:07:02 2009 From: stassats at gmail.com (Stas Boukarev) Date: Fri, 05 Jun 2009 19:07:02 +0400 Subject: [Openmcl-devel] declare in a loop In-Reply-To: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> (slepstein@mindspring.com's message of "Fri, 5 Jun 2009 11:02:54 -0400 (EDT)") References: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Message-ID: <87y6s6oh2h.fsf@gmail.com> slepstein at mindspring.com writes: > It seems to me that the ability to declare the type of local variables within a loop might result in faster compiled code. For example, if one iterated through a list of objects as in > (for i in whatever?) > it would be nice to know what the type of i is. > > Is there syntax for this or a good reason not to have it? (loop for i fixnum in list) or (loop for i of-type (unsigned-byte 64) in list) for compound type specifiers. -- With best regards, Stas. From brian at mastenbrook.net Fri Jun 5 08:07:41 2009 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Fri, 5 Jun 2009 10:07:41 -0500 Subject: [Openmcl-devel] declare in a loop In-Reply-To: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> References: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Message-ID: <4C1509EB-D246-456F-9326-F7654A195EBB@mastenbrook.net> You might want to read the documentation on LOOP: http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm On Jun 5, 2009, at 10:02 AM, slepstein at mindspring.com wrote: > It seems to me that the ability to declare the type of local > variables within a loop might result in faster compiled code. For > example, if one iterated through a list of objects as in > (for i in whatever?) > it would be nice to know what the type of i is. > > Is there syntax for this or a good reason not to have it? > > Thanks in advance. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -- Brian Mastenbrook brian at mastenbrook.net http://brian.mastenbrook.net/ From neil.baylis at gmail.com Fri Jun 5 08:08:43 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Fri, 5 Jun 2009 08:08:43 -0700 Subject: [Openmcl-devel] Swank listener startup preference seems not to work In-Reply-To: <2CE01F18-38F9-485D-9292-A31CDE1AAD21@mac.com> References: <1e6b7d810906042110p510ba2ya1d84353e5fd922@mail.gmail.com> <2CE01F18-38F9-485D-9292-A31CDE1AAD21@mac.com> Message-ID: <1e6b7d810906050808u2717f6ben3683a3203716ae59@mail.gmail.com> Well, this morning I can't reproduce the name conflict issue. I was going to capture the emacs messages I was seeing, to help debug the problem. I decided to close & reopen emacs, so there would be minimum distracting info in the *slime-events* buffer. After restarting emacs I no longer see the name conflicts. I had previously stopped and restarted slime many times without restarting emacs. I had also restarted emacs multiple times in the past few days. It might be that this is the first time I restarted emacs since rebuilding ccl. Anyway, it seems to be working the way you describe now, sorry for the noise. Thanks, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From gz at clozure.com Fri Jun 5 08:16:41 2009 From: gz at clozure.com (Gail Zacharias) Date: Fri, 05 Jun 2009 11:16:41 -0400 Subject: [Openmcl-devel] declare in a loop In-Reply-To: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa. earthlink.net> References: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Message-ID: <200906051515.KXJ50977@mr08.lnh.mail.rcn.net> for i type-of-i in whatever At 6/5/2009 11:02 AM, slepstein at mindspring.com wrote: >It seems to me that the ability to declare the type of local >variables within a loop might result in faster compiled code. For >example, if one iterated through a list of objects as in (for i in >whatever ) it would be nice to kknow what the type of i is. Is there >syntax for this or a good reason not to have it? Thanks in advance. >_______________________________________________ Openmcl-devel >mailing list Openmcl-devel at clozure.com >http://clozure.com/mailman/listinfo/openmcl-devel From FLengyel at gc.cuny.edu Fri Jun 5 08:35:17 2009 From: FLengyel at gc.cuny.edu (Lengyel, Florian) Date: Fri, 5 Jun 2009 11:35:17 -0400 Subject: [Openmcl-devel] declare in a loop References: <25805662.1244214174610.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> <4C1509EB-D246-456F-9326-F7654A195EBB@mastenbrook.net> Message-ID: <6889DDC1CE0D7845912CB738AEE21A0A0245E1C6@MAILBE.acad.gc.cuny.edu> You might want to formulate a more focused reply. ________________________________ From: openmcl-devel-bounces at clozure.com on behalf of Brian Mastenbrook Sent: Fri 6/5/2009 11:07 AM To: slepstein at mindspring.com Cc: openmcl-devel at clozure.com Subject: Re: [Openmcl-devel] declare in a loop You might want to read the documentation on LOOP: http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm On Jun 5, 2009, at 10:02 AM, slepstein at mindspring.com wrote: > It seems to me that the ability to declare the type of local > variables within a loop might result in faster compiled code. For > example, if one iterated through a list of objects as in > (for i in whatever...) > it would be nice to know what the type of i is. > > Is there syntax for this or a good reason not to have it? > > Thanks in advance. > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel -- Brian Mastenbrook brian at mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ 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 tcr at freebits.de Fri Jun 5 11:48:32 2009 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Fri, 05 Jun 2009 20:48:32 +0200 Subject: [Openmcl-devel] readtable References: <873aaepxg1.fsf@gmail.com> Message-ID: <87hbyutt33.fsf@freebits.de> Stas Boukarev writes: > (setf *readtable* (copy-readtable)) should restore standard readtable. ITYM, (COPY-READTABLE NIL). (COPY-READTABLE) will return a copy of the current readtable. :-) -T. From stassats at gmail.com Fri Jun 5 12:02:25 2009 From: stassats at gmail.com (Stas Boukarev) Date: Fri, 05 Jun 2009 23:02:25 +0400 Subject: [Openmcl-devel] readtable In-Reply-To: <87hbyutt33.fsf@freebits.de> (Tobias C. Rittweiler's message of "Fri, 05 Jun 2009 20:48:32 +0200") References: <873aaepxg1.fsf@gmail.com> <87hbyutt33.fsf@freebits.de> Message-ID: <87my8mo666.fsf@gmail.com> "Tobias C. Rittweiler" writes: > Stas Boukarev writes: > >> (setf *readtable* (copy-readtable)) should restore standard readtable. > > ITYM, (COPY-READTABLE NIL). (COPY-READTABLE) will return a copy of the > current readtable. :-) > Right. -- With best regards, Stas. From taoufik.dachraoui at wanadoo.fr Fri Jun 5 16:21:06 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Sat, 6 Jun 2009 01:21:06 +0200 Subject: [Openmcl-devel] read macro Message-ID: <71DB7D67-829C-41DD-AC82-760540B9B10D@wanadoo.fr> Hi, I am puzzled about the following, can someone tell me why read is expecting a function THERE in the first command and not in the second command (below)? ? (read) here (there) HERE ? > Error: Undefined function THERE called with arguments () . > While executing: CCL::TOPLEVEL-EVAL, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Retry applying THERE to NIL. > Type :? for other options. 1 > :pop ? (read) (there) (THERE) ? Kind regards -Taoufik From taoufik.dachraoui at wanadoo.fr Fri Jun 5 17:09:42 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Sat, 6 Jun 2009 02:09:42 +0200 Subject: [Openmcl-devel] read macro In-Reply-To: <71DB7D67-829C-41DD-AC82-760540B9B10D@wanadoo.fr> References: <71DB7D67-829C-41DD-AC82-760540B9B10D@wanadoo.fr> Message-ID: <9E4DA010-C733-480D-A1D8-FE6ECEA7CBBF@wanadoo.fr> On Jun 6, 2009, at 1:21 AM, Taoufik Dachraoui wrote: > Hi, > > I am puzzled about the following, can someone tell me why read is > expecting a function THERE in the first command > and not in the second command (below)? > > ? (read) > here (there) > > HERE > ? > Error: Undefined function THERE called with arguments () . > > While executing: CCL::TOPLEVEL-EVAL, in process listener(1). > > Type :GO to continue, :POP to abort, :R for a list of available > restarts. > > If continued: Retry applying THERE to NIL. > > Type :? for other options. > 1 > :pop > > ? (read) > (there) > > (THERE) > ? > > > Kind regards > > -Taoufik Sorry, it looks obvious now, I guess I am tired I need to take a break. Kind regards -Taoufik From ron at awun.net Sat Jun 6 10:01:10 2009 From: ron at awun.net (Ron Garret) Date: Sat, 6 Jun 2009 10:01:10 -0700 Subject: [Openmcl-devel] Class redefinition demo Message-ID: <513A6ECA-CC33-4F9A-888C-CDE109FAAAEF@awun.net> For those of you playing with RMCL, there's a bug that causes class redefinition not to work properly. Gary has produced a patch, which is at ftp://clozure.com/pub/rmcl-updates Because I'm allergic to FTP, a stripped-down version of the patch is included in this email which you can just load into RMCL. No need to rebuild the app if you don't want to. This patch has allowed me to resurrect my favorite Lisp demo of all time, which is also attached. It's called draggable, and it's a dramatic illustration of the power of class redefinition. Load the demo. It will open a window with a bunch of text objects. Click on them and try to drag them around and observe that nothing happens. Now evaluate the first of the commented-out lines at the bottom of the file and try dragging them around again. Now evaluate the second line and repeat. Let's see someone do *that* in Python! Enjoy! rg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rmcl-clos-patch.lisp Type: application/octet-stream Size: 1746 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: draggable.lisp Type: application/octet-stream Size: 1871 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From terje at in-progress.com Sat Jun 6 10:55:51 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Sat, 6 Jun 2009 10:55:51 -0700 Subject: [Openmcl-devel] Class redefinition demo In-Reply-To: <513A6ECA-CC33-4F9A-888C-CDE109FAAAEF@awun.net> References: <513A6ECA-CC33-4F9A-888C-CDE109FAAAEF@awun.net> Message-ID: <9FE223AD-48CD-4468-B9ED-D05C85CBE8F9@in-progress.com> Thank you Gary and Ron for respectively creating the patch and providing the stripped down version. I'll start using it right away. PS: I suggest we make a habit of using #+rmcl in patches to distinguish code for RMCL from code meant for PPC MCL. Or at least that it warns if used for the wrong LISP. -- Terje Norderhaug On Jun 6, 2009, at 10:01 AM, Ron Garret wrote: > For those of you playing with RMCL, there's a bug that causes class > redefinition not to work properly. Gary has produced a patch, > which is at > > ftp://clozure.com/pub/rmcl-updates > > Because I'm allergic to FTP, a stripped-down version of the patch > is included in this email which you can just load into RMCL. No > need to rebuild the app if you don't want to. > > This patch has allowed me to resurrect my favorite Lisp demo of all > time, which is also attached. It's called draggable, and it's a > dramatic illustration of the power of class redefinition. Load the > demo. It will open a window with a bunch of text objects. Click > on them and try to drag them around and observe that nothing > happens. Now evaluate the first of the commented-out lines at the > bottom of the file and try dragging them around again. Now > evaluate the second line and repeat. > > Let's see someone do *that* in Python! > > Enjoy! > > rg > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From taoufik.dachraoui at wanadoo.fr Sat Jun 6 12:34:12 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Sat, 6 Jun 2009 21:34:12 +0200 Subject: [Openmcl-devel] fully expand a lisp code w/macros to a lisp code wo/macros Message-ID: <8A66DDB9-E89E-4BFF-B9E8-0B0A0C6FBE9C@wanadoo.fr> Hi, Did someone tried to fully expand a function/macro to remove all macro calls? macroexpand and macroexpand-1 are not solutions. Kind regards -Taoufik From stassats at gmail.com Sat Jun 6 12:37:32 2009 From: stassats at gmail.com (Stas Boukarev) Date: Sat, 06 Jun 2009 23:37:32 +0400 Subject: [Openmcl-devel] fully expand a lisp code w/macros to a lisp code wo/macros In-Reply-To: <8A66DDB9-E89E-4BFF-B9E8-0B0A0C6FBE9C@wanadoo.fr> (Taoufik Dachraoui's message of "Sat, 6 Jun 2009 21:34:12 +0200") References: <8A66DDB9-E89E-4BFF-B9E8-0B0A0C6FBE9C@wanadoo.fr> Message-ID: <8763f9nog3.fsf@gmail.com> Taoufik Dachraoui writes: > Hi, > > Did someone tried to fully expand a function/macro to remove all macro > calls? > > macroexpand and macroexpand-1 are not solutions. > Perhaps ccl:macroexpand-all? -- With best regards, Stas. From eslick at media.mit.edu Sat Jun 6 13:42:58 2009 From: eslick at media.mit.edu (Ian Eslick) Date: Sat, 6 Jun 2009 16:42:58 -0400 Subject: [Openmcl-devel] cl-l10n latest Message-ID: Has anyone tried loading the latest cl-l10n? Several of the files included have foreign characters that appear to cause problems for ccl while compiling. I'm trying to determine if it is a setup problem or a ccl related incompatibility. Thank you, Ian From stassats at gmail.com Sat Jun 6 13:56:53 2009 From: stassats at gmail.com (Stas Boukarev) Date: Sun, 07 Jun 2009 00:56:53 +0400 Subject: [Openmcl-devel] cl-l10n latest In-Reply-To: (Ian Eslick's message of "Sat, 6 Jun 2009 16:42:58 -0400") References: Message-ID: <87ws7pm67e.fsf@gmail.com> Ian Eslick writes: > Has anyone tried loading the latest cl-l10n? Several of the files > included have foreign characters that appear to cause problems for ccl > while compiling. I'm trying to determine if it is a setup problem or > a ccl related incompatibility. > Try to start ccl with -K utf-8 option. -- With best regards, Stas. From rme at clozure.com Sat Jun 6 14:12:44 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Sat, 6 Jun 2009 17:12:44 -0400 Subject: [Openmcl-devel] cl-l10n latest In-Reply-To: References: Message-ID: On Jun 6, 2009, at 4:42 PM, Ian Eslick wrote: > Has anyone tried loading the latest cl-l10n? Several of the files > included have foreign characters that appear to cause problems for ccl > while compiling. I'm trying to determine if it is a setup problem or > a ccl related incompatibility. If you set *default-external-format* to :utf-8, that might do the trick for cl-l10n. See http://ccl.clozure.com/ccl-documentation.html#Unicode From ron at awun.net Sun Jun 7 01:17:00 2009 From: ron at awun.net (Ron Garret) Date: Sun, 7 Jun 2009 01:17:00 -0700 Subject: [Openmcl-devel] mouse-enter and mouse-leave events Message-ID: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> I'm trying to port the draggable demo to CCL and have it mostly working, except that my subviews don't seem to be getting mouse-enter and mouse-leave events. I know that I have to explicitly enable mouse- move events, but is there something analogous I have to do to get enter and leave events? I haven't been able to find anything indicating that in the Cocoa docs, and yet it doesn't seem to work despite the fact that the handler interface code is pretty much identical. Code attached. Thanks, rg -------------- next part -------------- A non-text attachment was scrubbed... Name: drag.lisp Type: application/octet-stream Size: 5101 bytes Desc: not available URL: -------------- next part -------------- From ron at awun.net Sun Jun 7 01:19:05 2009 From: ron at awun.net (Ron Garret) Date: Sun, 7 Jun 2009 01:19:05 -0700 Subject: [Openmcl-devel] mouse-enter and mouse-leave events In-Reply-To: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> References: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> Message-ID: <4C7198B5-8ECC-4ADF-86B7-B98FD3D5A635@awun.net> Just remembered that this code depends on (the latest version of) my utilities file. On Jun 7, 2009, at 1:17 AM, Ron Garret wrote: > I'm trying to port the draggable demo to CCL and have it mostly > working, except that my subviews don't seem to be getting mouse- > enter and mouse-leave events. I know that I have to explicitly > enable mouse-move events, but is there something analogous I have to > do to get enter and leave events? I haven't been able to find > anything indicating that in the Cocoa docs, and yet it doesn't seem > to work despite the fact that the handler interface code is pretty > much identical. > > Code attached. > > Thanks, > rg > > > _______________________________________________ > 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: utilities.lisp Type: application/octet-stream Size: 26614 bytes Desc: not available URL: From gb at clozure.com Sun Jun 7 02:22:19 2009 From: gb at clozure.com (Gary Byers) Date: Sun, 7 Jun 2009 03:22:19 -0600 (MDT) Subject: [Openmcl-devel] mouse-enter and mouse-leave events In-Reply-To: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> References: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> Message-ID: See . The short version is that mouse-tracking events are generated when the mouse enters or leaves a "tracking area" (10.5) or "tracking rect" (earlier systems) which requires some work to set up and possibly some work to maintain but potentially offers greater flexibility than "mouse entered/left view" would. On Sun, 7 Jun 2009, Ron Garret wrote: > I'm trying to port the draggable demo to CCL and have it mostly working, > except that my subviews don't seem to be getting mouse-enter and mouse-leave > events. I know that I have to explicitly enable mouse-move events, but is > there something analogous I have to do to get enter and leave events? I > haven't been able to find anything indicating that in the Cocoa docs, and yet > it doesn't seem to work despite the fact that the handler interface code is > pretty much identical. > > Code attached. > > Thanks, > rg > From ralex at cs.colorado.edu Sun Jun 7 09:36:20 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Sun, 7 Jun 2009 10:36:20 -0600 Subject: [Openmcl-devel] mouse-enter and mouse-leave events In-Reply-To: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> References: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> Message-ID: XMLisp implements these kinds of events for OpenGL through scene picking: http://www.google.com/codesearch?q=MOUSE-HOVER-ENTER-EVENT-HANDLER+package%3Ahttp%3A%2F%2Fxmlisp%5C.googlecode%5C.com&origq=MOUSE-HOVER-ENTER-EVENT-HANDLER&btnG=Search+Trunk To make them work mouse tracking needs to be enabled, e.g., in XML ... Alex On Jun 7, 2009, at 2:17 AM, Ron Garret wrote: > I'm trying to port the draggable demo to CCL and have it mostly > working, except that my subviews don't seem to be getting mouse- > enter and mouse-leave events. I know that I have to explicitly > enable mouse-move events, but is there something analogous I have to > do to get enter and leave events? I haven't been able to find > anything indicating that in the Cocoa docs, and yet it doesn't seem > to work despite the fact that the handler interface code is pretty > much identical. > > Code attached. > > Thanks, > rg > > > _______________________________________________ > 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 joakim at joakimsandgren.com Sun Jun 7 10:01:21 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sun, 7 Jun 2009 19:01:21 +0200 Subject: [Openmcl-devel] cgfloat... Message-ID: Hi, how can I do a cgfloat? the gui::cgfloat return a normal float. that setLineWidth: dont want... how 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 ron at awun.net Sun Jun 7 11:11:25 2009 From: ron at awun.net (Ron Garret) Date: Sun, 7 Jun 2009 11:11:25 -0700 Subject: [Openmcl-devel] mouse-enter and mouse-leave events In-Reply-To: References: <439D9CA8-5E09-415B-AD29-A5211032812F@awun.net> Message-ID: <67FA25ED-7F38-41AF-B6C3-0A5AEDE75022@awun.net> Ah. Got it. Thanks! rg On Jun 7, 2009, at 2:22 AM, Gary Byers wrote: > > > See > >. > The short version is that mouse-tracking events are generated when the > mouse enters or leaves a "tracking area" (10.5) or "tracking rect" > (earlier systems) which requires some work to set up and possibly some > work to maintain but potentially offers greater flexibility than > "mouse entered/left view" would. > > > > On Sun, 7 Jun 2009, Ron Garret wrote: > >> I'm trying to port the draggable demo to CCL and have it mostly >> working, except that my subviews don't seem to be getting mouse- >> enter and mouse-leave events. I know that I have to explicitly >> enable mouse-move events, but is there something analogous I have >> to do to get enter and leave events? I haven't been able to find >> anything indicating that in the Cocoa docs, and yet it doesn't seem >> to work despite the fact that the handler interface code is pretty >> much identical. >> >> Code attached. >> >> Thanks, >> rg >> From raffaelcavallaro at mac.com Sun Jun 7 11:15:10 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Sun, 07 Jun 2009 14:15:10 -0400 Subject: [Openmcl-devel] cgfloat... In-Reply-To: References: Message-ID: <1D42A968-0079-49D7-BE99-17FF3E89B9E9@mac.com> On Jun 7, 2009, at 1:01 PM, Joakim Sandgren wrote: > Hi, > how can I do a cgfloat? the gui::cgfloat return a normal float. > that setLineWidth: dont want... > how to do?... This works correctly on both 32-bit and 64-bit ccl: Welcome to Clozure Common Lisp Version 1.4-dev-r12220M-trunk (DarwinX8664)! ? (type-of (coerce 3 'ns:cg-float)) DOUBLE-FLOAT Welcome to Clozure Common Lisp Version 1.4-dev-r12220M-trunk (DarwinX8632)! ? (type-of (coerce 3 'ns:cg-float)) SINGLE-FLOAT ? The approach I use is to bind *read-default-float-format* to ns:cg- float in code that expects CGFloats. warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From j-anthony at comcast.net Sun Jun 7 13:56:37 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Sun, 07 Jun 2009 16:56:37 -0400 Subject: [Openmcl-devel] Binary IO... Message-ID: <1244408197.2420.175.camel@sirius> Hi, As part of a porting job for my graph store, I'm experimenting with various binary IO variations (which need random access as well). Originally, this was done in C. I suppose I can still do that, but the CCL version is so much better than the ACL variant that getting rid of the C for it seems like a good - simpler - idea. There are some other possibilities as well but that is irrelevant here. But, there is still a head scratching aspect to the CL variant. Enclosed are two simple programs, one in C and one in CL. They both do the same thing and the CL pretty much mimics the "C level" form of the C. All they do is write and read a binary file in 8MB chunks (320MB worth). Setting aside the "elapsed time" aspects (which seem to pretty clearly be tied to the OS disk caching behavior) they are both pretty fast. But the C is still around 3X faster in general. This seems to be due to the fact that the CL burns up typically ~1.5 seconds in user mode. The C version typically runs with 0 (!) user mode time. The system level time of both is about the same ~800ms or so. I would have thought that read-sequence and write-sequence basically map to fread and fwrite respectively - especially (as in this case) the sequence involved is a simple array of unsigned byte 8. Long winded prelude to what would the CL variant be doing in user mode (read/write-sequence) that the C version is able to (or "dangerously") skips? Off hand, it doesn't seem like the type determination/resolution in read/write-sequence would burn up this much time. C is compiled simply with gcc. Here are a couple example timings: C: gcc (GCC) 4.1.0 20060304 (x8632) $ time ../megabyte-binary-io 0.004u 0.840s 0:00.86 97.6% 0+0k 0+0io 0pf+0w $ time ../megabyte-binary-io 0.000u 0.736s 0:00.73 100.0% 0+0k 0+0io 0pf+0w CL: (ccl-1.3 x8632) ? (time (main)) (MAIN) took 2,661 milliseconds (2.661 seconds) to run with 2 available CPU cores. During that period, 1,680 milliseconds (1.680 seconds) were spent in user mode 904 milliseconds (0.904 seconds) were spent in system mode 6 milliseconds (0.006 seconds) was spent in GC. 8,394,104 bytes of memory allocated. NIL ? (time (main)) (MAIN) took 7,590 milliseconds (7.590 seconds) to run with 2 available CPU cores. During that period, 1,716 milliseconds (1.716 seconds) were spent in user mode 768 milliseconds (0.768 seconds) were spent in system mode 6 milliseconds (0.006 seconds) was spent in GC. 8,394,104 bytes of memory allocated. Thanks, /Jon -------------- next part -------------- A non-text attachment was scrubbed... Name: megabyte-binary-io.lisp Type: text/x-emacs-lisp Size: 1399 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: megabyte-binary-io.c Type: text/x-csrc Size: 717 bytes Desc: not available URL: From steve.nunez at illation.com.sg Sun Jun 7 16:56:42 2009 From: steve.nunez at illation.com.sg (Steve =?ISO-8859-1?B?TvrxZXo=?=) Date: Mon, 08 Jun 2009 09:56:42 +1000 Subject: [Openmcl-devel] LISP & Statistics Message-ID: Gentlemen, I hope you?ll forgive a question that?s only tangentially related to OpenMCL... I?ve got a project coming up that involves predictive modelling and PMML. This is an area I have been involved with in the past, but am quite rusty. It seems that the ?state of the art? is ?R?. It?s an active, up to date project, with many contributions. In the Lisp side, there?s ?lisp-stat?, which seems dead. I don?t mind learning ?R?, but it?s YAL (Yet Another Language ? when are we (the industry) going to stop wasting time with this?), but would prefer not to add the learning curve time required to the project. Are there any viable alternatives for doing statistics in Lisp? 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 gb at clozure.com Sun Jun 7 17:04:30 2009 From: gb at clozure.com (Gary Byers) Date: Sun, 7 Jun 2009 18:04:30 -0600 (MDT) Subject: [Openmcl-devel] Binary IO... In-Reply-To: <1244408197.2420.175.camel@sirius> References: <1244408197.2420.175.camel@sirius> Message-ID: A stream's buffer is nailed down in foreign memory, so we can safely read from and write to it without worrying about the GC moving it around (because of activity in other threads.) That's not generally true of some arbitrary lisp vector, so in that general case we have to copy the vector's data into the buffer before writing (and copy from the buffer to the vector after reading.) Here's a little bit of profiling output from oprofile on Linux: samples % symbol name 10823 92.8774 110 0.9440 79 0.6779 61 0.5235 54 0.4634 51 0.4377 [a lot more of it omitted] I think that we can fairly safely ignore everything but %COPY-IVECTOR-TO-IVECTOR-BYTES for the time being. In your example, that function's being used to copy the contents of the sequence being (repeatedly) read or written to the stream's buffer. You might be able to do that copying at least marginally faster, but I think that it's likely that the C code is just reading/writing the vector directly (without copying), and since the lisp code is spending >90% of its time copying, it's likely that this copying accounts for most of the user-mode time difference. There are ways to inhibit the GC, obtain the (absolute, non-relocatable) address of the vector, and do I/O directly (bypassing the buffer). Whether that's better overall depends on what the cost of inhibiting the GC would be (which in turn depends on what kind of consing activitiy is going on in other threads.) On Sun, 7 Jun 2009, Jon S. Anthony wrote: > Hi, > > As part of a porting job for my graph store, I'm experimenting with > various binary IO variations (which need random access as well). > Originally, this was done in C. I suppose I can still do that, but the > CCL version is so much better than the ACL variant that getting rid of > the C for it seems like a good - simpler - idea. There are some other > possibilities as well but that is irrelevant here. But, there is still > a head scratching aspect to the CL variant. > > Enclosed are two simple programs, one in C and one in CL. They both do > the same thing and the CL pretty much mimics the "C level" form of the > C. All they do is write and read a binary file in 8MB chunks (320MB > worth). > > Setting aside the "elapsed time" aspects (which seem to pretty clearly > be tied to the OS disk caching behavior) they are both pretty fast. But > the C is still around 3X faster in general. This seems to be due to the > fact that the CL burns up typically ~1.5 seconds in user mode. The C > version typically runs with 0 (!) user mode time. The system level time > of both is about the same ~800ms or so. > > I would have thought that read-sequence and write-sequence basically map > to fread and fwrite respectively - especially (as in this case) the > sequence involved is a simple array of unsigned byte 8. > > Long winded prelude to what would the CL variant be doing in user mode > (read/write-sequence) that the C version is able to (or "dangerously") > skips? Off hand, it doesn't seem like the type determination/resolution > in read/write-sequence would burn up this much time. > > C is compiled simply with gcc. Here are a couple example timings: > > C: gcc (GCC) 4.1.0 20060304 (x8632) > > $ time ../megabyte-binary-io > > 0.004u 0.840s 0:00.86 97.6% 0+0k 0+0io 0pf+0w > > $ time ../megabyte-binary-io > > 0.000u 0.736s 0:00.73 100.0% 0+0k 0+0io 0pf+0w > > > CL: (ccl-1.3 x8632) > > ? (time (main)) > (MAIN) took 2,661 milliseconds (2.661 seconds) to run > with 2 available CPU cores. > During that period, 1,680 milliseconds (1.680 seconds) were spent in > user mode > 904 milliseconds (0.904 seconds) were spent in > system mode > 6 milliseconds (0.006 seconds) was spent in GC. > 8,394,104 bytes of memory allocated. > NIL > ? (time (main)) > (MAIN) took 7,590 milliseconds (7.590 seconds) to run > with 2 available CPU cores. > During that period, 1,716 milliseconds (1.716 seconds) were spent in > user mode > 768 milliseconds (0.768 seconds) were spent in > system mode > 6 milliseconds (0.006 seconds) was spent in GC. > 8,394,104 bytes of memory allocated. > > > Thanks, > > /Jon > > > From lnp at healy.washington.dc.us Sun Jun 7 18:28:37 2009 From: lnp at healy.washington.dc.us (Liam Healy) Date: Sun, 7 Jun 2009 21:28:37 -0400 Subject: [Openmcl-devel] LISP & Statistics In-Reply-To: References: Message-ID: <654935030906071828n1938cd1eg16f3dacd86ea17a0@mail.gmail.com> GSLL is an interface to GSL, the GNU scientific library, which includes statistics functions. http://common-lisp.net/project/gsll/ There are other Lisp statistics projects around including a Lisp interface to R. Liam On Sun, Jun 7, 2009 at 7:56 PM, Steve N??ez wrote: > Gentlemen, > > I hope you?ll forgive a question that?s only tangentially related to > OpenMCL... > > I?ve got a project coming up that involves predictive modelling and PMML. > This is an area I have been involved with in the past, but am quite rusty. > It seems that the ?state of the art? is ?R?. It?s an active, up to date > project, with many contributions. In the Lisp side, there?s ?lisp-stat?, > which seems dead. > > I don?t mind learning ?R?, but it?s YAL (Yet Another Language ? when are we > (the industry) going to stop wasting time with this?), but would prefer not > to add the learning curve time required to the project. > > Are there any viable alternatives for doing statistics in Lisp? > > 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 ron at awun.net Sun Jun 7 18:30:26 2009 From: ron at awun.net (Ron Garret) Date: Sun, 7 Jun 2009 18:30:26 -0700 Subject: [Openmcl-devel] Draggable for CCL Message-ID: <8BF2EAB6-DAF3-4087-8E5F-3AC5757A2C02@awun.net> I've ported the draggable demo to CCL. It's built on top of some Lispy wrappers for windows and views that might turn out to be more generally useful infrastructure. Enjoy! FYI, the Cocoa/CCL learning curve seems to be flattening out for me. I did not have a single crash while developing this code. CCL looks more and more like it's ready for prime time. rg -------------- next part -------------- A non-text attachment was scrubbed... Name: draggable.lisp Type: application/octet-stream Size: 7196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: utilities.lisp Type: application/octet-stream Size: 26614 bytes Desc: not available URL: From ralex at cs.colorado.edu Sun Jun 7 23:00:02 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Mon, 8 Jun 2009 00:00:02 -0600 Subject: [Openmcl-devel] Lisp for the 21 century: how to deal with URLs Message-ID: It would be nice if we could bring Lisp into the 21 century by adding some kind of native support for URLs. For instance, with more and more people posting Lisp files by attaching them to emails how about being able to just load them via (load URL)? Chances are you already keep your files in some web accessible repository, e.g., Google Code/ svn At a conceptual level there is a question of how to integrate (or perhaps replace) the existing notion of CL pathnames with URLs. This will cause some headaches but could replace the portable logical pathnames with a long overdue modern approach. At an implementation level, in CCL, one could start by hacking load. If the pathname is a string starting with "http://" then the chance is pretty good that we are dealing with a URL (load "http://xmlisp.googlecode.com/svn/trunk/XMLisp/sources/IDE/specific/Mac%20CCL/anticipat-symbol-complete.lisp ") The file could be downloaded via HTTP, perhaps as temp file, and then loaded the "old" way. Even here there are questions. Should one use CFNetwork? URLDownload looks temptingly simple but depreciated, NSURLDownload hmmmm.... just use TCP streams and make you own HTTP GET, ... so many options. With a bit more work one could do some clever local caching similar to Google Gears. Any suggestions? Alex 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 Sun Jun 7 23:39:53 2009 From: ron at awun.net (Ron Garret) Date: Sun, 7 Jun 2009 23:39:53 -0700 Subject: [Openmcl-devel] Lisp for the 21 century: how to deal with URLs In-Reply-To: References: Message-ID: <39E54007-15C3-4251-9060-9D1709939DC2@awun.net> I like it! (defun nsstr (s) (make-instance 'gui::ns-lisp-string :string s)) ; Really ought to be built-in to CCL (defun load-url (url) (let ((data (make-instance ns:ns-data :with-contents-of-url (#/URLWithString: ns:ns-url (nsstr url)))) (filename (format nil "/tmp/~a" (gensym)))) (#/writeToFile:atomically: data (nsstr filename) #$NO) (load filename))) Implementing "save-url" is going to be trickier though :-) rg On Jun 7, 2009, at 11:00 PM, Alexander Repenning wrote: > It would be nice if we could bring Lisp into the 21 century by adding > some kind of native support for URLs. For instance, with more and more > people posting Lisp files by attaching them to emails how about being > able to just load them via (load URL)? Chances are you already keep > your files in some web accessible repository, e.g., Google Code/ svn > > At a conceptual level there is a question of how to integrate (or > perhaps replace) the existing notion of CL pathnames with URLs. This > will cause some headaches but could replace the portable logical > pathnames with a long overdue modern approach. > > At an implementation level, in CCL, one could start by hacking load. > If the pathname is a string starting with "http://" then the chance is > pretty good that we are dealing with a URL > > (load "http://xmlisp.googlecode.com/svn/trunk/XMLisp/sources/IDE/specific/Mac%20CCL/anticipat-symbol-complete.lisp > ") > > The file could be downloaded via HTTP, perhaps as temp file, and then > loaded the "old" way. Even here there are questions. Should one use > CFNetwork? URLDownload looks temptingly simple but depreciated, > NSURLDownload hmmmm.... just use TCP streams and make you own HTTP > GET, ... so many options. > > With a bit more work one could do some clever local caching similar to > Google Gears. > > Any suggestions? > > 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 From david at lichteblau.com Mon Jun 8 00:12:36 2009 From: david at lichteblau.com (David Lichteblau) Date: Mon, 8 Jun 2009 09:12:36 +0200 Subject: [Openmcl-devel] Lisp for the 21 century: how to deal with URLs In-Reply-To: References: Message-ID: <20090608071236.GA27169@radon> Quoting Alexander Repenning (ralex at cs.colorado.edu): > It would be nice if we could bring Lisp into the 21 century by adding > some kind of native support for URLs. For instance, with more and more > people posting Lisp files by attaching them to emails how about being > able to just load them via (load URL)? Chances are you already keep > your files in some web accessible repository, e.g., Google Code/ svn Scieneer CL has support for URIs as namestrings: http://www.scieneer.com/scl/doc/pathnames.html I haven't used it myself, but Douglas Crosher helped port cxml to Scieneer, and the URI <-> pathname mappings necessitated by XML's use of URIs for entities are certainly implemented very cleanly on SCL. d. From joswig at lisp.de Mon Jun 8 00:54:25 2009 From: joswig at lisp.de (Rainer Joswig) Date: Mon, 8 Jun 2009 09:54:25 +0200 Subject: [Openmcl-devel] Lisp for the 21 century: how to deal with URLs In-Reply-To: References: Message-ID: Am 08.06.2009 um 08:00 schrieb Alexander Repenning: > It would be nice if we could bring Lisp into the 21 century by adding > some kind of native support for URLs. For instance, with more and more > people posting Lisp files by attaching them to emails how about being > able to just load them via (load URL)? Chances are you already keep > your files in some web accessible repository, e.g., Google Code/ svn > > At a conceptual level there is a question of how to integrate (or > perhaps replace) the existing notion of CL pathnames with URLs. This > will cause some headaches but could replace the portable logical > pathnames with a long overdue modern approach. 'logical pathnames' and URLs are really very different things for different purposes. Logical pathnames were invented to make file locations configurable and independent of physical location in groups of computers. If you had URLs as a type of pathnames, it would still make sense to have logical pathnames and now allow pathname translations over URLs. URLs are only a part of the solution. MIME types then are necessary, HTTP traffic, HTTPs, ... > > At an implementation level, in CCL, one could start by hacking load. > If the pathname is a string starting with "http://" then the chance is > pretty good that we are dealing with a URL > > (load "http://xmlisp.googlecode.com/svn/trunk/XMLisp/sources/IDE/specific/Mac%20CCL/anticipat-symbol-complete.lisp > ") I'm not sure 'LOAD' without any security story is more than a hack. But the security problems are clear: * unencrypted traffic can be manipulated easily * DNS names and their resolution can be manipulated * the files in public repositories can be manipulated * proxies can manipulate the traffic they see * CL has no security model, no sandboxes, LOAD executes code without any protection. When you load a file over the web without any security and have the file contents immediately execute (LOAD executes code) - I'd say that's an invitation for all kinds of abuse. > > The file could be downloaded via HTTP, perhaps as temp file, and then > loaded the "old" way. Even here there are questions. Should one use > CFNetwork? URLDownload looks temptingly simple but depreciated, > NSURLDownload hmmmm.... just use TCP streams and make you own HTTP > GET, ... so many options. > > With a bit more work one could do some clever local caching similar to > Google Gears. > > Any suggestions? CL-HTTP does some of that stuff already. I guess other Lisp based solutions, too. It has some simple functionality: COPY-FILES from and to HTTP, getting directory listings, ... The useful stuff for HTTP access is: * opening streams to HTTP resources for reading and writing * copying text and binary data * 'understanding' some types of 'directories' regards, Rainer Joswig > > 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 Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From joswig at lisp.de Mon Jun 8 01:12:03 2009 From: joswig at lisp.de (Rainer Joswig) Date: Mon, 8 Jun 2009 10:12:03 +0200 Subject: [Openmcl-devel] LISP & Statistics In-Reply-To: References: Message-ID: <72E7F36D-AF20-42FC-B642-FD6D59D735EC@lisp.de> Am 08.06.2009 um 01:56 schrieb Steve N??ez: > Gentlemen, > > I hope you?ll forgive a question that?s only tangentially related to > OpenMCL... > > I?ve got a project coming up that involves predictive modelling and > PMML. This is an area I have been involved with in the past, but am > quite rusty. It seems that the ?state of the art? is ?R?. It?s an > active, up to date project, with many contributions. In the Lisp > side, there?s ?lisp-stat?, which seems dead. > > I don?t mind learning ?R?, but it?s YAL (Yet Another Language ? when > are we (the industry) going to stop wasting time with this?), but > would prefer not to add the learning curve time required to the > project. > > Are there any viable alternatives for doing statistics in Lisp? Funny at least one of the authors of R was/is looking into moving to Common Lisp. See the article 'Back to the Future: Lisp as the base for a Statistical Computing System'. http://books.google.com/books?id=8Cf16JkKz30C&pg=PA21&lpg=PA21 Also see these talks: http://www.stat.auckland.ac.nz/~ihaka/?Talks Here is some 'statistics' code for Common Lisp: http://github.com/blindglobe Above also hosts a Common Lisp version of the core of 'lisp-stat'. The CL Directory links to maths libraries: http://www.cl-user.net/asp/tags/11071 Also see the CLIKI page: http://www.cliki.net/Mathematics Regards, Rainer Joswig > > 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 Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpgoldman at sift.info Mon Jun 8 05:41:11 2009 From: rpgoldman at sift.info (Robert Goldman) Date: Mon, 08 Jun 2009 07:41:11 -0500 Subject: [Openmcl-devel] LISP & Statistics In-Reply-To: <72E7F36D-AF20-42FC-B642-FD6D59D735EC@lisp.de> References: <72E7F36D-AF20-42FC-B642-FD6D59D735EC@lisp.de> Message-ID: <4A2D06E7.4020705@sift.info> Rainer Joswig wrote: > > Am 08.06.2009 um 01:56 schrieb Steve N??ez: > >> Gentlemen, >> >> I hope you?ll forgive a question that?s only tangentially related to >> OpenMCL... >> >> I?ve got a project coming up that involves predictive modelling and >> PMML. This is an area I have been involved with in the past, but am >> quite rusty. It seems that the ?state of the art? is ?R?. It?s an >> active, up to date project, with many contributions. In the Lisp side, >> there?s ?lisp-stat?, which seems dead. >> >> I don?t mind learning ?R?, but it?s YAL (Yet Another Language ? when >> are we (the industry) going to stop wasting time with this?), but >> would prefer not to add the learning curve time required to the project. >> >> Are there any viable alternatives for doing statistics in Lisp? > > Funny at least one of the authors of R was/is looking into moving to > Common Lisp. > > See the article 'Back to the Future: Lisp as the base for a Statistical > Computing System'. > > http://books.google.com/books?id=8Cf16JkKz30C&pg=PA21&lpg=PA21 > > > Also see these talks: http://www.stat.auckland.ac.nz/~ihaka/?Talks > > Here is some 'statistics' code for Common Lisp: > > http://github.com/blindglobe > > Above also hosts a Common Lisp version of the core of 'lisp-stat'. > > The CL Directory links to maths libraries: > http://www.cl-user.net/asp/tags/11071 > > Also see the CLIKI page: > > http://www.cliki.net/Mathematics A long time ago I used Larry Hunter's bio statistics CL code. But I don't know that it was really aimed at the same task as yours. See http://compbio.uchsc.edu/Hunter_lab/Hunter/cl-statistics.lisp > > > Regards, > > Rainer Joswig > > > >> >> 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 > > 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 From taoufik.dachraoui at wanadoo.fr Mon Jun 8 07:10:55 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Mon, 8 Jun 2009 16:10:55 +0200 Subject: [Openmcl-devel] difference between CCL and COMMON-LISP packages Message-ID: <2966E668-4E63-4110-8239-0DBC0A9917D6@wanadoo.fr> Hi What is the diff webtween CCL and COMMON-LISP packages; they have the exact same symbols. Kind regards -Taoufik From j-anthony at comcast.net Mon Jun 8 07:41:22 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Mon, 08 Jun 2009 10:41:22 -0400 Subject: [Openmcl-devel] Binary IO... In-Reply-To: References: <1244408197.2420.175.camel@sirius> Message-ID: <1244472082.2420.187.camel@sirius> Hmmmm, forgot about the GC again (I suppose that is as much a good thing as a bad thing - forgetting about it - or more exactly, what it does - is sort of the point...) I think your analysis is exactly right and the behavior pretty much exactly what is needed in the absence of any "tuning". On the subject of which - On Sun, 2009-06-07 at 18:04 -0600, Gary Byers wrote: > A stream's buffer is nailed down in foreign memory, so we can safely > read from and write to it without worrying about the GC moving it > around ... > There are ways to inhibit the GC, obtain the (absolute, non-relocatable) > address of the vector, and do I/O directly (bypassing the buffer). Whether > that's better overall depends on what the cost of inhibiting the GC would > be (which in turn depends on what kind of consing activitiy is going on > in other threads.) It is straight forward to "pin" a vector like this in ACL, when creating it, by essentially telling the memory/GC machinery to just place it (on creation) in an unmoving tenured area, and thereby be assured that the GC won't be moving it. You don't need to "inhibit" the GC after it is created (and pinned). At which point, you effectively have the "nailed down vector", as you say. You indicate something like this is doable in CCL, any info or pointers for that? I'm guessing (well, hoping) that any GC inhibition here will only be upfront temporary as well. Thanks again! /Jon From stassats at gmail.com Mon Jun 8 07:19:21 2009 From: stassats at gmail.com (Stas Boukarev) Date: Mon, 08 Jun 2009 18:19:21 +0400 Subject: [Openmcl-devel] difference between CCL and COMMON-LISP packages In-Reply-To: <2966E668-4E63-4110-8239-0DBC0A9917D6@wanadoo.fr> (Taoufik Dachraoui's message of "Mon, 8 Jun 2009 16:10:55 +0200") References: <2966E668-4E63-4110-8239-0DBC0A9917D6@wanadoo.fr> Message-ID: <87hbyqn6za.fsf@gmail.com> Taoufik Dachraoui writes: > Hi > > What is the diff webtween CCL and COMMON-LISP packages; they have the > exact same symbols. > No, they're not: (loop for symbol being the symbol in :ccl count 1) => 16641 (loop for symbol being the symbol in :cl count 1) => 978 COMMON-LISP package is defined by the standard and exports exactly defined set of symbols. CCL is an internal package specific to Clozure CL. -- With best regards, Stas. From joswig at lisp.de Mon Jun 8 07:51:47 2009 From: joswig at lisp.de (Rainer Joswig) Date: Mon, 8 Jun 2009 16:51:47 +0200 Subject: [Openmcl-devel] difference between CCL and COMMON-LISP packages In-Reply-To: <87hbyqn6za.fsf@gmail.com> References: <2966E668-4E63-4110-8239-0DBC0A9917D6@wanadoo.fr> <87hbyqn6za.fsf@gmail.com> Message-ID: CL and COMMON-LISP are names for the same package. CCL is a different package. ? (describe (find-package "CCL")) # Type: PACKAGE Class: # Internal Symbols: 15766 External Symbols: 592 PKG.ITAB: (#(CCL::FFI-ARG-TYPE CCL::$FBITEMBEDDEDLAP CCL::LOCAL-BLOCK CCL::*NX-IGNORE-IF-UNUSED* CCL::FLAGS-SANS-WEAK CCL::*EQL-SPECIALIZER-CLASS* CCL::PPRINT-TAB-NOT-PRETTY 0 CCL::PARENT CCL::CLEANUP-LAB CCL::STREAM-SURROUNDING- CHARACTERS CCL::FFI-UNION-P CCL::OP3-FUN CCL::OUT-LOCK CCL::ERR-NUM CCL::%STAT-VALUES CCL::VECT-SUBTYPE CCL::PRIMARY-OWNER- NOTIFY 0 CCL::%COPY-DOUBLE-FLOAT ...) 16265 . 17363) PKG.ETAB: (#(ADVISE *BREAK-LOOP-WHEN-UNINTERRUPTABLE* WITH-INTERRUPTS- ENABLED STREAM-READ-LINE 0 0 0 0 CANCEL 0 APPLYHOOK *LISTENER- INDENT* GET-SETF-METHOD-MULTIPLE-VALUE PROCESS-SUSPEND-COUNT 0 0 0 *.LISP-PATHNAME* WITH-TERMINAL-INPUT METHOD-LAMBDA- LIST ...) 592 . 673) PKG.USED: (#) PKG.USED-BY: (# # #) PKG.NAMES: ("CCL") PKG.SHADOWED: NIL PKG.LOCK: # PKG.INTERN-HOOK: NIL ? (describe (find-package "CL")) # Type: PACKAGE Class: # Internal Symbols: 0 External Symbols: 978 PKG.ITAB: (#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...) 0 . 36) PKG.ETAB: (#(DEFSETF NUMBER 0 &REST ABORT SUBSTITUTE *PRINT-LENGTH* DEFVAR ECHO-STREAM-INPUT-STREAM PROGV *READ-DEFAULT-FLOAT- FORMAT* GETHASH STRUCTURE-CLASS UNBOUND-SLOT COMPILER-MACRO SUBSTITUTE- IF COERCE STRING-TRIM BIT-ORC2 0 ...) 978 . 1009) PKG.USED: NIL PKG.USED-BY: (# # # # # # # # # # # # # # # # # #) PKG.NAMES: ("COMMON-LISP" "CL") PKG.SHADOWED: NIL PKG.LOCK: # PKG.INTERN-HOOK: NIL Am 08.06.2009 um 16:19 schrieb Stas Boukarev: > Taoufik Dachraoui writes: > >> Hi >> >> What is the diff webtween CCL and COMMON-LISP packages; they have the >> exact same symbols. >> > No, they're not: > (loop for symbol being the symbol in :ccl count 1) => 16641 > (loop for symbol being the symbol in :cl count 1) => 978 > > COMMON-LISP package is defined by the standard and exports exactly > defined set of symbols. CCL is an internal package specific to > Clozure CL. > > -- > With best regards, Stas. > _______________________________________________ > 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 From dlw at itasoftware.com Mon Jun 8 08:08:10 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Mon, 08 Jun 2009 11:08:10 -0400 Subject: [Openmcl-devel] Lisp for the 21 century: how to deal with URLs In-Reply-To: References: Message-ID: <4A2D295A.4030502@itasoftware.com> Alex, The main question is: are there things that are important to do with URL's that can't be provided with a library? Do we really want functions that take pathnames to also take URL's? Even if we do, is that particularly important to have? Suppose we had a library called "URL", in package "url", implementing an abstract class called "url". We define generic functions such as: (defgeneric load-program (url) "The argument is an object of type url:url. Get all the characters from the resource identified by URL, and read and evaluate each one. If such-and-such happens, signal condition such-and-such; if such-and-such... etc etc Otherwise it has succeed, and returns whatever.") Then anyone can make an url:url, and call url:load-program. (I'm not sure that's the very best possible name but it'll do for purposes of this email.) If you want to load a program that's stored in a file, you can use the "file" scheme [Note: "scheme" means the thing at the beginning of the URL, before the colon]. We would either define the "file" scheme to be interpreted the same way that Lisp pathname functions interpret strings, or else we might have to make up a new scheme for that, depending on the exact specs of the "file" scheme in the URL RFC (I'm too lazy to check right now). Then you could use load-program with logical pathnames or any other kind of Lisp pathname. As Rainer said, logical pathnames are solving a different problem, so we would not want to get rid of them. At the implementation level, there would be a subclass of url:url for each scheme, and a defined way for an application/library to add support for a new scheme, e.g. (url:add-scheme "svn" 'svn:svn-url) where "svn"" is a Lisp package that knows about Subversion, and "svn-url" is a subclass of url:url defined in the svn package. The svn package then does (defmethod url:load-program (u (svn:svn-url)) ...) which knows how to access an svn repository, for example. > > At an implementation level, in CCL, one could start by hacking load. > If the pathname is a string starting with "http://" then the chance is > pretty good I'm not a big fan of this kind of heuristic, that depends on chances being pretty good. I prefer nice, clean, deterministic, simple contracts. > The file could be downloaded via HTTP, perhaps as temp file, and then > loaded the "old" way. Yes, you could either stream it or buffer it; that's entirely an implementation question, having nothing to do with the "in the language" vs. "in a library" question. From a practical point of view, doing it as a library would let it be portable, so that we would not have to get all eleven CL implementations to (a) agree on the spec and (b) release new versions. Roger Corman, for example, doesn't have anybody to help him, and he doesn't have a lot of time to work on his implementation. I suspect some of them others are in similar positions. (Note that in real life, you'd probably want to talk about "uri"'s rather than "url"'s, and you'd probably want to use the existing "puri" library by Kevin Rosenberg, and so on. The above is just conceptual.) -- Dan > > > 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 raffaelcavallaro at mac.com Mon Jun 8 09:20:41 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Mon, 08 Jun 2009 12:20:41 -0400 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL Message-ID: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> This is under 10.5.7. Ron, I ran into this trying out your draggable code. 64-bit: ? ns::ns-tracking-area # 32-bit: ? ns::ns-tracking-area > Error: Unbound variable: NS:NS-TRACKING-AREA I realize that NSTrackingArea is available in 10.5 and later only, but people will be using the 32-bit CCL under 10.5, if only because there are things that don't work under the 64-bit runtime (QuickTime plug-in in WebKit for example). warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From ron at awun.net Mon Jun 8 10:08:02 2009 From: ron at awun.net (Ron Garret) Date: Mon, 8 Jun 2009 10:08:02 -0700 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> Message-ID: <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> On Jun 8, 2009, at 9:20 AM, Raffael Cavallaro wrote: > This is under 10.5.7. Ron, I ran into this trying out your draggable > code. > > 64-bit: > ? ns::ns-tracking-area > # > > 32-bit: > ? ns::ns-tracking-area >> Error: Unbound variable: NS:NS-TRACKING-AREA > > I realize that NSTrackingArea is available in 10.5 and later only, but > people will be using the 32-bit CCL under 10.5, if only because there > are things that don't work under the 64-bit runtime (QuickTime plug-in > in WebKit for example). Or PDFViews :-) I think this is just a bug in the 32-bit CCL interfaces. It works in 32-bit objc. I've filed a ticket. But if someone can point me to a description of how to generate mouse- enter and mouse-leave events in <10.5 I'll add code to support that as well. rg From arthur.cater at ucd.ie Mon Jun 8 11:32:36 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Mon, 08 Jun 2009 19:32:36 +0100 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> Message-ID: Use?#/addTrackingRect:owner:userData:assumeInside: with - the view - its #/bounds - a ns-object as target - ccl::+null-ptr+ - #$NO Then (objc:define-objc-method ((:void :mouse-entered (:id event)) ) ...) likewise :mouse-exited and :mouse-move Arthur ----- Original Message ----- From: Ron Garret Date: Monday, June 8, 2009 6:12 pm Subject: Re: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL To: Raffael Cavallaro Cc: openmcl-devel > > On Jun 8, 2009, at 9:20 AM, Raffael Cavallaro wrote: > > > This is under 10.5.7. Ron, I ran into this trying out your draggable > > code. > > > > 64-bit: > > ? ns::ns-tracking-area > > # > > > > 32-bit: > > ? ns::ns-tracking-area > >> Error: Unbound variable: NS:NS-TRACKING-AREA > > > > I realize that NSTrackingArea is available in 10.5 and later > only, but > > people will be using the 32-bit CCL under 10.5, if only > because there > > are things that don't work under the 64-bit runtime (QuickTime > plug-in > > in WebKit for example). > > Or PDFViews :-) > > I think this is just a bug in the 32-bit CCL interfaces.? > It works in? > 32-bit objc.? I've filed a ticket. > > But if someone can point me to a description of how to generate > mouse- > enter and mouse-leave events in <10.5 I'll add code to > support that as? > well. > > 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 ron at awun.net Mon Jun 8 17:44:32 2009 From: ron at awun.net (Ron Garret) Date: Mon, 8 Jun 2009 17:44:32 -0700 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> Message-ID: [This may be a repeat, but the original never showed up in my inbox. Also, there's an update at the end.] On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: > Use #/addTrackingRect:owner:userData:assumeInside: with > - the view > - its #/bounds > - a ns-object as target > - ccl::+null-ptr+ > - #$NO > > Then > (objc:define-objc-method ((:void :mouse-entered (:id event)) > ) ...) > > likewise :mouse-exited and :mouse-move Thanks! Updated version enclosed. This has been tested in 32-bit CCL, and should now work on Tiger as well. This version also fixes a bug whereby testviews did not get properly re-initialized to add a tracker when the class got redefined. I was using an initialize-instance :after method when I should have been using shared initialize -- I think. There is still a subtle bug which I can't figure out. When you add a highlighted mixin to an existing testview instance, you have to click on it once before it starts to highlight itself. I have no idea why this is happening. I may not be using shared-initialize properly. Maybe a CLOS wizard can help with some advice on the proper way to do this. UPDATE: it turns out that the reason for this is that calling shared- initialize is done lazily. So until there is an interaction with the updated object it doesn't get re-initialized, so add-tracker doesn't get called, so the event that would normally cause the interaction never gets received. Makes an interesting little puzzle. rg -------------- next part -------------- A non-text attachment was scrubbed... Name: draggable.lisp Type: application/octet-stream Size: 7981 bytes Desc: not available URL: -------------- next part -------------- From ron at awun.net Mon Jun 8 12:29:22 2009 From: ron at awun.net (Ron Garret) Date: Mon, 8 Jun 2009 12:29:22 -0700 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> Message-ID: <436DB8C9-CE32-4EF6-9D10-5976F5DAA0B4@awun.net> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: > Use #/addTrackingRect:owner:userData:assumeInside: with > - the view > - its #/bounds > - a ns-object as target > - ccl::+null-ptr+ > - #$NO > > Then > (objc:define-objc-method ((:void :mouse-entered (:id event)) > ) ...) > > likewise :mouse-exited and :mouse-move Thanks! Updated version enclosed. This has been tested in 32-bit CCL, and should now work on Tiger as well. This version also fixes a bug whereby testviews did not get properly re-initialized to add a tracker when the class got redefined. I was using an initialize-instance :after method when I should have been using shared initialize -- I think. There is still a subtle bug which I can't figure out. When you add a highlighted mixin to an existing testview instance, you have to click on it once before it starts to highlight itself. I have no idea why this is happening. I may not be using shared-initialize properly. Maybe a CLOS wizard can help with some advice on the proper way to do this. rg -------------- next part -------------- A non-text attachment was scrubbed... Name: draggable.lisp Type: application/octet-stream Size: 7981 bytes Desc: not available URL: -------------- next part -------------- From ron at awun.net Mon Jun 8 22:02:24 2009 From: ron at awun.net (Ron Garret) Date: Mon, 8 Jun 2009 22:02:24 -0700 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> Message-ID: <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> Try updating. The 1.3 branch is currently at verison r12153M. It works for me on that version. rg On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: > > > using Clozure Common Lisp Version 1.3-r12088M (DarwinX8664) > > > On executing the add-subview example form in draggable.lisp > > I get: > > *** Error in event process: unknown arg spec :REGISTERS > > (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> > #) 85 > (#:G5085) > #:G5085: # > > #:COMPILER-VAR: (NIL) > #:G5082: # > > (442C10) : 1 (SIGNAL #) 981 > (CONDITION &REST CCL::ARGS) > CONDITION: # > CCL::ARGS: NIL > > CCL::%HANDLERS%: ((ERROR) (ERROR)) > CCL::TAG: # > CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > CCL::FN: # drawRect:]|) #x493DBF> > > (442C68) : 2 (%ERROR # (:REGISTERS) > 558482) 117 > (CONDITION CCL::ARGS CCL::ERROR-POINTER) > CONDITION: # > CCL::ARGS: (:REGISTERS) > CCL::ERROR-POINTER: 558482 > > > > (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS # (#x170192C0)> :ADDRESS # "Lisp Rules!" (#x137CD2F0)> :ADDRESS # #x7FFF82F59600> :ADDRESS # NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > fobj=0x170178c0, spc=12.00"; > } (#x17019E50)> :VOID) 701 > (CCL::ENTRY &REST CCL::SPECS-AND-VALS) > CCL::ENTRY: 140735390423728 > CCL::SPECS-AND-VALS: (:REGISTERS # 0x170192c0> (#x170192C0)> :ADDRESS # Rules!" (#x137CD2F0)> :ADDRESS ...) > > CCL::LEN: 9 > CCL::TOTAL-WORDS: 0 > CCL::RESULT-SPEC: :VOID > CCL::NARGS: 4 > CCL::N-FP-ARGS: 0 > CCL::I: 0 > CCL::SPECS: (:REGISTERS # > (#x170192C0)> :ADDRESS # Rules!" (#x137CD2F0)> :ADDRESS ...) > CCL::SPEC: :REGISTERS > > (442CF8) : 4 (FUNCALL #'# # CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- > SELECTOR :NAME "sizeWithAttributes:" :%SEL # #x7FFF82F59600>) # NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > fobj=0x170178c0, spc=12.00"; > } (#x17019E50)>) 805 > (#:G3751 #:G3752 CCL::ARG0) > #:G3751: # > #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL > #) > CCL::ARG0: # NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > fobj=0x170178c0, spc=12.00"; > } (#x17019E50)> > > #:G3753: # [gcable] (#x17029190) > #:G3756: # > #:G3755: # (#x170192C0)> > > (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE > (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> # NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > fobj=0x170178c0, spc=12.00"; > } (#x17019E50)>) 501 > (CCL::RECEIVER &REST CCL::ARGS) > CCL::RECEIVER: # > CCL::ARGS: (# NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > fobj=0x170178c0, spc=12.00"; > } (#x17019E50)>) > > CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : > %SEL #) > FUNCTION: # > > (442D78) : 6 (FUNCALL #'#<# VIEW)>> # # (#x7FFF5FBFD370) #x3000420F928D>) 229 > (V &OPTIONAL RECT) > V: # > RECT: # > > > > (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> > 17591849974380) 981 > (#:G5081) > #:G5081: 17591849974380 > > #:G5088: # > #:G5082: # > #:COMPILER-VAR: (NIL) > #:G5087: # drawRect:]|) #x493DBF> > #:G5089: (CONDITION #) > CCL::%HANDLERS%: ((CONDITION #) (ERROR)) > SELF: # (#x170221C0)> > _CMD: # > RECT: # > > (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 > (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > CCL::INDEX: 277 > CCL::ARGS-PTR-FIXNUM: 17591849974380 > > CCL::LISP-FUNCTION: # (Non-Global) #x300041F007BF> > WITHOUT-INTERRUPTS: NIL > CCL::*CALLBACK-TRACE-P*: NIL > > (442F08) : 10 (FUNCALL #'# # APPLICATION (#x1C3580)> #S(CCL::OBJC- > SELECTOR :NAME "run" :%SEL #)) 205 > (#:G3072 #:G3073) > #:G3072: # (#x1C3580)> > #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF82FFFD68>) > > > > (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE > (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # APPLICATION (#x1C3580)>) 501 > (CCL::RECEIVER &REST CCL::ARGS) > CCL::RECEIVER: # > (#x1C3580)> > CCL::ARGS: NIL > > CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # Pointer #x7FFF82FFFD68>) > FUNCTION: # > > (442F68) : 12 (EVENT-LOOP NIL) 413 > (&OPTIONAL GUI::END-TEST) > GUI::END-TEST: NIL > > GUI::APP: # (#x1C3580)> > *BREAK-ON-ERRORS*: NIL > #:G163537: (ERROR) > CCL::%HANDLERS%: ((ERROR)) > GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (# #x3000420F8DBD>) > > > > > > > > Am 09.06.2009 um 02:44 schrieb Ron Garret: > >> [This may be a repeat, but the original never showed up in my >> inbox. Also, there's an update at the end.] >> >> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: >> >>> Use #/addTrackingRect:owner:userData:assumeInside: with >>> - the view >>> - its #/bounds >>> - a ns-object as target >>> - ccl::+null-ptr+ >>> - #$NO >>> >>> Then >>> (objc:define-objc-method ((:void :mouse-entered (:id event)) >>> ) ...) >>> >>> likewise :mouse-exited and :mouse-move >> >> Thanks! Updated version enclosed. This has been tested in 32-bit >> CCL, and should now work on Tiger as well. >> >> This version also fixes a bug whereby testviews did not get >> properly re-initialized to add a tracker when the class got >> redefined. I was using an initialize-instance :after method when I >> should have been using shared initialize -- I think. There is >> still a subtle bug which I can't figure out. When you add a >> highlighted mixin to an existing testview instance, you have to >> click on it once before it starts to highlight itself. I have no >> idea why this is happening. I may not be using shared-initialize >> properly. Maybe a CLOS wizard can help with some advice on the >> proper way to do this. >> >> UPDATE: it turns out that the reason for this is that calling >> shared-initialize is done lazily. So until there is an interaction >> with the updated object it doesn't get re-initialized, so add- >> tracker doesn't get called, so the event that would normally cause >> the interaction never gets received. Makes an interesting little >> puzzle. >> >> rg >> >> >> _______________________________________________ >> 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 > > From joswig at lisp.de Mon Jun 8 21:35:13 2009 From: joswig at lisp.de (Rainer Joswig) Date: Tue, 9 Jun 2009 06:35:13 +0200 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> Message-ID: using Clozure Common Lisp Version 1.3-r12088M (DarwinX8664) On executing the add-subview example form in draggable.lisp I get: *** Error in event process: unknown arg spec :REGISTERS (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> #) 85 (#:G5085) #:G5085: # #:COMPILER-VAR: (NIL) #:G5082: # (442C10) : 1 (SIGNAL #) 981 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (ERROR)) CCL::TAG: # CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* CCL::FN: # (442C68) : 2 (%ERROR # (:REGISTERS) 558482) 117 (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: (:REGISTERS) CCL::ERROR-POINTER: 558482 (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS # (#x170192C0)> :ADDRESS # :ADDRESS # :ADDRESS # :VOID) 701 (CCL::ENTRY &REST CCL::SPECS-AND-VALS) CCL::ENTRY: 140735390423728 CCL::SPECS-AND-VALS: (:REGISTERS # (#x170192C0)> :ADDRESS # :ADDRESS ...) CCL::LEN: 9 CCL::TOTAL-WORDS: 0 CCL::RESULT-SPEC: :VOID CCL::NARGS: 4 CCL::N-FP-ARGS: 0 CCL::I: 0 CCL::SPECS: (:REGISTERS # (#x170192C0)> :ADDRESS # :ADDRESS ...) CCL::SPEC: :REGISTERS (442CF8) : 4 (FUNCALL #'# # #S(CCL::OBJC- SELECTOR :NAME "sizeWithAttributes:" :%SEL #) #) 805 (#:G3751 #:G3752 CCL::ARG0) #:G3751: # #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL #) CCL::ARG0: # #:G3753: # [gcable] (#x17029190) #:G3756: # #:G3755: # (#x170192C0)> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # #) 501 (CCL::RECEIVER &REST CCL::ARGS) CCL::RECEIVER: # CCL::ARGS: (#) CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : %SEL #) FUNCTION: # (442D78) : 6 (FUNCALL #'#<#> # #) 229 (V &OPTIONAL RECT) V: # RECT: # (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> 17591849974380) 981 (#:G5081) #:G5081: 17591849974380 #:G5088: # #:G5082: # #:COMPILER-VAR: (NIL) #:G5087: # #:G5089: (CONDITION #) CCL::%HANDLERS%: ((CONDITION #) (ERROR)) SELF: # (#x170221C0)> _CMD: # RECT: # (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 (CCL::INDEX CCL::ARGS-PTR-FIXNUM) CCL::INDEX: 277 CCL::ARGS-PTR-FIXNUM: 17591849974380 CCL::LISP-FUNCTION: # WITHOUT-INTERRUPTS: NIL CCL::*CALLBACK-TRACE-P*: NIL (442F08) : 10 (FUNCALL #'# # (#x1C3580)> #S(CCL::OBJC- SELECTOR :NAME "run" :%SEL #)) 205 (#:G3072 #:G3073) #:G3072: # (#x1C3580)> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #) (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> # (#x1C3580)>) 501 (CCL::RECEIVER &REST CCL::ARGS) CCL::RECEIVER: # (#x1C3580)> 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: # (#x1C3580)> *BREAK-ON-ERRORS*: NIL #:G163537: (ERROR) CCL::%HANDLERS%: ((ERROR)) GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#) Am 09.06.2009 um 02:44 schrieb Ron Garret: > [This may be a repeat, but the original never showed up in my > inbox. Also, there's an update at the end.] > > On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: > >> Use #/addTrackingRect:owner:userData:assumeInside: with >> - the view >> - its #/bounds >> - a ns-object as target >> - ccl::+null-ptr+ >> - #$NO >> >> Then >> (objc:define-objc-method ((:void :mouse-entered (:id event)) >> ) ...) >> >> likewise :mouse-exited and :mouse-move > > Thanks! Updated version enclosed. This has been tested in 32-bit > CCL, and should now work on Tiger as well. > > This version also fixes a bug whereby testviews did not get properly > re-initialized to add a tracker when the class got redefined. I was > using an initialize-instance :after method when I should have been > using shared initialize -- I think. There is still a subtle bug > which I can't figure out. When you add a highlighted mixin to an > existing testview instance, you have to click on it once before it > starts to highlight itself. I have no idea why this is happening. > I may not be using shared-initialize properly. Maybe a CLOS wizard > can help with some advice on the proper way to do this. > > UPDATE: it turns out that the reason for this is that calling shared- > initialize is done lazily. So until there is an interaction with > the updated object it doesn't get re-initialized, so add-tracker > doesn't get called, so the event that would normally cause the > interaction never gets received. Makes an interesting little puzzle. > > rg > > > _______________________________________________ > 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 From joswig at lisp.de Tue Jun 9 01:16:42 2009 From: joswig at lisp.de (Rainer Joswig) Date: Tue, 9 Jun 2009 10:16:42 +0200 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> Message-ID: Same error in Clozure Common Lisp Version 1.3-r12235M (DarwinX8664). Mac OS X 10.5.7 on 64bit Intel... *** Error in event process: unknown arg spec :REGISTERS (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> #) 85 (#:G2965) #:G2965: # #:COMPILER-VAR: (NIL) #:G2962: # (442C10) : 1 (SIGNAL #) 981 (CONDITION &REST CCL::ARGS) CONDITION: # CCL::ARGS: NIL CCL::%HANDLERS%: ((ERROR) (ERROR)) CCL::TAG: # CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* CCL::FN: # (442C68) : 2 (%ERROR # (:REGISTERS) 558482) 117 (CONDITION CCL::ARGS CCL::ERROR-POINTER) CONDITION: # CCL::ARGS: (:REGISTERS) CCL::ERROR-POINTER: 558482 ... Regards, Rainer Joswig Am 09.06.2009 um 07:02 schrieb Ron Garret: > Try updating. The 1.3 branch is currently at verison r12153M. It > works for me on that version. > > rg > > On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: > >> >> >> using Clozure Common Lisp Version 1.3-r12088M (DarwinX8664) >> >> >> On executing the add-subview example form in draggable.lisp >> >> I get: >> >> *** Error in event process: unknown arg spec :REGISTERS >> >> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >> #) 85 >> (#:G5085) >> #:G5085: # >> >> #:COMPILER-VAR: (NIL) >> #:G5082: # >> >> (442C10) : 1 (SIGNAL #) 981 >> (CONDITION &REST CCL::ARGS) >> CONDITION: # >> CCL::ARGS: NIL >> >> CCL::%HANDLERS%: ((ERROR) (ERROR)) >> CCL::TAG: # >> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >> CCL::FN: #> drawRect:]|) #x493DBF> >> >> (442C68) : 2 (%ERROR # (:REGISTERS) >> 558482) 117 >> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >> CONDITION: # >> CCL::ARGS: (:REGISTERS) >> CCL::ERROR-POINTER: 558482 >> >> >> >> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS #> (#x170192C0)> :ADDRESS #> "Lisp Rules!" (#x137CD2F0)> :ADDRESS #> #x7FFF82F59600> :ADDRESS #> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >> fobj=0x170178c0, spc=12.00"; >> } (#x17019E50)> :VOID) 701 >> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) >> CCL::ENTRY: 140735390423728 >> CCL::SPECS-AND-VALS: (:REGISTERS #> 0x170192c0> (#x170192C0)> :ADDRESS #> Rules!" (#x137CD2F0)> :ADDRESS ...) >> >> CCL::LEN: 9 >> CCL::TOTAL-WORDS: 0 >> CCL::RESULT-SPEC: :VOID >> CCL::NARGS: 4 >> CCL::N-FP-ARGS: 0 >> CCL::I: 0 >> CCL::SPECS: (:REGISTERS # >> (#x170192C0)> :ADDRESS #> Rules!" (#x137CD2F0)> :ADDRESS ...) >> CCL::SPEC: :REGISTERS >> >> (442CF8) : 4 (FUNCALL #'# #> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- >> SELECTOR :NAME "sizeWithAttributes:" :%SEL #> #x7FFF82F59600>) #> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >> fobj=0x170178c0, spc=12.00"; >> } (#x17019E50)>) 805 >> (#:G3751 #:G3752 CCL::ARG0) >> #:G3751: # >> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL >> #) >> CCL::ARG0: #> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >> fobj=0x170178c0, spc=12.00"; >> } (#x17019E50)> >> >> #:G3753: # [gcable] (#x17029190) >> #:G3756: # >> #:G3755: # (#x170192C0)> >> >> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >> fobj=0x170178c0, spc=12.00"; >> } (#x17019E50)>) 501 >> (CCL::RECEIVER &REST CCL::ARGS) >> CCL::RECEIVER: # >> CCL::ARGS: (#> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >> fobj=0x170178c0, spc=12.00"; >> } (#x17019E50)>) >> >> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : >> %SEL #) >> FUNCTION: # >> >> (442D78) : 6 (FUNCALL #'#<#> (TEXT-VIEW)>> # #> (#x7FFF5FBFD370) #x3000420F928D>) 229 >> (V &OPTIONAL RECT) >> V: # >> RECT: # >> >> >> >> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> >> 17591849974380) 981 >> (#:G5081) >> #:G5081: 17591849974380 >> >> #:G5088: # >> #:G5082: # >> #:COMPILER-VAR: (NIL) >> #:G5087: #> drawRect:]|) #x493DBF> >> #:G5089: (CONDITION #) >> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >> SELF: # (#x170221C0)> >> _CMD: # >> RECT: # >> >> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 >> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >> CCL::INDEX: 277 >> CCL::ARGS-PTR-FIXNUM: 17591849974380 >> >> CCL::LISP-FUNCTION: #> (Non-Global) #x300041F007BF> >> WITHOUT-INTERRUPTS: NIL >> CCL::*CALLBACK-TRACE-P*: NIL >> >> (442F08) : 10 (FUNCALL #'# >> # (#x1C3580)> >> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #> #x7FFF82FFFD68>)) 205 >> (#:G3072 #:G3073) >> #:G3072: # (#x1C3580)> >> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #> Pointer #x7FFF82FFFD68>) >> >> >> >> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #> APPLICATION (#x1C3580)>) 501 >> (CCL::RECEIVER &REST CCL::ARGS) >> CCL::RECEIVER: # >> (#x1C3580)> >> CCL::ARGS: NIL >> >> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #> Pointer #x7FFF82FFFD68>) >> FUNCTION: # >> >> (442F68) : 12 (EVENT-LOOP NIL) 413 >> (&OPTIONAL GUI::END-TEST) >> GUI::END-TEST: NIL >> >> GUI::APP: # (#x1C3580)> >> *BREAK-ON-ERRORS*: NIL >> #:G163537: (ERROR) >> CCL::%HANDLERS%: ((ERROR)) >> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#> #x3000420F8DBD>) >> >> >> >> >> >> >> >> Am 09.06.2009 um 02:44 schrieb Ron Garret: >> >>> [This may be a repeat, but the original never showed up in my >>> inbox. Also, there's an update at the end.] >>> >>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: >>> >>>> Use #/addTrackingRect:owner:userData:assumeInside: with >>>> - the view >>>> - its #/bounds >>>> - a ns-object as target >>>> - ccl::+null-ptr+ >>>> - #$NO >>>> >>>> Then >>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) >>>> ) ...) >>>> >>>> likewise :mouse-exited and :mouse-move >>> >>> Thanks! Updated version enclosed. This has been tested in 32-bit >>> CCL, and should now work on Tiger as well. >>> >>> This version also fixes a bug whereby testviews did not get >>> properly re-initialized to add a tracker when the class got >>> redefined. I was using an initialize-instance :after method when >>> I should have been using shared initialize -- I think. There is >>> still a subtle bug which I can't figure out. When you add a >>> highlighted mixin to an existing testview instance, you have to >>> click on it once before it starts to highlight itself. I have no >>> idea why this is happening. I may not be using shared-initialize >>> properly. Maybe a CLOS wizard can help with some advice on the >>> proper way to do this. >>> >>> UPDATE: it turns out that the reason for this is that calling >>> shared-initialize is done lazily. So until there is an >>> interaction with the updated object it doesn't get re-initialized, >>> so add-tracker doesn't get called, so the event that would >>> normally cause the interaction never gets received. Makes an >>> interesting little puzzle. >>> >>> rg >>> >>> >>> _______________________________________________ >>> 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 >> >> Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de From gb at clozure.com Tue Jun 9 04:32:13 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 9 Jun 2009 05:32:13 -0600 (MDT) Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> Message-ID: The bug's somewhat tersesly described in: It's still open, though the code in the trunk version of the IDE that was exposing/triggering the problem has been changed. That code can cause the IDE to start up with ;;;; see CLtL2; DECLARATION-INFORMATION didn't make it into ANSI CL ? (ccl:declaration-information 'optimize nil) ((SPEED 0) (SAFETY 3) (COMPILATION-SPEED 0) (SPACE 0) (DEBUG 3)) This combination of OPTIMIZE settings causes some rarely-executed code to be executed, and the real bug is in that code. (Of course, this should just have the effect of making the code as slow, bloated, and stupid as possible, but it incidentally exposes a bug.) Untile the real bug is if fixed, you can work around the problem by doing: ? (declaim (optimize (speed 1) (space 1) (safety 1) (debug 1) (compilation-speed 1))) on startup. On Tue, 9 Jun 2009, Rainer Joswig wrote: > Same error in Clozure Common Lisp Version 1.3-r12235M (DarwinX8664). > > Mac OS X 10.5.7 on 64bit Intel... > > > *** Error in event process: unknown arg spec :REGISTERS > > (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> > #) 85 > (#:G2965) > #:G2965: # > > #:COMPILER-VAR: (NIL) > #:G2962: # > > (442C10) : 1 (SIGNAL #) 981 > (CONDITION &REST CCL::ARGS) > CONDITION: # > CCL::ARGS: NIL > > CCL::%HANDLERS%: ((ERROR) (ERROR)) > CCL::TAG: # > CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > CCL::FN: # drawRect:]|) #x493DBF> > > (442C68) : 2 (%ERROR # (:REGISTERS) > 558482) 117 > (CONDITION CCL::ARGS CCL::ERROR-POINTER) > CONDITION: # > CCL::ARGS: (:REGISTERS) > CCL::ERROR-POINTER: 558482 > > ... > > Regards, > > Rainer Joswig > > > > Am 09.06.2009 um 07:02 schrieb Ron Garret: > >> Try updating. The 1.3 branch is currently at verison r12153M. It >> works for me on that version. >> >> rg >> >> On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: >> >>> >>> >>> using Clozure Common Lisp Version 1.3-r12088M (DarwinX8664) >>> >>> >>> On executing the add-subview example form in draggable.lisp >>> >>> I get: >>> >>> *** Error in event process: unknown arg spec :REGISTERS >>> >>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >>> #) 85 >>> (#:G5085) >>> #:G5085: # >>> >>> #:COMPILER-VAR: (NIL) >>> #:G5082: # >>> >>> (442C10) : 1 (SIGNAL #) 981 >>> (CONDITION &REST CCL::ARGS) >>> CONDITION: # >>> CCL::ARGS: NIL >>> >>> CCL::%HANDLERS%: ((ERROR) (ERROR)) >>> CCL::TAG: # >>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >>> CCL::FN: #>> drawRect:]|) #x493DBF> >>> >>> (442C68) : 2 (%ERROR # (:REGISTERS) >>> 558482) 117 >>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >>> CONDITION: # >>> CCL::ARGS: (:REGISTERS) >>> CCL::ERROR-POINTER: 558482 >>> >>> >>> >>> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS #>> (#x170192C0)> :ADDRESS #>> "Lisp Rules!" (#x137CD2F0)> :ADDRESS #>> #x7FFF82F59600> :ADDRESS #>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>> fobj=0x170178c0, spc=12.00"; >>> } (#x17019E50)> :VOID) 701 >>> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) >>> CCL::ENTRY: 140735390423728 >>> CCL::SPECS-AND-VALS: (:REGISTERS #>> 0x170192c0> (#x170192C0)> :ADDRESS #>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>> >>> CCL::LEN: 9 >>> CCL::TOTAL-WORDS: 0 >>> CCL::RESULT-SPEC: :VOID >>> CCL::NARGS: 4 >>> CCL::N-FP-ARGS: 0 >>> CCL::I: 0 >>> CCL::SPECS: (:REGISTERS # >>> (#x170192C0)> :ADDRESS #>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>> CCL::SPEC: :REGISTERS >>> >>> (442CF8) : 4 (FUNCALL #'# #>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- >>> SELECTOR :NAME "sizeWithAttributes:" :%SEL #>> #x7FFF82F59600>) #>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>> fobj=0x170178c0, spc=12.00"; >>> } (#x17019E50)>) 805 >>> (#:G3751 #:G3752 CCL::ARG0) >>> #:G3751: # >>> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL >>> #) >>> CCL::ARG0: #>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>> fobj=0x170178c0, spc=12.00"; >>> } (#x17019E50)> >>> >>> #:G3753: # [gcable] (#x17029190) >>> #:G3756: # >>> #:G3755: # (#x170192C0)> >>> >>> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>> fobj=0x170178c0, spc=12.00"; >>> } (#x17019E50)>) 501 >>> (CCL::RECEIVER &REST CCL::ARGS) >>> CCL::RECEIVER: # >>> CCL::ARGS: (#>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>> fobj=0x170178c0, spc=12.00"; >>> } (#x17019E50)>) >>> >>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : >>> %SEL #) >>> FUNCTION: # >>> >>> (442D78) : 6 (FUNCALL #'#<#>> (TEXT-VIEW)>> # #>> (#x7FFF5FBFD370) #x3000420F928D>) 229 >>> (V &OPTIONAL RECT) >>> V: # >>> RECT: # >>> >>> >>> >>> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> >>> 17591849974380) 981 >>> (#:G5081) >>> #:G5081: 17591849974380 >>> >>> #:G5088: # >>> #:G5082: # >>> #:COMPILER-VAR: (NIL) >>> #:G5087: #>> drawRect:]|) #x493DBF> >>> #:G5089: (CONDITION #) >>> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >>> SELF: # (#x170221C0)> >>> _CMD: # >>> RECT: # >>> >>> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 >>> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >>> CCL::INDEX: 277 >>> CCL::ARGS-PTR-FIXNUM: 17591849974380 >>> >>> CCL::LISP-FUNCTION: #>> (Non-Global) #x300041F007BF> >>> WITHOUT-INTERRUPTS: NIL >>> CCL::*CALLBACK-TRACE-P*: NIL >>> >>> (442F08) : 10 (FUNCALL #'# >>> # (#x1C3580)> >>> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>> #x7FFF82FFFD68>)) 205 >>> (#:G3072 #:G3073) >>> #:G3072: # (#x1C3580)> >>> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>> Pointer #x7FFF82FFFD68>) >>> >>> >>> >>> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #>> APPLICATION (#x1C3580)>) 501 >>> (CCL::RECEIVER &REST CCL::ARGS) >>> CCL::RECEIVER: # >>> (#x1C3580)> >>> CCL::ARGS: NIL >>> >>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>> Pointer #x7FFF82FFFD68>) >>> FUNCTION: # >>> >>> (442F68) : 12 (EVENT-LOOP NIL) 413 >>> (&OPTIONAL GUI::END-TEST) >>> GUI::END-TEST: NIL >>> >>> GUI::APP: # (#x1C3580)> >>> *BREAK-ON-ERRORS*: NIL >>> #:G163537: (ERROR) >>> CCL::%HANDLERS%: ((ERROR)) >>> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#>> #x3000420F8DBD>) >>> >>> >>> >>> >>> >>> >>> >>> Am 09.06.2009 um 02:44 schrieb Ron Garret: >>> >>>> [This may be a repeat, but the original never showed up in my >>>> inbox. Also, there's an update at the end.] >>>> >>>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: >>>> >>>>> Use #/addTrackingRect:owner:userData:assumeInside: with >>>>> - the view >>>>> - its #/bounds >>>>> - a ns-object as target >>>>> - ccl::+null-ptr+ >>>>> - #$NO >>>>> >>>>> Then >>>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) >>>>> ) ...) >>>>> >>>>> likewise :mouse-exited and :mouse-move >>>> >>>> Thanks! Updated version enclosed. This has been tested in 32-bit >>>> CCL, and should now work on Tiger as well. >>>> >>>> This version also fixes a bug whereby testviews did not get >>>> properly re-initialized to add a tracker when the class got >>>> redefined. I was using an initialize-instance :after method when >>>> I should have been using shared initialize -- I think. There is >>>> still a subtle bug which I can't figure out. When you add a >>>> highlighted mixin to an existing testview instance, you have to >>>> click on it once before it starts to highlight itself. I have no >>>> idea why this is happening. I may not be using shared-initialize >>>> properly. Maybe a CLOS wizard can help with some advice on the >>>> proper way to do this. >>>> >>>> UPDATE: it turns out that the reason for this is that calling >>>> shared-initialize is done lazily. So until there is an >>>> interaction with the updated object it doesn't get re-initialized, >>>> so add-tracker doesn't get called, so the event that would >>>> normally cause the interaction never gets received. Makes an >>>> interesting little puzzle. >>>> >>>> rg >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> > > 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 > > From raffaelcavallaro at mac.com Tue Jun 9 05:13:20 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Tue, 09 Jun 2009 08:13:20 -0400 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: <436DB8C9-CE32-4EF6-9D10-5976F5DAA0B4@awun.net> References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <436DB8C9-CE32-4EF6-9D10-5976F5DAA0B4@awun.net> Message-ID: On Jun 8, 2009, at 3:29 PM, Ron Garret wrote: > Thanks! Updated version enclosed. This has been tested in 32-bit > CCL, and should now work on Tiger as well. Thanks for this Ron; it's a really cool demo! It works fine in CCL64, but under CCL32 (both the latest 12235 trunk version) it errors as below. I suppose this matters less and less with Snow Leopard approaching though. From what I can tell, it appears that the 32-bit IDE is having problems with your define-class defclass wrapper macro in the form (define-class window ? ? > Error: Invalid type specifier: 100 . > While executing: CCL::VALUES-SPECIFIER-TYPE-INTERNAL, in process Listener(6). > Type cmd-. to abort, cmd-\ for a list of available restarts. > Type :? for other options. 1 > :b (3FD8C7C) : 0 (VALUES-SPECIFIER-TYPE-INTERNAL 100 NIL) 1375 (3FD8C98) : 1 (FUNCALL #'# 100 NIL) 1407 (3FD8CD8) : 2 (SPECIFIER-TYPE 100 NIL) 55 (3FD8CE8) : 3 (%TYPEP X0 100) 71 (3FD8CF8) : 4 (TYPEP X0 100 NIL) 263 (3FD8D10) : 5 (FUNCALL #'#<(:INTERNAL DEFINE-CLASS)> (:CV X0 100)) 207 (3FD8D24) : 6 (FUNCALL #'# (DEFINE-CLASS WINDOW NS- WINDOW SUBVIEWS (:CV X0 100) ...) NIL) 879 (3FD8D60) : 7 (FUNCALL # (DEFINE-CLASS WINDOW NS-WINDOW SUBVIEWS (:CV X0 100) ...) NIL) 175 (3FD8D78) : 8 (MACROEXPAND-1 (DEFINE-CLASS WINDOW NS-WINDOW SUBVIEWS (:CV X0 100) ...) NIL) 239 (3FD8D90) : 9 (CHEAP-EVAL-MACROEXPAND-1 (DEFINE-CLASS WINDOW NS- WINDOW SUBVIEWS (:CV X0 100) ...) NIL) 63 (3FD8DA4) : 10 (CHEAP-EVAL-IN-ENVIRONMENT (DEFINE-CLASS WINDOW NS- WINDOW SUBVIEWS (:CV X0 100) ...) NIL) 4295 (3FD8DB8) : 11 (TOPLEVEL-EVAL (DEFINE-CLASS WINDOW NS-WINDOW SUBVIEWS (:CV X0 100) ...) ((*PACKAGE* *LOADING-FILE-SOURCE-FILE* GUI::*LOADING-TOPLEVEL-LOCATION*) # "/ Users/raffaelc/ccl/examples/ccl-raf/draggable.lisp" NIL)) 743 (3FD8DF8) : 12 (READ-LOOP :INPUT-STREAM # :OUTPUT-STREAM # :BREAK-LEVEL 0 :PROMPT-FUNCTION #) 1831 (3FD8F0C) : 13 (TOPLEVEL-LOOP) 71 (3FD8F14) : 14 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER- PROCESS)>) 583 (3FD8F60) : 15 (RUN-PROCESS-INITIAL-FORM # (#)) 671 (3FD8FA4) : 16 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET- INTERNAL (PROCESS)))> # (#)) 335 (3FD8FCC) : 17 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP- FUNCTION)>) 279 1 > warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From gb at clozure.com Tue Jun 9 05:39:16 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 9 Jun 2009 06:39:16 -0600 (MDT) Subject: [Openmcl-devel] Binary IO... In-Reply-To: <1244472082.2420.187.camel@sirius> References: <1244408197.2420.175.camel@sirius> <1244472082.2420.187.camel@sirius> Message-ID: There are a couple of approaches to this; they're probably described in some detail in the ccl/doc/release-notes* files but the documentation may only mention them in passing (if at all). First of all, an "ivector" is a simple one-dimensional array that's specialized to a numeric or character element type. CCL:MAKE-HEAP-IVECTOR element-count element-type where ELEMENT-COUNT is an unsigned integer and ELEMENT-TYPE is a type specifier - is essentially like (make-array element-count :element-type element-type) except for the fact that the array is allocated in foreign memory (never scanned or moved by the GC. CCL:MAKE-HEAP-IVECTOR returns 3 value: a MACPTR (which points to the 0th element of the vector), a vector (allocated in foreign memory), and the size of the vector in 8-bit bytes. The vector's contents have undefined values ("whatever was there"). CCL:STREAM-DEVICE stream direction DIRECTION should be one of :INPUT or :OUTPUT; STREAM can be any stream. For streams that're associated with file descriptors (sockets and file streams), STREAM-DEVICE returns that file descriptor (or "file handle" as an integer on Windows.) So: (multiple-value-bind (pointer vector) (ccl:make-heap-ivector (ash 8 20) '(unsigned-byte 8)) ;; 'vector' should behave like a regular vector (dotimes (i (length vector)) (setf (aref vector i) (logand i #xff))) (with-open-file (f "some-path" :direction :output ...) (let* ((fd (ccl:stream-device f :output))) (dotimes (i 40) (#_write fd pointer (ash 8 20))))) (with-open-file (f "some-path" :direction :input ...) ;; There can be some cases where an input stream may ;; read from the stream before being asked to. Seek ;; to the start of the file. (let* ((fd (ccl:stream-device f :output))) (#_lseek fd 0 #$SEEK_SET) (dotimes (i 40) (#_read fd pointer (ash 8 20))))) (values pointer vector)) That should be much faster than the version that uses WRITE-SEQUENCE and READ-SEQUENCE, because it doesn't have to copy bytes between the stream's buffer (allocated with MAKE-HEAP-IVECTOR) and the sequence. Since a "heap ivector" isn't even seen by the GC, it'll exist until the end of a session (it's not meaningfully preserved by SAVE-APPLICATION.) If there's a well-defined point in time at which you're done with it, you can explicitly dispose of the vector by doing: (CCL:DISPOSE-HEAP-IVECTOR ivector) ; where ivector is the vector returned ; by MAKE-HEAP-IVECTOR The results of referring to a heap-ivector after it's been disposed of are undefined. (Roughly the same as referring to memory allocated by #_malloc after that memory's been #_free'd.) The "heap ivector" mechanism works reasonably well for ivectors that have well-defined (and relatively long) lifetimes. It's not necessary to inhibit the GC in order to pass a pointer to their first element to foreign code (their address is guaranteed not to change.) Foreign code that might cache that address can safely do so. It's also possible to temporarily inhibit the GC and execute code with a pointer to the current address of an arbitrary ivector: (CCL:WITH-HEAP-IVECTOR (ptr ivector) &body body) temporarily disables the GC, binds PTR to a pointer to the (current) address of the first element of the ivector IVECTOR, and executes BODY. In general, memory allocation requests that'd otherwise cause the GC to be invoked may be satisfied by obtaining more memory from the OS if the GC is inhibited. The chances of this happening (and leading to a worst-case scenario of uncontrolled heap growth) can be minimized if the BODY doesn't cons much (and if other threads don't cons much), but it's very hard to quantify what "much" means. If the pointer PTR is passed to foreign code, that code shouldn't cache the pointer or otherwise try to use it after the WITH-HEAP-IVECTOR form exits; all that's guaranteed is that the vector won't move (and therefore the pointer will remain valid) during the extent of the form, and that isn't otherwise guaranteed. On Mon, 8 Jun 2009, Jon S. Anthony wrote: > > Hmmmm, forgot about the GC again (I suppose that is as much a good thing > as a bad thing - forgetting about it - or more exactly, what it does - > is sort of the point...) > > I think your analysis is exactly right and the behavior pretty much > exactly what is needed in the absence of any "tuning". On the subject > of which - > > > On Sun, 2009-06-07 at 18:04 -0600, Gary Byers wrote: >> A stream's buffer is nailed down in foreign memory, so we can safely >> read from and write to it without worrying about the GC moving it >> around > ... >> There are ways to inhibit the GC, obtain the (absolute, non-relocatable) >> address of the vector, and do I/O directly (bypassing the buffer). Whether >> that's better overall depends on what the cost of inhibiting the GC would >> be (which in turn depends on what kind of consing activitiy is going on >> in other threads.) > > It is straight forward to "pin" a vector like this in ACL, when creating > it, by essentially telling the memory/GC machinery to just place it (on > creation) in an unmoving tenured area, and thereby be assured that the > GC won't be moving it. You don't need to "inhibit" the GC after it is > created (and pinned). At which point, you effectively have the "nailed > down vector", as you say. You indicate something like this is doable in > CCL, any info or pointers for that? I'm guessing (well, hoping) that > any GC inhibition here will only be upfront temporary as well. > > Thanks again! > > /Jon > > > From ron at awun.net Tue Jun 9 05:57:04 2009 From: ron at awun.net (Ron Garret) Date: Tue, 9 Jun 2009 05:57:04 -0700 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> Message-ID: <69AF2D4D-A34A-471E-A16C-EE9D93E71262@awun.net> Why is Rainer seeing this bug now and not me? At this point we're running the same code on the same CCL version on the same OS X version. rg On Jun 9, 2009, at 4:32 AM, Gary Byers wrote: > The bug's somewhat tersesly described in: > > > > It's still open, though the code in the trunk version of the IDE > that was exposing/triggering the problem has been changed. > > That code can cause the IDE to start up with > > ;;;; see CLtL2; DECLARATION-INFORMATION didn't make it into ANSI CL > ? (ccl:declaration-information 'optimize nil) > ((SPEED 0) (SAFETY 3) (COMPILATION-SPEED 0) (SPACE 0) (DEBUG 3)) > > This combination of OPTIMIZE settings causes some rarely-executed > code to be executed, and the real bug is in that code. > (Of course, this should just have the effect of making the code as > slow, bloated, and stupid as possible, but it incidentally exposes > a bug.) > > Untile the real bug is if fixed, you can work around the problem by > doing: > > ? (declaim (optimize (speed 1) (space 1) (safety 1) (debug 1) > (compilation-speed 1))) > > on startup. > > > > > On Tue, 9 Jun 2009, Rainer Joswig wrote: > >> Same error in Clozure Common Lisp Version 1.3-r12235M >> (DarwinX8664). >> >> Mac OS X 10.5.7 on 64bit Intel... >> >> >> *** Error in event process: unknown arg spec :REGISTERS >> >> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >> #) 85 >> (#:G2965) >> #:G2965: # >> >> #:COMPILER-VAR: (NIL) >> #:G2962: # >> >> (442C10) : 1 (SIGNAL #) 981 >> (CONDITION &REST CCL::ARGS) >> CONDITION: # >> CCL::ARGS: NIL >> >> CCL::%HANDLERS%: ((ERROR) (ERROR)) >> CCL::TAG: # >> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >> CCL::FN: #> drawRect:]|) #x493DBF> >> >> (442C68) : 2 (%ERROR # (:REGISTERS) >> 558482) 117 >> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >> CONDITION: # >> CCL::ARGS: (:REGISTERS) >> CCL::ERROR-POINTER: 558482 >> >> ... >> >> Regards, >> >> Rainer Joswig >> >> >> >> Am 09.06.2009 um 07:02 schrieb Ron Garret: >> >>> Try updating. The 1.3 branch is currently at verison r12153M. It >>> works for me on that version. >>> >>> rg >>> >>> On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: >>> >>>> >>>> >>>> using Clozure Common Lisp Version 1.3-r12088M (DarwinX8664) >>>> >>>> >>>> On executing the add-subview example form in draggable.lisp >>>> >>>> I get: >>>> >>>> *** Error in event process: unknown arg spec :REGISTERS >>>> >>>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >>>> #) 85 >>>> (#:G5085) >>>> #:G5085: # >>>> >>>> #:COMPILER-VAR: (NIL) >>>> #:G5082: # >>>> >>>> (442C10) : 1 (SIGNAL #) 981 >>>> (CONDITION &REST CCL::ARGS) >>>> CONDITION: # >>>> CCL::ARGS: NIL >>>> >>>> CCL::%HANDLERS%: ((ERROR) (ERROR)) >>>> CCL::TAG: # >>>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >>>> CCL::FN: #>>> drawRect:]|) #x493DBF> >>>> >>>> (442C68) : 2 (%ERROR # (:REGISTERS) >>>> 558482) 117 >>>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >>>> CONDITION: # >>>> CCL::ARGS: (:REGISTERS) >>>> CCL::ERROR-POINTER: 558482 >>>> >>>> >>>> >>>> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS #>>> (#x170192C0)> :ADDRESS #>>> "Lisp Rules!" (#x137CD2F0)> :ADDRESS #>>> #x7FFF82F59600> :ADDRESS #>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)> :VOID) 701 >>>> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) >>>> CCL::ENTRY: 140735390423728 >>>> CCL::SPECS-AND-VALS: (:REGISTERS #>>> 0x170192c0> (#x170192C0)> :ADDRESS #>>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>>> >>>> CCL::LEN: 9 >>>> CCL::TOTAL-WORDS: 0 >>>> CCL::RESULT-SPEC: :VOID >>>> CCL::NARGS: 4 >>>> CCL::N-FP-ARGS: 0 >>>> CCL::I: 0 >>>> CCL::SPECS: (:REGISTERS # >>>> (#x170192C0)> :ADDRESS #>>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>>> CCL::SPEC: :REGISTERS >>>> >>>> (442CF8) : 4 (FUNCALL #'# #>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- >>>> SELECTOR :NAME "sizeWithAttributes:" :%SEL #>>> #x7FFF82F59600>) #>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)>) 805 >>>> (#:G3751 #:G3752 CCL::ARG0) >>>> #:G3751: # >>>> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL >>>> #) >>>> CCL::ARG0: #>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)> >>>> >>>> #:G3753: # [gcable] (#x17029190) >>>> #:G3756: # >>>> #:G3755: # (#x170192C0)> >>>> >>>> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #>>> DICTIONARY { >>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)>) 501 >>>> (CCL::RECEIVER &REST CCL::ARGS) >>>> CCL::RECEIVER: # >>>> CCL::ARGS: (#>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)>) >>>> >>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : >>>> %SEL #) >>>> FUNCTION: # >>>> >>>> (442D78) : 6 (FUNCALL #'#<#>>> (TEXT-VIEW)>> # #>>> (#x7FFF5FBFD370) #x3000420F928D>) 229 >>>> (V &OPTIONAL RECT) >>>> V: # >>>> RECT: # >>>> >>>> >>>> >>>> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> >>>> 17591849974380) 981 >>>> (#:G5081) >>>> #:G5081: 17591849974380 >>>> >>>> #:G5088: # >>>> #:G5082: # >>>> #:COMPILER-VAR: (NIL) >>>> #:G5087: #>>> drawRect:]|) #x493DBF> >>>> #:G5089: (CONDITION #) >>>> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >>>> SELF: # (#x170221C0)> >>>> _CMD: # >>>> RECT: # >>>> >>>> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 >>>> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >>>> CCL::INDEX: 277 >>>> CCL::ARGS-PTR-FIXNUM: 17591849974380 >>>> >>>> CCL::LISP-FUNCTION: #>>> (Non-Global) #x300041F007BF> >>>> WITHOUT-INTERRUPTS: NIL >>>> CCL::*CALLBACK-TRACE-P*: NIL >>>> >>>> (442F08) : 10 (FUNCALL #'# >>>> # (#x1C3580)> >>>> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>> #x7FFF82FFFD68>)) 205 >>>> (#:G3072 #:G3073) >>>> #:G3072: # (#x1C3580)> >>>> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>> Pointer #x7FFF82FFFD68>) >>>> >>>> >>>> >>>> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> >>>> #>>> APPLICATION (#x1C3580)>) 501 >>>> (CCL::RECEIVER &REST CCL::ARGS) >>>> CCL::RECEIVER: # >>>> (#x1C3580)> >>>> CCL::ARGS: NIL >>>> >>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>> Pointer #x7FFF82FFFD68>) >>>> FUNCTION: # >>>> >>>> (442F68) : 12 (EVENT-LOOP NIL) 413 >>>> (&OPTIONAL GUI::END-TEST) >>>> GUI::END-TEST: NIL >>>> >>>> GUI::APP: # >>>> (#x1C3580)> >>>> *BREAK-ON-ERRORS*: NIL >>>> #:G163537: (ERROR) >>>> CCL::%HANDLERS%: ((ERROR)) >>>> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#>>> #x3000420F8DBD>) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Am 09.06.2009 um 02:44 schrieb Ron Garret: >>>> >>>>> [This may be a repeat, but the original never showed up in my >>>>> inbox. Also, there's an update at the end.] >>>>> >>>>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: >>>>> >>>>>> Use #/addTrackingRect:owner:userData:assumeInside: with >>>>>> - the view >>>>>> - its #/bounds >>>>>> - a ns-object as target >>>>>> - ccl::+null-ptr+ >>>>>> - #$NO >>>>>> >>>>>> Then >>>>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) >>>>>> ) ...) >>>>>> >>>>>> likewise :mouse-exited and :mouse-move >>>>> >>>>> Thanks! Updated version enclosed. This has been tested in 32-bit >>>>> CCL, and should now work on Tiger as well. >>>>> >>>>> This version also fixes a bug whereby testviews did not get >>>>> properly re-initialized to add a tracker when the class got >>>>> redefined. I was using an initialize-instance :after method when >>>>> I should have been using shared initialize -- I think. There is >>>>> still a subtle bug which I can't figure out. When you add a >>>>> highlighted mixin to an existing testview instance, you have to >>>>> click on it once before it starts to highlight itself. I have no >>>>> idea why this is happening. I may not be using shared-initialize >>>>> properly. Maybe a CLOS wizard can help with some advice on the >>>>> proper way to do this. >>>>> >>>>> UPDATE: it turns out that the reason for this is that calling >>>>> shared-initialize is done lazily. So until there is an >>>>> interaction with the updated object it doesn't get re-initialized, >>>>> so add-tracker doesn't get called, so the event that would >>>>> normally cause the interaction never gets received. Makes an >>>>> interesting little puzzle. >>>>> >>>>> rg >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >> >> 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 From ron at awun.net Tue Jun 9 06:06:40 2009 From: ron at awun.net (Ron Garret) Date: Tue, 9 Jun 2009 06:06:40 -0700 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <436DB8C9-CE32-4EF6-9D10-5976F5DAA0B4@awun.net> Message-ID: On Jun 9, 2009, at 5:13 AM, Raffael Cavallaro wrote: > > On Jun 8, 2009, at 3:29 PM, Ron Garret wrote: > >> Thanks! Updated version enclosed. This has been tested in 32-bit >> CCL, and should now work on Tiger as well. > > Thanks for this Ron; it's a really cool demo! > Glad you like it :-) > It works fine in CCL64, but under CCL32 (both the latest 12235 trunk > version) it errors as below. That's really weird. Why does it work for me and not for you? > I suppose this matters less and less with > Snow Leopard approaching though. From what I can tell, it appears that > the 32-bit IDE is having problems with your define-class defclass > wrapper macro in the form (define-class window ? Looks to me like you might be using an older version of utilities.lisp (or you have an old fasl32 lying around). I made some changes to define-class specifically for the window class to support class- allocated slots. It looks like you're trying to use an older version of define-class that didn't have that feature. rg From joswig at lisp.de Tue Jun 9 06:11:16 2009 From: joswig at lisp.de (Rainer Joswig) Date: Tue, 9 Jun 2009 15:11:16 +0200 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> Message-ID: Am 09.06.2009 um 13:32 schrieb Gary Byers: > The bug's somewhat tersesly described in: > > > > It's still open, though the code in the trunk version of the IDE > that was exposing/triggering the problem has been changed. > > That code can cause the IDE to start up with > > ;;;; see CLtL2; DECLARATION-INFORMATION didn't make it into ANSI CL > ? (ccl:declaration-information 'optimize nil) ((SPEED 0) (SAFETY 3) > (COMPILATION-SPEED 0) (SPACE 0) (DEBUG 3)) yes, it starts up with these values. > > This combination of OPTIMIZE settings causes some rarely-executed > code to be executed, and the real bug is in that code. > (Of course, this should just have the effect of making the code as > slow, bloated, and stupid as possible, but it incidentally exposes > a bug.) Actually I'm a fan of higher safety/debug than speed values. ;-) > > Untile the real bug is if fixed, you can work around the problem by > doing: > > ? (declaim (optimize (speed 1) (space 1) (safety 1) (debug 1) > (compilation-speed 1))) > > on startup. > Then it works. Thanks for the infos. Regards, Rainer Joswig > > > > On Tue, 9 Jun 2009, Rainer Joswig wrote: > >> Same error in Clozure Common Lisp Version 1.3-r12235M >> (DarwinX8664). >> >> Mac OS X 10.5.7 on 64bit Intel... >> >> >> *** Error in event process: unknown arg spec :REGISTERS >> >> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >> #) 85 >> (#:G2965) >> #:G2965: # >> >> #:COMPILER-VAR: (NIL) >> #:G2962: # >> >> (442C10) : 1 (SIGNAL #) 981 >> (CONDITION &REST CCL::ARGS) >> CONDITION: # >> CCL::ARGS: NIL >> >> CCL::%HANDLERS%: ((ERROR) (ERROR)) >> CCL::TAG: # >> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >> CCL::FN: #> drawRect:]|) #x493DBF> >> >> (442C68) : 2 (%ERROR # (:REGISTERS) >> 558482) 117 >> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >> CONDITION: # >> CCL::ARGS: (:REGISTERS) >> CCL::ERROR-POINTER: 558482 >> >> ... >> >> Regards, >> >> Rainer Joswig >> >> >> >> Am 09.06.2009 um 07:02 schrieb Ron Garret: >> >>> Try updating. The 1.3 branch is currently at verison r12153M. It >>> works for me on that version. >>> >>> rg >>> >>> On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: >>> >>>> >>>> >>>> using Clozure Common Lisp Version 1.3-r12088M (DarwinX8664) >>>> >>>> >>>> On executing the add-subview example form in draggable.lisp >>>> >>>> I get: >>>> >>>> *** Error in event process: unknown arg spec :REGISTERS >>>> >>>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >>>> #) 85 >>>> (#:G5085) >>>> #:G5085: # >>>> >>>> #:COMPILER-VAR: (NIL) >>>> #:G5082: # >>>> >>>> (442C10) : 1 (SIGNAL #) 981 >>>> (CONDITION &REST CCL::ARGS) >>>> CONDITION: # >>>> CCL::ARGS: NIL >>>> >>>> CCL::%HANDLERS%: ((ERROR) (ERROR)) >>>> CCL::TAG: # >>>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >>>> CCL::FN: #>>> drawRect:]|) #x493DBF> >>>> >>>> (442C68) : 2 (%ERROR # (:REGISTERS) >>>> 558482) 117 >>>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >>>> CONDITION: # >>>> CCL::ARGS: (:REGISTERS) >>>> CCL::ERROR-POINTER: 558482 >>>> >>>> >>>> >>>> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS #>>> (#x170192C0)> :ADDRESS #>>> "Lisp Rules!" (#x137CD2F0)> :ADDRESS #>>> #x7FFF82F59600> :ADDRESS #>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)> :VOID) 701 >>>> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) >>>> CCL::ENTRY: 140735390423728 >>>> CCL::SPECS-AND-VALS: (:REGISTERS #>>> 0x170192c0> (#x170192C0)> :ADDRESS #>>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>>> >>>> CCL::LEN: 9 >>>> CCL::TOTAL-WORDS: 0 >>>> CCL::RESULT-SPEC: :VOID >>>> CCL::NARGS: 4 >>>> CCL::N-FP-ARGS: 0 >>>> CCL::I: 0 >>>> CCL::SPECS: (:REGISTERS # >>>> (#x170192C0)> :ADDRESS #>>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>>> CCL::SPEC: :REGISTERS >>>> >>>> (442CF8) : 4 (FUNCALL #'# #>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- >>>> SELECTOR :NAME "sizeWithAttributes:" :%SEL #>>> #x7FFF82F59600>) #>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)>) 805 >>>> (#:G3751 #:G3752 CCL::ARG0) >>>> #:G3751: # >>>> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL >>>> #) >>>> CCL::ARG0: #>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)> >>>> >>>> #:G3753: # [gcable] (#x17029190) >>>> #:G3756: # >>>> #:G3755: # (#x170192C0)> >>>> >>>> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #>>> DICTIONARY { >>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)>) 501 >>>> (CCL::RECEIVER &REST CCL::ARGS) >>>> CCL::RECEIVER: # >>>> CCL::ARGS: (#>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>> fobj=0x170178c0, spc=12.00"; >>>> } (#x17019E50)>) >>>> >>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : >>>> %SEL #) >>>> FUNCTION: # >>>> >>>> (442D78) : 6 (FUNCALL #'#<#>>> (TEXT-VIEW)>> # #>>> (#x7FFF5FBFD370) #x3000420F928D>) 229 >>>> (V &OPTIONAL RECT) >>>> V: # >>>> RECT: # >>>> >>>> >>>> >>>> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> >>>> 17591849974380) 981 >>>> (#:G5081) >>>> #:G5081: 17591849974380 >>>> >>>> #:G5088: # >>>> #:G5082: # >>>> #:COMPILER-VAR: (NIL) >>>> #:G5087: #>>> drawRect:]|) #x493DBF> >>>> #:G5089: (CONDITION #) >>>> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >>>> SELF: # (#x170221C0)> >>>> _CMD: # >>>> RECT: # >>>> >>>> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 >>>> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >>>> CCL::INDEX: 277 >>>> CCL::ARGS-PTR-FIXNUM: 17591849974380 >>>> >>>> CCL::LISP-FUNCTION: #>>> (Non-Global) #x300041F007BF> >>>> WITHOUT-INTERRUPTS: NIL >>>> CCL::*CALLBACK-TRACE-P*: NIL >>>> >>>> (442F08) : 10 (FUNCALL #'# >>>> # (#x1C3580)> >>>> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>> #x7FFF82FFFD68>)) 205 >>>> (#:G3072 #:G3073) >>>> #:G3072: # (#x1C3580)> >>>> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>> Pointer #x7FFF82FFFD68>) >>>> >>>> >>>> >>>> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> >>>> #>>> APPLICATION (#x1C3580)>) 501 >>>> (CCL::RECEIVER &REST CCL::ARGS) >>>> CCL::RECEIVER: # >>>> (#x1C3580)> >>>> CCL::ARGS: NIL >>>> >>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>> Pointer #x7FFF82FFFD68>) >>>> FUNCTION: # >>>> >>>> (442F68) : 12 (EVENT-LOOP NIL) 413 >>>> (&OPTIONAL GUI::END-TEST) >>>> GUI::END-TEST: NIL >>>> >>>> GUI::APP: # >>>> (#x1C3580)> >>>> *BREAK-ON-ERRORS*: NIL >>>> #:G163537: (ERROR) >>>> CCL::%HANDLERS%: ((ERROR)) >>>> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#>>> #x3000420F8DBD>) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Am 09.06.2009 um 02:44 schrieb Ron Garret: >>>> >>>>> [This may be a repeat, but the original never showed up in my >>>>> inbox. Also, there's an update at the end.] >>>>> >>>>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: >>>>> >>>>>> Use #/addTrackingRect:owner:userData:assumeInside: with >>>>>> - the view >>>>>> - its #/bounds >>>>>> - a ns-object as target >>>>>> - ccl::+null-ptr+ >>>>>> - #$NO >>>>>> >>>>>> Then >>>>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) >>>>>> ) ...) >>>>>> >>>>>> likewise :mouse-exited and :mouse-move >>>>> >>>>> Thanks! Updated version enclosed. This has been tested in 32-bit >>>>> CCL, and should now work on Tiger as well. >>>>> >>>>> This version also fixes a bug whereby testviews did not get >>>>> properly re-initialized to add a tracker when the class got >>>>> redefined. I was using an initialize-instance :after method when >>>>> I should have been using shared initialize -- I think. There is >>>>> still a subtle bug which I can't figure out. When you add a >>>>> highlighted mixin to an existing testview instance, you have to >>>>> click on it once before it starts to highlight itself. I have no >>>>> idea why this is happening. I may not be using shared-initialize >>>>> properly. Maybe a CLOS wizard can help with some advice on the >>>>> proper way to do this. >>>>> >>>>> UPDATE: it turns out that the reason for this is that calling >>>>> shared-initialize is done lazily. So until there is an >>>>> interaction with the updated object it doesn't get re-initialized, >>>>> so add-tracker doesn't get called, so the event that would >>>>> normally cause the interaction never gets received. Makes an >>>>> interesting little puzzle. >>>>> >>>>> rg >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >> >> 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 >> >> Rainer Joswig, Hamburg, Germany http://lispm.dyndns.org/ mailto:joswig at lisp.de From gb at clozure.com Tue Jun 9 06:17:41 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 9 Jun 2009 07:17:41 -0600 (MDT) Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: <69AF2D4D-A34A-471E-A16C-EE9D93E71262@awun.net> References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> <69AF2D4D-A34A-471E-A16C-EE9D93E71262@awun.net> Message-ID: The code that sets the optimization settings (persistently and probably not intentionally so) is in ccl/examples/cocoa/easygui/views.lisp. For reasons that I don't pretend to understand, that file is loaded everytime that the standalone IDE starts up, but isn't loaded or referenced when one just does (require "COCOA"). That's my best guess; if it's not correct and it was more important that I can imagine it to be to determine what other difference in environment led to to different behavior, then I suppose that - armed with knowledge of what all of those differences are - one could come up with a more accurate explanation. I don't know. To be honest, I don't really care; it seems like the time spent puzzling over this could be better spent trying to fix the bug. On Tue, 9 Jun 2009, Ron Garret wrote: > Why is Rainer seeing this bug now and not me? At this point we're running > the same code on the same CCL version on the same OS X version. > > rg > > On Jun 9, 2009, at 4:32 AM, Gary Byers wrote: > >> The bug's somewhat tersesly described in: >> >> >> >> It's still open, though the code in the trunk version of the IDE >> that was exposing/triggering the problem has been changed. >> >> That code can cause the IDE to start up with >> >> ;;;; see CLtL2; DECLARATION-INFORMATION didn't make it into ANSI CL >> ? (ccl:declaration-information 'optimize nil) >> ((SPEED 0) (SAFETY 3) (COMPILATION-SPEED 0) (SPACE 0) (DEBUG 3)) >> >> This combination of OPTIMIZE settings causes some rarely-executed >> code to be executed, and the real bug is in that code. >> (Of course, this should just have the effect of making the code as >> slow, bloated, and stupid as possible, but it incidentally exposes >> a bug.) >> >> Untile the real bug is if fixed, you can work around the problem by doing: >> >> ? (declaim (optimize (speed 1) (space 1) (safety 1) (debug 1) >> (compilation-speed 1))) >> >> on startup. >> >> >> >> >> On Tue, 9 Jun 2009, Rainer Joswig wrote: >> >>> Same error in Clozure Common Lisp Version 1.3-r12235M (DarwinX8664). >>> >>> Mac OS X 10.5.7 on 64bit Intel... >>> >>> >>> *** Error in event process: unknown arg spec :REGISTERS >>> >>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >>> #) 85 >>> (#:G2965) >>> #:G2965: # >>> >>> #:COMPILER-VAR: (NIL) >>> #:G2962: # >>> >>> (442C10) : 1 (SIGNAL #) 981 >>> (CONDITION &REST CCL::ARGS) >>> CONDITION: # >>> CCL::ARGS: NIL >>> >>> CCL::%HANDLERS%: ((ERROR) (ERROR)) >>> CCL::TAG: # >>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >>> CCL::FN: #>> drawRect:]|) #x493DBF> >>> >>> (442C68) : 2 (%ERROR # (:REGISTERS) >>> 558482) 117 >>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >>> CONDITION: # >>> CCL::ARGS: (:REGISTERS) >>> CCL::ERROR-POINTER: 558482 >>> >>> ... >>> >>> Regards, >>> >>> Rainer Joswig >>> >>> >>> >>> Am 09.06.2009 um 07:02 schrieb Ron Garret: >>> >>>> Try updating. The 1.3 branch is currently at verison r12153M. It >>>> works for me on that version. >>>> >>>> rg >>>> >>>> On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: >>>> >>>>> >>>>> >>>>> using Clozure Common Lisp Version 1.3-r12088M (DarwinX8664) >>>>> >>>>> >>>>> On executing the add-subview example form in draggable.lisp >>>>> >>>>> I get: >>>>> >>>>> *** Error in event process: unknown arg spec :REGISTERS >>>>> >>>>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView drawRect:]|)> >>>>> #) 85 >>>>> (#:G5085) >>>>> #:G5085: # >>>>> >>>>> #:COMPILER-VAR: (NIL) >>>>> #:G5082: # >>>>> >>>>> (442C10) : 1 (SIGNAL #) 981 >>>>> (CONDITION &REST CCL::ARGS) >>>>> CONDITION: # >>>>> CCL::ARGS: NIL >>>>> >>>>> CCL::%HANDLERS%: ((ERROR) (ERROR)) >>>>> CCL::TAG: # >>>>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* >>>>> CCL::FN: #>>>> drawRect:]|) #x493DBF> >>>>> >>>>> (442C68) : 2 (%ERROR # (:REGISTERS) >>>>> 558482) 117 >>>>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) >>>>> CONDITION: # >>>>> CCL::ARGS: (:REGISTERS) >>>>> CCL::ERROR-POINTER: 558482 >>>>> >>>>> >>>>> >>>>> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS #>>>> (#x170192C0)> :ADDRESS #>>>> "Lisp Rules!" (#x137CD2F0)> :ADDRESS #>>>> #x7FFF82F59600> :ADDRESS #>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>>> fobj=0x170178c0, spc=12.00"; >>>>> } (#x17019E50)> :VOID) 701 >>>>> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) >>>>> CCL::ENTRY: 140735390423728 >>>>> CCL::SPECS-AND-VALS: (:REGISTERS #>>>> 0x170192c0> (#x170192C0)> :ADDRESS #>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>>>> >>>>> CCL::LEN: 9 >>>>> CCL::TOTAL-WORDS: 0 >>>>> CCL::RESULT-SPEC: :VOID >>>>> CCL::NARGS: 4 >>>>> CCL::N-FP-ARGS: 0 >>>>> CCL::I: 0 >>>>> CCL::SPECS: (:REGISTERS # >>>>> (#x170192C0)> :ADDRESS #>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) >>>>> CCL::SPEC: :REGISTERS >>>>> >>>>> (442CF8) : 4 (FUNCALL #'# #>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- >>>>> SELECTOR :NAME "sizeWithAttributes:" :%SEL #>>>> #x7FFF82F59600>) #>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>>> fobj=0x170178c0, spc=12.00"; >>>>> } (#x17019E50)>) 805 >>>>> (#:G3751 #:G3752 CCL::ARG0) >>>>> #:G3751: # >>>>> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL >>>>> #) >>>>> CCL::ARG0: #>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>>> fobj=0x170178c0, spc=12.00"; >>>>> } (#x17019E50)> >>>>> >>>>> #:G3753: # [gcable] (#x17029190) >>>>> #:G3756: # >>>>> #:G3755: # (#x170192C0)> >>>>> >>>>> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>>> fobj=0x170178c0, spc=12.00"; >>>>> } (#x17019E50)>) 501 >>>>> (CCL::RECEIVER &REST CCL::ARGS) >>>>> CCL::RECEIVER: # >>>>> CCL::ARGS: (#>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) >>>>> fobj=0x170178c0, spc=12.00"; >>>>> } (#x17019E50)>) >>>>> >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : >>>>> %SEL #) >>>>> FUNCTION: # >>>>> >>>>> (442D78) : 6 (FUNCALL #'#<#>>>> (TEXT-VIEW)>> # #>>>> (#x7FFF5FBFD370) #x3000420F928D>) 229 >>>>> (V &OPTIONAL RECT) >>>>> V: # >>>>> RECT: # >>>>> >>>>> >>>>> >>>>> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> >>>>> 17591849974380) 981 >>>>> (#:G5081) >>>>> #:G5081: 17591849974380 >>>>> >>>>> #:G5088: # >>>>> #:G5082: # >>>>> #:COMPILER-VAR: (NIL) >>>>> #:G5087: #>>>> drawRect:]|) #x493DBF> >>>>> #:G5089: (CONDITION #) >>>>> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) >>>>> SELF: # (#x170221C0)> >>>>> _CMD: # >>>>> RECT: # >>>>> >>>>> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 >>>>> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) >>>>> CCL::INDEX: 277 >>>>> CCL::ARGS-PTR-FIXNUM: 17591849974380 >>>>> >>>>> CCL::LISP-FUNCTION: #>>>> (Non-Global) #x300041F007BF> >>>>> WITHOUT-INTERRUPTS: NIL >>>>> CCL::*CALLBACK-TRACE-P*: NIL >>>>> >>>>> (442F08) : 10 (FUNCALL #'# >>>>> # (#x1C3580)> >>>>> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>>> #x7FFF82FFFD68>)) 205 >>>>> (#:G3072 #:G3073) >>>>> #:G3072: # (#x1C3580)> >>>>> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>>> Pointer #x7FFF82FFFD68>) >>>>> >>>>> >>>>> >>>>> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND-UNAMBIGUOUS-MESSAGE >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION T)))> #>>>> APPLICATION (#x1C3580)>) 501 >>>>> (CCL::RECEIVER &REST CCL::ARGS) >>>>> CCL::RECEIVER: # >>>>> (#x1C3580)> >>>>> CCL::ARGS: NIL >>>>> >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL #>>>> Pointer #x7FFF82FFFD68>) >>>>> FUNCTION: # >>>>> >>>>> (442F68) : 12 (EVENT-LOOP NIL) 413 >>>>> (&OPTIONAL GUI::END-TEST) >>>>> GUI::END-TEST: NIL >>>>> >>>>> GUI::APP: # (#x1C3580)> >>>>> *BREAK-ON-ERRORS*: NIL >>>>> #:G163537: (ERROR) >>>>> CCL::%HANDLERS%: ((ERROR)) >>>>> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (#>>>> #x3000420F8DBD>) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Am 09.06.2009 um 02:44 schrieb Ron Garret: >>>>> >>>>>> [This may be a repeat, but the original never showed up in my >>>>>> inbox. Also, there's an update at the end.] >>>>>> >>>>>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: >>>>>> >>>>>>> Use #/addTrackingRect:owner:userData:assumeInside: with >>>>>>> - the view >>>>>>> - its #/bounds >>>>>>> - a ns-object as target >>>>>>> - ccl::+null-ptr+ >>>>>>> - #$NO >>>>>>> >>>>>>> Then >>>>>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) >>>>>>> ) ...) >>>>>>> >>>>>>> likewise :mouse-exited and :mouse-move >>>>>> >>>>>> Thanks! Updated version enclosed. This has been tested in 32-bit >>>>>> CCL, and should now work on Tiger as well. >>>>>> >>>>>> This version also fixes a bug whereby testviews did not get >>>>>> properly re-initialized to add a tracker when the class got >>>>>> redefined. I was using an initialize-instance :after method when >>>>>> I should have been using shared initialize -- I think. There is >>>>>> still a subtle bug which I can't figure out. When you add a >>>>>> highlighted mixin to an existing testview instance, you have to >>>>>> click on it once before it starts to highlight itself. I have no >>>>>> idea why this is happening. I may not be using shared-initialize >>>>>> properly. Maybe a CLOS wizard can help with some advice on the >>>>>> proper way to do this. >>>>>> >>>>>> UPDATE: it turns out that the reason for this is that calling >>>>>> shared-initialize is done lazily. So until there is an >>>>>> interaction with the updated object it doesn't get re-initialized, >>>>>> so add-tracker doesn't get called, so the event that would >>>>>> normally cause the interaction never gets received. Makes an >>>>>> interesting little puzzle. >>>>>> >>>>>> rg >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>> >>> 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 > From j-anthony at comcast.net Tue Jun 9 07:28:44 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Tue, 09 Jun 2009 10:28:44 -0400 Subject: [Openmcl-devel] Binary IO... In-Reply-To: References: <1244408197.2420.175.camel@sirius> <1244472082.2420.187.camel@sirius> Message-ID: <1244557724.2420.202.camel@sirius> This appears to be pretty much exactly what I need. Since these vectors behave like "regular vectors" in normal code, I really don't even need the capabilities of WITH-HEAP-IVECTOR (at least I don't now think so...). The only thing left is the ability to have (or simulate) a bidirectional stream with this. So, is it legitimate to do this sort of thing (basically use the same stream for reading and writing)? Or can there be two separate streams open at the same time for the same file (one for input, one for output)? (defun open-store (filespec) ... (multiple-value-bind (pointer vector) (ccl:make-heap-ivector (ash 8 20) '(unsigned-byte 8)) (save-in-page-vector pointer vector)) (multiple-value-bind (pointer vector) (ccl:make-heap-ivector (ash 8 20) '(unsigned-byte 8)) (save-out-page-vector pointer vector)) ... (save-stream-in-right-place (open "./test.bin" :element-type '(unsigned-byte 8) :direction :io ; <<<------- input and output :if-exists :overwrite :if-does-not-exist :create)) ...) ... (defun read-page (page) (let* ((f (get-stream-from-right-place)) (fd (ccl:stream-device f :input))) <<<--- Use as input (multiple-value-bind (pointer vector size) (get-page-info page) (declare (type macptr pointer) (type (simple-array (unsigned-byte 8) (*)) vector) (type fixnum size)) (#_read fd pointer size)))) (defun write-page (page) (let* ((f (get-stream-from-right-place)) (fd (ccl:stream-device f :output))) <<<---- Use as output (multiple-value-bind (pointer vector size) (get-page-info page) (declare (type macptr pointer) (type (simple-array (unsigned-byte 8) (*)) vector) (type fixnum size)) (#_write fd pointer size)))) ... (defun doing-something (...) .... (read-page some-page) .... (write-page some-other-page) ....) Thanks again, /Jon On Tue, 2009-06-09 at 06:39 -0600, Gary Byers wrote: > There are a couple of approaches to this; they're probably described > in some detail in the ccl/doc/release-notes* files but the documentation > may only mention them in passing (if at all). > > First of all, an "ivector" is a simple one-dimensional array that's > specialized to a numeric or character element type. > > CCL:MAKE-HEAP-IVECTOR element-count element-type > > where ELEMENT-COUNT is an unsigned integer and ELEMENT-TYPE is a type > specifier - is essentially like > > (make-array element-count :element-type element-type) > > except for the fact that the array is allocated in foreign memory (never > scanned or moved by the GC. > > CCL:MAKE-HEAP-IVECTOR returns 3 value: a MACPTR (which points to the 0th > element of the vector), a vector (allocated in foreign memory), and the > size of the vector in 8-bit bytes. > > The vector's contents have undefined values ("whatever was there"). > > CCL:STREAM-DEVICE stream direction > > DIRECTION should be one of :INPUT or :OUTPUT; STREAM can be any stream. > For streams that're associated with file descriptors (sockets and file > streams), STREAM-DEVICE returns that file descriptor (or "file handle" > as an integer on Windows.) > > So: > > (multiple-value-bind (pointer vector) > (ccl:make-heap-ivector (ash 8 20) '(unsigned-byte 8)) > ;; 'vector' should behave like a regular vector > (dotimes (i (length vector)) > (setf (aref vector i) (logand i #xff))) > (with-open-file (f "some-path" :direction :output ...) > (let* ((fd (ccl:stream-device f :output))) > (dotimes (i 40) > (#_write fd pointer (ash 8 20))))) > (with-open-file (f "some-path" :direction :input ...) > ;; There can be some cases where an input stream may > ;; read from the stream before being asked to. Seek > ;; to the start of the file. > (let* ((fd (ccl:stream-device f :output))) > (#_lseek fd 0 #$SEEK_SET) > (dotimes (i 40) > (#_read fd pointer (ash 8 20))))) > (values pointer vector)) > > That should be much faster than the version that uses WRITE-SEQUENCE > and READ-SEQUENCE, because it doesn't have to copy bytes between > the stream's buffer (allocated with MAKE-HEAP-IVECTOR) and the sequence. > > Since a "heap ivector" isn't even seen by the GC, it'll exist until > the end of a session (it's not meaningfully preserved by SAVE-APPLICATION.) > If there's a well-defined point in time at which you're done with it, you > can explicitly dispose of the vector by doing: > > (CCL:DISPOSE-HEAP-IVECTOR ivector) ; where ivector is the vector returned > ; by MAKE-HEAP-IVECTOR > > The results of referring to a heap-ivector after it's been disposed of > are undefined. (Roughly the same as referring to memory allocated by > #_malloc after that memory's been #_free'd.) > > The "heap ivector" mechanism works reasonably well for ivectors that > have well-defined (and relatively long) lifetimes. It's not necessary > to inhibit the GC in order to pass a pointer to their first element to > foreign code (their address is guaranteed not to change.) Foreign code > that might cache that address can safely do so. > > It's also possible to temporarily inhibit the GC and execute code with > a pointer to the current address of an arbitrary ivector: > > (CCL:WITH-HEAP-IVECTOR (ptr ivector) &body body) > > temporarily disables the GC, binds PTR to a pointer to the (current) > address of the first element of the ivector IVECTOR, and executes BODY. > In general, memory allocation requests that'd otherwise cause the GC > to be invoked may be satisfied by obtaining more memory from the OS if > the GC is inhibited. The chances of this happening (and leading to > a worst-case scenario of uncontrolled heap growth) can be minimized > if the BODY doesn't cons much (and if other threads don't cons much), > but it's very hard to quantify what "much" means. > > If the pointer PTR is passed to foreign code, that code shouldn't cache > the pointer or otherwise try to use it after the WITH-HEAP-IVECTOR form > exits; all that's guaranteed is that the vector won't move (and therefore > the pointer will remain valid) during the extent of the form, and that > isn't otherwise guaranteed. > > > > > > > On Mon, 8 Jun 2009, Jon S. Anthony wrote: > > > > > Hmmmm, forgot about the GC again (I suppose that is as much a good thing > > as a bad thing - forgetting about it - or more exactly, what it does - > > is sort of the point...) > > > > I think your analysis is exactly right and the behavior pretty much > > exactly what is needed in the absence of any "tuning". On the subject > > of which - > > > > > > On Sun, 2009-06-07 at 18:04 -0600, Gary Byers wrote: > >> A stream's buffer is nailed down in foreign memory, so we can safely > >> read from and write to it without worrying about the GC moving it > >> around > > ... > >> There are ways to inhibit the GC, obtain the (absolute, non-relocatable) > >> address of the vector, and do I/O directly (bypassing the buffer). Whether > >> that's better overall depends on what the cost of inhibiting the GC would > >> be (which in turn depends on what kind of consing activitiy is going on > >> in other threads.) > > > > It is straight forward to "pin" a vector like this in ACL, when creating > > it, by essentially telling the memory/GC machinery to just place it (on > > creation) in an unmoving tenured area, and thereby be assured that the > > GC won't be moving it. You don't need to "inhibit" the GC after it is > > created (and pinned). At which point, you effectively have the "nailed > > down vector", as you say. You indicate something like this is doable in > > CCL, any info or pointers for that? I'm guessing (well, hoping) that > > any GC inhibition here will only be upfront temporary as well. > > > > Thanks again! > > > > /Jon > > > > > > From arthur.cater at ucd.ie Tue Jun 9 09:04:35 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Tue, 09 Jun 2009 17:04:35 +0100 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> <69AF2D4D-A34A-471E-A16C-EE9D93E71262@awun.net> Message-ID: I'm the guilty party for setting,?persistently and unintentionally so,??those optimization settings from within easygui views.lisp. Apologies to all concerned. I thought the compiler treated these declarations as affecting the subsequent contents of the source file in which they appeared ?(modulo later?declarations in the same overriding them), rather than causing?the form to be given effect when loading the fasl; must I put it within (eval-when (:compile-toplevel) ...)? I think that file gets loaded as part of (require 'cocoa-application), not as part of the startup of the ide-containing image. Arthur ----- Original Message ----- From: Gary Byers Date: Tuesday, June 9, 2009 2:31 pm Subject: Re: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL To: Ron Garret Cc: openmcl-devel Devel > The code that sets the optimization settings (persistently and > probablynot intentionally so) is in > ccl/examples/cocoa/easygui/views.lisp.? For > reasons that I don't pretend to understand, that file is loaded > everytimethat the standalone IDE starts up, but isn't loaded or > referenced when > one just does (require "COCOA"). > > That's my best guess; if it's not correct and it was more important > that I can imagine it to be to determine what other difference in > environment led to to different behavior, then I suppose that - armed > with knowledge of what all of those differences are - one could come > up with a more accurate explanation. > > I don't know.? To be honest, I don't really care; it seems > like the > time spent puzzling over this could be better spent trying to > fix the bug. > > On Tue, 9 Jun 2009, Ron Garret wrote: > > > Why is Rainer seeing this bug now and not me?? At this > point we're running > > the same code on the same CCL version on the same OS X version. > > > > rg > > > > On Jun 9, 2009, at 4:32 AM, Gary Byers wrote: > > > >> The bug's somewhat tersesly described in: > >> > >> > >> > >> It's still open, though the code in the trunk version of the IDE > >> that was exposing/triggering the problem has been changed. > >> > >> That code can cause the IDE to start up with > >> > >> ;;;; see CLtL2; DECLARATION-INFORMATION didn't make it into > ANSI CL > >> ? (ccl:declaration-information 'optimize nil) > >> ((SPEED 0) (SAFETY 3) (COMPILATION-SPEED 0) (SPACE 0) (DEBUG 3)) > >> > >> This combination of OPTIMIZE settings causes some rarely-executed > >> code to be executed, and the real bug is in that code. > >> (Of course, this should just have the effect of making the > code as > >> slow, bloated, and stupid as possible, but it incidentally exposes > >> a bug.) > >> > >> Untile the real bug is if fixed, you can work around the > problem by doing: > >> > >> ? (declaim (optimize (speed 1) (space 1) (safety 1) (debug 1) > >> (compilation-speed 1))) > >> > >> on startup. > >> > >> > >> > >> > >> On Tue, 9 Jun 2009, Rainer Joswig wrote: > >> > >>> Same error in? Clozure Common Lisp Version 1.3- > r12235M? (DarwinX8664). > >>> > >>> Mac OS X 10.5.7 on 64bit Intel... > >>> > >>> > >>> *** Error in event process: unknown arg spec :REGISTERS > >>> > >>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView > drawRect:]|)>>>> #) 85 > >>> (#:G2965) > >>>? #:G2965: # > >>> > >>> #:COMPILER-VAR: (NIL) > >>> #:G2962: # > >>> > >>> (442C10) : 1 (SIGNAL #) 981 > >>> (CONDITION &REST CCL::ARGS) > >>>? CONDITION: # > >>>? CCL::ARGS: NIL > >>> > >>> CCL::%HANDLERS%: ((ERROR) (ERROR)) > >>> CCL::TAG: # > >>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > >>> CCL::FN: # >>> drawRect:]|) #x493DBF> > >>> > >>> (442C68) : 2 (%ERROR # > (:REGISTERS)>>> 558482) 117 > >>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) > >>>? CONDITION: # > >>>? CCL::ARGS: (:REGISTERS) > >>>? CCL::ERROR-POINTER: 558482 > >>> > >>> ... > >>> > >>> Regards, > >>> > >>> Rainer Joswig > >>> > >>> > >>> > >>> Am 09.06.2009 um 07:02 schrieb Ron Garret: > >>> > >>>> Try updating.? The 1.3 branch is currently at verison > r12153M.? It > >>>> works for me on that version. > >>>> > >>>> rg > >>>> > >>>> On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: > >>>> > >>>>> > >>>>> > >>>>> using Clozure Common Lisp Version 1.3-r12088M? > (DarwinX8664)>>>>> > >>>>> > >>>>> On executing the add-subview example form in draggable.lisp > >>>>> > >>>>> I get: > >>>>> > >>>>> *** Error in event process: unknown arg spec :REGISTERS > >>>>> > >>>>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView > drawRect:]|)>>>>>> #) 85 > >>>>> (#:G5085) > >>>>> #:G5085: # > >>>>> > >>>>> #:COMPILER-VAR: (NIL) > >>>>> #:G5082: # > >>>>> > >>>>> (442C10) : 1 (SIGNAL #) 981 > >>>>> (CONDITION &REST CCL::ARGS) > >>>>> CONDITION: # > >>>>> CCL::ARGS: NIL > >>>>> > >>>>> CCL::%HANDLERS%: ((ERROR) (ERROR)) > >>>>> CCL::TAG: # > >>>>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > >>>>> CCL::FN: # [StandardView>>>>> drawRect:]|) #x493DBF> > >>>>> > >>>>> (442C68) : 2 (%ERROR # > (:REGISTERS)>>>>> 558482) 117 > >>>>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) > >>>>> CONDITION: # > >>>>> CCL::ARGS: (:REGISTERS) > >>>>> CCL::ERROR-POINTER: 558482 > >>>>> > >>>>> > >>>>> > >>>>> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS # >>>>> (#x170192C0)> :ADDRESS # CONSTANT-STRING > >>>>> "Lisp Rules!" (#x137CD2F0)> :ADDRESS # >>>>> #x7FFF82F59600> :ADDRESS # >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > >>>>> fobj=0x170178c0, spc=12.00"; > >>>>> } (#x17019E50)> :VOID) 701 > >>>>> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) > >>>>> CCL::ENTRY: 140735390423728 > >>>>> CCL::SPECS-AND-VALS: (:REGISTERS # >>>>> 0x170192c0> (#x170192C0)> :ADDRESS # >>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) > >>>>> > >>>>> CCL::LEN: 9 > >>>>> CCL::TOTAL-WORDS: 0 > >>>>> CCL::RESULT-SPEC: :VOID > >>>>> CCL::NARGS: 4 > >>>>> CCL::N-FP-ARGS: 0 > >>>>> CCL::I: 0 > >>>>> CCL::SPECS: (:REGISTERS # > >>>>> (#x170192C0)> :ADDRESS # >>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) > >>>>> CCL::SPEC: :REGISTERS > >>>>> > >>>>> (442CF8) : 4 (FUNCALL #'# #x300041D9AB4F> # >>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- > >>>>> SELECTOR :NAME "sizeWithAttributes:" :%SEL # Pointer>>>>> #x7FFF82F59600>) # >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > >>>>> fobj=0x170178c0, spc=12.00"; > >>>>> } (#x17019E50)>) 805 > >>>>> (#:G3751 #:G3752 CCL::ARG0) > >>>>> #:G3751: # > >>>>> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL > >>>>> #) > >>>>> CCL::ARG0: # >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > >>>>> fobj=0x170178c0, spc=12.00"; > >>>>> } (#x17019E50)> > >>>>> > >>>>> #:G3753: # [gcable] > (#x17029190)>>>>> #:G3756: # > >>>>> #:G3755: # (#x170192C0)> > >>>>> > >>>>> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND- > UNAMBIGUOUS-MESSAGE > >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION > T)))> # >>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> # MUTABLE-DICTIONARY { > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > >>>>> fobj=0x170178c0, spc=12.00"; > >>>>> } (#x17019E50)>) 501 > >>>>> (CCL::RECEIVER &REST CCL::ARGS) > >>>>> CCL::RECEIVER: # (#x137CD2F0)>>>>>> CCL::ARGS: (# >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > >>>>> fobj=0x170178c0, spc=12.00"; > >>>>> } (#x17019E50)>) > >>>>> > >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME > "sizeWithAttributes:" : > >>>>> %SEL #) > >>>>> FUNCTION: # > >>>>> > >>>>> (442D78) : 6 (FUNCALL #'#<# DRAW-CONTENTS > >>>>> (TEXT-VIEW)>> # # 100 X 100 @ 0,0 > >>>>> (#x7FFF5FBFD370) #x3000420F928D>) 229 > >>>>> (V &OPTIONAL RECT) > >>>>> V: # > >>>>> RECT: # #x3000420F928D>>>>>> > >>>>> > >>>>> > >>>>> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> > >>>>> 17591849974380) 981 > >>>>> (#:G5081) > >>>>> #:G5081: 17591849974380 > >>>>> > >>>>> #:G5088: # > >>>>> #:G5082: # > >>>>> #:COMPILER-VAR: (NIL) > >>>>> #:G5087: # [StandardView>>>>> drawRect:]|) #x493DBF> > >>>>> #:G5089: (CONDITION #) > >>>>> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) > >>>>> SELF: # > (#x170221C0)>>>>>> _CMD: # > >>>>> RECT: # #x3000420F928D>>>>>> > >>>>> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 > >>>>> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > >>>>> CCL::INDEX: 277 > >>>>> CCL::ARGS-PTR-FIXNUM: 17591849974380 > >>>>> > >>>>> CCL::LISP-FUNCTION: # drawRect:]|>>>>> (Non-Global)? #x300041F007BF> > >>>>> WITHOUT-INTERRUPTS: NIL > >>>>> CCL::*CALLBACK-TRACE-P*: NIL > >>>>> > >>>>> (442F08) : 10 (FUNCALL #'# > >>>>> # (#x1C3580)> > >>>>> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # >>>>> #x7FFF82FFFD68>)) 205 > >>>>> (#:G3072 #:G3073) > >>>>> #:G3072: # 0x1c3580> (#x1C3580)> > >>>>> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # >>>>> Pointer #x7FFF82FFFD68>) > >>>>> > >>>>> > >>>>> > >>>>> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND- > UNAMBIGUOUS-MESSAGE > >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION > T)))> # >>>>> APPLICATION (#x1C3580)>) 501 > >>>>> (CCL::RECEIVER &REST CCL::ARGS) > >>>>> CCL::RECEIVER: # 0x1c3580>>>>>> (#x1C3580)> > >>>>> CCL::ARGS: NIL > >>>>> > >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL > # >>>>> Pointer #x7FFF82FFFD68>) > >>>>> FUNCTION: # > >>>>> > >>>>> (442F68) : 12 (EVENT-LOOP NIL) 413 > >>>>> (&OPTIONAL GUI::END-TEST) > >>>>> GUI::END-TEST: NIL > >>>>> > >>>>> GUI::APP: # 0x1c3580> (#x1C3580)> > >>>>> *BREAK-ON-ERRORS*: NIL > >>>>> #:G163537: (ERROR) > >>>>> CCL::%HANDLERS%: ((ERROR)) > >>>>> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (# >>>>> #x3000420F8DBD>) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Am 09.06.2009 um 02:44 schrieb Ron Garret: > >>>>> > >>>>>> [This may be a repeat, but the original never showed up > in my > >>>>>> inbox.? Also, there's an update at the end.] > >>>>>> > >>>>>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: > >>>>>> > >>>>>>> Use #/addTrackingRect:owner:userData:assumeInside: with > >>>>>>> - the view > >>>>>>> - its #/bounds > >>>>>>> - a ns-object as target > >>>>>>> - ccl::+null-ptr+ > >>>>>>> - #$NO > >>>>>>> > >>>>>>> Then > >>>>>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) > >>>>>>> ) ...) > >>>>>>> > >>>>>>> likewise :mouse-exited and :mouse-move > >>>>>> > >>>>>> Thanks!? Updated version enclosed. This has been > tested in 32-bit > >>>>>> CCL, and should now work on Tiger as well. > >>>>>> > >>>>>> This version also fixes a bug whereby testviews did not get > >>>>>> properly re-initialized to add a tracker when the class got > >>>>>> redefined.? I was using an initialize-instance > :after method when > >>>>>> I should have been using shared initialize -- I > think.? There is > >>>>>> still a subtle bug which I can't figure out.? When > you add a > >>>>>> highlighted mixin to an existing testview instance, you > have to > >>>>>> click on it once before it starts to highlight > itself.? I have no > >>>>>> idea why this is happening.? I may not be using > shared-initialize > >>>>>> properly.? Maybe a CLOS wizard can help with some > advice on the > >>>>>> proper way to do this. > >>>>>> > >>>>>> UPDATE: it turns out that the reason for this is that calling > >>>>>> shared-initialize is done lazily.? So until there is an > >>>>>> interaction with the updated object it doesn't get re- > initialized,>>>>>> so add-tracker doesn't get called, so the > event that would > >>>>>> normally cause the interaction never gets received.? > Makes an > >>>>>> interesting little puzzle. > >>>>>> > >>>>>> rg > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>> > >>>>> > >>> > >>> 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 > > > _______________________________________________ > 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 joswig at lisp.de Tue Jun 9 10:15:56 2009 From: joswig at lisp.de (Rainer Joswig) Date: Tue, 9 Jun 2009 19:15:56 +0200 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> <69AF2D4D-A34A-471E-A16C-EE9D93E71262@awun.net> Message-ID: Am 09.06.2009 um 18:04 schrieb Arthur W Cater: > I'm the guilty party for setting, persistently and unintentionally > so, those optimization settings > from within easygui views.lisp. Apologies to all concerned. I > thought the compiler treated these > declarations as affecting the subsequent contents of the source file > in which they appeared > (modulo later declarations in the same overriding them), rather > than causing the form to be > given effect when loading the fasl; must I put it within (eval-when > (:compile-toplevel) ...)? > > I think that file gets loaded as part of (require 'cocoa- > application), not as part of the > startup of the ide-containing image. Using DECLAIM means that the compiler sees the declarations, but the declarations will also be set when the file is loaded (both source and compiled). It is like :EXECUTE, :LOAD-TOPLEVEL and :COMPILE-TOPLEVEL. (declaim (optimize (speed 0) (space 0) (compilation-speed 0) (safety 3) (debug 3))) macro expands to: (use c-m or c-x c-m in Hemlock) (PROGN (EVAL-WHEN (:COMPILE-TOPLEVEL) (CCL::COMPILE-TIME-PROCLAMATION '((OPTIMIZE (SPEED 0) (SPACE 0) (COMPILATION-SPEED 0) (SAFETY 3) (DEBUG 3))) NIL)) (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (PROCLAIM '(OPTIMIZE (SPEED 0) (SPACE 0) (COMPILATION-SPEED 0) (SAFETY 3) (DEBUG 3))))) PROCLAIM does not affect the compile time environment. If you use :COMPILE-TOPLEVEL around DECLAIM or PROCLAIM, I don't know if CCL will remove the declarations after compiling the file. Gary sure knows... Are there other places where DECLAIM is use like this? side note: one thing that was not clear to me for a long time because I never looked it up: :LOAD-TOPLEVEL has only effect in file compiled code. The form is not executed when a source file is loaded. It is executed when a compiled file (fasl) is loaded. Regards, Rainer Joswig > > Arthur > > ----- Original Message ----- > From: Gary Byers > Date: Tuesday, June 9, 2009 2:31 pm > Subject: Re: [Openmcl-devel] ns:ns-tracking-area not present in > 32bit CCL > To: Ron Garret > Cc: openmcl-devel Devel > > > The code that sets the optimization settings (persistently and > > probablynot intentionally so) is in > > ccl/examples/cocoa/easygui/views.lisp. For > > reasons that I don't pretend to understand, that file is loaded > > everytimethat the standalone IDE starts up, but isn't loaded or > > referenced when > > one just does (require "COCOA"). > > > > That's my best guess; if it's not correct and it was more important > > that I can imagine it to be to determine what other difference in > > environment led to to different behavior, then I suppose that - > armed > > with knowledge of what all of those differences are - one could come > > up with a more accurate explanation. > > > > I don't know. To be honest, I don't really care; it seems > > like the > > time spent puzzling over this could be better spent trying to > > fix the bug. > > > > On Tue, 9 Jun 2009, Ron Garret wrote: > > > > > Why is Rainer seeing this bug now and not me? At this > > point we're running > > > the same code on the same CCL version on the same OS X version. > > > > > > rg > > > > > > On Jun 9, 2009, at 4:32 AM, Gary Byers wrote: > > > > > >> The bug's somewhat tersesly described in: > > >> > > >> > > >> > > >> It's still open, though the code in the trunk version of the IDE > > >> that was exposing/triggering the problem has been changed. > > >> > > >> That code can cause the IDE to start up with > > >> > > >> ;;;; see CLtL2; DECLARATION-INFORMATION didn't make it into > > ANSI CL > > >> ? (ccl:declaration-information 'optimize nil) > > >> ((SPEED 0) (SAFETY 3) (COMPILATION-SPEED 0) (SPACE 0) (DEBUG 3)) > > >> > > >> This combination of OPTIMIZE settings causes some rarely-executed > > >> code to be executed, and the real bug is in that code. > > >> (Of course, this should just have the effect of making the > > code as > > >> slow, bloated, and stupid as possible, but it incidentally > exposes > > >> a bug.) > > >> > > >> Untile the real bug is if fixed, you can work around the > > problem by doing: > > >> > > >> ? (declaim (optimize (speed 1) (space 1) (safety 1) (debug 1) > > >> (compilation-speed 1))) > > >> > > >> on startup. > > >> > > >> > > >> > > >> > > >> On Tue, 9 Jun 2009, Rainer Joswig wrote: > > >> > > >>> Same error in Clozure Common Lisp Version 1.3- > > r12235M (DarwinX8664). > > >>> > > >>> Mac OS X 10.5.7 on 64bit Intel... > > >>> > > >>> > > >>> *** Error in event process: unknown arg spec :REGISTERS > > >>> > > >>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView > > drawRect:]|)>>>> #) 85 > > >>> (#:G2965) > > >>> #:G2965: # > > >>> > > >>> #:COMPILER-VAR: (NIL) > > >>> #:G2962: # > > >>> > > >>> (442C10) : 1 (SIGNAL #) 981 > > >>> (CONDITION &REST CCL::ARGS) > > >>> CONDITION: # > > >>> CCL::ARGS: NIL > > >>> > > >>> CCL::%HANDLERS%: ((ERROR) (ERROR)) > > >>> CCL::TAG: # > > >>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > > >>> CCL::FN: # > >>> drawRect:]|) #x493DBF> > > >>> > > >>> (442C68) : 2 (%ERROR # > > (:REGISTERS)>>> 558482) 117 > > >>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) > > >>> CONDITION: # > > >>> CCL::ARGS: (:REGISTERS) > > >>> CCL::ERROR-POINTER: 558482 > > >>> > > >>> ... > > >>> > > >>> Regards, > > >>> > > >>> Rainer Joswig > > >>> > > >>> > > >>> > > >>> Am 09.06.2009 um 07:02 schrieb Ron Garret: > > >>> > > >>>> Try updating. The 1.3 branch is currently at verison > > r12153M. It > > >>>> works for me on that version. > > >>>> > > >>>> rg > > >>>> > > >>>> On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: > > >>>> > > >>>>> > > >>>>> > > >>>>> using Clozure Common Lisp Version 1.3-r12088M > > (DarwinX8664)>>>>> > > >>>>> > > >>>>> On executing the add-subview example form in draggable.lisp > > >>>>> > > >>>>> I get: > > >>>>> > > >>>>> *** Error in event process: unknown arg spec :REGISTERS > > >>>>> > > >>>>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView > > drawRect:]|)>>>>>> #) 85 > > >>>>> (#:G5085) > > >>>>> #:G5085: # > > >>>>> > > >>>>> #:COMPILER-VAR: (NIL) > > >>>>> #:G5082: # > > >>>>> > > >>>>> (442C10) : 1 (SIGNAL #) 981 > > >>>>> (CONDITION &REST CCL::ARGS) > > >>>>> CONDITION: # > > >>>>> CCL::ARGS: NIL > > >>>>> > > >>>>> CCL::%HANDLERS%: ((ERROR) (ERROR)) > > >>>>> CCL::TAG: # > > >>>>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > > >>>>> CCL::FN: # > [StandardView>>>>> drawRect:]|) #x493DBF> > > >>>>> > > >>>>> (442C68) : 2 (%ERROR # > > (:REGISTERS)>>>>> 558482) 117 > > >>>>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) > > >>>>> CONDITION: # > > >>>>> CCL::ARGS: (:REGISTERS) > > >>>>> CCL::ERROR-POINTER: 558482 > > >>>>> > > >>>>> > > >>>>> > > >>>>> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS # > >>>>> (#x170192C0)> :ADDRESS # > CONSTANT-STRING > > >>>>> "Lisp Rules!" (#x137CD2F0)> :ADDRESS # > >>>>> #x7FFF82F59600> :ADDRESS # > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)> :VOID) 701 > > >>>>> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) > > >>>>> CCL::ENTRY: 140735390423728 > > >>>>> CCL::SPECS-AND-VALS: (:REGISTERS # > >>>>> 0x170192c0> (#x170192C0)> :ADDRESS # > >>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) > > >>>>> > > >>>>> CCL::LEN: 9 > > >>>>> CCL::TOTAL-WORDS: 0 > > >>>>> CCL::RESULT-SPEC: :VOID > > >>>>> CCL::NARGS: 4 > > >>>>> CCL::N-FP-ARGS: 0 > > >>>>> CCL::I: 0 > > >>>>> CCL::SPECS: (:REGISTERS # > > >>>>> (#x170192C0)> :ADDRESS # > >>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) > > >>>>> CCL::SPEC: :REGISTERS > > >>>>> > > >>>>> (442CF8) : 4 (FUNCALL #'# > #x300041D9AB4F> # > >>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- > > >>>>> SELECTOR :NAME "sizeWithAttributes:" :%SEL # > Pointer>>>>> #x7FFF82F59600>) # > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)>) 805 > > >>>>> (#:G3751 #:G3752 CCL::ARG0) > > >>>>> #:G3751: # > > >>>>> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" : > %SEL > > >>>>> #) > > >>>>> CCL::ARG0: # > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)> > > >>>>> > > >>>>> #:G3753: # [gcable] > > (#x17029190)>>>>> #:G3756: # > > >>>>> #:G3755: # (#x170192C0)> > > >>>>> > > >>>>> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND- > > UNAMBIGUOUS-MESSAGE > > >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION > > T)))> # > >>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> # > MUTABLE-DICTIONARY { > > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)>) 501 > > >>>>> (CCL::RECEIVER &REST CCL::ARGS) > > >>>>> CCL::RECEIVER: # > (#x137CD2F0)>>>>>> CCL::ARGS: (# > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)>) > > >>>>> > > >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME > > "sizeWithAttributes:" : > > >>>>> %SEL #) > > >>>>> FUNCTION: # > > >>>>> > > >>>>> (442D78) : 6 (FUNCALL #'#<# > DRAW-CONTENTS > > >>>>> (TEXT-VIEW)>> # # > 100 X 100 @ 0,0 > > >>>>> (#x7FFF5FBFD370) #x3000420F928D>) 229 > > >>>>> (V &OPTIONAL RECT) > > >>>>> V: # > > >>>>> RECT: # > #x3000420F928D>>>>>> > > >>>>> > > >>>>> > > >>>>> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> > > >>>>> 17591849974380) 981 > > >>>>> (#:G5081) > > >>>>> #:G5081: 17591849974380 > > >>>>> > > >>>>> #:G5088: # > > >>>>> #:G5082: # > > >>>>> #:COMPILER-VAR: (NIL) > > >>>>> #:G5087: # > [StandardView>>>>> drawRect:]|) #x493DBF> > > >>>>> #:G5089: (CONDITION #) > > >>>>> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) > > >>>>> SELF: # > > (#x170221C0)>>>>>> _CMD: # > > >>>>> RECT: # > #x3000420F928D>>>>>> > > >>>>> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 > > >>>>> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > > >>>>> CCL::INDEX: 277 > > >>>>> CCL::ARGS-PTR-FIXNUM: 17591849974380 > > >>>>> > > >>>>> CCL::LISP-FUNCTION: # > drawRect:]|>>>>> (Non-Global) #x300041F007BF> > > >>>>> WITHOUT-INTERRUPTS: NIL > > >>>>> CCL::*CALLBACK-TRACE-P*: NIL > > >>>>> > > >>>>> (442F08) : 10 (FUNCALL #'# > > >>>>> # (#x1C3580)> > > >>>>> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # > >>>>> #x7FFF82FFFD68>)) 205 > > >>>>> (#:G3072 #:G3073) > > >>>>> #:G3072: # > 0x1c3580> (#x1C3580)> > > >>>>> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # > >>>>> Pointer #x7FFF82FFFD68>) > > >>>>> > > >>>>> > > >>>>> > > >>>>> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND- > > UNAMBIGUOUS-MESSAGE > > >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION > > T)))> # > >>>>> APPLICATION (#x1C3580)>) 501 > > >>>>> (CCL::RECEIVER &REST CCL::ARGS) > > >>>>> CCL::RECEIVER: # > 0x1c3580>>>>>> (#x1C3580)> > > >>>>> CCL::ARGS: NIL > > >>>>> > > >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL > > # > >>>>> Pointer #x7FFF82FFFD68>) > > >>>>> FUNCTION: # > > >>>>> > > >>>>> (442F68) : 12 (EVENT-LOOP NIL) 413 > > >>>>> (&OPTIONAL GUI::END-TEST) > > >>>>> GUI::END-TEST: NIL > > >>>>> > > >>>>> GUI::APP: # > 0x1c3580> (#x1C3580)> > > >>>>> *BREAK-ON-ERRORS*: NIL > > >>>>> #:G163537: (ERROR) > > >>>>> CCL::%HANDLERS%: ((ERROR)) > > >>>>> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (# > >>>>> #x3000420F8DBD>) > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Am 09.06.2009 um 02:44 schrieb Ron Garret: > > >>>>> > > >>>>>> [This may be a repeat, but the original never showed up > > in my > > >>>>>> inbox. Also, there's an update at the end.] > > >>>>>> > > >>>>>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: > > >>>>>> > > >>>>>>> Use #/addTrackingRect:owner:userData:assumeInside: with > > >>>>>>> - the view > > >>>>>>> - its #/bounds > > >>>>>>> - a ns-object as target > > >>>>>>> - ccl::+null-ptr+ > > >>>>>>> - #$NO > > >>>>>>> > > >>>>>>> Then > > >>>>>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) > > >>>>>>> ) ...) > > >>>>>>> > > >>>>>>> likewise :mouse-exited and :mouse-move > > >>>>>> > > >>>>>> Thanks! Updated version enclosed. This has been > > tested in 32-bit > > >>>>>> CCL, and should now work on Tiger as well. > > >>>>>> > > >>>>>> This version also fixes a bug whereby testviews did not get > > >>>>>> properly re-initialized to add a tracker when the class got > > >>>>>> redefined. I was using an initialize-instance > > :after method when > > >>>>>> I should have been using shared initialize -- I > > think. There is > > >>>>>> still a subtle bug which I can't figure out. When > > you add a > > >>>>>> highlighted mixin to an existing testview instance, you > > have to > > >>>>>> click on it once before it starts to highlight > > itself. I have no > > >>>>>> idea why this is happening. I may not be using > > shared-initialize > > >>>>>> properly. Maybe a CLOS wizard can help with some > > advice on the > > >>>>>> proper way to do this. > > >>>>>> > > >>>>>> UPDATE: it turns out that the reason for this is that calling > > >>>>>> shared-initialize is done lazily. So until there is an > > >>>>>> interaction with the updated object it doesn't get re- > > initialized,>>>>>> so add-tracker doesn't get called, so the > > event that would > > >>>>>> normally cause the interaction never gets received. > > Makes an > > >>>>>> interesting little puzzle. > > >>>>>> > > >>>>>> rg > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 > > >>>>> > > >>>>> > > >>> > > >>> 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 > > > > > _______________________________________________ > > 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 From gb at clozure.com Tue Jun 9 10:31:33 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 9 Jun 2009 11:31:33 -0600 (MDT) Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <81DD3097-987D-4B1E-86AB-BE141FDAB81A@awun.net> <69AF2D4D-A34A-471E-A16C-EE9D93E71262@awun.net> Message-ID: You're right; EASYGUI (including that file) is loaded as the IDE is built. DECLAIM's dictionary entry says that DECLAIM will have load-time effects similar to the use of PROCLAIM, but that when it appears as a toplevel form in a file being compiled those effects occur at compile-time; it notes that the compile-time effects may or may not persist after the file has been compiled. (Implementations aren't required to limit the extent of those compile-time effects, though those implementations that I looked at a year or two ago all seemed to do so.) Nothing that I've ever been able to find in the spec seems to allow the implementation to limit the extent of the load-time effects of the macroexpansion of a DECLAIM (presumably PROCLAIM or something very much like it), and the description of PROCLAIM notes that it affects the global environment (defined as "that part of an environment that contains bindings with indefinite scope and indefinite extent.") and that PROCLAIM's effects are always in effect unless locally shadowed. Some implementations limit the extent of the load/execute-time effects of a DECLAIM (so that those effects don't persist after the containing file's been loaded), and there seems to be a lot of publically-available code that assumes that behavior. I don't think that that behavior's correct (though I used to think that it was expedient enough to overlook that.) Among other things, it seems that it should be possible to load a file which contains an OPTIMIZE declamation and have the effect to that declamation persist. Unfortunately (or not), that means that one must be careful to wrap an (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) around a declamation that's intended to only have compile-time effects. On Tue, 9 Jun 2009, Arthur W Cater wrote: > I'm the guilty party for setting, persistently and unintentionally > so, those optimization settingsfrom within easygui views.lisp. Apologies to > all concerned. I thought the compiler treated these > declarations as affecting the subsequent contents of the source file in > which they appeared > (modulo later declarations in the same overriding them), rather than > causing the form to be > given effect when loading the fasl; must I put it within (eval-when > (:compile-toplevel) ...)? > > I think that file gets loaded as part of (require 'cocoa-application), not > as part of the > startup of the ide-containing image. > > Arthur > > ----- Original Message ----- > From: Gary Byers > Date: Tuesday, June 9, 2009 2:31 pm > Subject: Re: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL > To: Ron Garret > Cc: openmcl-devel Devel > > > The code that sets the optimization settings (persistently and > > probablynot intentionally so) is in > > ccl/examples/cocoa/easygui/views.lisp. For > > reasons that I don't pretend to understand, that file is loaded > > everytimethat the standalone IDE starts up, but isn't loaded or > > referenced when > > one just does (require "COCOA"). > > > > That's my best guess; if it's not correct and it was more important > > that I can imagine it to be to determine what other difference in > > environment led to to different behavior, then I suppose that - armed > > with knowledge of what all of those differences are - one could come > > up with a more accurate explanation. > > > > I don't know. To be honest, I don't really care; it seems > > like the > > time spent puzzling over this could be better spent trying to > > fix the bug. > > > > On Tue, 9 Jun 2009, Ron Garret wrote: > > > > > Why is Rainer seeing this bug now and not me? At this > > point we're running > > > the same code on the same CCL version on the same OS X version. > > > > > > rg > > > > > > On Jun 9, 2009, at 4:32 AM, Gary Byers wrote: > > > > > >> The bug's somewhat tersesly described in: > > >> > > >> > > >> > > >> It's still open, though the code in the trunk version of the IDE > > >> that was exposing/triggering the problem has been changed. > > >> > > >> That code can cause the IDE to start up with > > >> > > >> ;;;; see CLtL2; DECLARATION-INFORMATION didn't make it into > > ANSI CL > > >> ? (ccl:declaration-information 'optimize nil) > > >> ((SPEED 0) (SAFETY 3) (COMPILATION-SPEED 0) (SPACE 0) (DEBUG 3)) > > >> > > >> This combination of OPTIMIZE settings causes some rarely-executed > > >> code to be executed, and the real bug is in that code. > > >> (Of course, this should just have the effect of making the > > code as > > >> slow, bloated, and stupid as possible, but it incidentally exposes > > >> a bug.) > > >> > > >> Untile the real bug is if fixed, you can work around the > > problem by doing: > > >> > > >> ? (declaim (optimize (speed 1) (space 1) (safety 1) (debug 1) > > >> (compilation-speed 1))) > > >> > > >> on startup. > > >> > > >> > > >> > > >> > > >> On Tue, 9 Jun 2009, Rainer Joswig wrote: > > >> > > >>> Same error in Clozure Common Lisp Version 1.3- > > r12235M (DarwinX8664). > > >>> > > >>> Mac OS X 10.5.7 on 64bit Intel... > > >>> > > >>> > > >>> *** Error in event process: unknown arg spec :REGISTERS > > >>> > > >>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView > > drawRect:]|)>>>> #) 85 > > >>> (#:G2965) > > >>> #:G2965: # > > >>> > > >>> #:COMPILER-VAR: (NIL) > > >>> #:G2962: # > > >>> > > >>> (442C10) : 1 (SIGNAL #) 981 > > >>> (CONDITION &REST CCL::ARGS) > > >>> CONDITION: # > > >>> CCL::ARGS: NIL > > >>> > > >>> CCL::%HANDLERS%: ((ERROR) (ERROR)) > > >>> CCL::TAG: # > > >>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > > >>> CCL::FN: # > >>> drawRect:]|) #x493DBF> > > >>> > > >>> (442C68) : 2 (%ERROR # > > (:REGISTERS)>>> 558482) 117 > > >>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) > > >>> CONDITION: # > > >>> CCL::ARGS: (:REGISTERS) > > >>> CCL::ERROR-POINTER: 558482 > > >>> > > >>> ... > > >>> > > >>> Regards, > > >>> > > >>> Rainer Joswig > > >>> > > >>> > > >>> > > >>> Am 09.06.2009 um 07:02 schrieb Ron Garret: > > >>> > > >>>> Try updating. The 1.3 branch is currently at verison > > r12153M. It > > >>>> works for me on that version. > > >>>> > > >>>> rg > > >>>> > > >>>> On Jun 8, 2009, at 9:35 PM, Rainer Joswig wrote: > > >>>> > > >>>>> > > >>>>> > > >>>>> using Clozure Common Lisp Version 1.3-r12088M > > (DarwinX8664)>>>>> > > >>>>> > > >>>>> On executing the add-subview example form in draggable.lisp > > >>>>> > > >>>>> I get: > > >>>>> > > >>>>> *** Error in event process: unknown arg spec :REGISTERS > > >>>>> > > >>>>> (442BE8) : 0 (FUNCALL #'#<(:INTERNAL |-[StandardView > > drawRect:]|)>>>>>> #) 85 > > >>>>> (#:G5085) > > >>>>> #:G5085: # > > >>>>> > > >>>>> #:COMPILER-VAR: (NIL) > > >>>>> #:G5082: # > > >>>>> > > >>>>> (442C10) : 1 (SIGNAL #) 981 > > >>>>> (CONDITION &REST CCL::ARGS) > > >>>>> CONDITION: # > > >>>>> CCL::ARGS: NIL > > >>>>> > > >>>>> CCL::%HANDLERS%: ((ERROR) (ERROR)) > > >>>>> CCL::TAG: # > > >>>>> CCL::HANDLERS: CCL::*BACKTRACE-CONTEXTS* > > >>>>> CCL::FN: # > [StandardView>>>>> drawRect:]|) #x493DBF> > > >>>>> > > >>>>> (442C68) : 2 (%ERROR # > > (:REGISTERS)>>>>> 558482) 117 > > >>>>> (CONDITION CCL::ARGS CCL::ERROR-POINTER) > > >>>>> CONDITION: # > > >>>>> CCL::ARGS: (:REGISTERS) > > >>>>> CCL::ERROR-POINTER: 558482 > > >>>>> > > >>>>> > > >>>>> > > >>>>> (442C90) : 3 (%FF-CALL 140735390423728 :REGISTERS # > >>>>> (#x170192C0)> :ADDRESS # > CONSTANT-STRING > > >>>>> "Lisp Rules!" (#x137CD2F0)> :ADDRESS # > >>>>> #x7FFF82F59600> :ADDRESS # > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)> :VOID) 701 > > >>>>> (CCL::ENTRY &REST CCL::SPECS-AND-VALS) > > >>>>> CCL::ENTRY: 140735390423728 > > >>>>> CCL::SPECS-AND-VALS: (:REGISTERS # > >>>>> 0x170192c0> (#x170192C0)> :ADDRESS # > >>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) > > >>>>> > > >>>>> CCL::LEN: 9 > > >>>>> CCL::TOTAL-WORDS: 0 > > >>>>> CCL::RESULT-SPEC: :VOID > > >>>>> CCL::NARGS: 4 > > >>>>> CCL::N-FP-ARGS: 0 > > >>>>> CCL::I: 0 > > >>>>> CCL::SPECS: (:REGISTERS # > > >>>>> (#x170192C0)> :ADDRESS # > >>>>> Rules!" (#x137CD2F0)> :ADDRESS ...) > > >>>>> CCL::SPEC: :REGISTERS > > >>>>> > > >>>>> (442CF8) : 4 (FUNCALL #'# > #x300041D9AB4F> # > >>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> #S(CCL::OBJC- > > >>>>> SELECTOR :NAME "sizeWithAttributes:" :%SEL # > Pointer>>>>> #x7FFF82F59600>) # > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)>) 805 > > >>>>> (#:G3751 #:G3752 CCL::ARG0) > > >>>>> #:G3751: # > > >>>>> #:G3752: #S(CCL::OBJC-SELECTOR :NAME "sizeWithAttributes:" :%SEL > > >>>>> #) > > >>>>> CCL::ARG0: # > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)> > > >>>>> > > >>>>> #:G3753: # [gcable] > > (#x17029190)>>>>> #:G3756: # > > >>>>> #:G3755: # (#x170192C0)> > > >>>>> > > >>>>> (442D38) : 5 (FUNCALL #'#<(:INTERNAL CCL::SEND- > > UNAMBIGUOUS-MESSAGE > > >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION > > T)))> # > >>>>> CONSTANT-STRING "Lisp Rules!" (#x137CD2F0)> # > MUTABLE-DICTIONARY { > > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)>) 501 > > >>>>> (CCL::RECEIVER &REST CCL::ARGS) > > >>>>> CCL::RECEIVER: # > (#x137CD2F0)>>>>>> CCL::ARGS: (# > >>>>> NSFont = "TimesNewRomanPS-ItalicMT 48.00 pt. P [] (0x13799150) > > >>>>> fobj=0x170178c0, spc=12.00"; > > >>>>> } (#x17019E50)>) > > >>>>> > > >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME > > "sizeWithAttributes:" : > > >>>>> %SEL #) > > >>>>> FUNCTION: # > > >>>>> > > >>>>> (442D78) : 6 (FUNCALL #'#<# > DRAW-CONTENTS > > >>>>> (TEXT-VIEW)>> # # > 100 X 100 @ 0,0 > > >>>>> (#x7FFF5FBFD370) #x3000420F928D>) 229 > > >>>>> (V &OPTIONAL RECT) > > >>>>> V: # > > >>>>> RECT: # > #x3000420F928D>>>>>> > > >>>>> > > >>>>> > > >>>>> (442DA0) : 7 (FUNCALL #'#<|-[StandardView drawRect:]|> > > >>>>> 17591849974380) 981 > > >>>>> (#:G5081) > > >>>>> #:G5081: 17591849974380 > > >>>>> > > >>>>> #:G5088: # > > >>>>> #:G5082: # > > >>>>> #:COMPILER-VAR: (NIL) > > >>>>> #:G5087: # > [StandardView>>>>> drawRect:]|) #x493DBF> > > >>>>> #:G5089: (CONDITION #) > > >>>>> CCL::%HANDLERS%: ((CONDITION #) (ERROR)) > > >>>>> SELF: # > > (#x170221C0)>>>>>> _CMD: # > > >>>>> RECT: # > #x3000420F928D>>>>>> > > >>>>> (442E48) : 8 (%PASCAL-FUNCTIONS% 277 17591849974380) 397 > > >>>>> (CCL::INDEX CCL::ARGS-PTR-FIXNUM) > > >>>>> CCL::INDEX: 277 > > >>>>> CCL::ARGS-PTR-FIXNUM: 17591849974380 > > >>>>> > > >>>>> CCL::LISP-FUNCTION: # > drawRect:]|>>>>> (Non-Global) #x300041F007BF> > > >>>>> WITHOUT-INTERRUPTS: NIL > > >>>>> CCL::*CALLBACK-TRACE-P*: NIL > > >>>>> > > >>>>> (442F08) : 10 (FUNCALL #'# > > >>>>> # (#x1C3580)> > > >>>>> #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # > >>>>> #x7FFF82FFFD68>)) 205 > > >>>>> (#:G3072 #:G3073) > > >>>>> #:G3072: # > 0x1c3580> (#x1C3580)> > > >>>>> #:G3073: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL # > >>>>> Pointer #x7FFF82FFFD68>) > > >>>>> > > >>>>> > > >>>>> > > >>>>> (442F28) : 11 (FUNCALL #'#<(:INTERNAL CCL::SEND- > > UNAMBIGUOUS-MESSAGE > > >>>>> (SHARED-INITIALIZE :AFTER (CCL::OBJC-DISPATCH-FUNCTION > > T)))> # > >>>>> APPLICATION (#x1C3580)>) 501 > > >>>>> (CCL::RECEIVER &REST CCL::ARGS) > > >>>>> CCL::RECEIVER: # > 0x1c3580>>>>>> (#x1C3580)> > > >>>>> CCL::ARGS: NIL > > >>>>> > > >>>>> CCL::SELECTOR: #S(CCL::OBJC-SELECTOR :NAME "run" :%SEL > > # > >>>>> Pointer #x7FFF82FFFD68>) > > >>>>> FUNCTION: # > > >>>>> > > >>>>> (442F68) : 12 (EVENT-LOOP NIL) 413 > > >>>>> (&OPTIONAL GUI::END-TEST) > > >>>>> GUI::END-TEST: NIL > > >>>>> > > >>>>> GUI::APP: # > 0x1c3580> (#x1C3580)> > > >>>>> *BREAK-ON-ERRORS*: NIL > > >>>>> #:G163537: (ERROR) > > >>>>> CCL::%HANDLERS%: ((ERROR)) > > >>>>> GUI::*EVENT-PROCESS-REPORTED-CONDITIONS*: (# > >>>>> #x3000420F8DBD>) > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Am 09.06.2009 um 02:44 schrieb Ron Garret: > > >>>>> > > >>>>>> [This may be a repeat, but the original never showed up > > in my > > >>>>>> inbox. Also, there's an update at the end.] > > >>>>>> > > >>>>>> On Jun 8, 2009, at 11:32 AM, Arthur W Cater wrote: > > >>>>>> > > >>>>>>> Use #/addTrackingRect:owner:userData:assumeInside: with > > >>>>>>> - the view > > >>>>>>> - its #/bounds > > >>>>>>> - a ns-object as target > > >>>>>>> - ccl::+null-ptr+ > > >>>>>>> - #$NO > > >>>>>>> > > >>>>>>> Then > > >>>>>>> (objc:define-objc-method ((:void :mouse-entered (:id event)) > > >>>>>>> ) ...) > > >>>>>>> > > >>>>>>> likewise :mouse-exited and :mouse-move > > >>>>>> > > >>>>>> Thanks! Updated version enclosed. This has been > > tested in 32-bit > > >>>>>> CCL, and should now work on Tiger as well. > > >>>>>> > > >>>>>> This version also fixes a bug whereby testviews did not get > > >>>>>> properly re-initialized to add a tracker when the class got > > >>>>>> redefined. I was using an initialize-instance > > :after method when > > >>>>>> I should have been using shared initialize -- I > > think. There is > > >>>>>> still a subtle bug which I can't figure out. When > > you add a > > >>>>>> highlighted mixin to an existing testview instance, you > > have to > > >>>>>> click on it once before it starts to highlight > > itself. I have no > > >>>>>> idea why this is happening. I may not be using > > shared-initialize > > >>>>>> properly. Maybe a CLOS wizard can help with some > > advice on the > > >>>>>> proper way to do this. > > >>>>>> > > >>>>>> UPDATE: it turns out that the reason for this is that calling > > >>>>>> shared-initialize is done lazily. So until there is an > > >>>>>> interaction with the updated object it doesn't get re- > > initialized,>>>>>> so add-tracker doesn't get called, so the > > event that would > > >>>>>> normally cause the interaction never gets received. > > Makes an > > >>>>>> interesting little puzzle. > > >>>>>> > > >>>>>> rg > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 > > >>>>> > > >>>>> > > >>> > > >>> 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 > > > > > _______________________________________________ > > Openmcl-devel mailing list > > Openmcl-devel at clozure.com > > http://clozure.com/mailman/listinfo/openmcl-devel > > From raffaelcavallaro at mac.com Tue Jun 9 11:53:04 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Tue, 09 Jun 2009 14:53:04 -0400 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <436DB8C9-CE32-4EF6-9D10-5976F5DAA0B4@awun.net> Message-ID: <810C0145-6561-4ADB-9E12-08B67D739ABD@mac.com> On Jun 9, 2009, at 9:06 AM, Ron Garret wrote: > Looks to me like you might be using an older version of > utilities.lisp (or you have an old fasl32 lying around). This must have been it - I downloaded a fresh version of your utilities from my imap server and it works fine now in CCL32 as well. Something I find really cool is that command-dragging works as well - you can execute the code after ; This is the cool part with the editor window foreground, and cmd-dragging on the text will move it around even though it isn't in the foreground window. You can also cmd-drag it when it's not the foreground application! BTW, I just noticed that dictionary lookup now works in editor panes (cmd-ctl-d when the mouse is over a word). warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From gb at clozure.com Tue Jun 9 12:52:20 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 9 Jun 2009 13:52:20 -0600 (MDT) Subject: [Openmcl-devel] Binary IO... In-Reply-To: <1244557724.2420.202.camel@sirius> References: <1244408197.2420.175.camel@sirius> <1244472082.2420.187.camel@sirius> <1244557724.2420.202.camel@sirius> Message-ID: If a file stream is opened with :direction :io, then there's a single underlying FD that can be used for reading and writing, and STREAM-DEVICE should return the same value for :INPUT and :OUTPUT. (A TWO-WAY-STREAM is generally composed of separate input and output streams that may have underlying FDs that're distinct). On Tue, 9 Jun 2009, Jon S. Anthony wrote: > > This appears to be pretty much exactly what I need. Since these vectors > behave like "regular vectors" in normal code, I really don't even need > the capabilities of WITH-HEAP-IVECTOR (at least I don't now think > so...). The only thing left is the ability to have (or simulate) a > bidirectional stream with this. > > So, is it legitimate to do this sort of thing (basically use the same > stream for reading and writing)? Or can there be two separate streams > open at the same time for the same file (one for input, one for output)? > I'd assume that reading and writing the same file (via separate streams/fds) could be problematic; I don't know how much the OS tries to ensure that the right things happen (e.g., that the reader will always see what the writer writes, even if readahead and caching mechanisms had prepared it to see something else.) I don't know, though, and if I ever knew anything useful about this I've forgotten it. If there are issues there, it seems likely that those issues aren't lisp- or CCL-specific. From j-anthony at comcast.net Tue Jun 9 15:52:11 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Tue, 09 Jun 2009 18:52:11 -0400 Subject: [Openmcl-devel] Binary IO... In-Reply-To: References: <1244408197.2420.175.camel@sirius> <1244472082.2420.187.camel@sirius> <1244557724.2420.202.camel@sirius> Message-ID: <1244587931.2420.224.camel@sirius> Hi Gary, Thanks for the help and information. The enclosed file shows a starting proof of concept that works exactly as wanted/expected. Just as fast as the C code!: (time (main2 nil)) (MAIN2 NIL) took 832 milliseconds (0.832 seconds) to run with 2 available CPU cores. During that period, 0 milliseconds (0.000 seconds) were spent in user mode 820 milliseconds (0.820 seconds) were spent in system mode 2,744 bytes of memory allocated. 1 minor page faults, 0 major page faults, 0 swaps. And results: (time (main2 32)) (MAIN2 32) took 1,311 milliseconds (1.311 seconds) to run with 2 available CPU cores. During that period, 488 milliseconds (0.488 seconds) were spent in user mode 804 milliseconds (0.804 seconds) were spent in system mode 2,744 bytes of memory allocated. 1 minor page faults, 0 major page faults, 0 swaps. T ? (subseq (second *input-page*) 0 12) #(32 32 32 32 32 32 32 32 32 32 32 32) Just works. BTW, are stuff like ccl:make-heap-ivector, ccl:stream-device, #_lseek, #_read, #_write, etc. indicated as being available somewhere? I scanned the documentation but don't see them there. Thanks again! /Jon On Tue, 2009-06-09 at 13:52 -0600, Gary Byers wrote: > If a file stream is opened with :direction :io, then there's a single > underlying FD that can be used for reading and writing, and STREAM-DEVICE > should return the same value for :INPUT and :OUTPUT. > > (A TWO-WAY-STREAM is generally composed of separate input and output streams > that may have underlying FDs that're distinct). > > On Tue, 9 Jun 2009, Jon S. Anthony wrote: > > > > > This appears to be pretty much exactly what I need. Since these vectors > > behave like "regular vectors" in normal code, I really don't even need > > the capabilities of WITH-HEAP-IVECTOR (at least I don't now think > > so...). The only thing left is the ability to have (or simulate) a > > bidirectional stream with this. > > > > So, is it legitimate to do this sort of thing (basically use the same > > stream for reading and writing)? Or can there be two separate streams > > open at the same time for the same file (one for input, one for output)? > > > > I'd assume that reading and writing the same file (via separate streams/fds) > could be problematic; I don't know how much the OS tries to ensure that > the right things happen (e.g., that the reader will always see what > the writer writes, even if readahead and caching mechanisms had prepared > it to see something else.) > > I don't know, though, and if I ever knew anything useful about this I've > forgotten it. If there are issues there, it seems likely that those issues > aren't lisp- or CCL-specific. -------------- next part -------------- A non-text attachment was scrubbed... Name: megabyte-binary-io.lisp Type: text/x-emacs-lisp Size: 3133 bytes Desc: not available URL: From ron at awun.net Tue Jun 9 16:16:04 2009 From: ron at awun.net (Ron Garret) Date: Tue, 9 Jun 2009 16:16:04 -0700 Subject: [Openmcl-devel] ns:ns-tracking-area not present in 32bit CCL In-Reply-To: <810C0145-6561-4ADB-9E12-08B67D739ABD@mac.com> References: <434D9F6F-C4AC-4C55-8016-78DDD6D13289@mac.com> <2E0D8214-6499-4335-A30D-7D1F32A3401B@awun.net> <436DB8C9-CE32-4EF6-9D10-5976F5DAA0B4@awun.net> <810C0145-6561-4ADB-9E12-08B67D739ABD@mac.com> Message-ID: <34534C5B-899D-458C-91BA-4244C4A35E2B@awun.net> On Jun 9, 2009, at 11:53 AM, Raffael Cavallaro wrote: > > On Jun 9, 2009, at 9:06 AM, Ron Garret wrote: > >> Looks to me like you might be using an older version of >> utilities.lisp (or you have an old fasl32 lying around). > > This must have been it - I downloaded a fresh version of your > utilities from my imap server and it works fine now in CCL32 as well. > Cool! Just FYI, I have decided I don't like the syntax I chose for shared slots, so the next release of utilities will have that changed in a non-backwards-compatible way. I mention this just on the off chance that anyone here is planning to write code using define-class. > Something I find really cool is that command-dragging works as well - > you can execute the code after > > ; This is the cool part > > with the editor window foreground, and cmd-dragging on the text will > move it around even though it isn't in the foreground window. You can > also cmd-drag it when it's not the foreground application! Yes, Cocoa is quite the wizzy framework. rg From mevins at mac.com Tue Jun 9 18:08:26 2009 From: mevins at mac.com (mikel evins) Date: Tue, 09 Jun 2009 20:08:26 -0500 Subject: [Openmcl-devel] ccl's swank-listener thingie Message-ID: <7646B7BF-DD57-4B40-B2A8-32C48632AC5E@mac.com> In recent trunk revisions of Clozure CL, the IDE includes a relatively unobtrusive new feature: it is possible to start a "swank-listener", either on launch, or by clicking a "Start now" button in the Preferences window. This is a new and experimental feature of the IDE. It has existed just long enough now without causing plagues, fires, and other disasters, that I'm now willing to describe its intended use. The code is young, and there are a jillion ways it can go wrong. Don't be surprised if it sneaks out with your Significant Other and sells your car for money to buy weapons of mass destruction. Anyhow, the intended use is: 1. Start the swank listener 2. Request a swank connection to a running CCL IDE 3. Shazam! SLIME is connected and working Okay, so what? What's different from what SLIME has always done? The main difference is that the CCL IDE in this case did not have SLIME's swank server loaded when we asked for a connection. Instead, the swank-listener code loads swank on demand and then completes the connection. Okay, why would we want to do that? Well, we could build swank into the CCL IDE, of course. But the swank protocol changes from time to time, and we were concerned that it would be a pain for people if they had to use some particular special version of SLIME just to interact with the CCL IDE. Also, sometimes when you're building a Cocoa app in Lisp, you want to be disciplined about what things you build into it, for reasons of debugging sanity, or security, or whatever. So it seemed like it might be useful to provide a way, during app development, to get a SLIME connection to a Cocoa app that wouldn't normally have swank built into it. So swank-listener is a means of asking a running CCL IDE for a SLIME/ swank connection, even when it doesn't have swank built into it. So how does one use it? I. Needed parts There are two pieces that make this thing work (assuming it does work): swank-ccl-ide.el An Emacs Lisp file that handles the Emacs side of things. swank-listener A Common-Lisp file that handles the CCL side of things II. How to use them 1. Modify your emacs startup so that swank-ccl-ide.el is loaded after slime. 2. Start up the CCL IDE, and make sure the swank-listener is running. When the swank listener is running, the value of gui::*ccl-swank- listener-active-p* should be T, and the value of gui::*active-gui- swank-listener-port* should be the port it's actually listening on. The Preferences window for the CCL IDE has, in the General tab, a couple of controls for the swank listener. Check the checkbox to make the swank listener run the next time the IDE is launched. Type in a port number (if you want to use something different from the default 4884). If you want to start the swank listener at once, click the "Start now" button. The "Start now" button does not affect the preference setting, by the way. 3. Make Emacs evaluate (request-ccl-load-swank). You can eval it in a buffer, or bind it to a key, or whatever you wish. If things are set up right, there will be a brief delay as the CCL IDE compiles and loads the swank code, and then you should have a live SLIME connection to the running CCL IDE. (When the swank code is already compiled, connecting is very quick). If you don't change any of the defaults, and if nothing else is using the default ports, then the connection should work. If you change the port that the swank-listener listens on, then you'll also need to change the value of *ccl-swank-listener-port* in the elisp file. If you want to change the port used for the SLIME/swank connection, pass it as an argument to the request function. For example, if you want the SLIME/swank connection to use port 5001, then call the emacs-lisp request function like this: (request-ccl-load-swank nil nil 5001) Nil arguments cause the request to use the default values for those parameters. III. What they do When it starts up, the swank listener creates a thread that waits for a connection on the swank-listener port (by default, 4884). If such a connection occurs, the swank-listener tries to read a line of text from it. If it gets a line of text, it assumes that it will be the string "[emacs-ccl-swank-request]" followed by a port number, a colon, and a filesystem path. The swank listener splits the port number and path from the message. It looks to see if the path names an existing file; if so, it loads that file and then attempts to load swank and create a swank server on the supplied port number. If that all succeeds, then the swank listener writes a message back to the connected client, telling it the port number that swank is listening on. On the Emacs side, calling (request-ccl-load-swank) opens a client connection on localhost, on the *ccl-swank-listener-port*, and attempts to write a line of text containing "[emacs-ccl-swank- request]" followed by the port number and pathname specified in the parameters to request-ccl-load-swank. By default, the port number is the value of the SLIME variable slime-port, and the pathname is the value returned by (swank-loader-path) (which is just the value of the SLIME variable slime-path, with the string "swank-loader.lisp" appended). In other words, the emacs code tells CCL that it wants CCL to load the swank code from the SLIME version that is currently loaded in Emacs, and use it to start a swank server. CCL either succeeds, and writes back to Emacs a message saying so, or it fails, and writes back a message that says it failed, and its best understanding of why it failed (which Emacs then displays as a minibuffer message). If CCL says it succeeded, then Emacs believes it, and tries to open a normal SLIME connection on the port CCL told it. If all went well, then a normal SLIME/swank session ensues. There are a zillion ways for this to go wrong, and I'm pretty sure I have not found and guarded against them all. If you decide to play with this facility, and you find hideous bugs, feel free to report them, and I'll do my best to fix the most hideous ones. --me From raffaelcavallaro at mac.com Tue Jun 9 21:46:26 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Wed, 10 Jun 2009 00:46:26 -0400 Subject: [Openmcl-devel] ccl's swank-listener thingie In-Reply-To: <7646B7BF-DD57-4B40-B2A8-32C48632AC5E@mac.com> References: <7646B7BF-DD57-4B40-B2A8-32C48632AC5E@mac.com> Message-ID: On Jun 9, 2009, at 9:08 PM, mikel evins wrote: > The code is young, and there are a jillion ways it can go wrong. Don't > be surprised if it sneaks out with your Significant Other and sells > your car for money to buy weapons of mass destruction. No wonder they call it SLIME. :) Raffael Cavallaro raffaelcavallaro at me.com From gb at clozure.com Wed Jun 10 02:56:48 2009 From: gb at clozure.com (Gary Byers) Date: Wed, 10 Jun 2009 03:56:48 -0600 (MDT) Subject: [Openmcl-devel] Binary IO... In-Reply-To: <1244587931.2420.224.camel@sirius> References: <1244408197.2420.175.camel@sirius> <1244472082.2420.187.camel@sirius> <1244557724.2420.202.camel@sirius> <1244587931.2420.224.camel@sirius> Message-ID: On Tue, 9 Jun 2009, Jon S. Anthony wrote: > > BTW, are stuff like ccl:make-heap-ivector, ccl:stream-device, #_lseek, > #_read, #_write, etc. indicated as being available somewhere? I scanned > the documentation but don't see them there. > CCL:MAKE-HEAP-IVECTOR's referenced in a tutorial in the documentation and I'd thought that it was described in release notes for some earlier version, but can't find it if so. It and other things that're exported from the CCL package are intended to be available and to rarely change (and should be documented.) The #_ reader macro is used to call foreign functions, and it and the rest of the FFI are pretty well documented. Standard C library things like #_read and #_write are documented (from the C point of view, at least) in the Unix man pages; depending on what OS you use, those pages are either preinstalled, installed as part of a "developer tools" package (OSX), or available through your distribution's package management system (yum, apt, whatever on Linux.) You can read man pages in the shell with the 'man' command: $ man lseek or in Emacs with 'm-x man'. (Googling can probably tell you more about using 'man' than I can, and many sites provide online HTML versions of OS man pages.) From gz at clozure.com Wed Jun 10 03:33:25 2009 From: gz at clozure.com (Gail Zacharias) Date: Wed, 10 Jun 2009 06:33:25 -0400 Subject: [Openmcl-devel] User contributions Message-ID: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> We have added a "ccl:contrib;" directory to CCL for distributing user-contributed software. It's in the trunk and will be included starting with the next release. To contribute, you can send your file (or zipped up directory) to openmcl-devel clearly saying that you want it to go into the CCL contrib directory. Better yet, ask for write access to the subversion repository and add it yourself -- that way you can also update it as needed. I hope some of the neat examples that have been floating around the list lately will make it into contrib! From thecodewitch at gmail.com Wed Jun 10 16:03:27 2009 From: thecodewitch at gmail.com (Greg Santucci) Date: Thu, 11 Jun 2009 10:03:27 +1100 Subject: [Openmcl-devel] Clozure Emacs/Slime problem in Win32 Message-ID: <66c9435a0906101603r6f222dc6u1a5ff4c996bf4269@mail.gmail.com> I've encountered a small problem when using Clozure with Emacs/slime. When I try (cl-glut-examples:gears) at the slime "inferior-lisp" repl, the example runs normally. When I try it in the normal repl buffer, it will work only if I did it in the "inferior-lisp" repl first. If not, the window doesn't appear, and the repl says nothing. I can't find any error messages or prompts in the other buffers. If at the "inferior-lisp" repl I run another example, such as (cl-glut-examples:rb-robot), suddenly both the robot and gears windows appear and run normally. Interestingly, this problem doesn't occur with lispbuilder-sdl examples. This is my .emacs (for Win32, its _emacs): (setq inferior-lisp-program "C:/lispbox/ccl/wx86cl.exe") ; your Lisp system (add-to-list 'load-path "C:/lispbox/slime-2009-05-31") ; your SLIME directory (require 'slime) (slime-setup '(slime-scratch slime-editing-commands slime-repl slime-mrepl)) Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.anderson at setf.de Thu Jun 11 00:32:47 2009 From: james.anderson at setf.de (james anderson) Date: Thu, 11 Jun 2009 09:32:47 +0200 Subject: [Openmcl-devel] ? jfli Message-ID: good morning; is anyone using the ccl jfli port? i observe that, for ccl1.3 on os x, the entry point name in the call to create a jvn lacks an initial "_" [http://trac.clozure.com/ccl/ browser/release/1.3/source/examples/jfli/jni.lisp?rev=11690#L1156], which makes one wonder. thanks, From edmund at furse.f2s.com Thu Jun 11 04:19:49 2009 From: edmund at furse.f2s.com (Edmund Furse) Date: Thu, 11 Jun 2009 12:19:49 +0100 Subject: [Openmcl-devel] Large arrays in 1.3 Message-ID: I can build large bit arrays in ccl 1.2 but not in 1.3 Here is an example (defvar xi29) (defvar max) (setq max (+ (product-of-primes 29) 600)) (prog () (setq xi29 (make-array (list max) :element-type 'bit)) (return 'ok)) The product of the primes is 6469693230. This works fine in ccl 1.2, but in 1.3 it freezes the application. Any ideas? Edmund Furse From gb at clozure.com Thu Jun 11 04:41:06 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 11 Jun 2009 05:41:06 -0600 (MDT) Subject: [Openmcl-devel] Large arrays in 1.3 In-Reply-To: References: Message-ID: describes a similar symptom (that wasn't actaully limited to the Cocoa IDE) that was fixed in svn in both the trunk and 1.3 a few months ago. If you haven't updated from svn and rebuilt the lisp recently, please do so. On Thu, 11 Jun 2009, Edmund Furse wrote: > I can build large bit arrays in ccl 1.2 but not in 1.3 > > Here is an example > > (defvar xi29) > (defvar max) > (setq max (+ (product-of-primes 29) 600)) > (prog () (setq xi29 (make-array (list max) :element-type 'bit)) > (return 'ok)) > > The product of the primes is 6469693230. > > This works fine in ccl 1.2, but in 1.3 it freezes the application. > > Any ideas? > > Edmund Furse > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From taoufik.dachraoui at wanadoo.fr Thu Jun 11 05:40:14 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 14:40:14 +0200 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed Message-ID: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> Hi I tried to modify the lisp reader such that the use of :: is disallowed (throws an error) but failed. I tried to use set-macro-character and set-dispatch-macro-character without success. example: ? ... set new lisp reader .... ? test::x Error: access to not exported symbols is forbidden Kind regards -Taoufik From gb at clozure.com Thu Jun 11 05:39:08 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 11 Jun 2009 06:39:08 -0600 (MDT) Subject: [Openmcl-devel] ? jfli In-Reply-To: References: Message-ID: I don't know if anyone's using the jfli port or not, but whether they are or not has nothing to do with whether entry point names have leading underscores on Darwin. The old way of looking up the addresses of foreign symbols on Darwin (which viewed all external symbols as having leading underscores and required its argument to have such a leading underscore) has been deprecated (certainly as of Tiger, possibly before - it's been a few years) in favor of a new (previously deprecated) way which pretends that Darwin symbols don't have leading underscores (at a lower level, they still do) and which strips an initial leading underscore from its argument. So: ? (foreign-symbol-address "read") # ? (foreign-symbol-address "_read") # the leading underscore is usually optional, and Apple has cleverly designed a symbol-lookup mechanism that makes it awkward to refer to foreign symbols that actually have meaningful leading underscores in their C-visible names. (But I digress ...). You're correct in noting that if the advocated way of resolving foreign symbol addresses on Darwin still required its argument to have a leading underscore the jfli example (and lots of other things, including lots of code in CCL itself) wouldn't work. Those things generally do (or at least aren't affected by this ...), and AFAIK jfli more-or-less does as well. (The "or less" parts that I'm aware of have to do with JNI objects not being freed when they should be, and the general plan is to RTFJNIM to get a clearer idea of when they should be.) What's there does seem to work at least well enough to run simple demos, including the simple SWT demo that's included (assuming that you can find an SWT library for your platform and can adjust the paths to it and the JFM that're hardwired into the examples.) One platform for which there was not a released SWT library (unless it's been released very recently) is 64-bit OSX: the OSX version of SWT has been based on Carbon (and is therefore 32-bit only), though work on a Cocoa-based version is ongoing.) Nick Levine made some changes to Rich Hickey's original jfli code a year or so ago; I wasn't aware of those changes when I did the CCL port last winter. Nick's changes include improvements to pathname handling and ways of abstracting away some Windows/Unix differences, and it'd be good to merge those changes into the CCL port when time permits. There's quite a bit of distance between being able to jump through a few hoops and get an SWT window to appear (using mostly platform-neutral code) and having a rich interface to a mature cross-platform GUI toolkit, but getting that window to appear is a necessary step towards something more interesting. (Or at least "maybe interesting.") On Thu, 11 Jun 2009, james anderson wrote: > good morning; > > is anyone using the ccl jfli port? > i observe that, for ccl1.3 on os x, the entry point name in the call > to create a jvn lacks an initial "_" [http://trac.clozure.com/ccl/ > browser/release/1.3/source/examples/jfli/jni.lisp?rev=11690#L1156], > which makes one wonder. > > thanks, > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From taoufik.dachraoui at wanadoo.fr Thu Jun 11 07:14:42 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 16:14:42 +0200 Subject: [Openmcl-devel] CCL::WITH-TOKEN-BUFFER Message-ID: Hi, How to use CCL::WITH-TOKEN-BUFFER ? >ccl Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinX8632)! ? (find-symbol "WITH-TOKEN-BUFFER" "CCL") NIL NIL ? (ccl::with-token-buffer (tb) (prin1 tb)) > Error: Undefined function TB called with arguments () . > While executing: CCL::CHEAP-EVAL-IN-ENVIRONMENT, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Retry applying TB to NIL. > Type :? for other options. 1 > The error is caused because the macro WITH-TOKEN-BUFFER is not defined The macro WITH-TOKEN-BUFFER is defined in l1-reader.lisp Why I cannnot use this macro? Kind regards -Taoufik From taoufik.dachraoui at wanadoo.fr Thu Jun 11 07:20:19 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 16:20:19 +0200 Subject: [Openmcl-devel] modify lisp reader Message-ID: <9FB0F72D-9F21-4B70-94F4-2E6017306E97@wanadoo.fr> Hi I would like to modify the lisp reader as follows: 1. add parameter *use-double-colon* (default to t) 2. when (null *use-double-colon*) then the lisp reader must reject any use of double colon Example: (let ((*use-double-colon* nil)) (read-from-string "test::x")) => Error: use of double colons are not allowed Kind regards -Taoufik From hans.huebner at gmail.com Thu Jun 11 07:28:29 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 11 Jun 2009 10:28:29 -0400 Subject: [Openmcl-devel] modify lisp reader In-Reply-To: <9FB0F72D-9F21-4B70-94F4-2E6017306E97@wanadoo.fr> References: <9FB0F72D-9F21-4B70-94F4-2E6017306E97@wanadoo.fr> Message-ID: Taoufik, you may be interested in http://darcs.informatimago.com/darcs/public/lisp/common-lisp/reader.lisp - It is a GPL'ed implementation of the Common Lisp reader. If you use that instead of hacking CCL's internals, you may end up with a portable solution. The CL reader, albeit being somewhat extensible, is really not meant to be flexible enough for implementing sandboxes, source code processors and the like. You will always have to resort to non-portable hacks, and the lack of a specification for that kind of things makes such hacks inherently risky (i.e. you need to completely understand all of the reader to make sure that no escape paths exist). -Hans On Thu, Jun 11, 2009 at 10:20, Taoufik Dachraoui wrote: > Hi > > I would like to modify the lisp reader as follows: > > > 1. add parameter *use-double-colon* ?(default to t) > 2. when (null *use-double-colon*) then the lisp reader must reject any > use of double colon > > Example: > > (let ((*use-double-colon* nil)) > ? ? ? ?(read-from-string "test::x")) > => Error: use of double colons are not allowed > > > Kind regards > > -Taoufik > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > From rpgoldman at sift.info Thu Jun 11 07:54:02 2009 From: rpgoldman at sift.info (Robert P. Goldman) Date: Thu, 11 Jun 2009 9:54:02 -0500 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> Message-ID: <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> This seems like a mistake, anyway, because this won't stop a user from typing (eval (list (intern "ERASE-TAOUFIKS-HARD-DRIVE" (find-package :private-package)))) I continue to think that trying to sandbox common lisp is a very big project for a novice. The browser builders are often getting sandboxing wrong for javascript, wh?ch is a much simpler language. ___ Robert P. Goldman Principal Scientist, SIFT, LLC www.sift.info ..... Original Message ....... On Thu, 11 Jun 2009 14:40:14 +0200 "Taoufik Dachraoui" wrote: >Hi > >I tried to modify the lisp reader such that the use of :: is >disallowed (throws an error) but failed. > >I tried to use set-macro-character and set-dispatch-macro-character >without success. > >example: > >? ... set new lisp reader .... >? test::x >Error: access to not exported symbols is forbidden > > >Kind regards > >-Taoufik > >_______________________________________________ >Openmcl-devel mailing list >Openmcl-devel at clozure.com >http://clozure.com/mailman/listinfo/openmcl-devel From taoufik.dachraoui at wanadoo.fr Thu Jun 11 08:09:35 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 17:09:35 +0200 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> Message-ID: <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> Hi Users will not have access to intern, find-package, ... I implemented a loader that exports public symbols and shadow unwanted symbols so that users will not be able to use any private or shadowed symbols. the only problem I am facing today (as far as I can see right now) is to disallow users to access non exported symbols by using the double colons (::) I tried to use set-macro-character and set-dispatch-macro-character but failed, and the reason is that the lisp reader as soon as it finds a macro- character the previously read word will be considered as a token and there is no way to rollback. For this reason I am trying to find a hack to modify the ccl lisp reader as follows: 1. add parameter *use-double-colon* (default to t) 2. when (null *use-double-colon*) then the lisp reader must reject any use of double colon Example: (let ((*use-double-colon* nil)) (read-from-string "test::x")) => Error: use of double colons are not allowed The portability is not an issue for me (at least now), and would like to hack the ccl lisp reader for performance reason (eg. do not want to use a new lisp reader on top of the already existing ccl lisp reader) Kind regards -Taoufik On Jun 11, 2009, at 4:54 PM, Robert P. Goldman wrote: > > This seems like a mistake, anyway, because this won't stop a user > from typing > > (eval (list (intern "ERASE-TAOUFIKS-HARD-DRIVE" (find- > package :private-package)))) > > I continue to think that trying to sandbox common lisp is a very big > project for a novice. > > The browser builders are often getting sandboxing wrong for > javascript, wh?ch is a much simpler language. > ___ > Robert P. Goldman > Principal Scientist, SIFT, LLC > www.sift.info > > ..... Original Message ....... > On Thu, 11 Jun 2009 14:40:14 +0200 "Taoufik Dachraoui" > wrote: >> Hi >> >> I tried to modify the lisp reader such that the use of :: is >> disallowed (throws an error) but failed. >> >> I tried to use set-macro-character and set-dispatch-macro-character >> without success. >> >> example: >> >> ? ... set new lisp reader .... >> ? test::x >> Error: access to not exported symbols is forbidden >> >> >> Kind regards >> >> -Taoufik >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel at clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel > > From raffaelcavallaro at mac.com Thu Jun 11 08:41:07 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Thu, 11 Jun 2009 11:41:07 -0400 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> Message-ID: <2494A0CB-00F5-4552-BDB3-3636A7B06F7F@mac.com> On Jun 11, 2009, at 11:09 AM, Taoufik Dachraoui wrote: > the only problem I am facing today (as far as I can see right now) > is to > disallow users to access non exported symbols by using the double > colons (::) I agree with Robert Goldman that this is a daunting undertaking with many ways to lose; for this particular problem, you may want to take input as strings, parse them for colons yourself, and only then hand them off to the lisp reader. regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From rpgoldman at sift.info Thu Jun 11 08:53:26 2009 From: rpgoldman at sift.info (Robert Goldman) Date: Thu, 11 Jun 2009 10:53:26 -0500 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <2494A0CB-00F5-4552-BDB3-3636A7B06F7F@mac.com> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <2494A0CB-00F5-4552-BDB3-3636A7B06F7F@mac.com> Message-ID: <4A312876.4050404@sift.info> Raffael Cavallaro wrote: > On Jun 11, 2009, at 11:09 AM, Taoufik Dachraoui wrote: > >> the only problem I am facing today (as far as I can see right now) >> is to >> disallow users to access non exported symbols by using the double >> colons (::) > > I agree with Robert Goldman that this is a daunting undertaking with > many ways to lose; for this particular problem, you may want to take > input as strings, parse them for colons yourself, and only then hand > them off to the lisp reader. > Also, it doesn't seem clear to me that running all the users in a single lisp process is a win, instead of letting the OS help you by giving different processes to different users. Cheers, r From ron at awun.net Thu Jun 11 08:56:58 2009 From: ron at awun.net (Ron Garret) Date: Thu, 11 Jun 2009 08:56:58 -0700 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> Message-ID: <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote: > Hi > > Users will not have access to intern, find-package, ... > > I implemented a loader that exports public symbols and shadow unwanted > symbols > so that users will not be able to use any private or shadowed symbols. > > the only problem I am facing today (as far as I can see right now) > is to > disallow users to access non exported symbols by using the double > colons (::) > The "as far as I can see right now" is a very important disclaimer. The main problem with security is that there's a very big gap between appearing to be secure and actually being secure. People make careers out of bridging that gap, and still very often they get it wrong. Not that I really want to discourage you -- it's good that you're being ambitious, but it's important that you understand the magnitude of the problem you are attempting to solve. > I tried to use set-macro-character and set-dispatch-macro-character > but failed, and > the reason is that the lisp reader as soon as it finds a macro- > character the previously > read word will be considered as a token and there is no way to > rollback. Why is that a problem? Is there a reason you don't just pre-process the string to remove all colons before reading it? Or simply reject any string containing colons? rg From taoufik.dachraoui at wanadoo.fr Thu Jun 11 09:03:21 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 18:03:21 +0200 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> Message-ID: <6E7AB2CF-250E-4D16-93D3-4A7D14E32A14@wanadoo.fr> Hi The best I could find without hacking the ccl lisp reader is the following: (defparameter *secure-readtable* (copy-readtable nil)) (set-macro-character #\: #'(lambda (s c) (declare (ignore s c)) (progn (setq *readtable* (copy-readtable nil)) (error "use of colons is not allowed"))) nil *secure-readtable*) Example: ? (let ((*readtable* *secure-readtable*)) (read)) :x > Error: use of colons is not allowed > While executing: #, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > (get-macro-character #\:) NIL NIL 1 > :pop ? But with this, users will not be able to use keywords either. Is there a way to know if the colon is the first character in the token? Does the reader has accessible working variables that we can consult? Kind regards -Taoufk On Jun 11, 2009, at 4:54 PM, Robert P. Goldman wrote: > > This seems like a mistake, anyway, because this won't stop a user > from typing > > (eval (list (intern "ERASE-TAOUFIKS-HARD-DRIVE" (find- > package :private-package)))) > > I continue to think that trying to sandbox common lisp is a very big > project for a novice. > > The browser builders are often getting sandboxing wrong for > javascript, wh?ch is a much simpler language. > ___ > Robert P. Goldman > Principal Scientist, SIFT, LLC > www.sift.info > > ..... Original Message ....... > On Thu, 11 Jun 2009 14:40:14 +0200 "Taoufik Dachraoui" > wrote: >> Hi >> >> I tried to modify the lisp reader such that the use of :: is >> disallowed (throws an error) but failed. >> >> I tried to use set-macro-character and set-dispatch-macro-character >> without success. >> >> example: >> >> ? ... set new lisp reader .... >> ? test::x >> Error: access to not exported symbols is forbidden >> >> >> Kind regards >> >> -Taoufik >> >> _______________________________________________ >> 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 taoufik.dachraoui at wanadoo.fr Thu Jun 11 09:14:53 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 18:14:53 +0200 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> Message-ID: <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> On Jun 11, 2009, at 5:56 PM, Ron Garret wrote: > > > On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote: > >> Hi >> >> Users will not have access to intern, find-package, ... >> >> I implemented a loader that exports public symbols and shadow >> unwanted >> symbols >> so that users will not be able to use any private or shadowed >> symbols. >> >> the only problem I am facing today (as far as I can see right now) >> is to >> disallow users to access non exported symbols by using the double >> colons (::) >> > > The "as far as I can see right now" is a very important disclaimer. > The main problem with security is that there's a very big gap > between appearing to be secure and actually being secure. People > make careers out of bridging that gap, and still very often they get > it wrong. Not that I really want to discourage you -- it's good > that you're being ambitious, but it's important that you understand > the magnitude of the problem you are attempting to solve. > >> I tried to use set-macro-character and set-dispatch-macro-character >> but failed, and >> the reason is that the lisp reader as soon as it finds a macro- >> character the previously >> read word will be considered as a token and there is no way to >> rollback. > > Why is that a problem? > > Is there a reason you don't just pre-process the string to remove > all colons before reading it? Or simply reject any string > containing colons? > > rg > > I thought about processing the string before passing it to the reader but I think it is better to leave the lisp reader deal with it (faster); but it seems that there is no solution at sight right now; probably only by modifying (hacking) the ccl lisp reader. Another way is to create a set-macro-character for #\: and throw an error, but this will inhibit the use of keywords. About making lisp secure: Suppose you have access to a limited set of symbols (known as secure), and that the colons are forbidden, then how a user can access symbols in packages that he did not inherit? I think the question, is what are the lisp symbols that must be disallowed in a secure environment? streams, processes, eval, compile, ... I just want to try hard before I abandon. I am looking forward to read discussions about a secure lisp environment. Kind regards -Taoufik From ron at awun.net Thu Jun 11 09:43:53 2009 From: ron at awun.net (Ron Garret) Date: Thu, 11 Jun 2009 09:43:53 -0700 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> Message-ID: <5A2CCD55-28E5-4A88-8EE4-C1F3F271AA07@awun.net> On Jun 11, 2009, at 9:14 AM, Taoufik Dachraoui wrote: > I thought about processing the string before passing it to the > reader but I > think it is better to leave the lisp reader deal with it (faster); Are you familiar with the aphorism: premature optimization is the root of all evil? > but it seems > that there is no solution at sight right now; probably only by > modifying > (hacking) the ccl lisp reader. That's not the only way. But you are right that what you want to do is not trivial. > Another way is to create a set-macro-character for #\: and throw an > error, > but this will inhibit the use of keywords. That's right. But throwing an error is not your only option. (Note: I am encouraging you in this direction not because I think it's the right thing to do, but because there is a solution to your problem that you've overlooked, and I think you would benefit by finding it. By yourself that is.) > About making lisp secure: > > Suppose you have access to a limited set of symbols (known as secure), > and that the colons are forbidden, then how a user can access symbols > in packages that he did not inherit? By exploiting other weaknesses in the system. What those are I don't know, I haven't taken the time to look for them. But because CCL was not designed from the ground up to be secure they are almost certainly there to be found. I can actually think of a long list of potential weaknesses, but I'm not going to tell you what they are because I don't want you to fall into the trap of thinking that if you can just patch up that list then you're done. When it comes to security, it's the things you *haven't* thought of that cause the problems. That's why security is so hard. > I think the question, is what are the lisp symbols that must be > disallowed > in a secure environment? streams, processes, eval, compile, ... Earlier you said you were so worried about efficiency you didn't want to make an extra pass over your input strings, now you say you want to deny your users access to the compiler. I guarantee you that the slowdown you'll get from preprocessing your input will pale in comparison to what you will see if you only run interpreted code. BTW, one of the unique aspects of CCL's design is that all code is compiled by default, so if you want to keep your users away from the compiler in CCL you're really fighting an uphill battle. > I just want to try hard before I abandon. I am looking forward to read > discussions about a secure lisp environment. Good for you. Like I said, it's good that you are trying this. Just don't be disappointed if you don't succeed. You are not the first to go down this path. rg From mevins at mac.com Thu Jun 11 09:51:47 2009 From: mevins at mac.com (mikel evins) Date: Thu, 11 Jun 2009 11:51:47 -0500 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> Message-ID: <317FD2ED-E68E-4AC0-AD32-76034F133B70@mac.com> On Jun 11, 2009, at 11:14 AM, Taoufik Dachraoui wrote: > > On Jun 11, 2009, at 5:56 PM, Ron Garret wrote: > >> >> >> On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote: >> >>> Hi >>> >>> Users will not have access to intern, find-package, ... >>> >>> I implemented a loader that exports public symbols and shadow >>> unwanted >>> symbols >>> so that users will not be able to use any private or shadowed >>> symbols. >>> >>> the only problem I am facing today (as far as I can see right now) >>> is to >>> disallow users to access non exported symbols by using the double >>> colons (::) >>> >> >> The "as far as I can see right now" is a very important disclaimer. >> The main problem with security is that there's a very big gap >> between appearing to be secure and actually being secure. People >> make careers out of bridging that gap, and still very often they get >> it wrong. Not that I really want to discourage you -- it's good >> that you're being ambitious, but it's important that you understand >> the magnitude of the problem you are attempting to solve. >> >>> I tried to use set-macro-character and set-dispatch-macro-character >>> but failed, and >>> the reason is that the lisp reader as soon as it finds a macro- >>> character the previously >>> read word will be considered as a token and there is no way to >>> rollback. >> >> Why is that a problem? >> >> Is there a reason you don't just pre-process the string to remove >> all colons before reading it? Or simply reject any string >> containing colons? >> >> rg >> >> > > I thought about processing the string before passing it to the reader > but I > think it is better to leave the lisp reader deal with it (faster); but > it seems > that there is no solution at sight right now; probably only by > modifying > (hacking) the ccl lisp reader. > > Another way is to create a set-macro-character for #\: and throw an > error, > but this will inhibit the use of keywords. > > About making lisp secure: > > Suppose you have access to a limited set of symbols (known as secure), > and that the colons are forbidden, then how a user can access symbols > in packages that he did not inherit? (funcall (intern "LAUNCH-MISSILES" (find-package "TOP-SECRET-PACKAGE"))) (apply (symbol-function (find-symbol "DESTROY-THE-WORLD") (find- package "THE-EVIL-PACKAGE")) '()) (do-symbols (s (find-if (lambda (p) (member "WORLD-ENDING- PACKAGE" (package-nicknames p))) (list-all-packages))) (when (and (char= (elt (symbol-name s) 0) #\D) (char= (elt (symbol-name s) 0) #\E) (char= (elt (symbol-name s) 0) #\S) (char= (elt (symbol-name s) 0) #\T) (char= (elt (symbol-name s) 0) #\R) (char= (elt (symbol-name s) 0) #\O) (char= (elt (symbol-name s) 0) #\Y)) (funcall (symbol-function s)))) (do-all-symbols (s) (when (test-symbol-for-function-that-produces-hell- on-earth s) (let ((my-evil-symbol (gensym)))) (setf (symbol-function my-evil-symbol) (symbol-function s)) (pass-evil-symbol-to-function-calling- macro my-evil-symbol))) ... From taoufik.dachraoui at wanadoo.fr Thu Jun 11 10:23:08 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 19:23:08 +0200 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <317FD2ED-E68E-4AC0-AD32-76034F133B70@mac.com> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> <317FD2ED-E68E-4AC0-AD32-76034F133B70@mac.com> Message-ID: On Jun 11, 2009, at 6:51 PM, mikel evins wrote: > > > On Jun 11, 2009, at 11:14 AM, Taoufik Dachraoui wrote: > >> >> On Jun 11, 2009, at 5:56 PM, Ron Garret wrote: >> >>> >>> >>> On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote: >>> >>>> Hi >>>> >>>> Users will not have access to intern, find-package, ... >>>> >>>> I implemented a loader that exports public symbols and shadow >>>> unwanted >>>> symbols >>>> so that users will not be able to use any private or shadowed >>>> symbols. >>>> >>>> the only problem I am facing today (as far as I can see right now) >>>> is to >>>> disallow users to access non exported symbols by using the double >>>> colons (::) >>>> >>> >>> The "as far as I can see right now" is a very important disclaimer. >>> The main problem with security is that there's a very big gap >>> between appearing to be secure and actually being secure. People >>> make careers out of bridging that gap, and still very often they get >>> it wrong. Not that I really want to discourage you -- it's good >>> that you're being ambitious, but it's important that you understand >>> the magnitude of the problem you are attempting to solve. >>> >>>> I tried to use set-macro-character and set-dispatch-macro-character >>>> but failed, and >>>> the reason is that the lisp reader as soon as it finds a macro- >>>> character the previously >>>> read word will be considered as a token and there is no way to >>>> rollback. >>> >>> Why is that a problem? >>> >>> Is there a reason you don't just pre-process the string to remove >>> all colons before reading it? Or simply reject any string >>> containing colons? >>> >>> rg >>> >>> >> >> I thought about processing the string before passing it to the reader >> but I >> think it is better to leave the lisp reader deal with it (faster); >> but >> it seems >> that there is no solution at sight right now; probably only by >> modifying >> (hacking) the ccl lisp reader. >> >> Another way is to create a set-macro-character for #\: and throw an >> error, >> but this will inhibit the use of keywords. >> >> About making lisp secure: >> >> Suppose you have access to a limited set of symbols (known as >> secure), >> and that the colons are forbidden, then how a user can access symbols >> in packages that he did not inherit? > > (funcall (intern "LAUNCH-MISSILES" (find-package "TOP-SECRET- > PACKAGE"))) > > (apply (symbol-function (find-symbol "DESTROY-THE-WORLD") (find- > package "THE-EVIL-PACKAGE")) '()) > > (do-symbols (s (find-if (lambda (p) (member "WORLD-ENDING- > PACKAGE" (package-nicknames p))) (list-all-packages))) > (when (and (char= (elt (symbol-name s) 0) #\D) > (char= (elt (symbol-name s) 0) #\E) > (char= (elt (symbol-name s) 0) #\S) > (char= (elt (symbol-name s) 0) #\T) > (char= (elt (symbol-name s) 0) #\R) > (char= (elt (symbol-name s) 0) #\O) > (char= (elt (symbol-name s) 0) #\Y)) > (funcall (symbol-function s)))) > > (do-all-symbols (s) (when (test-symbol-for-function-that-produces- > hell-on-earth s) > (let ((my-evil-symbol (gensym)))) > (setf (symbol-function my-evil-symbol) > (symbol-function s)) > (pass-evil-symbol-to-function-calling- > macro my-evil-symbol))) > > > ... > > > As I said earlier, all symbols that allow users to access and/or modify data of other users will be shadowed (eg. intern, in-package, find-symbol, do-symbols, ...) Kind regards -Taoufik From taoufik.dachraoui at wanadoo.fr Thu Jun 11 10:20:33 2009 From: taoufik.dachraoui at wanadoo.fr (Taoufik Dachraoui) Date: Thu, 11 Jun 2009 19:20:33 +0200 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <5A2CCD55-28E5-4A88-8EE4-C1F3F271AA07@awun.net> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> <5A2CCD55-28E5-4A88-8EE4-C1F3F271AA07@awun.net> Message-ID: <2A5475A8-C6D3-42C8-9DA1-800CBFD86032@wanadoo.fr> On Jun 11, 2009, at 6:43 PM, Ron Garret wrote: > > > On Jun 11, 2009, at 9:14 AM, Taoufik Dachraoui wrote: > >> I thought about processing the string before passing it to the >> reader but I >> think it is better to leave the lisp reader deal with it (faster); > > Are you familiar with the aphorism: premature optimization is the > root of all evil? Yes, but this not what I call premature optimization. Often, when you try to optimize early, usually the optimized code is complex, and this is the problem, adding complexity early is not not beneficial at best. In my case I thought that by just writing a read macro will solve the problem; it is not the case. But I considered this as an opportunity to learn something new to me. > >> but it seems >> that there is no solution at sight right now; probably only by >> modifying >> (hacking) the ccl lisp reader. > > That's not the only way. But you are right that what you want to do > is not trivial. I looked at the l1-reader.lisp where double-colon is handled, it may not be difficult to modify the code for a ccl expert (not me). > >> Another way is to create a set-macro-character for #\: and throw an >> error, >> but this will inhibit the use of keywords. > > That's right. But throwing an error is not your only option. > (Note: I am encouraging you in this direction not because I think > it's the right thing to do, but because there is a solution to your > problem that you've overlooked, and I think you would benefit by > finding it. By yourself that is.) > >> About making lisp secure: >> >> Suppose you have access to a limited set of symbols (known as >> secure), >> and that the colons are forbidden, then how a user can access symbols >> in packages that he did not inherit? > > By exploiting other weaknesses in the system. What those are I > don't know, I haven't taken the time to look for them. But because > CCL was not designed from the ground up to be secure they are almost > certainly there to be found. I can actually think of a long list of > potential weaknesses, but I'm not going to tell you what they are > because I don't want you to fall into the trap of thinking that if > you can just patch up that list then you're done. When it comes to > security, it's the things you *haven't* thought of that cause the > problems. That's why security is so hard. Agree, it is hard, but tractable (they did it for java, even though they did not solve all security issues, but they have something running). If we wait until we are sure to solve all security issues, we will never manage to do it. >> I think the question, is what are the lisp symbols that must be >> disallowed >> in a secure environment? streams, processes, eval, compile, ... > > Earlier you said you were so worried about efficiency you didn't > want to make an extra pass over your input strings, now you say you > want to deny your users access to the compiler. I guarantee you > that the slowdown you'll get from preprocessing your input will pale > in comparison to what you will see if you only run interpreted code. > > BTW, one of the unique aspects of CCL's design is that all code is > compiled by default, so if you want to keep your users away from the > compiler in CCL you're really fighting an uphill battle. The server can compile functions on behalf of users >> I just want to try hard before I abandon. I am looking forward to >> read >> discussions about a secure lisp environment. > > Good for you. Like I said, it's good that you are trying this. > Just don't be disappointed if you don't succeed. You are not the > first to go down this path. > > rg > > I will not be disappointed if I learn something. Kind regards -Taoufik From rpgoldman at sift.info Thu Jun 11 11:07:18 2009 From: rpgoldman at sift.info (Robert Goldman) Date: Thu, 11 Jun 2009 13:07:18 -0500 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> <317FD2ED-E68E-4AC0-AD32-76034F133B70@mac.com> Message-ID: <4A3147D6.7080607@sift.info> Taoufik Dachraoui wrote: > On Jun 11, 2009, at 6:51 PM, mikel evins wrote: > >> >> On Jun 11, 2009, at 11:14 AM, Taoufik Dachraoui wrote: >> >>> On Jun 11, 2009, at 5:56 PM, Ron Garret wrote: >>> >>>> >>>> On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote: >>>> >>>>> Hi >>>>> >>>>> Users will not have access to intern, find-package, ... >>>>> >>>>> I implemented a loader that exports public symbols and shadow >>>>> unwanted >>>>> symbols >>>>> so that users will not be able to use any private or shadowed >>>>> symbols. >>>>> >>>>> the only problem I am facing today (as far as I can see right now) >>>>> is to >>>>> disallow users to access non exported symbols by using the double >>>>> colons (::) >>>>> >>>> The "as far as I can see right now" is a very important disclaimer. >>>> The main problem with security is that there's a very big gap >>>> between appearing to be secure and actually being secure. People >>>> make careers out of bridging that gap, and still very often they get >>>> it wrong. Not that I really want to discourage you -- it's good >>>> that you're being ambitious, but it's important that you understand >>>> the magnitude of the problem you are attempting to solve. >>>> >>>>> I tried to use set-macro-character and set-dispatch-macro-character >>>>> but failed, and >>>>> the reason is that the lisp reader as soon as it finds a macro- >>>>> character the previously >>>>> read word will be considered as a token and there is no way to >>>>> rollback. >>>> Why is that a problem? >>>> >>>> Is there a reason you don't just pre-process the string to remove >>>> all colons before reading it? Or simply reject any string >>>> containing colons? >>>> >>>> rg >>>> >>>> >>> I thought about processing the string before passing it to the reader >>> but I >>> think it is better to leave the lisp reader deal with it (faster); >>> but >>> it seems >>> that there is no solution at sight right now; probably only by >>> modifying >>> (hacking) the ccl lisp reader. >>> >>> Another way is to create a set-macro-character for #\: and throw an >>> error, >>> but this will inhibit the use of keywords. >>> >>> About making lisp secure: >>> >>> Suppose you have access to a limited set of symbols (known as >>> secure), >>> and that the colons are forbidden, then how a user can access symbols >>> in packages that he did not inherit? >> (funcall (intern "LAUNCH-MISSILES" (find-package "TOP-SECRET- >> PACKAGE"))) >> >> (apply (symbol-function (find-symbol "DESTROY-THE-WORLD") (find- >> package "THE-EVIL-PACKAGE")) '()) >> >> (do-symbols (s (find-if (lambda (p) (member "WORLD-ENDING- >> PACKAGE" (package-nicknames p))) (list-all-packages))) >> (when (and (char= (elt (symbol-name s) 0) #\D) >> (char= (elt (symbol-name s) 0) #\E) >> (char= (elt (symbol-name s) 0) #\S) >> (char= (elt (symbol-name s) 0) #\T) >> (char= (elt (symbol-name s) 0) #\R) >> (char= (elt (symbol-name s) 0) #\O) >> (char= (elt (symbol-name s) 0) #\Y)) >> (funcall (symbol-function s)))) >> >> (do-all-symbols (s) (when (test-symbol-for-function-that-produces- >> hell-on-earth s) >> (let ((my-evil-symbol (gensym)))) >> (setf (symbol-function my-evil-symbol) >> (symbol-function s)) >> (pass-evil-symbol-to-function-calling- >> macro my-evil-symbol))) >> >> >> ... >> >> >> > As I said earlier, all symbols that allow users to access and/or > modify data of other users will be > shadowed (eg. intern, in-package, find-symbol, do-symbols, ...) Possible alternative approach: make a package for each user by hand. Do *not* (:use COMMON-LISP). Let individual symbols in if you feel they can be trusted. Make sure you don't admit find-symbol, intern, and their kin! Break the reader as you have already considered. Cheers, r From ron at awun.net Thu Jun 11 11:15:40 2009 From: ron at awun.net (Ron Garret) Date: Thu, 11 Jun 2009 11:15:40 -0700 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: <2A5475A8-C6D3-42C8-9DA1-800CBFD86032@wanadoo.fr> References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> <5A2CCD55-28E5-4A88-8EE4-C1F3F271AA07@awun.net> <2A5475A8-C6D3-42C8-9DA1-800CBFD86032@wanadoo.fr> Message-ID: <126CEE11-CB87-4DF8-830A-2E48E75946F4@awun.net> On Jun 11, 2009, at 10:20 AM, Taoufik Dachraoui wrote: > they did it for java Yes, but they were starting with a clean slate and with sandboxing as an explicit design goal before they ever wrote a line of code. You are starting with twenty years worth of legacy code and design that didn't take security into account at all. The Java folks also had Guy Steele on their team. And even then they still, as you yourself pointed out, did not solve all the security issues. > I will not be disappointed if I learn something. That's the spirit! So since you seem to have the right attitude, I'll go ahead and show you what I came up with when I tried noodling around with this a long time ago. My goal when I wrote this code was not security, but to co-opt the colon for other syntactic purposes having to do with esoteric language design issues. This code was just an experiment, nowhere near ready for prime-time, but you may find it useful nonetheless. (defun symbol-charp (c) (and (not (digit-char-p c *read-base*)) (or (alpha-char-p c) (find c ":_ at .")))) (defun symbol-cont-charp (c) (or (digit-char-p c *read-base*) (symbol-charp c) (find c "-"))) (defun colon-reader (s ch) (let ((chars (list ch)) ch2) (loop do (setf ch2 (read-char s nil nil)) while (symbol-cont-charp ch2) do (push ch2 chars)) (if ch2 (unread-char ch2 s)) (intern (string-upcase (coerce (nreverse chars) 'string))))) (let ((*readtable* (let* ((rt (copy-readtable nil))) (loop for i from 0 to 255 do (let ((ch (code-char i))) (when (symbol-charp ch) (set-macro-character ch 'colon-reader t rt)))) rt))) (let ((*read-base* 16)) (dolist (x (read-from-string "(abc .a a: a.b a[1] 1a -1a 1z -1z \"string\" def:ghi ; comment klm::opq 123 1.23 1.23e4 1.23d4 #xabc)")) (print (list x (type-of x)))))) rg From james.anderson at setf.de Thu Jun 11 13:06:21 2009 From: james.anderson at setf.de (james anderson) Date: Thu, 11 Jun 2009 22:06:21 +0200 Subject: [Openmcl-devel] ? jfli In-Reply-To: References: Message-ID: <8B384E18-806F-4E9A-BED9-AE063FD3AC3F@setf.de> On 2009-06-11, at 14:39 , Gary Byers wrote: > I don't know if anyone's using the jfli port or not, but whether > they are or not has nothing to do with whether entry point names > have leading underscores on Darwin. > > The old way of looking up the addresses of foreign symbols on Darwin > (which viewed all external symbols as having leading underscores and > required its argument to have such a leading underscore) has been > deprecated (certainly as of Tiger, possibly before - it's been a few > years) in favor of a new (previously deprecated) way which pretends > that Darwin symbols don't have leading underscores (at a lower level, > they still do) and which strips an initial leading underscore from > its argument. So: > > ? (foreign-symbol-address "read") > # > ? (foreign-symbol-address "_read") > # that is not what i see happen. marbella:/Development/Applications/LISP/ccl-1.3 james$ system_profiler SPSoftwareDataType Software: System Software Overview: System Version: Mac OS X 10.4.11 (8S165) Kernel Version: Darwin 8.11.0 Boot Volume: marbella-backup Computer Name: marbella User Name: james anderson (james) marbella:/Development/Applications/LISP/ccl-1.3 james$ ./dppccl Welcome to Clozure Common Lisp Version 1.3-RC1-r11719M (DarwinPPC32)! ? (foreign-symbol-address "read") NIL ? 1.3-r11936 does this as well. > > the leading underscore is usually optional, and Apple has cleverly > designed a symbol-lookup mechanism that makes it awkward to refer > to foreign symbols that actually have meaningful leading underscores > in their C-visible names. (But I digress ...). > > You're correct in noting that if the advocated way of resolving > foreign symbol addresses on Darwin still required its argument > to have a leading underscore the jfli example (and lots of other > things, including lots of code in CCL itself) wouldn't work. i wrote the note, because it didn't. what would make the "_" not optional? > Those > things generally do (or at least aren't affected by this ...), and > AFAIK jfli more-or-less does as well. (The "or less" parts that I'm > aware of have to do with JNI objects not being freed when they should > be, and the general plan is to RTFJNIM to get a clearer idea of when > they should be.) > > What's there does seem to work at least well enough to run simple > demos, including the simple SWT demo that's included (assuming that > you can find an SWT library for your platform and can adjust the paths > to it and the JFM that're hardwired into the examples.) One platform > for which there was not a released SWT library (unless it's been > released very recently) is 64-bit OSX: the OSX version of SWT has been > based on Carbon (and is therefore 32-bit only), though work on a > Cocoa-based version is ongoing.) i intend to use it in 64-bit linux. > > Nick Levine made some changes to Rich Hickey's original jfli code > a year or so ago; I wasn't aware of those changes when I did the > CCL port last winter. Nick's changes include improvements to > pathname handling and ways of abstracting away some Windows/Unix > differences, and it'd be good to merge those changes into the CCL > port when time permits. i will keep that in mind. from the list of things mr levine had in that blog note about the changes, i will look at them before i try to do anything serious with it. From cavandusen at gmail.com Thu Jun 11 14:56:53 2009 From: cavandusen at gmail.com (Chris Van Dusen) Date: Thu, 11 Jun 2009 16:56:53 -0500 Subject: [Openmcl-devel] read-line Doesn't Return in IDE Message-ID: <7A456740-7124-4AB8-A791-209B80233801@gmail.com> Hi, After updating from trunk, a function of mine that used to work is not returning from within the IDE. I was able to track it down to this line (based on code from Peter Seibel's book): (read-line *query-io*) At the command line, it does this: Welcome to Clozure Common Lisp Version 1.4-dev-r12256M-trunk (DarwinX8664)! ? (read-line *query-io*) this "this" NIL From Emacs/Slime: ; SLIME 2009-06-1 CL-USER> (read-line *query-io*) this "this" NIL In the IDE: Welcome to Clozure Common Lisp Version 1.4-dev-r12256M-trunk (DarwinX8664)! ? (read-line *query-io*) this and it just sits there (so far...) Thanks, Chris. From rme at clozure.com Thu Jun 11 15:06:27 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 11 Jun 2009 18:06:27 -0400 Subject: [Openmcl-devel] Clozure Emacs/Slime problem in Win32 In-Reply-To: <66c9435a0906101603r6f222dc6u1a5ff4c996bf4269@mail.gmail.com> References: <66c9435a0906101603r6f222dc6u1a5ff4c996bf4269@mail.gmail.com> Message-ID: <47F3F8C2-A46B-4921-ACD8-2EC7931D0D26@clozure.com> On Jun 10, 2009, at 7:03 PM, Greg Santucci wrote: > When I try (cl-glut-examples:gears) at the slime "inferior-lisp" > repl, the example runs normally. When I try it in the normal repl > buffer, it will work only if I did it in the "inferior-lisp" repl > first. If not, the window doesn't appear, and the repl says nothing. > I can't find any error messages or prompts in the other buffers. If > at the "inferior-lisp" repl I run another example, such as (cl-glut- > examples:rb-robot), suddenly both the robot and gears windows appear > and run normally. I would expect that this is some sort of threading issue. The repl in the *inferior-lisp* buffer is the initial thread. I believe that the slime repl is a different thread. Just as a wild guess, could it be due the issue with #_ShowWindow that is discussed in ccl:examples;mswin.lisp? Quoting from a comment therein: ;; Depending on how the lisp process was created, the first call ;; to #_ShowWindow in that process might ignore its argument ;; (and instead use an argument specified in the STARTUPINFO ;; structure passed to #_CreateProcess.) SLIME under FSF Emacs ;; runs the lisp with this flag set, and it's possible to waste ;; a week or two trying to track this down. (Trust me.) (#_ShowWindow hwnd #$SW_SHOW) ;; In case the parent process said to ignore #_ShowWindow's argument ;; the first time it's called, call #_ShowWindow again. This seems ;; to be harmless, if a little strange ... (#_ShowWindow hwnd #$SW_SHOW) > > Interestingly, this problem doesn't occur with lispbuilder-sdl > examples. From ron at awun.net Thu Jun 11 15:06:56 2009 From: ron at awun.net (Ron Garret) Date: Thu, 11 Jun 2009 15:06:56 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> Message-ID: <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> On Jun 10, 2009, at 3:33 AM, Gail Zacharias wrote: > We have added a "ccl:contrib;" directory to CCL for distributing > user-contributed software. It's in the trunk and will be included > starting with the next release. > > To contribute, you can send your file (or zipped up directory) to > openmcl-devel clearly saying that you want it to go into the CCL > contrib directory. Better yet, ask for write access to the > subversion repository and add it yourself -- that way you can also > update it as needed. > > I hope some of the neat examples that have been floating around the > list lately will make it into contrib! Along those lines, and following Alexander's suggestion of not including code as attachments, I have placed updated versions of the scribble and draggable demos at: http://www.flownet.com/ron/lisp/ There's also two new demos: an image-view class which does the obvious thing, and a pdf-view with overlays, so you can, for example, overlay a scribble view over a pdf view and scribble on a PDF. You'll need to snarf three files from there to run the demos: rg-utils.lisp rg-cocoa-utils.lisp rg-demos.lisp The two utils files are intended to be useful in their own right independent of the demos. I have tested these on the heads of the 1.3 and trunk in both 32 and 64 bit on OS X 10.5.7. The PDF demo can crash your machine in 64-bit mode because of an as-yet uncorrected bug in OS X. These probably need documentation before they're ready to be included in contrib, but they two of the files are public domain and the third (rg-utils) just requires attribution so anyone can do pretty much anything they like with them. As always, feedback welcome. rg From terje at in-progress.com Thu Jun 11 16:31:10 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Thu, 11 Jun 2009 16:31:10 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> Message-ID: <689DFF4E-BAD1-4742-9061-AF81465A0EB8@in-progress.com> On Jun 10, 2009, at 3:33 AM, Gail Zacharias wrote: > We have added a "ccl:contrib;" directory to CCL for distributing > user-contributed software. It's in the trunk and will be included > starting with the next release. > > To contribute, you can send your file (or zipped up directory) to > openmcl-devel clearly saying that you want it to go into the CCL > contrib directory. Better yet, ask for write access to the > subversion repository and add it yourself -- that way you can also > update it as needed. MCL have a rich library of user contributions/libraries on the CD distributions that we all could benefit from having updated for compatibility Clozure CL. I'll port the relevant ones of mine, but there are many for which the original developer is long gone. Perhaps this could be an opportunity for say students on summer break to make a name in the Common LISP developer community, placing literally your mark on CCL contributions to be used for many years to come without having to start from scratch? -- Terje Norderhaug From cavandusen at gmail.com Thu Jun 11 18:03:03 2009 From: cavandusen at gmail.com (Chris Van Dusen) Date: Thu, 11 Jun 2009 20:03:03 -0500 Subject: [Openmcl-devel] User contributions In-Reply-To: <689DFF4E-BAD1-4742-9061-AF81465A0EB8@in-progress.com> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <689DFF4E-BAD1-4742-9061-AF81465A0EB8@in-progress.com> Message-ID: <3CCC9E81-CAF4-4D52-BF05-698426DC967D@gmail.com> I would be interested in that. How would one go about obtaining the CD distribution, or the contributions contained therein? Thanks, Chris. On Jun 11, 2009, at 6:31 PM, Terje Norderhaug wrote: > On Jun 10, 2009, at 3:33 AM, Gail Zacharias wrote: >> We have added a "ccl:contrib;" directory to CCL for distributing >> user-contributed software. It's in the trunk and will be included >> starting with the next release. >> >> To contribute, you can send your file (or zipped up directory) to >> openmcl-devel clearly saying that you want it to go into the CCL >> contrib directory. Better yet, ask for write access to the >> subversion repository and add it yourself -- that way you can also >> update it as needed. > > MCL have a rich library of user contributions/libraries on the CD > distributions that we all could benefit from having updated for > compatibility Clozure CL. I'll port the relevant ones of mine, but > there are many for which the original developer is long gone. Perhaps > this could be an opportunity for say students on summer break to make > a name in the Common LISP developer community, placing literally your > mark on CCL contributions to be used for many years to come without > having to start from scratch? > > -- Terje Norderhaug > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From mevins at mac.com Thu Jun 11 18:36:15 2009 From: mevins at mac.com (mikel evins) Date: Thu, 11 Jun 2009 20:36:15 -0500 Subject: [Openmcl-devel] modify lisp reader such that :: is disallowed In-Reply-To: References: <08028FE5-DD1D-4912-883D-9EA297EF7EC8@wanadoo.fr> <1358-SnapperMsg6FC6F8FAC656CB17@[173.4.2.22]> <13012A04-19C3-4E45-BD6D-4B7B704F91C7@wanadoo.fr> <10DF58EF-80C2-4EA2-A0D6-2D631DC024BD@awun.net> <0E67D833-90C0-4603-9D30-4AF801243014@wanadoo.fr> <317FD2ED-E68E-4AC0-AD32-76034F133B70@mac.com> Message-ID: On Jun 11, 2009, at 12:23 PM, Taoufik Dachraoui wrote: > > On Jun 11, 2009, at 6:51 PM, mikel evins wrote: > >> >> >> On Jun 11, 2009, at 11:14 AM, Taoufik Dachraoui wrote: >> >>> >>> On Jun 11, 2009, at 5:56 PM, Ron Garret wrote: >>> >>>> >>>> >>>> On Jun 11, 2009, at 8:09 AM, Taoufik Dachraoui wrote: >>>> >>>>> Hi >>>>> >>>>> Users will not have access to intern, find-package, ... >>>>> >>>>> I implemented a loader that exports public symbols and shadow >>>>> unwanted >>>>> symbols >>>>> so that users will not be able to use any private or shadowed >>>>> symbols. >>>>> >>>>> the only problem I am facing today (as far as I can see right now) >>>>> is to >>>>> disallow users to access non exported symbols by using the double >>>>> colons (::) >>>>> >>>> >>>> The "as far as I can see right now" is a very important disclaimer. >>>> The main problem with security is that there's a very big gap >>>> between appearing to be secure and actually being secure. People >>>> make careers out of bridging that gap, and still very often they >>>> get >>>> it wrong. Not that I really want to discourage you -- it's good >>>> that you're being ambitious, but it's important that you understand >>>> the magnitude of the problem you are attempting to solve. >>>> >>>>> I tried to use set-macro-character and set-dispatch-macro- >>>>> character >>>>> but failed, and >>>>> the reason is that the lisp reader as soon as it finds a macro- >>>>> character the previously >>>>> read word will be considered as a token and there is no way to >>>>> rollback. >>>> >>>> Why is that a problem? >>>> >>>> Is there a reason you don't just pre-process the string to remove >>>> all colons before reading it? Or simply reject any string >>>> containing colons? >>>> >>>> rg >>>> >>>> >>> >>> I thought about processing the string before passing it to the >>> reader >>> but I >>> think it is better to leave the lisp reader deal with it (faster); >>> but >>> it seems >>> that there is no solution at sight right now; probably only by >>> modifying >>> (hacking) the ccl lisp reader. >>> >>> Another way is to create a set-macro-character for #\: and throw an >>> error, >>> but this will inhibit the use of keywords. >>> >>> About making lisp secure: >>> >>> Suppose you have access to a limited set of symbols (known as >>> secure), >>> and that the colons are forbidden, then how a user can access >>> symbols >>> in packages that he did not inherit? >> >> (funcall (intern "LAUNCH-MISSILES" (find-package "TOP-SECRET- >> PACKAGE"))) >> >> (apply (symbol-function (find-symbol "DESTROY-THE-WORLD") (find- >> package "THE-EVIL-PACKAGE")) '()) >> >> (do-symbols (s (find-if (lambda (p) (member "WORLD-ENDING- >> PACKAGE" (package-nicknames p))) (list-all-packages))) >> (when (and (char= (elt (symbol-name s) 0) #\D) >> (char= (elt (symbol-name s) 0) #\E) >> (char= (elt (symbol-name s) 0) #\S) >> (char= (elt (symbol-name s) 0) #\T) >> (char= (elt (symbol-name s) 0) #\R) >> (char= (elt (symbol-name s) 0) #\O) >> (char= (elt (symbol-name s) 0) #\Y)) >> (funcall (symbol-function s)))) >> >> (do-all-symbols (s) (when (test-symbol-for-function-that-produces- >> hell-on-earth s) >> (let ((my-evil-symbol (gensym)))) >> (setf (symbol-function my-evil-symbol) >> (symbol-function s)) >> (pass-evil-symbol-to-function-calling- >> macro my-evil-symbol))) >> >> >> ... >> >> >> > As I said earlier, all symbols that allow users to access and/or > modify data of other users will be > shadowed (eg. intern, in-package, find-symbol, do-symbols, ...) That's a lot of symbols! The implementation in front of me has about 9,000 symbols that name functions. I wonder how many of them have malicious potential uses? I wonder how many can be combined with some number of the other ones to result in a security hole? Phew, that's going to be quite a bit of checking! I'm not saying you should give up; far from it. On the contrary, I'd suggest trying to get a research grant for it. If you limit yourself to one specific implementation on one specific CPU and OS, that could be enough work to keep you busy, interested, and receiving paychecks for several years. It could result in some pretty interesting publications, too. --me From neil.baylis at gmail.com Thu Jun 11 22:51:55 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Thu, 11 Jun 2009 22:51:55 -0700 Subject: [Openmcl-devel] 64 bit vs 32 bit Message-ID: <1e6b7d810906112251t16e08ea9h6890d8cb95b4df01@mail.gmail.com> Is there any advantage to using the 64 bit version on a system with less than 4 GByte of memory? Is it superior to the 32 bit version in any other ways? Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From joswig at lisp.de Fri Jun 12 00:25:11 2009 From: joswig at lisp.de (Rainer Joswig) Date: Fri, 12 Jun 2009 09:25:11 +0200 Subject: [Openmcl-devel] User contributions In-Reply-To: <3CCC9E81-CAF4-4D52-BF05-698426DC967D@gmail.com> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <689DFF4E-BAD1-4742-9061-AF81465A0EB8@in-progress.com> <3CCC9E81-CAF4-4D52-BF05-698426DC967D@gmail.com> Message-ID: Usually many/most of the contributions were also in a contrib subdirectory on ftp.digitool.com. But not all. I just tried to reach this FTP server and it does not seem to be reachable. Would it be possible to serve some MCL software from the Clozure FTP site? Especially the documentation, open source versions and the contribs? Regards, Rainer Joswig Am 12.06.2009 um 03:03 schrieb Chris Van Dusen: > I would be interested in that. How would one go about obtaining the > CD distribution, or the contributions contained therein? > > Thanks, > Chris. > > On Jun 11, 2009, at 6:31 PM, Terje Norderhaug wrote: > >> On Jun 10, 2009, at 3:33 AM, Gail Zacharias wrote: >>> We have added a "ccl:contrib;" directory to CCL for distributing >>> user-contributed software. It's in the trunk and will be included >>> starting with the next release. >>> >>> To contribute, you can send your file (or zipped up directory) to >>> openmcl-devel clearly saying that you want it to go into the CCL >>> contrib directory. Better yet, ask for write access to the >>> subversion repository and add it yourself -- that way you can also >>> update it as needed. >> >> MCL have a rich library of user contributions/libraries on the CD >> distributions that we all could benefit from having updated for >> compatibility Clozure CL. I'll port the relevant ones of mine, but >> there are many for which the original developer is long gone. Perhaps >> this could be an opportunity for say students on summer break to make >> a name in the Common LISP developer community, placing literally your >> mark on CCL contributions to be used for many years to come without >> having to start from scratch? >> >> -- Terje Norderhaug >> _______________________________________________ >> 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 From hebisch at math.uni.wroc.pl Fri Jun 12 04:06:35 2009 From: hebisch at math.uni.wroc.pl (Waldek Hebisch) Date: Fri, 12 Jun 2009 13:06:35 +0200 (CEST) Subject: [Openmcl-devel] 64 bit vs 32 bit In-Reply-To: <1e6b7d810906112251t16e08ea9h6890d8cb95b4df01@mail.gmail.com> Message-ID: Neil Baylis wrote: > Is there any advantage to using the 64 bit version on a system with less > than 4 GByte of memory? Is it superior to the 32 bit version in any other > ways? 64 bit version has bigger fixnums. For me it means that 64 bit version freqently is able to do computations using fixnums, while 32 bit version has to use bignums. I did not try 32 bit Closure CL, but for sbcl it happend few times that 32 bit version was about 10 times slower than 64-bit one. In principle 64 bit version should have faster bignums, but IIUC in Closure CL 32 and 64 bit versions use essentially the same code for bignum arithmetic. -- Waldek Hebisch hebisch at math.uni.wroc.pl From raffaelcavallaro at mac.com Fri Jun 12 05:08:22 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Fri, 12 Jun 2009 08:08:22 -0400 Subject: [Openmcl-devel] 64 bit vs 32 bit In-Reply-To: <1e6b7d810906112251t16e08ea9h6890d8cb95b4df01@mail.gmail.com> References: <1e6b7d810906112251t16e08ea9h6890d8cb95b4df01@mail.gmail.com> Message-ID: On Jun 12, 2009, at 1:51 AM, Neil Baylis wrote: > Is there any advantage to using the 64 bit version on a system with > less than 4 GByte of memory? Is it superior to the 32 bit version in > any other ways? You might also want to take note of the fact that foreign calls are significantly slower on the 64-bit intel CCL than the 32-bit intel CCL: "there's a lot more overhead in a Darwinx8664 foreign function call than there is on other platforms." "(let (t1 t2 t3 t4) (setq t1 (#_mach_absolute_time)) (setq t2 (#_mach_absolute_time)) (setq t3 (#_mach_absolute_time)) (setq t4 (#_mach_absolute_time)) (format t "~%t2-t1=~A, t3-t2=~A, t4-t3=~A" (- t2 t1) (- t3 t2) (- t4 t3))) generates results like: t2-t1=341, t3-t2=146, t4-t3=140 in 32-bit Darwin x86 CCL, and generates results like: t2-t1=1995, t3-t2=1809, t4-t3=1795 on x86-64 Darwin. That's pretty pronounced - rouughly an order of magnitud - and it's directly attributable to those extra syscalls (Getting rid of the syscalls would speed up ff-call on x86-64 Darwin, but would would make one less register available for general use and would likely slow down many other things.)" Raffael Cavallaro raffaelcavallaro at me.com From j-anthony at comcast.net Fri Jun 12 06:11:44 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Fri, 12 Jun 2009 09:11:44 -0400 Subject: [Openmcl-devel] 64 bit vs 32 bit In-Reply-To: References: <1e6b7d810906112251t16e08ea9h6890d8cb95b4df01@mail.gmail.com> Message-ID: <1244812304.2420.266.camel@sirius> On Fri, 2009-06-12 at 08:08 -0400, Raffael Cavallaro wrote: > On Jun 12, 2009, at 1:51 AM, Neil Baylis wrote: > > > Is there any advantage to using the 64 bit version on a system with > > less than 4 GByte of memory? Is it superior to the 32 bit version in > > any other ways? > > You might also want to take note of the fact that foreign calls are > significantly slower on the 64-bit intel CCL than the 32-bit intel CCL: Is that on all Intel platforms? Below, Gary speaks only to Darwin and about extra system calls required on that platform. What's this like on Linux? Also, I believe that 64 bit Intel is not register starved like 32 bit Intel ==> compiler/optimizer not nearly hamstrung as much needing to spill registers to temporaries. That would likely increase performance on Intel 64 over 32 in many cases - maybe most?. That is born out in some tests I've done (admittedly only a few at present) where Intel 64 (on Darwin(!)) with 1GB tended to be 3X faster than FC5 Intel 32 with 2GB. OK, memory was a non issue in these handful of examples. Maybe this was down to the register mismatch. /Jon > > > "there's a lot > more overhead in a Darwinx8664 foreign function call than there > is on other platforms." > > "(let (t1 t2 t3 t4) > (setq t1 (#_mach_absolute_time)) > (setq t2 (#_mach_absolute_time)) > (setq t3 (#_mach_absolute_time)) > (setq t4 (#_mach_absolute_time)) > (format t "~%t2-t1=~A, t3-t2=~A, t4-t3=~A" (- t2 t1) (- t3 t2) (- t4 > t3))) > > generates results like: > > t2-t1=341, t3-t2=146, t4-t3=140 > > in 32-bit Darwin x86 CCL, and generates results like: > > t2-t1=1995, t3-t2=1809, t4-t3=1795 > > on x86-64 Darwin. That's pretty pronounced - rouughly an order of > magnitud - and it's directly attributable to those extra syscalls > (Getting rid of the syscalls would speed up ff-call on x86-64 Darwin, > but would would make one less register available for general use > and would likely slow down many other things.)" > > > > Raffael Cavallaro > raffaelcavallaro at me.com > > > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From j-anthony at comcast.net Fri Jun 12 06:16:36 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Fri, 12 Jun 2009 09:16:36 -0400 Subject: [Openmcl-devel] Binary IO... In-Reply-To: References: <1244408197.2420.175.camel@sirius> <1244472082.2420.187.camel@sirius> <1244557724.2420.202.camel@sirius> <1244587931.2420.224.camel@sirius> Message-ID: <1244812596.2420.270.camel@sirius> On Wed, 2009-06-10 at 03:56 -0600, Gary Byers wrote: > Standard C library things like #_read and #_write are documented (from the Just for the record, these (read, write, lseek) are not standard (ANSI) C things. IIRC they are glibc things. /Jon From pc at p-cos.net Fri Jun 12 06:49:19 2009 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 12 Jun 2009 15:49:19 +0200 Subject: [Openmcl-devel] MCL 2.0 Message-ID: Hi, I have found a set of 3.5" disks containing MCL 2.0 and MCL 2.0B1, from Apple Computer. Is anyone interested in those? I have no idea whether they are still readable... Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From raffaelcavallaro at mac.com Fri Jun 12 07:12:22 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Fri, 12 Jun 2009 10:12:22 -0400 Subject: [Openmcl-devel] 64 bit vs 32 bit In-Reply-To: <1244812304.2420.266.camel@sirius> References: <1e6b7d810906112251t16e08ea9h6890d8cb95b4df01@mail.gmail.com> <1244812304.2420.266.camel@sirius> Message-ID: On Jun 12, 2009, at 9:11 AM, Jon S. Anthony wrote: > Is that on all Intel platforms? Below, Gary speaks only to Darwin and > about extra system calls required on that platform. Only on Apple platforms, iirc. Not true of CCL intel Linux. regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From karsten.poeck at gmail.com Fri Jun 12 13:33:21 2009 From: karsten.poeck at gmail.com (Karsten Poeck) Date: Fri, 12 Jun 2009 22:33:21 +0200 Subject: [Openmcl-devel] User contributions References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> Message-ID: In article <5065C024-18B6-4E09-B3BD-C009D2F5FF96 at awun.net>, Ron Garret wrote: > http://www.flownet.com/ron/lisp/ > > There's also two new demos: an image-view class which does the obvious > thing, and a pdf-view with overlays, so you can, for example, overlay > a scribble view over a pdf view and scribble on a PDF. > > You'll need to snarf three files from there to run the demos: > > rg-utils.lisp > rg-cocoa-utils.lisp > rg-demos.lisp How do you normally load your files? I tried opening in hemlock an "Compile and load buffer" but this fails with a lot of undefined forward references, e.g Error: Undefined function CONVERT-ARGS called with arguments ((S)) . Error: Undefined function EXTRACT-DECLARATIONS called with arguments undefined class view and other errors. Does your code perhaps lack some (eval-when ...) regards Karsten From ron at awun.net Fri Jun 12 13:39:02 2009 From: ron at awun.net (Ron Garret) Date: Fri, 12 Jun 2009 13:39:02 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> Message-ID: <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> On Jun 12, 2009, at 1:33 PM, Karsten Poeck wrote: > In article <5065C024-18B6-4E09-B3BD-C009D2F5FF96 at awun.net>, > Ron Garret wrote: > >> http://www.flownet.com/ron/lisp/ >> >> There's also two new demos: an image-view class which does the >> obvious >> thing, and a pdf-view with overlays, so you can, for example, overlay >> a scribble view over a pdf view and scribble on a PDF. >> >> You'll need to snarf three files from there to run the demos: >> >> rg-utils.lisp >> rg-cocoa-utils.lisp >> rg-demos.lisp > > How do you normally load your files? Evalute-all in the trunk, load-buffer in 1.3 > I tried opening in hemlock an > "Compile and load buffer" but this fails with a lot of undefined > forward > references, e.g > Error: Undefined function CONVERT-ARGS called with arguments ((S)) . > Error: Undefined function EXTRACT-DECLARATIONS called with arguments > undefined class view and other errors. > > Does your code perhaps lack some (eval-when ...) > Undoubtedly. Like I said, it's not quite ready for inclusion in contribs. rg From ron at awun.net Fri Jun 12 14:03:36 2009 From: ron at awun.net (Ron Garret) Date: Fri, 12 Jun 2009 14:03:36 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> Message-ID: <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> On Jun 12, 2009, at 1:39 PM, Ron Garret wrote: > >> >> Does your code perhaps lack some (eval-when ...) >> > > Undoubtedly. Like I said, it's not quite ready for inclusion in > contribs. BTW, a workaround until I get around to fixing this if you really want fasl files is to load everything first and then compile the files. I very rarely use fasl files for my own code because it's changing all the time and the CCL compiler is so fast. rg From joakim at joakimsandgren.com Sat Jun 13 14:12:33 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Sat, 13 Jun 2009 23:12:33 +0200 Subject: [Openmcl-devel] collapse selection Message-ID: Hi, I was wondering if someone could look at the collapse selection behavior (ticket #471). I think this is really a behavior that is not correct for a mac application. Is it very difficult to fix ? 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 ron at awun.net Sat Jun 13 15:51:53 2009 From: ron at awun.net (Ron Garret) Date: Sat, 13 Jun 2009 15:51:53 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> Message-ID: <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> On Jun 12, 2009, at 2:03 PM, Ron Garret wrote: > > On Jun 12, 2009, at 1:39 PM, Ron Garret wrote: > >> >>> >>> Does your code perhaps lack some (eval-when ...) >>> >> >> Undoubtedly. Like I said, it's not quite ready for inclusion in >> contribs. > > BTW, a workaround until I get around to fixing this if you really want > fasl files is to load everything first and then compile the files. And just in case anyone actually tried this, it won't work. The reason is that I'm doing (essentially) this: (defconstant +guardian+ (gensym)) as part of my iterators code. But it turns out this is a broken idiom because, as Gary points out in http://trac.clozure.com/ccl/ticket/539: The spec says: "If a defconstant form appears as a top level form, the compiler must recognize that name names a constant variable. An implementation may choose to evaluate the value-form at compile time, load time, or both. Therefore, users must ensure that the initial-value can be evaluated at compile time (regardless of whether or not references to name appear in the file) and that it always evaluates to the same value." I am open to suggestions on how to fix this because this leave me at a bit of a loss. rg From brian at mastenbrook.net Sat Jun 13 16:43:35 2009 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Sat, 13 Jun 2009 18:43:35 -0500 Subject: [Openmcl-devel] User contributions In-Reply-To: <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> Message-ID: On Jun 13, 2009, at 5:51 PM, Ron Garret wrote: > And just in case anyone actually tried this, it won't work. The > reason is that I'm doing (essentially) this: > > (defconstant +guardian+ (gensym)) > > as part of my iterators code. But it turns out this is a broken idiom > because, as Gary points out in http://trac.clozure.com/ccl/ticket/539: > > The spec says: > > "If a defconstant form appears as a top level form, the compiler must > recognize that name names a constant variable. An implementation may > choose to evaluate the value-form at compile time, load time, or both. > Therefore, users must ensure that the initial-value can be evaluated > at compile time (regardless of whether or not references to name > appear in the file) and that it always evaluates to the same value." > > > I am open to suggestions on how to fix this because this leave me at a > bit of a loss. Use a symbol-macro instead: (macrolet ((define-guardian (name) `(define-symbol-macro ,name ', (gensym)))) (define-guardian +guardian+)) -- Brian Mastenbrook brian at mastenbrook.net http://brian.mastenbrook.net/ From ron at awun.net Sat Jun 13 17:58:13 2009 From: ron at awun.net (Ron Garret) Date: Sat, 13 Jun 2009 17:58:13 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> Message-ID: On Jun 13, 2009, at 4:43 PM, Brian Mastenbrook wrote: > On Jun 13, 2009, at 5:51 PM, Ron Garret wrote: > >> And just in case anyone actually tried this, it won't work. The >> reason is that I'm doing (essentially) this: >> >> (defconstant +guardian+ (gensym)) >> >> as part of my iterators code. But it turns out this is a broken >> idiom >> because, as Gary points out in http://trac.clozure.com/ccl/ticket/ >> 539: >> >> The spec says: >> >> "If a defconstant form appears as a top level form, the compiler must >> recognize that name names a constant variable. An implementation may >> choose to evaluate the value-form at compile time, load time, or >> both. >> Therefore, users must ensure that the initial-value can be evaluated >> at compile time (regardless of whether or not references to name >> appear in the file) and that it always evaluates to the same value." >> >> >> I am open to suggestions on how to fix this because this leave me >> at a >> bit of a loss. > > Use a symbol-macro instead: > > (macrolet ((define-guardian (name) `(define-symbol-macro ,name ', > (gensym)))) > (define-guardian +guardian+)) That fails if you reload an uncompiled version of the file. Ironically, using DEFVAR instead of DEFCONSTANT or DEFINE-SYMBOL-MACRO comes closest to doing the Right Thing -- but then you can't rely on the system to prohibit assignment and rebinding. rg From ron at awun.net Sat Jun 13 18:03:15 2009 From: ron at awun.net (Ron Garret) Date: Sat, 13 Jun 2009 18:03:15 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> Message-ID: <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> On Jun 13, 2009, at 5:58 PM, Ron Garret wrote: > > On Jun 13, 2009, at 4:43 PM, Brian Mastenbrook wrote: > >> On Jun 13, 2009, at 5:51 PM, Ron Garret wrote: >> >>> And just in case anyone actually tried this, it won't work. The >>> reason is that I'm doing (essentially) this: >>> >>> (defconstant +guardian+ (gensym)) >>> >>> as part of my iterators code. But it turns out this is a broken >>> idiom >>> because, as Gary points out in http://trac.clozure.com/ccl/ticket/ >>> 539: >>> >>> The spec says: >>> >>> "If a defconstant form appears as a top level form, the compiler >>> must >>> recognize that name names a constant variable. An implementation may >>> choose to evaluate the value-form at compile time, load time, or >>> both. >>> Therefore, users must ensure that the initial-value can be evaluated >>> at compile time (regardless of whether or not references to name >>> appear in the file) and that it always evaluates to the same value." >>> >>> >>> I am open to suggestions on how to fix this because this leave me >>> at a >>> bit of a loss. >> >> Use a symbol-macro instead: >> >> (macrolet ((define-guardian (name) `(define-symbol-macro ,name ', >> (gensym)))) >> (define-guardian +guardian+)) > > That fails if you reload an uncompiled version of the file. > > Ironically, using DEFVAR instead of DEFCONSTANT or DEFINE-SYMBOL-MACRO > comes closest to doing the Right Thing -- but then you can't rely on > the system to prohibit assignment and rebinding. > This seems to mostly work: (defconstant +guardian+ '#.(gensym)) rg From ron at awun.net Sat Jun 13 18:20:26 2009 From: ron at awun.net (Ron Garret) Date: Sat, 13 Jun 2009 18:20:26 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> Message-ID: <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> On Jun 13, 2009, at 6:03 PM, Ron Garret wrote: > > On Jun 13, 2009, at 5:58 PM, Ron Garret wrote: > >> >> On Jun 13, 2009, at 4:43 PM, Brian Mastenbrook wrote: >> >>> On Jun 13, 2009, at 5:51 PM, Ron Garret wrote: >>> >>>> And just in case anyone actually tried this, it won't work. The >>>> reason is that I'm doing (essentially) this: >>>> >>>> (defconstant +guardian+ (gensym)) >>>> >>>> as part of my iterators code. But it turns out this is a broken >>>> idiom >>>> because, as Gary points out in http://trac.clozure.com/ccl/ticket/ >>>> 539: >>>> >>>> The spec says: >>>> >>>> "If a defconstant form appears as a top level form, the compiler >>>> must >>>> recognize that name names a constant variable. An implementation >>>> may >>>> choose to evaluate the value-form at compile time, load time, or >>>> both. >>>> Therefore, users must ensure that the initial-value can be >>>> evaluated >>>> at compile time (regardless of whether or not references to name >>>> appear in the file) and that it always evaluates to the same >>>> value." >>>> >>>> >>>> I am open to suggestions on how to fix this because this leave me >>>> at a >>>> bit of a loss. >>> >>> Use a symbol-macro instead: >>> >>> (macrolet ((define-guardian (name) `(define-symbol-macro ,name ', >>> (gensym)))) >>> (define-guardian +guardian+)) >> >> That fails if you reload an uncompiled version of the file. >> >> Ironically, using DEFVAR instead of DEFCONSTANT or DEFINE-SYMBOL- >> MACRO >> comes closest to doing the Right Thing -- but then you can't rely on >> the system to prohibit assignment and rebinding. >> > > This seems to mostly work: > > (defconstant +guardian+ '#.(gensym)) > But I think this is the Right Answer: (defmacro defguardian (name) `(defconstant ,name (if (boundp ',name) ,name (gensym)))) Or if you're really being paranoid: (defmacro defguardian (name) `(defconstant ,name (if (boundp ',name) ,name '#.(gensym)))) rg From rpgoldman at sift.info Sat Jun 13 18:50:24 2009 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 13 Jun 2009 20:50:24 -0500 Subject: [Openmcl-devel] User contributions In-Reply-To: <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> Message-ID: <4A345760.3060602@sift.info> Ron Garret wrote: > On Jun 12, 2009, at 2:03 PM, Ron Garret wrote: > >> On Jun 12, 2009, at 1:39 PM, Ron Garret wrote: >> >>>> Does your code perhaps lack some (eval-when ...) >>>> >>> Undoubtedly. Like I said, it's not quite ready for inclusion in >>> contribs. >> BTW, a workaround until I get around to fixing this if you really want >> fasl files is to load everything first and then compile the files. > > And just in case anyone actually tried this, it won't work. The > reason is that I'm doing (essentially) this: > > (defconstant +guardian+ (gensym)) > > as part of my iterators code. But it turns out this is a broken idiom > because, as Gary points out in http://trac.clozure.com/ccl/ticket/539: > > The spec says: > > "If a defconstant form appears as a top level form, the compiler must > recognize that name names a constant variable. An implementation may > choose to evaluate the value-form at compile time, load time, or both. > Therefore, users must ensure that the initial-value can be evaluated > at compile time (regardless of whether or not references to name > appear in the file) and that it always evaluates to the same value." > > > I am open to suggestions on how to fix this because this leave me at a > bit of a loss. Is it possible to write a macro that will look to see whether the +guardian+ is already bound and, if it is, keep the old binding, otherwise bind it by invoking gensym? This is pretty much what the define-constant macro (in the "Idiosyncracies"/"defining constants" section of the SBCL info file) does. Best, r From ron at awun.net Sun Jun 14 18:21:20 2009 From: ron at awun.net (Ron Garret) Date: Sun, 14 Jun 2009 18:21:20 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> Message-ID: <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> On Jun 13, 2009, at 6:20 PM, Ron Garret wrote: > > But I think this is the Right Answer: > > (defmacro defguardian (name) > `(defconstant ,name (if (boundp ',name) ,name (gensym)))) > > Or if you're really being paranoid: > > (defmacro defguardian (name) > `(defconstant ,name (if (boundp ',name) ,name '#.(gensym)))) Bloody hell, that doesn't work either! Do this: (eval-when (:compile-toplevel :load-toplevel :execute) (defun noisy-gensym () (format t "~&Calling gensym") (gensym)) (defmacro defguardian (name) `(defconstant ,name (if (boundp ',name) ,name (noisy-gensym)))) (defguardian foo) (defun foo () foo) ) Compile-and-load and observe that noisy-gensym gets called twice (and that foo and (foo) have different values). This is getting ridiculous. I humbly submit that there's a case to be made that allowing this kind of behavior is a bug in the standard. Or, failing that, a freedom that it might be wiser to choose to forego. Both CLisp and SBCL do the Right Thing with a simple defconstant. It should not be this hard to make a guardian. In fact, at this point I still don't know a way to do it that actually works in a compiled file in CCL. rg -------------- next part -------------- An HTML attachment was scrubbed... URL: From alms at clozure.com Mon Jun 15 08:51:28 2009 From: alms at clozure.com (Andrew Shalit) Date: Mon, 15 Jun 2009 11:51:28 -0400 Subject: [Openmcl-devel] collapse selection In-Reply-To: References: Message-ID: <3AFBC28A-D84F-4FA1-B5C5-20BC5819A286@clozure.com> This is bug #471 (http://trac.clozure.com/ccl/ticket/471), and it's being worked on. Andrew On Jun 13, 2009, at 5:12 PM, Joakim Sandgren wrote: > Hi, > I was wondering if someone could look at the collapse selection > behavior (ticket #471). > I think this is really a behavior that is not correct for a mac > application. > Is it very difficult to fix ? > > 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 > > _______________________________________________ > 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 rwiker at gmail.com Tue Jun 16 14:40:28 2009 From: rwiker at gmail.com (Raymond Wiker) Date: Tue, 16 Jun 2009 23:40:28 +0200 Subject: [Openmcl-devel] HANDLE leak in windows port Message-ID: <04318634-FFA1-4DC3-800C-3B0F54B83F04@gmail.com> I have a small web application built on top of Hunchentoot and supporting libraries, and have noticed that the number of Windows "handles" allocated to the process is steadily increasing. In fact, there seems to be a small number of handles leaked on every HTTP request. Having spent some time on this, my guess is that the low-level socket code tries to close sockets using the close() call. This would work on most Unixes (and Unixalikes), but Windows requires that closesocket() is used instead of close(). It appears that the function make-ioblock-stream has a hook for adding a socket-specific close() function, but it is hardcoded to 'fd-stream- close in the call from make-fd-stream. The call to make-fd-stream, in turn, has a TODO comment that indicates that the implementors have thought about the possible need for specializing close() behaviour. Does this make sense? From dlw at itasoftware.com Wed Jun 17 11:57:54 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Wed, 17 Jun 2009 14:57:54 -0400 Subject: [Openmcl-devel] User contributions In-Reply-To: <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> Message-ID: <4A393CB2.5040308@itasoftware.com> Ron Garret wrote: > > > It should not be this hard to make a guardian. In fact, at this > point I still don't know a way to do it that actually works in a > compiled file in CCL. What's a guardian? That is, what are you actually trying to do here? It looks like you are trying to establish an object that you know will be distinct from any object that is produced by any future call to read, and you want to give it a global name, and you want to make sure that a compile-time error will happen if there is any attempt to set or bind that name. Is that the goal? -- Dan > > 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 ron at awun.net Wed Jun 17 12:42:30 2009 From: ron at awun.net (Ron Garret) Date: Wed, 17 Jun 2009 12:42:30 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <4A393CB2.5040308@itasoftware.com> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> <4A393CB2.5040308@itasoftware.com> Message-ID: <24E7E7EA-A741-4645-A42A-F3064AF1F18F@awun.net> On Jun 17, 2009, at 11:57 AM, Dan Weinreb wrote: > > > Ron Garret wrote: >> >> >> >> It should not be this hard to make a guardian. In fact, at this >> point I still don't know a way to do it that actually works in a >> compiled file in CCL. > What's a guardian? > It's a singleton object that is used for its value alone, not for any operations that it performs. > That is, what are you actually trying to do here? I'm trying to implement abstract iterators without using conditions. > It looks like you are trying to establish an object > that you know will be distinct from any object > that is produced by any future call to read, > and you want to give it a global name, and > you want to make sure that a compile-time > error will happen if there is any attempt > to set or bind that name. Is that the goal? Almost. Having the guardian bound to a global name is a convenience, not a requirement. I don't really care if I access the guardian by typing +guardian+ or (+guardian+) or even (funcall '#.#'+guardian+) if push comes to shove. The invariant that I want to maintain is that the result of any reference to +guardian+ (or (+guardian+) or whatever) is always EQ to any other such reference or call, and always NOT eq to the result of any computation that does not reference or call +guardian+. And this invariant must hold regardless of any intervening operations (i.e. file compilations and load, assignments, etc.) It doesn't matter whether operations that would cause the invariant to be broken result in an error (like trying to rebind a constant), or if such operations are merely impossible (like trying to reassign a closed-over value in the absence of an explicit provision for do such a reassignment). BTW, just for perspective, this makes a very interesting intellectual exercise, but it's not all that important for my purposes. I'm content to work around the problem by simply using an interned symbol with a very obscure name. But I do think there's an argument to be made that allowing: (defconstant foo ...) (defun foo () foo) (eq foo (foo)) to return NIL is a bug in the spec. rg From dlw at itasoftware.com Wed Jun 17 13:15:12 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Wed, 17 Jun 2009 16:15:12 -0400 Subject: [Openmcl-devel] User contributions In-Reply-To: <24E7E7EA-A741-4645-A42A-F3064AF1F18F@awun.net> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> <4A393CB2.5040308@itasoftware.com> <24E7E7EA-A741-4645-A42A-F3064AF1F18F@awun.net> Message-ID: <4A394ED0.7000806@itasoftware.com> Ron Garret wrote: > > The invariant that I want to maintain is that the result of any > reference to +guardian+ (or (+guardian+) or whatever) is always EQ to > any other such reference or call, and always NOT eq to the result of > any computation that does not reference or call +guardian+. And this > invariant must hold regardless of any intervening operations (i.e. > file compilations and load, assignments, etc.) Well, if you mean this for the scope of a single Lisp world, then you could just do (defvar +guardian+ (list)) If you call compile-file or load or setq, as long as the symbol +guardian+ is not affected, your invariant is met. If you mean a scope larger than a Lisp world, there's a deep issue of what you mean by "eq". > > It doesn't matter whether operations that would cause the invariant to > be broken result in an error (like trying to rebind a constant), or if > such operations are merely impossible (like trying to reassign a > closed-over value in the absence of an explicit provision for do such > a reassignment). > > BTW, just for perspective, this makes a very interesting intellectual > exercise, but it's not all that important for my purposes. I'm > content to work around the problem by simply using an interned symbol > with a very obscure name. But I do think there's an argument to be > made that allowing: > > (defconstant foo ...) > (defun foo () foo) > (eq foo (foo)) > > to return NIL is a bug in the spec. Of course it will never return nil if you simply evaluate these three forms with a single Lisp world. The problems arise when you are crossing Lisp worlds, because you have one Lisp that compiles a file into a fasl and then a second Lisp that reads the fasl. If you first evaluate (defconstant foo (gensym)) and then you load in a file whose source contained that same form, you are violating the rule that says that a subsequent defconstant of the same symbol must have the same value. From ron at awun.net Wed Jun 17 15:46:47 2009 From: ron at awun.net (Ron Garret) Date: Wed, 17 Jun 2009 15:46:47 -0700 Subject: [Openmcl-devel] User contributions In-Reply-To: <4A394ED0.7000806@itasoftware.com> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> <4A393CB2.5040308@itasoftware.com> <24E7E7EA-A741-4645-A42A-F3064AF1F18F@awun.net> <4A394ED0.7000806@itasoftware.com> Message-ID: On Jun 17, 2009, at 1:15 PM, Dan Weinreb wrote: > > > Ron Garret wrote: >> >> The invariant that I want to maintain is that the result of any >> reference to +guardian+ (or (+guardian+) or whatever) is always EQ >> to any other such reference or call, and always NOT eq to the >> result of any computation that does not reference or call +guardian >> +. And this invariant must hold regardless of any intervening >> operations (i.e. file compilations and load, assignments, etc.) > Well, if you mean this for the scope of a single Lisp world, then > you could just do > > (defvar +guardian+ (list)) > > If you call compile-file or load or setq, as long as the > symbol +guardian+ is not affected, your invariant is > met. > > If you mean a scope larger than a Lisp world, there's a deep issue > of what you mean by "eq". > That's true, but it's a red-herring. You can exhibit the underlying problem without gensyms. For example: (eval-when (:compile-toplevel :load-toplevel :execute) (defconstant foo (get-internal-real-time)) (defun foo () foo) ) Compile this file, quit Lisp, reload the fasl. No errors, not even warnings about constants being redefined, and no existentially ambiguous constructs like uninterned symbols. And yet (equal foo (foo)) will return NIL with very high probability. The real problem is not in the meaning of "eq" but rather in the meaning of "constant." There are two possible meanings: 1. A value that the user can't change 2. A value that the compiler may (but is not obligated to) assume won't change The problem is that what I really want is #1, but I can't get it unless I also accept #2, and #2 causes problems because the compiler has too much latitude. What's really going on is that the compiler constant-folds the compile-time value of foo into the compiled version of #'foo, but not into the definition of the constant foo. The compiler is free to do so according to the spec, so the above behavior is technically correct. But behaving correctly is not necessarily the same as doing the Right Thing IMHO. rg From rme at clozure.com Thu Jun 18 00:16:05 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 18 Jun 2009 03:16:05 -0400 Subject: [Openmcl-devel] read-line Doesn't Return in IDE In-Reply-To: <7A456740-7124-4AB8-A791-209B80233801@gmail.com> References: <7A456740-7124-4AB8-A791-209B80233801@gmail.com> Message-ID: <94186B6A-D9E0-4B28-99D8-C3292837B81D@clozure.com> On Jun 11, 2009, at 5:56 PM, Chris Van Dusen wrote: > In the IDE: > Welcome to Clozure Common Lisp Version 1.4-dev-r12256M-trunk > (DarwinX8664)! > ? (read-line *query-io*) > this > > and it just sits there (so far...) This should work correctly again as of r12264. From tfb at tfeb.org Thu Jun 18 07:21:47 2009 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 18 Jun 2009 15:21:47 +0100 Subject: [Openmcl-devel] hash key on UK mac keyboards Message-ID: [Sorry, this may be not appropriate for this list: I would ask on IRC but have given up on Mac IRC clients for now...] Hi, I have a mac with a UK keyboard, and I'm using 1.3 but not fetched by SVN (the IDE-building instructions did not work for me so I just fetched the ftpable one). To type hash on one of these, you say option-3. (shift-3 is pound-sign). Of course, you can't type this if the IDE is set up to bind option to meta, and not being able to type hash is fairly annoying in CL. And of course, not having a meta key is also pretty irritating. I think that the answer is probably to work out how to bind shift-3 to insert a hash, and I can probably do that. But it's a very (*very*) long time since I used Hemlock, so if anyone else has seen this problem and can assist me being lazy, that would be much appreciated. Thanks --tim From cavandusen at gmail.com Thu Jun 18 08:26:48 2009 From: cavandusen at gmail.com (Chris Van Dusen) Date: Thu, 18 Jun 2009 10:26:48 -0500 Subject: [Openmcl-devel] read-line Doesn't Return in IDE In-Reply-To: <94186B6A-D9E0-4B28-99D8-C3292837B81D@clozure.com> References: <7A456740-7124-4AB8-A791-209B80233801@gmail.com> <94186B6A-D9E0-4B28-99D8-C3292837B81D@clozure.com> Message-ID: Thanks! One thing that I did notice is this when an error is encountered: > Type cmd-/ to continue, cmd-/ to abort, cmd-\ for a list of available restarts. One of them has to go... :) Chris. On Thu, Jun 18, 2009 at 2:16 AM, R. Matthew Emerson wrote: > > On Jun 11, 2009, at 5:56 PM, Chris Van Dusen wrote: > > > In the IDE: > > Welcome to Clozure Common Lisp Version 1.4-dev-r12256M-trunk > > (DarwinX8664)! > > ? (read-line *query-io*) > > this > > > > and it just sits there (so far...) > > This should work correctly again as of r12264. > _______________________________________________ > 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 Thu Jun 18 09:35:10 2009 From: lisp at clairvaux.org (Glen Foy) Date: Thu, 18 Jun 2009 12:35:10 -0400 Subject: [Openmcl-devel] hash key on UK mac keyboards In-Reply-To: References: Message-ID: On Jun 18, 2009, at 10:21 AM, Tim Bradshaw wrote: > [Sorry, this may be not appropriate for this list: I would ask on IRC > but have given up on Mac IRC clients for now...] > > Hi, I have a mac with a UK keyboard, and I'm using 1.3 but not fetched > by SVN (the IDE-building instructions did not work for me so I just > fetched the ftpable one). To type hash on one of these, you say > option-3. (shift-3 is pound-sign). Of course, you can't type this if > the IDE is set up to bind option to meta, and not being able to type > hash is fairly annoying in CL. And of course, not having a meta key > is also pretty irritating. > > I think that the answer is probably to work out how to bind shift-3 to > insert a hash, and I can probably do that. But it's a very (*very*) > long time since I used Hemlock, so if anyone else has seen this > problem and can assist me being lazy, that would be much appreciated Something like this might be what you want: (hi::defcommand "Insert Hash" (p) "Insert # on a UK keyboard." (let ((char #\#)) (if (and p (> p 1)) (hi::insert-string (hi::current-point-for-insertion) (make-string p :initial-element char)) (hi::insert-character (hi::current-point-for-insertion) char)))) (hi::bind-key "Insert Hash" #k"control-3") You can, of course, bind it to whatever keys you want. From tfb at tfeb.org Thu Jun 18 09:53:48 2009 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 18 Jun 2009 17:53:48 +0100 Subject: [Openmcl-devel] Rebuilding CCL Message-ID: Sorry, a followup question to the one I asked just now. How do you rebuild the Cocoa IDE? What I've done: - Fetched the original 1.3 .DMG file. The IDE works fine in this (so the various *.app things there are fine). - Discovered that, in fact, "svn update" works for this. Did that - rebuilt the command-line application using (ccl:rebuild-ccl :full t). This works fine - Now try ccl -e "(require :cocoa-application)". This builds an application bundle, but when you run it spits out a lot of noise about compiling & loading stuff into the listener, and then ends up in a break loop. If I run the command-line application (which claims to be "1.3- r12265M (Darwinx8632)" now), and do a (require "COCOA"), this does start the IDE, but each time you run it it compiles a lot of stuff. That smells bad to me - is there some issue with file-dates which I do not understand? I'm using an x86(-64) MacBook, running 10.5.7, patched to date. It may be that the answer is "the current version does not build" and I should just go back to the DMG one and not try and update/rebuild it: that would be fine, though it's kind of nice to be able to rebuild it. Thanks --tim From millejoh at mac.com Thu Jun 18 10:24:47 2009 From: millejoh at mac.com (John Miller) Date: Thu, 18 Jun 2009 12:24:47 -0500 Subject: [Openmcl-devel] Rebuilding CCL In-Reply-To: References: Message-ID: <60219792-F97A-49AC-BD03-9A2FACEA808D@mac.com> Tim, I find that doing a (require "COCOA-APPLICATION") from the command- line always works for me. Whenever I update from the IDE, however, the next time a restart I get an error in Hemlock (which I promise to make ticket for the next time it happens. Honest. Scout's honor.). I've been building from the trunk for many months and had almost no problems doing this. You might want to try doing this instead trying to update using the 1.3 DMG file as I do not think that set of files follows the trunk. Note that my version of CCL says "Welcome to Clozure Common Lisp Version 1.4-dev-r12265M-trunk (DarwinX8664)!" Cheers, John On Jun 18, 2009, at 11:53 AM, Tim Bradshaw wrote: > Sorry, a followup question to the one I asked just now. > > How do you rebuild the Cocoa IDE? > > What I've done: > - Fetched the original 1.3 .DMG file. The IDE works fine in this (so > the various *.app things there are fine). > - Discovered that, in fact, "svn update" works for this. Did that > - rebuilt the command-line application using (ccl:rebuild-ccl :full > t). This works fine > - Now try ccl -e "(require :cocoa-application)". This builds an > application bundle, but when you run it spits out a lot of noise about > compiling & loading stuff into the listener, and then ends up in a > break loop. > > If I run the command-line application (which claims to be "1.3- > r12265M (Darwinx8632)" now), and do a (require "COCOA"), this does > start the IDE, but each time you run it it compiles a lot of stuff. > That smells bad to me - is there some issue with file-dates which I do > not understand? > > I'm using an x86(-64) MacBook, running 10.5.7, patched to date. > > It may be that the answer is "the current version does not build" and > I should just go back to the DMG one and not try and update/rebuild > it: that would be fine, though it's kind of nice to be able to rebuild > it. > > Thanks > > --tim > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Thu Jun 18 10:33:52 2009 From: ron at awun.net (Ron Garret) Date: Thu, 18 Jun 2009 10:33:52 -0700 Subject: [Openmcl-devel] Rebuilding CCL In-Reply-To: <60219792-F97A-49AC-BD03-9A2FACEA808D@mac.com> References: <60219792-F97A-49AC-BD03-9A2FACEA808D@mac.com> Message-ID: One thing you might want to check is your init files. I've had problems in the past where an init file was loading something into the environment during a rebuild that CCL didn't like for reasons I can no longer recall. The -n flag is your friend in this case. rg On Jun 18, 2009, at 10:24 AM, John Miller wrote: > Tim, > > I find that doing a (require "COCOA-APPLICATION") from the command- > line always works for me. Whenever I update from the IDE, however, > the next time a restart I get an error in Hemlock (which I promise to > make ticket for the next time it happens. Honest. Scout's honor.). > > I've been building from the trunk for many months and had almost no > problems doing this. You might want to try doing this instead trying > to update using the 1.3 DMG file as I do not think that set of files > follows the trunk. Note that my version of CCL says "Welcome to > Clozure Common Lisp Version 1.4-dev-r12265M-trunk (DarwinX8664)!" > > > Cheers, > John > > On Jun 18, 2009, at 11:53 AM, Tim Bradshaw wrote: > >> Sorry, a followup question to the one I asked just now. >> >> How do you rebuild the Cocoa IDE? >> >> What I've done: >> - Fetched the original 1.3 .DMG file. The IDE works fine in this (so >> the various *.app things there are fine). >> - Discovered that, in fact, "svn update" works for this. Did that >> - rebuilt the command-line application using (ccl:rebuild-ccl :full >> t). This works fine >> - Now try ccl -e "(require :cocoa-application)". This builds an >> application bundle, but when you run it spits out a lot of noise >> about >> compiling & loading stuff into the listener, and then ends up in a >> break loop. >> >> If I run the command-line application (which claims to be "1.3- >> r12265M (Darwinx8632)" now), and do a (require "COCOA"), this does >> start the IDE, but each time you run it it compiles a lot of stuff. >> That smells bad to me - is there some issue with file-dates which I >> do >> not understand? >> >> I'm using an x86(-64) MacBook, running 10.5.7, patched to date. >> >> It may be that the answer is "the current version does not build" and >> I should just go back to the DMG one and not try and update/rebuild >> it: that would be fine, though it's kind of nice to be able to >> rebuild >> it. >> >> Thanks >> >> --tim >> _______________________________________________ >> 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 rme at clozure.com Thu Jun 18 11:25:55 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 18 Jun 2009 14:25:55 -0400 Subject: [Openmcl-devel] Rebuilding CCL In-Reply-To: References: Message-ID: <372601D5-4185-415F-AF80-8992EE164233@clozure.com> On Jun 18, 2009, at 12:53 PM, Tim Bradshaw wrote: > Sorry, a followup question to the one I asked just now. > > How do you rebuild the Cocoa IDE? > > What I've done: > - Fetched the original 1.3 .DMG file. The IDE works fine in this (so > the various *.app things there are fine). > - Discovered that, in fact, "svn update" works for this. Did that > - rebuilt the command-line application using (ccl:rebuild-ccl :full > t). This works fine > - Now try ccl -e "(require :cocoa-application)". This builds an > application bundle, but when you run it spits out a lot of noise about > compiling & loading stuff into the listener, and then ends up in a > break loop. As a workaround, try building the IDE by first starting up the lisp and then evaluating (require 'cocoa-application) at the prompt. In other words, don't use the -e command-line flag. $ ./dx86cl64 Welcome to Clozure Common Lisp Version 1.3-r12265M (DarwinX8664)! ? (require 'cocoa-application) [...] ;Loading #P"ccl:cocoa-ide;fasls;search-files.dx64fsl.newest"... ;Loading #P"ccl:cocoa-ide;fasls;start.dx64fsl.newest"... Saving application to /Users/rme/test/ccl/Clozure CL-x8664.app/ $ open ./Clozure\ CL-x8664.app/ That should work. > If I run the command-line application (which claims to be "1.3- > r12265M (Darwinx8632)" now), and do a (require "COCOA"), this does > start the IDE, but each time you run it it compiles a lot of stuff. > That smells bad to me - is there some issue with file-dates which I do > not understand? That's expected. (Hemlock always gets recompiled.) > It may be that the answer is "the current version does not build" and > I should just go back to the DMG one and not try and update/rebuild > it: that would be fine, though it's kind of nice to be able to rebuild > it. IDE development has been happening in the trunk. Until we somehow separate the Cocoa IDE from the base lisp, it's probably best for most IDE users to run the trunk. You can check out the trunk with: svn co http://svn.clozure.com/publicsvn/openmcl/trunk/darwinx86/ccl For instance, in the trunk, if a character typed with an option key turns out to be a standard-char, then we assume that the user meant to insert that char. This addresses the problem of typing a # on a UK keyboard, for instance: there's no need for a custom command. From raffaelcavallaro at mac.com Thu Jun 18 11:37:32 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Thu, 18 Jun 2009 14:37:32 -0400 Subject: [Openmcl-devel] Rebuilding CCL In-Reply-To: References: Message-ID: <296340CA-0F8A-4C9D-BBE0-3AC144AA5376@mac.com> On Jun 18, 2009, at 12:53 PM, Tim Bradshaw wrote: > If I run the command-line application (which claims to be "1.3- > r12265M (Darwinx8632)" now), and do a (require "COCOA"), this does > start the IDE, but each time you run it it compiles a lot of stuff. > That smells bad to me - is there some issue with file-dates which I do > not understand? I noticed the same thing a while back (February, according to the Finder). As a workaround I found that this works and I've used it successfully scores of times over the last several months: -------- begin rebuild-ccl ----------- #! /bin/sh cd ~/ccl svn update ./dx86cl64 -e "(ccl:rebuild-ccl :full t :force t)" -e "(quit)" ./dx86cl64 -e "#-easygui (require 'cocoa-application) #+easygui nil" ./dx86cl -e "(ccl:rebuild-ccl :full t :force t)" -e "(quit)" ./dx86cl -e "#-easygui (require 'cocoa-application) #+easygui nil" -------- end rebuild-ccl ------------ warmest regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From ron at awun.net Thu Jun 18 13:08:42 2009 From: ron at awun.net (Ron Garret) Date: Thu, 18 Jun 2009 13:08:42 -0700 Subject: [Openmcl-devel] Debugging threads Message-ID: <3345F833-6896-4A49-9293-A642407448A2@awun.net> What is ostensibly the current state of thread debugging? When I get an error in a thread I get a message like this in the altconsole: ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 33) to yield control to this thread. ;;; but when I follow the instructions nothing happens. I can inspect the thread through the Tools->Processes menu, but I can't figure out how to get a backtrace. Is this the way things are or am I doing something wrong? If the former, is there already a ticket on this or should I file one? I find it hard to believe that I'm the first person to want to get a backtrace on a thread. rg From rme at clozure.com Thu Jun 18 13:46:55 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Thu, 18 Jun 2009 16:46:55 -0400 Subject: [Openmcl-devel] Debugging threads In-Reply-To: <3345F833-6896-4A49-9293-A642407448A2@awun.net> References: <3345F833-6896-4A49-9293-A642407448A2@awun.net> Message-ID: <2FCFC4AF-27C7-436A-9570-01A3A09A478A@clozure.com> On Jun 18, 2009, at 4:08 PM, Ron Garret wrote: > What is ostensibly the current state of thread debugging? When I get > an error in a thread I get a message like this in the altconsole: > > ;;; > ;;; # requires access to > Shared Terminal Input > ;;; Type (:y 33) to yield control to this thread. > ;;; > > but when I follow the instructions nothing happens. I can inspect the > thread through the Tools->Processes menu, but I can't figure out how > to get a backtrace. > > Is this the way things are or am I doing something wrong? If the > former, is there already a ticket on this or should I file one? I > find it hard to believe that I'm the first person to want to get a > backtrace on a thread. Try (process-interrupt ccl::*initial-process* #'break); the break loop will occur in the altconsole and something will actually be around to read the (:y 33) that you type. Please do make a ticket. When we have a window system, it seems like we ought to be able to give each thread its own *terminal-io* (bound to a window stream or something). From tfb at tfeb.org Thu Jun 18 14:45:02 2009 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 18 Jun 2009 22:45:02 +0100 Subject: [Openmcl-devel] Rebuilding CCL In-Reply-To: <60219792-F97A-49AC-BD03-9A2FACEA808D@mac.com> References: <60219792-F97A-49AC-BD03-9A2FACEA808D@mac.com> Message-ID: <3F5387B6-05AF-4E70-8BBF-868F82F5D293@tfeb.org> On 18 Jun 2009, at 18:24, John Miller wrote: > I find that doing a (require "COCOA-APPLICATION") from the command- > line always works for me. Whenever I update from the IDE, however, > the next time a restart I get an error in Hemlock (which I promise > to make ticket for the next time it happens. Honest. Scout's > honor.). This seems to work for me, thanks. In fact I'm doing a combination of this and what Ron suggested, which seems to be enough (my init file, so far, only sets some printer control variables, but I've certainly known other systems to be fragile against this (for instance things that create symbols using (intern (with-output-to-string ...))). > > I've been building from the trunk for many months and had almost no > problems doing this. You might want to try doing this instead trying > to update using the 1.3 DMG file as I do not think that set of files > follows the trunk. Note that my version of CCL says "Welcome to > Clozure Common Lisp Version 1.4-dev-r12265M-trunk (DarwinX8664)!" Mine claims to be (a later version than it originally was of) 1.3. Given the cost of disk space and how long it takes to do a cold build, I probably will try keeping a trunk version as well in due course. Thanks to everyone who replied! --tim From tfb at tfeb.org Fri Jun 19 01:53:02 2009 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 19 Jun 2009 09:53:02 +0100 Subject: [Openmcl-devel] hash key on UK mac keyboards In-Reply-To: References: Message-ID: <5C581414-EC3C-4B71-8C38-64C432F3D748@tfeb.org> On 18 Jun 2009, at 17:35, Glen Foy wrote: > > Something like this might be what you want: > > (hi::defcommand "Insert Hash" (p) > "Insert # on a UK keyboard." > (let ((char #\#)) > (if (and p (> p 1)) > (hi::insert-string > (hi::current-point-for-insertion) > (make-string p :initial-element char)) > (hi::insert-character (hi::current-point-for-insertion) char)))) > > (hi::bind-key "Insert Hash" #k"control-3") Thank you, this works. It even brings back memories of Hemlock definitions I once made for CMUCL. The binding doesn't work because the OS has grabbed that somewhere (and plain shift-3 does not get through at all), but control-meta-3 works. I need to find something less painful to type, clearly. --tim From joakim at joakimsandgren.com Fri Jun 19 04:04:31 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 19 Jun 2009 13:04:31 +0200 Subject: [Openmcl-devel] concerning ticket #546 Message-ID: <791F694D-E5F9-424E-A386-C4D59FBEDE2C@joakimsandgren.com> this is in 1.4-dev-r12267M-trunk (DarwinX8632)! send you images here. should I put these images into the ticket? 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: Image 2.png Type: image/png Size: 39080 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Image 3.png Type: image/png Size: 44274 bytes Desc: not available URL: From ralex at cs.colorado.edu Fri Jun 19 07:51:03 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Fri, 19 Jun 2009 16:51:03 +0200 Subject: [Openmcl-devel] User contributions In-Reply-To: <4A393CB2.5040308@itasoftware.com> References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> <4A393CB2.5040308@itasoftware.com> Message-ID: <94B03517-CB2B-4CDA-9262-899AB3C9903D@cs.colorado.edu> I am not quite sure what the problem is but just in case you do need an UUID (from memory.lisp in XMLisp) here is a simple OS X way to do this: ;;______________________________________________________________ ;; Universally Unique Identifier (UUID) | ;; http://en.wikipedia.org/wiki/Universally_Unique_Identifier | ;;_____________________________________________________________/ (defun UNIVERSALLY-UNIQUE-IDENTIFIER () " Return an Universally Unique Identifier (UUID). An UUID is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE)" (ccl::lisp-string-from-nsstring (#_CFUUIDCreateString (%null-ptr) (#_CFUUIDCreate (%null-ptr))))) On Jun 17, 2009, at 8:57 PM, Dan Weinreb wrote: > It looks like you are trying to establish an object > that you know will be distinct from any object > that is produced by any future call to read, > and you want to give it a global name, and > you want to make sure that a compile-time > error will happen if there is any attempt > to set or bind that name. Is that the goal? 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 Fri Jun 19 08:09:25 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Fri, 19 Jun 2009 11:09:25 -0400 Subject: [Openmcl-devel] User contributions In-Reply-To: References: <200906101035.PYO67104@mr02.lnh.mail.rcn.net> <5065C024-18B6-4E09-B3BD-C009D2F5FF96@awun.net> <2F83EC94-1736-48E1-8CA2-396FF64A391C@awun.net> <1E45A9A3-DFB7-45A6-BF07-785EEABF9CEA@awun.net> <2E5D02D7-1D0C-4450-8929-125F59FCB168@awun.net> <965B6117-172E-4F27-82C5-731B785DDAD6@awun.net> <84678E15-BD1B-4917-B9EE-1A736CD75A0A@awun.net> <65F519F0-24A0-452B-812F-74215EAC1211@awun.net> <4A393CB2.5040308@itasoftware.com> <24E7E7EA-A741-4645-A42A-F3064AF1F18F@awun.net> <4A394ED0.7000806@itasoftware.com> Message-ID: <4A3BAA25.1030200@itasoftware.com> Yes, I agree completely. Well put. So the practical advice is that the value form of a defconstant must be a form that is idempotent, and it's probably also a very good idea for that form to have no side effects. This is a recommended convention that cannot (easily) be enforced. I'm adding this to our style guide. -- Dan Ron Garret wrote: > > On Jun 17, 2009, at 1:15 PM, Dan Weinreb wrote: > >> >> >> Ron Garret wrote: >>> >>> The invariant that I want to maintain is that the result of any >>> reference to +guardian+ (or (+guardian+) or whatever) is always EQ >>> to any other such reference or call, and always NOT eq to the result >>> of any computation that does not reference or call +guardian+. And >>> this invariant must hold regardless of any intervening operations >>> (i.e. file compilations and load, assignments, etc.) >> Well, if you mean this for the scope of a single Lisp world, then >> you could just do >> >> (defvar +guardian+ (list)) >> >> If you call compile-file or load or setq, as long as the >> symbol +guardian+ is not affected, your invariant is >> met. >> >> If you mean a scope larger than a Lisp world, there's a deep issue >> of what you mean by "eq". >> > > That's true, but it's a red-herring. You can exhibit the underlying > problem without gensyms. For example: > > (eval-when (:compile-toplevel :load-toplevel :execute) > (defconstant foo (get-internal-real-time)) > (defun foo () foo) > ) > > Compile this file, quit Lisp, reload the fasl. No errors, not even > warnings about constants being redefined, and no existentially > ambiguous constructs like uninterned symbols. And yet (equal foo > (foo)) will return NIL with very high probability. > > The real problem is not in the meaning of "eq" but rather in the > meaning of "constant." There are two possible meanings: > > 1. A value that the user can't change > > 2. A value that the compiler may (but is not obligated to) assume > won't change > > The problem is that what I really want is #1, but I can't get it > unless I also accept #2, and #2 causes problems because the compiler > has too much latitude. What's really going on is that the compiler > constant-folds the compile-time value of foo into the compiled version > of #'foo, but not into the definition of the constant foo. The > compiler is free to do so according to the spec, so the above behavior > is technically correct. But behaving correctly is not necessarily the > same as doing the Right Thing IMHO. > > rg > From joakim at joakimsandgren.com Fri Jun 19 08:15:01 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 19 Jun 2009 17:15:01 +0200 Subject: [Openmcl-devel] Fwd: [Clozure CL] #546: key args listing don't show References: <90722B36-7683-446A-8278-FA56721F31FA@joakimsandgren.com> Message-ID: I retry then. Joakim D?but du message r?exp?di? : > De : Joakim Sandgren > Date : 19 juin 2009 17:02:05 HAEC > ? : openmcl-trac at clozure.com > Cc : Gary Byers > Objet : R?p : [Clozure CL] #546: key args listing don't show > > This is true and make sens. But this was the beahvior in MCL. Before > I try to have an opinion here I dont have your example (defgeneric > draw-character ((c character) (s view) &key font color)) to work. It > gives me > > > Error: Bad generic function lambda list: ((C CHARACTER) (S VIEW) > &KEY FONT COLOR) > > While executing: CCL::CHECK-GENERIC-FUNCTION-LAMBDA-LIST, in > process Listener(6). > > Type cmd-. to abort, cmd-\ for a list of available restarts. > > Type :? for other options. > > or another > > Error: Bad generic function lambda list: ((TRUC LIST) &KEY FLUP > FLOP) > > While executing: CCL::CHECK-GENERIC-FUNCTION-LAMBDA-LIST, in > process Listener(6). > > Type cmd-. to abort, cmd-\ for a list of available restarts. > > Type :? for other options. > > or even > > Error: Bad generic function lambda list: ((TRUC LIST) (TRUC2 > NUMBER)) > > While executing: CCL::CHECK-GENERIC-FUNCTION-LAMBDA-LIST, in > process Listener(6). > > Type cmd-. to abort, cmd-\ for a list of available restarts. > > Type :? for other options. > > the only defgeneric arglist I have working is without specialized > arguments or with only &key (that do print the names in the > echoarea) or &rest argument. > > enlighten me please. > > sincerely > Joakim > > Le 19 juin 09 ? 16:11, Clozure CL a ?crit : > >> #546: key args listing don't show >> ----------------------- >> +---------------------------------------------------- >> Reporter: josa1965 | Owner: >> Type: defect | Status: closed >> Priority: normal | Milestone: >> Component: IDE | Version: 1.3 >> Resolution: invalid | Keywords: >> ----------------------- >> +---------------------------------------------------- >> Changes (by gb): >> >> * status: reopened => closed >> * resolution: => invalid >> >> Comment: >> >> Are you really talking about the case where a generic function has no >> specialized arguments but accepts &key ? >> >> In the general case (where a generic function accepts at least one >> required/specializable argument and its methods accept &key >> arguments), >> the generic function's lambda list merely contains &key; individual >> methods can accept different sets of keywords, and it's not >> meaningful or >> useful to say that the generic function accepts a particular set of >> keyword arguments (what arguments are actually accepted >> depends on what methods are applicable.) >> >> It's sometimes useful to declare that (all methods on) a particular >> generic function will accept (at least) a particular set of keyword >> arguments: >> >> {{{ >> (defgeneric draw-character ((c character) (s view) &key font color)) >> }}} >> >> so it's meaningful to say that "the arglist of the function DRAW- >> CHARACTER >> is (c s &key font color)", even though it's possible to define >> methods >> that accept additional keyword arguments. Without the DEFGENERIC, >> it's >> not really meaningful. >> >> In the case where only a single method is defined on a generic >> function >> (and in your specializer-less example, only a single primary method >> can >> ever be defined) we ''could'' conceivably say that the generic >> function's >> arglist is the sole method function's arglist, but (except in the >> specializer-less case) that'd mean that the generic function's >> arglist >> would change as soon as a second method was defined. >> >> If it's meaningful to talk about the set of keyword arguments >> accepted by >> a generic function, then the only way to define that set is to use >> DEFGENERIC (or the functional MOP equivalent.) >> >> -- >> Ticket URL: >> Clozure CL >> > > > > > 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 joakim at joakimsandgren.com Fri Jun 19 08:36:26 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Fri, 19 Jun 2009 17:36:26 +0200 Subject: [Openmcl-devel] =?iso-8859-1?q?R=E9p_=3A_=5BClozure_CL=5D_=23546?= =?iso-8859-1?q?=3A_key_args_listing_don=27t_show?= Message-ID: of course gb is right. but I am a very average user that have always lived with MCL and they echoed the - one and only - &key argument list. I mean, I have never gone very deep into all this and since MCL did echoed that I wanted i didint bother anymore. I'd say that 95 procent of my "functions" are defmethods, some small utilities are defuns, and defgenereic I have never used... I think it could even be a pedagogic view on this to make you reflecting over why defmethod isnt echoing the list... but yes, perhaps even if it is "stupid" and not "well done", one like me could use an echoing of the &key arg list in the only method of that genereic function... for the tickets, you have to correct me since I never used this kind of developing system before and am doing it only because Matthew Emserson encouraged us to do so - even if we wern't sure of if it was worth a ticket or not... so please correct me when I'm doing wrong. And, every time I wait one or two weeks and take another trunk, things have happened! I am very happy for all this!! Sincerely Joakim Le 19 juin 09 ? 16:23, Clozure CL a ?crit : > #546: key args listing don't show > -------------------------- > +------------------------------------------------- > Reporter: josa1965 | Owner: > Type: enhancement | Status: reopened > Priority: normal | Milestone: Cocoa IDE v? > Component: IDE | Version: 1.3 > Resolution: | Keywords: > -------------------------- > +------------------------------------------------- > Changes (by alms): > > * status: closed => reopened > * type: defect => enhancement > * resolution: invalid => > * milestone: => Cocoa IDE v? > > Comment: > > This is marked as an IDE ticket, not an ANSII CL or Compiler > ticket. So > I've reopened it and changed it from a defect to an enhancement. I > also > gave it milestone that indicates it's not part of the current round > IDE > work. > > GB is of course correct about the keyword arguments to generic > functions. > That said, the IDE could still be more helpful than it currently > is. I > can think of a couple of ways to handle this. > > If all of the methods on a generic function have the same keywords, > then > it could echo those keywords when it echoes the argument list. This > seems > like it should be straightforward and a good thing to do. > > If the methods have different keywords, we could consider echoing > all of > the keywords, maybe using font colors or something to distinguish > those > which are used by all the methods and those which are only used by > some. > I think this would be helpful, but others might find it confusing. > > -- > Ticket URL: > Clozure CL > 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 jared at cs.utexas.edu Fri Jun 19 14:27:24 2009 From: jared at cs.utexas.edu (Jared C. Davis) Date: Fri, 19 Jun 2009 16:27:24 -0500 Subject: [Openmcl-devel] save-application Message-ID: <75cb50350906191427g57f65e99ocd3dfcc498e57816@mail.gmail.com> Hi, I'm wondering about the :error-handler option on CCL::save-application. I'm using CCL 1.3-r12155M on Linux X86-64. I saved my program with (CCL::save-application "foo" :toplevel-function #'main :error-handler :quit) When I then cause my program to generate an error, e.g., by literally calling (error "something is wrong."), instead of quitting I see the following message: > Error: something is wrong. > While executing: function-that-calls-error, in process toplevel(2). ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 2) to yield con The message literally stops right there. I can Control+C out into a break loop, and from there I can quit. Anyway, I had expected it to quit instead. Is there an easy way to get the program to simply quit if there is any call of (error ...) encountered? Thanks! Jared -- Jared C. Davis 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/ From eslick at media.mit.edu Fri Jun 19 15:41:36 2009 From: eslick at media.mit.edu (Ian Eslick) Date: Fri, 19 Jun 2009 15:41:36 -0700 Subject: [Openmcl-devel] iPhone Message-ID: <2A0659FA-456A-44D1-8CFF-7795C939A592@media.mit.edu> I know there's an open task to think about making ClozureCL work on the ARM and use the bridge to build iPhone apps. Does anyone know whether such an app is remotely likely to pass the Apple store review process? Thank you, Ian From alms at clozure.com Fri Jun 19 16:02:31 2009 From: alms at clozure.com (Andrew Shalit) Date: Fri, 19 Jun 2009 19:02:31 -0400 Subject: [Openmcl-devel] iPhone In-Reply-To: <2A0659FA-456A-44D1-8CFF-7795C939A592@media.mit.edu> References: <2A0659FA-456A-44D1-8CFF-7795C939A592@media.mit.edu> Message-ID: It's certainly possible. Apple's rules for what they allow and don't allow give them a lot of leeway. The cynical might even call the rules arbitrary. Their restriction on interpreters would not necessarily disallow CL applications. They discuss interpreters in the same breath as "component systems." It looks like their chief concern is not opening a doorway that would allow users (or developers) to load additional executable code onto an app after it was delivered. If you had a Common Lisp application didn't expose that type of capability, it could certainly make it through. That said, Apple really has been arbitrary in rejecting apps. You don't have to look far to find multiple stories of people whose apps are rejected for doing things several previously approved apps do. It's a black box, and unless you have Nine Inch Nails' publicist, there's not a lot you can do about it. In term of making this a technical possibility: As far as I know, we haven't looked at what specifically would be required to build an app containing CCL that could be codesigned by Xcode. I just don't know how easy/hard/possible/impossible that would be. There's also the small matter of getting six to twelve months of Gary Byers' time funded to do the ARM port. If anyone would like to make a contribution to that, please let us know. We have not so far been able to find any significant funding source. I'd love to see it happen, though. On Jun 19, 2009, at 6:41 PM, Ian Eslick wrote: > I know there's an open task to think about making ClozureCL work on > the ARM and use the bridge to build iPhone apps. Does anyone know > whether such an app is remotely likely to pass the Apple store review > process? > > Thank you, > Ian > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From ron at awun.net Fri Jun 19 16:24:02 2009 From: ron at awun.net (Ron Garret) Date: Fri, 19 Jun 2009 16:24:02 -0700 Subject: [Openmcl-devel] iPhone In-Reply-To: References: <2A0659FA-456A-44D1-8CFF-7795C939A592@media.mit.edu> Message-ID: <702CB667-3D67-4071-B1B7-9B89A981D44E@awun.net> You might also want to consider a compiler written in CL for a non-CL Lisp dialect that compiled to Objective-C. That would be a lot easier to do (no GB-level guruness needed since you get the runtime and native code compilation for free), and you'd side-step a lot of the concerns about Apple rejecting the app out of prejudice. rg On Jun 19, 2009, at 4:02 PM, Andrew Shalit wrote: > It's certainly possible. Apple's rules for what they allow and don't > allow give them a lot of leeway. The cynical might even call the > rules arbitrary. > > Their restriction on interpreters would not necessarily disallow CL > applications. They discuss interpreters in the same breath as > "component systems." It looks like their chief concern is not opening > a doorway that would allow users (or developers) to load additional > executable code onto an app after it was delivered. If you had a > Common Lisp application didn't expose that type of capability, it > could certainly make it through. > > That said, Apple really has been arbitrary in rejecting apps. You > don't have to look far to find multiple stories of people whose apps > are rejected for doing things several previously approved apps do. > It's a black box, and unless you have Nine Inch Nails' publicist, > there's not a lot you can do about it. > > In term of making this a technical possibility: > > As far as I know, we haven't looked at what specifically would be > required to build an app containing CCL that could be codesigned by > Xcode. I just don't know how easy/hard/possible/impossible that would > be. > > There's also the small matter of getting six to twelve months of Gary > Byers' time funded to do the ARM port. If anyone would like to make a > contribution to that, please let us know. We have not so far been > able to find any significant funding source. > > I'd love to see it happen, though. > > > > > On Jun 19, 2009, at 6:41 PM, Ian Eslick wrote: > >> I know there's an open task to think about making ClozureCL work on >> the ARM and use the bridge to build iPhone apps. Does anyone know >> whether such an app is remotely likely to pass the Apple store review >> process? >> >> Thank you, >> Ian >> _______________________________________________ >> 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 neil.baylis at gmail.com Fri Jun 19 17:22:53 2009 From: neil.baylis at gmail.com (Neil Baylis) Date: Fri, 19 Jun 2009 17:22:53 -0700 Subject: [Openmcl-devel] iPhone In-Reply-To: <702CB667-3D67-4071-B1B7-9B89A981D44E@awun.net> References: <2A0659FA-456A-44D1-8CFF-7795C939A592@media.mit.edu> <702CB667-3D67-4071-B1B7-9B89A981D44E@awun.net> Message-ID: <1e6b7d810906191722t73c6a787u6ce788d9dbe8b909@mail.gmail.com> Recently info has been published about how to write iPhone apps using scheme. They use Gambit, which compiles into quite portable C code. info here... Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From lisp at clairvaux.org Sat Jun 20 09:25:38 2009 From: lisp at clairvaux.org (Glen Foy) Date: Sat, 20 Jun 2009 12:25:38 -0400 Subject: [Openmcl-devel] A question about ticket #400 Message-ID: In browsing the tickets today I came across this: "Define and implement an API for managing text attributes in editor buffers. It's not a near-term goal to make these text attributes persistent (i.e., to somehow save them with the file, via extended attributes on files or whatever), though it might be worthwhile to keep such a possibility in mind when designing the API." No persistent text attributes?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gz at clozure.com Sat Jun 20 09:44:23 2009 From: gz at clozure.com (Gail Zacharias) Date: Sat, 20 Jun 2009 12:44:23 -0400 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: References: Message-ID: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> At 6/20/2009 12:25 PM, Glen Foy wrote: >In browsing the tickets today I came across this: > >"Define and implement an API for managing text attributes in editor buffers. > >It's not a near-term goal to make these text attributes persistent >(i.e., to somehow save them with the file, via extended attributes >on files or whatever), though it might be worthwhile to keep such a >possibility in mind when designing the API." > > >No persistent text attributes?? Yeah, here's the thing... The API can easily provide any number of functions such as save/load-buffer-as-html or save/load-buffer-as-rtf or save/load-buffer-in-home-baked-format-with-font-info-encoded-in-lisp-comments or whatever, stuff like that would be trivial to write. The problem is that it's not clear to me what Hemlock should actually do to save the attributes, given the reality of living in a unix file system. Any thoughts? From sky at viridian-project.de Sat Jun 20 09:53:32 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sat, 20 Jun 2009 18:53:32 +0200 (CEST) Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> Message-ID: <6d06d2758a333431fb602b34d92110e4.squirrel@mail.stardawn.org> Gail Zacharias wrote: > The problem is that it's not clear to me what Hemlock should actually do > to save the attributes, given the reality of living in a unix file > system. Any thoughts? Vim stores marks, undo history and other things in a per-user file. Not sure if that's suitable here... Leslie -- http://www.linkedin.com/in/polzer From ron at awun.net Sat Jun 20 10:18:02 2009 From: ron at awun.net (Ron Garret) Date: Sat, 20 Jun 2009 10:18:02 -0700 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> Message-ID: On Jun 20, 2009, at 9:44 AM, Gail Zacharias wrote: > At 6/20/2009 12:25 PM, Glen Foy wrote: >> In browsing the tickets today I came across this: >> >> "Define and implement an API for managing text attributes in editor >> buffers. >> >> It's not a near-term goal to make these text attributes persistent >> (i.e., to somehow save them with the file, via extended attributes >> on files or whatever), though it might be worthwhile to keep such a >> possibility in mind when designing the API." >> >> >> No persistent text attributes?? > > > Yeah, here's the thing... The API can easily provide any number of > functions such as save/load-buffer-as-html or save/load-buffer-as-rtf > or > save/load-buffer-in-home-baked-format-with-font-info-encoded-in-lisp- > comments > or whatever, stuff like that would be trivial to write. The problem > is that it's not clear to me what Hemlock should actually do to save > the attributes, given the reality of living in a unix file > system. Any thoughts? I don't understand what aspect of "the reality of living in a unix file system" you think is relevant here. Is it that if you saved rich text as, say, RTF then you couldn't load it without munging the file to extract the plain text? I don't see why that's a problem. Just save rich text as .lisp.rtf and tweak LOAD and COMPILE-FILE to extract the plain text from those files instead of loading them raw. Or am I missing something? rg From lisp at clairvaux.org Sat Jun 20 10:23:42 2009 From: lisp at clairvaux.org (Glen Foy) Date: Sat, 20 Jun 2009 13:23:42 -0400 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> Message-ID: <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> On Jun 20, 2009, at 12:44 PM, Gail Zacharias wrote: > > Yeah, here's the thing... The API can easily provide any number of > functions such as save/load-buffer-as-html or save/load-buffer-as- > rtf or save/load-buffer-in-home-baked-format-with-font-info-encoded- > in-lisp-comments or whatever, stuff like that would be trivial to > write. The problem is that it's not clear to me what Hemlock should > actually do to save the attributes, given the reality of living in a > unix file system. Any thoughts? If we are just talking about Hemlock as a source code editor, it may not be necessary or even desirable to distribute styled files. Everyone has their own idea of what source code should look like anyway. From that point of view, the styling information could be stored in an associated invisible file and distributed or not distributed as the author saw fit. When hacking, Hemlock would look for the associated file, using it if it was there. This would be a simple solution. People may, however, want to use Hemlock for other purposes. In which case the two file approach is not so good. This issue clearly needs some brainstorming. From tfb at tfeb.org Sat Jun 20 15:52:53 2009 From: tfb at tfeb.org (Tim Bradshaw) Date: Sat, 20 Jun 2009 23:52:53 +0100 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> Message-ID: On 20 Jun 2009, at 18:23, Glen Foy wrote: > > > This issue clearly needs some brainstorming. I think it would be worth looking at what GNU Emacs does, and specifically at the various differences between it & Lucid Emacs (now Xemacs). I remember there being differences in approach (I was in the lemacs camp at the time). From gb at clozure.com Mon Jun 22 04:14:17 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 22 Jun 2009 05:14:17 -0600 (MDT) Subject: [Openmcl-devel] save-application In-Reply-To: <75cb50350906191427g57f65e99ocd3dfcc498e57816@mail.gmail.com> References: <75cb50350906191427g57f65e99ocd3dfcc498e57816@mail.gmail.com> Message-ID: I think that :error-handler is an anachronism that probably should be removed. The simplest way to get exit-on-error behavior is to start the application with the "--batch" command-line argument; that basically says "there's no one sitting at a keyboard to respond to a break loop, so just try to quit if a break loop would be entered", among other things. With that option if effect, an unhandled error will print a message to *ERROR-OUTPUT*, try to print a backtrace to *DEBUG-IO*, and exit with a non-zero status. On Fri, 19 Jun 2009, Jared C. Davis wrote: > Hi, > > I'm wondering about the :error-handler option on > CCL::save-application. I'm using CCL 1.3-r12155M on Linux X86-64. I > saved my program with > > (CCL::save-application "foo" > :toplevel-function #'main > :error-handler :quit) > > When I then cause my program to generate an error, e.g., by literally > calling (error "something is wrong."), instead of quitting I see the > following message: > > > Error: something is wrong. > > While executing: function-that-calls-error, in process toplevel(2). > > ;;; > ;;; # requires access > to Shared Terminal Input > ;;; Type (:y 2) to yield con > > The message literally stops right there. I can Control+C out into a > break loop, and from there I can quit. > > Anyway, I had expected it to quit instead. > > Is there an easy way to get the program to simply quit if there is any > call of (error ...) encountered? > > Thanks! > Jared > > > -- > Jared C. Davis > 11410 Windermere Meadows > Austin, TX 78759 > http://www.cs.utexas.edu/users/jared/ > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From dlw at itasoftware.com Mon Jun 22 10:47:54 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Mon, 22 Jun 2009 13:47:54 -0400 Subject: [Openmcl-devel] iPhone In-Reply-To: <1e6b7d810906191722t73c6a787u6ce788d9dbe8b909@mail.gmail.com> References: <2A0659FA-456A-44D1-8CFF-7795C939A592@media.mit.edu> <702CB667-3D67-4071-B1B7-9B89A981D44E@awun.net> <1e6b7d810906191722t73c6a787u6ce788d9dbe8b909@mail.gmail.com> Message-ID: <4A3FC3CA.8010809@itasoftware.com> Perhaps one could write an app in Common Lisp and then use a KCL-family implementation such as Embedded Common Lisp to generate a C implementation. Of course there are lots of issues of the runtime, libraries, talking to Objective-C, etc. Neil Baylis wrote: > Recently info has been published about how to write iPhone apps using > scheme. They use Gambit, which compiles into quite portable C code. > > info here... > > > Neil > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Jun 22 10:50:32 2009 From: dlw at itasoftware.com (Dan Weinreb) Date: Mon, 22 Jun 2009 13:50:32 -0400 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> Message-ID: <4A3FC468.6040803@itasoftware.com> Any approach that involves storing data in a separate file runs into problems when someone tries to move the file, rename the file, mail the file, back up the file, compress the file, put the file into an archive file, and so on. -- Dan Glen Foy wrote: > On Jun 20, 2009, at 12:44 PM, Gail Zacharias wrote: > >> Yeah, here's the thing... The API can easily provide any number of >> functions such as save/load-buffer-as-html or save/load-buffer-as- >> rtf or save/load-buffer-in-home-baked-format-with-font-info-encoded- >> in-lisp-comments or whatever, stuff like that would be trivial to >> write. The problem is that it's not clear to me what Hemlock should >> actually do to save the attributes, given the reality of living in a >> unix file system. Any thoughts? >> > > If we are just talking about Hemlock as a source code editor, it may > not be necessary or even desirable to distribute styled files. > Everyone has their own idea of what source code should look like anyway. > > From that point of view, the styling information could be stored in > an associated invisible file and distributed or not distributed as the > author saw fit. When hacking, Hemlock would look for the associated > file, using it if it was there. This would be a simple solution. > > > People may, however, want to use Hemlock for other purposes. In which > case the two file approach is not so good. > > > This issue clearly needs some brainstorming. > > > > > > > _______________________________________________ > 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 ron at awun.net Mon Jun 22 11:46:56 2009 From: ron at awun.net (Ron Garret) Date: Mon, 22 Jun 2009 11:46:56 -0700 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <4A3FC468.6040803@itasoftware.com> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> <4A3FC468.6040803@itasoftware.com> Message-ID: <713706A7-993A-48C4-90AF-873A19171F04@awun.net> IMHO, it's a mistake to put code in files at all, especially Lisp code. Lisp code isn't text, it's a data structure. It belongs in a database, not a file. The idea that code consists of lines of text is a leftover from the days when code resided on punched cards. rg On Jun 22, 2009, at 10:50 AM, Dan Weinreb wrote: > Any approach that involves storing data in a separate file > runs into problems when someone tries to move the file, > rename the file, mail the file, back up the file, compress > the file, put the file into an archive file, and so on. > -- Dan > > Glen Foy wrote: >> >> On Jun 20, 2009, at 12:44 PM, Gail Zacharias wrote: >> >>> Yeah, here's the thing... The API can easily provide any number of >>> functions such as save/load-buffer-as-html or save/load-buffer-as- >>> rtf or save/load-buffer-in-home-baked-format-with-font-info-encoded- >>> in-lisp-comments or whatever, stuff like that would be trivial to >>> write. The problem is that it's not clear to me what Hemlock should >>> actually do to save the attributes, given the reality of living in a >>> unix file system. Any thoughts? >>> >> >> If we are just talking about Hemlock as a source code editor, it may >> not be necessary or even desirable to distribute styled files. >> Everyone has their own idea of what source code should look like >> anyway. >> >> From that point of view, the styling information could be stored in >> an associated invisible file and distributed or not distributed as >> the >> author saw fit. When hacking, Hemlock would look for the associated >> file, using it if it was there. This would be a simple solution. >> >> >> People may, however, want to use Hemlock for other purposes. In >> which >> case the two file approach is not so good. >> >> >> This issue clearly needs some brainstorming. >> >> >> >> >> >> >> _______________________________________________ >> 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 Mon Jun 22 12:09:22 2009 From: lisp at clairvaux.org (Glen Foy) Date: Mon, 22 Jun 2009 15:09:22 -0400 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <4A3FC468.6040803@itasoftware.com> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> <4A3FC468.6040803@itasoftware.com> Message-ID: <64238533-5E49-484C-941B-9ECC46E44619@clairvaux.org> On Jun 22, 2009, at 1:50 PM, Dan Weinreb wrote: > Any approach that involves storing data in a separate file > runs into problems when someone tries to move the file, > rename the file, mail the file, back up the file, compress > the file, put the file into an archive file, and so on. Well, restyling a file is trivial after one of these operations. And if you are worried about countless, unused, invisible, zombie styling files slowly seizing control of your hard drive, a three minute hack could put them to rest. But all things considered, a one file solution is probably better. People will want to use Hemlock for various purposes. From kristianbredin at gmail.com Mon Jun 22 17:26:50 2009 From: kristianbredin at gmail.com (Kristian Bredin) Date: Tue, 23 Jun 2009 02:26:50 +0200 Subject: [Openmcl-devel] Profiling with profile.lisp in CCL? Message-ID: <8AA800EE-4A8A-49E8-83ED-2CE4AC13E4BF@gmail.com> Hi! I wonder if John Carroll by any chance is reading postings on this list (?) I used to (very much) like his profiling tool called "profile.lisp". However it doesn't seem to work in Clozure Common Lisp. Specifically, there's a few functions such as process.stack-group, process.quantum etc. that's not defined in Clozure Common Lisp. Anyone else that have been able to port this to CCL? Or if John is actually listening: should I hope for a port? All the best, Kristian From patrick.may at mac.com Mon Jun 22 18:13:30 2009 From: patrick.may at mac.com (Patrick May) Date: Mon, 22 Jun 2009 21:13:30 -0400 Subject: [Openmcl-devel] SSL_load_error_strings Message-ID: <0F213570-5611-4EBC-9BD5-58E899BDE056@mac.com> I'm using drakma to call out to a REST API. It works fine on my laptop under OSX but gives the error: Can't resolve foreign symbol "SSL_load_error_strings" on a CentOS box. OpenSSL is installed. What else do I need to configure? Thanks, Patrick From rme at clozure.com Mon Jun 22 19:30:38 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Mon, 22 Jun 2009 22:30:38 -0400 Subject: [Openmcl-devel] SSL_load_error_strings In-Reply-To: <0F213570-5611-4EBC-9BD5-58E899BDE056@mac.com> References: <0F213570-5611-4EBC-9BD5-58E899BDE056@mac.com> Message-ID: <826EF39A-873C-48D4-ADFD-44C83694849D@clozure.com> On Jun 22, 2009, at 9:13 PM, Patrick May wrote: > I'm using drakma to call out to a REST API. It works fine on my > laptop under OSX but gives the error: > > Can't resolve foreign symbol "SSL_load_error_strings" > > on a CentOS box. OpenSSL is installed. What else do I need to > configure? That's not much error context, so it's hard to say. Do you get similar results when doing the following? Welcome to Clozure Common Lisp Version 1.3-r12003M (LinuxX8632)! ? (open-shared-library "libssl.so") # ? (external "SSL_load_error_strings") # ? From patrick.may at mac.com Tue Jun 23 03:11:56 2009 From: patrick.may at mac.com (Patrick May) Date: Tue, 23 Jun 2009 06:11:56 -0400 Subject: [Openmcl-devel] SSL_load_error_strings In-Reply-To: <826EF39A-873C-48D4-ADFD-44C83694849D@clozure.com> References: <0F213570-5611-4EBC-9BD5-58E899BDE056@mac.com> <826EF39A-873C-48D4-ADFD-44C83694849D@clozure.com> Message-ID: On 22 Jun 2009, at 22:30, R. Matthew Emerson wrote: > On Jun 22, 2009, at 9:13 PM, Patrick May wrote: > >> I'm using drakma to call out to a REST API. It works fine on my >> laptop under OSX but gives the error: >> >> Can't resolve foreign symbol "SSL_load_error_strings" >> >> on a CentOS box. OpenSSL is installed. What else do I need to >> configure? > > That's not much error context, so it's hard to say. > > Do you get similar results when doing the following? > > Welcome to Clozure Common Lisp Version 1.3-r12003M (LinuxX8632)! > ? (open-shared-library "libssl.so") > # > ? (external "SSL_load_error_strings") > # libssl.so.6 #x149ECF86> > ? Here's what I get from that: Welcome to Clozure Common Lisp Version 1.3-r11936 (LinuxX8664)! ? (open-shared-library "libssl.so") > Error: Error opening shared library "libssl.so": libssl.so: cannot open shared object file: No such file or directory > While executing: OPEN-SHARED-LIBRARY, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > :pop ? (open-shared-library "libssl3.so") # ? (external "SSL_load_error_strings") # ? That looks like there is a problem. Do I need a different version of OpenSSL? Thanks, Patrick From gb at clozure.com Tue Jun 23 03:54:34 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 23 Jun 2009 04:54:34 -0600 (MDT) Subject: [Openmcl-devel] SSL_load_error_strings In-Reply-To: References: <0F213570-5611-4EBC-9BD5-58E899BDE056@mac.com> <826EF39A-873C-48D4-ADFD-44C83694849D@clozure.com> Message-ID: On a Fedora 10 system (which is likely sort of a distant cousin of whatever version of CentOS you're running), 'libssl.so' is a symbolic link to a particular version of the SSL library; the versioned library is installed as part of an 'openssl' package, while the link is part of an 'openssl-devel' package. There are possibly both 64- and 32-bit versions, and you seem to be running a 64-bit version of CCL (and therefore want to install the 64-bit version(s)). The original error about failure to resolve (determine the address of) the symbol "SSL_load_error_strings" would usually occur if something tries to use (call the code at) that address. Before reaching that point, the lisp package ("drakma" or one of its dependencies) that you're using would likely have tried to open the library that defines that symbol. That presumably didn't happen or quietly failed; you might want to see if you can find out what's going on there (since loading the library would be the first step here ...) On Tue, 23 Jun 2009, Patrick May wrote: > On 22 Jun 2009, at 22:30, R. Matthew Emerson wrote: >> On Jun 22, 2009, at 9:13 PM, Patrick May wrote: >> >>> I'm using drakma to call out to a REST API. It works fine on my >>> laptop under OSX but gives the error: >>> >>> Can't resolve foreign symbol "SSL_load_error_strings" >>> >>> on a CentOS box. OpenSSL is installed. What else do I need to >>> configure? >> >> That's not much error context, so it's hard to say. >> >> Do you get similar results when doing the following? >> >> Welcome to Clozure Common Lisp Version 1.3-r12003M (LinuxX8632)! >> ? (open-shared-library "libssl.so") >> # >> ? (external "SSL_load_error_strings") >> #> libssl.so.6 #x149ECF86> >> ? > > Here's what I get from that: > > Welcome to Clozure Common Lisp Version 1.3-r11936 (LinuxX8664)! > ? (open-shared-library "libssl.so") > > Error: Error opening shared library "libssl.so": libssl.so: cannot > open shared object file: No such file or directory > > While executing: OPEN-SHARED-LIBRARY, in process listener(1). > > Type :POP to abort, :R for a list of available restarts. > > Type :? for other options. > 1 > :pop > > ? (open-shared-library "libssl3.so") > # > ? (external "SSL_load_error_strings") > # #x30004149FCBD> > ? > > That looks like there is a problem. Do I need a different version of > OpenSSL? > > Thanks, > > Patrick > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From patrick.may at mac.com Tue Jun 23 04:15:03 2009 From: patrick.may at mac.com (Patrick May) Date: Tue, 23 Jun 2009 07:15:03 -0400 Subject: [Openmcl-devel] SSL_load_error_strings In-Reply-To: <1245755004.2206.5.camel@blackhole.universe.org> References: <0F213570-5611-4EBC-9BD5-58E899BDE056@mac.com> <826EF39A-873C-48D4-ADFD-44C83694849D@clozure.com> <1245755004.2206.5.camel@blackhole.universe.org> Message-ID: <4111B890-008E-453E-A2F7-364F3DBF60E5@mac.com> On 23 Jun 2009, at 07:03, Stelian Ionescu wrote: > On Tue, 2009-06-23 at 06:11 -0400, Patrick May wrote: >> Here's what I get from that: >> >> Welcome to Clozure Common Lisp Version 1.3-r11936 (LinuxX8664)! >> ? (open-shared-library "libssl.so") >>> Error: Error opening shared library "libssl.so": libssl.so: cannot >> open shared object file: No such file or directory >>> While executing: OPEN-SHARED-LIBRARY, in process listener(1). >>> Type :POP to abort, :R for a list of available restarts. >>> Type :? for other options. >> 1 > :pop >> >> ? (open-shared-library "libssl3.so") >> # >> ? (external "SSL_load_error_strings") >> #> #x30004149FCBD> >> ? >> >> That looks like there is a problem. Do I need a different version of >> OpenSSL? > > /usr/lib/libssl3.so is not openssl, but NSS(Mozilla's own SSL > library). > What you need is /lib/libssl.so.6 Thanks, I'm getting closer. I do have /lib/libssl.so.6 installed. Do I need to set my LD_LIBRARY_PATH to allow Clozure and cl+ssl to see it? Regards, Patrick From ralex at cs.colorado.edu Tue Jun 23 09:42:07 2009 From: ralex at cs.colorado.edu (Alexander Repenning) Date: Tue, 23 Jun 2009 18:42:07 +0200 Subject: [Openmcl-devel] A question about ticket #400 In-Reply-To: <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> References: <200906201645.PZH01743@mr02.lnh.mail.rcn.net> <71F0A1DE-C8A9-4BA9-8DAF-686E60BD9B4C@clairvaux.org> Message-ID: <9A3D7682-994F-417E-A1DD-C4AAF75881AF@cs.colorado.edu> I agree. It should be OK to just keep the content of a file ASCII (or unicode) and apply the styling just in time. Even Google code can do this (using Java script) at a fast enough rate. Saving would only save ASCII/unicode but one could have a Save As option including saving the styled version as RTF. alex On Jun 20, 2009, at 7:23 PM, Glen Foy wrote: > > On Jun 20, 2009, at 12:44 PM, Gail Zacharias wrote: >> >> Yeah, here's the thing... The API can easily provide any number of >> functions such as save/load-buffer-as-html or save/load-buffer-as- >> rtf or save/load-buffer-in-home-baked-format-with-font-info-encoded- >> in-lisp-comments or whatever, stuff like that would be trivial to >> write. The problem is that it's not clear to me what Hemlock should >> actually do to save the attributes, given the reality of living in a >> unix file system. Any thoughts? > > If we are just talking about Hemlock as a source code editor, it may > not be necessary or even desirable to distribute styled files. > Everyone has their own idea of what source code should look like > anyway. > > From that point of view, the styling information could be stored in > an associated invisible file and distributed or not distributed as the > author saw fit. When hacking, Hemlock would look for the associated > file, using it if it was there. This would be a simple solution. > > > People may, however, want to use Hemlock for other purposes. In which > case the two file approach is not so good. > > > This issue clearly needs some brainstorming. > > > > > > > _______________________________________________ > 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 howell at ucsc.edu Tue Jun 23 11:12:52 2009 From: howell at ucsc.edu (David Cope) Date: Tue, 23 Jun 2009 11:12:52 -0700 Subject: [Openmcl-devel] font size Message-ID: Apologes for such a simple question/fix. We're teaching Lisp using Clozure for the first time and noticed that the information at the bottom of the Listener disappears after the font size for the window exceeds 14 pt. We're projecting for all of the students to see and keeping that little info bit alive would be very helpful. Thanks, Dave C howell at ucsc.edu http://arts.ucsc.edu/faculty/cope WACM - Workshop in Algorithmic Computer Music http://arts.ucsc.edu/WACM From rme at clozure.com Tue Jun 23 12:03:43 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Tue, 23 Jun 2009 15:03:43 -0400 Subject: [Openmcl-devel] font size In-Reply-To: References: Message-ID: <08F9CEC8-42A8-4730-B33A-53ADA1C60E02@clozure.com> On Jun 23, 2009, at 2:12 PM, David Cope wrote: > Apologes for such a simple question/fix. We're teaching > Lisp using Clozure for the first time and noticed that the > information at the bottom of the Listener disappears after > the font size for the window exceeds 14 pt. We're > projecting for all of the students to see and keeping that > little info bit alive would be very helpful. I checked in a quick little hack to the trunk that makes the echo area height correspond to the size of the default font. (http://trac.clozure.com/openmcl/changeset/12282 ) I hope that helps. From joakim at joakimsandgren.com Wed Jun 24 02:02:13 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Wed, 24 Jun 2009 11:02:13 +0200 Subject: [Openmcl-devel] changeset 12281 Message-ID: is fantastic!! thank you for the correct collapsings!!! I just run upon a small thing... when you have doubleclicked a word to select it, and then take shift meta to the right it extends the selection with the word to the right of the slected word. but when you chave doubleclicked a word and take meta shift and Left arrow, you first de-select the selected word and then start to select the words to the left of the first selected word, instead of starting to select the word to the left of the selected word. that is, then you double click select a word, the position is to the right of the word... thank you very much for the good work! 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 didier at lrde.epita.fr Wed Jun 24 06:00:39 2009 From: didier at lrde.epita.fr (Didier Verna) Date: Wed, 24 Jun 2009 15:00:39 +0200 Subject: [Openmcl-devel] [Final CfPart] 6th European Lisp Workshop, July 6th, Genova, Italy Message-ID: +------------------------------------------------------------+ | FINAL CALL FOR PARTICIPATION | | 6th European Lisp Workshop | | July 6, Genova, Italy - co-located with ECOOP 2009 | | http://elw.bknr.net/2009 | +------------------------------------------------------------+ Important Dates =============== ECOOP late registration deadline: July 03, 2009 6th European Lisp Workshop: July 06, 2009 Please note that registration must be done with ECOOP itself. There is a reduced registration fee for workshop-only attendance. The early registration deadline is in two days, so register now! See http://ecoop09.disi.unige.it/ for details. 2009 Special News ================= * Edi Weitz will give a keynote address on the use of his notorious open source libraries in commercial / industrial application. * The workshop is sponsored by ITA Software, Inc. Please visit them at http://www.itasoftware.com/ * This year, and for the first time, the workshop proceedings will be published in the ACM Digital Library. Overview ======== "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bio-informatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp, one of the eldest computer languages still in use today, is gaining momentum again. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch, making it the ideal candidate for writing Domain Specific Languages. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and retains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. This workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit contributions that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. Programme ========= In addition to Edi Weitz's keynote address, the workshop will feature four technical papers and two tutorials. Please visit the programme web page (http://elw2009.bknr.net/programme) for a detailed description. Organizers ========== Didier Verna, EPITA Research and Development Laboratory, Paris Charlotte Herzeel, Programming Technology Lab, Vrije Universiteit, Brussel Robert Strandh, LaBRI, University of Bordeaux I, France Christophe Rhodes, Goldsmiths College, University of London Hans H?bner, Software Developer, Berlin -- European Lisp Workshop, July 6th, Genova, Italy: http://elw.bknr.net/2009 Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com From mevins at mac.com Wed Jun 24 06:05:25 2009 From: mevins at mac.com (mikel evins) Date: Wed, 24 Jun 2009 08:05:25 -0500 Subject: [Openmcl-devel] changeset 12281 In-Reply-To: References: Message-ID: <20999406-1F27-429F-B7D3-7C034B75AE9D@mac.com> On Jun 24, 2009, at 4:02 AM, Joakim Sandgren wrote: > is fantastic!! > thank you for the correct collapsings!!! > > I just run upon a small thing... > when you have doubleclicked a word to select it, and then take shift > meta to the right it extends the selection with the word to the > right of the slected word. > but when you chave doubleclicked a word and take meta shift and Left > arrow, you first de-select the selected word and then start to > select the words to the left of the first selected word, instead of > starting to select the word to the left of the selected word. > that is, then you double click select a word, the position is to the > right of the word... THanks for the report; I'll look at this one right away. --me From joakim at joakimsandgren.com Wed Jun 24 08:22:29 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Wed, 24 Jun 2009 17:22:29 +0200 Subject: [Openmcl-devel] changeset 12281 In-Reply-To: <20999406-1F27-429F-B7D3-7C034B75AE9D@mac.com> References: <20999406-1F27-429F-B7D3-7C034B75AE9D@mac.com> Message-ID: <8D6C1E4A-8974-4702-82A8-4C8AEA2CA6FB@joakimsandgren.com> Thank You! I propose that you add to the default hemlock bindings.lisp file these: (hi:bind-key "Select Forward Word" #k"meta-shift-rightarrow") (hi:bind-key "Select Backward Word" #k"meta-shift-leftarrow") (hi:bind-key "Forward Form" #k"control-rightarrow") (hi:bind-key "Select Forward Form" #k"control-shift-rightarrow") (hi:bind-key "Backward Form" #k"control-leftarrow") (hi:bind-key "Select Backward Form" #k"control-shift-leftarrow") but it is perhaps too personal...? by the way the (hi:bind-key "Select Backward Character" #k"shift-leftarrow") (hi:bind-key "Select Forward Character" #k"shift-rightarrow") do not work... why? and... I found that doubleclicking on a form to select it, then collapsing it to the right or to the left, return do not work anymore as new-line for this document. if you are to the left, the form goes line by line downward but the cursor stay in place - like control-O, if you collapse to the right you create a new line underneith the form but the cursor is still in place (just to the left of the collapsed form).. and this is like it is everywhere - in that document. if you open another return is return again. if you close the other document and reopen it everything is ok again... collapsing form seems to alter the retrurn - new line function... Sincerely Joakim Le 24 juin 09 ? 15:05, mikel evins a ?crit : > > On Jun 24, 2009, at 4:02 AM, Joakim Sandgren wrote: > >> is fantastic!! >> thank you for the correct collapsings!!! >> >> I just run upon a small thing... >> when you have doubleclicked a word to select it, and then take >> shift meta to the right it extends the selection with the word to >> the right of the slected word. >> but when you chave doubleclicked a word and take meta shift and >> Left arrow, you first de-select the selected word and then start to >> select the words to the left of the first selected word, instead of >> starting to select the word to the left of the selected word. >> that is, then you double click select a word, the position is to >> the right of the word... > > THanks for the report; I'll look at this one right away. > > --me > > 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 mevins at mac.com Wed Jun 24 08:30:31 2009 From: mevins at mac.com (mikel evins) Date: Wed, 24 Jun 2009 10:30:31 -0500 Subject: [Openmcl-devel] changeset 12281 In-Reply-To: <8D6C1E4A-8974-4702-82A8-4C8AEA2CA6FB@joakimsandgren.com> References: <20999406-1F27-429F-B7D3-7C034B75AE9D@mac.com> <8D6C1E4A-8974-4702-82A8-4C8AEA2CA6FB@joakimsandgren.com> Message-ID: <054E99E5-BEA4-4365-937A-6F5352C8949B@mac.com> On Jun 24, 2009, at 10:22 AM, Joakim Sandgren wrote: > Thank You! > I propose that you add to the default hemlock bindings.lisp file > these: > > (hi:bind-key "Select Forward Word" #k"meta-shift-rightarrow") > (hi:bind-key "Select Backward Word" #k"meta-shift-leftarrow") > > (hi:bind-key "Forward Form" #k"control-rightarrow") > (hi:bind-key "Select Forward Form" #k"control-shift-rightarrow") > > (hi:bind-key "Backward Form" #k"control-leftarrow") > (hi:bind-key "Select Backward Form" #k"control-shift-leftarrow") I'll add them and see if anyione objects. Looking into this question, I'm finding that there are several common movement and selection commands that don't have bindings or don't work in Hemlock right now. I'll see if I can improve that situation (but I also need to characterize it well enough to write a decent Trac ticket for it). > but it is perhaps too personal...? > > by the way the > (hi:bind-key "Select Backward Character" #k"shift-leftarrow") > (hi:bind-key "Select Forward Character" #k"shift-rightarrow") > do not work... > why? Heck if I know; I was just looking at that myself, and scratching my head about it. I'll see if I can fix that, too. > and... I found that doubleclicking on a form to select it, then > collapsing it to the right or to the left, return do not work > anymore as new-line for this document. > if you are to the left, the form goes line by line downward but the > cursor stay in place - like control-O, > if you collapse to the right you create a new line underneith the > form but the cursor is still in place (just to the left of the > collapsed form).. > and this is like it is everywhere - in that document. if you open > another return is return again. if you close the other document and > reopen it everything is ok again... > > collapsing form seems to alter the retrurn - new line function... Yeah, that's unexpected, too. I guess I know what I'll be working on for the next few days. Thanks for all the input; it's very helpful. --me From ron at awun.net Wed Jun 24 09:37:06 2009 From: ron at awun.net (Ron Garret) Date: Wed, 24 Jun 2009 09:37:06 -0700 Subject: [Openmcl-devel] Did the subversion server change? Message-ID: <730FB3F3-6F05-4274-BDFB-92EB22665754@awun.net> I'm suddenly getting this error when it always worked before: [ron at mickey:~/devel/ccl/trunk]$ svn update subversion/libsvn_wc/questions.c:110: (apr_err=155021) svn: This client is too old to work with working copy '.'; please get a newer Subversion client Did you guys update your subversion? rg From kpreid at mac.com Wed Jun 24 09:41:57 2009 From: kpreid at mac.com (Kevin Reid) Date: Wed, 24 Jun 2009 12:41:57 -0400 Subject: [Openmcl-devel] Did the subversion server change? In-Reply-To: <730FB3F3-6F05-4274-BDFB-92EB22665754@awun.net> References: <730FB3F3-6F05-4274-BDFB-92EB22665754@awun.net> Message-ID: <13BD27FA-D9B6-48FD-9F0C-5A435F6E2DCB@mac.com> On Jun 24, 2009, at 12:37, Ron Garret wrote: > I'm suddenly getting this error when it always worked before: > > [ron at mickey:~/devel/ccl/trunk]$ svn update > subversion/libsvn_wc/questions.c:110: (apr_err=155021) > svn: This client is too old to work with working copy '.'; please get > a newer Subversion client > > Did you guys update your subversion? That error is completely independent of the server. You must have touched your working copy with a newer Subversion client; perhaps you have two different versions installed? If you must downgrade, use -- Kevin Reid From ron at awun.net Wed Jun 24 10:46:12 2009 From: ron at awun.net (Ron Garret) Date: Wed, 24 Jun 2009 10:46:12 -0700 Subject: [Openmcl-devel] Did the subversion server change? In-Reply-To: <13BD27FA-D9B6-48FD-9F0C-5A435F6E2DCB@mac.com> References: <730FB3F3-6F05-4274-BDFB-92EB22665754@awun.net> <13BD27FA-D9B6-48FD-9F0C-5A435F6E2DCB@mac.com> Message-ID: <9876123A-E8FD-4ABA-8010-2E15C94438B3@awun.net> On Jun 24, 2009, at 9:41 AM, Kevin Reid wrote: > On Jun 24, 2009, at 12:37, Ron Garret wrote: > >> I'm suddenly getting this error when it always worked before: >> >> [ron at mickey:~/devel/ccl/trunk]$ svn update >> subversion/libsvn_wc/questions.c:110: (apr_err=155021) >> svn: This client is too old to work with working copy '.'; please get >> a newer Subversion client >> >> Did you guys update your subversion? > > That error is completely independent of the server. You must have > touched your working copy with a newer Subversion client; perhaps you > have two different versions installed? Nope, I haven't changed anything. I did, however, have a very old svn client (1.3.1). I upgraded and that fixed it. 12281 is indeed very cool! :-) rg From mevins at mac.com Wed Jun 24 12:02:43 2009 From: mevins at mac.com (mikel evins) Date: Wed, 24 Jun 2009 14:02:43 -0500 Subject: [Openmcl-devel] changeset 12281 In-Reply-To: <8D6C1E4A-8974-4702-82A8-4C8AEA2CA6FB@joakimsandgren.com> References: <20999406-1F27-429F-B7D3-7C034B75AE9D@mac.com> <8D6C1E4A-8974-4702-82A8-4C8AEA2CA6FB@joakimsandgren.com> Message-ID: On Jun 24, 2009, at 10:22 AM, Joakim Sandgren wrote: > Thank You! > I propose that you add to the default hemlock bindings.lisp file > these: > > (hi:bind-key "Select Forward Word" #k"meta-shift-rightarrow") > (hi:bind-key "Select Backward Word" #k"meta-shift-leftarrow") > > (hi:bind-key "Forward Form" #k"control-rightarrow") > (hi:bind-key "Select Forward Form" #k"control-shift-rightarrow") > > (hi:bind-key "Backward Form" #k"control-leftarrow") > (hi:bind-key "Select Backward Form" #k"control-shift-leftarrow") > > but it is perhaps too personal...? > > by the way the > (hi:bind-key "Select Backward Character" #k"shift-leftarrow") > (hi:bind-key "Select Forward Character" #k"shift-rightarrow") > do not work... > why? > > and... I found that doubleclicking on a form to select it, then > collapsing it to the right or to the left, return do not work > anymore as new-line for this document. > if you are to the left, the form goes line by line downward but the > cursor stay in place - like control-O, > if you collapse to the right you create a new line underneith the > form but the cursor is still in place (just to the left of the > collapsed form).. > and this is like it is everywhere - in that document. if you open > another return is return again. if you close the other document and > reopen it everything is ok again... > > collapsing form seems to alter the retrurn - new line function... It didn't, but it did bash point in a way that confsed the buffer. I *think* all the above are fixed in 12287. If that's true, then we'll no doubt discover something else that needs fixing. :-) --me From patrick.may at mac.com Wed Jun 24 14:32:52 2009 From: patrick.may at mac.com (Patrick May) Date: Wed, 24 Jun 2009 17:32:52 -0400 Subject: [Openmcl-devel] SSL_load_error_strings In-Reply-To: References: <0F213570-5611-4EBC-9BD5-58E899BDE056@mac.com> <826EF39A-873C-48D4-ADFD-44C83694849D@clozure.com> Message-ID: <420AB5B1-2E15-40E2-92A4-CD837CB7A667@mac.com> On 23 Jun 2009, at 06:54, Gary Byers wrote: > On a Fedora 10 system (which is likely sort of a distant cousin of > whatever version of CentOS you're running), 'libssl.so' is a symbolic > link to a particular version of the SSL library; the versioned library > is installed as part of an 'openssl' package, while the link is part > of an 'openssl-devel' package. There are possibly both 64- and 32-bit > versions, and you seem to be running a 64-bit version of CCL (and > therefore want to install the 64-bit version(s)). Thanks. "yum install openssl-devel" did the trick. Regards, Patrick From ron at awun.net Wed Jun 24 22:04:31 2009 From: ron at awun.net (Ron Garret) Date: Wed, 24 Jun 2009 22:04:31 -0700 Subject: [Openmcl-devel] Keybindings Message-ID: <514FF604-5381-49D3-B10A-5DE97768701C@awun.net> Pressing TAB indents the current line, but not the current region (if there's one selected. If I do this: (hi:bind-key "Indent Region" #k"tab") then TAB indents the current region if one is selected, but not the current line if one is not. Is there any way to get TAB to do both depending on whether or not there is a selection? And while I'm at it... is there a way to get a list of all the current keybindings, and a list of all of the commands available to be bound to key events? Thanks, rg From gb at clozure.com Wed Jun 24 23:42:00 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 25 Jun 2009 00:42:00 -0600 (MDT) Subject: [Openmcl-devel] Keybindings In-Reply-To: <514FF604-5381-49D3-B10A-5DE97768701C@awun.net> References: <514FF604-5381-49D3-B10A-5DE97768701C@awun.net> Message-ID: On Wed, 24 Jun 2009, Ron Garret wrote: > Pressing TAB indents the current line, but not the current region (if > there's one selected. If I do this: > > (hi:bind-key "Indent Region" #k"tab") > > then TAB indents the current region if one is selected, but not the > current line if one is not. > > Is there any way to get TAB to do both depending on whether or not > there is a selection? Sure: define a command that does both, depending on whether or not there's a selection, then bind #k"tab" to that command. > > And while I'm at it... > > is there a way to get a list of all the current keybindings, and a > list of all of the commands available to be bound to key events? C-h is actually somehat useful (sometimes). (Try "C-h h" to see what options C-h supports.) Note that I'm not trying to claim that C-h is anything more than "somewhat useful, sometimes"; it's a few notches above "completely useless" and several notches below "as useful as it could be." C-h m describes all of the key bindings available in a named "mode"; it doesn't describe bindings that're common to all modes. (I don't know of a way to do that via C-h.) If all else fails, most (all ?) of the calls to HI:BIND-KEY that establish key bindings are in "ccl:cocoa-ide;hemlock;src;bindings.lisp". > > Thanks, > rg > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From ron at awun.net Wed Jun 24 23:46:42 2009 From: ron at awun.net (Ron Garret) Date: Wed, 24 Jun 2009 23:46:42 -0700 Subject: [Openmcl-devel] Keybindings In-Reply-To: References: <514FF604-5381-49D3-B10A-5DE97768701C@awun.net> Message-ID: On Jun 24, 2009, at 11:42 PM, Gary Byers wrote: > > If all else fails, most (all ?) of the calls to HI:BIND-KEY that > establish > key bindings are in "ccl:cocoa-ide;hemlock;src;bindings.lisp". > Just what I was looking for. Thanks! rg From joakim at joakimsandgren.com Thu Jun 25 00:00:25 2009 From: joakim at joakimsandgren.com (Joakim Sandgren) Date: Thu, 25 Jun 2009 09:00:25 +0200 Subject: [Openmcl-devel] changeset 12281 In-Reply-To: References: <20999406-1F27-429F-B7D3-7C034B75AE9D@mac.com> <8D6C1E4A-8974-4702-82A8-4C8AEA2CA6FB@joakimsandgren.com> Message-ID: <150D690A-F4E3-4BC0-9A5F-300631B40B91@joakimsandgren.com> brilliant!! all is working super!!! now its just the "select word to the left of a doubleclick selected word" that isnt in place... ;-) its going fast forward!! sincerely Joakim Le 24 juin 09 ? 21:02, mikel evins a ?crit : > > On Jun 24, 2009, at 10:22 AM, Joakim Sandgren wrote: > >> Thank You! >> I propose that you add to the default hemlock bindings.lisp file >> these: >> >> (hi:bind-key "Select Forward Word" #k"meta-shift-rightarrow") >> (hi:bind-key "Select Backward Word" #k"meta-shift-leftarrow") >> >> (hi:bind-key "Forward Form" #k"control-rightarrow") >> (hi:bind-key "Select Forward Form" #k"control-shift-rightarrow") >> >> (hi:bind-key "Backward Form" #k"control-leftarrow") >> (hi:bind-key "Select Backward Form" #k"control-shift-leftarrow") >> >> but it is perhaps too personal...? >> >> by the way the >> (hi:bind-key "Select Backward Character" #k"shift-leftarrow") >> (hi:bind-key "Select Forward Character" #k"shift-rightarrow") >> do not work... >> why? >> >> and... I found that doubleclicking on a form to select it, then >> collapsing it to the right or to the left, return do not work >> anymore as new-line for this document. >> if you are to the left, the form goes line by line downward but the >> cursor stay in place - like control-O, >> if you collapse to the right you create a new line underneith the >> form but the cursor is still in place (just to the left of the >> collapsed form).. >> and this is like it is everywhere - in that document. if you open >> another return is return again. if you close the other document and >> reopen it everything is ok again... >> >> collapsing form seems to alter the retrurn - new line function... > > It didn't, but it did bash point in a way that confsed the buffer. > > I *think* all the above are fixed in 12287. If that's true, then > we'll no doubt discover something else that needs fixing. :-) > > --me > > 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 Thu Jun 25 00:00:51 2009 From: ron at awun.net (Ron Garret) Date: Thu, 25 Jun 2009 00:00:51 -0700 Subject: [Openmcl-devel] Keybindings In-Reply-To: References: <514FF604-5381-49D3-B10A-5DE97768701C@awun.net> Message-ID: <35F9D204-5325-4357-AE73-7381293A4C96@awun.net> On Jun 24, 2009, at 11:42 PM, Gary Byers wrote: > > > On Wed, 24 Jun 2009, Ron Garret wrote: > >> Pressing TAB indents the current line, but not the current region (if >> there's one selected. If I do this: >> >> (hi:bind-key "Indent Region" #k"tab") >> >> then TAB indents the current region if one is selected, but not the >> current line if one is not. >> >> Is there any way to get TAB to do both depending on whether or not >> there is a selection? > > Sure: define a command that does both, depending on whether or not > there's a selection, then bind #k"tab" to that command. > Woohoo! (defcommand "Indent" (p) "Invokes function held by the Hemlock variable \"Indent Function\", moving point past region if called with argument." (if (region-active-p) (let ((region (current-region))) (with-mark ((start (region-start region) :left-inserting) (end (region-end region) :left-inserting)) (indent-region-for-commands (region start end)))) (let ((point (current-point))) (with-mark ((mark point :left-inserting)) (cond ((or (not p) (zerop p)) (funcall (value indent-function) mark) (when (mark< point mark) (move-mark point mark))) (t (if (plusp p) (unless (line-offset point (1- p)) (buffer-end point)) (unless (line-offset mark (1+ p)) (buffer-start mark))) (indent-region-for-commands (region mark point)) (find-attribute (line-start point) :whitespace #'zerop))))))) rg From mevins at mac.com Thu Jun 25 06:39:09 2009 From: mevins at mac.com (mikel evins) Date: Thu, 25 Jun 2009 08:39:09 -0500 Subject: [Openmcl-devel] changeset 12281 In-Reply-To: <150D690A-F4E3-4BC0-9A5F-300631B40B91@joakimsandgren.com> References: <20999406-1F27-429F-B7D3-7C034B75AE9D@mac.com> <8D6C1E4A-8974-4702-82A8-4C8AEA2CA6FB@joakimsandgren.com> <150D690A-F4E3-4BC0-9A5F-300631B40B91@joakimsandgren.com> Message-ID: <423CF09B-873E-4989-9BC5-1286227D98DC@mac.com> On Jun 25, 2009, at 2:00 AM, Joakim Sandgren wrote: > brilliant!! all is working super!!! > > now its just the "select word to the left of a doubleclick selected > word" that isnt in place... ;-) Oooo...just to make sure I identify that one correctly, what keybinding do you expect to do that? --me From mevins at mac.com Thu Jun 25 06:48:51 2009 From: mevins at mac.com (mikel evins) Date: Thu, 25 Jun 2009 08:48:51 -0500 Subject: [Openmcl-devel] Keybindings In-Reply-To: References: <514FF604-5381-49D3-B10A-5DE97768701C@awun.net> Message-ID: <554800F8-0A3C-45AA-BE3D-A1D5450ACC56@mac.com> On Jun 25, 2009, at 1:42 AM, Gary Byers wrote: > If all else fails, most (all ?) of the calls to HI:BIND-KEY that > establish > key bindings are in "ccl:cocoa-ide;hemlock;src;bindings.lisp". All except for one to start italics in icom.lisp, I think. There are more files to look in for commands. The easy way to find them all is to do something like grep -inr defcommand path/to/cocoa-ide | grep -v unused | grep -v \.svn (I hope the correction for that path is obvious.) Looks like the files to search are cocoa-ide/cocoa-grep.lisp cocoa-ide/hemlock/src/command.lisp cocoa-ide/hemlock/src/completion.lisp cocoa-ide/hemlock/src/doccoms.lisp cocoa-ide/hemlock/src/echocoms.lisp cocoa-ide/hemlock/src/edit-defs.lisp cocoa-ide/hemlock/src/filecoms.lisp cocoa-ide/hemlock/src/fill.lisp cocoa-ide/hemlock/src/icom.lisp cocoa-ide/hemlock/src/indent.lisp cocoa-ide/hemlock/src/isearchcoms.lisp cocoa-ide/hemlock/src/killcoms.lisp cocoa-ide/hemlock/src/lispmode.lisp cocoa-ide/hemlock/src/listener.lisp cocoa-ide/hemlock/src/morecoms.lisp cocoa-ide/hemlock/src/register.lisp cocoa-ide/hemlock/src/searchcoms.lisp cocoa-ide/hemlock/src/symbol-completion.lisp cocoa-ide/hemlock/src/text.lisp cocoa-ide/hemlock/src/undo.lisp From mevins at mac.com Thu Jun 25 07:20:58 2009 From: mevins at mac.com (mikel evins) Date: Thu, 25 Jun 2009 09:20:58 -0500 Subject: [Openmcl-devel] up and working on ccl some more Message-ID: <082AC876-A531-4607-8880-FCABF8E3FA96@mac.com> From j-anthony at comcast.net Thu Jun 25 13:53:35 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Thu, 25 Jun 2009 16:53:35 -0400 Subject: [Openmcl-devel] GC aspects, tuning, behavior Message-ID: <1245963215.2420.607.camel@sirius> Hi, This will likely be a few exchanges... As part of my ongoing porting/open sourcing the graph store/semantic engine system I have developed I am now educating myself on various details of CCLs GC. This is to enable understanding the basic behavior for various possible tuning scenarios in different circumstances. I have a pretty good grip on various details of ACL's GC when originally looking into this sort of stuff, but (being implementation dependent - a good thing here...) CCL's is different. If you have a bunch of objects that will be allocated up front for some processing, and you know that these will basically be around for the life of the program (more or less), it can be useful to just allocate them from the start in old space. In ACL you can do this by setting the generation-spread to 0 and tenure-limit to nil. Basically this means new things have no generations to move through - just go directly to old space - and inhibit GC (tenure "unlimited" amount until next trigger). Of course, you also need to request enough old space up front. CCL's GC has three basic generations for new space allocations: young, medium, old. I don't think old here is true old space, but simply the oldest new space generation before things get tenured to old space. But I could be wrong, but assuming I'm not, (lisp-heap-gc-threshold new-threshold) should basically do the job of requesting enough space, assuming you can request a full GC. Is there a means of requesting a full GC? ccl::freeze does this, but with the (undoubtedly useful as times) side effect of pinning everything left alive as non relocatable. That's a very neat feature, but is primary reason for freeze - not the full GC it also does. Next, if you set the generation 0-2 sizes all to 0, would this indicate to the GC that all new things are just immediately placed in old space? (like setting generation-spread to 0 in ACL). I'm not sure about this one, especially as the documentation says that whatever is requested is rounded up to a multiple of 64KB (of course 0 is such a multiple, but...) Along with this - are there multiple old spaces, and if so do they behave analogous to the generations in new space (ACL does something like this - it may not even make sense for CCL's GC but I thought I'd ask...) Let's start with this and see what happens :-) Thanks in advance for any info! /Jon From terje at in-progress.com Thu Jun 25 13:37:07 2009 From: terje at in-progress.com (Terje Norderhaug) Date: Thu, 25 Jun 2009 13:37:07 -0700 Subject: [Openmcl-devel] Process attributes Message-ID: I am working on extending the Swank server (for Slime) to provide more information about the processes of a remote Clozure than what currently is available. But: Calling ccl::process-total-run-time returns NIL on Clozure Version 1.3-r11936 (DarwinPPC32). Is there a way to get the total run time of a process in Clozure (actively executing, not just how long time it is since the process was created)? Also, MCL provides a process-last-run-time that can be used to determine how long time a process has been idle. Does Clozure have such functionality? I've peeked into l1-processes.lisp to no avail. -- Terje Norderhaug From gb at clozure.com Thu Jun 25 14:27:32 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 25 Jun 2009 15:27:32 -0600 (MDT) Subject: [Openmcl-devel] Process attributes In-Reply-To: References: Message-ID: On Thu, 25 Jun 2009, Terje Norderhaug wrote: > I am working on extending the Swank server (for Slime) to provide > more information about the processes of a remote Clozure than what > currently is available. But: > > Calling ccl::process-total-run-time returns NIL on Clozure Version > 1.3-r11936 (DarwinPPC32). Is there a way to get the total run time > of a process in Clozure (actively executing, not just how long time > it is since the process was created)? If the OS keeps track of this, then there's generally some OS-dependent way of asking about it. (I'm sure that there's a way to get that info on Mach/OSX and on Windows, -think- that I know how to do it on Linux, suspect that there are ways of doing it on Solaris, don't really know how to do it on FreeBSD.) > > Also, MCL provides a process-last-run-time that can be used to > determine how long time a process has been idle. Does Clozure have > such functionality? The OS is the only thing that could possibly know this and I don't know of any OS that exposes the info. (There's generally no way in which the information could be accurate, since the thread you'd be asking about might start and stop running an arbitrary number of times while you were asking.) > > I've peeked into l1-processes.lisp to no avail. I have a feeling we're not in Kansas anymore. > > -- Terje Norderhaug > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From gb at clozure.com Thu Jun 25 18:33:58 2009 From: gb at clozure.com (Gary Byers) Date: Thu, 25 Jun 2009 19:33:58 -0600 (MDT) Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: <1245963215.2420.607.camel@sirius> References: <1245963215.2420.607.camel@sirius> Message-ID: CCL's GC basically manages a single contiguous region of memory; you can think of that region as being divided into two subregions. The subregion "on the left" contains allocated objects (things that survived the last GC) and the subregion "on the right" contains free space. When an image is first loaded and after a full GC, the size of the free space is determined by LISP-HEAP-GC-THRESHOLD. Conceptually (it doesn't really work exactly like this), free space fills up from left to right; when free space fills up completely, a full GC is triggered. The GC identifies which objects are live, then does an in-place, order-preserving compaction of live objects ("towards the left"), creating contiguous free space on the right. If necessary, more pages are obtained from the OS so that the free space is of a size determined by LISP-HEAP-GC-THRESHOLD; in some cases, the heap can shrink and unneeded pages can be returned to the OS. (There's a large - possibly very large - chunk of reserved address space "to the right" of the free area.) The fact that garbage is returned to (contiguous) free space by in-place, order-preserving compaction offers some useful properties. If allocated object X is "to the left of" (has a lower address than) object Y, then it is generally true that X is older than Y (X has survived more GC cycles than Y has), though X and Y may be of the same vintage/generation. If we wanted to, we could keep some extra bookkeeping information and identify each subregion of allocated space that had survived I full GCs for I = 1 .. N, and part of that bookkeeping might involve adjusting some pointers if/when things moved around due to compaction. We don't actually do that, but we do use a similar scheme to keep track of things on the right end of allocated space (maintaining regions that describe "newly allocated things", "things that've survived a few GCs", "things that've survived quite a few GCs but might still become garbage soon.") These regions are the EGC's "generations", and they're basically just a pair of pointers to the start and end of a region in allocated space and a threshold/limit value that affects EGC policy (how big the youngest generation can get before the EGC is invoked, how big the older ephemeral generations can get before the EGC looks at them as well as looking at the youngest generation.) The EGC's essentially doing the same work as the full GC does - identifying live objects and doing an in-place order-preserving compaction on them - only it's doing that work on (generally) small subregions of at the extreme right end of allocated space. To the extent that it's true that a high percentage of newly-allocated objects are short-lived, this work is productive. (That's true of all ephemeral/generational GC schemes; the only things that might be atypical of CCL's EGC is that promoting/tenuring objects from one generation to the next is done by adjusting the bounds of the generations, not by copying things to other memory areas.) There are a lot of things to like about this scheme; it makes allocation quick (since free memory is contiguous) and it generally takes time proportional to the number of live objects. The worst-case scenarios - which would involve copying large objects around during in-place compaction - tend not to happen all that often (or tend to happen a few times before things stabilize.) In practice, long-lived objects tend not to move around, though in theory they could. The scheme doesn't special-case "large" objects (they tend to behave like the pig in the python: the pig eventually gets from one end of the python to the other, but it's not always pleasant for pig or python and may involve some premature tenuring.) There's no way to allocate an object and declare it to be "old", though this could be done (essentially by pushing everything to the right and allocating the object at or near the extreme left.) I can imagine cases where this would be worthwhile and desirable, but in most cases where I'd have been concerned about this that concern has been unfounded. You can manually invoke a full GC via (CCL:GC). There's no way to trigger the EGC manually. I don't remember if anything checks for it, but setting the size of generation 0 to 0 will probably cause the EGC to be triggered unproductively (if it doesn't cause worse behavior.) Setting the size of generations 1 or 2 to 0 could be done but may not be very useful; making the generations slightly larger than the defaults could improve performance somewhat (if things are "short-lived, but not THAT short-lived.") On Thu, 25 Jun 2009, Jon S. Anthony wrote: > Hi, > > This will likely be a few exchanges... > > As part of my ongoing porting/open sourcing the graph store/semantic > engine system I have developed I am now educating myself on various > details of CCLs GC. This is to enable understanding the basic behavior > for various possible tuning scenarios in different circumstances. I have > a pretty good grip on various details of ACL's GC when originally > looking into this sort of stuff, but (being implementation dependent - a > good thing here...) CCL's is different. > > If you have a bunch of objects that will be allocated up front for some > processing, and you know that these will basically be around for the > life of the program (more or less), it can be useful to just allocate > them from the start in old space. In ACL you can do this by setting the > generation-spread to 0 and tenure-limit to nil. Basically this means > new things have no generations to move through - just go directly to old > space - and inhibit GC (tenure "unlimited" amount until next trigger). > Of course, you also need to request enough old space up front. > > CCL's GC has three basic generations for new space allocations: young, > medium, old. I don't think old here is true old space, but simply the > oldest new space generation before things get tenured to old space. But > I could be wrong, but assuming I'm not, > > (lisp-heap-gc-threshold new-threshold) should basically do the job of > requesting enough space, assuming you can request a full GC. > > Is there a means of requesting a full GC? ccl::freeze does this, but > with the (undoubtedly useful as times) side effect of pinning everything > left alive as non relocatable. That's a very neat feature, but is > primary reason for freeze - not the full GC it also does. > > > Next, if you set the generation 0-2 sizes all to 0, would this indicate > to the GC that all new things are just immediately placed in old space? > (like setting generation-spread to 0 in ACL). I'm not sure about this > one, especially as the documentation says that whatever is requested is > rounded up to a multiple of 64KB (of course 0 is such a multiple, > but...) > > Along with this - are there multiple old spaces, and if so do they > behave analogous to the generations in new space (ACL does something > like this - it may not even make sense for CCL's GC but I thought I'd > ask...) > > Let's start with this and see what happens :-) > > Thanks in advance for any info! > > /Jon > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > > From rme at clozure.com Fri Jun 26 10:35:31 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Fri, 26 Jun 2009 13:35:31 -0400 Subject: [Openmcl-devel] upcoming release Message-ID: We'd like to do another release of Clozure CL within the next month or so. If there are bugs or enhancement requests that should get attention before the release, please open Trac tickets for them. If you have (or have been watching) existing tickets that don't seem to be getting anywhere, you might leave a comment on the ticket asking about its status. Thanks for all the bug reports and feedback to date. From rme at clozure.com Fri Jun 26 11:07:25 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Fri, 26 Jun 2009 14:07:25 -0400 Subject: [Openmcl-devel] Cocoa-based IDE sources Message-ID: Thanks to funding from users, we've been able to do some significant work on the Cocoa-based IDE. As you probably know, we use the Subversion revision control system to manage the CCL sources. Ongoing development takes place in the trunk. This generally works fine. In the case of the Cocoa-based IDE, however, this has caused some minor trouble. Users who are interested in improvements the IDE have been obliged to track and run the trunk, even though it's probably the case that such users would normally like to run a release. Therefore, it seems like it might be a good idea to separate the Cocoa- based IDE sources in some way. Here are some approaches we could take: * Make the svn external for the cocoa-ide/ directory in the release branches point to the cocoa-ide/ sources in the trunk. (We do a similar thing already for the documentation.) The idea would be that the IDE is still under rapid enough development that it doesn't make sense to periodically say "this is a stable release point". * Move the Cocoa-based IDE sources into a separate repository entirely. The IDE would essentially become an application that could be installed, much like, e.g. Hunchentoot or McCLIM. We could still use an svn external to point to the IDE sources, but maybe we would only do this for the Mac OS X targets. If anyone has suggestions on how to better manage this, I'd be interested to hear them. From ron at awun.net Fri Jun 26 11:16:55 2009 From: ron at awun.net (Ron Garret) Date: Fri, 26 Jun 2009 11:16:55 -0700 Subject: [Openmcl-devel] Cocoa-based IDE sources In-Reply-To: References: Message-ID: <763C2C8D-F3BB-450F-958B-B3140BA0E1B5@awun.net> I vote for the second option. On Jun 26, 2009, at 11:07 AM, R. Matthew Emerson wrote: > Thanks to funding from users, we've been able to do some significant > work on the Cocoa-based IDE. > > As you probably know, we use the Subversion revision control system to > manage the CCL sources. Ongoing development takes place in the > trunk. This generally works fine. > > In the case of the Cocoa-based IDE, however, this has caused some > minor trouble. Users who are interested in improvements the IDE have > been obliged to track and run the trunk, even though it's probably the > case that such users would normally like to run a release. > > Therefore, it seems like it might be a good idea to separate the > Cocoa- > based IDE sources in some way. > > Here are some approaches we could take: > > * Make the svn external for the cocoa-ide/ directory in the release > branches point to the cocoa-ide/ sources in the trunk. (We do a > similar thing already for the documentation.) The idea would be that > the IDE is still under rapid enough development that it doesn't make > sense to periodically say "this is a stable release point". > > * Move the Cocoa-based IDE sources into a separate repository > entirely. The IDE would essentially become an application that could > be installed, much like, e.g. Hunchentoot or McCLIM. We could still > use an svn external to point to the IDE sources, but maybe we would > only do this for the Mac OS X targets. > > If anyone has suggestions on how to better manage this, I'd be > interested to hear them. > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel From j-anthony at comcast.net Fri Jun 26 16:51:51 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Fri, 26 Jun 2009 19:51:51 -0400 Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: References: <1245963215.2420.607.camel@sirius> Message-ID: <1246060311.2420.696.camel@sirius> Let me see if I'm getting the basic claims here. First, CCL's generational GC is not a copying type collector but a mark/compact collector (that alone is somewhat interesting as it must be one of a very few that take this route). So, it doesn't have semi-spaces (hemispheres) in either new (creation/young) space or in old (aging) space. It really only has one old/aging space (the so called region "on the left"). It uses 3 generations - all in new/creation space (the so called region "on the right"). This space is of size LISP-HEAP-GC-THRESHOLD. It is split into three regions - one for each generation. Youngest (generation 0) is probably "right most" with gen 1 adjacent to the left and gen 2 adjacent to gen 1 on the left. I don't think the sizes of these regions is user accessible, but the "threshold limits" (for when to trigger a minor collection) for them are - they are the egc-configuration values. While these probably affect the size of the regions in some way as well (under the overall constraint of LISP-HEAP-GC-THRESHOLD), there is no way to configure the sizes of these regions directly - only the overall size they are carved from: LISP-HEAP-GC-THRESHOLD. Since you don't use a copying collector these spaces are not split into semi-spaces. Also, for the same basic reason, it doesn't sound like you use the technique of using older generations as "Tospace" areas for a given scavenge. There is some promotion policy (not mentioned, but maybe based on percent used of the regions for each generation and/or the number of minor collections an item survives), and minor collections (those involving only new space - what you seem to call EGC collections) are performed by mark/compaction in each region. When promotion occurs, for Gen I, the items to be promoted (a subset of the live ones) are moved to Gen I+1. However, a somewhat interesting wrinkle on this is that the promotion is done by simply advancing the "top" pointer of Gen I+1's region - Gen I+1 sort of eats part of Gen I. Since the scavenge technique uses order preserving compaction, the piece of Gen I that Gen I+1 eats will be (most likely anyway) the oldest (via some measure - probably collection cycles). However that probably means there will be a gap in Gen I+1 between it's last set of non promoted collected survivors and the newly eaten Gen I items. That gap will be removed on the next collection (via compaction) of Gen I+1. Of course any collection for an older generation will collect younger ones as well (do to the usual idea of only wanting to track - via write barriers - old-young pointer changes). When new space fills up completely, a full/global/major collection is triggered and promotable items in the 3 new space generations are "moved" to old space (again, probably by simply advancing the "top" pointer of old space). It also does a collection (mark/compaction) on the items in old space (which probably includes the new promoted things as that step likely happens first). Old space's "top" (right most) pointer is adjusted to just past last live thing in old space. If there is not enough space freed up in old space to account for all the newly promoted objects plus the ones remaining in new space so that LISP-HEAP-GC-THRESHOLD space is available for new space, some extra space is allocated to the "top" (right most) of new space to achieve this limit. The basic scheme does not treat "large" objects specially - I don't think that buys much either, especially nowadays. There is no way to invoke or trigger a minor collection (egc collection). ccl:gc invokes a full/major/global collection. That's not so good, IMHO, but I guess it is what it is. There is no way to tell the GC/allocator/mutator that a "new" item is really an old space item, i.e., just allocate it up front in old space. I don't think that is so good either - there are definitely cases where this is a major win. But given your basic scheme, I can see how this would be non trivial to achieve: There's only one old space. It's fully compacted (modulo all current knowledge of live items in it). There's simply no place to use to achieve direct old space allocation. The idea you mention - moving everything to the "right", allocating, moving everything "left" - is indeed "crazy". Is this more or less on track? /Jon On Thu, 2009-06-25 at 19:33 -0600, Gary Byers wrote: > CCL's GC basically manages a single contiguous region of memory; you > can think of that region as being divided into two subregions. The > subregion "on the left" contains allocated objects (things that survived > the last GC) and the subregion "on the right" contains free space. When > an image is first loaded and after a full GC, the size of the free space > is determined by LISP-HEAP-GC-THRESHOLD. > > Conceptually (it doesn't really work exactly like this), free space fills > up from left to right; when free space fills up completely, a full GC > is triggered. The GC identifies which objects are live, then does an > in-place, order-preserving compaction of live objects ("towards the left"), > creating contiguous free space on the right. If necessary, more pages > are obtained from the OS so that the free space is of a size determined > by LISP-HEAP-GC-THRESHOLD; in some cases, the heap can shrink and unneeded > pages can be returned to the OS. (There's a large - possibly very large - > chunk of reserved address space "to the right" of the free area.) > > The fact that garbage is returned to (contiguous) free space by > in-place, order-preserving compaction offers some useful properties. > If allocated object X is "to the left of" (has a lower address than) > object Y, then it is generally true that X is older than Y (X has > survived more GC cycles than Y has), though X and Y may be of the same > vintage/generation. If we wanted to, we could keep some extra > bookkeeping information and identify each subregion of allocated space > that had survived I full GCs for I = 1 .. N, and part of that bookkeeping > might involve adjusting some pointers if/when things moved around due to > compaction. > > We don't actually do that, but we do use a similar scheme to keep track > of things on the right end of allocated space (maintaining regions that > describe "newly allocated things", "things that've survived a few GCs", > "things that've survived quite a few GCs but might still become garbage > soon.") These regions are the EGC's "generations", and they're basically > just a pair of pointers to the start and end of a region in allocated > space and a threshold/limit value that affects EGC policy (how big the > youngest generation can get before the EGC is invoked, how big the older > ephemeral generations can get before the EGC looks at them as well as > looking at the youngest generation.) The EGC's essentially doing the > same work as the full GC does - identifying live objects and doing an > in-place order-preserving compaction on them - only it's doing that > work on (generally) small subregions of at the extreme right end of > allocated space. To the extent that it's true that a high percentage > of newly-allocated objects are short-lived, this work is productive. > (That's true of all ephemeral/generational GC schemes; the only things > that might be atypical of CCL's EGC is that promoting/tenuring objects > from one generation to the next is done by adjusting the bounds of > the generations, not by copying things to other memory areas.) > > There are a lot of things to like about this scheme; it makes > allocation quick (since free memory is contiguous) and it generally > takes time proportional to the number of live objects. The worst-case > scenarios - which would involve copying large objects around during > in-place compaction - tend not to happen all that often (or tend to > happen a few times before things stabilize.) In practice, long-lived > objects tend not to move around, though in theory they could. > > The scheme doesn't special-case "large" objects (they tend to behave > like the pig in the python: the pig eventually gets from one end of > the python to the other, but it's not always pleasant for pig or > python and may involve some premature tenuring.) There's no way to > allocate an object and declare it to be "old", though this could be > done (essentially by pushing everything to the right and allocating > the object at or near the extreme left.) I can imagine cases where > this would be worthwhile and desirable, but in most cases where I'd > have been concerned about this that concern has been unfounded. > > You can manually invoke a full GC via (CCL:GC). There's no way > to trigger the EGC manually. > > I don't remember if anything checks for it, but setting the size > of generation 0 to 0 will probably cause the EGC to be triggered > unproductively (if it doesn't cause worse behavior.) Setting the > size of generations 1 or 2 to 0 could be done but may not be > very useful; making the generations slightly larger than the defaults > could improve performance somewhat (if things are "short-lived, but > not THAT short-lived.") > > > > > > > On Thu, 25 Jun 2009, Jon S. Anthony wrote: > > > Hi, > > > > This will likely be a few exchanges... > > > > As part of my ongoing porting/open sourcing the graph store/semantic > > engine system I have developed I am now educating myself on various > > details of CCLs GC. This is to enable understanding the basic behavior > > for various possible tuning scenarios in different circumstances. I have > > a pretty good grip on various details of ACL's GC when originally > > looking into this sort of stuff, but (being implementation dependent - a > > good thing here...) CCL's is different. > > > > If you have a bunch of objects that will be allocated up front for some > > processing, and you know that these will basically be around for the > > life of the program (more or less), it can be useful to just allocate > > them from the start in old space. In ACL you can do this by setting the > > generation-spread to 0 and tenure-limit to nil. Basically this means > > new things have no generations to move through - just go directly to old > > space - and inhibit GC (tenure "unlimited" amount until next trigger). > > Of course, you also need to request enough old space up front. > > > > CCL's GC has three basic generations for new space allocations: young, > > medium, old. I don't think old here is true old space, but simply the > > oldest new space generation before things get tenured to old space. But > > I could be wrong, but assuming I'm not, > > > > (lisp-heap-gc-threshold new-threshold) should basically do the job of > > requesting enough space, assuming you can request a full GC. > > > > Is there a means of requesting a full GC? ccl::freeze does this, but > > with the (undoubtedly useful as times) side effect of pinning everything > > left alive as non relocatable. That's a very neat feature, but is > > primary reason for freeze - not the full GC it also does. > > > > > > Next, if you set the generation 0-2 sizes all to 0, would this indicate > > to the GC that all new things are just immediately placed in old space? > > (like setting generation-spread to 0 in ACL). I'm not sure about this > > one, especially as the documentation says that whatever is requested is > > rounded up to a multiple of 64KB (of course 0 is such a multiple, > > but...) > > > > Along with this - are there multiple old spaces, and if so do they > > behave analogous to the generations in new space (ACL does something > > like this - it may not even make sense for CCL's GC but I thought I'd > > ask...) > > > > Let's start with this and see what happens :-) > > > > Thanks in advance for any info! > > > > /Jon > > > > > > > > _______________________________________________ > > Openmcl-devel mailing list > > Openmcl-devel at clozure.com > > http://clozure.com/mailman/listinfo/openmcl-devel > > > > From slepstein at mindspring.com Fri Jun 26 21:30:21 2009 From: slepstein at mindspring.com (slepstein at mindspring.com) Date: Sat, 27 Jun 2009 00:30:21 -0400 (GMT-04:00) Subject: [Openmcl-devel] extracting values of variables Message-ID: <27768453.1246077021563.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> I'm still a Clozure newbie and what I need most is to debug in the breaks. Some of the interface is intuitive and great, but in MCL I could use (local #) to the Listener in a break to access and then manipulate values. The documentation suggests that I should be able to get values of arguments and of local variables, but it doesn't work consistently. I've attached a copy of the top of a backtrace window. Why can't it determine the values here please? 1 > (:local line 5) ;; Can't determine value of LINE in frame 5. 1 > (:arg problem 5) ;; Can't determine value of PROBLEM in frame 5. 1 > (:arg count 4) ;; Can't determine value of COUNT in frame 4. 1 > (:local 0 5) > Error: value # is not of the expected type FIXNUM. > While executing: CCL::MAP-ENTRY-VALUE, in process Listener(7). Thanks in advance for any help you can offer. And if you are still looking for wishes: ? it would be great to have frame numbers and local variable numbers and arg numbers in the backtrace list ? it would be great if the key command that accesses the backtrace window initially would continue to pull it to the front once you have buried it beneath other windows -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 1.png Type: image/png Size: 27577 bytes Desc: not available URL: From stassats at gmail.com Fri Jun 26 22:10:00 2009 From: stassats at gmail.com (Stas Boukarev) Date: Sat, 27 Jun 2009 09:10:00 +0400 Subject: [Openmcl-devel] extracting values of variables In-Reply-To: <27768453.1246077021563.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <27768453.1246077021563.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: <9f0fec110906262210w7a735683lec651f2761c3593c@mail.gmail.com> On Sat, Jun 27, 2009 at 8:30 AM, wrote: > I'm still a Clozure newbie and what I need most is to debug in the breaks. Some of the interface is intuitive and great, but in MCL I could use (local #) to the Listener in a break to access and then manipulate values. ?The documentation suggests that I should be able to get values of arguments and of local variables, but it doesn't work consistently. I've attached a copy of the top of a backtrace window. Here's what I get: ? (defun foo (a) (let ((a (+ 10 a))) (break) a)) FOO ? (foo 10) > Break: > While executing: FOO, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Return from BREAK. > Type :? for other options. 1 > (:ARG A 0) 10 1 > (:LOCAL A 0) 20 1 > (:V 0 0) 10 1 > (:V 1 0) 20 -- With best regards, Stas. From stoye at stoye.com Sat Jun 27 02:46:08 2009 From: stoye at stoye.com (R.Stoye) Date: Sat, 27 Jun 2009 11:46:08 +0200 Subject: [Openmcl-devel] upcoming release In-Reply-To: References: Message-ID: some time ago i created these two tickets: http://trac.clozure.com/openmcl/ticket/468 in short: CCL::FIND-APPLICABLE-METHODS wants to be called with classnames (symbols), but the new xref mechanisms are passing the classes: (ccl::xref-describe 'ccl:process-interrupt :verbose t) -> Errors on (FIND-CLASS # NIL NIL) My workaround is to redefine ccl::find-applicable-methods to map the args list and replace non-symbols. the second one is somewhat magic (means i don't understand what's going on there: http://trac.clozure.com/openmcl/ticket/469 in short: if you compile/load a file in which a defgeneric is the last form, the source-notes for that function/methods are missing. my workaround is to put some definition below that form. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at mcaleely.com Sat Jun 27 06:10:30 2009 From: john at mcaleely.com (John McAleely) Date: Sat, 27 Jun 2009 14:10:30 +0100 Subject: [Openmcl-devel] Cocoa-based IDE sources In-Reply-To: <763C2C8D-F3BB-450F-958B-B3140BA0E1B5@awun.net> References: <763C2C8D-F3BB-450F-958B-B3140BA0E1B5@awun.net> Message-ID: > On Jun 26, 2009, at 11:07 AM, R. Matthew Emerson wrote: >> Therefore, it seems like it might be a good idea to separate the >> Cocoa- >> based IDE sources in some way. This seems like a sound move. >> * Make the svn external for the cocoa-ide/ directory in the release >> branches point to the cocoa-ide/ sources in the trunk. (We do a >> similar thing already for the documentation.) The idea would be that >> the IDE is still under rapid enough development that it doesn't make >> sense to periodically say "this is a stable release point". >> >> * Move the Cocoa-based IDE sources into a separate repository >> entirely. The IDE would essentially become an application that could >> be installed, much like, e.g. Hunchentoot or McCLIM. We could still >> use an svn external to point to the IDE sources, but maybe we would >> only do this for the Mac OS X targets. The second option sounds like a good idea, and gets my support. There seems to be quite a body of interest on this list for various GUI experiments and ideas, plus the desire to see the IDE get better. If it is given a life of its own, it would seem more likely to flourish. I also like the idea of installing a version of CCL on my production servers that contains less code, should I not want the IDE there. I would be interested in how to make the install process drop-dead- simple for two user cases. Those who develop on the Mac, and will make use of the IDE, and a 'console-REPL-only' install which would be used on other platforms, and also (perhaps) in some server environments on OSX. J From ron at awun.net Sat Jun 27 12:32:22 2009 From: ron at awun.net (Ron Garret) Date: Sat, 27 Jun 2009 12:32:22 -0700 Subject: [Openmcl-devel] Whither easygui? Message-ID: <57D19B3A-71A4-43EC-8A1C-FDDEC44613BE@awun.net> What is the current state of easygui? Is it stable (at least at the API level)? Is it under active development? If so, by whom? Do they need help? Is anyone using it? If so, how is it working for you? The reason I'm asking is because I'm kind of transitioning away from noodling-around mode and into serious development mode. Right now I've got my own cocoa utilities that I wrote mostly as an exercise. But I don't want to use them for real work if there's a better alternative. rg From gb at clozure.com Sat Jun 27 13:25:12 2009 From: gb at clozure.com (Gary Byers) Date: Sat, 27 Jun 2009 14:25:12 -0600 (MDT) Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: <1246060311.2420.696.camel@sirius> References: <1245963215.2420.607.camel@sirius> <1246060311.2420.696.camel@sirius> Message-ID: On Fri, 26 Jun 2009, Jon S. Anthony wrote: > > Let me see if I'm getting the basic claims here. First, CCL's > generational GC is not a copying type collector but a mark/compact > collector (that alone is somewhat interesting as it must be one of a > very few that take this route). So, it doesn't have semi-spaces > (hemispheres) in either new (creation/young) space or in old (aging) > space. It really only has one old/aging space (the so called region "on > the left"). At some point in time, I seem to remember hearing that Microsoft's .NET GC uses a mark/compact scheme that's eerily similar to CCL's. (I may be misremembering that.) > > It uses 3 generations - all in new/creation space (the so called region > "on the right"). This space is of size LISP-HEAP-GC-THRESHOLD. It is > split into three regions - one for each generation. Youngest > (generation 0) is probably "right most" with gen 1 adjacent to the left > and gen 2 adjacent to gen 1 on the left. I don't think the sizes of > these regions is user accessible, but the "threshold limits" (for when > to trigger a minor collection) for them are - they are the > egc-configuration values. While these probably affect the size of the > regions in some way as well (under the overall constraint of > LISP-HEAP-GC-THRESHOLD), there is no way to configure the sizes of these > regions directly - only the overall size they are carved from: > LISP-HEAP-GC-THRESHOLD. > Since they aren't statically sized regions, there is indeed no way to configure their size; the threshold limits basically have to do with when the region gets GCed. > Since you don't use a copying collector these spaces are not split into > semi-spaces. Also, for the same basic reason, it doesn't sound like you > use the technique of using older generations as "Tospace" areas for a > given scavenge. Right; it's not a multispace, copying collector. > > There is some promotion policy (not mentioned, but maybe based on > percent used of the regions for each generation and/or the number of > minor collections an item survives), and minor collections (those > involving only new space - what you seem to call EGC collections) are > performed by mark/compaction in each region. When promotion occurs, for > Gen I, the items to be promoted (a subset of the live ones) are moved to > Gen I+1. However, a somewhat interesting wrinkle on this is that the > promotion is done by simply advancing the "top" pointer of Gen I+1's > region - Gen I+1 sort of eats part of Gen I. Since the scavenge > technique uses order preserving compaction, the piece of Gen I that Gen > I+1 eats will be (most likely anyway) the oldest (via some measure - > probably collection cycles). However that probably means there will be > a gap in Gen I+1 between it's last set of non promoted collected > survivors and the newly eaten Gen I items. That gap will be removed on > the next collection (via compaction) of Gen I+1. > There's never a gap. When the youngest generation fills up, then at the very least that generation is collected and compacted; the GC operates on the (generally small) region of memory between the youngest generation's start and end. > Of course any collection for an older generation will collect younger > ones as well (do to the usual idea of only wanting to track - via write > barriers - old-young pointer changes). And if, at the point when the youngest generation is full and a GC is triggered the next oldest generation's size exceeds its threshold, it's also collected (and likewise for the oldest ephemeral generation.) This means that the GC operates on (marks and compacts) objects in the contiguous region region between the start of the oldest ephemeral region and the end of the youngest ephemeral region. > > When new space fills up completely, a full/global/major collection is > triggered and promotable items in the 3 new space generations are > "moved" to old space (again, probably by simply advancing the "top" > pointer of old space). It also does a collection (mark/compaction) on > the items in old space (which probably includes the new promoted things > as that step likely happens first). Old space's "top" (right most) > pointer is adjusted to just past last live thing in old space. If there > is not enough space freed up in old space to account for all the newly > promoted objects plus the ones remaining in new space so that > LISP-HEAP-GC-THRESHOLD space is available for new space, some extra > space is allocated to the "top" (right most) of new space to achieve > this limit. Yes, basically. If it helps: the GC (whether "ephemeral" or "full") always operates on a region of allocated memory between the start of allocated space and its end. A full GC operates on all of allocated space; an ephemeral GC operates on a generally small where the start is nearer the end. In all cases (for simplicity's sake), the live objects in the region that the GC operates on are compacted towards the start of the region, generally freeing up memory near the end of allocated space/start of free space. The differences (really the only ones) between full and ephemeal GC have to do with the size (start) of the region being GCed and with the fact that the ephemeral GC has to consider pointers from old objects to new ones. The exception to the "everything's always fully compacted" rule has to do with CCL::FREEZE, which you mentioned earlier. CCL::FREEZE does a full GC and notes the end allocated space after GC; subsequent full GCs (including those invoked by FREEZE) will not compact below/to the left of that point (though a full GC will zero out the words occupied by "frozen" objects that become garbage. (So frozen objects are tenured in the sense that they're immune from relocation due to compaction, but they're not immortal and can die in office.) > > The basic scheme does not treat "large" objects specially - I don't > think that buys much either, especially nowadays. > > There is no way to invoke or trigger a minor collection (egc > collection). ccl:gc invokes a full/major/global collection. That's not > so good, IMHO, but I guess it is what it is. It's not hard to implement, but I've always found it hard to understand why someone would want to invoke a minor collection manually: there's a fairly good chance that one just happened and an equally good chance that one's about to, and it's not immediately clear that one can accurately predict the effects of an ephemeral collection. (For a full GC, you can more reliably predict that "doing one now makes it less likely that you'll do one in the middle of the big demo", for example; I can't fill in the blank in "I want to force an ephemeral GC now, so that ____.") > > There is no way to tell the GC/allocator/mutator that a "new" item is > really an old space item, i.e., just allocate it up front in old space. > I don't think that is so good either - there are definitely cases where > this is a major win. As I said, I used to be more concerned about this than I am now (or, more accurately, every time that I've convinced myself that it'd be a big win to do some sort of static allocation, I've been proven wrong.) I can't say that your intuition about this is wrong, but I can certainly say that mine often has been. To try to explain some of the basis for my skepticism: a live object is only moved (compacted) by CCL's GC if some older object(s) (to the left) become garbage. If we create a new object (a function, just because that's easy to do and functions' printed representations contain their addresses) and GC a few times, printing the function (and observing its address) after each GC, we can see the effects of compaction (and something else as well): ? (defun foo (x) x) FOO ? #'foo # ? (gc) NIL ? #'foo # ? (gc) NIL ? #'foo # ? (gc) NIL ? #'foo # ? (gc) NIL ? #'foo # ? (gc) NIL ? #'foo # The "something else" of course is that the object stopped moving after a few GC iterations. (I did this in a fresh image that generally contained some things that're reinitialized when the session starts; after that's happened, it might take fewer iterations for things to reach a point of relative stability.) #'FOO isn't nailed down/pinned in memory, so its address might change on some future GC if some older object(s) become garbage. Old objects tend to be ... long-lived, so in practice things tend to "settle" and not be affected by compaction for relatively long stretches of time. In a straightforward 2-space copying GC, a long-lived object's address would likely change on every GC until something decides that it'd be better to keep it in a static memory area, and it might indeed be a big win to just allocate it in that static area in the first place. In a compacting GC, long-lived things -tend- to spend large parts of their lifetimes at stable addresses (aren't moved by the compaction process), though it may take a few GC cycles to reach stability and the object is still (potentially) subject to compaction. There might still be scenarios where static allocation could win (by offering stronger guarantees that the object wouldn't move or by avoiding the "few" GC cycles that it takes to reach quiescence), but since the tradeoff is between static allocation and "dynamic allocation that's in fact nearly static" (as opposed to "dynamic allocation where space flips happen on every GC"), the degree of ... winnitude is certainly different. > But given your basic scheme, I can see how this > would be non trivial to achieve: There's only one old space. It's fully > compacted (modulo all current knowledge of live items in it). There's > simply no place to use to achieve direct old space allocation. The idea > you mention - moving everything to the "right", allocating, moving > everything "left" - is indeed "crazy". If this does prove to be necessary, the less crazy way of doing it would involve reserving some address space at the extreme left and doing static allocation there. In 64-bit CCL, there's some other stuff a bit less than 1GB away (to the left), so there isn't currently an infinite amount of room to grow in that direction, but this wouldn't involve moving anything else out of the way. > > Is this more or less on track? I think so. Bill St Clair once wrote a little graphic utility for MCL (the "GC thermometer", if anyone remembers) that displayed a representation of the heap in a wide/short window at the bottom of the screen; it updated itself every second or so and basically provided an animated view of GC activity. If something like that still existed, it'd likely make some of this stuff easier to understand (and certainly easier to visualize.) > > > /Jon > > > On Thu, 2009-06-25 at 19:33 -0600, Gary Byers wrote: >> CCL's GC basically manages a single contiguous region of memory; you >> can think of that region as being divided into two subregions. The >> subregion "on the left" contains allocated objects (things that survived >> the last GC) and the subregion "on the right" contains free space. When >> an image is first loaded and after a full GC, the size of the free space >> is determined by LISP-HEAP-GC-THRESHOLD. >> >> Conceptually (it doesn't really work exactly like this), free space fills >> up from left to right; when free space fills up completely, a full GC >> is triggered. The GC identifies which objects are live, then does an >> in-place, order-preserving compaction of live objects ("towards the left"), >> creating contiguous free space on the right. If necessary, more pages >> are obtained from the OS so that the free space is of a size determined >> by LISP-HEAP-GC-THRESHOLD; in some cases, the heap can shrink and unneeded >> pages can be returned to the OS. (There's a large - possibly very large - >> chunk of reserved address space "to the right" of the free area.) >> >> The fact that garbage is returned to (contiguous) free space by >> in-place, order-preserving compaction offers some useful properties. >> If allocated object X is "to the left of" (has a lower address than) >> object Y, then it is generally true that X is older than Y (X has >> survived more GC cycles than Y has), though X and Y may be of the same >> vintage/generation. If we wanted to, we could keep some extra >> bookkeeping information and identify each subregion of allocated space >> that had survived I full GCs for I = 1 .. N, and part of that bookkeeping >> might involve adjusting some pointers if/when things moved around due to >> compaction. >> >> We don't actually do that, but we do use a similar scheme to keep track >> of things on the right end of allocated space (maintaining regions that >> describe "newly allocated things", "things that've survived a few GCs", >> "things that've survived quite a few GCs but might still become garbage >> soon.") These regions are the EGC's "generations", and they're basically >> just a pair of pointers to the start and end of a region in allocated >> space and a threshold/limit value that affects EGC policy (how big the >> youngest generation can get before the EGC is invoked, how big the older >> ephemeral generations can get before the EGC looks at them as well as >> looking at the youngest generation.) The EGC's essentially doing the >> same work as the full GC does - identifying live objects and doing an >> in-place order-preserving compaction on them - only it's doing that >> work on (generally) small subregions of at the extreme right end of >> allocated space. To the extent that it's true that a high percentage >> of newly-allocated objects are short-lived, this work is productive. >> (That's true of all ephemeral/generational GC schemes; the only things >> that might be atypical of CCL's EGC is that promoting/tenuring objects >> from one generation to the next is done by adjusting the bounds of >> the generations, not by copying things to other memory areas.) >> >> There are a lot of things to like about this scheme; it makes >> allocation quick (since free memory is contiguous) and it generally >> takes time proportional to the number of live objects. The worst-case >> scenarios - which would involve copying large objects around during >> in-place compaction - tend not to happen all that often (or tend to >> happen a few times before things stabilize.) In practice, long-lived >> objects tend not to move around, though in theory they could. >> >> The scheme doesn't special-case "large" objects (they tend to behave >> like the pig in the python: the pig eventually gets from one end of >> the python to the other, but it's not always pleasant for pig or >> python and may involve some premature tenuring.) There's no way to >> allocate an object and declare it to be "old", though this could be >> done (essentially by pushing everything to the right and allocating >> the object at or near the extreme left.) I can imagine cases where >> this would be worthwhile and desirable, but in most cases where I'd >> have been concerned about this that concern has been unfounded. >> >> You can manually invoke a full GC via (CCL:GC). There's no way >> to trigger the EGC manually. >> >> I don't remember if anything checks for it, but setting the size >> of generation 0 to 0 will probably cause the EGC to be triggered >> unproductively (if it doesn't cause worse behavior.) Setting the >> size of generations 1 or 2 to 0 could be done but may not be >> very useful; making the generations slightly larger than the defaults >> could improve performance somewhat (if things are "short-lived, but >> not THAT short-lived.") >> >> >> >> >> >> >> On Thu, 25 Jun 2009, Jon S. Anthony wrote: >> >>> Hi, >>> >>> This will likely be a few exchanges... >>> >>> As part of my ongoing porting/open sourcing the graph store/semantic >>> engine system I have developed I am now educating myself on various >>> details of CCLs GC. This is to enable understanding the basic behavior >>> for various possible tuning scenarios in different circumstances. I have >>> a pretty good grip on various details of ACL's GC when originally >>> looking into this sort of stuff, but (being implementation dependent - a >>> good thing here...) CCL's is different. >>> >>> If you have a bunch of objects that will be allocated up front for some >>> processing, and you know that these will basically be around for the >>> life of the program (more or less), it can be useful to just allocate >>> them from the start in old space. In ACL you can do this by setting the >>> generation-spread to 0 and tenure-limit to nil. Basically this means >>> new things have no generations to move through - just go directly to old >>> space - and inhibit GC (tenure "unlimited" amount until next trigger). >>> Of course, you also need to request enough old space up front. >>> >>> CCL's GC has three basic generations for new space allocations: young, >>> medium, old. I don't think old here is true old space, but simply the >>> oldest new space generation before things get tenured to old space. But >>> I could be wrong, but assuming I'm not, >>> >>> (lisp-heap-gc-threshold new-threshold) should basically do the job of >>> requesting enough space, assuming you can request a full GC. >>> >>> Is there a means of requesting a full GC? ccl::freeze does this, but >>> with the (undoubtedly useful as times) side effect of pinning everything >>> left alive as non relocatable. That's a very neat feature, but is >>> primary reason for freeze - not the full GC it also does. >>> >>> >>> Next, if you set the generation 0-2 sizes all to 0, would this indicate >>> to the GC that all new things are just immediately placed in old space? >>> (like setting generation-spread to 0 in ACL). I'm not sure about this >>> one, especially as the documentation says that whatever is requested is >>> rounded up to a multiple of 64KB (of course 0 is such a multiple, >>> but...) >>> >>> Along with this - are there multiple old spaces, and if so do they >>> behave analogous to the generations in new space (ACL does something >>> like this - it may not even make sense for CCL's GC but I thought I'd >>> ask...) >>> >>> Let's start with this and see what happens :-) >>> >>> Thanks in advance for any info! >>> >>> /Jon >>> >>> >>> >>> _______________________________________________ >>> Openmcl-devel mailing list >>> Openmcl-devel at clozure.com >>> http://clozure.com/mailman/listinfo/openmcl-devel >>> >>> > > From slepstein at mindspring.com Sat Jun 27 14:49:36 2009 From: slepstein at mindspring.com (slepstein at mindspring.com) Date: Sat, 27 Jun 2009 17:49:36 -0400 (EDT) Subject: [Openmcl-devel] extracting values of variables Message-ID: <15693444.1246139376563.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> My problem is trying to manipulate values in the break. (Inspection is clear.) For example, how would I go about multiplying the values of the two slots during the break? And thank you for helping! ? (defclass bar () ((slot-1 :initarg :slot-1 :initform 1 :accessor slot-1) (slot-2 :initarg :slot-2 :initform 2 :accessor slot-2))) # ? (setf foo (make-instance 'bar)) # ? (describe foo) # Class: # Wrapper: # Instance slots SLOT-1: 1 SLOT-2: 2 ? (defun baz (x) (print (+ (slot-1 x) (slot-2 x))) (break)) BAZ ? (baz foo) 3 > Break: > While executing: BAZ, in process Listener(6). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Return from BREAK. > Type :? for other options. 1 > (:arg x 0) # 1 > (slot-1 (:arg x 0)) > Error: Unbound variable: X > While executing: CCL::CHEAP-EVAL-IN-ENVIRONMENT, in process Listener(6). > 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 > (:apply-in-frame 0 slot-1) > Error: Too few arguments in call to #: > 0 arguments provided, at least 1 required. > While executing: SLOT-1, in process Listener(6). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > (:apply-in-frame 0 slot-1 x) > Error: Fault during read of memory address #x10 > While executing: (X), in process Listener(6). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. -----Original Message----- >From: Stas Boukarev >Sent: Jun 27, 2009 1:10 AM >To: slepstein at mindspring.com >Cc: openmcl-devel at clozure.com >Subject: Re: [Openmcl-devel] extracting values of variables > >On Sat, Jun 27, 2009 at 8:30 AM, wrote: >> I'm still a Clozure newbie and what I need most is to debug in the breaks. Some of the interface is intuitive and great, but in MCL I could use (local #) to the Listener in a break to access and then manipulate values. ?The documentation suggests that I should be able to get values of arguments and of local variables, but it doesn't work consistently. I've attached a copy of the top of a backtrace window. > >Here's what I get: >? (defun foo (a) (let ((a (+ 10 a))) (break) a)) >FOO >? (foo 10) >> Break: >> While executing: FOO, in process listener(1). >> Type :GO to continue, :POP to abort, :R for a list of available restarts. >> If continued: Return from BREAK. >> Type :? for other options. >1 > (:ARG A 0) >10 >1 > (:LOCAL A 0) >20 >1 > (:V 0 0) >10 >1 > (:V 1 0) >20 > > >-- >With best regards, Stas. From gb at clozure.com Sat Jun 27 15:49:47 2009 From: gb at clozure.com (Gary Byers) Date: Sat, 27 Jun 2009 16:49:47 -0600 (MDT) Subject: [Openmcl-devel] extracting values of variables In-Reply-To: <15693444.1246139376563.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <15693444.1246139376563.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: On Sat, 27 Jun 2009, slepstein at mindspring.com wrote: > My problem is trying to manipulate values in the break. (Inspection is clear.) For example, how would I go about multiplying the values of the two slots during the break? And thank you for helping! > > ? (defclass bar () ((slot-1 :initarg :slot-1 :initform 1 :accessor slot-1) > (slot-2 :initarg :slot-2 :initform 2 :accessor slot-2))) > # > ? (setf foo (make-instance 'bar)) > # > ? (describe foo) > # > Class: # > Wrapper: # > Instance slots > SLOT-1: 1 > SLOT-2: 2 > ? (defun baz (x) (print (+ (slot-1 x) (slot-2 x))) (break)) > BAZ > ? (baz foo) > > 3 >> Break: >> While executing: BAZ, in process Listener(6). >> Type :GO to continue, :POP to abort, :R for a list of available restarts. >> If continued: Return from BREAK. >> Type :? for other options. > 1 > (:arg x 0) > # At this point, the REPL variable * is set to that instance of BAR, so 1> (slot-1 *) would access its SLOT-1 slot. From slepstein at mindspring.com Sat Jun 27 17:51:39 2009 From: slepstein at mindspring.com (slepstein at mindspring.com) Date: Sat, 27 Jun 2009 20:51:39 -0400 (EDT) Subject: [Openmcl-devel] extracting values of variables Message-ID: <30296016.1246150299167.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> So that means if I want to operate on several local variables during a break, I have to setf temporary names for each of them, and manipulate those names? I can if I must, and thank you for the explanation (** and *** work too). If you are looking for user-friendly improvements, I'd suggest numbering the frames and variables, and providing some simpler way to manipulate them during a break. In MCL one typed (local #) but could reference local values and arguments only in the same frame. I do understand that this is more powerful, but it makes for difficult debugging? -----Original Message----- >From: Gary Byers >Sent: Jun 27, 2009 6:49 PM >To: slepstein at mindspring.com >Cc: Stas Boukarev , openmcl-devel at clozure.com >Subject: Re: [Openmcl-devel] extracting values of variables > > > >On Sat, 27 Jun 2009, slepstein at mindspring.com wrote: > >> My problem is trying to manipulate values in the break. (Inspection is clear.) For example, how would I go about multiplying the values of the two slots during the break? And thank you for helping! >> >> ? (defclass bar () ((slot-1 :initarg :slot-1 :initform 1 :accessor slot-1) >> (slot-2 :initarg :slot-2 :initform 2 :accessor slot-2))) >> # >> ? (setf foo (make-instance 'bar)) >> # >> ? (describe foo) >> # >> Class: # >> Wrapper: # >> Instance slots >> SLOT-1: 1 >> SLOT-2: 2 >> ? (defun baz (x) (print (+ (slot-1 x) (slot-2 x))) (break)) >> BAZ >> ? (baz foo) >> >> 3 >>> Break: >>> While executing: BAZ, in process Listener(6). >>> Type :GO to continue, :POP to abort, :R for a list of available restarts. >>> If continued: Return from BREAK. >>> Type :? for other options. >> 1 > (:arg x 0) >> # > >At this point, the REPL variable * is set to that instance of BAR, so > >1> (slot-1 *) > >would access its SLOT-1 slot. > From arthur.cater at ucd.ie Sun Jun 28 10:20:30 2009 From: arthur.cater at ucd.ie (Arthur W Cater) Date: Sun, 28 Jun 2009 18:20:30 +0100 Subject: [Openmcl-devel] Whither easygui? In-Reply-To: <57D19B3A-71A4-43EC-8A1C-FDDEC44613BE@awun.net> References: <57D19B3A-71A4-43EC-8A1C-FDDEC44613BE@awun.net> Message-ID: I submitted extensive changes to easygui back in March, I think I'm not the original author?and I don't know who is. I have done almost no more development since then, but I suppose I ought to submit the little more there is ... There were several justified criticisms that (embarrassed squirm) I never properly replied to. - The API exports some cocoa-specific things it ought not to - The API should be platform agnostic, even if Cocoa is (for now) the only platform - Some (unspecified) features appeared to one critic to be crude responses to a specific need; ??I can guess what some of them are I am not happy with the need for keyword arguments to mouse-down and friends. There's a bug that bites me occasionally, to do with a SLOT-VECTOR not having enough slots when #/isFlipped asks: I keep meaning to throw some more time at understanding that one, it is intermittent?and damned annoying! I suspect it is a threading issue. I do use it. I would welcome assistance, or indeed coup! Extending what was there when I began was indeed a response to a specific need, I wanted to port my MCL-based work- in-progress Go-playing app?to CCL. I don't think of myself as a developer of GUI toolkits. I find the idea of a platform-independent toolkit, such as Alexander Repenning is working on if I understand correctly, very appealing. Probably easygui could be platform-independent too, but I for one am not going to work on making it so. I know virtually nothing about other platforms, and not enough about Cocoa. I'm happy to engage in discussions of how easygui might be improved, and of what it currently does, with anyone interested in using extending or improving it. Arthur ----- Original Message ----- From: Ron Garret Date: Saturday, June 27, 2009 8:36 pm Subject: [Openmcl-devel] Whither easygui? To: Openmcl-devel Devel > What is the current state of easygui?? Is it stable (at > least at the? > API level)? Is it under active development?? If so, by > whom?? Do they? > need help?? Is anyone using it?? If so, how is it > working for you? > > The reason I'm asking is because I'm kind of transitioning away > from? > noodling-around mode and into serious development mode.? > Right now? > I've got my own cocoa utilities that I wrote mostly as an > exercise.?? > But I don't want to use them for real work if there's a > better? > alternative. > > 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 j-anthony at comcast.net Sun Jun 28 11:07:01 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Sun, 28 Jun 2009 14:07:01 -0400 Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: References: <1245963215.2420.607.camel@sirius> <1246060311.2420.696.camel@sirius> Message-ID: <1246212421.2420.762.camel@sirius> On Sat, 2009-06-27 at 14:25 -0600, Gary Byers wrote: > > On Fri, 26 Jun 2009, Jon S. Anthony wrote: > > > > > Let me see if I'm getting the basic claims here. First, CCL's > > generational GC is not a copying type collector but a mark/compact > > collector (that alone is somewhat interesting as it must be one of a > > very few that take this route). So, it doesn't have semi-spaces > > (hemispheres) in either new (creation/young) space or in old (aging) > > space. It really only has one old/aging space (the so called region "on > > the left"). > > At some point in time, I seem to remember hearing that Microsoft's .NET > GC uses a mark/compact scheme that's eerily similar to CCL's. (I may > be misremembering that.) Don't know. I think Ungar built one of these at Xerox for a Smalltalk impl at some point. Or at least partly so. > > It uses 3 generations - all in new/creation space (the so called region > > "on the right"). This space is of size LISP-HEAP-GC-THRESHOLD. It is > > split into three regions - one for each generation. Youngest > > (generation 0) is probably "right most" with gen 1 adjacent to the left > > and gen 2 adjacent to gen 1 on the left. I don't think the sizes of > > these regions is user accessible, but the "threshold limits" (for when > > to trigger a minor collection) for them are - they are the > > egc-configuration values. While these probably affect the size of the > > regions in some way as well (under the overall constraint of > > LISP-HEAP-GC-THRESHOLD), there is no way to configure the sizes of these > > regions directly - only the overall size they are carved from: > > LISP-HEAP-GC-THRESHOLD. > > > > Since they aren't statically sized regions, there is indeed no way to > configure their size; the threshold limits basically have to do with > when the region gets GCed. Right. > > There is some promotion policy (not mentioned, but maybe based on > > percent used of the regions for each generation and/or the number of > > minor collections an item survives), and minor collections (those > > involving only new space - what you seem to call EGC collections) are Could you give a thumbnail sketch of what the promotion policy is? That could give interesting hints about behavior under various conditions. > ... Since the scavenge > > technique uses order preserving compaction, the piece of Gen I that Gen > > I+1 eats will be (most likely anyway) the oldest (via some measure - > > probably collection cycles). However that probably means there will be > > a gap in Gen I+1 between it's last set of non promoted collected > > survivors and the newly eaten Gen I items. That gap will be removed on > > the next collection (via compaction) of Gen I+1. > > > > There's never a gap. > > When the youngest generation fills up, then at the very least that generation > is collected and compacted; the GC operates on the (generally small) region > of memory between the youngest generation's start and end. Yes, but the "gap" bit was about when things from a younger generation are promoted to an older generation during a scavenge of just the younger generation (no older scavenge triggered - but maybe you are saying that can't happen?) My understanding was that promotion was achieved by simply increasing the top pointer of the older generation (Gen I+1) so that it now included part of what was once the younger generation (Gen I). The gap would then be the piece of space between the last currently believed live object of Gen I+1 and the oldest just promoted object from Gen I: ...|XXXXX ...|YYYYYYYY...| <--- Before scavenge triggers promotion I+1 I ^-- "Highest currently allocated address" ^----- "top of I+1, before promotion" ...|XXXXX ...YYYY|YYYY...| <---- After scavenge promotes some of I ^--- New top of I+1 effects promotion ^-- the "gap" Or, maybe such a promotion always triggers a mark compact of I+1?? Or maybe I have just misunderstood the description. > > Of course any collection for an older generation will collect younger > > ones as well (do to the usual idea of only wanting to track - via write > > barriers - old-young pointer changes). > > And if, at the point when the youngest generation is full and a GC is > triggered the next oldest generation's size exceeds its threshold, it's > also collected (and likewise for the oldest ephemeral generation.) This > means that the GC operates on (marks and compacts) objects in the contiguous > region region between the start of the oldest ephemeral region and the > end of the youngest ephemeral region. Yes, sure. > > When new space fills up completely, a full/global/major collection is > > triggered and promotable items in the 3 new space generations are > > "moved" to old space (again, probably by simply advancing the "top" > > pointer of old space). It also does a collection (mark/compaction) on > > the items in old space (which probably includes the new promoted things > > as that step likely happens first). Old space's "top" (right most) > > pointer is adjusted to just past last live thing in old space. If there > > is not enough space freed up in old space to account for all the newly > > promoted objects plus the ones remaining in new space so that > > LISP-HEAP-GC-THRESHOLD space is available for new space, some extra > > space is allocated to the "top" (right most) of new space to achieve > > this limit. > > Yes, basically. > > If it helps: the GC (whether "ephemeral" or "full") always operates > on a region of allocated memory between the start of allocated space > and its end. A full GC operates on all of allocated space; an ephemeral > GC operates on a generally small where the start is nearer the end. In > all cases (for simplicity's sake), the live objects in the region that > the GC operates on are compacted towards the start of the region, generally > freeing up memory near the end of allocated space/start of free space. The > differences (really the only ones) between full and ephemeal GC have to do > with the size (start) of the region being GCed and with the fact that the > ephemeral GC has to consider pointers from old objects to new ones. Yes, that's how I understood it was working at this level. > The exception to the "everything's always fully compacted" rule has to > do with CCL::FREEZE, which you mentioned earlier. CCL::FREEZE does a > full GC and notes the end allocated space after GC; subsequent full > GCs (including those invoked by FREEZE) will not compact below/to the > left of that point Makes sense. > (though a full GC will zero out the words occupied > by "frozen" objects that become garbage. (So frozen objects are > tenured in the sense that they're immune from relocation due to > compaction, but they're not immortal and can die in office.) Is that zeroed out space actually reuseable? Or do the dead continue to take up office space in "peter principle" analogy... > > The basic scheme does not treat "large" objects specially - I don't > > think that buys much either, especially nowadays. > > > > There is no way to invoke or trigger a minor collection (egc > > collection). ccl:gc invokes a full/major/global collection. That's not > > so good, IMHO, but I guess it is what it is. > > It's not hard to implement, but I've always found it hard to understand > why someone would want to invoke a minor collection manually: there's > a fairly good chance that one just happened and an equally good chance > that one's about to, and it's not immediately clear that one can accurately > predict the effects of an ephemeral collection. (For a full GC, you can > more reliably predict that "doing one now makes it less likely that you'll > do one in the middle of the big demo", for example; I can't fill in the > blank in "I want to force an ephemeral GC now, so that ____.") I think this (and see below about the other point) is more useful in a copying collector where you can also control the promotion policy. It also depends on your knowing a fair amount about what is happening in certain special cases. But as I'm thinking of it right now, those actually have more to do with preventing "premature" minor collections than triggering them. > > There is no way to tell the GC/allocator/mutator that a "new" item is > > really an old space item, i.e., just allocate it up front in old space. > > I don't think that is so good either - there are definitely cases where > > this is a major win. > > As I said, I used to be more concerned about this than I am now (or, more > accurately, every time that I've convinced myself that it'd be a big win > to do some sort of static allocation, I've been proven wrong.) I can't > say that your intuition about this is wrong, but I can certainly say that > mine often has been. This isn't so much about intuition as simple observations in the past - but that has been with copying collectors and mostly with one specific collector. > The "something else" of course is that the object stopped moving after > a few GC iterations. Sure, and of course that happens in copying collectors as well. But, > In a straightforward 2-space copying GC, a long-lived object's address > would likely change on every GC until something decides that it'd be > better to keep it in a static memory area, That's really no different from what is happening in the compaction collector. However, there is typically less work being done for such things in the compactor since they don't need to be copied except during promotion compactions. Scavenge compactions in a generation (region) will only move them if something older than they dies before promotion. Which in the sort of case being discussed would not likely be happening. In the copying collector, they will be copied on each scavenge. > and it might indeed be a > big win to just allocate it in that static area in the first place. > In a compacting GC, long-lived things -tend- to spend large parts of > their lifetimes at stable addresses (aren't moved by the compaction > process), though it may take a few GC cycles to reach stability Again, that's basically true of copying collectors as well. The real issue here is that if you know that a lot (hundreds of thousands to millions) of objects are going to be created that are not going to die during a given program run, then those "GC cycles" can add up during the "bulk load" process (a few milliseconds here a few milliseconds there - pretty soon you're talking real time). But again, this will be rather more pronounced for a copying collector as the cycles will typically always move the objects until they actually are tenured to an old/aging space. In a compacting collector (certainly the one described for CCL here) they will tend not to move except possibly during a promotion. That's a big difference. > and > the object is still (potentially) subject to compaction. That would be the equivalent of possibly being dumped during a global/major GC in a copying collector. However, notice that for this case, the copying collector comes out rather better: you don't need to do any work since it won't be copied to the Tospace, but the compactor will very likely need to move stuff into the vacated space. There is no free lunch ... > but since the > tradeoff is between static allocation and "dynamic allocation that's > in fact nearly static" (as opposed to "dynamic allocation where space > flips happen on every GC"), the degree of ... winnitude is certainly > different. Yes. > > Is this more or less on track? > > I think so. I think we are pretty near closure (!) here. This thing is sufficiently different that there really isn't a whole lot you can tune. However, let me ask about this scenario for the "loads of large numbers of known to be "undying" objects": Start with a major/global/full GC. Save the current value of lisp-gc-heap-threshold. Set the threshold limits of gen-1 and gen-2 (NOT gen 0) to something very small. Actually how about just 0. Set lisp-heap-gc-threshold "high" - basically enough to hold all the objects to be created. Create objects. There should be no minor GC during this as they should all fit in Gen 0. Do a full GC. Set lisp-gc-heap-threshold back to its saved (previous) value. I guess this part depends on promotion policy: Will all these things be moved to old space at this point? Or do you need to do a "few" GC's to trigger the promotion? Or will it all just go "KA-BOOM!" Or... > Bill St Clair once wrote a little graphic utility for MCL (the "GC > thermometer", if anyone remembers) that displayed a representation of > the heap in a wide/short window at the bottom of the screen; it > updated itself every second or so and basically provided an animated > view of GC activity. If something like that still existed, it'd likely > make some of this stuff easier to understand (and certainly easier to > visualize.) That would be pretty cool. Unfortunately it likely wouldn't do me any good as I'm on Linux... /Jon From j-anthony at comcast.net Sun Jun 28 13:31:26 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Sun, 28 Jun 2009 16:31:26 -0400 Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: <1246212421.2420.762.camel@sirius> References: <1245963215.2420.607.camel@sirius> <1246060311.2420.696.camel@sirius> <1246212421.2420.762.camel@sirius> Message-ID: <1246221086.2420.772.camel@sirius> On Sun, 2009-06-28 at 14:07 -0400, Jon S. Anthony wrote: > > Start with a major/global/full GC. Save the current value of > lisp-gc-heap-threshold. Set the threshold limits of gen-1 and gen-2 (NOT > gen 0) to something very small. Actually how about just 0. Set > lisp-heap-gc-threshold "high" - basically enough to hold all the objects > to be created. Create objects. There should be no minor GC during this > as they should all fit in Gen 0. Do a full GC. Set > lisp-gc-heap-threshold back to its saved (previous) value. I guess this > part depends on promotion policy: Will all these things be moved to old > space at this point? This isn't going to work, not the least reason for which is that it doesn't account for the generation thresholds. You'd have to set Gen 0's limit to something around the size set for heap threshold. But even then, after thinking about it, I think this may work rather poorly since it can't really account for real garbage that will accumulate. It's plausible that may be more (much more even) than the objects you want to tenure to old space. So, Gen 0 may end up being traced many times, and since it will be containing a lot of those new "undying" objects, the size it has to trace will grow and grow causing the whole thing to degrade in overall performance. It's possible that the promotion policy (which I don't know at this point) might save the situation by promoting sizable groups of these objects before things really degrade. Maybe. But even so, doesn't sound too good... /Jon From rme at clozure.com Sun Jun 28 13:20:39 2009 From: rme at clozure.com (R. Matthew Emerson) Date: Sun, 28 Jun 2009 16:20:39 -0400 Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: <1246212421.2420.762.camel@sirius> References: <1245963215.2420.607.camel@sirius> <1246060311.2420.696.camel@sirius> <1246212421.2420.762.camel@sirius> Message-ID: <78874274-F039-42FC-8484-EBC02E247773@clozure.com> On Jun 28, 2009, at 2:07 PM, Jon S. Anthony wrote: > I think we are pretty near closure (!) here. This thing is > sufficiently > different that there really isn't a whole lot you can tune. However, > let me ask about this scenario for the "loads of large numbers of > known > to be "undying" objects": > > Start with a major/global/full GC. Save the current value of > lisp-gc-heap-threshold. Set the threshold limits of gen-1 and gen-2 > (NOT > gen 0) to something very small. Actually how about just 0. Set > lisp-heap-gc-threshold "high" - basically enough to hold all the > objects > to be created. Create objects. There should be no minor GC during > this > as they should all fit in Gen 0. Do a full GC. Set > lisp-gc-heap-threshold back to its saved (previous) value. I guess > this > part depends on promotion policy: Will all these things be moved to > old > space at this point? Or do you need to do a "few" GC's to trigger the > promotion? Or will it all just go "KA-BOOM!" Or... You could consider disabling the EGC with (ccl:egc nil) while you're doing your initial "bulk load" of objects that you expect to be long- lived. From gb at clozure.com Mon Jun 29 05:49:58 2009 From: gb at clozure.com (Gary Byers) Date: Mon, 29 Jun 2009 06:49:58 -0600 (MDT) Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: <1246212421.2420.762.camel@sirius> References: <1245963215.2420.607.camel@sirius> <1246060311.2420.696.camel@sirius> <1246212421.2420.762.camel@sirius> Message-ID: On Sun, 28 Jun 2009, Jon S. Anthony wrote: > >>> There is some promotion policy (not mentioned, but maybe based on >>> percent used of the regions for each generation and/or the number of >>> minor collections an item survives), and minor collections (those >>> involving only new space - what you seem to call EGC collections) are > > Could you give a thumbnail sketch of what the promotion policy is? That > could give interesting hints about behavior under various conditions. > There isn't a promotion policy as such (or there's a ridiculously simple one): anything that survives a GC of generation N is immediately incorporated (promoted, tenured) into generation N+1. This can in some hopefully rare cases cause (extremely) premature tenuring: since generations less than N are collected whenever generation N is collected, in the worst case, this can mean that something that survives a single GC can get tenured directly into old space (where it can only be recovered by a full GC.) How often this happens (and how much it costs) is application-dependent; when compiling the lisp itself - something that can create both a lot of short-lived objects and a lot of stuff whose lifetime is sort of "intermediate" - the ratio of generation 0 to generation 2 collections is about 50:1 (doubling the size of generation 2 makes that ratio closer to 100:1, not surprisingly.) So, with the default parameters in that case, about 2% of all GCs are of generation 2 (and therefore of generations 1 and 0 as well); with the default EGC configuration, about 1/7 (2MB out of 14) of the memory in the region being GCed were newly allocated, and typically only a small percentage of newly-allocated objects survive even 1 GC. (If I'm doing the math right, then this particular worst-case-scenario where something is tenured to oldspace after it survives a single GC happens "a small percentage" (the generation 0 survival rate) of .28% (.0028) of the time. A more elaborate promotion/tenuring policy could avoid this particular worst-case behavior, but any such policy is heuristic (trying to predict the lifetime of an object based on its history) and I'm not convinced that a more elaborate tenuring policy necessarily offers a better heuristic. (I confess that I haven't thought about it or studied the issues in 10 years or more; 10 years ago, the results that people claimed or observed were in the noise.) > >> ... Since the scavenge >>> technique uses order preserving compaction, the piece of Gen I that Gen >>> I+1 eats will be (most likely anyway) the oldest (via some measure - >>> probably collection cycles). However that probably means there will be >>> a gap in Gen I+1 between it's last set of non promoted collected >>> survivors and the newly eaten Gen I items. That gap will be removed on >>> the next collection (via compaction) of Gen I+1. >>> >> >> There's never a gap. >> >> When the youngest generation fills up, then at the very least that generation >> is collected and compacted; the GC operates on the (generally small) region >> of memory between the youngest generation's start and end. > > Yes, but the "gap" bit was about when things from a younger generation > are promoted to an older generation during a scavenge of just the > younger generation (no older scavenge triggered - but maybe you are > saying that can't happen?) It is always the case - after any kind of GC - that all live memory is compacted into a contiguous region ("on the left") and therefore free memory is a single contiguous region on the right. > > My understanding was that promotion was achieved by simply increasing > the top pointer of the older generation (Gen I+1) so that it now > included part of what was once the younger generation (Gen I). The gap > would then be the piece of space between the last currently believed > live object of Gen I+1 and the oldest just promoted object from Gen I: > > ...|XXXXX ...|YYYYYYYY...| <--- Before scavenge triggers promotion > > I+1 I ^-- "Highest currently allocated address" > > ^----- "top of I+1, before promotion" > > > ...|XXXXX ...YYYY|YYYY...| <---- After scavenge promotes some of I > > ^--- New top of I+1 effects promotion > > ^-- the "gap" > > Or, maybe such a promotion always triggers a mark compact of I+1?? Or > maybe I have just misunderstood the description. The highest allocated address and all of the Ys that survive the GC will have moved to the left. > > >>> Of course any collection for an older generation will collect younger >>> ones as well (do to the usual idea of only wanting to track - via write >>> barriers - old-young pointer changes). >> >> And if, at the point when the youngest generation is full and a GC is >> triggered the next oldest generation's size exceeds its threshold, it's >> also collected (and likewise for the oldest ephemeral generation.) This >> means that the GC operates on (marks and compacts) objects in the contiguous >> region region between the start of the oldest ephemeral region and the >> end of the youngest ephemeral region. > > Yes, sure. > > >>> When new space fills up completely, a full/global/major collection is >>> triggered and promotable items in the 3 new space generations are >>> "moved" to old space (again, probably by simply advancing the "top" >>> pointer of old space). It also does a collection (mark/compaction) on >>> the items in old space (which probably includes the new promoted things >>> as that step likely happens first). Old space's "top" (right most) >>> pointer is adjusted to just past last live thing in old space. If there >>> is not enough space freed up in old space to account for all the newly >>> promoted objects plus the ones remaining in new space so that >>> LISP-HEAP-GC-THRESHOLD space is available for new space, some extra >>> space is allocated to the "top" (right most) of new space to achieve >>> this limit. >> >> Yes, basically. >> >> If it helps: the GC (whether "ephemeral" or "full") always operates >> on a region of allocated memory between the start of allocated space >> and its end. A full GC operates on all of allocated space; an ephemeral >> GC operates on a generally small where the start is nearer the end. In >> all cases (for simplicity's sake), the live objects in the region that >> the GC operates on are compacted towards the start of the region, generally >> freeing up memory near the end of allocated space/start of free space. The >> differences (really the only ones) between full and ephemeal GC have to do >> with the size (start) of the region being GCed and with the fact that the >> ephemeral GC has to consider pointers from old objects to new ones. > > Yes, that's how I understood it was working at this level. > > >> The exception to the "everything's always fully compacted" rule has to >> do with CCL::FREEZE, which you mentioned earlier. CCL::FREEZE does a >> full GC and notes the end allocated space after GC; subsequent full >> GCs (including those invoked by FREEZE) will not compact below/to the >> left of that point > > Makes sense. > > >> (though a full GC will zero out the words occupied >> by "frozen" objects that become garbage. (So frozen objects are >> tenured in the sense that they're immune from relocation due to >> compaction, but they're not immortal and can die in office.) > > Is that zeroed out space actually reuseable? Or do the dead continue to > take up office space in "peter principle" analogy... > The free chunks are of varying size. They can be linked into a list (turning the GC into something like a mark/sweep collector, at least as far as frozen space is concerned) and recycled as "static" cons cells. "Static" cons cells can be used as address-based hash table keys without incurring rehashing costs that would be present if those address-based keys moved due to GC activity. > >>> The basic scheme does not treat "large" objects specially - I don't >>> think that buys much either, especially nowadays. >>> >>> There is no way to invoke or trigger a minor collection (egc >>> collection). ccl:gc invokes a full/major/global collection. That's not >>> so good, IMHO, but I guess it is what it is. >> >> It's not hard to implement, but I've always found it hard to understand >> why someone would want to invoke a minor collection manually: there's >> a fairly good chance that one just happened and an equally good chance >> that one's about to, and it's not immediately clear that one can accurately >> predict the effects of an ephemeral collection. (For a full GC, you can >> more reliably predict that "doing one now makes it less likely that you'll >> do one in the middle of the big demo", for example; I can't fill in the >> blank in "I want to force an ephemeral GC now, so that ____.") > > I think this (and see below about the other point) is more useful in a > copying collector where you can also control the promotion policy. It > also depends on your knowing a fair amount about what is happening in > certain special cases. But as I'm thinking of it right now, those > actually have more to do with preventing "premature" minor collections > than triggering them. > > >>> There is no way to tell the GC/allocator/mutator that a "new" item is >>> really an old space item, i.e., just allocate it up front in old space. >>> I don't think that is so good either - there are definitely cases where >>> this is a major win. >> >> As I said, I used to be more concerned about this than I am now (or, more >> accurately, every time that I've convinced myself that it'd be a big win >> to do some sort of static allocation, I've been proven wrong.) I can't >> say that your intuition about this is wrong, but I can certainly say that >> mine often has been. > > This isn't so much about intuition as simple observations in the past - > but that has been with copying collectors and mostly with one specific > collector. > > >> The "something else" of course is that the object stopped moving after >> a few GC iterations. > > Sure, and of course that happens in copying collectors as well. But, > > >> In a straightforward 2-space copying GC, a long-lived object's address >> would likely change on every GC until something decides that it'd be >> better to keep it in a static memory area, > > That's really no different from what is happening in the compaction > collector. However, there is typically less work being done for such > things in the compactor since they don't need to be copied except during > promotion compactions. Scavenge compactions in a generation (region) > will only move them if something older than they dies before promotion. > Which in the sort of case being discussed would not likely be happening. > In the copying collector, they will be copied on each scavenge. > > >> and it might indeed be a >> big win to just allocate it in that static area in the first place. >> In a compacting GC, long-lived things -tend- to spend large parts of >> their lifetimes at stable addresses (aren't moved by the compaction >> process), though it may take a few GC cycles to reach stability > > Again, that's basically true of copying collectors as well. The real > issue here is that if you know that a lot (hundreds of thousands to > millions) of objects are going to be created that are not going to die > during a given program run, then those "GC cycles" can add up during the > "bulk load" process (a few milliseconds here a few milliseconds there - > pretty soon you're talking real time). But again, this will be rather > more pronounced for a copying collector as the cycles will typically > always move the objects until they actually are tenured to an old/aging > space. In a compacting collector (certainly the one described for CCL > here) they will tend not to move except possibly during a promotion. > That's a big difference. > > >> and >> the object is still (potentially) subject to compaction. > > That would be the equivalent of possibly being dumped during a > global/major GC in a copying collector. However, notice that for this > case, the copying collector comes out rather better: you don't need to > do any work since it won't be copied to the Tospace, but the compactor > will very likely need to move stuff into the vacated space. There is no > free lunch ... > > >> but since the >> tradeoff is between static allocation and "dynamic allocation that's >> in fact nearly static" (as opposed to "dynamic allocation where space >> flips happen on every GC"), the degree of ... winnitude is certainly >> different. > > Yes. > > >>> Is this more or less on track? >> >> I think so. > > I think we are pretty near closure (!) here. This thing is sufficiently > different that there really isn't a whole lot you can tune. However, > let me ask about this scenario for the "loads of large numbers of known > to be "undying" objects": > > Start with a major/global/full GC. Save the current value of > lisp-gc-heap-threshold. Set the threshold limits of gen-1 and gen-2 (NOT > gen 0) to something very small. Actually how about just 0. Set > lisp-heap-gc-threshold "high" - basically enough to hold all the objects > to be created. Create objects. There should be no minor GC during this > as they should all fit in Gen 0. Do a full GC. Set > lisp-gc-heap-threshold back to its saved (previous) value. I guess this > part depends on promotion policy: Will all these things be moved to old > space at this point? Or do you need to do a "few" GC's to trigger the > promotion? Or will it all just go "KA-BOOM!" Or... > You lost me there. If you do a full GC, then everything that's been allocated will be GCed and compacted and considered "old"; that's what a full GC does. Ephemeral (generational, lifetime-based) GCs try to exploit the heuristic that "most of the time, most newly-created objects are short-lived" and therefore concentrating GC effort on discovering which newly-created objects are live and which are garbage will be worthwhile. If that heuristic assumption is false (if a high percentage of newly-created objects are live after GC), that GC effort is wasted. A bulk-load (something that creates and initializes a lot of long-lived objects) does likely violate the "most new objects die young" assumption, and Matt's suggestion (turning off the EGC around the bulk load) may make that load/initialization run faster (the EGC won't be spinning its wheels discovering that most of these new objects are long-lived) and will get you to the same place (the newly-allocated objects will effectively wind up in old space, where they belong.) Obviously, if you can do some of this initialization before saving an image that's likely to be better than if you have to do it on startup, but if you're concerned about it that's probably not practical in your case. You might want to just time your initialization code with EGC on and with it off; I wouldn't be shocked if the EGC spent a lot of time doing nothing useful, but it's probably worth trying to verify that: even if you're (primarily) creating a lot of long-lived objects, the process of doing so may or may not also create a lot of short-lived objects that the EGC likes. From j-anthony at comcast.net Mon Jun 29 10:16:21 2009 From: j-anthony at comcast.net (Jon S. Anthony) Date: Mon, 29 Jun 2009 13:16:21 -0400 Subject: [Openmcl-devel] GC aspects, tuning, behavior In-Reply-To: References: <1245963215.2420.607.camel@sirius> <1246060311.2420.696.camel@sirius> <1246212421.2420.762.camel@sirius> Message-ID: <1246295781.2420.791.camel@sirius> On Mon, 2009-06-29 at 06:49 -0600, Gary Byers wrote: > There isn't a promotion policy as such (or there's a ridiculously > simple one): anything that survives a GC of generation N is > immediately incorporated (promoted, tenured) into generation N+1. OK, yes I would call that a promotion policy, simple though it may be. Knowing this also clears up some stuff. ... > something is tenured to oldspace after it survives a single GC happens > "a small percentage" (the generation 0 survival rate) of .28% (.0028) ... Thanks for the analysis - pretty neat. > It is always the case - after any kind of GC - that all live memory is > compacted into a contiguous region ("on the left") and therefore free > memory is a single contiguous region on the right. So, the I+1 region is compacted as well. OK. > > Start with a major/global/full GC. Save the current value of > > lisp-gc-heap-threshold. Set the threshold limits of gen-1 and gen-2 (NOT > > gen 0) to something very small. Actually how about just 0. Set > > lisp-heap-gc-threshold "high" - basically enough to hold all the objects > > to be created. Create objects. There should be no minor GC during this > > as they should all fit in Gen 0. Do a full GC. Set > > lisp-gc-heap-threshold back to its saved (previous) value. I guess this > > part depends on promotion policy: Will all these things be moved to old > > space at this point? Or do you need to do a "few" GC's to trigger the > > promotion? Or will it all just go "KA-BOOM!" Or... > > > > You lost me there. If you do a full GC, then everything that's been allocated Well, as I mentioned in another message, what I say there turns out to makes no sense on a couple of levels. And even if you "fixed" those, it still would be kind of bogus. I'm pretty sure that for this kind of thing what Matthew suggested (and you echo) is the way to go: disable the ecg during the load. Setting the heap threashold to be around what you expect to need is likely a win as well, but messing with anything else really doesn't make much sense. > A bulk-load (something that creates and initializes a lot of > long-lived objects) does likely violate the "most new objects die > young" assumption, and Matt's suggestion (turning off the EGC around > the bulk load) may make that load/initialization run faster (the EGC > won't be spinning its wheels discovering that most of these new > objects are long-lived) and will get you to the same place (the > newly-allocated objects will effectively wind up in old space, where > they belong.) Exactly. I am now quite sure this is the most sensible route. > You might want to just time your initialization code with EGC on and > with it off; I wouldn't be shocked if the EGC spent a lot of time > doing nothing useful, but it's probably worth trying to verify that: > even if you're (primarily) creating a lot of long-lived objects, the > process of doing so may or may not also create a lot of short-lived > objects that the EGC likes. Also makes sense. Many thanks to you (and Matt) for taking the time with this. I appreciate it and I think I have a pretty good grasp of what is going on and the issues now. More than enough to move on. Thanks! /Jon From tfb at tfeb.org Mon Jun 29 03:14:40 2009 From: tfb at tfeb.org (Tim Bradshaw) Date: Mon, 29 Jun 2009 11:14:40 +0100 Subject: [Openmcl-devel] CCL rebuild for the naive Message-ID: <3AD24F03-8F4D-4603-BC8C-DBB1619805A3@tfeb.org> This is probably an idiot question. I've been trying to write a script which will do a full CCL rebuild after I've done an "svn update". Rebuilding the command-line apps is fine, you just need to do ccl -n -e '(progn (ccl:rebuild-ccl :full t) (quit))' and similarly for ccl64. The IDE is a pain though. The obvious thing: ccl -n -e '(require :cocoa-application)' results in some confusion about the application trying to open a file called "(require :cocoa-application)". I tried this: echo '(require :cocoa-application)' | ccl -n -b which produces an application which is (I think) confused about where the listener output should go, as it opens the "AltConsole" thing immediately. Running CCL and typing "(require :cocoa-application)" works, but obviously not from a script (please, don't suggest using "expect"!). Is there anything I am missing? Thanks --tim From raffaelcavallaro at mac.com Mon Jun 29 13:03:47 2009 From: raffaelcavallaro at mac.com (Raffael Cavallaro) Date: Mon, 29 Jun 2009 16:03:47 -0400 Subject: [Openmcl-devel] CCL rebuild for the naive In-Reply-To: <3AD24F03-8F4D-4603-BC8C-DBB1619805A3@tfeb.org> References: <3AD24F03-8F4D-4603-BC8C-DBB1619805A3@tfeb.org> Message-ID: <2427219A-D500-4125-9FDE-A9702CE27A64@mac.com> On Jun 29, 2009, at 6:14 AM, Tim Bradshaw wrote: > Is there anything I am missing? As I mentioned in an earlier reply on this subject, I had similar problems and found that the following made them go away: ./dx86cl64 -e "#-easygui (require 'cocoa-application) #+easygui nil" I.e., for some reason conditionalizing execution on the presence of the gui package works where the unconditional execution doesn't. Don't know why though. Here's the full script: --- begin rebuild-ccl --- #! /bin/sh cd ~/ccl svn update ./dx86cl64 -e "(ccl:rebuild-ccl :full t :force t)" -e "(quit)" ./dx86cl64 -e "#-easygui (require 'cocoa-application) #+easygui nil" ./dx86cl -e "(ccl:rebuild-ccl :full t :force t)" -e "(quit)" ./dx86cl -e "#-easygui (require 'cocoa-application) #+easygui nil" --- end rebuild ccl --- regards, Ralph Raffael Cavallaro raffaelcavallaro at me.com From ron at awun.net Mon Jun 29 13:18:37 2009 From: ron at awun.net (Ron Garret) Date: Mon, 29 Jun 2009 13:18:37 -0700 Subject: [Openmcl-devel] Test - please ignore Message-ID: Sorry about the spam, but my messages to this list are suddenly being bounced and I'm trying to figure out why. From gb at clozure.com Tue Jun 30 01:22:35 2009 From: gb at clozure.com (Gary Byers) Date: Tue, 30 Jun 2009 02:22:35 -0600 (MDT) Subject: [Openmcl-devel] CCL rebuild for the naive In-Reply-To: <3AD24F03-8F4D-4603-BC8C-DBB1619805A3@tfeb.org> References: <3AD24F03-8F4D-4603-BC8C-DBB1619805A3@tfeb.org> Message-ID: See . On Mon, 29 Jun 2009, Tim Bradshaw wrote: > This is probably an idiot question. > > I've been trying to write a script which will do a full CCL rebuild > after I've done an "svn update". > > Rebuilding the command-line apps is fine, you just need to do > > ccl -n -e '(progn (ccl:rebuild-ccl :full t) (quit))' > > and similarly for ccl64. > > The IDE is a pain though. The obvious thing: > > ccl -n -e '(require :cocoa-application)' > > results in some confusion about the application trying to open a file > called "(require :cocoa-application)". I tried this: > > echo '(require :cocoa-application)' | ccl -n -b > > which produces an application which is (I think) confused about where > the listener output should go, as it opens the "AltConsole" thing > immediately. > > Running CCL and typing "(require :cocoa-application)" works, but > obviously not from a script (please, don't suggest using "expect"!). > > Is there anything I am missing? > > Thanks > > --tim > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel at clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel > >