[armedbear-devel] Environment not found
Hi, I was looking for documentation of the standard options that the `abcl' driver accepts -- but could not find one. The FAQ page http://common-lisp.net/project/armedbear/faq.shtml suggests as first option `Our wiki'. Clicking on the link http://trac.common-lisp.net/project/wiki displays the message as indicated in the $SUBJECT. I take that to indicate that ABCL (website) is relying on a dangling reference... That being reported, where is the documentation of the options accepted by the `abcl' driver? Thanks, -- Gaby
On 29 November 2010 03:14, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
suggests as first option `Our wiki'. Clicking on the link http://trac.common-lisp.net/project/wiki displays the message as indicated in the $SUBJECT. I take that to indicate that ABCL (website) is relying on a dangling reference...
Thanks for the heads-up, that link is botched. We'll fix it.
That being reported, where is the documentation of the options accepted by the `abcl' driver?
I don't think there is any documentation for those besides the source code in Interpreter.java (preprocessCommandLineArguments). We'll need to fix that as well.
On Sun, Nov 28, 2010 at 7:33 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 29 November 2010 03:14, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
suggests as first option `Our wiki'. Clicking on the link http://trac.common-lisp.net/project/wiki displays the message as indicated in the $SUBJECT. I take that to indicate that ABCL (website) is relying on a dangling reference...
Thanks for the heads-up, that link is botched. We'll fix it.
That being reported, where is the documentation of the options accepted by the `abcl' driver?
I don't think there is any documentation for those besides the source code in Interpreter.java (preprocessCommandLineArguments). We'll need to fix that as well.
OK, thanks. I see that, among other things, the following are supported (at least from eyeballing the source code) --eval --batch --noinform and they are part of what I was looking for. However, --batch does not seem to work to do anything that it name would suggest -- e.g. it still lands me into the REPL (which I don't want). Furthermore, --eval does not print the result of evaluation. For example, trying abcl --noinform --batch --eval '(lisp-implementation-version)' lands me squarely into the REPL with no printed result. I was expecting "0.24.0-dev" printed on the standard output stream, and control back to the shell. -- Gaby
On Sun, Nov 28, 2010 at 7:44 PM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
Furthermore, --eval does not print the result of evaluation. For example, trying
abcl --noinform --batch --eval '(lisp-implementation-version)'
Even abcl --noinform --batch --eval '(format t "~a" (lisp-implementation-version))' does not show anything, except landing me in the REPL. At least, that must be a bug :-) -- Gaby
On 29 November 2010 03:53, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
Furthermore, --eval does not print the result of evaluation. For example, trying abcl --noinform --batch --eval '(lisp-implementation-version)'
Fix committed as r13090 on trunk. Please check that it fixes the problems with --batch/--eval. Note that currently merely doing --eval '(lisp-implementation-version)' doesn't print anything on the standard output, as (lisp-implementation-version) just returns a string. I have so far chosen not to make --batch mode print evaluation results automatically, so if you want to print something on stdout in batch mode, use FORMAT. Please give feedback if the approach chosen is reasonable. Thanks, -VJV-
On Fri, Dec 10, 2010 at 10:20 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 29 November 2010 03:53, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
Furthermore, --eval does not print the result of evaluation. For example, trying abcl --noinform --batch --eval '(lisp-implementation-version)'
Fix committed as r13090 on trunk. Please check that it fixes the problems with --batch/--eval. Note that currently merely doing --eval '(lisp-implementation-version)' doesn't print anything on the standard output, as (lisp-implementation-version) just returns a string. I have so far chosen not to make --batch mode print evaluation results automatically, so if you want to print something on stdout in batch mode, use FORMAT.
Ville -- Thanks for looking into this. With the new version, when I do echo '(format nil "version=~a" (lisp-implementation-version))' | ./abcl --noinform I get something on the standard as expected. However, if I add --batch then nothing is printed -- i.e. when using FORMAT. If I do echo '(prog (format nil "version=~a" (lisp-implementation-version)) (quit))' | ./abcl only the prompt is printed, not the result. -- Gaby
On Sat, Dec 11, 2010 at 1:36 AM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
With the new version, when I do
echo '(format nil "version=~a" (lisp-implementation-version))' | ./abcl --noinform
I get something on the standard as expected. However, if I add --batch then nothing is printed -- i.e. when using FORMAT.
If I do
echo '(prog (format nil "version=~a" (lisp-implementation-version)) (quit))' | ./abcl
only the prompt is printed, not the result.
That's because (format nil ...) prints to a string, not to *standard-output*. You want (format t ...) instead. Bye Alessio
On Fri, Dec 10, 2010 at 6:41 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
If I do
echo '(prog (format nil "version=~a" (lisp-implementation-version)) (quit))' | ./abcl
only the prompt is printed, not the result.
That's because (format nil ...) prints to a string, not to *standard-output*. You want (format t ...) instead.
oops, never mind -- I was testing the wrong thing. What I needed is working now. Thanks to both of you. -- Gaby
On 11 December 2010 02:41, Alessio Stalla <alessiostalla@gmail.com> wrote:
If I do echo '(prog (format nil "version=~a" (lisp-implementation-version)) (quit))' | ./abcl only the prompt is printed, not the result. That's because (format nil ...) prints to a string, not to *standard-output*. You want (format t ...) instead.
No, it looks like there may be a lingering flushing problem. Adding the (quit) seems to botch the print (there's no --batch, so everything the REPL prints should be printed), so that does seem like a flushing problem indeed.
participants (3)
-
Alessio Stalla
-
Gabriel Dos Reis
-
Ville Voutilainen