armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

ASDF 3.3.4 released today
by Robert Goldman 14 Feb '20

14 Feb '20

Dear Lisp Maintainers, Here is the announcement of today's bug fix release, version 3.3.4, of ASDF. This will not change the API, and fixes some issues, so it should be low-risk inclusion into your distributions. Best regards, Robert ---- In honor of Valentine's Day, and more honestly, just because it's overdue, today we release ASDF 3.3.4, the fourth bugfix release for the 3.3 release series. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.4 at their earliest convenience. This is especially true for SBCL, for which 3.3.4 fixes a bug preventing ASDF upgrade from working smoothly. Immense thanks, as always, to Faré Rideau. Also thanks to the many bug reporters and patch submitters including (alphabetically): * Rommel Martinez * Jan Moringen * Karsten Poeck * François-René Rideau * Martin Simmons * Eric Timmons * Guillaume Le Vaillant

1 0

coerce a number to a short
by Brad Knotwell 12 Feb '20

12 Feb '20

I've been using ABCL to get access to a Java library and it's worked generally well. I have run into one problem I haven't been able to workaround. I need to make a call to a method that takes a short as an argument. I'm passing in a value--10--that fits in a short but ABCL can't find the method (presumedly due to a type issue). I've tried using jcoerce but it's not doing what I expect. What's the right way to do this? Thx. --Brad

3 10

Maven artifacts no longer available via non-TLS which breaks ABCL-ASDF
by Mark Evenson 06 Feb '20

06 Feb '20

