armedbear-devel

armedbear-devel@common-lisp.net

2 participants
1202 discussions

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

On the Bear turning to Java 11
by Mark Evenson 16 Nov '19

16 Nov '19

As the leaves fall in the Northern hemisphere, thoughts of the Bear turn to a rumored permanent slumber, and a complete absence of the possibility of new updates. The Bear [accepts][trac] [all][gitab] patches][github], so if you don't like the current implementation, please get out and push. Or pull? Or fast forward? The Bear is seemingly always confused with Git… As previously rumored, [patches for getting the Armed Bear Common Lisp implementation running on Java 11][github-with-java11] have landed in the [trunk][trunk-with-java11]. Unless anyone objects strongly, we will release [ABCL 1.6.0][abcl-1.6.0] as soon as possible with the intention to support the openjdk{6,7,8,11} runtimes. After stabilizing the 1.6 branch with the inevitable necessary and unknown updates, we can turn our attention to the [2.0 branch][abcl-2.0.0] which will introduce support for additional runtimes but drop support for emitting openjdk6 or openjdk7 compatible byte-code. As always, everyone's desires are welcome to be expressed. yers in CONS, Mark <evenson.not.org(a)gmail.com> [trunk-with-java11]: https://abcl.org/trac/changeset/15133 [github-with-java11]: https://github.com/armedbear/abcl/commit/a628e961a1dc33e1f225191a19494701d7… [github]: https://github.com/armedbear/abcl/ [trac]: https://abcl.org/trac/ [gitlab]: https://common-lisp.net/abcl/abcl/ [svn]: svn://abcl.org/svn/ [mailing-list]: <mailto:armedbear-devel@common-lisp.net> [abcl-1.6.0]: https://abcl.org/trac/milestone/1.6.0 [abcl-2.0.0]: https://abcl.org/trac/milestone/2.0.0 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 1

Moving the Bear past Java 11
by Mark Evenson 14 Nov '19

14 Nov '19

As the leaves fall in the Northern hemisphere, thoughts of the Bear turn to a rumored permanent slumber, and a complete absence of the possibility of new updates. The Bear [accepts][trac] [all][gitab] patches][github], so if you don't like the current implementation, please get out and push. Or pull? Or fast forward? The Bear is seemingly always confused with Git… As previously rumored, [patches for getting the Armed Bear Common Lisp implementation running on Java 11][github-with-java11] have landed in the [trunk][trunk-with-java11]. Unless anyone objects strongly, we will release [ABCL 1.6.0][abcl-1.6.0] as soon as possible with the intention to support the openjdk{6,7,8,11} runtimes. After stabilizing the 1.6 branch with the inevitable necessary and unknown updates, we can turn our attention to the [2.0 branch][abcl-2.0.0] which will introduce support for additional runtimes but drop support for emitting openjdk6 or openjdk7 compatible byte-code. As always, everyone's desires are welcome to be expressed. yers in CONS, Mark <evenson.not.org(a)gmail.com> [trunk-with-java11]: https://abcl.org/trac/changeset/15133 [github-with-java11]: https://github.com/armedbear/abcl/commit/a628e961a1dc33e1f225191a19494701d7… [github]: https://github.com/armedbear/abcl/ [trac]: https://abcl.org/trac/ [gitlab]: https://gitlab.common-lisp.net/abcl/abcl/ [svn]: svn://abcl.org/svn/ [mailing-list]: <mailto:armedbear-devel@common-lisp.net> [abcl-1.6.0]: https://abcl.org/trac/milestone/1.6.0 [abcl-2.0.0]: https://abcl.org/trac/milestone/2.0.0 -- "No, this is not a disentanglement, but a progressive /knotting-into/."

1 0

Directory handling
by Marco Antoniotti 13 Jun '19

13 Jun '19

Dear all, I have been looking at the ABCL manual and packages and I was not able (my fault!) to find functions like CURRENT-DIRECTORY and/or CHANGE-DIRECTORY (or CHDIR). Could you tell me how to get to this functionality? Also, what is the set of features that ABCL uses to identify the platform? On a Mac OSX I see (at a minimum): CL-USER> (dolist (f *features*) (print f)) :SWANK :X86-64 :UNIX :DARWIN :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES NIL Thanks -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

4 10

Repositories of ABCL-specific code? / Kill runaway ABCL function and return to REPL?
by Elliott, Clark 12 Jun '19

12 Jun '19

