FYI.
---------- Forwarded message ----------
From: Didier Verna <didier(a)lrde.epita.fr>
Date: Wed, Mar 17, 2010 at 2:25 PM
Subject: [Openmcl-devel] [2nd CfP] 7th European Lisp Workshop at
ECOOP'10, June 21/22
To: Open MCL Development <openmcl-devel(a)clozure.com>
+------------------------------------------------------------+
| 2ND CALL FOR PAPERS |
| 7th European Lisp Workshop |
| June 21/22, Maribor, Slovenia - co-located with ECOOP 2010 |
+------------------------------------------------------------+
News
====
Our invited speaker, Manuel Serrano, will talk about "diffuse programming"
and HOP. The abstract of his presentation can be found on the website at:
http://european-lisp-workshop.org/upcoming/programme.php
Important Dates
===============
Submission deadline: April 19, 2010
Notification of acceptance: May 05, 2010
ECOOP early registration deadline: May 10, 2010
7th European Lisp Workshop: June 21 or 22, 2010 (tbdl)
Please note that registration must be done with ECOOP itself.
For more information visit http://www.european-lisp-workshop.org
Contact: Didier Verna, didier(a)lrde.epita.fr
Invited Speaker
===============
Manuel Serrano (INRIA, France)
http://www-sop.inria.fr/members/Manuel.Serrano/
Overview
========
"...Please don't assume Lisp is only useful for Animation and
Graphics, AI, Bio-informatics, B2B and E-Commerce, Data Mining,
EDA/Semiconductor applications, Expert Systems, Finance, Intelligent
Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation,
Natural Language, Optimization, Research, Risk Analysis, Scheduling,
Telecom, and Web Authoring just because these are the only things they
happened to list."
-- Kent Pitman
Lisp, one of the eldest computer languages still in use today, is
gaining momentum again. The structure of Lisp makes it easy to extend
the language or even to implement entirely new dialects without
starting from scratch, making it the ideal candidate for writing
Domain Specific Languages. Common Lisp, with the Common Lisp Object
System (CLOS), was the first object-oriented programming language to
receive an ANSI standard and remains the most complete and advanced
object system of any programming language, while influencing many
other object-oriented programming languages that followed.
This workshop will address the near-future role of Lisp-based
languages in research, industry and education. We solicit
contributions that discuss the opportunities Lisp provides to capture
and enhance the possibilities in software engineering. We want to
promote lively discussion between researchers proposing new approaches
and practitioners reporting on their experience with the strengths and
limitations of current Lisp technologies.
The workshop will have two components: there will be formal talks, and
interactive turorial/demo/coding sessions.
Papers
======
Formal presentations in the workshop should take between 20 minutes
and half an hour; additional time will be given for questions and
answers. Suggested topics include (but are not limited to):
- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Protocol meta-programming and libraries
- New language features and abstractions
- Software evolution
- Development aids
- Persistent systems
- Dynamic optimization
- Implementation techniques
- Hardware Support
- Efficiency, distribution and parallel programming
- Educational approaches and perspectives
- Experience reports and case studies
Interactive Tutorial/Demo/Coding Sessions
=========================================
Additionally, we invite less formal talks in the form of interactive
tutorial/demo/coding sessions. The purpose of these sessions is both
to demonstrate and receive feedback on any interesting Lisp system,
either stable or under development. Being less formal than technical
paper presentations, these sessions are expected to be highly
interactive.
Submission Guidelines
=====================
Potential contributors are encouraged to submit:
- a long paper (around 10 pages) presenting scientific and/or
empirical results about Lisp-based uses or new approaches for
software engineering purposes,
- a short essay (5 pages) defending a position about where
research, practice or education based on Lisp should be heading in
the near future,
- a proposal for an interactive tutorial/demo/coding session (1-2
pages) describing the involved library or application, and the
subject of the session.
Papers (both long and short) should be formatted following the ACM SIGS
guidelines and include ACM classification categories and terms (see below).
Authors will later be required to sign an ACM copyright form, as the workshop
proceedings will be published in the ACM Digital Library.
For more information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templateshttp://www.acm.org/about/class/1998
Submissions should be uploaded to Easy Chair, at the following address:
http://www.easychair.org/conferences/?conf=elw2010
Organizers
==========
Didier Verna, EPITA Research and Development Laboratory, Paris
Charlotte Herzeel, Programming Technology Lab, Vrije Universiteit, Brussel
Robert Strandh, LaBRI, University of Bordeaux 1, France
Christophe Rhodes, Goldsmiths College, University of London
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
Openmcl-devel mailing list
Openmcl-devel(a)clozure.com
http://clozure.com/mailman/listinfo/openmcl-devel
Some quick notes on status of 0.19 for release where I see things.
1. [r12550][1] should probably be backported if anything.
[1]: http://trac.common-lisp.net/armedbear/changeset/12550
2. [r12549][2] is probably mostly just cosmetic, but brings up
questions of how well the Pathname use of :UNSPECIFIC should be.
[2]: http://trac.common-lisp.net/armedbear/changeset/12549
3. I'm still unhappy about the state of the Pathname support, but its a
goal that should be postponed until 0.20, as the current implementation
is no worse that what shipped in 0.18.1. Most notably, I think I really
need to a) support URLs as Pathnames and b) allow all Pathnames to be
arguments of OPEN which probably means subclassing Stream.java. And
this is a whole lot of work, so postpone.
4. Disturbingly, I uncovered a [compiler stack inconsistency error][3]
today in working on ASDF. I checked that this was *NOT* induced by the
recent PROGV fix, and exists at least as far back at 0.18.1. So, it
should not affect the decision to release unless we feel we should fix
it before release.
[3]: http://trac.common-lisp.net/armedbear/ticket/89
So, if we're in a "lets get this thing out the door", just release
what's on 0.19 (after updating the README).
If you want to backport [r12550], I think it should not affect any of
the existing test results, but they should be re-run just to make sure.
I probably won't have such time until tomorrow (Wednesday).
--
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
> Attached is a (trivial) patch so that 'run-tests.sh' actually uses the flags
> argument.
Thanks. It was applied, and many small bugs were fixed in ASDF 1.647
as I did more testing and improved the test infrastructure.
> ABCL now passes the ASDF test suite:
>
> -#---------------------------------------
> Using abcl --noinit
> Ran 21 tests:
> 21 passing and 0 failing
> all tests apparently successful
> -#---------------------------------------
>
Yay!
> After discussion on IRC and further thought, I no longer advocate that ASDF2
> not make the relocating the FASLs the default. There are certainly decent
> arguments for it, and we do want progress in ASDF2, right? Instead, I would
> advise that you make a section in the (really excellent looking) manual that
> explicates the changes that an ASDF1 user—both with and without using
> ASDF-BINARY-LOCATIONS—should expect in ASDF2. And I would include the
> *LOAD-TRUENAME*/*LOAD-PATHNAME* issue (i.e. use a conditionalized
> ASDF:SYSTEM-DEFINITION-PATHNAME invocation) in that section.
>
Yes. We need a FAQ section for migration from ASDF1 to ASDF2,
with questions each in its own subsection, and a rationale for each change.
Sigh.
> Otherwise, ASDF2 looks quite cool. What's your timeframe for an official
> release? I'd include it as-is in ABCL, but don't want to chase all the
> release candidates to ASDF2.
>
Hopefully we'd like to release ASDF2 before summer.
I suggest that at some point (e.g. now) you pick one of the release
candidates that you consider not too broken after testing,
then upgrade to the real ASDF2 release when it's out,
and otherwise only upgrade when there's a good reason to
(i.e. fixing major brokenness, or adding major feature,
or there's been a stable version for 6 months
that you haven't upgraded to yet).
Thanks a lot for your support!
And don't forget to implement the long DEFINE-METHOD-COMBINATION :)
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
What a lot of trouble to prove in political economy that two and two make four;
and if you succeed in doing so, people cry, 'It is so clear that it is boring.'
Then they vote as if you had never proved anything at all.
— Frederic Bastiat, "What Is Seen and What is Not Seen", 1850
In ASDF 1.636, I removed the dreaded DEFINE-METHOD-COMBINATION that
has made ASDF hard to port to ABCL.
Can someone in the ABCL team check whether the latest ABCL works with ASDF?
Can you contribute a patch to run-tests.sh so it will run with ABCL?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Nothing is particularly hard if you divide it into small jobs. — Henry Ford
Am I right to observe that abcl coerces any number > fixnum size to bigint?
I'm having trouble calling a java method that takes a long. I seem to
have worked around it calling the method with (new 'long
"9223372036854775807") rather than 9223372036854775807 .
Is this the desired behavior?
-Alan
Is there a way to suppress the startup banner:
Armed Bear Common Lisp 0.20.0-dev
Java 1.5.0_19 Apple Inc.
Java HotSpot(TM) Client VM
Low-level initialization completed in 0.374 seconds.
Startup completed in 0.912 seconds.
?
Thanks,
Alan
java -cp ~/Desktop/test.jar org.armedbear.lisp.Main --noinit -a -b -c -d
Armed Bear Common Lisp 0.20.0-dev
Java 1.5.0_19 Apple Inc.
Java HotSpot(TM) Client VM
Low-level initialization completed in 0.364 seconds.
Startup completed in 0.893 seconds.
lType ":help" for a list of available commands.
CL-USER(1): *command-line-argument-list*
("-d" "-c" "-b" "-a")
The mail below was induced by the "automatic ticket annotator" from
Trac. While I installed it many moons ago, I was under the impression
it wasn't working. Nothing like that was the case: I just didn't get
it enough.
See http://trac.edgewall.org/browser/branches/0.11-stable/contrib/trac-post-com…
on how you can annotate or close tickets from your commit message.
Bye,
Erik.
On Sat, Mar 13, 2010 at 8:05 PM, armedbear
<armedbear-devel(a)common-lisp.net> wrote:
> #38: CLOS :metaclass support
> -------------------------+--------------------------------------------------
> Reporter: ehuelsmann | Owner: ehuelsmann
> Type: defect | Status: accepted
> Priority: major | Milestone: 0.20
> Component: other | Version:
> Resolution: | Keywords:
> -------------------------+--------------------------------------------------
>
> Comment(by ehuelsmann):
>
> (In [12527]) Make all class accessor functions generic functions instead
> of normal ones, to support METACLASS. Additionally, make
> it possible to store general objects in Layout.lispClass.
> Because classes may be of a different Java type than
> StandardClass, fall back to the generic functions to access
> the required fields from Java.
>
> See #38.
>
> --
> Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/38#comment:2>
> armedbear <http://common-lisp.net/project/armedbear>
> armedbear
> _______________________________________________
> armedbear-ticket mailing list
> armedbear-ticket(a)common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket
>