I'm about to look into Software Transactional Memory techniques for some
financial code I'm involved with. Any advice about which libraries to
look at (and why) would be quite welcome.
Thanks
pt
ILC 2014 - International Lisp Conference
"Lisp on the Move"
August 14-17 2014, Université de Montréal, Montréal, Canada
Sponsored by the Association of Lisp Users
http://www.international-lisp-conference.org
Scope:
Lisp is one of the greatest ideas from computer science and a major
influence for almost all programming languages and for all
sufficiently complex software applications.
The International Lisp Conference is a forum for the discussion of
Lisp and, in particular, the design, implementation and application of
any of the Lisp dialects. We encourage everyone interested in Lisp to
participate.
We invite high quality submissions in all areas involving Lisp
dialects and any other languages in the Lisp family, including, but
not limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript,
Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc.
This year's focus will be directed towards integrated solutions,
including mobile computing. We especially invite submissions in the
following areas:
* Pervasive computing
* Interoperability
* Portability
* Implementation challenges/tradeoffs for embedded/mobile platforms
* Language support for mobile toolkits and frameworks
* Language support for distribution
* Language support for reliability, availability, and serviceability
* Mobile IDEs
* Mobile applications
Contributions are also welcome in other areas, including but not
limited to:
* Language design and implementation
* Language integration, inter-operation and deployment
* Applications (especially commercial)
* Reflection, meta-object protocols, meta-programming
* Domain-specific languages
* Programming paradigms and environments
* Efficient parallel and concurrent computation
* Language support for managing both manual and automatic GC
* Theorem proving
* Scientific computing
* Data mining
* Semantic web
Technical Programme:
Original submissions in all areas related to the conference themes are
invited for the following categories:
Papers: Technical papers of up to 10 pages that describe original
results.
Demonstrations: Abstracts of up to 2 pages for demonstrations of
tools, libraries and applications.
Workshops: Abstracts of up to 2 pages for groups of people who intend
to work on a focused topic for half a day.
Tutorials: Abstracts of up to 2 pages for in-depth presentations about
topics of special interest for 1 to 2 hours.
Panel discussions: Abstracts of up to 2 pages for discussions about
current themes. Panel discussion proposals must mention panel member
who are willing to partake in a discussion.
The conference will also provide slots for lightning talks, to be
registered on-site every day.
For inquiries about any other kind of participation (commercial
exhibits, advertising, prizes, book signing etc.), please see the
contacts below.
Important Dates:
- May 18, 2014: Submission deadline
- June 09, 2014: Notification of acceptance
- June 29, 2014: Final Papers due
- August 14, 2014: Conference
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.
Submissions should be uploaded to Easy Chair, at the following
address: https://www.easychair.org/conferences/?conf=ilc14
Organizing Committee:
General Chair: Marc Feeley (Université de Montréal, Montréal, Canada)
Programme Chair: Didier Verna (EPITA Research lab, Paris, France)
Local chair: Marc Feeley (Université de Montréal, Montréal, Canada)
Programme Committee:
to be announced
Contacts:
* General Questions: ilc14-organizing-committee at alu.org
* Programme Committee: ilc14 at easychair.org
For more information, see http://www.international-lisp-conference.org
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
ELS'14 - 7th European Lisp Symposium
IRCAM, Paris, France
May 5-6, 2014
http://www.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, Hop and so on. We
encourage everyone interested in Lisp to participate.
The 7th European Lisp Symposium invites high quality papers about
novel research results, insights and lessons learned from practical
applications, and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.
Topics include but are not limited to:
- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
- Educational approaches and perspectives
- Experience reports and case studies
Please note that IRCAM, the conference venue, is a French institute
for research on music and acoustics. Submissions relating Lisp to
music or other acoustical matters will hence be particularly welcome,
although given no heightened favor during the review process.
We invite submissions in the following forms:
Papers: Technical papers of up to 8 pages that describe original
results or explain known ideas in new and elegant ways.
Demonstrations: Abstracts of up to 2 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.
The symposium will also provide slots for lightning talks, to be
registered on-site every day.
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:
- TODAY: Mark your calendar. Start planning now!
- 09 Mar 2014: Submission deadline
- 31 Mar 2014: Notification of acceptance
- 21 Apr 2014: Final Papers due
- 05 May 2014: Symposium. Join us there!
Program Committee:
Chair:
Kent Pitman, Hypermeta Inc., U.S.A.
Local Organizers:
Didier Verna, EPITA Research Lab, France
Gérard Assayag, IRCAM, France
Members:
To be announced later
Search Keywords:
#els2014, ELS 2014, ELS '14, European Lisp Symposium 2014,
European Lisp Symposium '14, 7th ELS, 7th European Lisp Symposium,
European Lisp Conference 2014, European Lisp Conference '14
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
Hi,
Meta-question: Where does this mailing list have a webpage that can be referred to, and that explains how to subscribe / unsubscribe?
Thanks, and sorry if this is a too-obvious question,
Pascal
--
Pascal Costanza
In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp).
Yes, it's in the keyword package. Why?
Because it's the one and only macro I want to be accessible from everywhere
without a prefix, yet without modifying existing defpackage forms to make
it accessible — because it's only used temporarily for debugging.
:DBG is a macro for print-debugging. The syntax is
(:DBG tag forms... last-form)
The semantics is that if tag is true, print the tag, then for each
form, write its source and its values; return the values of the last
form. If tag is false, just evaluate the last form and return its
values. (Tag is typically a constant keyword or string, identifying
the point where values are printed.)
The expansion is rather space and time efficient, as far as the
semantics permit.
I find :DBG soooo useful for print-debugging. I've seen tens of
variants of it, but every time with something not quite right in the
syntax, semantics or implementation. I just wanted one variant that
got everything right, and make it ubiquitous. Because when you need
it, you need it now, and there's no time to modify things to load an
additional library. And when you're done, you want minimal cleanup,
too: just delete the form, except maybe keep the last subform.
Previously, I was using (uiop:uiop-debug) from uiop/utility which
allows you to load a magic file of your choice that defines a debug
mode. The default one I provided was mine, which define :DBG as DBG in
your current package (thereby avoiding symbol import issues). But that
still adds a new definition everytime and an extra line or form to
cleanup.
I was recently convinced that using the keyword package instead makes
perfect sense: on the one hand, that's using a shared namespace that
it is polite to not pollute, but on the other hand, such a temporary
print-debugging macro the only use case I imagine of otherwise wanting
something to be immediately accessible without package prefixing yet
without modifying the package definition form.
It's still time to remove that macro before the next release, but I
believe it's the right thing to include it, and maybe some of you will
agree with me and start using it, if not from the yet unrelease ASDF
3.1.1, perhaps from a copy in your .sbclrc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken
Hi,
I have moved the hosting of the Closer projects (MOP Feature Tests, Closer to MOP, ContextL, Filtered Functions, AspectL, LW Compat) to sourceforge. I also switched from darcs hosting to git hosting.
You can find the software now at http://sourceforge.net/p/closer/_list/git
All libraries have received new version numbers based on semantic versioning.
The mailing lists will from now on also be hosted at sourceforge. Please subscribe to the mailing lists at http://sourceforge.net/p/closer/mailman/ if you are interested.
The information on the Closer webpage at http://common-lisp.net/project/closer/ has also been updated accordingly.
Please let me know if you have any questions or problems.
Pascal
--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.
Hi
in case some of you wants to try yet another^n HTML Common Lisp Documentation Generation system, you can have a look at my blog post here:
http://within-parens.blogspot.com/2013/11/with-little-he.html
It still has a few rough edges but (AFAICT) it works.
Cheers
--
Marco
I wish to resign from my activities as the main maintainer of the Common Lisp Document Repository (CDR - http://cdr.europlisp.org). Although Arthur Lemmens, Edi Weitz, and Marc Battyani have supported the effort throughout CDR's existence, for which I'm very grateful, the main work rested on my shoulders.
CDR had some noticeable impact in the seven years of its existence, but it may benefit from some new ideas and a fresh perspective. Since Arthur, Edi, and/or Marc do not want to take over the day-to-day activities for maintaining CDR, this effectively means that we are looking for volunteers to take over its maintenance.
I would like to ensure that CDR doesn't become unmaintained, so I will keep on running things for as long as necessary.
Feel free to ask any questions, either publicly, or privately to me directly, or via editors(a)cdr.eurolisp.org.
Thanks,
Pascal
--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.
Hello,
yesterday, I fell on something extremely weird, or at least, which I
currently fail to understand. Basically, after a (defvar *var*), there
are times when (setq *var* '(0 0)) doesn't work (the previous value of
*var* remains in effect).
I cannot currently provide a minimal example because the situation
involves several levels of nested macro / function calls in code I
didn't write (*var* is solely mine though).
At first, I thought I had fallen on a compiler bug, but I get the same
behavior with at least 3 lisp implementations.
I ultimately found a workaround, consisting in using (list 0 0) instead
of '(0 0) in the assignment. I'm hoping this would be a clue to someone
here to get at least a direction for investigating...
Thanks.
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info