user-pic

Max Maischein

  • Website: corion.net
  • About: I'm the Treasurer for the Frankfurt Perlmongers e.V. . I have organized Perl events including 7 German Perl Workshops one YAPC::Europe.
Subscribe to feed Recent Actions from Max Maischein

  • https://www.google.com/accounts/o8/id?id=AItOawlKCInGw3AtPhoc4NBTcIFE1ggZxSjXMXY commented on Unicode is 20++ years old and still a problem

    You can workaround and find any file with File::Find. Just convert file/dir names to/from bytes before/after passing to file::find.

  • xdg commented on Unicode is 20++ years old and still a problem

    How is File::Find supposed to know how file names are encoded on your particular filesystem? (Hint: not all filesystems store names as UTF-8 Unicode.)

    That said, I don't see what Text::CSV::Slurp is doing to filenames that would cause a problem. If it gets octets from File::Find, it looks like it's passing them right back to an open call.

    It's not opening files in UTF-8 mode, but that's sort of a separate problem.

  • Helmut Wollmersdorfer commented on Unicode is 20++ years old and still a problem

    How is File::Find supposed to know how file names are encoded on your particular filesystem?

    File::Find could guess the encoding via e.g. Encode::Locale with an accuracy of 99.99%. Of course the sanity must be checked during decoding, because Posix handles only bytes.

    Each module importing strings from an external representation should take care of the correct decoding, or as a minimum should document and warn about its limitations.

    That said, I don't see what Text::CSV::Slurp is doing to filenames that would cause a problem.

    I used Text::CSV::Slurp only to s…

  • vsespb commented on Unicode is 20++ years old and still a problem

    > File::Find could guess the encoding via e.g. Encode::Locale with an accuracy of 99.99%.

    So you want it to be broken by design, and write/read garbage from filesystems in some cases?
    Filesystem encodings never should not be detected with locale !
    Your proposed design leads to data loss.

  • Matt S Trout (mst) commented on Virtual Spring Cleaning (part 2 of X) in which I release Apache::Tika::Async

    Given Future already supports all of the different loops, as soon as you load an event loop at all it's effectively free.

    Search::Elasticsearch chose Promises for no particular reason and the author was open to adding Future support as well; if I ever have to use it I'll likely do so since I hate having to deal with things that aren't the common standard.

    If you're already forcing people to deal with AE, I'd simply call it AnyEvent::Apache::Tika so those of us who don't like software that breaks in production because the author doesn't like another CPAN module can avoid it in…

Subscribe to feed Responses to Comments from Max Maischein

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.