<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.lisp.openmcl.devel">
    <title>gmane.lisp.openmcl.devel</title>
    <link>http://blog.gmane.org/gmane.lisp.openmcl.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7914"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7907"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7906"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7903"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7902"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7900"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7899"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7897"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7896"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7875"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7873"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7869"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7865"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7863"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7860"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7852"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7851"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7850"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7843"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.openmcl.devel/7840"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7914">
    <title>Why canot CCL load libSDL* ?</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7914</link>
    <description>&lt;pre&gt;When i quickload a game from https://github.com/sykopomp/common-worm, CCL  
reports:


But:
lrwxr-xr-x  1 root  wheel      16&amp;gt;ls -l /usr/local/lib/libSDL*
lrwxr-xr-x  1 root  wheel      16 12  3 09:23  
/usr/local/lib/libSDL-1.2.so&amp;lt; at &amp;gt; -&amp;gt; libSDL-1.2.so.11
-rwxr-xr-x  1 root  wheel  452662 12  3 09:23  
/usr/local/lib/libSDL-1.2.so.11*
-rw-r--r--  1 root  wheel  559164 12  3 09:23 /usr/local/lib/libSDL.a
-rwxr-xr-x  1 root  wheel    1170 12  3 09:23 /usr/local/lib/libSDL.la*
lrwxr-xr-x  1 root  wheel      16 12  3 09:23 /usr/local/lib/libSDL.so&amp;lt; at &amp;gt; -&amp;gt;  
libSDL-1.2.so.11
-rw-r--r--  1 root  wheel     872 12  3 09:23 /usr/local/lib/libSDLmain.a

FreeBSD mybsd.zsoft.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3  
07:15:25 UTC 2012      
root&amp;lt; at &amp;gt;obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386



Sincerely!
&lt;/pre&gt;</description>
    <dc:creator>z_axis</dc:creator>
    <dc:date>2012-05-22T03:14:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7907">
    <title>CXML-RNG, Plexippus XPath, and Xuriella XSLT</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7907</link>
    <description>&lt;pre&gt;Greetings,

Has anyone got any of the above working on CCL? Specifically I'm trying to use Plexippus, but get:

        Unknown type specifier: CXML-STP-IMPL::DOCUMENT-TYPE

When invoking any Plexippus functions. Not even the simple examples in the documentation run. This is on the latest 1.8 CCL.

Any other suggestions for XPath with CCL?

Regards,
- SteveN

--
Illation Pty Ltd
8/350 Collins Street
Melbourne 3000

T:   +61 3 8399 9442
M: +61 4 0096 4240

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel&amp;lt; at &amp;gt;clozure.com
http://clozure.com/mailman/listinfo/openmcl-devel
&lt;/pre&gt;</description>
    <dc:creator>Steven Núñez</dc:creator>
    <dc:date>2012-05-20T10:54:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7906">
    <title>trunk may be unstable for a day or two</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7906</link>
    <description>&lt;pre&gt;I want to check in a bunch of changes (around a dozen files, all in
the lisp-kernel directory) to the CCL trunk.  Most of the changes involve
low-level GC-related things; things seem to work (but could stand some
stress-testing) on x8664 Linux but may or may not even compile cleanly
on other platforms, and the easiest way for me to get things working
everywhere is to check the code in and start building and testing it.

People who use the trunk may want to refrain from doing an "svn update"
for the next day or two; I'll send an "all clear" message to this list
when the dust seems to have settled.
&lt;/pre&gt;</description>
    <dc:creator>Gary Byers</dc:creator>
    <dc:date>2012-05-18T20:59:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7903">
    <title>Determining the Operating System on Windows</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7903</link>
    <description>&lt;pre&gt;Hey Everyone,

I was wondering if there was an easy way in CCL to determine which operating system the application was running on.  More specifically I am trying to determine which version of Windows is running.  

Is there any easy way to do this with CCL or should I proceed into the realm of win32 hacking to get this done?

Thanks a bunch,

