Steel Bank Common Lisp

Immanuel Litzroth <immanuell@...> writes:

> In cmucl you can download the sources and go directly to the code of 
> a function (implemented in cmu) by setting the appropriate searchlist.
> I have not got something like this working in sbcl. Is this possible or
> do I need to do a compile for this functionality?

It's possible.  If your distribution doesn't do it for you, you may
need to set the translations of the "SYS" logical pathname host
appropriately.

(for sources which live in /var/tmp/sbcl, 

CL-USER> (logical-pathname-translations "SYS")
(("SYS:SRC;**;*.*.*" #P"/var/tmp/sbcl/src/**/*.*")
 ("SYS:CONTRIB;**;*.*.*" #P"/var/tmp/sbcl/contrib/**/*.*"))

works for me)

Cheers,

Christophe

Immanuel Litzroth <immanuell@...> writes:
>
> In cmucl you can download the sources and go directly to the code of a
> function (implemented in cmu) by setting the appropriate searchlist.
> I have not got something like this working in sbcl. Is this possible
> or do I need to do a compile for this functionality?

I think you need to have visited the file already, or compiled it with
slime running or something--M-. seems to work for me.  Worst case, you
could always just run etags in the relevant directory, and then M-X
visit-tags-table.

-- 
Robert Uhl <http://public.xdi.org/=ruhl>
There are two ways--one of Life, and one of death.  And there is a very
great difference between the two ways.                    --The Didache

OK, things look a little different against sbcl head (0.9.2.53).

Apparently the buffer argument to sb-sys:read-n-bytes must be exactly
size 512:

The value ".^@.^@" is not of type (SIMPLE-ARRAY CHARACTER (512)).
   [Condition of type TYPE-ERROR]

Restarts:
  0: [ABORT] Abort handling SLIME request.
  1: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: (SB-IMPL::FD-STREAM-READ-N-CHARACTERS/UTF-8 #<SB-SYS:FD-STREAM for "file /var/tmp/foo" {6164C7A1}> ".^@.^@" 0 4 T)
  1: (NIL)
  2: (SB-INT:EVAL-IN-LEXENV (WITH-OPEN-FILE (S "/var/tmp/foo" :DIRECTION :INPUT) (LET (#) (SB-SYS:READ-N-BYTES S BUFFER 0 4) BUFFER)) #<NULL-LEXENV>)

Any size other than 512 fails as above.  Is this intended behavior?

If I supply an :external-format of :ascii then sb-sys:read-n-bytes
will read all four bytes:

(with-open-file (s "/var/tmp/foo" :direction :input :external-format :ascii)
  (let ((buffer (make-array 512 :element-type 'character)))
    (sb-sys:read-n-bytes s buffer 0 4)
    buffer))

But if I change :external-format to :utf-8 it only returns the first
character.  The same file is _created_ whether I use :ascii or :utf-8,
but I get different results when reading.  Is this to be expected?

Any ideas appreciated.

-russ

Russell McManus <russell_mcmanus@...> writes:

> Any size other than 512 fails as above.  Is this intended behavior?

I think so.  Well, I think you're falling into a trap that's been
(unintentionally) laid for you, lurking for months if not years.

I would suggest using sb-sys:read-n-bytes on a byte stream, not a
character stream, and converting the octets you get from reading them
into a string using octets-to-string.  The SBCL internal machinery is
such that it never calls sb-sys:read-n-bytes on a character stream
directly, I believe, but we don't detect violations -- and before the
implementation of Unicode, this didn't matter because strings and
(unsigned-byte 8) vectors had identical memory layout.

I don't know if this solves your actual problem, but if you can rework
the I/O layer to use octets, I think that's more likely to work.

Cheers,

Christophe

Christophe Rhodes <csr21@...> writes:

> Russell McManus <russell_mcmanus@...> writes:
>
>> Any size other than 512 fails as above.  Is this intended behavior?
>
> I think so.  Well, I think you're falling into a trap that's been
> (unintentionally) laid for you, lurking for months if not years.
>
> I would suggest using sb-sys:read-n-bytes on a byte stream, not a
> character stream, and converting the octets you get from reading them
> into a string using octets-to-string.  The SBCL internal machinery is
> such that it never calls sb-sys:read-n-bytes on a character stream
> directly, I believe, but we don't detect violations -- and before the
> implementation of Unicode, this didn't matter because strings and
> (unsigned-byte 8) vectors had identical memory layout.
>
> I don't know if this solves your actual problem, but if you can rework
> the I/O layer to use octets, I think that's more likely to work.

Thanks for the help.  I'm writing an NNTP server.

Perhaps I'll try to write a better doc string for the function based
on your comments above and send it to the list, to help the next
swedish chef who comes along thinking that he can blindly port code
from cmucl to sbcl...

Should read-n-bytes signal an error condition when given the wrong
type of stream?

-russ

How should I interpret the lack of response to this question?

(0) I should not want to restart after signals/exceptions, as that
really means the C++ DLL/DSO data/stack/whatever is hopelessly screwed
up.

(1) It is not possible to restart the C++ after either a signal or
exception, as there are no mechanics in SBCL to do so.

(2) It is possible to write such mechanics, but they would be a PITA
to implement.

(3) It is a stupid question, as there is another obvious -- to
everybody but me -- solution.  (Pray tell, what might that be?)

(4) Nobody has a clue.

-jm

On Wednesday 20 July 2005 12:15 pm, John Morrison wrote:
> Hi;
>
> Short version is the subject line of this message.
>
> The longer version: I can now generate bindings for my several
> millions of lines of C++ code (using gccxml).  I can build the DLLs so
> that inlined functions are available (-fkeep-inline-functions).  I can
> combine DLLs with no linear load order (using gcc) into a single DLL
> that can be opened with load-shared-object.  I can call C++ entry
> points.
>
> One of the remaining issues is how to deal with signals and C++
> exceptions.
>
> W.r.t. signals, if SBCL catches a signal that arises during the
> calling of C++ code via sb-alien, SBCL catches the signal.  Can I (or
> even should I) resume the execution?
>
> I have the same questions regarding C++ exceptions...
>
> Thanks for the help,
>
> -jm
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 10 Fawcett Street, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@...

John Morrison wrote:
> One of the remaining issues is how to deal with signals and C++
> exceptions.
> 
> W.r.t. signals, if SBCL catches a signal that arises during the
> calling of C++ code via sb-alien, SBCL catches the signal.  Can I (or
> even should I) resume the execution?
> 
> I have the same questions regarding C++ exceptions...

Well if there is no C++ try/catch block to deal with the exception then 
the stack will be unwound all the way back to main() and your program 
will exit.  So to be able to catch C++ exceptions from Lisp I think 
you'd either need to;

* use C++ wrapper functions with try/catch blocks that set certain error
   flags for Lisp to pick up, or

* make Lisp put a C++ try/catch block around each call by arcane and
   non-portable stack manipulations and whatnot.

I am not aware of any Lisp implementation being able to do the latter, 
but the former is very much doable, and is more or less how C++ to 
Python interfaces work.  (Python the language, not the Common Lisp 
compiler.)

Kind regards,

Dirk Gerrits

Hi Dirk;

Thanks for the information!

On Sunday 24 July 2005 03:52 pm, Dirk Gerrits wrote:
> Well if there is no C++ try/catch block to deal with the exception then
> the stack will be unwound all the way back to main() and your program
> will exit.  So to be able to catch C++ exceptions from Lisp I think
> you'd either need to;
>
> * use C++ wrapper functions with try/catch blocks that set certain error
>    flags for Lisp to pick up, or
>
> * make Lisp put a C++ try/catch block around each call by arcane and
>    non-portable stack manipulations and whatnot.
>
> I am not aware of any Lisp implementation being able to do the latter,
> but the former is very much doable, and is more or less how C++ to
> Python interfaces work.  (Python the language, not the Common Lisp
> compiler.)

Is this some sort of automated post-process (as I am contemplating),
or does it rely on some sort of programming convention and/or library
(e.g., Boost), or is it some sort of automagical runtime thing like
your second option?

Perhaps if you would please be so kind as to provide a URL, then I
could come up to speed without further pestering.

Thanks again,

-jm

>
> Kind regards,
>
> Dirk Gerrits
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 10 Fawcett Street, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@...

Hi John.

John Morrison wrote:
> On Sunday 24 July 2005 03:52 pm, Dirk Gerrits wrote:
> 
>> Well if there is no C++ try/catch block to deal with the exception
>> then the stack will be unwound all the way back to main() and your
>> program will exit.  So to be able to catch C++ exceptions from Lisp
>> I think you'd either need to;
>> 
>> * use C++ wrapper functions with try/catch blocks that set certain
>> error flags for Lisp to pick up, or
>> 
>> * make Lisp put a C++ try/catch block around each call by arcane
>> and non-portable stack manipulations and whatnot.
>> 
>> I am not aware of any Lisp implementation being able to do the
>> latter, but the former is very much doable, and is more or less how
>> C++ to Python interfaces work.  (Python the language, not the
>> Common Lisp compiler.)
> 
> 
> Is this some sort of automated post-process (as I am contemplating), 
> or does it rely on some sort of programming convention and/or library
> (e.g., Boost), or is it some sort of automagical runtime thing like 
> your second option?

To call C++ functions from Python you basically wrap them in C functions
that take and return PyObject pointers.  The body of such a function
will call the original C++ function from inside a try/catch block.

Both SWIG and Boost.Python allow you to create such wrapper functions
more or less automatically; SWIG as a standalone application with its
own C++ parser, Boost.Python as a library for C++ compilers.

> Perhaps if you would please be so kind as to provide a URL, then I 
> could come up to speed without further pestering.

Certainly:
http://www.swig.org/
http://boost.org/libs/python/doc/index.html

Kind regards,

Dirk Gerrits

"Emre Sevinc" <emres@...> writes:

> To cut the long story short, I simply provide
> the link to the problem I encounter, basically it is
> about trying to read a file containing Turkish characters
> (ISO-8859-9) w/o success:
> http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/0a77731a32e493fd/7aea80918aa55041
> People suggested CLISP but I don't want to switch
> my Lisp implementation for encoding issues, I want
> to handle it with SBCL if I can.

Without reading that link: you would need to implement support for
iso-8859-9, to convert between the numerical codes provided by the
operating system and the characters that they represent.  CLISP
currently supports more external formats than SBCL does; we are
waiting for users to implement external formats which they use.
(Implementing an iso-8859-x external format is relatively
straightforward, though Teemu Kalvas' implementation of -15 has aimed
for maximal efficiency)

Cheers,

Christophe

On Tue, Jul 19, 2005 at 08:14:16PM -0300, Paulo Jabardo wrote:
> Hello, I am experiencing a few problems with sbcl
> (compiled version 0.9.0 available on sourceforge) on
> linux on AMD64 (ubuntu 5.04 AMD64, kernel 2.6.10).

2.6.10 has broken userspace traps on x86-64. Please use either some
earlier or later kernel (both 2.6.9 and 2.6.11 should work), or
recompile your kernel with the patch from the following message:

http://article.gmane.org/gmane.lisp.steel-bank.devel/4180

-- 
Juho Snellman

Nikodemus Siivola <tsiivola@...> writes:

> Moved to sbcl-help.
>
> On Tue, 12 Jul 2005, Carlos Ungil wrote:
>
>> * set_auto_gc_trigger: tried to set gc trigger too high! (0x080922a0)
>> fatal error encountered in SBCL pid 14044:
>
> This is SBCL's admittedly rather suboptimal way of tell you that
> you've run out of heap space.

If sockets are involved, it's possible that the cheneygc
implementation of with-pinned-objects (which is basically
without-gcing) plays a part in this: it's possible to hold on to way
too much garbage within the dynamic contour of without-gcing.

Cheers,

Christophe

SAVE-LISP-AND-DIE

Yeah, if we're all lucky enough to accomplish the first part, first.
:)

Nikodemus Siivola wrote:
> On Thu, 7 Jul 2005 jim@... wrote:
> 
>> couple of questions about images - I can write an image core with 
>> sb-ext:save-lisp-and-die but then need to kill sbcl/slime...from the 
>> manual
> 
> 
> Not "need to kill", it does that for you: if save-lisp-and-die does not
> end your session please report this as a bug. Of course, if you are 
> saving cores with multiple threads running all bets are off.
> 
>> "It corrupts the current Lisp image enough that the current process 
>> needs to be killed afterwards. This can be worked around by forking 
>> another process that saves the core."
>>
>> how is this done?
> 
> 
> Like this (read the wait and fork manpages for details):
> 
> * (require :sb-posix)
> 
> ("SB-GROVEL" "SB-POSIX")
> * (let ((pid (sb-posix:fork)))
>     (if (zerop pid)
>         (save-lisp-and-die "foo.core")
>         (sb-posix:wait)))
> [doing purification: roots handlers stack bindings static cleanup done]
> [undoing binding stack and other enclosing state... done]
> [saving current Lisp image into /Users/demoss/Sources/sbcl/foo.core:
> writing 21034864 bytes from the read-only space at 0x01000000
> writing 6256504 bytes from the static space at 0x08000000
> writing 2144 bytes from the dynamic space at 0x40000000
> done]
> 
> 674
> 0
> * (lisp-implementation-version)
> 
> "0.9.2.31"
> 
>> Also, how can I load the image later into a sbcl session in 
>> slime/emacs? sbcl --core mycore works but that's launching a raw sbcl 
>> process...
> 
> 
> You can't switch or load cores into a running SBCL. The core is in the 
> SBCL: runtime contains code to start the core, the garbage collector and 
> bits of OS support, almost everything else is in the core. Loading a 
> core is a bit of misnomer anyways: starting a core is more accurate.
> 
> If you need to just save session data write SEXPs to a file and read it 
> back in. If you need a quick and dirty way of serializing things that is 
> faster then PRINT/READ Google for fasldump and bindum. If you need to 
> serialize large amounts of data write an appropriate specialized format 
> ("everything is just a bucket of bits"). ...and then there all the 
> persistense frameworks, DB interfaces, etc.
> 
> Saving cores is mainly a delivery method, IMO.
> 
> (This is not to say that it cannot be co-opted for other purposes, but 
> that is beside the point.)
> 
> Cheers,
> 
>  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
>                   Lispnik: "Buddha is big, has hairy armpits, and laughs."
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
> 

thanks, that explains a lot.