gmane.lisp.steel-bank.devel

Re: Test failure on freebsd/x86-64 with threads enabled

Harald Hanche-Olsen — 2008-10-07T19:30:07

+ "Nikodemus Siivola" random-state.net>: Hmm, funny. This happened, all with no action on my part: [... 2.5 megabytes of output ...] Finished running tests. Status: Expected failure: callback.impure.lisp / UNDERFLOW-DETECTION Unexpected success: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346) Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353) Expected failure: external-format.impure.lisp / (CHARACTER-DECODE-LARGE FORCE-END-OF-FILE) Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT ok //apparent success (reached end of run-tests.sh normally) "Unexpected success", that was ... unexpected. - Harald ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes G

Re: Test failure on freebsd/x86-64 with threads enabled

Nikodemus Siivola — 2008-10-07T18:41:11

I'm 80% sure this is the same fork() and thread-stack problem that plagues Darwin. What happens if you do sh run-tests.sh *.impure.lisp ? cheers, -- nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Test failure on freebsd/x86-64 with threads enabled

Harald Hanche-Olsen — 2008-10-07T17:37:48

I decided to try out a build with threads enabled on freebsd 7/x86-64, with these test results: Status: Expected failure: callback.impure.lisp / UNDERFLOW-DETECTION Invalid exit status: clos-add-remove-method.impure.lisp Invalid exit status: clos-cache.impure.lisp Invalid exit status: clos-interrupts.impure.lisp Invalid exit status: compare-and-swap.impure.lisp Invalid exit status: deadline.impure.lisp Invalid exit status: debug.impure.lisp Expected failure: external-format.impure.lisp / (CHARACTER-DECODE-LARGE FORCE-END-OF-FILE) Invalid exit status: gc.impure.lisp Invalid exit status: hash.impure.lisp Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Invalid exit status: threads.impure.lisp Invalid exit status: timer.impure.lisp test failed, expected 104 return code, got 1 Now the funny thing is all those "Invalid exit status" ones: In each case, sb

Re: RFC: --script commandline argument

Nikodemus Siivola — 2008-10-07T17:12:42

Whoops. I seem to have missed that boat! Sorry for the noise. Cheers, -- Nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Richard M Kreuter — 2008-10-07T16:53:01

Not printing the banner when the core is embedded is the status quo (see the 8th line from the bottom of the diff). -- Richard ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Nikodemus Siivola — 2008-10-07T16:32:50

I actually doubt this. People who *need* specific semantics are going to write wrapper scripts, etc. A de-facto out of the box solution is what most people will gravitate to. I agree. I really doubt that is going to happen. Multiline tramps and shell-script wrappers, yes. Custom toplevels for running scripts? No. No principal objections. (Trival nit: I am not sure --noinform is right for embedded cores, since they are not used only for application delivery -- and even for some applications it is a *good* thing to see what version they are running on.) Cheers, -- Nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Richard M Kreuter — 2008-10-07T14:51:32

As different people are invariably going to want a batch-mode flag with different, incompatible semantics, ISTM that we ought to both (a) come up with something handy, albeit arbitrary, (b) make it possible for dissenters to implement their preferred thing in a custom toplevel. AFAICT, the proximate impediment is the banner printing. Can't we move the banner printing into Lisp, fercryinoutloud? (Patch to this effect attached. Builds and passes tests on Linux/x86-64.) -- Richard diff --git a/build-order.lisp-expr b/build-order.lisp-expr index 79840f4..08e0f8f 100644 --- a/build-order.lisp-expr +++ b/build-order.lisp-expr < at >< at > -179,6 +179,11 < at >< at > ;; automatically by grovel_headers.c, i.e. it's not in CVS. ("output/stuff-groveled-from-headers" :not-host) + ;; src/code/toplevel wants to look at a variable in the runtime for + ;; the godforsaken "do I print a banner?" flag, so we need + ;; target-alieneval for extern-alien. + ("src/code/target-alieneval" :not-host) + ;; a comment from classic CMU CL:

Re: RFC: --script commandline argument

Nikodemus Siivola — 2008-10-07T15:38:38

If we are happy forcing people to install or symlink stuff to those locations, or start their scripts with builerplate that loads the ASDF setup they need from an ad-hoc location. I think clbuild is an excellent example where this is not a good idea. I offer myself as a use-case: all the things that I would be likely to use --script for are likely to require libraries managed by clbuild. It would seem like a step backwards to add more manual library management just so that --script was usable. We're better of writing multiline shell trampolines or adding shebang magic to .sbclrc. Additionally, since SBCL fasls are now incompatible between even minor versions, I would definitely want any --script I run to have automatic recompilation magic for ASDF turned on -- which means loading the bit where I define it. (Well, we *could* make that part of vanilla SBCL or ASDF...) Of the solutions proposed / stuff I've thought about so far two options seem reasonable: either provide .asdfrc, or load sysinit and user

