Re: [Sbcl-help] Semi-functional Windows package

For the correct core lookup, set SBCL_HOME env. variable to c:\Program
Files\Steel Bank Common Lisp\1.0.37\
Kittens of Death is already reported in LP.
The last failure is due to the launcher program sensitivity to spaces, so it
thinks that C:/Program is a path to the application, and the rest components
are arguments. Quoting the full path should help.
Regards,
Roman
2011/4/14 Faré <fahree@...>
> I tried to use the windows installer for SBCL as advertised on sbcl.org.
>
> * It installs stuff in c:\Program Files\Steel Bank Common Lisp\1.0.37\
> which is fine, but the sbcl.exe there expects a core file in
> /usr/local/lib/sbcl. Oops.
> * --noinform doesn't get rid of the message concerning Kittens of Death.
>
> Could some windows developer solve these issues in a new packaging?
> Maybe using a more recent version of SBCL, too.
>
> I see that yamaraj has uploaded more recent SBCL binaries to the
> ntemacs project on sourceforge... They are the latest version, but
> they also install at the right place but look for the core file at the
> wrong place and print the annoying message even on --noinform.
>
> To run SBCL, I use a sbcl.bat file with this line:
> @"c:\Program Files\Steel Bank Common Lisp\1.0.47\sbcl.exe" --core
> "c:\Program Files\Steel Bank Common Lisp\1.0.47\sbcl.core" %*
>
> Also, the quoting of spaces and/or quotes in command-lines created by
> run-program seem somewhat dysfunctional, as examplified by this test:
>
> sbcl --load test
>
> (format t "Hello, World!~&")
> (load "h:\\cl\\xcvb\\master.lisp")
> (in-package :xcvbm)
> (format t "Blah: ~A~%" (run-program/read-output-string '("cmd" "/c"
> "echo" "1 2" "2" "3")))
> (format t "Bloh: ~A~%" (run-program/read-output-string '("c:\\Program
> Files\\Steel Bank Common Lisp\\sbcl.bat" "--noinform" "--eval"
> "(progn(princ(lisp-implementation-version))(terpri)(sb-ext:quit))")))
> (format t "Bleh: ~A~%" (run-program/read-output-string '("c:\\Program
> Files\\Steel Bank Common Lisp\\sbcl.bat" "--noinform" "--eval"
> "(progn(format t \"Blih! ~A~%\")
> (lisp-implementation-version))(sb-ext:quit))")))
> (sb-ext:quit)
>
> Remarkably, the Blah test displays Blah: "1 2" 2 3 (mind the
> interesting quoting), the Bloh test succeeds, and the Bleh test fails
> with a suggestion that in that case quoting failed:
>
> 'c:/Program' is not recognized as an internal or external command,
> operable program or batch file.
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics |
> http://fare.tunes.org ]
> The fear of death follows from the fear of life. A man who lives fully is
> prepared to die at any time. — Mark Twain
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

Thread view

I tried to use the windows installer for SBCL as advertised on sbcl.org.
* It installs stuff in c:\Program Files\Steel Bank Common Lisp\1.0.37\
which is fine, but the sbcl.exe there expects a core file in
/usr/local/lib/sbcl. Oops.
* --noinform doesn't get rid of the message concerning Kittens of Death.
Could some windows developer solve these issues in a new packaging?
Maybe using a more recent version of SBCL, too.
I see that yamaraj has uploaded more recent SBCL binaries to the
ntemacs project on sourceforge... They are the latest version, but
they also install at the right place but look for the core file at the
wrong place and print the annoying message even on --noinform.
To run SBCL, I use a sbcl.bat file with this line:
@"c:\Program Files\Steel Bank Common Lisp\1.0.47\sbcl.exe" --core
"c:\Program Files\Steel Bank Common Lisp\1.0.47\sbcl.core" %*
Also, the quoting of spaces and/or quotes in command-lines created by
run-program seem somewhat dysfunctional, as examplified by this test:
sbcl --load test
(format t "Hello, World!~&")
(load "h:\\cl\\xcvb\\master.lisp")
(in-package :xcvbm)
(format t "Blah: ~A~%" (run-program/read-output-string '("cmd" "/c"
"echo" "1 2" "2" "3")))
(format t "Bloh: ~A~%" (run-program/read-output-string '("c:\\Program
Files\\Steel Bank Common Lisp\\sbcl.bat" "--noinform" "--eval"
"(progn(princ(lisp-implementation-version))(terpri)(sb-ext:quit))")))
(format t "Bleh: ~A~%" (run-program/read-output-string '("c:\\Program
Files\\Steel Bank Common Lisp\\sbcl.bat" "--noinform" "--eval"
"(progn(format t \"Blih! ~A~%\")
(lisp-implementation-version))(sb-ext:quit))")))
(sb-ext:quit)
Remarkably, the Blah test displays Blah: "1 2" 2 3 (mind the
interesting quoting), the Bloh test succeeds, and the Bleh test fails
with a suggestion that in that case quoting failed:
'c:/Program' is not recognized as an internal or external command,
operable program or batch file.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The fear of death follows from the fear of life. A man who lives fully is
prepared to die at any time. — Mark Twain

For the correct core lookup, set SBCL_HOME env. variable to c:\Program
Files\Steel Bank Common Lisp\1.0.37\
Kittens of Death is already reported in LP.
The last failure is due to the launcher program sensitivity to spaces, so it
thinks that C:/Program is a path to the application, and the rest components
are arguments. Quoting the full path should help.
Regards,
Roman
2011/4/14 Faré <fahree@...>
> I tried to use the windows installer for SBCL as advertised on sbcl.org.
>
> * It installs stuff in c:\Program Files\Steel Bank Common Lisp\1.0.37\
> which is fine, but the sbcl.exe there expects a core file in
> /usr/local/lib/sbcl. Oops.
> * --noinform doesn't get rid of the message concerning Kittens of Death.
>
> Could some windows developer solve these issues in a new packaging?
> Maybe using a more recent version of SBCL, too.
>
> I see that yamaraj has uploaded more recent SBCL binaries to the
> ntemacs project on sourceforge... They are the latest version, but
> they also install at the right place but look for the core file at the
> wrong place and print the annoying message even on --noinform.
>
> To run SBCL, I use a sbcl.bat file with this line:
> @"c:\Program Files\Steel Bank Common Lisp\1.0.47\sbcl.exe" --core
> "c:\Program Files\Steel Bank Common Lisp\1.0.47\sbcl.core" %*
>
> Also, the quoting of spaces and/or quotes in command-lines created by
> run-program seem somewhat dysfunctional, as examplified by this test:
>
> sbcl --load test
>
> (format t "Hello, World!~&")
> (load "h:\\cl\\xcvb\\master.lisp")
> (in-package :xcvbm)
> (format t "Blah: ~A~%" (run-program/read-output-string '("cmd" "/c"
> "echo" "1 2" "2" "3")))
> (format t "Bloh: ~A~%" (run-program/read-output-string '("c:\\Program
> Files\\Steel Bank Common Lisp\\sbcl.bat" "--noinform" "--eval"
> "(progn(princ(lisp-implementation-version))(terpri)(sb-ext:quit))")))
> (format t "Bleh: ~A~%" (run-program/read-output-string '("c:\\Program
> Files\\Steel Bank Common Lisp\\sbcl.bat" "--noinform" "--eval"
> "(progn(format t \"Blih! ~A~%\")
> (lisp-implementation-version))(sb-ext:quit))")))
> (sb-ext:quit)
>
> Remarkably, the Blah test displays Blah: "1 2" 2 3 (mind the
> interesting quoting), the Bloh test succeeds, and the Bleh test fails
> with a suggestion that in that case quoting failed:
>
> 'c:/Program' is not recognized as an internal or external command,
> operable program or batch file.
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics |
> http://fare.tunes.org ]
> The fear of death follows from the fear of life. A man who lives fully is
> prepared to die at any time. — Mark Twain
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

On 14 April 2011 00:47, Roman Marynchak <roman.marynchak@...> wrote:
> For the correct core lookup, set SBCL_HOME env. variable to c:\Program
> Files\Steel Bank Common Lisp\1.0.37\
>
It would be nice for the default value to be more sensible than
/usr/local/lib/sbcl
and/or for the installer to fix up a registry entry, environment variable, etc.
> Kittens of Death is already reported in LP.
OK. Is there a semi-official maintainer for Windows?
> The last failure is due to the launcher program sensitivity to spaces, so it
> thinks that C:/Program is a path to the application, and the rest components
> are arguments. Quoting the full path should help.
Maybe. But interestingly, the first attempt, which calls SBCL with
space-less arguments, works fine. So why in one case it works and in
the other it doesn't, seems interesting.
Thanks to all the hackers here for SBCL!
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Boxer’s law of economics: “The economy interprets taxation and regulation as
damage and routes around it.” — Jessica Boxer, http://esr.ibiblio.org/?p=1752

>
>
>
> OK. Is there a semi-official maintainer for Windows?
>
> I don't think so. There are many Windows features (x64 port, threads + some
fixes) which are forks during the long period of time. People who use them
find these features to be working.
IMHO, it is better to have at least "experimental" features than to wait
years for the stable ones. Any software system has bugs. The current Windows
port cannot be spoiled by these changes, and SBCL community needs to be more
open in such cases, encouraging people to merge the code, giving them the
commit access, etc. The people who maintain Win64 forks could be excellent
Windows maintainers, just let them get rid of the forks and move the code to
the main tree. Maybe I am wrong here, but it seems to be the optimal way to
boost the "SBCL for Windows" development and attract more developers.
Regards,
Roman