- armedbear-devel - mailman3.common-lisp.net

Final Call for Participation - ELS 2023, 16th European Lisp Symoisium
by Didier Verna 06 Apr '23

06 Apr '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

Test
by Marco Antoniotti 26 Mar '23

26 Mar '23

Just ignore... Sorry :) MA -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY CSCE 2023 - csce2023.lakecomoschool.org

1 0

Was ABCL 1.9.1's source tarball re-uploaded?
by Ruoyu Zhong 22 Mar '23

22 Mar '23

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

2 2

[CfPart] 16th European Lisp Symposium, April 24-25, Amsterdam
by Didier Verna 09 Mar '23

09 Mar '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

abcl-1.9.1 released
by Mark Evenson 03 Mar '23

03 Mar '23

━━━━━━━━━━━━━━━━━━━━━ ABCL 1.9.1 RELEASED Mark Evenson ━━━━━━━━━━━━━━━━━━━━━ Table of Contents ───────────────── 1. abcl-1.9.1 .. 1. News ..... 1. CFFI compatibility ..... 2. (Alan Ruttenberg) Ability to discriminate generic function execution on sub-types of MOP:SPECIALIZER ..... 3. Overhauled relationship to later openjdk threading models ..... 4. (Uthar) Implement array types for JAVA:JNEW-RUNTIME-CLASS ..... 5. (Alejandrozf) Compiler uses of signals to fallback to interpreted form ..... 6. (Alejandrozf) Further fixes to COMPILE-FILE-PATHNAME ..... 7. (Tarn W. Burton) Avoid NIL in simple LOOP from CL:FORMAT directives ..... 8. Broad testing and tweaks across Java Long Term Support (LTS) binaries 2. Fuller details 1 abcl-1.9.1 ════════════ If one has been hesitating about using the latest ABCL because one "never uses a dot oh release", we have now sloughed off abcl-1.9.1 for your appraisal from the depths of a Bear's long winter nap. Now one can use the somewhat less buggy version of the Tenth Edition of Armed Bear Common Lisp, available, as usual, at <https://abcl.org/releases/1.9.1/> or via Maven <https://search.maven.org/artifact/org.abcl/abcl/1.9.1/jar>. 1.1 News ──────── N.b. that when running on openjdk17 and later runtimes, there is quite a bit of necessary fiddling with command line arguments to "open" various modules to the Bear's introspective gaze. For example, see <https://abcl.org/svn/tags/1.9.1/ci/create-abcl-properties.bash> for the switches necessary to use CFFI to successfully run the CL+SSL test suite. As a reward for your patience, we mention the following notable improvements: 1.1.1 CFFI compatibility ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We improved the compiler to use wide indices for stack frame locals for the ALOAD, ASTORE, ILOAD, ISTORE, LLOAD, and LSTORE opcodes, which among other goodness, allows CFFI-TESTS to compile again. In addition, we have updated the jar artifact used by CFFI to jna-5.12.1 which includes support for native linkage on the Apple Silicon and other exotic architectures. 1.1.2 (Alan Ruttenberg) Ability to discriminate generic function execution on sub-types of MOP:SPECIALIZER ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Following SBCL, CCL, and ECL, the Bear now accepts subtypes of MOP:SPECIALIZER as a generic function discriminator. 1.1.3 Overhauled relationship to later openjdk threading models ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Going back to the future of the original green thread models, recent openjdk releases have started offering lightweight threading implementations. For the Bear, the ability to spawn virtual threads is indicated by the presence of :VIRTUAL-THREADS in CL:*FEATURES*. Setting the special THREADS:*THREADING-MODEL* to :VIRTUAL results in THREADS:MAKE-THREADS spawning virtual threads. On some openjdks one may have to pass a command-line switch the JVM to enable virtual threading. 1.1.4 (Uthar) Implement array types for JAVA:JNEW-RUNTIME-CLASS ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Support for creating synthetic Java classes at runtime via JAVA:JNEW-RUNTIME-CLASS has been improved by introducing machinery for dealing with array types. 1.1.5 (Alejandrozf) Compiler uses of signals to fallback to interpreted form ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We fall back to use an interpreted form for compilation results larger than 65535 bytes, which fixes the loading of the FirCAS computer algebra system. 1.1.6 (Alejandrozf) Further fixes to COMPILE-FILE-PATHNAME ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We have restored the ability to compile Maxima by hopefully untangling the last kinks in the reworking of our COMPILE-FILE-PATHNAME logic. 1.1.7 (Tarn W. Burton) Avoid NIL in simple LOOP from CL:FORMAT directives ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Simplify simple CL:LOOP requires only compound forms, in the place where returning NIL is neither permitted nor desired. 1.1.8 Broad testing and tweaks across Java Long Term Support (LTS) binaries ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We have extensively tested against recent openjdk8, openjdk11, openjdk17, and openjdk19 binaries. Unfortunately, for openjdk17+ runtimes one needs to pass additional runtime command line switches to the hosting JVM which "open" Java modules to reflective actions. 2 Fuller details ════════════════ More details can be found in <https://abcl.org/svn/tags/1.9.1/CHANGES>. Enjoy, and please CONS responsibly… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

Setting different class loader
by Steven Nunez 06 Feb '23

06 Feb '23

Greetings all, I have what I think is a problem with the ABCL class loader. I am working with a 'big data' library, Spark, but run into an issue on line 2 of the programming guide example. I am able to load the JARs from Maven with the ASDF system definition: (asdf:defsystem #:spark :description "Wrapper for Spark 3.0" :serial t :defsystem-depends-on (abcl-asdf) :depends-on (#:jss #:javaparser) :components ((:mvn "org.apache.spark/spark-core_2.12" :version "3.0.0") (:file "package") (:file "spark"))) and can create a SparkConf object: (defvar *spark-conf* #1"new SparkConf() .setAppName("abcl-app") .setMaster("local")" ) But when I try to create a 'context' (defvar *sc* (new 'JavaSparkContext *spark-conf*)) I get an error in the initialisation: Java exception 'java.lang.NoClassDefFoundError: Could not initialize class org.apache.spark.package$'. There isn't much on this except from the Jenkins guys, who have attempted to put Spark and Spark applications into a CI system. They seem to think that it's related to a call to get a properties file in the package class and on a StackOverflow discussion suggested that "you should make sure that you set the classloader that Spark was loaded through using the Thread.currentThread().setContextClassLoader(myCustomLoader) call". I've verified with (java:dump-classpath) that the JAR is on the ABCL classpath, and the JAR file does contain the spark-version-info.properties file. I've also tried getting the file myself with: (defvar rs #1"Thread.currentThread() .getContextClassLoader() .getResourceAsStream("spark-version-info.properties")" ) which returns nil, so their theory may be correct. Messing around with class loaders is a bit beyond my 20 year old Java knowledge so I thought I'd ask here if anyone has any ideas on how I can load Spark in way to use the default Java class loader. Alternatively it occurs to me to ask why the ABCL class loader isn't able to find the properties file if the JAR is on the classpath and then to correct whatever that problem is. Cheers, Steve

3 6

[CfP] 16th European Lisp Symposium, April 24-25, Amsterdam
by Didier Verna 02 Feb '23

02 Feb '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium Call for Papers 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 ~~~~~~~~~~~ First keynote speaker announced: Gerald Jay Sussman, MIT, MA, USA Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 26, 2023 - Author notification: March 26, 2023 - Final papers due: 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 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=els2023. 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 ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal, Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ Stefan Monnier, Université de Montréal, Canada Mark Evenson, RavenPack Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany Ioanna Dimitriou, Igalia S.L., Spain, Germany Robert Smith 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 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

1 0

[CfP] ELS 2023, 16th European Lisp Symposium, April 24-25, Amsterdam
by Didier Verna 06 Dec '22

06 Dec '22

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium Call for Papers April 24-25, 2023 Startup Village, Amsterdam, Nederlands https://www.european-lisp-symposium.org/2023 Sponsored by EPITA and DIRO ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 26, 2023 - Author notification: March 26, 2023 - Final papers due: 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 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. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. 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=els2023. 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 ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ TBA 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

1 0

Stack trace from condition
by Garrett Dangerfield 17 Nov '22

17 Nov '22

(handler-case (error "hi") (error (e) ;; print stack trace here )) How do I get the stack trace for the error? Thanks, Garrett Dangerfield.

2 1

File I/O Metrics
by Garrett Dangerfield 05 Nov '22

05 Nov '22

I don't want to cause a firestore here but I was doing some simple benchmarks on file i/o between Java, ABCL, and SBCL and I'm a bit shocked, honestly. Reading a 2.5M file in 16M chunks in (using iso-8859-1): - abcl takes a tad over 1 second - sbcl takes 0.04 seconds Reading a 5.8G file in 16M chunks in (using iso-8859-1 for Lisp, for Java it's just bytes): - abcl takes...too long, I gave up - sbcl takes between 20 and 21 seconds - Java takes 1.5 seconds These are all run on the same computer using the same files, etc. What's up with this? Thoughts? I'd heard that SBCL should be as fast as C under at least some circumstances. I'd wager that C is at least as fast as Java (probably faster). Thanks, Garrett Dangerfield. (he/him/his) P.S. Don't get me wrong, I *LOVE* Lisp, I'm trying to get away from Java as fast as I can (the syntax is killing me slowly). I've used ABCL in projects before (it was wonderful, Java doesn't handle XML well). Lisp code: (with-open-file (stream "/media/danger/OS/temp/jars.txt" :external-format :iso-8859-1) ; great_expectations.iso (let ((size (file-length stream)) (buffer-size (* 16 1024 1024)) ; 16M ) (time (loop with buffer = (make-array buffer-size :element-type 'character) for n-characters = (read-sequence buffer stream) while (< 0 n-characters))) ))) Java code: private static final int BUFFER_SIZE = 16 * 1024 * 1024; try (InputStream in = new FileInputStream("/media/danger/OS/temp/great_expectations.iso"); ) { byte[] buff = new byte[BUFFER_SIZE]; int chunkLen = -1; long start = System.currentTimeMillis(); while ((chunkLen = in.read(buff)) != -1) { System.out.println("chunkLen = " + chunkLen); } double duration = System.currentTimeMillis() - start; duration /= 1000; System.out.println(String.format("it took %,2f secs", duration)); } catch (Exception e) { e.printStackTrace(System.out); } finally { System.out.println("Done."); }

7 10