Steel Bank Common Lisp

On 28 Apr 2004, David Steuber spake thusly:

> I still consider myself very much a Lisp beginner (neolisper?).  I
> kind of skipped through macros and clos in Graham's ACL book.  I
> figured I could come back to that stuff.  I am hoping that I have
> enough ground work to handle seperate concepts such as threads and
> also sockets and other things.

Another neolisper here !  I really had some hard work to do to get mp
in CMUCL working.  But I thought that was just me. ;-)

I would really really love to have a sb-thread tutorial for beginners.
In fact I am ready to work on it if guided (remember, neolisper
here).

-- 
quasi

Utopia Unlimited!

On Wed, 28 Apr 2004, David Steuber wrote:

> To quote a line from the SBCL manual:
>
> "Dynamic bindings to symbols are per-thread. Signal handlers are
> per-thread."

...

> (setf *foo* "baz")
>
> then /that/ thread and /only/ that thread has *foo* bound to "baz".

No. That's assignment, not binding.

What it means is that after you have done

 (let ((*foo* ...))
   ...)

then within that dynamic contour you can assign to *foo* without other
threads being affected.

If *foo* hasn't been bound (by LET) in the thread, then the assignments
affects all threads that haven't rebound their *foo*'s.

Cheers,

 -- Nikodemus

David Steuber <david@...> writes:

> To quote a line from the SBCL manual:
>
> "Dynamic bindings to symbols are per-thread. Signal handlers are
> per-thread."
>
> Although I have not seen how Lisp does signal handling, it is nice to
> know that the handler will be called in the same thread that the
> signal was raised.  That at least means that you can pretend the

Yup.

> thread is its own little world.  I'm not quite sure about the dynamic
> bindings.  My interpretation is that
>
> (defvar *foo* "bar")
>
> means that every thread has *foo* with the initial value of "bar".  If
> a thread does
>
> (setf *foo* "baz")
>
> then /that/ thread and /only/ that thread has *foo* bound to "baz".
> If this is the case, then that is great.  I have a sort of thread
> local storage thing going on for free.

As Nikodemus points out, by using SETF you're setting the (global
value of the) variable, not rebinding it.  To bind it, use LET.

Once you've bound it, any further setfs will affect only the local
binding, so, yes, you have thread-local storage.

> That then leads me to wonder how to create a shareable object such as
> a hash table (or an a-list) that has serialized access from all the
> threads that need to touch it in some way.

Using a variable declared globally with DEFVAR or DEFPARAMETER, and
a mutex to control access to it.

;; from memory; details probably wrong, but that's what apropos is for
(defvar *foo* 1)
(defvar *foo-lock* (make-mutex))

(with-mutex (*foo-lock*)
  (incf *foo*)) ; or whatever

> Then there are other threading issues like waiting on objects (Java
> style) and other scheduling issues.  For example, if thread creation
> has too much overhead for a given purpose, I would want to pre-spawn a
> number of threads and have them sleeping in a queue to be woken up as
> needed to handle a request and then go back into the queue when
> finished rather than exiting.

You most probably want to be using the condition variables for this.
Summary: create a waitqueue for the threads to wait on
(make-waitqueue) and a lock to say who has control of it.  Now have
queue readers acquire the lock then use condition-wait (which
atomically drops the lock and blocks) when the queue is empty and they
need to wait, and queue writers acquire the lock then use
condition-notify to wake one or more readers when they've added
something worth reading.

In outline, anyway.  Better threads docs is on my todo (aka my "yeah,
right, like that'll ever happen") list


-dan

-- 
"please make sure that the person is your friend before you confirm"

Daniel Barlow <dan@...> writes:

> As Nikodemus points out, by using SETF you're setting the (global
> value of the) variable, not rebinding it.  To bind it, use LET.
> 
> Once you've bound it, any further setfs will affect only the local
> binding, so, yes, you have thread-local storage.

I think I'm getting straightened out on that point.

> > That then leads me to wonder how to create a shareable object such as
> > a hash table (or an a-list) that has serialized access from all the
> > threads that need to touch it in some way.
> 
> Using a variable declared globally with DEFVAR or DEFPARAMETER, and
> a mutex to control access to it.
> 
> ;; from memory; details probably wrong, but that's what apropos is for
> (defvar *foo* 1)
> (defvar *foo-lock* (make-mutex))
> 
> (with-mutex (*foo-lock*)
>   (incf *foo*)) ; or whatever