--Mike
&lt;/pre&gt;</description>
    <dc:creator>Michael Minerva</dc:creator>
    <dc:date>2012-05-17T18:31:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7902">
    <title>DIRECTORY quibbles</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7902</link>
    <description>&lt;pre&gt;I was tinkering with DIRECTORY, attempting to debug something with ASDF.

I discovered that (DIRECTORY "*") was returning directories in the current
working directory, but not directories with dots in their names.

Reading the CCL docs http://ccl.clozure.com/manual/chapter4.4.html (also
the docs included in trunk), the interface specifies a keyword option
:DIRECTORIES which should default to NIL. It is apparently defaulting to T,
and checking the source files it is coded this way.  I think the
documentation specifies the correct, or at least most conforming, behavior,
that is, to list files. Maybe it is less surprising to get directories by
default, by analogy to an OS level directory listing command like ls or dir.

However, I find it odd that specifying a file wildcard matches on
directories. For instance (DIRECTORY (MAKE-PATHNAME :DIRECTORY NIL :NAME
:WILD :TYPE :WILD) :DIRECTORIES T :FILES NIL) will return all directories.
I would expect this to always return NIL. I'm asking for just directories
which have a any filename, any type, and no directory.

I would expect (DIRECTORY (MAKE-PATHNAME :DIRECTORY '(:RELATIVE :WILD))
:DIRECTORIES T :FILES NIL) to return all directories in the current working
directory, and it does. I'm asking for just directories, relative to the
current working directory, with a any directory name.

The converse works as expected: (DIRECTORY (MAKE-PATHNAME :DIRECTORY
'(:RELATIVE :WILD)) :DIRECTORIES NIL :FILES T) returns NIL.

I really don't see the need for :DIRECTORIES or :FILES at all if DIRECTORY
follows the pathname object for matching.

In fact, CLISP implements DIRECTORY in this very manner. It doesn't have
keyword options to specify wither files or directories are requested --
rather it uses the pathname spec. (DIRECTORY #P"*/") returns all
directories, (DIRECTORY "*.*") returns all files and no directories.

Finally, DIRECTORY has an undocumented keyword option :TEST which would be
super handy if it is in an appropriate state for public consumption.

Maybe I'm barking up the wrong tree?


Thanks,
Erik.
_______________________________________________
Openmcl-devel mailing list
Openmcl-devel&amp;lt; at &amp;gt;clozure.com
http://clozure.com/mailman/listinfo/openmcl-devel
&lt;/pre&gt;</description>
    <dc:creator>Erik Pearson</dc:creator>
    <dc:date>2012-05-16T17:26:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7900">
    <title>Got it (was: Capturing output from shell command)</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7900</link>
    <description>&lt;pre&gt;Forget it,

I managed to solve the problem with the following code:

---------------------------
(defun main (args)
   (if args
       (format t "~&amp;amp;Arguments were: ~a" args))
   (system "ls" "-n")
   (quit))

(defun system (cmd &amp;amp;optional args)
   (with-input-from-string
       (istream (with-output-to-string (ostream)
         (run-program cmd (list args) :output ostream)))
     (copy-stream istream)))

(defun copy-stream (in)
   (loop for line = (read-line in nil nil)
        while line
        do (format t "~%~a" line)))

(let ((args ccl:*unprocessed-command-line-arguments*))
   (main args))

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

-pekka-
&lt;/pre&gt;</description>
    <dc:creator>pekka</dc:creator>
    <dc:date>2012-05-14T21:54:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7899">
    <title>Capturing output from shell command</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7899</link>
    <description>&lt;pre&gt;Dear Sir,

I reused some code from manual in order to study
command line arguments and calling external programs:

------------------------
(defun main (args)
    (format t "~a" args)
    (process-arguments)
    (quit))

(defun process-arguments ()
   (with-output-to-string (stream)
     (run-program "ls" '("-n") :wait t :output t)))

(let ((args ccl:*unprocessed-command-line-arguments*))
   (main args))

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

It runs on OS X Lion terminal as follows:

$ ccl64 -l op.lisp -- one two three
total 16
-rw-r--r--  1 501  20  1280 May 13 19:11 clg.lisp
-rw-r--r--  1 501  20   270 May 13 23:49 op.lisp
(one two three)
$

All fine, except when I replace ":output t" with ":output stream".
How can I get the lines the shell directed to "stream" into a list?

------------------------
(defun main (args)
    (format t "~a" args)
    (process-arguments)
    (quit))

(defun process-arguments ()
   (with-output-to-string (stream)
     (run-program "ls" '("-n") :wait t :output stream)))
     ;; How to access data from the stream ????????????????

(let ((args ccl:*unprocessed-command-line-arguments*))
   (main args))

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


-pekka-
&lt;/pre&gt;</description>
    <dc:creator>pekka</dc:creator>
    <dc:date>2012-05-13T21:08:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7897">
    <title>Control-C or SIGINT</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7897</link>
    <description>&lt;pre&gt;Possibly a silly question:

I wrote a tiny linux console application (tool). This tool processes a file,
creates output and waits until the file further grows to present more output
(I use my program fwflt in a pipe: tail -f /var/log/xx | fwflt -c).

I'd like to simply break the program using control-c at the console prompt.
This works fine when my program waits for the file to grow - but - when I
hit control-c during an output/processing phase, everything gets messed up.
A break listener loop is created and terminal input to the repl seems to be
(non sensibly) fed from my programs terminal output.

Is there a way out of this problem? 

I used save-application with :error-handler :quit-quietly

Hints are appreciated :)

Best Regards Andreas
&lt;/pre&gt;</description>
    <dc:creator>Andreas Thiele</dc:creator>
    <dc:date>2012-05-15T11:45:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7896">
    <title>Bignum issue</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7896</link>
    <description>&lt;pre&gt;This eventually gives an assertion failure on my machine.

(defun compute ()
  (loop
     :for result := 1 :then (* result 10)
     :repeat 2000
     :finally (return result)))

(defun test ()
  (declare (optimize (debug 3) (safety 3) (speed 0)))
  (let ((expected (expt 10 2000))
        (result (compute)))
    (assert (eql expected result))))

(defun run ()
  (let ((count 0))
    (loop
       (test)
       (incf count)
       (when (zerop (mod count 1000))
         (princ ".")))))

Tested on 32-bit CCL 1.8 and from SVN; Linux Core-i7. Number of
iterations until the assert signals: 36000, 31000, 18000, 24000,
230000 (an outlier).

The value of `result' varies, though it always consists of a bunch of
nines, followed by random digits, followed by zeros. The value of
`expected' is correct.

The problem seems to be exacerbated by the presence of threads. If we
create many threads then the assertion fails immediately.

(defun test ()
  (declare (optimize (debug 3) (safety 3) (speed 0)))
  (let ((expected (expt 10 2000)))
    (ccl:process-run-function
     "test"
     (lambda ()
       (let ((result (compute)))
         (assert (eql expected result)))))))

(defun run ()
  (loop :repeat 25 :do (test)))
&lt;/pre&gt;</description>
    <dc:creator>James M. Lawrence</dc:creator>
    <dc:date>2012-05-15T00:09:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7875">
    <title>Semaphore troubles</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7875</link>
    <description>&lt;pre&gt;Is there anything incorrect about the code below? The function `test'
eventually fails at the first assertion, with `result' being `later'
rather than `sooner'. On my system (Linux Core-i7) the failure occurs
within 100 iterations.

The condition-wait function, which has been lifted directly from
bordeaux-threads, looks suspicious. What if ccl:signal-semaphore is
called during the time interval between the calls to ccl:release-lock
and ccl:wait-on-semaphore?

I don't see any CCL functions which take a semaphore and a lock. I
suppose I don't understand the CCL thread model? What is the proper
way to construct a blocking queue? Thanks in advance.

(I wrote a smaller test case without the queue, but I couldn't
reproduce the problem with it.)

ccl-1.8/lx86cl, md5 040409ba578edfa8b3dd62b009d57929

(defun condition-wait (cvar lock)
  (unwind-protect
       (progn
         (ccl:release-lock lock)
         (ccl:wait-on-semaphore cvar))
    (ccl:grab-lock lock)))

;;; raw-queue

(defun make-raw-queue ()
  (cons nil nil))

(defun push-raw-queue (value q)
  (let ((new (cons value nil)))
    (if (car q)
        (setf (cddr q) new)
        (setf (car  q) new))
    (setf (cdr q) new)))

(defun pop-raw-queue (q)
  (if (car q)
      (multiple-value-prog1 (values (caar q) t)
        (unless (setf (car q) (cdar q))
          ;; clear lingering ref
          (setf (cdr q) nil)))
      (values nil nil)))

;;; queue

(defstruct queue
  (impl (make-raw-queue))
  (lock (ccl:make-lock))
  (cvar (ccl:make-semaphore)))

(defun push-queue (object queue)
  (ccl:with-lock-grabbed ((queue-lock queue))
    (push-raw-queue object (queue-impl queue))
    (ccl:signal-semaphore (queue-cvar queue))))

(defun pop-queue (queue)
  (ccl:with-lock-grabbed ((queue-lock queue))
    (loop (multiple-value-bind (value presentp)
              (pop-raw-queue (queue-impl queue))
            (if presentp
                (return value)
                (condition-wait (queue-cvar queue)
                                (queue-lock queue)))))))

;;; run

(defun test ()
  (let ((tasks (make-queue)))
    (loop
       :repeat 2
       :do (ccl:process-run-function
            "test"
            (lambda ()
              (loop (funcall (or (pop-queue tasks)
                                 (return)))))))
    (let ((receiver (make-queue)))
      (push-queue (lambda ()
                    (push-queue (progn (sleep 0.2) 'later)
                                receiver))
                  tasks)
      (push-queue (lambda ()
                    (push-queue 'sooner receiver))
                  tasks)
      (let ((result (pop-queue receiver)))
        (assert (eq 'sooner result)))
      (let ((result (pop-queue receiver)))
        (assert (eq 'later result))))
    (push-queue nil tasks)
    (push-queue nil tasks))
  (format t "."))

(defun run ()
  (loop (test)))
&lt;/pre&gt;</description>
    <dc:creator>James M. Lawrence</dc:creator>
    <dc:date>2012-05-09T01:51:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7873">
    <title>Hemlock file save anomaly</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7873</link>
    <description>&lt;pre&gt;I'm unsure whether this is a bug, feature or how things are meant to be.

I have a file, I open it in the CCL editor. While it is still open 
(and unmodified), I also open the same file in another editor.  I 
change the file there and save it. Back in Hemlock I use [File] 
[Revert] to update the CCL buffer. I do some edits in CCL. Now I try 
to save the file and get:
---
The location of the document "xyz.lisp" cannot be determined.
You can specify where to save it.
      [Cancel] [Save As...]
---
I command-mouse the editor window top label, this opens the 
appropriate folder as normal. The file is still there, all seems safe 
and sound.

Perhaps I'm being disgusting by trying to edit the same file 
semi-concurrently from two different editors. The other editor does 
not complain, and for multi-platform developments (same source 
running to two different environments) this seems a useful technique 
at times.
&lt;/pre&gt;</description>
    <dc:creator>peter</dc:creator>
    <dc:date>2012-05-04T11:42:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7869">
    <title>Combining FASLs</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7869</link>
    <description>&lt;pre&gt;Dear CCL developers,

is there a relatively simple way in CCL to combine several FASLs into one?
On SBCL, you can simply concatenate them.
On ECL, you can link the underlying .o's together into a bigger .so

On CCL, loading the concatenation of several fasls seems to be
identical to loading just the first one.

Why this matters:
* asdf-bundle offers a way on supported implementations to deliver an
entire system (and possibly its dependencies, too) as a single fasl.
* we might want to use that with the Google build system.

—♯ƒ • François-René ÐVB Rideau •Reflection&amp;amp;Cybernethics• http://fare.tunes.org
Always design a thing by considering it in its next larger context — a chair
in a room, a room in a house, a house in an environment, an environment in a
city plan. — Eliel Saarinen
_______________________________________________
Openmcl-devel mailing list
Openmcl-devel&amp;lt; at &amp;gt;clozure.com
http://clozure.com/mailman/listinfo/openmcl-devel
&lt;/pre&gt;</description>
    <dc:creator>Faré</dc:creator>
    <dc:date>2012-05-03T04:22:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7865">
    <title>AgentCubes: a 3D Game Design tool based on CCL</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7865</link>
    <description>&lt;pre&gt;Dear All,

AgentCubes is a 3D programming tool written entirely in CCL (Mac and Win). It is aimed at end users with no background in programming or 3D modeling. Still beta but you can see some movies or even download it and try to make a game. For instance, if you have some kids and actually tried to teach them Lisp, you may want to give AgentCubes a try. The Visual Programming Language gets turned into Lisp and compiled every time you touch the program. You can even turn your game into HTML5/WebGL. 

http://www.agentsheets.com/agentcubes/

If you find some Lisp bleed please let me know. 


best,  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&amp;lt; at &amp;gt;clozure.com
http://clozure.com/mailman/listinfo/openmcl-devel
&lt;/pre&gt;</description>
    <dc:creator>Alexander Repenning</dc:creator>
    <dc:date>2012-05-02T19:20:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7863">
    <title>reentrant locks support</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7863</link>
    <description>&lt;pre&gt;Hi

I have been assuming that on CCL (at least on Linux x64)
ccl:make-lock and ccl:grab-lock allow recursive locking in the same thread.
( http://ccl.clozure.com/ccl-documentation.html#f_grab-lock  was not 
clear enough)
Could somebody please confirm.

Reason -
While I haven't found anything to say otherwise, there is a thread (no 
pun intended) going on in
bordeaux-threads-devel mailing list that says they'll remove support for 
recursive locks.
I do not want that to happen.

-Antony
&lt;/pre&gt;</description>
    <dc:creator>Antony</dc:creator>
    <dc:date>2012-05-02T16:10:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7860">
    <title>UTF8 redux</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7860</link>
    <description>&lt;pre&gt;Not to beat a dead horse, but here's an excellent writeup about the benefits of using UTF-8 as the default text encoding:

http://www.utf8everywhere.org/

It's worth reading, especially the "myths" section at the end.

rg
&lt;/pre&gt;</description>
    <dc:creator>Ron Garret</dc:creator>
    <dc:date>2012-04-29T17:34:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7852">
    <title>Clozure CL 1.8 now in Mac App Store</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7852</link>
    <description>&lt;pre&gt;Clozure CL 1.8 is now available in the Mac App Store.

If the instructions on http://ccl.clozure.com/download.html
scare you off, the Mac App Store version may be a good choice
for you.
&lt;/pre&gt;</description>
    <dc:creator>R. Matthew Emerson</dc:creator>
    <dc:date>2012-04-23T17:44:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7851">
    <title>Why doesn't this work?</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7851</link>
    <description>&lt;pre&gt;It seems like doing this:

(setf (hi::character-attribute :lisp-syntax #\[) :open-paren)
(setf (hi::character-attribute :lisp-syntax #\]) :close-paren)

should make the editor treat square brackets like parens (i.e. allow square-bracket-delimited lists to be syntax highlighted and selected like regular parens) but it doesn't work.  Anyone know why, or how to make this work?

Thanks,
rg
&lt;/pre&gt;</description>
    <dc:creator>Ron Garret</dc:creator>
    <dc:date>2012-04-23T07:06:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7850">
    <title>What is the new context argument in all thecompiler functions?</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7850</link>
    <description>&lt;pre&gt;I was surprised (and somewhat dismayed) to see the interface to a bunch of nx1 compiler functions has changed in a non-backwards-compatible way by adding a CONTEXT argument at the beginning of the argument list.  What was the reason for this?  What does CONTEXT do?

Thanks,
rg
&lt;/pre&gt;</description>
    <dc:creator>Ron Garret</dc:creator>
    <dc:date>2012-04-23T06:52:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7843">
    <title>where is shell output stored when launching anexternal program?</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7843</link>
    <description>&lt;pre&gt;I am launching external processes with clozure common lisp. For better feedback/debugging, I would like to display the bash error string when I try to execute a nonexistent binary.

For example:

? (setf *t* (run-program "programDoesNotExist" '() :output t :error :output :wait nil))
#&amp;lt;EXTERNAL-PROCESS (programDoesNotExist)[919] (RUNNING) #x302000E6471D&amp;gt;

? *t*
#&amp;lt;EXTERNAL-PROCESS (programDoesNotExist)[919] (EXITED : 71) #x302000E6471D&amp;gt;

? (inspect *t*)
[0]     #&amp;lt;EXTERNAL-PROCESS (programDoesNotExist)[919] (EXITED : 71) #x302000E6471D&amp;gt;
[1]     Type: EXTERNAL-PROCESS
[2]     Class: #&amp;lt;STRUCTURE-CLASS EXTERNAL-PROCESS&amp;gt;
[3]     PID: 919
[4]     %STATUS: :EXITED
[5]     %EXIT-CODE: 71
[6]     PTY: NIL
[7]     INPUT: NIL
[8]     OUTPUT: NIL
[9]     ERROR: NIL
[10]    STATUS-HOOK: NIL
[11]    PLIST: NIL
[12]    TOKEN: (0)
[13]    CORE: NIL
[14]    ARGS: ("programDoesNotExist")
[15]    SIGNAL: #&amp;lt;SEMAPHORE #x302000E6483D&amp;gt;
[16]    COMPLETED: #&amp;lt;SEMAPHORE #x302000E647BD&amp;gt;
[17]    WATCHED-FDS: NIL
[18]    WATCHED-STREAMS: NIL
[19]    EXTERNAL-FORMAT: #&amp;lt;EXTERNAL-FORMAT NIL/:UNIX #x30200049FE9D&amp;gt;
Inspect&amp;gt; 

Even with the inspector, I can't find the error information printed by the shell. I'm trying to recover this string in the lisp process:

$ programDoesNotExist
-bash: programDoesNotExist: command not found

Any help would be greatly appreciated.

Thanks,
-Clayton
&lt;/pre&gt;</description>
    <dc:creator>clayton stanley</dc:creator>
    <dc:date>2012-04-17T01:00:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7840">
    <title>Uparrow and downarrow behavior</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7840</link>
    <description>&lt;pre&gt;I have a vague recollection of someone complaining on this list not too long ago about the default behavior of the up and down arrow keys, but I can no longer find the original message.  In any case, this code will rebind these keys to make the listener act as if it were a readline application:

(in-package :hemlock)
(bind-key "Previous Interactive Input" #k"uparrow" :mode "Listener")
(bind-key "Next Interactive Input" #k"downarrow" :mode "Listener")

I find this handy as well:

(bind-key "Kill Interactive Input" #k"control-w" :mode "Listener")

rg
&lt;/pre&gt;</description>
    <dc:creator>Ron Garret</dc:creator>
    <dc:date>2012-04-15T19:24:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.openmcl.devel/7838">
    <title>how to ignore this warning? - shadows standard CLdefinition.</title>
    <link>http://comments.gmane.org/gmane.lisp.openmcl.devel/7838</link>
    <description>&lt;pre&gt;I update to  1.9-dev-r15327M-trunk  (DarwinX8664)!.

I sometime shadow standard cl function.

for example..

(defmethod plus ((p1 number) (p2 number))
  (+ p1 p2))

(defmethod plus ((p1 string) (p2 string))
  (concatenate 'string p1 p2))

(labels ((+ (&amp;amp;rest rest)
   (reduce #'plus rest)))
  (+ "clozure" " common" " lisp"))


;Compiler warnings :
;   In an anonymous lambda form: Local function or macro name + shadows
standard CL definition.
=&amp;gt; "clozure common lisp"



if I can ignore it, tell me what to do....    thank you.
_______________________________________________
Openmcl-devel mailing list
Openmcl-devel&amp;lt; at &amp;gt;clozure.com
http://clozure.com/mailman/listinfo/openmcl-devel
&lt;/pre&gt;</description>
    <dc:creator>박성민</dc:creator>
    <dc:date>2012-04-15T17:15:01</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.lisp.openmcl.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.openmcl.devel</link>
  </textinput>
</rdf:RDF>

