Steel Bank Common Lisp

Terrence Brannon <terrence.x.brannon@...> writes:
> The manual says it loads HOME/.sbclrc but HOME is not defined in my 
> environment.

USER-HOMEDIR-PATHNAME should tell you where "home" is:

  * (user-homedir-pathname)
  #P"C:\\Documents and Settings\\Luís\\"

Notice that it returns different values depending on whether you're
running it from Emacs, Cygwin, MSYS, cmd.exe, etc, because it first
looks for the HOME environment variable first (which is set by Emacs,
Cygwin, etc, but not necessarily set system-wide) and only then through
SHGetFolderPath(CSIDL_PROFILE) which should return something like what
you see in the example above.

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/

Yes Luis, everything you say below is reproducible. I think I should've 
discussed my exact problem instead of assuming that the .sbclrc is not loaded. 

My exact problem is this. If I go to the SLIME repl, and type

(asdf:operate 'asdf:load-op 'redick)

Then the package loads just fine.

However, if I evaluate the same form by opening an Emacs file and going to the 
end of the form and type C-x C-e, then I get the error:

Debugger entered--Lisp error: (void-function asdf:operate)
  (asdf:operate (quote asdf:load-op) (quote redick))
  eval((asdf:operate (quote asdf:load-op) (quote redick)))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)

And I dont know why this started happening. It works just fine on my home 
Windows XP laptop, but it stopped working on this work-laptop the second I 
started playing with Clisp for awhile (because Common Music doesnt load under 
SBCL) and tried to return the SBCL.

I guess that's the punishment for adultery.

Terrence Brannon wrote:
> However, if I evaluate the same form by opening an Emacs file and going to the 
> end of the form and type C-x C-e, then I get the error:
> 
> Debugger entered--Lisp error: (void-function asdf:operate)
>   (asdf:operate (quote asdf:load-op) (quote redick))
>   eval((asdf:operate (quote asdf:load-op) (quote redick)))
>   eval-last-sexp-1(nil)
>   eval-last-sexp(nil)
>   call-interactively(eval-last-sexp)

What do you mean by "opening an Emacs file"? It seems you're asking 
Emacs to evaluate the form, not SLIME. If the buffer you're in is an 
Emacs Lisp buffer, that's exactly what will happen.

Otherwise, I'd suggest checking your SLIME setup and asking slime-devel 
for help.
-- 
Brian Mastenbrook
brian@...
http://brian.mastenbrook.net/

Brian Mastenbrook <brian <at> mastenbrook.net> writes:

> 
> What do you mean by "opening an Emacs file"? It seems you're asking 
> Emacs to evaluate the form, not SLIME. 

Bingo - SLIME was not activated and so the form was not being sent to an 
inferior lisp. Now it works. Thanks.

On Sat, Dec 22, 2007 at 10:20:55PM +0100, Nicolas Neuss wrote:
> I sometimes like to use DEFMETHOD as replacement for DEFUN + type
> declarations (i.e., even if there is no broader use of that function in
> which case a DEFGENERIC would make sense).  In these cases, the style
> warning "implicitly creating new generic function" is a nuisance.  Is it
> possible to switch off this warning selectively?

Are you sure you want to do this? If you are not suppressing style
warnings completely, I'd expect it's because you want to be warned
about things like defining unused variables and calling undefined
functions and so forth. Issuing warnings about code like
  (defgeneric suppressing-errors (family fun)
  (defmethod suppresing-errors ((family decorated-family) fun)
    (with-invoked-decorators (family)
      (funcall fun)))
has always seemed to me to be in the same spirit, and the only thing
the compiler will be able to see wrong about that code is that the
the DEFMETHOD has no matching DEFGENERIC.

Also, it seems to me that that's an odd thing to use DEFMETHOD for. I
sometimes feel the need, but I meet the need with a family of
DEFMACROs like
  (defmacro def-declaimed-fun (name (args types return-type &key inline)
                                &body body)) 
    `(progn (declaim ...) (defun ...)))
and
  (defmacro def-declaimed-proc (name (args types &key inline) &body body)
    `(def-declaimed-fun ,name (,args ,types (values) :inline ,inline) ,@body))
If you choose to use DEFMETHOD instead, you're choosing to tell the
compiler something somewhat misleading about what you're doing; a
roundabout way to stop the style warnings would be to choose to be
less misleading.

-- 
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C
God grant me serenity to accept the code I cannot change, courage to 
change the code I can, and wisdom to know the difference. -- Erik Naggum

On 23.12.2007, at 05:20, Nicolas Neuss wrote:

