From: Zach B. <xa...@xa...> - 2008-09-23 02:41:25
Attachments:
save-runtime-options-and-die.diff
|
Attached is a patch that adds a :save-runtime-options to save-lisp-and-die. When true and :executable is also true, the runtime options of the running sbcl are stored in the saved executable and reloaded when the executable runs. Provided command-line options that would normally affect the runtime are instead passed along to the application. With this patch, sbcl runtime+core executables can now have total control over command line processing by using :save-runtime-options and a custom toplevel. As things stand now, stuff like "--help", "--core", and the like are intercepted by the runtime, unless you use "--end-runtime-options". (I think that's a little awkward if you want to provide an opaque binary blob of SBCL-powered usefulness to someone.) It makes the change in a couple places: - save.c now optionally adds runtime option data to the saved core's trailer - runtime.c checks the executable for embedded-core-nature early, and if the runtime has an embedded core, and the embedded core has runtime options in the trailer, they're used instead of the normal command-line processing; the passed argv becomes the *POSIX-ARGV*. - save-lisp-and-die takes the extra :save-runtime-options argument, which defaults to NIL; you have to explicitly pass :save-runtime-options to get the new behavior Only noinform, dynamic-space-size, and control-stack-size are saved & restored. I don't think any of the other runtime options make sense in a runtime+core executable. Thoughts? Zach |
From: Thomas F. B. <tbu...@gm...> - 2008-09-23 12:43:57
|
2008/9/23 Zach Beane <xa...@xa...> > > Thoughts? It's kind of a weird interface, don't you think? I'd rather be able to supply the argv for the saved image at save-lisp-and-die time. Looks nice, otherwise. |
From: Zach B. <xa...@xa...> - 2008-09-23 12:49:08
|
On Tue, Sep 23, 2008 at 02:43:45PM +0200, Thomas F. Burdick wrote: > 2008/9/23 Zach Beane <xa...@xa...> > > > > Thoughts? > > It's kind of a weird interface, don't you think? I'd rather be able > to supply the argv for the saved image at save-lisp-and-die time. > Looks nice, otherwise. That was my initial thought, also: save a vector of strings to initialize the runtime options. That has the advantage of accomodating new runtime options pretty easily. But when I dug into it, I found there are only three runtime options (noinform arguably isn't an option, since it's disabled for embedded cores anyway), and they're numbers, and it was a little easier to just stuff those away into the core trailer. It's also somewhat compatible with the notion of establishing the global state at startup (by providing command line options and loading software) and freezing it into a core as-is. If you want different options, use a different startup command-line... Zach |
From: Nikodemus S. <nik...@ra...> - 2008-09-24 01:16:16
|
On Mon, Sep 22, 2008 at 10:14 PM, Zach Beane <xa...@xa...> wrote: > Attached is a patch that adds a :save-runtime-options to > save-lisp-and-die. When true and :executable is also true, the runtime > options of the running sbcl are stored in the saved executable and > reloaded when the executable runs. I like this. There are some *additional* things that might be done, but it seems like a more than good enough starting point to me. Cheers, -- Nikodemus |
From: Zach B. <xa...@xa...> - 2008-09-24 12:37:55
|
On Tue, Sep 23, 2008 at 08:49:54PM -0400, Nikodemus Siivola wrote: > On Mon, Sep 22, 2008 at 10:14 PM, Zach Beane <xa...@xa...> wrote: > > > Attached is a patch that adds a :save-runtime-options to > > save-lisp-and-die. When true and :executable is also true, the runtime > > options of the running sbcl are stored in the saved executable and > > reloaded when the executable runs. > > I like this. There are some *additional* things that might be done, > but it seems like a more than good enough starting point to me. Thanks for the feedback. What additional things did you have in mind? Zach |
From: Nikodemus S. <nik...@ra...> - 2008-09-24 12:57:20
|
On Wed, Sep 24, 2008 at 8:37 AM, Zach Beane <xa...@xa...> wrote: > On Tue, Sep 23, 2008 at 08:49:54PM -0400, Nikodemus Siivola wrote: >> On Mon, Sep 22, 2008 at 10:14 PM, Zach Beane <xa...@xa...> wrote: >> >> > Attached is a patch that adds a :save-runtime-options to >> > save-lisp-and-die. When true and :executable is also true, the runtime >> > options of the running sbcl are stored in the saved executable and >> > reloaded when the executable runs. >> >> I like this. There are some *additional* things that might be done, >> but it seems like a more than good enough starting point to me. > > Thanks for the feedback. What additional things did you have in mind? Mainly accepting :save-runtime-options plist-of-options-to-save (and having T default to the current options) -- but this is a superset of what the patch provides, so I don't think it has to be a prequisite for merging. Cheers, -- Nikodemus |
From: Juho S. <js...@ik...> - 2008-09-24 13:10:25
|
Zach Beane <xa...@xa...> writes: > Attached is a patch that adds a :save-runtime-options to > save-lisp-and-die. When true and :executable is also true, the runtime > options of the running sbcl are stored in the saved executable and > reloaded when the executable runs. Does making this optional really make sense? At the very least it seems like this should be the default, rather having to make people opt in. And it's not completely obvious to me that anyone is going to ever want to pass runtime options to binaries with embedded cores, so even making it opt out might be overkill. -- Juho Snellman |
From: Zach B. <xa...@xa...> - 2008-09-24 12:54:33
|
On Wed, Sep 24, 2008 at 03:52:20PM +0300, Juho Snellman wrote: > Zach Beane <xa...@xa...> writes: > > Attached is a patch that adds a :save-runtime-options to > > save-lisp-and-die. When true and :executable is also true, the runtime > > options of the running sbcl are stored in the saved executable and > > reloaded when the executable runs. > > Does making this optional really make sense? At the very least it > seems like this should be the default, rather having to make people > opt in. And it's not completely obvious to me that anyone is going to > ever want to pass runtime options to binaries with embedded cores, so > even making it opt out might be overkill. My main concern in making it both optional and off by default was to preserve backwards compatibility. Nobody's embedded-core workflow will change if they simply ignore the new feature. But maybe it's not worth worrying about...I don't think anyone should want to pass runtime options to embedded-core binaries either. Zach |
From: Zach B. <xa...@xa...> - 2008-10-02 14:41:23
Attachments:
save-runtime-options-2.diff
|
Attached is a new take on my previous patch to save runtime options in an embedded core. It changes two things: - saving runtime options is not configurable; they're always saved in cores, and always used by runtimes with embedded cores - the noinform runtime option is not part of the saved options, since it's always assumed to be true for embedded cores anyway I hope this or something like it can be committed. Zach |
From: Nikodemus S. <nik...@ra...> - 2008-10-12 04:10:25
|
On Wed, Sep 24, 2008 at 3:52 PM, Juho Snellman <js...@ik...> wrote: > Does making this optional really make sense? At the very least it > seems like this should be the default, rather having to make people > opt in. And it's not completely obvious to me that anyone is going to > ever want to pass runtime options to binaries with embedded cores, so > even making it opt out might be overkill. I don't agree. I think it's perfectly reasonable to save an executable for a server-application, and yet want runtime option processing. It may also be that the options used while building the system are wildly inappropriate for deployment. It also seems to me that embedded cores are perfectly fine for distributing SBCL itself: "Here, have a lisp, it's a single file." I don't care if it's opt-in or opt-out, but I do want to be able to save executable images that do runtime option processing. Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2008-10-12 04:34:20
Attachments:
0001-saving-runtime-options-in-executables.patch
|
On Sun, Oct 12, 2008 at 7:10 AM, Nikodemus Siivola <nik...@ra...> wrote: > I don't care if it's opt-in or opt-out, but I do want to be able to > save executable images that do runtime option processing. The attached patch is almost identical to Zach's first one (a couple of cosmetic documentation changes, and removal of redundant --noinform saving as in his second patch.) I'm personally happy ehough with this, and will commit this in a day or two unless there are objections. Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2008-10-17 12:49:51
|
On Sun, Oct 12, 2008 at 7:25 AM, Nikodemus Siivola <nik...@ra...> wrote: > The attached patch is almost identical to Zach's first one (a couple > of cosmetic documentation changes, and removal of redundant --noinform > saving as in his second patch.) > > I'm personally happy ehough with this, and will commit this in a day > or two unless there are objections. Committed as 1.0.21.24, kudos for Xach! > Cheers, > > -- Nikodemus |
From: Bruce O'N. <ec...@pc...> - 2008-10-27 10:40:26
|
Hi (sorry if this is a dup, but, I didn't see the first one come through). I think that src/code/save.lisp has a misplaced paren which causes non gencgc systems to not actually save the .core when you call save-lisp-and-die. The phrase which begins with (when gc at line 132 I think should end with the end of the call to (gc-and-save at line 140. Right now the (when gc bit ends after the call to save at line 145. A diff is below. Thanks! cheers bruce *** save.lisp 2008-10-17 14:49:36.000000000 +0200 --- /home/edoneel/tmp/save.lisp 2008-10-26 23:44:43.754692889 +0100 *************** *** 137,148 **** ;; since the GC will invalidate the stack. #!+gencgc (gc-and-save (unix-namestring core-file-name nil) (foreign-bool executable) ! (foreign-bool save-runtime-options)) (without-gcing (save (unix-namestring core-file-name nil) (get-lisp-obj-address #'restart-lisp) (foreign-bool executable) ! (foreign-bool save-runtime-options)))))) ;; Save the restart function into a static symbol, to allow GC-AND-SAVE ;; access to it even after the GC has moved it. #!+gencgc --- 137,148 ---- ;; since the GC will invalidate the stack. #!+gencgc (gc-and-save (unix-namestring core-file-name nil) (foreign-bool executable) ! (foreign-bool save-runtime-options))) (without-gcing (save (unix-namestring core-file-name nil) (get-lisp-obj-address #'restart-lisp) (foreign-bool executable) ! (foreign-bool save-runtime-options))))) ;; Save the restart function into a static symbol, to allow GC-AND-SAVE ;; access to it even after the GC has moved it. #!+gencgc On Fri, Oct 17, 2008 at 03:49:45PM +0300, Nikodemus Siivola wrote: > On Sun, Oct 12, 2008 at 7:25 AM, Nikodemus Siivola > <nik...@ra...> wrote: > > > The attached patch is almost identical to Zach's first one (a couple > > of cosmetic documentation changes, and removal of redundant --noinform > > saving as in his second patch.) > > > > I'm personally happy ehough with this, and will commit this in a day > > or two unless there are objections. > > Committed as 1.0.21.24, kudos for Xach! > > > 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=/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: <ec...@pc...> - 2008-10-26 22:52:10
|
Hi, I think that there is a slightly out of place paran in src/code/save.lisp which breaks non gencgc versions. *** save.lisp 2008-10-26 21:13:19.415342931 +0100 --- save.lisp.org 2008-10-17 14:49:36.000000000 +0200 *************** *** 137,148 **** ;; since the GC will invalidate the stack. #!+gencgc (gc-and-save (unix-namestring core-file-name nil) (foreign-bool executable) ! (foreign-bool save-runtime-options))) (without-gcing (save (unix-namestring core-file-name nil) (get-lisp-obj-address #'restart-lisp) (foreign-bool executable) ! (foreign-bool save-runtime-options))))) ;; Save the restart function into a static symbol, to allow GC-AND-SAVE ;; access to it even after the GC has moved it. #!+gencgc --- 137,148 ---- ;; since the GC will invalidate the stack. #!+gencgc (gc-and-save (unix-namestring core-file-name nil) (foreign-bool executable) ! (foreign-bool save-runtime-options)) (without-gcing (save (unix-namestring core-file-name nil) (get-lisp-obj-address #'restart-lisp) (foreign-bool executable) ! (foreign-bool save-runtime-options)))))) ;; Save the restart function into a static symbol, to allow GC-AND-SAVE ;; access to it even after the GC has moved it. #!+gencgc I think that the (when gc should close at the end of (gc-and-save. With this small change the sparc linux version builds. Without the change save-lisp-and-die never actually saves the .core. Thanks very much! cheers bruce On Fri, Oct 17, 2008 at 03:49:45PM +0300, Nikodemus Siivola wrote: > On Sun, Oct 12, 2008 at 7:25 AM, Nikodemus Siivola > <nik...@ra...> wrote: > > > The attached patch is almost identical to Zach's first one (a couple > > of cosmetic documentation changes, and removal of redundant --noinform > > saving as in his second patch.) > > > > I'm personally happy ehough with this, and will commit this in a day > > or two unless there are objections. > > Committed as 1.0.21.24, kudos for Xach! > > > 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=/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Nikodemus S. <nik...@ra...> - 2008-10-27 16:01:31
|
On Mon, Oct 27, 2008 at 12:51 AM, <ec...@pc...> wrote: > I think that there is a slightly out of place paran in src/code/save.lisp > which breaks non gencgc versions. Thank you! Merged as 1.0.21.35. (No biggie, but for future reference: unified diffs are preferred as most people find them easier to read. All of "diff -u", "cvs diff -u", and what Git does by default are fine.) Cheers, -- Nikodemus |