headers
dnm0 | 11 Feb 2008 16:54
Picon

OpenBSD fresh install

Hi all,

I'm trying to install SBCL on my OpenBSD box:
OpenBSD 4.1 GENERIC.MP#1152 amd64

I downloaded the 0.8.1 binary from the sbcl.org site and installed it in
the usual place (/usr/local/) using install.sh.

$ sbcl
/usr/local/bin/sbcl[1]: syntax error: `(' unexpected

Any thoughts?  I didn't see anything similar in the archives.

TIA,
dnm

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |
headers
Mari Masuda | 11 Feb 2008 18:15
Picon
Favicon

cannot launch sbcl

Hi,

I am new to SBCL.  I am using a Mac Book Pro running OS X 10.4.11.  I  
just downloaded sbcl-1.0.12-x86-darwin and did the following in  
Terminal:

$ cd Desktop/sbcl-1.0.12-x86-darwin/
$ sudo sh install.sh
Password:
 > here it spit out a bunch of installation information <
$ sudo pico /etc/profile
 > here I added /usr/local/bin to my PATH <
 > here I quit and restarted Terminal <
$ sbcl
dyld: lazy symbol binding failed: Symbol not found: _kill$UNIX2003
   Referenced from: /usr/local/bin/sbcl
   Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _kill$UNIX2003
   Referenced from: /usr/local/bin/sbcl
   Expected in: /usr/lib/libSystem.B.dylib

Trace/BPT trap
$

Can anyone tell me what I'm doing wrong?

Thanks,
Mari Masuda
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cyrus Harmon | 11 Feb 2008 18:58

Re: cannot launch sbcl

It looks like the SBCL binary you downloaded was built with 10.5 and  
requires 10.5. There are some linker flags for allowing 10.5-based  
builds to be run on pre-10.5 OSes, but it doesn't look like we're  
using them at the moment.

I'd suggest downloading an earlier binary and rebuilding from the  
current sources using that.

Cyrus

On Feb 11, 2008, at 9:15 AM, Mari Masuda wrote:

> Hi,
>
> I am new to SBCL.  I am using a Mac Book Pro running OS X 10.4.11.  I
> just downloaded sbcl-1.0.12-x86-darwin and did the following in
> Terminal:
>
> $ cd Desktop/sbcl-1.0.12-x86-darwin/
> $ sudo sh install.sh
> Password:
>> here it spit out a bunch of installation information <
> $ sudo pico /etc/profile
>> here I added /usr/local/bin to my PATH <
>> here I quit and restarted Terminal <
> $ sbcl
> dyld: lazy symbol binding failed: Symbol not found: _kill$UNIX2003
>   Referenced from: /usr/local/bin/sbcl
>   Expected in: /usr/lib/libSystem.B.dylib
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mari Masuda | 11 Feb 2008 20:03
Picon
Favicon

Re: cannot launch sbcl

Thank you for your help.  I downloaded the sbcl 1.0.10 binaries and  
built sbcl 1.0.14 from source.  Now it seems to be working fine.   
Thanks again.

Mari

On Feb 11, 2008, at 09:58, Cyrus Harmon wrote:

> It looks like the SBCL binary you downloaded was built with 10.5  
> and requires 10.5. There are some linker flags for allowing 10.5- 
> based builds to be run on pre-10.5 OSes, but it doesn't look like  
> we're using them at the moment.
>
> I'd suggest downloading an earlier binary and rebuilding from the  
> current sources using that.
>
> Cyrus
>
> On Feb 11, 2008, at 9:15 AM, Mari Masuda wrote:
>
>> Hi,
>>
>> I am new to SBCL.  I am using a Mac Book Pro running OS X 10.4.11.  I
>> just downloaded sbcl-1.0.12-x86-darwin and did the following in
>> Terminal:
>>
>> $ cd Desktop/sbcl-1.0.12-x86-darwin/
>> $ sudo sh install.sh
>> Password:
>>> here it spit out a bunch of installation information <
(Continue reading)

Permalink | Reply | 0 comments |
headers
obregonmateo | 14 Feb 2008 18:30
Picon

Bug with dotimes() and make-thread()

Hi everyone-

I'm new to this list, as I've recently decided to port my old Common Lisp code 
to SBCL, because it's open s/w and because it claims to be very portable.

However, I've found a BUG that shows up in the following code. Sometimes this 
snippet generates an erroneous result:

;; first run:

CL-USER> (let ((res nil))
	   (dotimes (n 3)
	     (push (sb-thread:make-thread #'(lambda () (cons n n))) res))
	   (mapcar #'sb-thread:join-thread (reverse res)))

((0 . 0) (2 . 2) (3 . 3))

;; second run:

CL-USER> (let ((res nil))
	   (dotimes (n 3)
	     (push (sb-thread:make-thread #'(lambda () (cons n n))) res))
	   (mapcar #'sb-thread:join-thread (reverse res)))

((0 . 0) (1 . 1) (2 . 2))

;; several reposts later:

CL-USER> (let ((res nil))
	   (dotimes (n 3)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kevin Reid | 14 Feb 2008 18:52
Picon
Gravatar

Re: Bug with dotimes() and make-thread()

On Feb 14, 2008, at 12:30, obregonmateo <at> gmail.com wrote:

> However, I've found a BUG that shows up in the following code.  
> Sometimes this snippet generates an erroneous result:
>
> ;; first run:
>
> CL-USER> (let ((res nil))
> 	   (dotimes (n 3)
> 	     (push (sb-thread:make-thread #'(lambda () (cons n n))) res))
> 	   (mapcar #'sb-thread:join-thread (reverse res)))
>
> ((0 . 0) (2 . 2) (3 . 3))
...
> ((0 . 0) (1 . 1) (2 . 2))
...
> ((0 . 0) (1 . 1) (3 . 3))

This is not a bug, but permitted behavior of DOTIMES. According to  
the CLHS:

"It is implementation-dependent whether dotimes establishes a new  
binding of var on each iteration or whether it establishes a binding  
for var once at the beginning and then assigns it on any subsequent  
iterations."

SBCL currently does the latter. Therefore, your three lambdas close  
over the same binding, which is the one being mutated by DOTIMES.

The variation you are seeing comes from the OS scheduler: whether the
(Continue reading)

Permalink | Reply | 2 comments |
headers
obregonmateo | 14 Feb 2008 19:31
Picon

Re: Bug with dotimes() and make-thread()

Learn something new every day. :)

Thanks for quote. The issue is definitely related to when the closure bindings 
take effect.

I tried your snippet in different lisps and got the following:

CMU Common Lisp CVS 19d 19d-release (19D), ...
* (let ((res nil))
   (dotimes (n 3)
     (push (lambda () (cons n n)) res))
   (mapcar #'funcall (reverse res)))
((0 . 0) (1 . 1) (2 . 2))

On clisp:
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (let ((res nil))
   (dotimes (n 3)
     (push (lambda () (cons n n)) res))
   (mapcar #'funcall (reverse res)))
((3 . 3) (3 . 3) (3 . 3))

On ACL:
;; International Allegro CL Enterprise Edition
CL-USER(1): (let ((res nil))
   (dotimes (n 3)
     (push (lambda () (cons n n)) res))
   (mapcar #'funcall (reverse res)))
((3 . 3) (3 . 3) (3 . 3))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikodemus Siivola | 14 Feb 2008 19:59
Gravatar

Re: Bug with dotimes() and make-thread()

On 2/14/08, obregonmateo <at> gmail.com <obregonmateo <at> gmail.com> wrote:

> I'm trying to write some optimised code that takes advantage of several CPUs
>  in an SMP linux system. I'll try and better the code so that I avoid creating
>  an extra environment.

Do not worry about it: just insert the LET you need to be portably
correct. Most compilers will generate identical code for

 (dotimes (i 3)
   (let ((i i))
      (let ((i i))
          ...)))

and

  (dotimes (i 3)
    (let ((i i))
       ...))

-- and even if they don't, the difference is going to be noise
compared to the cost of spawning a thread. (Noise compared to almost
anything, really.)

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
(Continue reading)

Permalink | Reply | 0 comments |
headers
Victor Kryukov | 19 Feb 2008 03:57
Picon
Gravatar

Hash table thread-safety

Hello,

I'm a bit confused about which hash tables operations are thread-safe
in SBCL - I know about locks, but I want to avoid them as much as
possible due to efficiency reasons. I'd appreciate if anybody would
tell me whether the following statements are true or false for the
latest x86-64 SBCL on the multi-core CPU. Even simple yes/no would be
fine; if you could provide some brief reasoning/implementation details
- that's even better. Feel free to refer me to any external sources of
information, of course.

1/ Multiple threads can safely read from the same hash table.

2/ Multiple threads can write to the same hash table. If two different
threads attempt to overwrite the same key simultaneously, the
resulting value (first or second one) is not specified, but it will be
one of the values provided, and no other problems would occur.

3/ Multiple threads can read and write to the same hash table. If one
thread attempts to read a value while another thread attempts to write
a new value, the value that reader gets (old or new) is not specified,
but the new value would be written, and no other problems would occur.

4/ Same as 2,3 above if one thread removes a key and another tries to
write/read it.

5/ Last, but not the least - I'd like to understand the behaviour of
maphash when other threads write to the hash-table. Is it true that
maphash is guaranteed about looping over all the _initial_ hash
elements, while behaviour for new added values is not specified?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nikodemus Siivola | 19 Feb 2008 08:27
Gravatar

Re: Hash table thread-safety

On 2/19/08, Victor Kryukov <victor.kryukov <at> gmail.com> wrote:

First off:

CL-USER> (documentation 'make-hash-table 'function)
"Create and return a new hash table. The keywords are as follows:
     :TEST -- Indicates what kind of test to use.
     :SIZE -- A hint as to how many elements will be put in this hash
       table.
     :REHASH-SIZE -- Indicates how to expand the table when it fills up.
       If an integer, add space for that many elements. If a floating
       point number (which must be greater than 1.0), multiply the size
       by that amount.
     :REHASH-THRESHOLD -- Indicates how dense the table can become before
       forcing a rehash. Can be any positive number <=1, with density
       approaching zero as the threshold approaches 0. Density 1 means an
       average of one entry per bucket.
     :WEAKNESS -- If NIL (the default) it is a normal non-weak hash table.
       If one of :KEY, :VALUE, :KEY-AND-VALUE, :KEY-OR-VALUE it is a weak
       hash table.
       Depending on the type of weakness the lack of references to the
       key and the value may allow for removal of the entry. If WEAKNESS
       is :KEY and the key would otherwise be garbage the entry is eligible
       for removal from the hash table. Similarly, if WEAKNESS is :VALUE
       the life of an entry depends on its value's references. If WEAKNESS
       is :KEY-AND-VALUE and either the key or the value would otherwise be
       garbage the entry can be removed. If WEAKNESS is :KEY-OR-VALUE and
       both the key and the value would otherwise be garbage the entry can
       be removed.
     :SYNCHRONIZED -- If NIL (the default), the hash-table may have
(Continue reading)

Permalink | Reply | 3 comments |

Gmane