> Hello,
>
> I sometimes like to use DEFMETHOD as replacement for DEFUN + type
> declarations (i.e., even if there is no broader use of that function  
> in
> which case a DEFGENERIC would make sense).  In these cases, the style
> warning "implicitly creating new generic function" is a nuisance.   
> Is it
> possible to switch off this warning selectively?

In addition to all the points in Bill's reply, there's also

(defgeneric foo (x) (:method ((x fixnum)) x))

Since that form defines the generic function and a method, there are  
no warnings.

Rudi

Rudi Schlatte <rudi@...> writes:

> On 23.12.2007, at 05:20, Nicolas Neuss wrote:
>
>> Hello,
>>
>> I sometimes like to use DEFMETHOD as replacement for DEFUN + type
>> declarations (i.e., even if there is no broader use of that function  in
>> which case a DEFGENERIC would make sense).  In these cases, the style
>> warning "implicitly creating new generic function" is a nuisance.   Is it
>> possible to switch off this warning selectively?
>
> In addition to all the points in Bill's reply, there's also
>
> (defgeneric foo (x) (:method ((x fixnum)) x))

Yes, I know, but this is still too clumsy to write for my taste.

(BTW, the use of a type specifier like FIXNUM -which is not guaranteed to
be a class- is non-standard.)

Merry christmas,
Nicolas

> Since that form defines the generic function and a method, there are  no
> warnings.
>
> Rudi
>
>

-- 
PD Dr. Nicolas Neuss  University Karlsruhe  Tel: 0049-721-608-7634
Email: neuss@...
WWW: <http://www.mathematik.uni-karlsruhe.de/~neuss>

william.newman@... (William Harold Newman) writes:

> Are you sure you want to do this? If you are not suppressing style
> warnings completely, I'd expect it's because you want to be warned
> about things like defining unused variables and calling undefined
> functions and so forth.

Yes.

> Issuing warnings about code like
>   (defgeneric suppressing-errors (family fun)
>   (defmethod suppresing-errors ((family decorated-family) fun)
>     (with-invoked-decorators (family)
>       (funcall fun)))
> has always seemed to me to be in the same spirit, and the only thing
> the compiler will be able to see wrong about that code is that the
> the DEFMETHOD has no matching DEFGENERIC.

OK, but this special style is probably not so rarely encountered.  At
least, it was mentioned also by Kent Pitman in comp.lang.lisp several
times.  I usually use it in cases like this:

;;; class definition

(defclass () ...)

;;; method definitions - some of them are specializations of already
;;; existing generic functions, some of them are more for local use.  At
;;; least for the moment I do not want to decide, if these should be
;;; functions or generic functions.

(defmethod ... ())
...

> Also, it seems to me that that's an odd thing to use DEFMETHOD for. I
> sometimes feel the need, but I meet the need with a family of
> DEFMACROs like
>   (defmacro def-declaimed-fun (name (args types return-type &key inline)
>                                 &body body)) 
>     `(progn (declaim ...) (defun ...)))
> and
>   (defmacro def-declaimed-proc (name (args types &key inline) &body body)
>     `(def-declaimed-fun ,name (,args ,types (values) :inline ,inline) ,@body))
> If you choose to use DEFMETHOD instead, you're choosing to tell the
> compiler something somewhat misleading about what you're doing; a
> roundabout way to stop the style warnings would be to choose to be
> less misleading.

The macro has the problem, that highlighting probably will not work as
well, and maybe also the editor will not be able to locate the function
definition as well, especially if something in the file has changed.

Merry christmas,
Nicolas

On Dec 24, 2007 9:09 AM, Nicolas Neuss <neuss@...> wrote:

As of very recently (1.0.12.38), the signalled condition is

 SB-EXT:IMPLICIT-GENERIC-FUNCTION-WARNING (subclass of STYLE-WARNING)

so you can indeed selectively muffle it by doing

