Hi ABCL-ers :)
I just sent a PR https://github.com/armedbear/abcl/pull/635 that allows to
optionally define different UIs for the visualize and control stepping
process of abcl-stepper.
I also made an initial implementation to be used as a guide for more UI if
someone else is interested
https://gitlab.com/cl-projects/abcl-visual-stepper. This version uses HTMX
<http://htmx.org> and websockets.
The UI is not quite beautiful and it is still a work in progress allowing
syntax highlighting in the browser and other little niceties to the stepper
user. Probably someone with more UI/UX experience can make a better UI and
can do it by using the generic functions defined in the stepper code and
defining his own protocol.
I believe this idea could be also generalized for other components of the
system (inspector, debugger, REPL, etc)
Any feedback is appreciated,
Thanks
Alejandro
Hi!
Sorry if this question sounds trivial (likely it is) but how can I
verify the packages downloaded on the ABCL website?
I am able to download the signature file (*.asc) but I do not know how
to find the public key to match the signature.
----------------
$ gpg --verify abcl-bin-1.9.2.tar.gz.asc
gpg: assuming signed data in 'abcl-bin-1.9.2.tar.gz'
gpg: Signature made Wed Jun 21 10:01:48 2023 CEST
gpg: using DSA key 5491D207FF9ECDE0BEA277772A9641104DB1773D
[...]
gpg: Can't check signature: No public key
---------------- ^^^^^^^^^^^^^
Thanks in advance!
C.
In SBCL and Allegro, it's possible for UIOP to create a pathname for a
file whose name is "*" and then we can find a file with such a(n odd)
pathname.
On ABCL, though, this gives me an error:
(truename (ensure-pathname "*"))
```
(truename (uiop:ensure-pathname "*"))
#<THREAD "interpreter" native {21C91F12}>: Debugger invoked on condition
of type FILE-ERROR
Cannot find the TRUENAME for a wild pathname.
```
But actually, I don't think this *is* a wild pathname:
```
CL-USER(4): (describe (uiop:ensure-pathname "*"))
#P"*" is an object of type PATHNAME:
HOST NIL
DEVICE NIL
DIRECTORY NIL
NAME "*"
TYPE :UNSPECIFIC
VERSION NIL
```
*this* is a wild pathname:
```
CL-USER(5): (describe (parse-namestring "*"))
#P"*" is an object of type PATHNAME:
HOST NIL
DEVICE NIL
DIRECTORY NIL
NAME :WILD
TYPE NIL
VERSION NIL
```
Is this an ABCL bug, since it means ABCL cannot address a file whose
name is "*"?
The interested may refer to [this ASDF
issue](https://gitlab.common-lisp.net/asdf/asdf/-/issues/140) and the
corresponding merge request.
Thanks!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ABCL 1.9.2 FOR MIDSUMMER'S EVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
On the threshold of the Northern Hemisphere's Midsummer's Eve, we unveil
the second revision of the Tenth Edition of the Armed Bear Common Lisp
implementation, viz. abcl-1.9.2.
Most notably, we are pleased to present the fruits of Alejandro Zamora
Fonseca's labors on an interpreted implementation of CL:STEP with the
first release of the ABCL-STEPPER contrib. See
<https://abcl.org/svn/tags/1.9.2/contrib/abcl-stepper/README.markdown>
for more details. This implementation was the subject of his
demonstration <https://zenodo.org/record/7815887> as this year's
European Lisp Symposium.
The POSIX-SYSCALLS contrib now provides the ability to set environment
variables under UNIX systems <https://abcl.org/trac/changeset/15700>, as
well as providing an example of how best to add abstract additional
functionality to the core implementation.
This release also features a substantially re-worked Gray Stream
implementation which fixes enough our implementation to be a first class
citizen of SLIME's usage. With the next release of SLIME, one will have
to use abcl-1.9.2 in order to use the slime-repl. See
<https://github.com/slime/slime/pull/765> for more details.
The ASDF-JAR contrib has been restored to a usable functionality, which
includes re-packaging of ASDF systems from within jar files as well as
better abstraction for finding non-source artifacts. Please refer to
<https://gitlab.common-lisp.net/abcl/abcl/-/blob/master/contrib/asdf-jar/REA…>
for a refresher on what facilities ASDF-JAR provides for the aspiring
ASDF packager.
A complete list of changes may be viewed at
<https://abcl.org/svn/tags/1.9.2/CHANGES>.
The release itself is available at <https://abcl.org/releases/1.9.2/>.
--
"A screaming comes across the sky. It has happened before but there is nothing
to compare to it now."
Hi,
I've been away from ABCL for some time, so I ask your indulgence in case
I'm revisiting a familiar issue. I tried (SETF (UIOP:GETENV "foo")
"value") and got
Not (currently) implemented on ABCL: (SETF UIOP/OS:GETENV)
On investigation, I see that the JVM doesn't normally support setting
environment variables, but there are known ways to jimmy it into doing so:
https://stackoverflow.com/questions/318239/how-do-i-set-environment-variabl…
Would a PR to add such a hack to ABCL be welcome, or should I just make it
a local mod? Or is there another, recommended way of doing this?
-- Scott
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
16th European Lisp Symposium
In-Cooperation-With: ACM SIGLAN
Call for Participation
April 24-25, 2023
Startup Village, Amsterdam, Nederlands
https://www.european-lisp-symposium.org/2023
Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Recent News
~~~~~~~~~~~
Registrer now. Early bird discount closing soon!
Keynote details now available.
Important Dates
~~~~~~~~~~~~~~~
- Final papers due: April 9, 2023
- Early registration deadline: April 9, 2023
- Symposium: April 24-25, 2023
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
Keynotes
~~~~~~~~
##### Artificial Intelligence: a Problem of Plumbing?
-- Gerald J. Sussman, MIT CSAIL, USA
We have made amazing progress in the construction and deployment of
systems that do work originally thought to require human-like
intelligence. On the symbolic side we have world-champion
Chess-playing and Go-playing systems. We have deductive systems and
algebraic manipulation systems that exceed the capabilities of human
mathematicians. We are now observing the rise of connectionist
mechanisms that appear to see and hear pretty well, and chatbots that
appear to have some impressive linguistic ability. But there is a
serious problem. The mechanisms that can distinguish pictures of cats
from pictures of dogs have no idea what a cat or a dog is. The
chatbots have no idea what they are talking about. The algebraic
systems do not understand anything about the real physical world. And
no deontic logic system has any idea about feelings and morality.
So what is the problem? We generally do not know how to combine
systems so that a system that knows how to solve problems of class A
and another system that knows how to solve problems of class B can be
combined to solve not just problems of class A or class B but can
solve problems that require both skills that are needed for problems
of class A and skills that are needed for problems of class B.
Perhaps this is partly a problem of plumbing. We do not have
linguistic structures that facilitate discovering and building
combinations. This is a fundamental challenge for the
programming-language community. We need appropriate ideas for abstract
plumbing fittings that enable this kind of cooperation among disparate
mechanisms. For example, why is the amazingly powerful tree
exploration mechanism that is used for games not also available, in
the same system, to a deductive engine that is being applied to a
social interaction problem?
I will attempt to elucidate this problem and perhaps point at avenues
of attack that we may work on together.
##### Hedy: Gradual, Multi-Lingual, and Teacher-Centric Programming Education
-- Felienne Hermans, Vrije Universiteit Amsterdam, Nederlands
When kids learn to program they often use either a visual language
like Scratch, or a textual language like Python. While visual
languages are great for the first steps, children and educators often
want to move on to textual languages. However, early on, a textual
language and its error messages can be scary. Hedy aims to bridge this
gap with a programming language that is gradual, using different
language levels.
In level 1, there is hardly any syntax at all; printing is done with:
print hello!
At every level, new syntax and concepts are added, so learners do not
have to master everything at once. Hedy builds up to a subset of
Python including conditions, loops, variables, and lists.
To make learning as accessible as possible, Hedy also allows for the
use of localized keywords, f.e in Spanish: imprimir Hello! Hedy
(www.hedy.org) was launched in early 2020 and over 5 million Hedy
progams have been created to date, and has been translated into 46
languages.
##### A Language-Based Approach to Programming with Serialized Data
-- Michael Vollmer, School of Computing, University of Kent, UK
It is common for software running today to use object representations
fixed by the language runtime system; both the Java and Haskell
runtimes dictate an object layout, and the compiler must stick to it
for all programs. And yet when humans optimize a program, one of their
primary levers on performance is changing data representation. For
example, an HPC programmer knows how to pack a regular tree into a
byte array for more efficient access. Unfortunately, this is
error-prone, making it an undesirable way to achieve performance
optimization at the expense of safety and readability.
Furthermore, whenever a program receives data from the network or
disk, rigid insistence on a particular heap layout causes an impedance
mismatch we know as deserialization. Data represented in memory has
pointers and arbitrary, sparse layout, while data on disk is packed
contiguously, so data must be transformed from one form to another and
back.
Programming with serialized data is a technique for unifying the
in-memory and on-disk representations of data, where the serialized
form is used both on-disk and in-memory. This technique allows data
processing programs to skip the deserialization/reserialization steps
by operating directly on the data in its serialized form. It also
represents a principled approach to optimizing programs by compacting
data representations, which increases locality and minimizes
indirection.
In this talk, I will present a programming language, LoCal, for
programming with serialized data. I will also describe Gibbon, an
experimental compiler that automatically transforms functional
programs to operate on serialized data.
##### Run-Time Verification of Communication Protocols in Clojure
-- Sung-Shik Jongmans, Open Universiteit, Nederlands
To simplify shared-memory concurrent programming, languages have
started to offer core support for high-level communications
primitives, in the form of message passing though channels, in
addition to lower-level synchronization primitives. Yet, a growing
body of evidence suggests that channel-based programming abstractions
also have their issues.
The Discourje project aims to help programmers cope with channels and
concurrency bugs in Clojure programs, based on dynamic analysis. The
idea is that programmers write not only implementations of
communication protocols in their Clojure programs, but also
specifications. Discourje then offers a run-time verification library
to ensure that channel actions in implementations are safe relative to
specifications.
Programme Chair
~~~~~~~~~~~~~~~
Stefan Monnier, DIRO, Université de Montréal, Canada
Programme Committee
~~~~~~~~~~~~~~~~~~~
Mark Evenson, not.org, Austria
Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
Ioanna Dimitriou, Igalia S.L., Germany
Robert Smith, HRL Laboratories
Mattias Engdegård
Marc Feeley, Université de Montréal, Canada
Marc Battyani, FractalConcept
Alan Ruttenberg, National Center for Ontological Research, USA
Nick Levine, RavenPack, Spain
Ludovic Courtès, Inria, France
Matthew Flatt, University of Utah, USA
Irène Durand, Université Bordeaux 1, France
Jay McCarthy, Brigham Young University, USA
Ambrose Bonnaire-Sergeant, Cisco
Christopher League, Long Island University, NY, USA
Pascal Costanza, Intel, Belgium
Christian Queinnec
Local Chair
~~~~~~~~~~~
Breanndán Ó Nualláin, Machine Learning Programs, Nederlands
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
Dear ABCL maintainers,
I am a maintainer for the Homebrew package manager. Recently we noticed that the
checksum of ABCL 1.9.1’s source tarball, downloaded from
https://abcl.org/releases/1.9.1/abcl-src-1.9.1.tar.gz, has changed from
9dc2fb0886e97be1906e6d0a96671ef9d0f52b9f91817e4c64741cd18bf8e0d1
(as of 2023-02-20 10:19 UTC) to
a5bc677c9441f4a833c20a541bddd16fff9264846691de9a1daf6699f8ff11e2. May I confirm
if the source tarball was updated? Thanks!
Regards,
Ruoyu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
16th European Lisp Symposium
In-Cooperation-With: ACM SIGLAN
Call for Participation
April 24-25, 2023
Startup Village, Amsterdam, Nederlands
https://www.european-lisp-symposium.org/2023
Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Recent News
~~~~~~~~~~~
Registrations are now open (early bird deadline: April 9)
Keynote speakers announced (see below)
Important Dates
~~~~~~~~~~~~~~~
- Author notification: March 26, 2023
- Final papers due: April 9, 2023
- Early registration deadline: April 9, 2023
- Symposium: April 24-25, 2023
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
Keynotes
~~~~~~~~
##### Artificial Intelligence: a Problem of Plumbing?
-- Gerald J. Sussman, MIT CSAIL, USA
We have made amazing progress in the construction and deployment of
systems that do work originally thought to require human-like
intelligence. On the symbolic side we have world-champion
Chess-playing and Go-playing systems. We have deductive systems and
algebraic manipulation systems that exceed the capabilities of human
mathematicians. We are now observing the rise of connectionist
mechanisms that appear to see and hear pretty well, and chatbots that
appear to have some impressive linguistic ability. But there is a
serious problem. The mechanisms that can distinguish pictures of cats
from pictures of dogs have no idea what a cat or a dog is. The
chatbots have no idea what they are talking about. The algebraic
systems do not understand anything about the real physical world. And
no deontic logic system has any idea about feelings and morality.
So what is the problem? We generally do not know how to combine
systems so that a system that knows how to solve problems of class A
and another system that knows how to solve problems of class B can be
combined to solve not just problems of class A or class B but can
solve problems that require both skills that are needed for problems
of class A and skills that are needed for problems of class B.
Perhaps this is partly a problem of plumbing. We do not have
linguistic structures that facilitate discovering and building
combinations. This is a fundamental challenge for the
programming-language community. We need appropriate ideas for abstract
plumbing fittings that enable this kind of cooperation among disparate
mechanisms. For example, why is the amazingly powerful tree
exploration mechanism that is used for games not also available, in
the same system, to a deductive engine that is being applied to a
social interaction problem?
I will attempt to elucidate this problem and perhaps point at avenues
of attack that we may work on together.
##### Gradual, Multi-Lingual, and Teacher-Centric Programming Education
-- Felienne Hermans, Vrije Universiteit Amsterdam, Nederlands
(tba)
Programme Chair
~~~~~~~~~~~~~~~
Stefan Monnier, DIRO, Université de Montréal, Canada
Programme Committee
~~~~~~~~~~~~~~~~~~~
Mark Evenson, not.org, Austria
Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
Ioanna Dimitriou, Igalia S.L., Germany
Robert Smith, HRL Laboratories
Mattias Engdegård
Marc Feeley, Université de Montréal, Canada
Marc Battyani, FractalConcept
Alan Ruttenberg, National Center for Ontological Research, USA
Nick Levine, Ravenbrook Ltd, UK
Ludovic Courtès, Inria, France
Matthew Flatt, University of Utah, USA
Irène Durand, Université Bordeaux 1, France
Jay McCarthy, Brigham Young University, USA
Ambrose Bonnaire-Sergeant, Cisco
Christopher League, Long Island University, NY, USA
Pascal Costanza, Intel, Belgium
Christian Queinnec
Local Chair
~~~~~~~~~~~
Breanndán Ó Nualláin, Machine Learning Programs, Nederlands
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info