[Openmcl-devel] I frequently run into this problem doing a wildcarded directory listing on windows in1.9-r15765 (WindowsX8664)

[Kalman Reti]

On Sat, Jun 22, 2013 at 2:11 PM, Gary Byers <gb at clozure.com> wrote:

> At first glance, I suspected that this was a mundane bug in (apparently)
> rarely-executed code and that the bug involved some confusion as to
> whether the macro CCL::UTF-16-COMBINE-SURROGATE-**PAIRS returned a
> character or a character-code.
>

There seems to be a difference of opinion on how many astral planes are
legal
in Unicode. The problematic character is the first one in the
"Supplementary Ideographic
Pane" as shown in https://en.wikipedia.org/wiki/Unicode which extends from
0x20000 to
0x2FFFF.

Perhaps this is what you meant, but I couldn't quite turn your sentence
above into
something that seems to correspond...


> On learning that it's actually a result of a failure to adhere to the
> principle that says "DIRECTORY should always return the next entry, even
> if bugs in the code prevent it from processing filenames correctly" ...
> well, let's just say that I'm as filled with moral outrage as the next
> guy.  (Maybe even more filled.)
>
> Such moments of moral clarity (or, now that I think of it, any other
> kind of clarity) are sadly all too rare; I'd barely begun to savor this
> one before a voice in the back of my head started saying "Idiot!  Why
> don't you just fix the bug ?  And watch where you're driving!"
>
> I suspect that that voice will win out, and that a fix for this bug
> will be committed to the trunk and propagated to 1.9 after a bit of
> smoke-testing.


Thanks.


>
> On Sat, 22 Jun 2013, Kalman Reti wrote:
>
>  On Sat, Jun 22, 2013 at 7:47 AM, Kalman Reti <kalman.reti at gmail.com>
>> wrote:
>>       and I cannot figure out a way past it:
>>
>>
>> In windows explorer the file name shows up as:
>>
>> execute-button-app_??.pet_**2013-06-11-09-42-21_28472.dom
>>
>>
>> which I'm not sure will get through html, but after app_ there is a
>> c-cedilla, an
>> umbrella-looking character and a funny Korean-looking glyph that looks
>> like
>> a
>> conjoined lowercase h and backwards capital L rotated ninety-degrees
>> clockwise.
>>
>
It is this last character that is causing the problem; it is indeed U+20000.


>
>> Clearly something weird happened when that file was created, but its
>> existence should
>> not make it impossible to enumerate a directory, should it??
>>
>> ? (length (setq all (directory "c:/Foobarwork/2013-06-11/*.*"**)))
>> > Error: The value #\U+20000 is not of the expected type (MOD
>> 1114112).
>> > While executing: CCL::%GET-NATIVE-UTF-16-**CSTRING, in process
>> listener(1).
>> > Type :POP to abort, :R for a list of available restarts.
>> > Type :? for other options.
>> 1 > :b
>> *(22429728) : 0 (%GET-NATIVE-UTF-16-CSTRING #<A Foreign Pointer
>> #x6019AC>) 687
>> ?(224297C0) : 1 (GET-FOREIGN-NAMESTRING #<A Foreign Pointer #x6019AC>)
>> 37
>> ?(224297D8) : 2 (%READ-DIR 78) 181
>> ?(224297F0) : 3 (%FILES-IN-DIRECTORY "/Foobarwork/2013-06-11/"
>>
>> #P"c:/Foobarwork/2013-06-11/*.***" 150 (:DIRECTORIES T :FILES T :ALL
>> ...) #S(CCL::DIRECTORY-RESULT :TRUENAMES #<HASH-TABLE :TEST STRING=
>> size 23/60 #x21034A397D> :DIRECTORIES-SEEN
>> ("c:/Foobarwork/2013-06-11/"))**) 2613
>> ?(224298E0) : 4 (DIRECTORY "c:/Foobarwork/2013-06-11/*.*" :DIRECTORIES
>>
>> T :FILES T :ALL T :DIRECTORY-PATHNAMES T :INCLUDE-EMACS-LOCKFILES NIL
>> :TEST NIL :FOLLOW-LINKS T) 677
>> ?(22429990) : 5 (CALL-CHECK-REGS DIRECTORY
>> "c:/Foobarwork/2013-06-11/*.*"**) 221
>> ?(224299C8) : 6 (CHEAP-EVAL-IN-ENVIRONMENT ((DIRECTORY
>>
>> "c:/Foobarwork/2013-06-11/*.*"**)) NIL) 1805
>> ?(22429A18) : 7 (CHEAP-EVAL-IN-ENVIRONMENT (LENGTH (SETQ ALL #)) NIL)
>> 3453
>> ?(22429A68) : 8 (TOPLEVEL-EVAL (LENGTH (SETQ ALL #)) NIL) 693
>> ?(22429B00) : 9 (READ-LOOP :INPUT-STREAM #<SYNONYM-STREAM to
>>
>> *TERMINAL-IO* #x210069DFFD> :OUTPUT-STREAM #<SYNONYM-STREAM to
>> *TERMINAL-IO* #x210069DE9D> :BREAK-LEVEL 0 :PROMPT-FUNCTION
>> #<Compiled-function (:INTERNAL CCL::READ-LOOP) (Non-Global)
>> ?#x100518CEF>) 2261
>> ?(22429D58) : 10 (RUN-READ-LOOP :BREAK-LEVEL 0) 157
>> ?(22429D80) : 11 (TOPLEVEL-LOOP) 101
>> ?(22429DA8) : 12 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION
>>
>> (CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 101
>> ?(22429DC8) : 13 (FUNCALL #'#<(:INTERNAL
>> CCL::MAKE-MCL-LISTENER-**PROCESS)>) 645
>> ?(22429E60) : 14 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1)
>>
>> [Active] #x210069CC7D> (#<COMPILED-LEXICAL-CLOSURE # #x210069C7AF>))
>> 669
>> ?(22429EF0) : 15 (FUNCALL #'#<(:INTERNAL
>>
>> (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> #<TTY-LISTENER listener(1)
>> [Active] #x210069CC7D> (#<COMPILED-LEXICAL-CLOSURE # #x210069C7AF>))
>> 573
>> ?(22429F98) : 16 (FUNCALL #'#<(:INTERNAL
>> CCL::THREAD-MAKE-STARTUP-**FUNCTION)>) 277
>> 1 >?
>>
>>
>> The directory in question has vanilla-looking (if somewhat long)
>> pathnames. ?The problem is that
>
>
I was obviously wrong about the vanilla-looking part; serves me right for
depending upon emacs's dired (which ignores the offending file).

>
>> I cannot find a way to skip the offending entry and continue with the
>> rest of the wildcard
>> directory listing. ?Is there such a way that I am missing?
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130622/dcf7bf36/attachment.htm>