Re: Re: Adding Glib::IO to the released modules

On 16 June 2017 at 20:28,  <max augsburg gmx de> wrote:
Dear Emmanuele,

I fully agree with you. It would be great, if Glib::IO could be released. The manual making of the 
Glib::IO-binding "on the fly", as oldteecha described, is a very good workaround. I use it myself in 
several simple projects without problems. But the best solution would be a simple "use Glib::IO;".

We discussed this some time ago on the list. But I think, there was nobody, who could maintain the Glib::IO 
module. Jeremy Volkening and I worked a little bit on the module. But we had not enough time to make it 
release-ready. And in my case, I don't have the competence to really maintain such a complex module!

It's been a while since I maintained a Perl module, but I'd be happy
to work on it.

The only problem I noticed with Glib::IO was, that GIO reads and writes files in raw bytes format, which 
means everything is passed on without any encoding/decoding. For compability with perl strings one have to 
convert the bytes (= pure digits) to a bytestring without encoding and then to decode this bytrstring in 
the utf8 encoding format. The following two lines was for example for th Glib::IO::File::load_contents 
$content = pack 'C*', @{$content};
my $content_utf8 = decode('utf-8', $content);

I tried to fix this (see for the relevant methods in the 
Glib::IO::File part. But I don't know whether this is a good solution for the problem. I decided that the 
decoding task (the second command) furthermore has to do manually because perhaps somebody needs another 
encoding. Perhaps you know a better solution? In any case it would be great if you could check the patch 
and merge it before releasing...

I think we should leave the contents alone; decoding the data into
UTF-8 is not always appropriate — GIO can be, and often is, used to
load binary data. If you want to automatically encode/decode to/from
UTF-8, you should use one of the GConverter interface implementations;
or use a pure Perl implementation, if you know what you're doing.
Returning an array of bytes is perfectly fine.


[@] ebassi []

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]