[ruby-core:36755] [Ruby 1.9 - Feature #4774][Closed] User Friendly Handling of "Encoding::ConverterNotFoundError"

Issue #4774 has been updated by Yui NARUSE.

Status changed from Open to Closed


----------------------------------------
Feature #4774: User Friendly Handling of "Encoding::ConverterNotFoundError"
http://redmine.ruby-lang.org/issues/4774

Author: Lazaridis Ilias
Status: Closed
Priority: Normal
Assignee: 
Category: 
Target version: 


Based on my own (user) experience with issue [#4738] (which was solved), I suggest the following enhancement.

=== 1st Step - Minimum ===

The basic action would be to extend the error message "Encoding::ConverterNotFoundError" like this:

"
Converter XXXX to XXXX not found. 
More information on: http://ruby-lang.org/encoding-converter.html
"

The document would explains why this error happened, and what the user can do now.

Example: 

  please run "ruby --encode-sanity" and send the output to ...
  Search in "http://redmine.ruby-lang.org" for "converter XXX to XXX"

(something like that, that give a process to follow)

A developer locates the relevant missing file, e.g.: "ibm737-tbl.rb", and place it into the sources for the next release. 

The existent installation of the user has still the problem - he has to wait for the next release.

=== 2nd Step - Preliminary Encoders ===

The user would have the possibility to drop-in a translation table file. The file "ibm737-tbl.rb" is published on the "encoding-converter" page, the user gets it and drops it into it's local installation, e.g.:

ruby192/lib/enc/trans/preliminary/

The exception (Encoding::ConverterNotFoundError) tries to resolve the missing translation table with a lookup to a preliminary/*.rb table (which has lower speed, but it works).

With the next release, the file would become redundant, because it was compiled in. A message could inform the user about it.

-

=== Alternative - By Compilation ===

If the compilation of the translation tables is unavoidable by design, then the site 

http://ruby-lang.org/encoding-converter.html

could point to the relevant compiled *.so files

In this case, the missing *.so file would be generated out of "ibm737-tbl.rb", and provided for download (for the major OS, Win, Mac etc.!)

The files could be "stolen" from actual automated builds (don't know if currently available for ruby).

=== gem based ===

The final possible implementation (and possibly the most elegant one) would be, to have the preliminary encoding-translations within a gem.

So, in this example, ibm737-tbl.rb would have been placed into the ruby sources, and the actual "trans" gem would have been updated and uploaded (with native versions for the major OS's).

The user would update his local installation by:

chcp 850 => change codepage to 850 or something else, thus gem works
gem install encoders => installs the encoding-translation which was just updated with ibm737-tbl.rb
chcp 737 => change back to original codepage

This way the user can continue with his install ruby immediately, and the sources are updated

-

(please note: I'm not familiar with the ruby sources. I've invested some hours to write this down, thus a core developer with the relevant domain knowledge can verify and possibly implement this.)




-- 
http://redmine.ruby-lang.org