headers
Arthur Lemmens | 10 Jan 2008 22:34
Picon
Picon
Favicon

Announcement: European Common Lisp Meeting, Amsterdam, April 19/20, 2008

[Sorry if you receive this announcement more than once.]

Arthur Lemmens and Edi Weitz are proud to announce the European Common
Lisp Meeting 2008.  The meeting will consist of a Sunday full of talks
on April 20, 2008, with optional dinners on Saturday and Sunday
evening.

For a list of speakers and more information please visit

    http://weitz.de/eclm2008/

We're looking forward to meeting you in Amsterdam,

Arthur Lemmens & Edi Weitz
Permalink | Reply | 0 comments |
headers
Tobias C. Rittweiler | 12 Jan 2008 22:13
Picon

[Possible BUG]: Iteration variables are specified to be always used.


The CLHS entry for IGNORE[1] says

  The stream variables established by with-open-file, with-open-stream,
  with-input-from-string, and with-output-to-string, and all /iteration
  variables/ are, by definition, always ``used''. Using (declare (ignore
  v)), for such a variable v has unspecified consequences.

And an /iteration variable/ is a binding established by one of

  do              do-external-symbols  dotimes  
  do*             do-symbols           loop     
  do-all-symbols  dolist                        

All implementations, that I've tested, got this at least partially
wrong, although I've not tested on all implementations that I've sent
this mail to. (Kudos to the implementation that get this totally right!)

There's even a whole issue write up about this [2] where the following
test case was adapted from:

  (DEFUN COMPILER-WARNINGS-P (BODIES &OPTIONAL (FLAG NIL))
    (MAPCAR #'(LAMBDA (BODY)
		(FLET ((TRY (BODY)
			 (LET ((WARNING 
				(WITH-OUTPUT-TO-STRING (*ERROR-OUTPUT*)
				  (COMPILE NIL `(LAMBDA , <at> BODY)))))
			   (IF FLAG WARNING (> (LENGTH WARNING) 0)))))
		  (LIST (TRY BODY)
			(TRY (LIST (CAR BODY)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrice Seyed | 14 Jan 2008 01:05
Favicon

:lisp-heap-size allocation with build-lisp-image

The documentation indicates
(http://www.franz.com/support/documentation/8.1/doc/building-images.htm):
'The (lisp heap size) value for an image is printed by (room t) output
(as resrve). '

With an output like:
Root pages: 62
 Lisp heap:  #x71000000  pos: #x71bc0000 resrve: #x9ff00000
 C heap:     #xa0000000  pos: #xa0010000 resrve: #xa00fa000
 Pure space: #xf89e8000  end: #xf9029558

Is #x9ff00000 the size of the lisp heap size? Is this a hex value
after subtracting '#x'?
If not, how is this translated into bytes?

I created two images with 'build-lisp-image' function, with one with
:lisp-heap-size of "1000m" and the other "2000m" on a 64-bit linux
system with 8gb of memory. Still the 'rsrve' value for Lisp heap is
the same, why? Does this have to do with providing :lisp-heap-start
and a beginning memory address?

Any comments/references, etc appreciated.
Patrice
Permalink | Reply | 0 comments |
headers
Luis Oliveira | 30 Jan 2008 01:36
Picon
Gravatar

Question named-readtables

Hello,

I have a quick question about Allegro's named-readtable facility. What
is the rationale for restricting the names to keywords? It seems to me
that using symbols would help avoid naming conflicts between similarly
named readtables from multiple codebases.

Thanks in advance,

--

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Permalink | Reply | 3 comments |

Gmane