Yay!  Examples!

Apropos has been helping me find out what exists.  But documentation
and describe have not been helpful in what to do with it :-(

> In outline, anyway.  Better threads docs is on my todo (aka my "yeah,
> right, like that'll ever happen") list

Heh.  No one likes to document ;-)

In the meantime, is SBCL following any de facto standards for
functions, macros, and objects for threading?  That is, is there a
place where I can look for some sort of tutorial on threaded
programming in Lisp in general that will work with SBCL?

I've resorted to looking through the source code now.  I'm already
confused by what I assume are basic things like (in-package
"SB!THREAD") instead of (in-package "SB-THREAD") and not being able
to find an associated (make-package "SB!THREAD").

I could start working on documentation as I figure things out, but it
is almost certain to be full of lies, misdirection, and apocrypha.
Then again, it might just be flat out wrong.

Do macros even take documentation strings?  The CLHS mentions
compiler-macro as a type, but I don't think that is the same thing.

* (documentation 'sb-thread:with-mutex 'function)

NIL
* (documentation 'sb-thread:with-mutex 'compiler-macro)

NIL

I know that sb-thread:with-mutex is a macro.  Documentation doesn't
like it when I pass in 'macro.

BTW, has anyone looked at this:

http://www.caddr.com/macho/archives/sbcl-devel/2004-4/3337.html

I haven't seen a response to it.  I was wondering if I need to provide
more information or if there is already a known problem with SMP
machines.  I don't know if this problem will get in my way or not, nor
do I know what sort of priority threads have.  Until I built SBCL on
it, I was running SBCL on my webserver only and that is a slow
machine.  The SMP box is on my LAN which makes working on it more
convenient.

Thanks.

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.

On Thu, 2004-04-29 at 07:09, Daniel Barlow wrote:
> In outline, anyway.  Better threads docs is on my todo (aka my "yeah,
> right, like that'll ever happen") list

Hmm... I'll whack up some docos. SB-THREADS could definitely use some.
And since I've kinda gotten the hang of them after much searching on the
'net for examples I can probably get at least some of it correct and
save others having to spend as much time as I did :)

It's not a big package so it shouldn't take long. I could use some
proof-reading though of course. I'll whack it up in text format for now.


-- 
Regards,

Robert Marlow

On Wed, 28 Apr 2004, David Steuber wrote:

> I've resorted to looking through the source code now.  I'm already
> confused by what I assume are basic things like (in-package
> "SB!THREAD") instead of (in-package "SB-THREAD") and not being able
> to find an associated (make-package "SB!THREAD").

The "!" vs. "-" is a bootstrapping mechnism to keep packages being built
separate from host packages -- towards the end of a build the "SB!FOO" is
renamed to "SB-FOO".

Similar explanations exist for various other mysterious beasts in the
sources: if something looks almost but not quite like the name of a
standard operator, then more likely then not it's part of the
bootstrapping machinery and unless you're wading in hip-deep hacking on
sbcl you can pretend it's the standard operator.

> Do macros even take documentation strings?  The CLHS mentions
> compiler-macro as a type, but I don't think that is the same thing.
>
> * (documentation 'sb-thread:with-mutex 'function)

From the CLHS pages:

 http://www.lispworks.com/reference/HyperSpec/Body/m_defmac.htm#defmacro

  "defmacro name lambda-list [[declaration* | documentation]] form*"

  So, yes. Macros take docstrings.


 http://www.lispworks.com/reference/HyperSpec/Body/f_docume.htm

  "The nature of the documentation string returned depends on the
   doc-type, as follows:"

   ...

  "function

    If x is a function name, returns the documentation string of the
    function, macro, or special operator whose name is x."

  So, the documentation of a macro is fetched by

   (documentation macro-name 'function)


> http://www.caddr.com/macho/archives/sbcl-devel/2004-4/3337.html

I'm under the impression that 2.4 kernels in general have threading
problems, and fixing them is a lower priority eg. threadsafetyfing
sbcl internals, and that for serious sb-thread use 2.6 kernels are
recommended, but dunno.

Cheers,

 -- Nikodemus

Nikodemus Siivola <tsiivola@...> writes:

>   So, the documentation of a macro is fetched by
> 
>    (documentation macro-name 'function)

Ok.  Since I tried that and got NIL, I can assume there was no
docstring.

> > http://www.caddr.com/macho/archives/sbcl-devel/2004-4/3337.html
> 
> I'm under the impression that 2.4 kernels in general have threading
> problems, and fixing them is a lower priority eg. threadsafetyfing
> sbcl internals, and that for serious sb-thread use 2.6 kernels are
> recommended, but dunno.

I really should get that machine up to 2.6.5.  When I first set it up
way back when, I didn't make the boot partition large enough and it
is almost full.  I might be able to clear out some stuff though.  I
would hate to repartition because I have no place to put the data
that is on that machine.

Backups?  Not here.

Anyway, I would agree with the policy of threadsafetyfing sbcl
internals prior to attempting backwards compatibility with older
kernels if that is indeed the case.

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.

On Thu, 2004-04-29 at 03:16, Nikodemus Siivola wrote:
> I'm under the impression that 2.4 kernels in general have threading
> problems, and fixing them is a lower priority eg. threadsafetyfing
> sbcl internals, and that for serious sb-thread use 2.6 kernels are
> recommended, but dunno.

There shouldn't be anything wrong with threads under Linux 2.4. There
are some scalability limits that are fixed by NPTL. NPTL is in various
Red Hat 2.4-based kernels (e.g. FC-1) and is standard in 2.6.

So, if you plan on having thousands of threads, you should probably use
a RH-based 2.4 kernel or 2.6. If you're just using a few threads,
however, any > 2.4 kernel should work fine for most situations.

-- 
Dave Roberts <ldave@...>

Daniel Barlow <dan@...> writes:

> If you know a reliable way to do scheduler-friendly locking absent
> futex support, please say, because nobody else is telling.

I don't.  I decided the path of least resistence was to see if I
could clean out space in my boot partition and install 2.6.5.  I was
able to do that.  Whether I compiled in all the options I need is
another issue that is currently unknown.  But the kernel boots and it
is SMP.  I tried the build of 0.8.10 again with sb-futex restored and
the thread test failed again.  Here are my results:

//running threads.impure.lisp test
; in: LAMBDA NIL
;     (ERROR "Missing shared library compilation options for this platform")
; ==>
;   "Missing shared library compilation options for this platform"
; 
; note: deleting unreachable code
; compilation unit finished
;   printed 1 note
#S(MUTEX :NAME "foo" :LOCK 0 :DATA NIL :VALUE NIL)
is an instance of class #<STRUCTURE-CLASS MUTEX>.
The following slots have :INSTANCE allocation:
 NAME     "foo"
 LOCK     0
 DATA     NIL
 VALUE    NIL
4249 got mutex
parent thread 4243
270488496 got mutex
parent thread 4243
woken, 270488496 got mutex
contention 4251 4252
interrupting child 4253
child pid 4253
interrupting child 4254
child pid 4254
unhandled condition (of type SIMPLE-CONTROL-ERROR):
  attempt to THROW to a tag that does not exist: SB-IMPL::%END-OF-THE-WORLD

0: 
("hairy arg processor for top level local call SB!DEBUG:BACKTRACE"
    128
    #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {505EA69}>)
1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    2
    #<SIMPLE-CONTROL-ERROR {9259A81}>
    #<unavailable argument>)[:EXTERNAL]
2: (INVOKE-DEBUGGER 1 #<SIMPLE-CONTROL-ERROR {9259A81}>)[:EXTERNAL]
3: (ERROR 5 SIMPLE-CONTROL-ERROR)[:EXTERNAL]
4: (SB-KERNEL::UNSEEN-THROW-TAG-ERROR-HANDLER
    4
    #<unavailable argument>
    #.(SB-SYS:INT-SAP #X414A5F08)
    #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X414A5BD8 :TYPE (*
                                                            (STRUCT
                                                             SB-VM::OS-CONTEXT-T-STRUCT))>
    (142))[:EXTERNAL]
5: (SB-KERNEL:INTERNAL-ERROR
    2
    #.(SB-SYS:INT-SAP #X414A5BD8)
    #<unavailable argument>)[:EXTERNAL]
6: ("foreign function call land: ra=#x80579F1")
7: ("foreign function call land: ra=#x805787D")
8: ("foreign function call land: ra=#x80523BB")
Argh! error within --disable-debugger error handling
9: ("foreign function call land: ra=#x80574EB")
interrupting child 4255
child pid 4255
interrupting child 4256
child pid 4256
done 4251
parent releasing lock
interrupting child 4257
child pid 4257
new thread 4257
................................unhandled condition (of type SIMPLE-ERROR): segmentation violation at #X0


unhandled condition in --disable-debugger mode, quitting
unhandled condition (of type SIMPLE-ERROR):
  Syscall interrupt_thread failed: No such process

0: ("hairy arg processor for top level local call SB!DEBUG:BACKTRACE"
    128
    #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {505EA69}>)
1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    2
    #<SIMPLE-ERROR {904E0C1}>
    #<unavailable argument>)[:EXTERNAL]
2: (INVOKE-DEBUGGER 1 #<SIMPLE-ERROR {904E0C1}>)[:EXTERNAL]
3: (ERROR 3 "Syscall ~A failed: ~A")[:EXTERNAL]
4: (INTERRUPT-THREAD
    2
    4257
    #<FUNCTION "#'(LAMBDA NIL (PRINC \".\") ...)" {9C1F4AD}>)[:EXTERNAL]
5: (#:EVAL-TMPFUN-2619 0)[:EXTERNAL]
6: (EVAL-IN-LEXENV
    2
    (LET ((C (TEST-INTERRUPT (LAMBDA () (LOOP (ALLOC-STUFF))))))
      (FORMAT T "new thread ~A~%" C)
      (DOTIMES (I 100)
        (SLEEP (RANDOM 1.0d0))
        (INTERRUPT-THREAD C
                          (LAMBDA ()
                            (PRINC ".")
                            (FORCE-OUTPUT)
                            (ASSERT
                             (ZEROP SB-KERNEL:*PSEUDO-ATOMIC-ATOMIC*)))))
      (TERMINATE-THREAD C))
    #S(SB-KERNEL:LEXENV
       :FUNS NIL
       :VARS NIL
       :BLOCKS NIL
       :TAGS NIL
       :TYPE-RESTRICTIONS NIL
       :LAMBDA NIL
       :CLEANUP NIL
       :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1)
                (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1)
                (COMPILATION-SPEED . 1))))[:EXTERNAL]
7: (SB-FASL::LOAD-AS-SOURCE
    3
    #<FILE-STREAM
      for "file \"/home/david/usr/src/sbcl/tests/threads.impure.lisp\""
      {902C449}>
    NIL
    NIL)[:EXTERNAL]
8: ("hairy arg processor for top level local call SB!FASL::INTERNAL-LOAD"
    #P"threads.impure.lisp"
    #P"/home/david/usr/src/sbcl/tests/threads.impure.lisp"
    :ERROR
    NIL
    NIL
    :SOURCE)
9: ("hairy arg processor for top level local call SB!FASL::INTERNAL-LOAD"
    #P"threads.impure.lisp"
    #P"/home/david/usr/src/sbcl/tests/threads.impure.lisp"
    :ERROR
    NIL
    NIL
    NIL)
10: (LOAD 1 "threads.impure.lisp")[:EXTERNAL]
11: (EVAL-IN-LEXENV
     2
     (LOAD "threads.impure.lisp")
     #S(SB-KERNEL:LEXENV
        :FUNS NIL
        :VARS NIL
        :BLOCKS NIL
        :TAGS NIL
        :TYPE-RESTRICTIONS NIL
        :LAMBDA NIL
        :CLEANUP NIL
        :POLICY ((SAFETY . 3) (COMPILATION-SPEED . 2) (DEBUG . 2) (SPEED . 1)
                 (SPACE . 1) (SB-EXT:INHIBIT-WARNINGS . 1))))[:EXTERNAL]
12: (SB-EXT:INTERACTIVE-EVAL 1 (LOAD "threads.impure.lisp"))[:EXTERNAL]
13: (SB-IMPL::REPL-FUN 1 T)[:EXTERNAL]
14: ("#'(LAMBDA NIL (LOOP # #))")
15: ("XEP for #'(LAMBDA NIL (LOOP # #))" 0)[:EXTERNAL]
16: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX 1 #<FUNCTION "CLOSURE" {9027815}>)[:EXTERNAL]
17: (SB-IMPL::TOPLEVEL-REPL 1 T)[:EXTERNAL]
18: (SB-IMPL::TOPLEVEL-INIT 0)[:EXTERNAL]
19: ("FLET SB!IMPL::RESTART-LISP")

unhandled condition in --disable-debugger mode, quitting
test threads.impure.lisp failed, expected 104 return code, got 1

david@...
$ uname -a
Linux vega 2.6.5-k7 #1 SMP Thu Apr 29 10:01:49 EDT 2004 i686 GNU/Linux
david@...
$ cat customize-target-features.lisp 
(lambda (list)
  (pushnew :sb-thread list)
  (pushnew :sb-futex list))
david@...
$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(TM) MP 1800+
stepping        : 2
cpu MHz         : 1533.697
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 3014.65

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 6
model name      : AMD Athlon(TM) MP 1800+
stepping        : 2
cpu MHz         : 1533.697
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 3063.80

I can provide more info if you tell me how.  This same test passes on
a single CPU system running the same kernel built with nearly the
same options (in fact, I snagged its .config so that I could just
make the relevent changes for a dual system with AMD instead of Intel
processor):

david@...:~
$ uname -a
Linux apostrophe 2.6.5-686 #1 Tue Apr 13 01:53:00 EDT 2004 i686 GNU/Linux
david@...:~
$ cat usr/src/sbcl/customize-target-features.lisp 
(lambda (list)
  (pushnew :sb-thread list)
  (pushnew :sb-futex list))
david@...:~
$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Celeron (Coppermine)
stepping        : 3
cpu MHz         : 568.271
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1110.01

Apostrophe is a slug compared to vega.

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.

David Steuber <david@...> writes:

> functions, macros, and objects for threading?  That is, is there a
> place where I can look for some sort of tutorial on threaded
> programming in Lisp in general that will work with SBCL?

You meay check the CL Cookbook's introduction to threading:

  http://cl-cookbook.sourceforge.net


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

On Apr 28, 2004, at 7:05 PM, Gary King wrote:

> I've just checked out sources for 8.10 and am going through the build 
> process using sbcl 0.8.9. It goes through a lot of "stuff" (technical 
> term) and them prints out:
>
> gnumake: `depend' is up to date.
> gcc3 -Dppc -g -Wall -O3 -no-cpp-precomp -I.  -c -o alloc.o alloc.c
> gcc3 -Dppc -g -Wall -O3 -no-cpp-precomp -I.  -c -o backtrace.o 
> backtrace.c
> backtrace.c: In function `previous_info':
> backtrace.c:159: warning: unsigned int format, long unsigned int arg 
> (arg 2)
> backtrace.c: In function `backtrace':
> backtrace.c:211: warning: unsigned int format, long unsigned int arg 
> (arg 2)
> backtrace.c:216: warning: unsigned int format, long unsigned int arg 
> (arg 2)
> backtrace.c:259: warning: unsigned int format, long unsigned int arg 
> (arg 2)
> gcc3 -Dppc -g -Wall -O3 -no-cpp-precomp -I.  -c -o breakpoint.o 
> breakpoint.c
> gcc3 -Dppc -g -Wall -O3 -no-cpp-precomp -I.  -c -o coreparse.o 
> coreparse.c
> coreparse.c: In function `load_core_file':
> coreparse.c:187: warning: implicit declaration of function `strlen'
> gcc3 -Dppc -g -Wall -O3 -no-cpp-precomp -I.  -c -o dynbind.o dynbind.c
> dynbind.c: In function `bind_variable':
> dynbind.c:43: `FREE_TLS_INDEX' undeclared (first use in this function)
> dynbind.c:43: (Each undeclared identifier is reported only once
> dynbind.c:43: for each function it appears in.)
> gnumake: *** [dynbind.o] Error 1
>
> I'm afraid I don't know what to do at this point. Any help is 
> appreciated. The only change I've made is to add a 
> customize-target-features.lisp consisting of:
>
> (lambda (list)
>   (flet ((enable (x) (pushnew x list))
>          (disable (x) (setf list (remove x list))))
>     #+nil (enable :sb-show)
>     #+nil (enable :sb-after-xc-core)
>     #+nil (disable :sb-doc)
>
>     (enable :sb-thread)
>     list))
>
> Any help would be appreciated.

:sb-thread doesn't work on OS X... don't know what gave you that idea. 
There have been issues building 0.8.10 on OS X; so far reports indicate 
that enabling :sb-ldb will resolve those issues.

Brian
--
Brian Mastenbrook
bmastenb@...
http://cs.indiana.edu/~bmastenb/

Hi Brian,

On Apr 28, 2004, at 8:09 PM, Brian Mastenbrook wrote:

> :sb-thread doesn't work on OS X... don't know what gave you that idea.

Just hope! I've done some looking and haven't found this information -- 
can you tell me where I ought to look? Also, is there any hope for 
threading support to start working on OS X anytime soon?

> There have been issues building 0.8.10 on OS X; so far reports 
> indicate that enabling :sb-ldb will resolve those issues.

thanks,
-- 
Gary Warren King, Lab Manager
EKSL East, University of Massachusetts * 413 577 0176

It is not enough to prepare our children for the world; we must also 
prepare the world for our children.
   -- Luis Rodriguez

* Nicolas Neuss <Nicolas.Neuss@...> [2004-04-29 15:27:39 +0200]:

> I have run across the following:
> 
> 1. I wanted to write a small REPL in this form
> 
> (loop do (format t "~&~%Choice: ")
> 	until (string-equal (read-line) "quit"))
> 
> Unfortunately, "Choice:" is printed here only after the input is read.
> Inserting (force-output) or (clear-output) after (format ...) did not
> help. Changing "Choice:" to "Choice:~%" did help, but how could I make it
> work without the newline?

Isn't it `finish-output' that you want there?

,----
| CL-USER[5]> (loop do (progn
|            (format t "~&Choice: ")
|            (finish-output))
|         until (string-equal (read-line) "quit"))
| 
| Choice: 1
| 
| Choice: 2
| 
| Choice: quit
| 
| nil
| CL-USER[6]> 
`----

-- 
Dave Pearson
http://www.davep.org/

Dave Pearson <davep@...> writes:

> * Nicolas Neuss <Nicolas.Neuss@...> [2004-04-29 15:27:39 +0200]:
> 
> > I have run across the following:
> > 
> > 1. I wanted to write a small REPL in this form
> > 
> > (loop do (format t "~&~%Choice: ")
> > 	until (string-equal (read-line) "quit"))
> > 
> > Unfortunately, "Choice:" is printed here only after the input is read.
> > Inserting (force-output) or (clear-output) after (format ...) did not
> > help. Changing "Choice:" to "Choice:~%" did help, but how could I make it
> > work without the newline?
> 
> Isn't it `finish-output' that you want there?

Yes, probably this is even better.  I have found out that also
(FORCE-OUTPUT) works.  I had stupidly called it as (FORCE-OUTPUT T) which
did not (and should not) work. Thanks for your answer.

Nicolas.

Nicolas Neuss <Nicolas.Neuss@...> writes:

> 2. I encountered an error on MAC OS X (sbcl-0.8.9) when trying to send
> commands to the graphic program Data Explorer.  The same program works on
> Linux without problems.  Can someone tell the problem from the backtrace
> below?  The stream was obtained with
> 
>   (sb-ext:process-input
>     (sb-ext:run-program *dx-pathname* :input :stream :output nil :wait nil))

Hmm.  Now I think that this is an error in the Mac version of Data
Explorer, because interfacing to Gnuplot works fine.

Sorry for the wasted bandwidth,

Nicolas.

On Sat, 24 Apr 2004, Larry Pells wrote:

> I have been trying to call lisp from C, but I have not been sucessful yet.

Even though I'm not sure if it works with current SBCL,
<http://random-state.net/tmp/sb-callhacks.lisp> may give you some ideas.

Cheers,

 -- Nikodemus

John Klein <jk271828@...> writes:

> --- David Steuber <david@...> wrote:
> 
> > I'm going to try your original again.
> > 
> > * (let ((f (make-array '(4096 4096) :element-type 'double-float)))
> >     (= (aref f 10 11) 99d0))
> > set_auto_gc_trigger: tried to set gc trigger too high! (0x807e37c)
> > fatal error encountered in SBCL pid 1299:
> 
> Yes, this is what I get.
> 
> On Linux with 0.8.5 this slightly more rigorous test (with much less physical
> memory) works:

I just tested on an old Linux box (384MB RAM) that is in theory far
less powerful than my PowerBook G4:

$ sbcl
This is SBCL 0.8.9.58, an implementation of ANSI Common Lisp.
...
* (time (let ((f (make-array '(4096 4096) :element-type 'double-float
           :initial-element 99d0)))
    (= (aref f 4000 4000) 99d0)))

Evaluation took:
                 8.791 seconds of real time
                 6.97394 seconds of user run time
                 1.427783 seconds of system run time
                 0 page faults and
                 134217736 bytes consed.
T
* (gc :full t)

NIL
*

I've also got sb-thread turned on on this one.

It would be nice to get the PPC/Darwin version of SBCL caught up.  I
think the PPC is a better architecture and should run much faster.
I'm still learning Lisp, so I can only contribute so much at the
moment.

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.