On Sat, Jun 22, 2013 at 2:11 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At first glance, I suspected that this was a mundane bug in (apparently)<br>
rarely-executed code and that the bug involved some confusion as to whether the macro CCL::UTF-16-COMBINE-SURROGATE-<u></u>PAIRS returned a<br>
character or a character-code.<br></blockquote><div><br></div><div>There seems to be a difference of opinion on how many astral planes are legal</div><div>in Unicode. The problematic character is the first one in the "Supplementary Ideographic</div>
<div>Pane" as shown in <a href="https://en.wikipedia.org/wiki/Unicode" target="_blank">https://en.wikipedia.org/wiki/Unicode</a> which extends from 0x20000 to</div><div>0x2FFFF.</div><div><br></div><div>Perhaps this is what you meant, but I couldn't quite turn your sentence above into</div>
<div>something that seems to correspond...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On learning that it's actually a result of a failure to adhere to the<br>
principle that says "DIRECTORY should always return the next entry, even<br>
if bugs in the code prevent it from processing filenames correctly" ...<br>
well, let's just say that I'm as filled with moral outrage as the next<br>
guy. (Maybe even more filled.)<br>
<br>
Such moments of moral clarity (or, now that I think of it, any other<br>
kind of clarity) are sadly all too rare; I'd barely begun to savor this<br>
one before a voice in the back of my head started saying "Idiot! Why<br>
don't you just fix the bug ? And watch where you're driving!"<br>
<br>
I suspect that that voice will win out, and that a fix for this bug<br>
will be committed to the trunk and propagated to 1.9 after a bit of<br>
smoke-testing.</blockquote><div><br></div><div>Thanks.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
On Sat, 22 Jun 2013, Kalman Reti wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Sat, Jun 22, 2013 at 7:47 AM, Kalman Reti <<a href="mailto:kalman.reti@gmail.com" target="_blank">kalman.reti@gmail.com</a>> wrote:<br>
and I cannot figure out a way past it:<br>
<br>
<br>
In windows explorer the file name shows up as:<br>
<br></div>
execute-button-app_??.pet_<u></u>2013-06-11-09-42-21_28472.dom<div><br>
<br>
which I'm not sure will get through html, but after app_ there is a<br>
c-cedilla, an<br>
umbrella-looking character and a funny Korean-looking glyph that looks like<br>
a<br>
conjoined lowercase h and backwards capital L rotated ninety-degrees<br>
clockwise.<br></div></blockquote></blockquote><div><br></div><div>It is this last character that is causing the problem; it is indeed U+20000.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
Clearly something weird happened when that file was created, but its<br>
existence should<br>
not make it impossible to enumerate a directory, should it??<br>
<br>
? (length (setq all (directory "c:/Foobarwork/2013-06-11/*.*"<u></u>)))<br>
> Error: The value #\U+20000 is not of the expected type (MOD<br>
1114112).<br>
> While executing: CCL::%GET-NATIVE-UTF-16-<u></u>CSTRING, in process<br>
listener(1).<br>
> Type :POP to abort, :R for a list of available restarts.<br>
> Type :? for other options.<br>
1 > :b<br>
*(22429728) : 0 (%GET-NATIVE-UTF-16-CSTRING #<A Foreign Pointer<br>
#x6019AC>) 687<br></div>
?(224297C0) : 1 (GET-FOREIGN-NAMESTRING #<A Foreign Pointer #x6019AC>)<br>
37<br>
?(224297D8) : 2 (%READ-DIR 78) 181<br>
?(224297F0) : 3 (%FILES-IN-DIRECTORY "/Foobarwork/2013-06-11/"<div><br>
#P"c:/Foobarwork/2013-06-11/*.<u></u>*" 150 (:DIRECTORIES T :FILES T :ALL<br>
...) #S(CCL::DIRECTORY-RESULT :TRUENAMES #<HASH-TABLE :TEST STRING=<br>
size 23/60 #x21034A397D> :DIRECTORIES-SEEN<br>
("c:/Foobarwork/2013-06-11/"))<u></u>) 2613<br></div>
?(224298E0) : 4 (DIRECTORY "c:/Foobarwork/2013-06-11/*.*" :DIRECTORIES<div><br>
T :FILES T :ALL T :DIRECTORY-PATHNAMES T :INCLUDE-EMACS-LOCKFILES NIL<br>
:TEST NIL :FOLLOW-LINKS T) 677<br></div>
?(22429990) : 5 (CALL-CHECK-REGS DIRECTORY<br>
"c:/Foobarwork/2013-06-11/*.*"<u></u>) 221<br>
?(224299C8) : 6 (CHEAP-EVAL-IN-ENVIRONMENT ((DIRECTORY<div><br>
"c:/Foobarwork/2013-06-11/*.*"<u></u>)) NIL) 1805<br></div>
?(22429A18) : 7 (CHEAP-EVAL-IN-ENVIRONMENT (LENGTH (SETQ ALL #)) NIL)<br>
3453<br>
?(22429A68) : 8 (TOPLEVEL-EVAL (LENGTH (SETQ ALL #)) NIL) 693<br>
?(22429B00) : 9 (READ-LOOP :INPUT-STREAM #<SYNONYM-STREAM to<div><br>
*TERMINAL-IO* #x210069DFFD> :OUTPUT-STREAM #<SYNONYM-STREAM to<br>
*TERMINAL-IO* #x210069DE9D> :BREAK-LEVEL 0 :PROMPT-FUNCTION<br>
#<Compiled-function (:INTERNAL CCL::READ-LOOP) (Non-Global)<br></div>
?#x100518CEF>) 2261<br>
?(22429D58) : 10 (RUN-READ-LOOP :BREAK-LEVEL 0) 157<br>
?(22429D80) : 11 (TOPLEVEL-LOOP) 101<br>
?(22429DA8) : 12 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION<div><br>
(CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 101<br></div>
?(22429DC8) : 13 (FUNCALL #'#<(:INTERNAL<br>
CCL::MAKE-MCL-LISTENER-<u></u>PROCESS)>) 645<br>
?(22429E60) : 14 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1)<div><br>
[Active] #x210069CC7D> (#<COMPILED-LEXICAL-CLOSURE # #x210069C7AF>))<br>
669<br></div>
?(22429EF0) : 15 (FUNCALL #'#<(:INTERNAL<div><br>
(CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> #<TTY-LISTENER listener(1)<br>
[Active] #x210069CC7D> (#<COMPILED-LEXICAL-CLOSURE # #x210069C7AF>))<br>
573<br></div>
?(22429F98) : 16 (FUNCALL #'#<(:INTERNAL<br>
CCL::THREAD-MAKE-STARTUP-<u></u>FUNCTION)>) 277<br>
1 >?<div><br>
<br>
The directory in question has vanilla-looking (if somewhat long)<br></div>
pathnames. ?The problem is that</blockquote></blockquote><div><br></div><div>I was obviously wrong about the vanilla-looking part; serves me right for</div><div>depending upon emacs's dired (which ignores the offending file). </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
I cannot find a way to skip the offending entry and continue with the<br>
rest of the wildcard<br></div>
directory listing. ?Is there such a way that I am missing?<br>
<br>
<br>
<br>
<br>
</blockquote>
</blockquote></div><br>