I have been using LispBox for a little under two months. I decided it
would be a good idea to switch over to SBCL, and to do that I followed
Robert Zubek's howto
>> http://robert.zubek.net/blog/2008/04/09/sbcl-emacs-windows-vista/
After a little fighting, I managed to get almost everything to run
perfectly. Everything except C-c C-c.
When I go to compile a file (as a non administrator user in Vista), i
get the error
> error opening #P"c:\\s3fg..lisp": Permission denied
> [Condition of type SB-INT:SIMPLE-FILE-ERROR]
>
>Restarts:
> 0: [ABORT] Return to SLIME's top level.
> 1: [CLOSE-CONNECTION] Close SLIME connection
> 2: [ABORT] Exit debugger, returning to top level.
>
>Backtrace:
> 0: (SB-IMPL::SIMPLE-FILE-PERROR "error opening ~S" #P"c:\s3fg..lisp" 13)
> 1: (SB-IMPL::SIMPLE-FILE-PERROR "error opening ~S" #P"c:\s3fg..lisp" 13)[:EXTERNAL]
> 2: ((LABELS SB-IMPL::VANILLA-OPEN-ERROR))
> 3: (OPEN "\s3fg..lisp")[:EXTERNAL]
> 4: ((LAMBDA (STRING &KEY SWANK-BACKEND::BUFFER POSITION DIRECTORY DEBUG)) ..)
> 5: ((LAMBDA ()))
> --more--
But, when I run emacs as 'Administrator' in Vista, it compiles fine.
I've never had an issue like this with LispBox, so I'm at a loss for
what is causing it or how to fix it.
Help please?
~Josh
On Dec 13, 3:27 pm, dydx <··············@gmail.com> wrote:
> I've never had an issue like this with LispBox, so I'm at a loss for
> what is causing it or how to fix it.
Slime is trying to create the temporary file in the root of your
drive, but your user account doesn't have permission to write there.
??>> error opening #P"c:\\s3fg..lisp": Permission denied
??>> [Condition of type SB-INT:SIMPLE-FILE-ERROR]
the problem is that it creates temporary files in wrong directory -- on
Windows
function tmpnam is sort of weird, returning pathes like \s3fg. that are
interpreted as
being in root dir.
you need to change temp-file-name function in slime-sbcl.lisp to fix this.
here's how this function is defined:
(defun temp-file-name ()
"Return a temporary file name to compile strings into."
(concatenate 'string (tmpnam nil) ".lisp"))
to make temp files in SBCL's current directory change it to this:
(concatenate 'string "." (tmpnam nil) ".lisp"))
or you can insert full path to any temp directory you wish, e.g.:
(concatenate 'string "c:\\users\\yourname\\temp" (tmpnam nil) ".lisp"))
of course you need to make sure this directory is writable
d> I decided it would be a good idea to switch over to SBCL,
by the way, it is not. SBCL on Windows is of alpha quality, port is still in
progress.
that means you're quite likely spend more time dealing with SBCL on Windows
bugs
rather than working with your code.
good idea would be to switch to Linux. you can run it under Vista via vmware
virtualization software.
Thanks for the help with that. I am finding SBCL a little funky at
times. I'm probably going to end up just setting CLISP as my inferior-
lisp-program.
~Josh
dydx wrote:
> Thanks for the help with that. I am finding SBCL a little funky at
> times. I'm probably going to end up just setting CLISP as my inferior-
> lisp-program.
As another option, I've heard good things about Corman lisp, and the
base compiler (i.e. not the IDE) appears to be free for personal use.
http://www.cormanlisp.com/license.html
And Allegro is available under not-overly-restrictive terms.
http://franz.com/downloads/allegrodownload.lhtml
- Daniel
On Dec 13, 4:27 pm, dydx <··············@gmail.com> wrote:
> I have been using LispBox for a little under two months. I decided it
> would be a good idea to switch over to SBCL, and to do that I followed
> Robert Zubek's howto
>
> >>http://robert.zubek.net/blog/2008/04/09/sbcl-emacs-windows-vista/
>
> After a little fighting, I managed to get almost everything to run
> perfectly. Everything except C-c C-c.
>
> When I go to compile a file (as a non administrator user in Vista), i
> get the error
>
>
>
> > error opening #P"c:\\s3fg..lisp": Permission denied
> > [Condition of type SB-INT:SIMPLE-FILE-ERROR]
>
> >Restarts:
> > 0: [ABORT] Return to SLIME's top level.
> > 1: [CLOSE-CONNECTION] Close SLIME connection
> > 2: [ABORT] Exit debugger, returning to top level.
>
> >Backtrace:
> > 0: (SB-IMPL::SIMPLE-FILE-PERROR "error opening ~S" #P"c:\s3fg..lisp" 13)
> > 1: (SB-IMPL::SIMPLE-FILE-PERROR "error opening ~S" #P"c:\s3fg..lisp" 13)[:EXTERNAL]
> > 2: ((LABELS SB-IMPL::VANILLA-OPEN-ERROR))
> > 3: (OPEN "\s3fg..lisp")[:EXTERNAL]
> > 4: ((LAMBDA (STRING &KEY SWANK-BACKEND::BUFFER POSITION DIRECTORY DEBUG)) ..)
> > 5: ((LAMBDA ()))
> > --more--
>
> But, when I run emacs as 'Administrator' in Vista, it compiles fine.
>
> I've never had an issue like this with LispBox, so I'm at a loss for
> what is causing it or how to fix it.
>
> Help please?
>
> ~Josh
It isn't a lisp/sbcl specific problem, per say, it is a 'Windows Vista
is terrible,' issue.
Pretty much Vista doesn't let you write a file anywhere that you do
not have specific rights to write to. This is OK (possibly great) for
security purposes, but terrible as soon as you want to actually do
something (software development, for example). In this example, sbcl
tries to write files out, and you get a directory not writable error.
This can be 'Fixed' easily by disabling 'User Access Control' in Vista
(one or two step process and easily Google'd).
HTH,
~ACL
acl> It isn't a lisp/sbcl specific problem, per say, it is a 'Windows Vista
acl> is terrible,' issue.
acl> Pretty much Vista doesn't let you write a file anywhere that you do
acl> not have specific rights to write to.
Linux won't allow regular users to write to / either. and neither will Mac
OS X.
and neither will Windows XP (unless you're working as admin). neither
FreeBSD or Solaris or whatever.
so all operating systems are terrible? no, it's more like you're an idiot.
acl> This is OK (possibly great) for security purposes, but terrible as
acl> soon as you want to actually do something (software development, for
acl> example). In this example, sbcl tries to write files out, and you get
acl> a directory not writable error.
how about writing files into proper directories, rather than scattering them
randomly over tbe filesystem?
this is SBCL/SLIME issue -- they generate temp files in a way that does not
correctly work on Windows.
On Dec 15, 5:34 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> acl> It isn't a lisp/sbcl specific problem, per say, it is a 'Windows Vista
> acl> is terrible,' issue.
>
> acl> Pretty much Vista doesn't let you write a file anywhere that you do
> acl> not have specific rights to write to.
>
> Linux won't allow regular users to write to / either. and neither will Mac
> OS X.
> and neither will Windows XP (unless you're working as admin). neither
> FreeBSD or Solaris or whatever.
>
> so all operating systems are terrible? no, it's more like you're an idiot.
>
> acl> This is OK (possibly great) for security purposes, but terrible as
> acl> soon as you want to actually do something (software development, for
> acl> example). In this example, sbcl tries to write files out, and you get
> acl> a directory not writable error.
>
> how about writing files into proper directories, rather than scattering them
> randomly over tbe filesystem?
>
> this is SBCL/SLIME issue -- they generate temp files in a way that does not
> correctly work on Windows.
Who shoved a stick up your ass?
Google 'user account control'.
I disabled it and that fixed it.
SBCL and slime are not the only applications that have trouble with
it.
This is a Vista specific problem.
acl> Who shoved a stick up your ass?
acl> Google 'user account control'.
acl> I disabled it and that fixed it.
acl> SBCL and slime are not the only applications that have trouble with
acl> it.
acl> This is a Vista specific problem.
this causes problems with applications that are badly written -- those which
try to write their files into places they are not supposed to.
for example, SBCL tries to write to #P"c:\\s3fg..lisp". do you think that
C:\
is the right place for temporary files? shouldn't it be a special TEMP
directory?
yes, you can fix this allowing SBCL to crap into any place it wants. on
unix-like systems it is equivalent to running as root, that is with all
possible
privileges. but is it a right solution?
please answer two questions above, your answers would be used to determine
if you're a complete idiot or if there is some hope you can understand
something.
note that one person have already added you to killfile, if you don't change
your
attitude to become more ignored in future.
On Dec 16, 5:44 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> acl> Who shoved a stick up your ass?
>
> acl> Google 'user account control'.
> acl> I disabled it and that fixed it.
> acl> SBCL and slime are not the only applications that have trouble with
> acl> it.
> acl> This is a Vista specific problem.
>
> this causes problems with applications that are badly written -- those which
> try to write their files into places they are not supposed to.
>
No. It also makes it so that you can't change the read protection on
certain volumes that are the correct place to write. You change the
read protection, vista automatically changes it back. It is a bug in
Vista.
> for example, SBCL tries to write to #P"c:\\s3fg..lisp". do you think that
> C:\
> is the right place for temporary files? shouldn't it be a special TEMP
> directory?
>
It also tries to write to user/you/workspace sometimes and can't write
to it either.
> yes, you can fix this allowing SBCL to crap into any place it wants. on
> unix-like systems it is equivalent to running as root, that is with all
> possible
> privileges. but is it a right solution?
>
It is currently the only solution for running SBCL on Vista.
> please answer two questions above, your answers would be used to determine
> if you're a complete idiot or if there is some hope you can understand
> something.
> note that one person have already added you to kill file, if you don't change
> your
> attitude to become more ignored in future.
This is asinine. I've been added to the kill file of someone who was
very insulting in responding to me after having been trying to
contribute constructively to this newsgroup for over 2 months. He
could dish it out but he couldn't take it, apparently. Go ahead and
add me to your kill file too.