Dear ABCL experts, I am working on AI system development in LISP. I like using ABCL because of its easy portability to Windows, Mac, and Linux and its direct access to Java. I am running ABCL in emacs shells, often as several processes at once, communicating via sockets. The LISP is working very well indeed. Great job! I've slogged through getting things like sockets and threads running--mostly using apropos and guessing--but it takes a lot of time. I STRONGLY prefer to work from examples of running code. I would dearly love some tips on the following: 1. Are there repositories of ABCL-specific running code, small programs, utility applications and etc. showing the actual running of ABCL implementation-specific functions? Native ABCL networking? ABCL tricks? Examples of running programs using the native threads? Examples of small systems using Java-to-LISP and LISP-to-Java (beyond the given short examples)? 2. How can I stop a runaway ABCL LISP function and return to top-level LISP without having to blow away the emacs buffer, and thus my entire current LISP context? In other LISPs I've had some kind of control key sequence, but can't find one for ABCL. E.g.: (defun runaway () (let ((n 0)) (loop while (< (incf n) 10) ;; Pretend this ran away. How do I kill it in ABCL REPL? do (sleep 1)))) Thanks in advance for any help. Best, Clark

3 2

Running Lisp tests
by Alessio Stalla 12 Jun '19

12 Jun '19

Greetings, I have trouble running ABCL's Lisp test suites: $ ant abcl.test ...lots of output... [java] Caught :ASDF/FIND-COMPONENT:MISSING-DEPENDENCY while processing --eval option "(asdf:test-system :abcl/test/ansi/compiled)": [java] #<MISSING-DEPENDENCY {1337E679}> [java] Java Result: 2 ...etc... Do you have any idea? Thanks Alessio

5 10

Re: ABCL functionality
by Marco Antoniotti 07 Jun '19

07 Jun '19

Thanks Elliott, but no. These are REPL conveniences. How is the “cd” command implemented? I know I should dig in the ABCL code, but I am one of the laziest lispers around :) :) :) All the best Marco > On Jun 6, 2019, at 04:28 , Elliott, Clark <elliott(a)depaul.edu> wrote: > > Hi Marco, > > I’m not sure if this is what you are looking for, but it took me a long time to find these interactive commands: > > CL-USER(6): :help > > COMMAND ABBR DESCRIPTION > apropos ap apropos > bt backtrace n stack frames (default 8) > cd change default directory > cf compile file(s) > cload cl compile and load file(s) > continue cont invoke restart n > describe de describe an object > error err print the current error message > exit ex exit lisp > frame fr set the value of cl:* to be frame n (default 0) > help he print this help > inspect in inspect an object > istep i navigate within inspection of an object > ld load a file > ls list directory > macroexpand ma macroexpand an expression > package pa change *PACKAGE* > pwd pw print current directory > reset res return to top level > rq require a module > trace tr trace function(s) > untrace untr untrace function(s) > > Commands must be prefixed by the command character, which is ':' by default. > > Best, > > Clark Elliott -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

2 1

ABCL starting to work under Java11
by Mark Evenson 11 Apr '19

11 Apr '19

It turns out that if we pretend that Java 9 and Java 10 never existed, we can run a lightly modified version of [ABCL on Java11][11]. Once I get something stable, that mostly works across both openjdk8 and openjdk11, I think I would like to fork an abcl-2.0.0 while maintaining support for openjdk[678] via the abcl-1.m.n series, Our CL:PATHNAME stuff needs to be adapted because Java11 stops referring to classes in `jar:file` location in favor of a synthetic reference to a `jrt:` path, but I think I may be able to easuly paper over this problem by tightening the isomorphism between a URI and the namestrings for ABCL’s implementation. [11]: https://github.com/armedbear/abcl/pull/96 Surprisingly, the compiler seems to work fine, so the implementation is certainly not intolerably slow under Java 11. JSS certainly does not work but the ABCL-CONTRIB works for implementations with access to a filesystem on which CL:DIRECTORY can work. This patch reworks ABCL-CONTRIB strategy to introspect the value of the the Java system property "java.class.path". This may not be sufficient to find the contribs under all possible ways that the implementation may be hosted. To provide some background to the issues here, ABCL-CONTRIB is deliberately packaged separately from the contents of abcl.jar in order to: • Keep the base ANSI implementation plus the included ASDF version in a single artifact with no other dependencies. • Push the decision to potentially infringe on licenses explicitly to the user. The knowledgable User may use the build-time option for the inclusion of code in system.lisp and the AIO packaging mechanism to create an unified "All-in-one" artifact. Since ASDF is always included as part of the base abcl.jar, we may rely on its presence to find additional artifacts to add as additional code to abcl, aka. "the abcl contribs". Currently, this is achieved by the following strategies, tried sequentially until one is found to be successful: • Introspecting for an implementation of "org.abcl-contrib" as declared in the system jar manifest. • Attempting to locate a jar file named abcl-contrib{MUMBLE}.jar on the filesystem by searching directories referenced on the class path. • Replacing the occurance of 'abcl' with 'abcl-contrib' in the the name of the system jar pathname, and then introspecting the contents. It would probably be helpful to add the following strategies to find members of ABCL-CONTRIB: • Locating an abcl-contrib.asd artifact via the usual ASDF conventions. • Retrieving the contents of ABCL-CONTRIB from the network via a "cool URI". • (Java 11) Appropiate use of Java modules to describe graphs of loadable ABCL artifacts. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

4 5

← Newer
1
...
8
9
10
11
12
13
14
...
121
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel