freenode/#lisp - IRC Chatlog
Search
4:57:03
tourjin
on windows10, windowsemacs with slime, if i run this it creates output file on c:\users\choij not on d:\home where can I check the settings for default file creation?
4:59:22
no-defun-allowed
Probably where you started your Lisp implementation. You may want merge-pathnames and user-homedir-pathname to ensure you are writing to your home directory.
4:59:49
no-defun-allowed
e.g (with-open-file (stream (merge-pathnames "testfile.txt" (user-homedir-pathname)) ...) ...)
5:00:50
no-defun-allowed
Josh_2: I don't wear glasses surprisingly, but if it ticks you off, I can polish them all day.
5:09:06
tourjin
no-defun-allowed , your tip worked fine . thanks. ck_ your tip shows #P"c:/Users/choij". is it determined by emacs? or by slime? how can I change it permanantly to d:/home?
5:09:41
no-defun-allowed
The CLHS page states "An implementation-dependent pathname, typically in the working directory that was current when Common Lisp was started up."
7:09:44
ArthurStrong
It's character name from the TV series. https://en.wikipedia.org/wiki/Count_Arthur_Strong_(TV_series)
10:41:31
froggey
can (locally (declare (type fixnum *unbound-special-variable*)) nil) signal an unbound variable error?
10:41:40
froggey
from the TYPE declaration page: "The meaning of a type declaration is equivalent to [...] executing (the typespec var) at the moment the scope of the declaration is entered."
11:04:06
froggey
(locally (the fixnum *unbound-special*) nil) does, which I'd expect to be equivalent
11:06:50
phoe
froggey: in that case file a SBCL issue, since it's likely an issue with SBCL's approach "treat type declarations as assertions"
11:14:15
froggey
it's not just SBCL, this is how other implementation behave too. (the <type> *unbound*) signals an error, but (declare (type <type> *unbound*)) doesn't
11:14:57
froggey
I'm wondering if it is reasonable for an implementation to have the declare signal an unbound variable error too
11:19:53
phoe
only if the variable is tried to be accessed an unbound variable error is to be signaled
11:21:27
froggey
it's equivalent to (defun foo () (the fixnum *foo*) (if (frob) (the fixnum *foo*) *bar*))
11:22:09
froggey
on variable reads, writes, *and* on entry to the scope that the declaration applies to
11:23:14
phoe
so it is normal that at the entry to the function toplevel SBCL complains about unbound variable
11:23:53
phoe
you want (defun foo () (if (frob) (locally (declare (fixnum *foo*)) *foo* *bar)) instead
11:26:13
froggey
SBCL *currently* does (defun foo () (if (frob) (the fixnum *foo*) *bar*)), not what I said
11:26:42
froggey
I'm wondering if my reading of the spec, which would allow an implementation to do (defun foo () (the fixnum *foo*) (if (frob) (the fixnum *foo*) *bar*)), is correct
11:28:10
phoe
I'm not able to pay too much energy towards checking this one - I'm fighting the spec on another field
11:44:57
jackdaniel
froggey: I think I've read somewhere that declarations are hints for the compiler and it doesn't have to take that into account (also, if the declarations is invalid then it is an undefined behavior)
11:46:04
jackdaniel
i.e when type is declared, compiler is entitled to assume that declaration is correct and i.e inline accesses for the particular data type without checking for the type. that said sbcl i.e expands such declaration into check-type if it doesn't know for sure what the type is
11:46:19
jackdaniel
ecl otoh on low safety settings will take that at face value and segfault on invalid declaration
11:59:05
froggey
point 3 from the TYPE page: "At the moment the scope of the declaration is entered, the consequences are undefined if the value of the declared variable is not of the declared type."
12:01:07
jackdaniel
compiler could expand this declaration to (the fixnum *foo*), if it is bound to fixnum then behavior is no different compared to a situation when such declaration does not exist
12:02:02
froggey
that's what I was thinking, but I can't find an implementation that does this, so I was a bit concerned