armedbear-devel

armedbear-devel@common-lisp.net

2 participants
1202 discussions

Problem with build-from-lisp.bash
by Pascal Bourguignon 11 Dec '18

11 Dec '18

Hi! The lisp commands to build abcl in the build-from-lisp.bash script have a problem: they’re mere progn forms. When an error occurs, the lisp implementations will enter into the debugger and expect an interactive debugging. This prevents building abcl in automatic scripts, such as: function install_abcl_from_sources(){ # Assume ccl is available. cd "${PREFIX}"/src/ local url='http://abcl.org/releases/1.4.0/abcl-src-1.4.0.tar.gz' local tarball;tarball="$(basename "${url}")" local dir;dir="$(basename "${tarball}" .tar.gz)" local jdkhome;jdkhome="$(java_home)" local logbase;logbase="$(pwd)/${dir}" export JAVA_HOME="${jdkhome}" if [[ ! -e "${tarball}" ]] ; then download "${url}" fi unarchive "${tarball}" "${dir}" cd "${dir}" case "$(uname)" in (Darwin) sed -e 's^"/usr/"^"'"${jdkhome}/"'"^' \ <customizations.lisp.in >customizations.lisp ;; (*) sed -e 's^"/home/peter/sun/jdk1.5.0_16/"^"'"${jdkhome}/"'"^' \ -e 's/fastjar/jar/' \ <customizations.lisp.in >customizations.lisp ;; esac chmod 755 ./build-from-lisp.bash printi 'Building abcl from lisp with ccl' ./build-from-lisp.bash ccl > "${logbase}".build-from-lisp.log 2>&1 \ && ( printi 'Installing abcl' ; install -m 755 abcl "${PREFIX}"/bin/ > "${logbase}".make-install.log 2>&1 ) \ || printe 'Compiling abcl failed; check the logs.' } since errors aren’t detected, but just suspend the execution indefinitely. Therefore, I would suggest to wrap those progn forms into a handler-case; for example, in the case of ccl: (handler-case (progn $3 (ccl:quit)) (error (err) (princ err *error-output*) (terpri *error-output*) (finish-output *error-output*) (ccl:quit 1))) -- __Pascal J. Bourguignon__

2 1

Re: ABCL efficiency and build settings
by Mark Evenson 27 Nov '18

27 Nov '18

> On Nov 22, 2018, at 06:54, ThutmoseIII Thoth <thutmosethree(a)gmail.com> wrote: […] > How well do these debugging/profiling facilities work with ABCL? Will I be able to find out the name of lisp functions being called during a profile or only Java functions? CCL has this problem where we cannot get the lisp functions names in profiling, only the objective C methods. The inspectability of the JVM call stack is certainly better than Clojure even from just reading the function names. Using a [customized version of SLIME][1] allows the use the [ABCL-INTROSPECT][2], which is probably the most advanced way of debugging ABCL. [1]: https://github.com/easye/slime/tree/evenson-20170914a [2]:https://gitlab.common-lisp.net/abcl/abcl/tree/master/contrib/abcl-intros… As for your suspecting that your application is spawning more threads than you would expect, from your code snippet I can’t really offer much other than to wonder what the definition on the DISCONNECT involves. Again providing an example of code, even a stripped down toy application that demonstrates the problem would be enoromously more useful for me to help out. — -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

ABCL efficiency and build settings
by ThutmoseIII Thoth 15 Nov '18

15 Nov '18

Greetings ABCL developers! I have built an application with ABCL and am very pleased with both ABCL and my application, but I would like some help and suggestions in terms of the efficiency of my program, building settings, and perhaps JVM tuning. In the OS X Activity Monitor, my application is reporting to be using 29 threads and 200% of the CPU — This is enough to make my computer HOT to the touch! The equivalent program was running with CCL and cocoa at about 70% CPU and about 10 threads and was not hot to the touch… My program is fairly simple in that it just displays images in a JFrame that it gets from bytes over a socket. For this program I decided to handle each socket and display on its own thread, so I’ve only created two additional threads. I “built” the program by compiling all the .lisp files into .abcl files, then writing a tiny Java main function which creates an Interpreter and loads each .abcl file and finally calls Interpreter.eval on a lisp function which starts the program. I am using the Oracle Java 1.8 Hotspot JVM and ABCL 1.5.0 built from source. Thank you and please write back with suggestions and questions that will help me make my program run more efficiently.

2 1

[CfP] 12th European Lisp Symposium, April 1-2 2019, Genova, Italy
by Didier Verna 31 Oct '18

31 Oct '18

ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In co-location with <Programming> 2019 Sponsored by EPITA http://www.european-lisp-symposium.org/2019/ 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 and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 12th 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 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 2 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. The symposium will also provide slots for lightning talks, to be registered on-site every day. 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 address: https://www.easychair.org/conferences/?conf=els2019 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. Important dates: - 01 Feb 2019 Submission deadline - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: tba Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Trouble running abcl 1.5.0 with java 1.8.0_161 on macOS 10.12.6
by Carlo Tambuatco 29 Jun '18

29 Jun '18

It seems to build fine, and generate the abcl.jar in the dist/ folder when I build from source. But this error occurs when I run the generated abcl wrapper: Armed Bear Common Lisp 1.5.0 Java 1.8.0_161 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.282 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads-gen' in boot classpath. Failed to find loadable system file 'autoloads-gen' in boot classpath. Exception in thread "interpreter" org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) It seems to recognize the correct java to build from, but I have no idea what these integrity errors mean.

4 3

ABCL conflicts with tomcat on ## path names
by Blake McBride 30 May '18

30 May '18

With tomcat, if you want to change the root application you can either rename the directory ROOT or ROOT##myapp. ROOT#myapp makes a lot of sense because it reminds you what's there. However, that naming convention seems to conflict with ABCL. My app under ROOT works fine, but when I name it to ROOT##myapp ABCL gives: org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) ERROR placeholder called with arguments: Failed to get cached ZipFile because java.io.FileNotFoundException: /home/arahant/apache-tomcat-8.5.31/demo/ROOT (No such file or directory) Failed to get cached ZipFile because java.io.FileNotFoundException: /home/arahant/apache-tomcat-8.5.31/demo/ROOT (No such file or directory) [ERROR] [utils.StartupListener ] - 2018-05-30 12:42:02 Error initializing Lisp. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) [ERROR] [utils.StartupListener ] - org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

2 5

Buglet: format "~$" on negative numbers prints two "-" signs
by Scott L. Burson 30 May '18

30 May '18

ABCL> (format nil "~$" -2.34) --2.34 I've fixed this locally by modifying 'format-dollars' to call 'abs' on the first argument to 'sys::flonum-to-string'. -- Scott

2 1

ASDF 3.3.2 released
by Robert Goldman 04 May '18

04 May '18

Dear Lisp implementors and maintainers, Today we release ASDF 3.3.2, the second bugfix release for the 3.3 release series. Of primary interest in this release are 1. Multiple fixes in handling misnamed (or "legacy-named," if you prefer) secondary systems ("foo-test" instead of "foo/test"). Thanks to Eric Timmons, there is also a similar fix for package-inferred-systems. 2. Fix an annoying warning message for compute-action-stamp. 3. Add support for the Mezzano implementation (thanks to E. Housel, H. Harrington). 4. Miscellaneous minor fixes and documentation tweaks. 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.2 at their earliest convenience. Immense thanks, as always, to Fare Rideau. Also thanks to the many bug reporters and patch submitters (see the Changelog), and to Anton Vodonosov and Dave Cooper for help with testing. Here is the changelog entry for 3.3.2: cl-asdf (2:3.3.2-1) unstable; urgency=low Bug fix release: * Dependency tracking: fix bugs in handling misnamed secondary systems. We now distinguish between "syntactic" and "semantic" primariness, properly warn in case a secondary system is misnamed, yet properly recompile or avoid spurious recompilation depending on whether there or not is a conflict or redefinition. Similarly handle package-inferred-system (thanks to Eric Timmons). Better warning in a fishy case of compute-action-stamp. * UIOP: Add package location information to define-package on SBCL. * Upgrade: fix issue with asdf/bundle. * Portability: add support for Mezzano (thanks to E. Housel, H. Harrington) * Documentation: add discussion of best practices. * Package-inferred system: Improve source file handling. * Test and documentation improvements. -- Francois-Rene Rideau <fare(a)tunes.org> Thu, 03 May 2018 22:46:19 -0400

1 0

Causing an exception rather than calling the debugger
by Blake McBride 02 May '18

02 May '18

Hi, I embedded ABCL in an app some years ago. When an error occurred, ABCL threw an exception. It did what I want. Today I upgraded to the latest jar and I am experiencing a different behavior. When an error occurs ABCL enters a debug REP loop. Calling a REP loop on error is perfect for interactive use but not workable in an embedded situation. I'm hoping there is a simple way for me to change this behavior. Any help is greatly appreciated. Thanks. Blake McBride

2 2

Re-entrant and multi-entrant ABCL calls
by Blake McBride 20 Apr '18

20 Apr '18

Greetings, Does ABCL safely support re-entrant and multi-entrant calls? What I mean by that is the following: Re-entrant: on a single OS thread - my Java program calls into ABCL, then ABCL calls into my Java application, and then the Java application calls back into ABCL. So the stack has Java, ABCL, JAVA, and then ABCL again. Multi-entrant: my Java application has many threads. One of my threads calls into ABCL. Then, while one thread is still in ABCL, another thread evokes ABCL. So now we have two calls into ABCL by two independent Java/OS threads running at the same time. I understand the typical problems associated with application-level shared variables. This is expected. The question revolves around ABCL's internals. I presume ABCL would have some shared data that is internal to ABCL. That's what I am unclear about. ABCL would have had to be designed for these scenarios from the ground up. This is a little hard to test because if it can't always correctly handle these situations, it may not become clear until certain scenarios arrive. It may be hard for any "test" program I write to cause those scenarios, so I thought this may be a known answer. Thanks! Blake

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel