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

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

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

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

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

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

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

Linux 8-bit binaries are wrong

Raymond Toy — 2012-01-11T18:01:29

I just noticed that the 8-bit binaries for linux after June 2011 are
wrong.  They're actually the unicode binaries.  The 2012-01 binary is ok.

I'm too lazy to go back and fix those snapshots, but I should probably go
and fix the 20c release though.

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

Happy New Year

Raymond Toy — 2012-01-07T18:46:35

With the start of a new year (where do they all go?), the first snapshot
of 2012 has been tagged.  Binaries will be uploaded soon.

Only a couple of user-visible changes have been added.   Most of the
changes are just code cleanups.

See the release notes for details.

Ray

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

Happy New Year

Raymond Toy — 2012-01-07T18:46:35

With the start of a new year (where do they all go?), the first snapshot
of 2012 has been tagged.  Binaries will be uploaded soon.

Only a couple of user-visible changes have been added.   Most of the
changes are just code cleanups.

See the release notes for details.

Ray

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

Happy New Year

Raymond Toy — 2012-01-07T18:46:35

With the start of a new year (where do they all go?), the first snapshot
of 2012 has been tagged.  Binaries will be uploaded soon.

Only a couple of user-visible changes have been added.   Most of the
changes are just code cleanups.

See the release notes for details.

Ray

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

2011-12 snapshot tagged

Raymond Toy — 2011-12-02T04:59:41

The 2011-12 snapshot has been tagged.  Binaries will be uploaded soon.

The main changes in this snapshot are an update to string-to-octets, an
update to asdf 2.019, and a reordering of the directories.  (An
unfortunate side-effect is that the history of the files didn't follow
the files.  The history is still there, but you have to checkout an old
version to see it.  If someone knows how to fix this, if possible, I'd
appreciate your help.)

Ray

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

A LOAD-TIME-VALUE/MAKE-INSTANCE bug

Nikodemus Siivola — 2011-12-01T11:17:38

[nikodemus< at >delirium:~/tmp]
(defclass c1 ()
  ())

(defun a-c1 ()
  (load-time-value (make-instance 'c1)))

[nikodemus< at >delirium:~/tmp]
; Loading #P"/dev/null".
CMU Common Lisp 20c release-20c (20C Unicode), running on delirium
With core: /usr/local/lib/cmucl/lib/lisp-sse2.core
Dumped on: Thu, 2011-11-03 06:58:17+02:00 on gondor.local
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
    Unicode 1.28 with Unicode version 6.0.0
    Python 1.1, target Intel x86/sse2
    CLOS based on Gerd's PCL 2010/03/19 15:19:03
* (load (compile-file "bug1.lisp"))

; Python version 1.1, VM version Intel x86/sse2 on 2011-12-01 13:14:19.
; Compiling: /Users/nikodemus/tmp/bug1.lisp 2011-12-01 13:13:33

; Compiling Load Time Value of (PCL::ENSURE-CTOR '(PCL::CTOR C1) 'C1 ...):
; Compiling Load Time Value of (MAKE-INSTANCE 'C1):
; Converted A-C1.
; Compiling DEFUN A-C1:
; Byte Compiling Top-Level Form:

; bug1.sse2f written.
; Compilation finished in 0:00:00.

; Loading #P"/Users/nikodemus/tmp/bug1.sse2f".


Error in function PCL::FIND-CLASS-FROM-CELL:  No class named C1.
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [CONTINUE] Return NIL from load of #P"/Users/nikodemus/tmp/bug1.sse2f".
  1: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

(PCL::FIND-CLASS-FROM-CELL C1 NIL T)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:pcl/macros.lisp.
0]

Cheers,

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

Remvoing hppa-assem.s

Raymond Toy — 2011-11-17T21:20:43

I don't know why hppa-assem.s is checked in, but it confuses git on a
case-insenstive file system like HPFS on a Mac.

I'm going to delete this file.  This file is not referenced in any of the
Config files or Makefiles.  I'm guessing it's the preprocessed version of
hppa-assem.S.

(There are probably lots of other files that could be removed, like the
hppa directories, but I'm not going there.)

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

New directory structure

Raymond Toy — 2011-11-04T04:59:48

Currently when you clone cmucl, you get a directory structure like

cmucl/
  BUILDING
  assembly/
  code/
  compiler/
  tools/
  <etc>

I want to change the structure to be

cmucl/
  BUILDING
  bin/
    build.sh
    build-all.sh
    create-target.sh
  src/

This is much convenient when using git.   It might be possible to
rearrange things even more, but I think this is good enough.  I'm tired
of having to cd to src to git diffs and logs and such.  With this
structure, I don't have to anymore.

Ray

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

Release 20c

Raymond Toy — 2011-11-03T04:42:29

Release 20c has been tagged (release-20c).  As an experiment, it's a
signed tag in git.

Binaries will be uploaded soon and the wiki will be updated soon too.

Ray

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

string-to-octets

Helmut Eller — 2011-10-29T11:18:47

I'm wondering how STRING-TO-OCTETS can be used with a fixed sized byte
buffer.  For example we want to write a long string to a byte stream
using a fixed size byte buffer.  STRING-TO-OCTETS seems to return the
buffer and the number of bytes written.  E.g.

(let ((buffer (make-array 20 :element-type '(unsigned-byte 8)))
      (string (make-string 100  :initial-element #\a)))
  (stream:string-to-octets string :external-format :utf32 :buffer buffer))

Returns a new vector (non-eq to buffer) and 404.

Shouldn't one return value also indicate how many characters were
converted so that the conversion can be continued at that character
offset without allocating a fresh buffer?

Helmut

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

Upcoming release

Raymond Toy — 2011-10-22T16:39:56

I noticed that it has been a year since our last release, so it's time
once again for another release.  A new branch has been created
(RELEASE-20c-BRANCH) for the release.

This time, I'm not going to do any pre-release.  We'll make just the one
build due at the end of this month for the 20c release.  If it's broken
for some reason, we'll send a patch if possible.  If it's really broken,
we'll recommend people to use the following snapshot.  (Of course,
because of the release, there will not be a snapshot for Nov.)

Ray

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

October snapshot tagged

Raymond Toy — 2011-10-01T15:28:44

The October snapshot has been tagged "snapshot-2011-10".  (I hope I did
that right with that new-fangled git thing!)

Key changes are:
o Moved repo to git
o Added command line options to control the size of the read-only space,
static space, control stack and binding stack.  The default sizes are
unchanged.

Other changes:  Trac has been integrated with git so that commit
messages are emailed to the appropriate lists, and commits can close
Trac tickets.

Binaries will be uploaded soon.

Ray

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

Labor Day snapshot

Raymond Toy — 2011-09-03T15:11:14

The Sept snapshot has been tagged and binaries will be uploaded soon.

Notable changes in this snapshot:

- ASDF2 updated to version 2.017.
- Improve type propagation for LOAD-TIME-VALUE.
- Getting documentation of a structure via DOCUMENTATION no longer
  signals an error.
- Reduce unnecessary consing of SAPs in ROOM.
- Make stack overflow checking actually work on Mac OS X.  The
  implementation had the :stack-checking feature, but it didn't
  actually prevent stack overflows from crashing lisp.
- Fix rounding of numbers larger than a fixnum.  (This is an ancient
bug, going back to the original CMU sources, I think.)

Ray

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

x86-validate.h

Helmut Eller — 2011-08-27T21:01:53

Is it necessary that we reserve such large areas at startup?

#define READ_ONLY_SPACE_SIZE    (0x0ffff000)/* 256MB - 1 page */
#define STATIC_SPACE_SIZE(0x0ffff000)/* 256MB - 1 page */
#define BINDING_STACK_SIZE(0x07fff000)/* 128MB - 1 page */
#define CONTROL_STACK_SIZE(0x07fff000 - 8192)  (about 128 MB)

Why are read-only and static space so large when a core file is
less than 30MB?  And why do we need such huge stacks?
The default stack limit for a JVM is less than 500KB.

With such settings one needs at least 720MB to start.  That's a problem
unless overcommitting is enabled.

Helmut

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