headers
Liam Healy | 1 Jul 2004 04:28
Picon

sbcl-mt: princ does not strings well

Package: sbcl-mt
Version: 0.8.28+really.0.8.10.48-1
Severity: normal

Strings get garbled up in princ:

 > sbcl-mt -noinit
This is SBCL 0.8.10.48, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (princ "one line" t)

"one line"
* (princ "line one
line two
line three" t)
one lineline one
line two

"line one
line two
line three"
* (quit)
line three> 

Looks like maybe the last (or only) line doesn't get flushed until the next
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christophe Rhodes | 1 Jul 2004 09:29
Picon
Picon
Favicon

Re: sbcl-mt: princ does not strings well

Liam Healy <lnp <at> healy.washington.dc.us> writes:

> Strings get garbled up in princ:
>
> Looks like maybe the last (or only) line doesn't get flushed until
> the next princ, or until you quit sbcl?

Right.  The reason you see garbling is that you're effectively
printing to two different streams here: T as a stream designator means
*terminal-io*, which is buffered; the repl prints return values to
*standard-output*, which is also buffered; to you they look the same,
though, because they're both going to your terminal.

If you need to ensure that all output is flushed at any point on a
given stream, use the Common Lisp functions FORCE-OUTPUT or
FINISH-OUTPUT.

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edwin M Westbrook | 1 Jul 2004 21:00
Picon

Re: build failure on OS X.3


Well...

Good news and bad news. The good news is that I got the binary distro of
0.8.9, and used that to successfully compile 0.8.12. This is also the bad
news, as it means that building from both 0.8.6 and 0.8.8 didn't work...
Maybe this is some problem with OS X.3?

-E

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 8 comments |
headers
Edwin M Westbrook | 1 Jul 2004 21:31
Picon

Keeping it clean with a MOP

Hello all,

I'm working with Tom Burdick to make an Objective-C bridge for SBCL. We're
trying to integrate the ObjC objects really nicely into SBCL, and we want
it all to play nicely in the MOP. We're doing this by defining an
objc-object class, instances of which are proxies for objects in the objc
heap, i.e. all methods called on an objc-object Lisp proxy get forwarded
(via sb-alien) to message handlers in objective-C land for the
corresponding ObjC object.

To be really clean (and well MOPped), we also wanted to make the
Objective-C slots in the underlying Objective-C objects visible to the
lisp world. We were hoping to do this through the normal MOP methods on
the proxy objects, so the proxy objects were truly transparent.
However, an objc slot should not be allocated in the proxy object, so it
should not have :instance allocation. Nor is it really a :shared slot. So
we figured we should have an :objc allocation, which would mean the slot
is located in the Objective-C world. We would have our own subclass of
effective-slot-definition, and would specialize slot-value-using-class on
it to use sb-alien to read the values from the actual objc object.

First of all, does this sound right? Tom and I have poured over the MOP
spec, and it doesn't directly confirm or deny any allegations that this is
ok. Specifically, compute-slots does not say that any non-standard slot
allocations should cause an error; it just says what the standard ones
should do. SBCL currently doesn't let you use a non-standard allocation.
The around method for compute-slots has an ecase form, which prevents any
slot from having an allocation type different than :instance or
:allocation. Does this sound like a bug or a feature?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christophe Rhodes | 1 Jul 2004 23:14
Picon
Picon
Favicon

Re: Keeping it clean with a MOP

Edwin M Westbrook <emw1 <at> express.cec.wustl.edu> writes:

> I'm working with Tom Burdick to make an Objective-C bridge for SBCL. We're
> trying to integrate the ObjC objects really nicely into SBCL, and we want
> it all to play nicely in the MOP. We're doing this by defining an
> objc-object class, instances of which are proxies for objects in the objc
> heap, i.e. all methods called on an objc-object Lisp proxy get forwarded
> (via sb-alien) to message handlers in objective-C land for the
> corresponding ObjC object.

This sounds interesting.

> To be really clean (and well MOPped), we also wanted to make the
> Objective-C slots in the underlying Objective-C objects visible to the
> lisp world. We were hoping to do this through the normal MOP methods on
> the proxy objects, so the proxy objects were truly transparent.
> However, an objc slot should not be allocated in the proxy object, so it
> should not have :instance allocation. Nor is it really a :shared slot. So
> we figured we should have an :objc allocation, which would mean the slot
> is located in the Objective-C world. We would have our own subclass of
> effective-slot-definition, and would specialize slot-value-using-class on
> it to use sb-alien to read the values from the actual objc object.
>
> First of all, does this sound right? 

It sounds at least plausible.  But...

> Tom and I have poured over the MOP spec, and it doesn't directly
> confirm or deny any allegations that this is ok. Specifically,
> compute-slots does not say that any non-standard slot allocations
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 1 Jul 2004 23:43
Picon
Picon
Favicon

Re: Keeping it clean with a MOP

Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

> [ A hacky workaround, following a different example in AMOP (on page
>   88, if you have the same edition I do) is to programatically add an
>   effective-slot-definition with :instance allocation, and specialize
>   slot-value-using-class on your objc-class.  There are two problems
>   with this: one is woeful inefficiency, including for normal slot-value
>   access in your objects as optimizations would no longer be possible;
>   the other is that there is a currently open bug preventing this: see
>   #334 in the BUGS file. ]

In partial penance for pessimism, and to encourage you warmly in
exploring this problem, here is a fix for bug #334 (which may reveal
other problems, of course: this has been only tested against the test
cases in that bug report).  During the great PCL reorganization of
last year, a number of new codepaths were opened up that weren't all
tested against user code, sadly: this patch fixes up, band-aid like,
two such unexpected codepaths.  Firstly, the old PCL code represented
:allocation :class as :allocation <class> -- this obviously had MOP
conformance problems, so we added a new allocation-class slot for
this.  User code cannot be expected to know about this, though, so we
must fix up any requests for :allocation :class slots ourselves to
have the class information.  This partly fixes 334b.  334a, and the
other half of 334b, are fixed by, again, adding some internal
information to user-created slotds.

It is entirely possible that these fixups should only apply to
standard-effective-slot-definitions.  I don't know.  But maybe this
will help you in your explorations.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Liam Healy | 2 Jul 2004 01:13
Picon

Re: sbcl-mt: princ does not strings well

Thanks for the explanation; indeed finish-output takes care of the
problem.  The CL implementation I'm porting the code from apparently
did its own finish-output after each princ.

>>>>> "Christophe" == Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

    Christophe> Liam Healy <lnp <at> healy.washington.dc.us> writes:
    >> Strings get garbled up in princ:
    >> 
    >> Looks like maybe the last (or only) line doesn't get flushed until
    >> the next princ, or until you quit sbcl?

    Christophe> Right.  The reason you see garbling is that you're effectively
    Christophe> printing to two different streams here: T as a stream designator means
    Christophe> *terminal-io*, which is buffered; the repl prints return values to
    Christophe> *standard-output*, which is also buffered; to you they look the same,
    Christophe> though, because they're both going to your terminal.

    Christophe> If you need to ensure that all output is flushed at any point on a
    Christophe> given stream, use the Common Lisp functions FORCE-OUTPUT or
    Christophe> FINISH-OUTPUT.

    Christophe> Cheers,

    Christophe> Christophe
    Christophe> -- 
    Christophe> http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
    Christophe> (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
    Christophe> (defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christophe Rhodes | 2 Jul 2004 10:12
Picon
Picon
Favicon

Re: customizing compute-slots

Bruno Haible <bruno <at> clisp.org> writes:

> The MOP spec says about COMPUTE-SLOTS's primary methods: "This
> method can be overridden." But when trying to do this, to add a new
> local or shared slot, I get an error:

Thanks for the report; I've merged a fix for this in sbcl-0.8.12.16.

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 0 comments |
headers
nyef | 2 Jul 2004 15:29
Picon

Win32 patches

Hello all.

At http://www.dridus.com/~nyef/sbcl-0.8.9-win32-changes.tgz
is a tarball containing diffs and new files between released
0.8.9 and my current working directory for win32. I haven't
touched it in about two weeks, so I figured it was time to
let someone else take a shot at it if they wanted.

Thus far, all compilation has been done using a mingw cross-
compiler (gcc 3.3.1) on a Linux box and sbcl 0.8.5. You may
need to modify the Config file for the runtime to suit the
compiler you end up using.

Some of the (new) functions in wrap.c may be set up to print
far more information than is necessary. write(), for example,
could probably be unwrapped without too much trouble.

For some reason, the Win32 console likes to return a bad file
descriptor error when writing to stdout or stderr. No doubt
there is a good reason for this. Using cygwin rxvt or cygwin
emacs around a bash shell will prevent this from happening.

There is still some sort of data corruption going on. During
the final purify for the save-lisp-and-die in make-target-2
the control structures for malloc()/free() get corrupted. If
you call (sb!impl::messagebox 0 "Foo" "Bar" 0) from the repl,
you get a crash somewhere in user32; but if you call (dotimes
(i 2) (sb!impl::messagebox 0 "Foo" "Bar" 0)), it works.

Oh yeah, and the wrapper for open() has a nasty hack in it.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christophe Rhodes | 7 Jul 2004 11:42
Picon
Picon
Favicon

Re: Win32 patches

nyef <at> sc.am writes:

> At http://www.dridus.com/~nyef/sbcl-0.8.9-win32-changes.tgz
> is a tarball containing diffs and new files between released
> 0.8.9 and my current working directory for win32. I haven't
> touched it in about two weeks, so I figured it was time to
> let someone else take a shot at it if they wanted.

Out of interest, does anyone on this list have an interest in sbcl on
windows?  I worry slightly that all the members here are already using
Unixoid platforms moderately exclusively.  If no-one here is biting,
it may be worth posting this to a more general audience...

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 2 comments |

Gmane