gmane.lisp.cmucl.devel

Cinco de Mayo snapshot

Raymond Toy — 2012-05-05T17:05:12

The 2012 Cinco de Mayo snapshot has been tagged and binaries will be
uploaded shortly.

Changes for this release include several bug fixes for external formats,
more aliases, and an update to asdf2 2.21.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: Apr 2012 snapshot

Alex Goncharov — 2012-04-04T04:28:17

I've moved most of my machines to the latest release of FreeBSD (9.0),
so, starting from this snapshot, I am building for FreeBSD 9, rather
than 8; snapshot-2012-04 is uploaded.  These builds won't run on
FreeBSD 8.  If somebody needs a build for FreeBSD 8: snapshot-2012-03
or earlier.

Apr 2012 snapshot

Raymond Toy — 2012-04-02T06:13:30

The April 2012 snapshot has been tagged.  Binaries will be uploaded
soon.  I only got around to adding a couple of minor microptimizations
this time.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: [asdf-devel] CMUCL error with 20c

Raymond Toy — 2012-03-31T20:09:54

Can't reproduce this with the 2012-03 snapshot on my Linux (openSuSE
64bit) box.  Do you have any stale fasls that are getting loaded into
cmucl on startup?

I don't recall anything special being needed to compile the latest git
sources with 20c.  If you can remember, please let me know.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

March snapshot

Raymond Toy — 2012-03-03T17:35:49

The March snapshot has been tagged and binaries will be available shortly.

Only a few minor changes in this update.  See
http://trac.common-lisp.net/cmucl/wiki/WikiStart for the changes.

Ray



_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Carl Shapiro — 2012-02-08T02:25:06

too.

Yes.  The structure assignment of the pending mask back to the ucontext
would copy 32-bytes instead of 8-bytes.

context->uc_sigmask = pending_mask;

I did not correctly recall the root cause.  The problem was a disagreement
over the size of sigset_t between glibc and the kernel.  The glibc
definition is a 32-byte bit set.

http://repo.or.cz/w/glibc.git/blob?f=sysdeps/unix/sysv/linux/bits/sigset.h


Yes, those numbers seem okay.  NSIG is sized correctly.  sigset_t is not.
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Feb snapshot tagged

Raymond Toy — 2012-02-04T16:48:46

The February snapshot has been tagged.  Binaries will be uploaded soon.

The changes for this snapshot are:

o utf-8 built into the core
o a bug in unicode-complete-name has been fixed
o Helmut's blocked signals issue

One other change is that the ppc port has been revived and is up-to-date
with the current sources.  However, only a unicode build is available. 
Many thanks to Robert Smith for making a ppc machine available for this.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Raymond Toy — 2012-02-04T15:33:25

So previously, the code was copying 32 bytes?  That seems like too much too.

NSIG is 65 on an Ubuntu 10 system.  It's also 65 on my OpenSuSE 11.3
system that I normally use to build cmucl.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Carl Shapiro — 2012-02-04T00:47:46

This looks like my fault

http://common-lisp.net/gitweb?p=projects/cmucl/cmucl.git;a=commit;h=342beebbfed6718f0bbc4276f29a18d0f7356ec8

LONG_BIT should have been CHAR_BIT.

I am surprised that the C library NSIG is now 65.  When I made this
change, the C library on the machine I used defined NSIG as 1024 but
the kernel data structure knew it was 64.  For example, compare

http://lxr.linux.no/#linux+v3.2.4/arch/x86/include/asm/signal.h

with

http://fxr.watson.org/fxr/source/sysdeps/unix/sysv/linux/bits/signum.h?v=GLIBC27#L69

Using the wrong definition of NSIG may cause a corruption.
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Raymond Toy — 2012-02-03T17:15:06

For your example with just a simple loop, a C-c causes an interrupt to
happen right away, so things work.  But when GC is running, interrupts are
disabled, so the C-c is remembered and and deferred to a later time and
then handled with a pendingInterrupt trap.  This is the main difference
between the two cases.

I think the problem is in interrupt_handle_pending:

    memcpy(&context->uc_sigmask, &pending_mask, NSIG / LONG_BIT);

We are trying to restore the sigmask that was saved by setup_pending_signal
(that coincidentally copies the entire uc_sigmask to pending_mask).

NSIG = 65 and LONG_BIT = 32 on my machine, so memcpy only copies 2 bytes.
I think we really want to copy at least 64 bits or 8 bytes.  If I modify
this code to copy 8 bytes, SigBlk is now 0 after returning, and C-c
continues to work.

This seems like a very long-standing bug!  Thanks for pointing it out.
This change will get into the Feb snapshot.  I hope you can do some testing
with it and let me know how it works out.

Ray
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Raymond Toy — 2012-02-01T19:47:59

Thanks!  Now I won't forget about it.

Ray
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Helmut Eller — 2012-02-01T18:26:18


Sure. See: http://trac.common-lisp.net/cmucl/ticket/55

Helmut

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Raymond Toy — 2012-02-01T17:20:11


Ok. Can you write up a ticket for this?

I will try sigio with slime again.  That will certainly help motivate me to
make it work better.  (Or frustrate me to switch back to fd-handler. :-( )

Carl has suggested modifying the compiler so that we only take (most)
signals at safe points.  This will certainly help many situations so we can
concentrate on the truly async signals like sigint.  Such safe points will
have some implications on speed, though.  That's for another day (or year).

Ray
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

ELS 2012, Zadar, Croatia

Marco Antoniotti — 2012-02-01T13:11:48

Apologies for the multiple postings. 

PAPER SUBMISSION DEADLINE EXTENDED 


European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 

http://european-lisp-symposium.org 

The purpose of the European Lisp Symposium is to provide a forum for 
the discussion and dissemination of all aspects of design, 
implementation and application of any of the Lisp and Lisp-inspired 
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, 
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We 
encourage everyone interested in Lisp to participate. 


The main theme of the 2012 European Lisp Conference is 
"Interoperability: Systems, Libraries, Workflows".  Lisp based and 
functional-languages based systems have grown a variety of solutions 
to become more and more integrated with the wider world of Information 
and Communication Technologies in current use.  There are several 
dimensions to the scope of the solutions proposed, ranging from 
"embedding" of interpreters in C-based systems, to the development of 
abstractions levels that facilitate the expression of complex context 
dependent tasks, to the construction of exchange formats handling 
libraries, to the construction of theorem-provers for the "Semantic 
Web".  The European Lisp Symposium 2012 solicits the submission of 
papers with this specific theme in mind, alongside the more 
traditional tracks which have appeared in the past editions. 

We invite submissions in the following forms: 

Papers: Technical papers of up to 15 pages that describe original 
results or explain known ideas in new and elegant ways. 

Demonstrations: Abstracts of up to 4 pages for demonstrations of 
tools, libraries, and applications. 

Tutorials: Abstracts of up to 4 pages for in-depth presentations about 
topics of special interest for at least 90 minutes and up to 180 
minutes. 

Lightning talks: Abstracts of up to one page for talks to last for no 
more than 5 minutes. 

All submissions should be formatted following the ACM SIGS guidelines 
and include ACM classification categories and terms. For more 
information on the submission guidelines and the ACM keywords, see: 
http://www.acm.org/sigs/publications/proceedings-templates and 
http://www.acm.org/about/class/1998. 


Important dates: 

February 15th 2012: submission deadline (extended deadline) 
March 7th 2012: acceptance results 

April 30th 2012: Conference opens 


Program Commitee. 
Chair: 
Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY 

Local organizers: 
Damir Cavar, Eastern Michigan University 
Franjo Pehar, University of Zadar 
Damir Kero, University of Zadar 

Members: 
Giuseppe Attardi, Università degli Studi di Pisa, Pisa, ITALY 
Pascal Costanza, Intel, Bruxelles, BELGIUM 
Marc Feeley, Université de Montreal, Montreal, CANADA 
Scott McKay, Google, U.S.A. 
Kent Pitman, U.S.A. 
Christophe Rhodes, Department of Computing, Goldsmiths, University of London, London, UNITED KINGDOM 
Robert Strandh, LABRI, Université de Bordeaux, Bordaux, FRANCE 
Didier Verna, EPITA / LRDE, FRANCE 
Taiichi Yuasa, Kyoto University, JAPAN


--
Marco Antoniotti


_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Helmut Eller — 2012-02-01T08:32:08


The problem doesn't occur with an empty loop.  Therefore I think it has
something to do with GC.


Works good enough for me (on Linux).  The GC should of course be
interrupt-safe.  The stream code is not reentrant so it is problematic
to use streams in signal handlers.  SLIME tries to be careful when
reading/writing to it's own stream and tries to delay interrupts to
safe-points.  SLIME can't fix other streams or non-reentrant code, but
the situation there is IMO the same as if the debugger is invoked with
SIGINT.

Helmut

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: gc & blocked signals

Raymond Toy — 2012-02-01T03:27:24

Yeah, that looks like a bug.  I think the problem is not with gc, but
with the signal handler(s).  I was planning on doing some work on the
signal handlers to make them simpler, based on what Carl did for
Windows.  This should make them simpler and safer.  Don't know if it
will take care of this problem or not.


Does SIGIO actually work for you?  I stopped using it long ago because
it caused strange errors to occur (on darwin).  I think it's because
SIGIO causes interrupts at bad places because cmucl isn't really
interrupt-safe.

Ray

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

gc & blocked signals

Helmut Eller — 2012-01-31T22:03:13

I think there is a problem related to blocked signals and garbage
collection:

1. Start cmucl -noinit -eval '(loop (ext:gc :full t))' 
   in a terminal and let it run.

2. Under Linux,  cat /proc/<pid>/status  shows that SigBlk is 0 i.e. 
   no signals are blocked.

3. Interrupt the loop with C-c (SIGINT) and wait for the debugger.

4. SigBlk is still 0.

5. Type c to continue the loop.

6. SigBlk is now 000000001fc90000

That's a bug, right?  It should again be zero.

The sigmask 000000001fc90000 corresponds to the signals:

 17 SIGCHLD
 20 SIGTSTP
 23 SIGURG
 24 SIGXCPU
 25 SIGXFSZ
 26 SIGVTALRM
 27 SIGPROF
 28 SIGWINCH
 29 SIGIO

SLIME uses SIGIO on a socket and if that stays blocked then SLIME can't
interrupt the Lisp process.  Also note that C-z in the terminal doesn't
stop the process; presumably because SIGTSTP is blocked.  

lisp-implementation-version is "20c release-20c (20C Unicode)".

Helmut

_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: Build failure on gcc-4.6 [resend with other user]

Raymond Toy — 2012-01-17T19:29:53


I don't have gcc 4.6 around anywhere so I can't test this.


A quick grep shows that this is only used for the stack guard zones, and
those functions are called only on x86.  For sparc, the C stack grows down,
but the Lisp control stack grows up, so those routines aren't used.

It looks like ppc never had the stack overflow support, and PA-RISC was
pretty much dead before I even started using cmucl.

So let's just get rid of them and fix up guard_zones to have a fixed
assumption on the stack direction.

Ray
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: Build failure on gcc-4.6 [resend with other user]

Carl Shapiro — 2012-01-17T18:52:06


If you think the call is being optimized away, you can try to add a
"noinline" attribute to limit the optimization.

Aside from the PA-RISC, don't all of the ports have a downward growing
stack?  Maybe it is time to make this a #define instead of using a clever
runtime check.
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Re: Build failure on gcc-4.6 [resend with other user]

Raymond Toy — 2012-01-17T17:52:47

Interesting.  I wonder if os_stack_grows_down_1 were moved to another file
would fix this.

I'll also look around to see if I have gcc 4.6 somewhere on my machines

Thanks for the tip,




Fantastic!

Thanks,

Ray
_______________________________________________
cmucl-imp mailing list
cmucl-imp< at >cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp

Build failure on gcc-4.6 [resend with other user]

Peter Van Eynde — 2012-01-17T07:25:12

Hello all,

If one uses gcc-4.6 to recompile cmucl then the test defined in:

src/lisp/os-common.c: os_stack_grows_down

always returns 0, even on x86/Linux where the correct answer is 1. I'm
guessing that this is due to the added smarts in gcc-4.6.

This causes the resulting lisp binary to segfault on startup, see Debian
bug 483331.

I 'fixed' this by making the function always return 1 as I'm only
concerned about x86/Linux :).

After this major hurdle expect 20c in Debian soonish...

Best regards, Peter