Sometime in the last month, the Maven central repository has stopped serving non-TLS content. This change badly borks ABCL-ASDF’s use of Maven which has utilized the non-TLS version of the Maven central repository since its inception, which means that previous versions of ABCL will mysteriously stop working without one having changed any code. The error reported by ABCL is obscure, as the actual error reported by the Maven Aether class is not present anywhere in the thrown exception but rather only written to the file-system under the <file:~/.m2/> hierarchy. Initially, the error reported by ABCL resembled ones in the past which involved incompatible releases of the Maven Aether interfaces which caused me a fair amount of confusion in diagnosing this problem. Solutions: 1) One may build ABCL from source with the [required patch][1][2] 2) The bug only affects downloading artifacts, not using the local cache present under <file:~/.m2/>, so as long as one doesn’t “go to the network”, one can use locally present artifacts without problems. One could use the `mvn` command-line interface to download artifacts for ABCL to use. 3) One may patch an instance of ABCL without recompilation via the following code at the REPL or placed in <file:~/.abclrc> (require :abcl-contrib) (asdf:load-system :abcl-asdf) (setf abcl-asdf::*default-repository* "https://repo1.maven.org/maven2/“) [1]: https://github.com/armedbear/abcl/commit/42abe93f4170ee30c92ba2507780cfba06… [2]: https://abcl.org/trac/changeset/15229 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[CfP] Reminder: 13rd European Lisp Symposium, April 27-28, Zürich
by Didier Verna 22 Jan '20

22 Jan '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers In cooperation with: ACM SIGPLAN Call for papers April 27 - April 28, 2020 GZ Riesbach Zürich, Switzerland http://www.european-lisp-symposium.org/2020 Sponsored by EPITA, Igalia S.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 13, 2020 - Author notification: March 16, 2020 - Final papers due: April 6, 2020 - Symposium: April 27 - 28, 2020 Scope ~~~~~ 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 dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2020 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. This year's focus will be directed towards "Compilers". We especially invite submissions in the following areas: - Compiler techniques - Compiler passes - Compiler compilers - Showcasing of industrial or experimental compilers - Code generation - Compiler verification - Compiler optimizations - JIT compilers Contributions are also welcome in other areas, including but 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 for at least 90 minutes and up to 180 minutes. 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 http://www.easychair.org/conferences/?conf=els2020 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 ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - Imec, ExaScience Lab, Belgium Christophe Rhodes - Google, UK Irène Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France Sky Hester - consultant, USA -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

java.lang.VerifyError with PROGN
by Eric Marsden 19 Dec '19

19 Dec '19

Hi, Compiling the loading the code below (a simplified extract of SBCL's codebase, found attempting to crossbuild SBCL with ABCL) results in a VerifyError, possibly related to the implementation of PROGN. Using 1.6.1-dev-svn-15217. java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find object/array on stack at java.base/java.lang.Class.getDeclaredConstructors0(Native Method) at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137) at java.base/java.lang.Class.getConstructor0(Class.java:3342) at java.base/java.lang.Class.newInstance(Class.java:556) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) --- (in-package :cl-user) (progn (defvar*sxhash-crosscheck* nil) (defun sxhash (x) (let ((answer (if (string= x "NIL") (ash 1343225879 (- 1))))) (push (cons x answer)*sxhash-crosscheck*) answer))) -- Eric Marsden https://risk-engineering.org/

5 10

[CfP] ELS 2020, 13th European Lisp Symposium, April 27-28, Zurich
by Didier Verna 06 Dec '19

06 Dec '19

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers Call for papers April 27 - April 28, 2020 GZ Riesbach Zürich, Switzerland http://www.european-lisp-symposium.org/2020 Sponsored by EPITA, Igalia S.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 13, 2020 - Author notification: March 16, 2020 - Final papers due: April 6, 2020 - Symposium: April 27 - 28, 2020 Scope ~~~~~ 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 dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2020 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. This year's focus will be directed towards "Compilers". We especially invite submissions in the following areas: - Compiler techniques - Compiler passes - Compiler compilers - Showcasing of industrial or experimental compilers - Code generation - Compiler verification - Compiler optimizations - JIT compilers Contributions are also welcome in other areas, including but 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 15 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 for at least 90 minutes and up to 180 minutes. 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 http://www.easychair.org/conferences/?conf=els2020 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 ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - IMEC, Intel Exascience Lab, Belgium Christophe Rhodes - Google, UK Iréne Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France (more PC members to be announced) -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

On preparations to turn the Bear past 11
by Mark Evenson 02 Dec '19

02 Dec '19

Dear long-suffering fans of the Bear, Rejoice! for preparations for the release of abcl-1.6.0 to support openjdk{6,7,8,11} and beyond near completion. We have managed to get a [Continuous Integration (CI)][travis-builds] build mostly working via Travis CI integration with the Github repository. Anyone who forks us on Github with suitable monkeying around can get automated build and test results for their commits to their fork. The [current version of the tests][.travis.yml] attempt to run in environments that are the cross product of macOS/Linux with openjdk8/openjdk11. This isn't quite completely working yet as I haven't apparently figured out how to use jenv in Travis to specify the correct openjdk to invoke, but I'm close. For now, we at least getting test coverage for openjdk11 under Linux, and I hope to iron out the remaining kinks real soon now. It should be theoretically possible to [add Windows builds][windows-builds] as well, but I am planning on to tackling that in the near future. The CI tests have given me the confidence to next attempt to release abcl-1.6.0 via existing release engineering process in spite of the following problems: 1. While they seemingly pass in the CI, the CFFI linkages to CL+SSL libraries often fail in a spectacularly segmentation fault in practical use. With judicious refinement, I think we can figure out what is going but for now we should just accept this. 2. [A major regression from abcl-1.5.0][pathname-problems] concerning the use of CL:PATHNAME to refer to objects within a jar/zip archive has been discovered, but curiously it is seemingly not fatal to anything other than the execution of ABCL test suite. In analyzing the problems, I realized that we can considerably clean up our abstraction for a CL:PATHNAME which denotes an entry in an archive by allowing nested archives using the CL:PATHNAME-DEVICE component. To do this in a reasonably clean manner means a fair amount of modification on the Java side of our implementation by reflecting the various types of a CL:PATHNAME in that Java hierarchy as Erik Hülsmann suggested many years ago. While I have some promising preliminary patches towards this, due to the amount of outstanding effort, I feel we should get abcl-1.6.0 out first. Please holler loudly real soon if anyone has problems with releasing as things currently stand. I intend follow up with abcl-1.6.1 within a month to hopefully address the two major blockers in addition to any errata. [travis-builds]: https://travis-ci.org/armedbear/abcl/builds [.travis.yml]: https://github.com/armedbear/abcl/blob/master/.travis.yml [windows-builds]: https://twitter.com/ArmedBear/status/1197538417678192645 [cl+ssl-problems]: https://abcl.org/trac/ticket/464 [pathname-problems]: https://github.com/armedbear/abcl/commit/e962be5e0dd86335cc66415a0a417f9e4b… yers, Mark <evenson(a)panix.com> -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 2

ABCL 1.6.0 unleashed
by Mark Evenson 23 Nov '19

23 Nov '19

Against the falling canvas of 2019, the Bear has freely thrust [ABCL 1.6.0][abcl.org/releases] onto the [world stage][github]. This release fully supports building and running on Java 6, 7, 8, and 11 via the [openjdk runtimes][adoptjdk]. By [building from our source][source-build], it is [rumored that the User may utilize additional hosting platforms such as Java 13][sfp-mail]. Support for Microsoft Windows platforms has not been thoroughly tested at this point but we intend to add it our automatic cloud based build in the process of releasing a [stablizing ABCL 1.6.1][1.6.1] build due by the end of this year. Thanks to all past, present, and future contributors to the Bear; here's to [hackin' our way out of the prison of the Java language][jss] for over a decade. [github]: https://github.com/armedbear/abcl [abcl.org/releases]: https://abcl.org/releases/1.6.0 [1.6.1]: https://abcl.org/trac/milestone/1.6.1 [source-build]: https://gitlab.common-lisp.net/abcl/abcl/tree/master/contrib/abcl-build [adoptjdk]: https://adoptopenjdk.net/ [sfp-mail]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2019-November/004… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

Patch for a couple of stack inconsistency bugs
by somewhat-functional-programmer 19 Nov '19

19 Nov '19

Hello list, Lately I have been starting to dive deeper into Common Lisp and have started to use ABCL more than SBCL or CCL lately. It is a very impressive project. I want to post a patch for review/comments and hopefully have it be worthwhile to eventually include it in ABCL. The patch attempts to fix a couple of stack inconsistency bugs in the compiler. I came across the stack inconsistency issue in one of my projects and started to try to find the root cause of the problem based on a nice minimal reproduction of the bug found in https://github.com/armedbear/abcl/issues/69. However, my particular bug was slightly different. It had to do with using a return-from in the cleanup form of an unwind-protect. The following two forms also result in a stack inconsistency problem (and are a more minimal reproduction of the bug my code introduced): (defun two-arg-fn (one two) (format t "Two args: ~S and ~S~%" one two)) (let ((fn (compile nil '(lambda () (two-arg-fn (block test-block (unwind-protect 30 (return-from test-block 8))) -1))))) (funcall fn)) My patch handles both the github issue and the stack inconsistency in the form above. It also fixes jvm::print-code to print string representations of values from the constant pool which I found useful in debugging the output. Anyhow, let me attempt to quickly summarize the stack inconsistency problem in general: - Certain common lisp control flow forms (tagbody/go/unwind-protect/block/return-from/throw/catch) require the use of JVM exceptions to implement in bytecode - When the JVM throws an exception, the operand stack is cleared and the exception is pushed onto the operand stack (see jvms8, 6.5/athrow, p378) - Therefore, any form which pushes values onto the operand stack for further use is confounded when these control flow forms are child forms - To properly handle these alternate control flows we need to save the result of the control flow form to a local variable in the stack frame (distinct from the operand stack, and not destroyed by an exception (well at least not until the exception passes /out/ of the method) and then reload for use by the parent form to push on the operand stack Take the case of the ash function (from the github issue). Bytecode for ash is emitted from jvm::p2-ash. It compiles its arguments to the operand stack, and is therefore vulnerable to the problem discussed above. Other low level functions (like + for example in p2-plus) use the following forms to overcome this issue: jvm::with-operand-accumulation and jvm::compile-operand. These forms save the results of "unsafe" forms (opstack unsafe) to "registers" (local variables in the stack frame). This technique allows for these complicated control flow forms to be a child form of + with no issues, but not the ash function (which does not do this). See my patch for how I added these already present with-operand-accumulation and compile-operand forms to ash so it is no longer vulnerable to stack inconsistency bugs. Generally, function calls in ABCL are not vulnerable to these stack inconsistency bugs. Function arguments are processed in jvm::process-args, and in this function, the opstack safety of child forms is checked, and values are saved to "registers" when a form is known to be unsafe. My case (the return-from in the cleanup form of an unwind-protect) simply wasn't properly being marked as opstack unsafe. I modified jvm::p1-unwind-protect to mark all direct children of the unwind-protect as opstack unsafe, which eliminated my problem. I believe there may have been confusion here in the code (speculation of course on my part) of 'protected' form referring to the form actually protected by the unwind-protect (which is totally different than being unsafe or needing opstack /protection/) (or I'm misinterpreting this function and potentially causing additional bugs!). The only other item in my patch is fixing how bytecode is printed for debugging. Basically, most items in a class constant pool are referenced with a 2 byte index, but one (ldc) uses a one byte index). This has been accounted for in the new function jvm::constant-pool-index. Let me know what you think, and again please review, there aren't many lines changed but I am new to the internals of the project. I think I ran all tests (ant abcl.test) but while the ant task completed successfully, my output complained of a missing dependency and I'm not sure what actually ran. -Mark The attached patch was produced against b3cfee6617e0c2c380d8675f3383d81e7758f358 from https://github.com/easye/abcl (latest master branch). [jvms8] https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf

2 3

format ~$ may need consider -0.0
by dingd 16 Nov '19

16 Nov '19

this is what sbcl does * (format nil "~$" -0.0) "-0.00"

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
120
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel