Oh, I forget to tell that C wrapper version doesn't have locale problem. And according to the commit log, seems we may expect it completely fixed in 2.0.4?
On Tue, Dec 20, 2011 at 11:23 AM, Nala Ginrut <[email protected]> wrote: > > > On Tue, Dec 20, 2011 at 5:38 AM, Ludovic Courtès <[email protected]> wrote: > >> Hi Nala! >> >> Thanks for testing! >> >> Nala Ginrut <[email protected]> skribis: >> >> > 1. I think file-system-fold based scandir tried to traverse the whole >> > directories include sub-directories. It's rather slow for a deep one if >> I >> > just >> > want a files list under 0 level directory tree; >> >> The code had initially approximately 1 typo per line, and I think I’ve >> fixed most of them now. ;-) >> >> So ‘scandir’ does not enter sub-directories. If it does, that’s another >> bug. :-) >> >> > 2. New scandir will crash while encounters a Chinese file name. This >> will >> > be eliminated by using (setlocale LC_ALL "zh_CN.UTF-8"). >> > I think it's the same problem we faced in another thread. There's >> > something locale problem in Guile. Of course, we have a temporary >> solution >> > in recent commit; >> >> Yes, Guile views file names as strings and decodes them from the current >> locale encoding. So if there are file names encoded differently, then >> scm_from_locale_string, called by ‘readdir’, throws a decoding-error. >> >> That’s unfortunate, I’m not sure what to do. I think GLib/GIO issues a >> warning in such cases, while still being able to handle the file. We >> could imagine ‘readdir’ returning a raw bytevector when decoding fails, >> and ‘open-file’ & co. could accept it as input. But that’s really ugly. >> >> I think Mark had some ideas about it, which would be worth checking. >> >> > 3. It returns weird result. E.g (scandir "mmr") >> > ==> ("." "." "." ".." ".." ".." "aa.c" "exclude" "ml" "myecl") >> >> One of the typos that got fixed, hopefully. :-) >> >> Can you check again? >> >> > Anyway, I think new scandir's cool. Though it's little slow than my C >> wrap >> > version >> >> Because it uses ‘file-system-fold’, it does one ‘stat’ call for each >> file, which the C version doesn’t do. That should be the only >> efficiency difference. >> >> Maybe we could change our ‘scandir’ to return a list of file name/stat >> pairs since we have the info anyway? >> >> > Well~it's a good idea I never thought about. And I've tested new commit, > it's wonderful. > Maybe you should consider this name/stat, now the new scandir is almost 4 > times slower than C wrapper version. > Anyway, name/stat list would be a smart and easy solution. ;-) > >