Re: RFC: --script commandline argument

Attila Lendvai — 2008-10-07T15:34:26

to add a little more shades to the picture, there are users who don't keep symlinks updated in $SBCL_HOME/site-systems/, but instead use a function in their .sbclrc that scans for .asd files in certain directories and update *CENTRAL-REGISTRY* accordingly. btw, currently i'm scripting sbcl with kludgery like this: #| exec run-sbcl `dirname "$0"`/../../../sbcl --noinform --load "$0" --end-toplevel-options --script-file "$0" "$< at >" |# (some lisp)

Re: RFC: --script commandline argument

Richard M Kreuter — 2008-10-07T15:10:35

We already have our ASDF set *CENTRAL-REGISTRY* to include ~/.sbcl/systems/ and $SBCL_HOME/site-systems/ and rig unary REQUIRE to try ASDF, so won't REQUIREs after (require :asdf) in a script suffice? -- Richard ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Nikodemus Siivola — 2008-10-07T15:01:12

A new part of ASDF. Or rather, wearing SBCL hats we would decide that finding libraries is ASDF's problem, but that we don't want to load any initfiles when running under --script. Then wearing ASDF hats we wonder if .asdfrc is a reasonable solution to the problem, since we can't just go and shoot the SBCL guys... Cheers, -- Nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Nikodemus Siivola — 2008-10-07T14:18:25

I think Perl might be a better comparison here, though -- shell scripting is not know for the massive amounts of libraries used... Loading nothing has the benefit that everything is explicit, and it should be clear why a library is not found if it not found -- but it seems moderately painful for using non-standard libraries that you have not manually symlinked to ~/.sbcl/systems/. One possibility would be to skip initfiles, but add .asdfrc which would be loaded along with ASDF when the script for (require :asdf). Cheers, -- Nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Zach Beane — 2008-10-07T14:25:35

I don't quite follow...would that be a new part of asdf, or part of the sbcl --script support? If the latter, I don't feel all that great about privileging ASDF in a --script mechanism. Zach ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Nikodemus Siivola — 2008-10-07T14:02:20

Yeah. I elided that because I was lazy -- it should be there. I wanted to get a basic agreement on semantics first; ignoring the shebang line is the easy part. :) Cheers, -- Nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Brian Mastenbrook — 2008-10-07T13:41:31

I meant to say that it should skip the first line, if and only if the first line begins with '#!'. -- Brian Mastenbrook brian< at >mastenbrook.net http://brian.mastenbrook.net/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Duplicate emails from me

Nikodemus Siivola — 2008-10-07T14:00:57

I apologize for the seemingly endless spew of duplicate emails from me to sbcl-devel. As far as I can tell it is a brokenness of some kind between Gmail and Sourceforge SMTP. My best guess at the moment is that Sourceforge does something that Gmail interpets as meaning "didn't make it, need to resend later" -- when in fact the message was received and delivered fine the first time. ...but since this interaction is between Gmail and Sourceforge, there is relatively little I can do about it except file tickets... Sorry for the inconvenience all around, -- Nikodemus ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Brian Mastenbrook — 2008-10-07T13:38:28

Perhaps I'm missing it in the diff, but I would expect --script to skip the first line of the loaded file, so I could use '#!/usr/bin/env sbcl --script'. I agree with Zach's comments regarding loading of init files. Perhaps --script should set the default for --userinit and --sysinit to null, but allow these options to be overridden so that 'sbcl --userinit $HOME/.sbclrc --script foo' works as expected. Wouldn't it also be sensible to use the interpreter for loading scripts? As a user, this is generally what I'd expect, but my expectations may be abnormal as I always prefer to use the interpreter for EVAL. -- Brian Mastenbrook brian< at >mastenbrook.net http://brian.mastenbrook.net/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://m

Re: RFC: --script commandline argument

Zach Beane — 2008-10-07T13:54:51

Same as with shell scripting; that is, there's nothing standard, and if a script wants to add extra configuration, it does it by sourcing some other file, or just including the configuration directly in the script. The interactive user startup files are not sourced by default. Zach ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: RFC: --script commandline argument

Kevin Reid — 2008-10-07T13:41:58

How would the script know what file to load? If a standard, what's the pathname, and is the script expected to handle it not existing?

Re: RFC: --script commandline argument

Kevin Reid — 2008-10-07T13:18:25

FWIW, I would like there to be some well-defined means for a 'script' to see site/user-specific configuration for its own benefit. For example, if the 'script' depends on some system, the site config might be needed to specify the search path to find it. The low-complexity solution that comes to mind is to give the init- files some way of determining whether the current startup is 'interactive' or 'script'; then they could decide whether to do whatever customization. (unless sb-ext:*script-startup* (do-funky-stuff))

Re: RFC: --script commandline argument

Zach Beane — 2008-10-07T13:22:28

I hear you, but in that case I think it's better to explicitly load a file that configures things as needed. Zach ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/