Hello,
I wanted to test closure-html so I installed and attempted to load it in LispWorks 6 on Windows.
CL-USER 3 > (asdf:load-system 'closure-html)
Error: External format (:UTF-8 :EOL-STYLE :LF) produces characters of type SIMPLE-CHAR, which is not a subtype of the specified element-type BASE-CHAR. 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
CL-USER 4 : 1 > :b Call to ERROR Call to STREAM::EXTERNAL-FORMAT-STREAM-DEFAULTED-ELEMENT-TYPE Call to STREAM::EXTERNAL-FORMAT-OPEN Call to OPEN Call to ASDF:FIND-SYSTEM Call to ASDF:OPERATE Call to ASDF:LOAD-SYSTEM Call to EVAL Call to CAPI::CAPI-TOP-LEVEL-FUNCTION Call to CAPI::INTERACTIVE-PANE-TOP-LOOP Call to MP::PROCESS-SG-FUNCTION
CL-USER 5 : 1 >
This diff corrects it for me. I don't have another lisp to test it immediately to see if this needs to be conditional.
--- a/system/asdf/asdf.lisp +++ b/system/asdf/asdf.lisp @@ -1022,7 +1022,7 @@ to `~a` which is not a directory.~@:>" (< (car in-memory) (safe-file-write-date on-disk)))) (let ((package (make-temporary-package))) (unwind-protect - (with-open-file (asd on-disk :if-does-not-exist nil) + (with-open-file (asd on-disk :if-does-not-exist nil :element-type :default) (if asd (let ((*package* package)) (asdf-message
Is this correct or is there something broken on my end?
Can anyone remind me why we are not just using probe-file there??? To make sure we have read permissions? But if we don't, we DESERVE to lose, and erroring out later would be a GOOD THING.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Tradition is the matter of which civilization is made. Anyone who rejects tradition per se should be left naked in a desert island. — Faré
On 27 March 2010 11:32, Futu Ranon futuranon@gmail.com wrote:
Hello,
I wanted to test closure-html so I installed and attempted to load it in LispWorks 6 on Windows.
CL-USER 3 > (asdf:load-system 'closure-html)
Error: External format (:UTF-8 :EOL-STYLE :LF) produces characters of type SIMPLE-CHAR, which is not a subtype of the specified element-type BASE-CHAR. 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
CL-USER 4 : 1 > :b Call to ERROR Call to STREAM::EXTERNAL-FORMAT-STREAM-DEFAULTED-ELEMENT-TYPE Call to STREAM::EXTERNAL-FORMAT-OPEN Call to OPEN Call to ASDF:FIND-SYSTEM Call to ASDF:OPERATE Call to ASDF:LOAD-SYSTEM Call to EVAL Call to CAPI::CAPI-TOP-LEVEL-FUNCTION Call to CAPI::INTERACTIVE-PANE-TOP-LOOP Call to MP::PROCESS-SG-FUNCTION
CL-USER 5 : 1 >
This diff corrects it for me. I don't have another lisp to test it immediately to see if this needs to be conditional.
--- a/system/asdf/asdf.lisp +++ b/system/asdf/asdf.lisp @@ -1022,7 +1022,7 @@ to `~a` which is not a directory.~@:>" (< (car in-memory) (safe-file-write-date on-disk)))) (let ((package (make-temporary-package))) (unwind-protect - (with-open-file (asd on-disk :if-does-not-exist nil) + (with-open-file (asd on-disk :if-does-not-exist nil :element-type :default) (if asd (let ((*package* package)) (asdf-message
Is this correct or is there something broken on my end?
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Samium,
you're the one who seemingly introduced this with-open-file in 2ca05589. Why do we need such a fancy and not-that-portable way of testing the file is there? Or why do we care to fail with our own error message, when LOAD will probably issue its own? If for whatever reason you *really* care about getting a system-definition-error, you can just handler-bind, encapsulate the error from LOAD (which could be many more things), and re-raise the sysdef error. But why oh why? Who cares to catch that error? Does desire?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Men, it has been well said, think in herds; it will be seen that they go mad in herds, while they only recover their senses slowly, and one by one. — Charles Mackay
Can anyone remind me why we are not just using probe-file there??? To make sure we have read permissions? But if we don't, we DESERVE to lose, and erroring out later would be a GOOD THING.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Tradition is the matter of which civilization is made. Anyone who rejects tradition per se should be left naked in a desert island. — Faré
On 27 March 2010 11:32, Futu Ranon futuranon@gmail.com wrote:
Hello,
I wanted to test closure-html so I installed and attempted to load it in LispWorks 6 on Windows.
CL-USER 3 > (asdf:load-system 'closure-html)
Error: External format (:UTF-8 :EOL-STYLE :LF) produces characters of type SIMPLE-CHAR, which is not a subtype of the specified element-type BASE-CHAR. 1 (abort) Return to level 0. 2 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
CL-USER 4 : 1 > :b Call to ERROR Call to STREAM::EXTERNAL-FORMAT-STREAM-DEFAULTED-ELEMENT-TYPE Call to STREAM::EXTERNAL-FORMAT-OPEN Call to OPEN Call to ASDF:FIND-SYSTEM Call to ASDF:OPERATE Call to ASDF:LOAD-SYSTEM Call to EVAL Call to CAPI::CAPI-TOP-LEVEL-FUNCTION Call to CAPI::INTERACTIVE-PANE-TOP-LOOP Call to MP::PROCESS-SG-FUNCTION
CL-USER 5 : 1 >
This diff corrects it for me. I don't have another lisp to test it immediately to see if this needs to be conditional.
--- a/system/asdf/asdf.lisp +++ b/system/asdf/asdf.lisp @@ -1022,7 +1022,7 @@ to `~a` which is not a directory.~@:>" (< (car in-memory) (safe-file-write-date on-disk)))) (let ((package (make-temporary-package))) (unwind-protect - (with-open-file (asd on-disk :if-does-not-exist nil) + (with-open-file (asd on-disk :if-does-not-exist nil :element-type :default) (if asd (let ((*package* package)) (asdf-message
Is this correct or is there something broken on my end?
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On Sat, 27 Mar 2010 12:44:08 -0400, Faré fahree@gmail.com wrote:
Samium,
you're the one who seemingly introduced this with-open-file in 2ca05589. Why do we need such a fancy and not-that-portable way of testing the file is there?
PROBE-FILE fails to catch dead symlinks, and I need a meaningful condition from which I can deduce /what/ is being failed upon, whereas the subtype of FILE-ERROR used by, for example, SBCL, doesn't give me this information.
regards, Samium Gromoff -- "Actually I made up the term 'object-oriented', and I can tell you I did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)
There is no portable way to distinguish between the many filesystem errors, anyway. Is there a good reason to not let LOAD report whatever error it wants?
Otherwise, we could use this function: (defun file-readable-p (path) (with-open-file (s path :direction :input :if-does-not-exist nil :element-type '(unsigned-byte 8)) (and s t)))
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Only presidents, editors, and people with tapeworms have the right to use the editorial "we." — Mark Twain
On 28 March 2010 19:04, Samium Gromoff _deepfire@feelingofgreen.ru wrote:
On Sat, 27 Mar 2010 12:44:08 -0400, Faré fahree@gmail.com wrote:
Samium,
you're the one who seemingly introduced this with-open-file in 2ca05589. Why do we need such a fancy and not-that-portable way of testing the file is there?
PROBE-FILE fails to catch dead symlinks, and I need a meaningful condition from which I can deduce /what/ is being failed upon, whereas the subtype of FILE-ERROR used by, for example, SBCL, doesn't give me this information.
regards, Samium Gromoff
On Sun, 28 Mar 2010 19:08:27 -0400, Faré fahree@gmail.com wrote:
There is no portable way to distinguish between the many filesystem errors, anyway. Is there a good reason to not let LOAD report whatever error it wants?
Hmm, LOAD is specified to raise a FILE-ERROR upon failure and I missed that SBCL's SIMPLE-FILE-ERROR is a subtype of it, so we get the failed upon pathname.
The status quo is that currently ASDF provides the name of the system in the condition, which we'd have to deduce from the pathname, if we were to let LOAD do the error checking.
In the cases of SBCL, ECL and CLisp FILE-ERROR-PATHNAME on a dead symlink is reasonable and returns the pathname of the dead symlink, not what it points to.
But there is something that bothers me still, as there are those multiple-systems-per-file .asd files, which makes pathname->system mapping less trivial. How much this makes a problem in the real life I cannot tell, just that it might be one in general.
In the end, I'm not sure, it's been long since I touched desire.
On 3/29/10 Mar 29 -4:38 PM, Samium Gromoff wrote:
On Sun, 28 Mar 2010 19:08:27 -0400, Faré fahree@gmail.com wrote:
There is no portable way to distinguish between the many filesystem errors, anyway. Is there a good reason to not let LOAD report whatever error it wants?
Hmm, LOAD is specified to raise a FILE-ERROR upon failure and I missed that SBCL's SIMPLE-FILE-ERROR is a subtype of it, so we get the failed upon pathname.
The status quo is that currently ASDF provides the name of the system in the condition, which we'd have to deduce from the pathname, if we were to let LOAD do the error checking.
In the cases of SBCL, ECL and CLisp FILE-ERROR-PATHNAME on a dead symlink is reasonable and returns the pathname of the dead symlink, not what it points to.
But there is something that bothers me still, as there are those multiple-systems-per-file .asd files, which makes pathname->system mapping less trivial. How much this makes a problem in the real life I cannot tell, just that it might be one in general.
In the end, I'm not sure, it's been long since I touched desire.
Is there some reason why the other choice mentioned --- catching an error from load and then re-signaling it with the additional information about the system --- cannot be used?
Best, R
On Tue, 30 Mar 2010 09:00:55 -0500, Robert Goldman rpgoldman@sift.info wrote:
Is there some reason why the other choice mentioned --- catching an error from load and then re-signaling it with the additional information about the system --- cannot be used?
Sorry that I didn't make it clear, no there's no reason at all.
On Tue, 30 Mar 2010 21:02:23 +0400, Samium Gromoff _deepfire@feelingofgreen.ru wrote:
On Tue, 30 Mar 2010 09:00:55 -0500, Robert Goldman rpgoldman@sift.info wrote:
Is there some reason why the other choice mentioned --- catching an error from load and then re-signaling it with the additional information about the system --- cannot be used?
Sorry that I didn't make it clear, no there's no reason at all.
Actually nevermind, I was entirely confused and thereby needlessly confusing in the previous mail -- I, for some reason assumed that changing the status quo implies we'd have to get rid of the precise condition.
Yes, there's entirely no reason for not catching FILE-ERROR /within/ ASDF, instead of proactively preventing it (in a racy manner).
-
Faré -
Futu Ranon -
Robert Goldman -
Samium Gromoff