Hi!
I noticed a possible mistake in the dump-image code for CLISP:
--8<---------------cut here---------------start------------->8--- (apply #'ext:saveinitmem filename :quiet t :start-package *package* :keep-global-handlers nil :executable (if executable 0 t) ;--- requires clisp 2.48 or later, still catches --clisp-x (when executable (list ;; :parse-options nil ;--- requires a non-standard patch to clisp. :norc t :script nil :init-function #'restore-image))) --8<---------------cut here---------------end--------------->8---
According to the documentation (https://clisp.sourceforge.io/impnotes/image.html):
When non-NIL, the saved file will be a standalone executable. In this case, the #P".mem" extension is not added. On Win32 and Cygwin the extension #P".exe" is added instead. Additionally, if this argument is 0, the standard CLISP command line options will not be processed by the executable but will be placed into EXT:*ARGS* instead.
Here since we are setting `:executable` to 0 or t, the result is always executable. I don't think this is right because then the result cannot be loaded with `clisp -M path/ro/result`.
I believe the fix would be
```diff - :executable (if executable 0 t) + :executable (if executable 0 nil) ```
Cheers!
Thanks for the patch. I have put it in place as https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/155
I need to have a look at the tests, and see if there's a place I can look to see if the executable flag is being set correctly, and if UIOP has the necessary features for me to be able to ask the filesystem about that.
Pierre, please grab this branch, install it, and see if it does the right thing in terms of the executable bit in both standalone executables, and images that are not standalone.
On 1 Dec 2020, at 3:56, Pierre Neidhardt wrote:
Hi!
I noticed a possible mistake in the dump-image code for CLISP:
--8<---------------cut here---------------start------------->8--- (apply #'ext:saveinitmem filename :quiet t :start-package *package* :keep-global-handlers nil :executable (if executable 0 t) ;--- requires clisp 2.48 or later, still catches --clisp-x (when executable (list ;; :parse-options nil ;--- requires a non-standard patch to clisp. :norc t :script nil :init-function #'restore-image))) --8<---------------cut here---------------end--------------->8---
According to the documentation (https://clisp.sourceforge.io/impnotes/image.html):
When non-NIL, the saved file will be a standalone executable. In this case, the #P".mem" extension is not added. On Win32 and Cygwin the extension #P".exe" is added instead. Additionally, if this argument is 0, the standard CLISP command line options will not be processed by the executable but will be placed into EXT:*ARGS* instead.
Here since we are setting `:executable` to 0 or t, the result is always executable. I don't think this is right because then the result cannot be loaded with `clisp -M path/ro/result`.
I believe the fix would be
- :executable (if executable 0 t) + :executable (if executable 0 nil)Cheers!
-- Pierre Neidhardt https://ambrevar.xyz/
Thanks!
I can't login on the Common Lisp GitLab because of the 2-factor-authentication. Since I can't answer Fare there, I'll do it here :)
As far as I understand, CLISP does not behave the same way as SBCL; while SBCL supports images that are both executable and loadable with --core, it's not the case for CLISP where `-M` fails to load an executable image.
Besides this change does alter the behaviour of `:executable t`, so the `uiop:dump-image ... :executable t` still generates an executable for CLISP.
Maybe there is a misunderstanding? :)
P.S.: What is `lisp-invocation`?
I have posted your response onto the Gitlab merge request.
https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/155
On 2 Dec 2020, at 3:54, Pierre Neidhardt wrote:
Thanks!
I can't login on the Common Lisp GitLab because of the 2-factor-authentication. Since I can't answer Fare there, I'll do it here :)
As far as I understand, CLISP does not behave the same way as SBCL; while SBCL supports images that are both executable and loadable with --core, it's not the case for CLISP where `-M` fails to load an executable image.
Besides this change does alter the behaviour of `:executable t`, so the `uiop:dump-image ... :executable t` still generates an executable for CLISP.
Maybe there is a misunderstanding? :)
P.S.: What is `lisp-invocation`?
-- Pierre Neidhardt https://ambrevar.xyz/
Thank you!
I believe both Fahree and Eric are making fare points.
If executables it's going to be, then I suggest the following:
- Update the docstring to explain that executables are always generated, and why.
- Optional: Supersede `dump-image` with a new `dump-executable` which would be less misleading :)
Cheers!
dump-image is always dumping an image on all implementations. On *some* implementations, these images happen to also always be executable, even though they don't count as "self-contained, end-user-ready executables" (but :self-contained-end-user-ready-executable might have been a bit much instead of :executable).
I'm not opposed to adding a flag :image-only or something to allow programmers to specify they don't want it executable, but then please do it right and maintain backward compatibility.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A true intellectual is a man who, after reading a book and being convinced by its arguments, will shoot someone or, more likely, order someone shot. — John McCarthy
On Thu, Dec 3, 2020 at 3:12 AM Pierre Neidhardt mail@ambrevar.xyz wrote:
Thank you!
I believe both Fahree and Eric are making fare points.
If executables it's going to be, then I suggest the following:
Update the docstring to explain that executables are always generated, and why.
Optional: Supersede `dump-image` with a new `dump-executable` which would be less misleading :)
Cheers!
-- Pierre Neidhardt https://ambrevar.xyz/
Faré fahree@gmail.com writes:
dump-image is always dumping an image on all implementations. On *some* implementations, these images happen to also always be executable,
Oh, OK, thanks for the clarification. Then I guess just updating the docstring with this explanation would be enough.
Cheers!
Hi Pierre,
I can't login on the Common Lisp GitLab because of the 2-factor-authentication. Since I can't answer Fare there, I'll do it here :)
Sorry to hear about your trouble getting into the gitlab.common-lisp.net.
Could you send an email to admin@common-lisp.net or join the IRC channel # common-lisp.net and request help to resolve your login issue?
Thanks,
Dave
Hi Dave,
thanks for reaching out. I've just sent an email to the admin and I've added you in copy.
Cheers!
-
Dave Cooper -
Faré -
Pierre Neidhardt -
Robert Goldman