Re: [Ecls-list] Configuration patch

2011-01-20 Thread Jerry James
On Wed, Jan 19, 2011 at 2:14 AM, Juan Jose Garcia-Ripoll wrote: > But do not bother to resend these ones. I will process them ASAP (which, as > you said, might be not too soon :-) Oh, I'm in no hurry. :-) > It depends :-) I got as far as being able to link ECL into Emacs long long > time ago. Th

Re: [Ecls-list] ECL-generated executables and restarts

2011-01-20 Thread Matthew Mondor
On Thu, 20 Jan 2011 05:13:58 -0500 Matthew Mondor wrote: > Is there something my program must do to have a normal debugger > including custom restarts when an unhandled condition occurs? > > Also, is what I'm doing sane, or would it be best to use the > prologue/epilogue features of c::build-pro

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Juan Jose Garcia-Ripoll
Ok, then what is broken is not the ordinary compiler, but the bytecodes compiler which is switch on by default in Windows. Juanjo On Thu, Jan 20, 2011 at 11:37 PM, Stas Boukarev wrote: > Stas Boukarev writes: > > > Juan Jose Garcia-Ripoll writes: > > > >> What settings do you have? I do not g

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Stas Boukarev
Stas Boukarev writes: > Juan Jose Garcia-Ripoll writes: > >> What settings do you have? I do not get those errors in any of my systems? > I can reproduce after doing (require 'bytecmp) And its compile-file has WITH-STANDARD-IO-SYNTAX around WRITE, which sets *print-readably* to T. -- With Best

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Stas Boukarev
Juan Jose Garcia-Ripoll writes: > What settings do you have? I do not get those errors in any of my systems? I can reproduce after doing (require 'bytecmp) -- With Best Regards, Stas. -- Special Offer-- Download ArcSig

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Juan Jose Garcia-Ripoll
What settings do you have? I do not get those errors in any of my systems? Juanjo On Thu, Jan 20, 2011 at 11:26 PM, Anton Vodonosov wrote: > Actually, the error is reproduced simply by creating a file test.lisp: > > (defpackage test) > > > Then start ECL and do > > > (compile-file "test.lisp") >

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Anton Vodonosov
Actually, the error is reproduced simply by creating a file test.lisp: (defpackage test) Then start ECL and do > (compile-file "test.lisp") ;;; Compiling test.lisp Cannot print object # readably. Available restarts: 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Anton Vodonosov
No, *print-readably* is NIL. 20.01.2011, 15:06, "Stas Boukarev" : > Anton Vodonosov ; writes: > >>  Hello. >> >>  Unfortunately deleting the ~/.slime directory doesn't help. >> >>  Correction, the error happens not when I load "swank-loader.lisp", but >> after that, when I >>  call swan-loader:in

Re: [Ecls-list] ecl with old libc: deadlock in gc due to signal handling

2011-01-20 Thread Juan Jose Garcia-Ripoll
On Thu, Jan 20, 2011 at 1:41 PM, Anton Vodonosov wrote: > I worry about this code: [...] > Can we run it in parallel with GC? > It is not 100% safe for other reasons, but memory allocation is protected by locks from other events such as garbage collection and memory allocation by other threads.

Re: [Ecls-list] ecl with old libc: deadlock in gc due to signal handling

2011-01-20 Thread Anton Vodonosov
20.01.2011, 14:55, "Juan Jose Garcia-Ripoll" : > On Thu, Jan 20, 2011 at 12:31 PM, Anton Vodonosov > wrote: >> It's a good idea, thanks. I will only need to think about race conditions, >> like if GC starts after the sigwait returns, but before we called >> GC_register_my_thread. Or this code

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Stas Boukarev
Anton Vodonosov writes: > Hello. >   > Unfortunately deleting the ~/.slime directory doesn't help. >   > Correction, the error happens not when I load "swank-loader.lisp", but after > that, when I > call swan-loader:init. >   > Here is the backtrace: >   > Backtrace: >   > SWANK-LOADER::HANDLE-S

Re: [Ecls-list] ecl with old libc: deadlock in gc due to signal handling

2011-01-20 Thread Juan Jose Garcia-Ripoll
On Thu, Jan 20, 2011 at 12:31 PM, Anton Vodonosov wrote: > > It's a good idea, thanks. I will only need to think about race conditions, > like if GC starts after the sigwait returns, but before we called > GC_register_my_thread. Or this code doesn't allocate any heap memory and > should not be pro

Re: [Ecls-list] ecl with old libc: deadlock in gc due to signal handling

2011-01-20 Thread Anton Vodonosov
Hello Juan Jose. It's enough to have a fix for the old libc only. It's a good idea, thanks. I will only need to think about race conditions, like if GC starts after the sigwait returns, but before we calledGC_register_my_thread. Or this code doesn't allocate any heap memory and should not be protec

Re: [Ecls-list] Cannot print object # readably

2011-01-20 Thread Anton Vodonosov
Hello. Unfortunately deleting the ~/.slime directory doesn't help. Correction, the error happens not when I load "swank-loader.lisp", but after that, when I call swan-loader:init. Here is the backtrace: Backtrace:  > SWANK-LOADER::HANDLE-SWANK-LOAD-ERROR  > swank-loader::compile-files  > swank-load

[Ecls-list] ECL-generated executables and restarts

2011-01-20 Thread Matthew Mondor
Hello again, If using a build script such as follows: (pushnew :mm-ecl-standalone *features*) (declaim (optimize (speed 0) (safety 3) (debug 3))) (compile-file "/path/to/program.lisp" :output-file "/tmp/program.o" :system-p t) (c::build-program "/tmp/program" :lisp-files '("/tmp/program.o")) (ext