(handler-bind ((sb-ext:implicit-generic-function-warning #'muffle-warning))
  (load "foo.lisp"))

in eg. an ASDF around-method.

Unfortunately, there is not as of yet a way to do this per-file using the
MUFFLE-CONDITION proclamations, since it applies only to compile-time
conditions -- but that may change (see list archives for the earlier
inconclusive discussion).

> ;;; method definitions - some of them are specializations of already
> ;;; existing generic functions, some of them are more for local use.  At
> ;;; least for the moment I do not want to decide, if these should be
> ;;; functions or generic functions.

I don't understand. The moment you write a DEFMETHOD you've obviously
decided in favor of using a generic function.

> The macro has the problem, that highlighting probably will not work as
> well, and maybe also the editor will not be able to locate the function
> definition as well, especially if something in the file has changed.

Editor smarts about DEFOO macros are indeed a bit problematic, but source
location problems should be IMO considered bugs in either Slime or
SB-INTROSPECT.

Merry Christmas,

 -- Nikodemus

"Nikodemus Siivola" <nikodemus@...> writes:

> On Dec 24, 2007 9:09 AM, Nicolas Neuss <neuss@...> wrote:
>
> As of very recently (1.0.12.38), the signalled condition is
>
>  SB-EXT:IMPLICIT-GENERIC-FUNCTION-WARNING (subclass of STYLE-WARNING)
>
> so you can indeed selectively muffle it by doing
>
> (handler-bind ((sb-ext:implicit-generic-function-warning #'muffle-warning))
>   (load "foo.lisp"))
>
> in eg. an ASDF around-method.

Nice, thank you.

> Unfortunately, there is not as of yet a way to do this per-file using the
> MUFFLE-CONDITION proclamations, since it applies only to compile-time
> conditions -- but that may change (see list archives for the earlier
> inconclusive discussion).
>
>> ;;; method definitions - some of them are specializations of already
>> ;;; existing generic functions, some of them are more for local use.  At
>> ;;; least for the moment I do not want to decide, if these should be
>> ;;; functions or generic functions.
>
> I don't understand. The moment you write a DEFMETHOD you've obviously
> decided in favor of using a generic function.

In principle you are right, but in spirit you are wrong:-) For example, I
use DEFMETHOD without an explicit DEFGENERIC when I want to convey the idea
of defining methods for a certain class.  And I omit DEFGENERIC also when I
am not yet sure if the functionality is more generally applicable, but, on
the other hand, want the type-checking of arguments provided by DEFMETHOD.

Yours, Nicolas

"Alex Mizrahi" <alex.mizrahi@...> writes:
> helo
> 
> SBCL 1.0.12 crashes on Linux x86_64 (CentOS 5, 2.6.18-8.el5) with
> messages like this:
> 
> -----
> debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD
> "iolib worker 0" {1003C2A511}>:
>   Unhandled memory fault at #x0.
> -----
> Final object pointer 0x2aacb0e6dde0, start 0x2aaab0e62000, end 0x2aaab0e62570
> fatal error encountered in SBCL pid 19749(tid 46912611776816):
> GC invariant lost, file "gc-common.c", line 197
> -----
> 
> it happens on a multithreaded web server using UCW and iolib.
> 
> what would be suggestions on debugging this error?

The GC invariant lost message is basically telling that some memory
corruption has happened, and the GC was the first one to notice
it. It's hard to debug that after the fact. A backtrace will basically
be useless, since it won't tell you anything about which piece of
memory was corrupted, let alone what corrupted it.

The iolib message is also somewhat suggestive of either memory
corruption having happened, or memory corruption just happening. So
figuring out what is going on there might be a good first step. So
compile your application and libraries with a higher debug level, get
a backtrace (or even better, a slime debugger), and see what exactly
is referencing the null pointer. Then figure out why it's doing so :-)

Also, to ensure that everything is being compiled at maximum safety,
you could remove all fasls, (sb-ext:restrict-compiler-policy 'safety
3) and then recompile. This would help if the memory corruption is
caused by Lisp code, e.g. some (safety 0) code doing an out of bounds
array write, but not if it's something done by foreign code.

> also i suspect there are less chanced crashing when only one thread is
> used, is that correct?

Having just one thread would reduce the chance of some kinds of errors
(e.g. the GC moving an array that a foreign function has a pointer
to).

-- 
Juho Snellman

T24gRGVjIDEyLCAyMDA3IDU6MDggUE0sIE1hcmMgSGFsYnLDvGdnZSA8bWFyYy5oYWxicnVlZ2dl
QHVuaWJ3LmRlPiB3cm90ZToKCj4gc2JjbCBzZWVtcyBub3QgdG8gd29yayBvbiBhbiBJdGFuaXVt
MiAodmFyaWluZyBlcnJvciBtZXNzYWdlcyBsaWtlCj4gIm1lbW9yeSBmYXVsdCIgb3IgInZhbHVl
IGlzIG5vdCBvZiB0eXBlIFNCLUtFUk5FTDpDVFlQRSIpLgo+Cj4gQ2FuIGFueWJvZHkgc3VnZ2Vz
dCBhbiBhbHRlcm5hdGl2ZSBMaXNwIHZlcnNpb24/IE9yIHN1Y2NlZGVkIGluIHJ1bm5pbmcKPiBz
YmNsIG9uIExpbnV4L0l0YW5pdW0/CgpUaGVyZSBpcyBubyBJdGFuaXVtIHBvcnQgb2YgU0JDTCwg
c28gaXQgbmVlZHMgdG8gYmUgcnVubmluZyBpbiB4ODYgZW11bGF0aW9uCm1vZGUgLS0gc2V0dGlu
ZyB3aGljaCBpcyBwcmVzdW1hYmx5IHRoZSB0YXNrIG9mIHlvdXIgb3BlcmF0aW5nIHN5c3RlbS4K
CldoYXQgZG9lcyB1bmFtZSAtYSBzYXk/IFdoZXJlIGRpZCB5b3Ugb2J0YWluIFNCQ0w/IFdoYXQg
YXJlIHlvdSBkb2luZyB0aGF0CnByb3Zva2VzIHRoZXNlIGVycm9ycyAoanVzdCBzdGFydGluZyBT
QkNMLCBvciBkbyB5b3UgYWN0dWFsbHkgaGF2ZSB0bwpydW4gc29tZSBjb2RlIHRvIHNlZSB0aGlz
PykgV2hhdCBTQkNMIHZlcnNpb24gYXJlIHlvdSB1c2luZz8gQ2FuIHlvdSBnZXQKYSBiYWNrdHJh
Y2U/CgpDaGVlcnMsCgogLS0gTmlrb2RlbXVzCg==

> Thank you for reply, Nicodemus.

Nikodemus.

On Dec 11, 2007 2:19 PM, Vodonosov Anton <avodonosov@...> wrote:

> debugger invoked on a SB-KERNEL::MEMORY-FAULT-ERROR in thread #<THREAD {B7528C1}>:
>
>   memory fault

Possible causes:

* SIGSEGV in foreign code.

* Foreign code scribbling over the lisp heap causing lisp to try to
access a location outside
the heap.

* Type-errors + SAFETY 0, TRULY-THE, or (> SPEED SAFETY).

* Compiler bugs. A few of these have been seen during the last half a
year or so, and all
known bugs causing memory faults should be fixed in HEAD -- so it
would be interesting
to know which SBCL version you are using.

> Maybe there is a way to speedup garbage collector or to tune
> sbcl to use less memory? (not generate debug information, etc.)

SPACE 3, DEBUG 0 -- but I doubt it'll get you far. Bottom line is that
current SBCL is not
really designed to run in 64Mb of memory. If you don't mind swapping
you can always try
increasing the virtual memory size...

Cheers,

 -- Nikodemus

> known bugs causing memory faults should be fixed in HEAD -- so it

> would be interesting

> to know which SBCL version you are using.

Not the recent, SBCL 1.0



> > Maybe there is a way to speedup garbage collector or to tune

> > sbcl to use less memory? (not generate debug information, etc.)

> SPACE 3, DEBUG 0 -- but I doubt it'll get you far. Bottom line is that

> current SBCL is not

> really designed to run in 64Mb of memory. If you don't mind swapping

> you can always try

> increasing the virtual memory size...



Could you give some hints how to track down the pleace in the web

server that causes most of consing? (I'm aware about profilers 

described in the manual and even tried statistical profiler, but

may be you have some interesting advices?)

On Dec 11, 2007 3:27 PM, Vodonosov Anton <avodonosov@...> wrote:
> > known bugs causing memory faults should be fixed in HEAD -- so it
>
> > would be interesting
>
> > to know which SBCL version you are using.
>
> Not the recent, SBCL 1.0

Unless you have a pressing reason to use 1.0, I would recommend updating.

> Could you give some hints how to track down the pleace in the web
> server that causes most of consing? (I'm aware about profilers
> described in the manual and even tried statistical profiler, but
> may be you have some interesting advices?)

Use eg. the statistical profiler as described in the manual.

Cheers,

 -- Nikodemus

Thank you for help.



> On Dec 11, 2007 3:27 PM, Vodonosov Anton <avodonosov@...> wrote:

> > > known bugs causing memory faults should be fixed in HEAD -- so it

> >

> > > would be interesting

> >

> > > to know which SBCL version you are using.

> >

> > Not the recent, SBCL 1.0

> Unless you have a pressing reason to use 1.0, I would recommend updating.

> > Could you give some hints how to track down the pleace in the web

> > server that causes most of consing? (I'm aware about profilers

> > described in the manual and even tried statistical profiler, but

> > may be you have some interesting advices?)

> Use eg. the statistical profiler as described in the manual.

> Cheers,

>  -- Nikodemus