Hello,
I have a multi-threading Java application (like a web server). ABCL is
already added to it but is not used too much. I have a particular need
within that application that I think ABCL would be well suited for, but I
first need to better understand how ABCL functions in a multithreading
environment. What I need is as follows.
I have some Lisp code and data that will be defined both by .lisp files and
from within Java. This code and data will be used by a multi-threading Java
application in a read-only way. However, the Java threads themselves need
to be able to introduce Lisp data that must be unique to each thread and
gets deleted when the thread ends (presumably by the GC).
Is there a way to do this with ABCL?
Thank you!
Blake McBride
Dear all,
Over 10 years ago, SBCL implemented the Package-Local Nicknames (PLNs)
extension. Since then, PLNs have also been adopted by multiple
implementations (ABCL, CCL, ECL, Clasp, Allegro CL and LispWorks) and
are now widely used in many projects.
However, PLNs are still considered experimental, as stated in the SBCL
manual, since there is no formal specification for them, and each
implementation interprets various corner cases differently. While the
need for a specification has been previously discussed, I was unable
to find any publicly accessible draft for one.
Therefore, I have drafted a specification intended to become a CDR
document. I initially wrote this draft about a year ago and have
recently revised it. You can find the latest version here:
https://gleefre.github.io/cdr-package-local-nicknames/index.html.
There are currently nine unresolved standardization issues, each with
at least one proposed resolution. Input on those issues would be
particularly helpful, but any feedback is welcome!
P.S. I am sharing this link across multiple platforms to reach as many
lispers as possible. This includes various mailing lists (Lisp Pro,
CDR-discuss and -devel for various CL implementations); IRC channels
(#commonlisp and implementation-specific ones); the Lisp Discord
server; several Telegram groups; and a post on Reddit. If you have any
suggestions for additional places to share the link, please let me
know.
My apologies to those receiving this message multiple times.
Best regards,
Alexander Fedorov.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
17th European Lisp Symposium
Call for Papers
May 6-7 2024
Federal Computing Center, Vienna, Austria
https://www.european-lisp-symposium.org/2024
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Important Dates
~~~~~~~~~~~~~~~
- Submission deadline: Feb. 25 2024 ** EXTENDED **
- Author notification: Mar. 24 2024
- Final papers due: Apr. 14 2024
- Symposium: May 6-7 2024
Scope
~~~~~
The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and application
of any of the Lisp dialects, including Common Lisp, Scheme, Emacs
Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen,
Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage
everyone interested in Lisp to participate.
The 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
This year, we suggest an emphasis on best practices, approaches,
and technologies for building highly recursive and self-adapting
architectures, in particular for AI, ML, tool integration and
instruction generation, using dynamic programming languages.
Technical Program
~~~~~~~~~~~~~~~~~
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.
* Experience reports: papers of up to 6 pages describing a successful
use of a Lisp dialect and/or analyzing obstacles that have kept it
from working in practice.
* Tutorials: abstracts of up to 4 pages for in-depth presentations
about topics of special interest.
* Demonstrations: abstracts of up to 4 pages for demonstrations of
tools, libraries, and applications.
All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms. Submissions should be uploaded to Easy Chair, at the following
link http://www.easychair.org/conferences/?conf=els2024.
Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.
Programme Chair
~~~~~~~~~~~~~~~
Giuseppe Attardi, University of Pisa, Italy
Organizing Chair
~~~~~~~~~~~~~~~~
Didier Verna, EPITA, France
Programme Committee
~~~~~~~~~~~~~~~~~~~
Ambrose Bonnaire-Sergeant, Untypable LLC
Frederic Peschanski, UPMC/LIP6
Jay McCarthy, UMass Lowell
Jim Newton, EPITA Research Lab
Kai Selgrad, OTH Regensburg
Mark Evenson, not.org
Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux
Robert Smith, HRL Laboratories LLC
Robert P. Goldman, SIFT LLC
Stefan Monnier, Université de Montréal
Local Chair
~~~~~~~~~~~
Philipp Marek, BRZ, Vienna, Austria
Virtualization Team
~~~~~~~~~~~~~~~~~~~
Georgiy Tugai, Configura, Sweden
Michal Herda, Poland
Yukari Hafner, Shirakumo.org, Switzerland
--
Resistance is futile. You will be jazzimilated.
Jazz site: http://www.didierverna.com
Other sites: http://www.didierverna.info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
17th European Lisp Symposium
Call for Papers
May 6-7 2024
Federal Computing Center, Vienna, Austria
https://www.european-lisp-symposium.org/2024
Sponsored by EPITA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Important Dates
~~~~~~~~~~~~~~~
- Submission deadline: Feb. 18 2024
- Author notification: Mar. 24 2024
- Final papers due: Apr. 14 2024
- Symposium: May 6-7 2024
Scope
~~~~~
The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and application
of any of the Lisp dialects, including Common Lisp, Scheme, Emacs
Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen,
Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage
everyone interested in Lisp to participate.
The 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
This year, we suggest an emphasis on best practices, approaches,
and technologies for building highly recursive and self-adapting
architectures, in particular for AI, ML, tool integration and
instruction generation, using dynamic programming languages.
Technical Program
~~~~~~~~~~~~~~~~~
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.
* Experience reports: papers of up to 6 pages describing a successful
use of a Lisp dialect and/or analyzing obstacles that have kept it
from working in practice.
* Tutorials: abstracts of up to 4 pages for in-depth presentations
about topics of special interest.
* Demonstrations: abstracts of up to 4 pages for demonstrations of
tools, libraries, and applications.
All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms. Submissions should be uploaded to Easy Chair, at the following
link http://www.easychair.org/conferences/?conf=els2024.
Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.
Programme Chair
~~~~~~~~~~~~~~~
Giuseppe Attardi, University of Pisa, Italy
Programme Committee
~~~~~~~~~~~~~~~~~~~
Ambrose Bonnaire-Sergeant, Untypable LLC
Frederic Peschanski, UPMC/LIP6
Jay McCarthy, UMass Lowell
Jim Newton, EPITA Research Lab
Kai Selgrad, OTH Regensburg
Mark Evenson, not.org
Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux
Robert Smith, HRL Laboratories LLC
Robert P. Goldman, SIFT LLC
Stefan Monnier, Université de Montréal
Local Chair
~~~~~~~~~~~
Philipp Marek, BRZ, Vienna, Austria
Virtualization Team
~~~~~~~~~~~~~~~~~~~
Georgiy Tugai, Configura, Sweden
Michał Herda, Poland
Yukari Hafner, Shirakumo.org, Switzerland
--
Resistance is futile. You will be jazzimilated.
Jazz site: http://www.didierverna.com
Other sites: http://www.didierverna.info
Hi Mark,
Last night a number of disruptions in cliki.net availability were reported,
a happens regularly lately -- and definitely during the weekly backup.
So I checked the server this morning. The server had a load of 50 (>15 per
cpu); 80% of that was going to Trac, however the access log
trac.common-lisp.net_access.log was silent. Turns out all the traffic was
on abcl.org. It was being spidered like crazy. Trac - or our server setup
(or both) - really isn't up to that task, which is why there is only
limited spidering allowed on trac.common-lisp.net. (Enough to spider
"current" trunk of projects and their issues.)
To restrict spidering, I've changed the robots.txt file at
/project/armedbear/public_html/robots.txt.
Could you please commit that robots.txt (or an even stricter one) to the
repository that the site is being synced from?
Thanks!
Regards,
Erik.
Hi, is there a way to unwrap a Java boxed value to get the Java
primitive value inside it?
In particular I am interested in obtaining the char inside a
Character, in order to supply the char to a method which requires a
char.
Thanks for any info,
Robert
[Attached find Alejandro’s reply for completeness. I need to redo my credentials to the admin dashboard to forward cleanly which is going to take an unknown amount of time]
> Begin forwarded message:
>
> From: armedbear-devel-owner(a)common-lisp.net
> Subject: armedbear-devel(a)common-lisp.net post from ale2014.zamora(a)gmail.com requires approval
> Date: January 3, 2024 at 21:25:42 GMT+1
> To: armedbear-devel-owner(a)common-lisp.net
>
> As list administrator, your authorization is requested for the
> following mailing list posting:
>
> List: armedbear-devel(a)common-lisp.net
> From: ale2014.zamora(a)gmail.com
> Subject: Re: Associating names with characters for named Unicode characters
>
> The message is being held because:
>
> The message is larger than the 40 KB maximum size
>
> At your convenience, visit your dashboard to approve or deny the
> request.
>
> From: Alejandro Zamora Fonseca <ale2014.zamora(a)gmail.com>
> Subject: Re: Associating names with characters for named Unicode characters
> Date: January 3, 2024 at 21:25:21 GMT+1
> To: Robert Dodier <robert.dodier(a)gmail.com>
> Cc: Armed Bear <armedbear-devel(a)common-lisp.net>
>
>
> Hi Robert
>
> Probably not completely related but I made a small library to handle with Unicode details with ABCL https://github.com/alejandrozf/abcl-utils
>
> Maybe that might help you in the association you want to make.
>

>
> Best,
>
> Alejandro
>
> El mié, 3 ene 2024 a las 16:51, Robert Dodier (<robert.dodier(a)gmail.com <mailto:robert.dodier@gmail.com>>) escribió:
>> Hi, I wonder if there is a way to associate a name with a character at
>> run time in ABCL.
>>
>> I am interested in working with Unicode characters which have names,
>> e.g. BOX DRAWINGS LIGHT HORIZONTAL and others listed in the document
>> at: https://www.unicode.org/charts/PDF/U2500.pdf
>>
>> I am thinking it would be great if I could refer to such characters by
>> name, e.g.: #\BOX_DRAWINGS_LIGHT_HORIZONTAL. It appears that such
>> names are not defined in ABCL; I'm looking for a way to define them at
>> run time.
>>
>> >From looking at the source code, maybe it's possible via the
>> setCharName static method in org.armedbear.lisp.LispCharacter.
>> However, when I try to get a reference to setCharName, I get an error:
>>
>> CL-USER(10): (java:jstatic "setCharName" "org.armedbear.lisp.LispCharacter")
>> #<THREAD "interpreter" native {48616CA1}>: Debugger invoked on
>> condition of type ERROR
>> No such static method: org.armedbear.lisp.LispCharacter.setCharName()
>>
>> I thought maybe the problem there is that setCharName isn't declared
>> public, but I tried the same operation with a declared public static
>> method and I get the same error:
>>
>> CL-USER(12): (java:jstatic "getInstance" "org.armedbear.lisp.LispCharacter")
>> #<THREAD "interpreter" native {48616CA1}>: Debugger invoked on
>> condition of type ERROR
>> No such static method: org.armedbear.lisp.LispCharacter.getInstance()
>>
>> so maybe I am not going about that correctly.
>>
>> setCharName modifies the lookup table
>> org.armedbear.lisp.LispCharacter.lispChars -- I'm sure it's not
>> recommended, but maybe I can put new entries into it directly; can
>> someone give me a hint as to the appropriate incantation in Lisp?
>> lispChars is declared public static so it seems like it should be
>> possible, if I can craft the appropriate method call to
>> org.armedbear.lisp.CharHashMap.put.
>>
>> Thanks for any info,
>>
>> Robert
>
>
>
>
>
>
--
"A screaming comes across the sky. It has happened before but there is nothing
to compare to it now."
Alejandro, thanks a lot for your reply.
Is there a way, in abcl-utils, to inform the Lisp reader to recognize
named characters such as #\BOX_DRAWINGS_LIGHT_HORIZONTAL in source
code? That is the ultimate goal I am seeking.
best,
Robert
Hi, I wonder if there is a way to associate a name with a character at
run time in ABCL.
I am interested in working with Unicode characters which have names,
e.g. BOX DRAWINGS LIGHT HORIZONTAL and others listed in the document
at: https://www.unicode.org/charts/PDF/U2500.pdf
I am thinking it would be great if I could refer to such characters by
name, e.g.: #\BOX_DRAWINGS_LIGHT_HORIZONTAL. It appears that such
names are not defined in ABCL; I'm looking for a way to define them at
run time.
From looking at the source code, maybe it's possible via the
setCharName static method in org.armedbear.lisp.LispCharacter.
However, when I try to get a reference to setCharName, I get an error:
CL-USER(10): (java:jstatic "setCharName" "org.armedbear.lisp.LispCharacter")
#<THREAD "interpreter" native {48616CA1}>: Debugger invoked on
condition of type ERROR
No such static method: org.armedbear.lisp.LispCharacter.setCharName()
I thought maybe the problem there is that setCharName isn't declared
public, but I tried the same operation with a declared public static
method and I get the same error:
CL-USER(12): (java:jstatic "getInstance" "org.armedbear.lisp.LispCharacter")
#<THREAD "interpreter" native {48616CA1}>: Debugger invoked on
condition of type ERROR
No such static method: org.armedbear.lisp.LispCharacter.getInstance()
so maybe I am not going about that correctly.
setCharName modifies the lookup table
org.armedbear.lisp.LispCharacter.lispChars -- I'm sure it's not
recommended, but maybe I can put new entries into it directly; can
someone give me a hint as to the appropriate incantation in Lisp?
lispChars is declared public static so it seems like it should be
possible, if I can craft the appropriate method call to
org.armedbear.lisp.CharHashMap.put.
Thanks for any info,
Robert
Hi,
Armed Bear Common Lisp 1.9.3-dev
Java 17.0.9 Debian
OpenJDK 64-Bit Server VM
Low-level initialization completed in 0.151 seconds.
Startup completed in 0.876 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (defvar *s*)
*S*
CL-USER(2): (defun foo () (princ-to-string (progv '(*s*) '(1) (catch 'ct
*s*))))
FOO
CL-USER(3): (compile 'foo)
; Caught ERROR:
; Stack inconsistency detected in <unknown> at index 44: found 3,
expected 1.
; Compilation unit finished
; Caught 1 ERROR condition