Bug #73252 for Marpa-XS: Glib dependency

This comes up, so thanks for the chance to put this on record. Imagine, as a "thought problem", that this ticket came with a patch. I would probably be forced to reject the patch. Here's why: How could I assure myself, to the same level of confidence I can have in Glib, that the patch was portable and thread-safe? Among other things, Marpa::XS uses Glib for thread-safety, memory management, atomic operation and error logging. For optimization, Marpa::XS "rolls its own" for most of its data structures, but when speed is less of an issue Marpa::XS uses Glib's trees, hashes and arrays. How could I assure myself that all these things in the patch worked portably, including in threaded environments? Further, with Glib comes, free, a lot of maintainability. Anything I'm not presently using that I need (such as random numbers) can be added without new code or an additional dependency.

Thanks for the chance to "make a record". I don't like the word "rejected", but it is less misleading than "resolved", so that is how I am classing this ticket. Briefly, the Glib dependency could only be eliminated with great effort, and by replacing it with something less reliable, less portable, less useful and less flexible. Imagine, as a "thought problem", that this ticket came with a patch. Here is why I would probably be forced to reject the patch: How could I assure myself, to the same level of confidence I can have in Glib, that the patch was portable and thread-safe? Among other things, Marpa::XS uses Glib for thread-safety, memory management, atomic operation and error logging. For optimization, Marpa::XS "rolls its own" for most of its data structures, but in certain cases where speed is less of an issue Marpa::XS uses Glib's trees, hashes and arrays. How could I assure myself, to the same level of confidence I can have in Glib, that all these things in the patch worked portably, including in threaded environments? As far as I can see, I simply could not. An additional note: the use of Glib has advantages for maintainance. Anything I'm not presently using that I end up needing (say, as a example, random numbers) can be added without new code or an additional dependency.

On Wed, Dec 14, 2011 at 6:22 PM, Jeffrey Kegler via RT <bug-Marpa-XS@rt.cpan.org> wrote: Show quoted text
Hi Jeffrey, Thank you for the detailed answer. These are of course all good reasons. However do you think it would be possible to include the Glib and ExtUtils::PkgConfig with the Marpa::XS distribution? Currently I cannot install Marpa::XS on Windows due to the ExtUtils::PkgConfig dependency. Similarly in a Linux install I am using where I do not have root permissions, I fail due to the missing Glib dependency. It might be possible for each user with problems similar to mine (pretty much anyone on Windows I would assume) to solve his/her case individually, but I suspect the net result would be to limit the wider adoption of Marpa::XS only to those users who have a recent Linux distro with updated GTK+ development libraries installed. That would be a shame. Looking at the CPAN testers matrix, it seems indeed only on Linux does Marpa::XS install cleanly: http://matrix.cpantesters.org/?dist=Marpa-XS-1.000000 Nor is the Glib dependency problem limited to Windows: http://www.cpantesters.org/cpan/report/808a1036-28da-11e1-9c03-8afdcf780847 Best regards, Offer Kaye

Including Glib & ExtUtils::PkgConfig AFAIK would offer no advantage over requiring them -- the problem is in figuring out how to install them. The failure is often due not to the Perl modules themselves, but to the lack of a GNU utility or library, or too old a version of one. Of course the normal cpan installation procedure does not update those. Again my apologies for the unfortunate label "rejected", because I am sympathetic -- notice that Glib & ExtUtils::PkgConfig are the *ONLY* non-core dependencies Marpa has. I *HATE* dependencies. And I do keep in the back of my mind how the list of things I use Glib for might be reduced, and then eliminated. But, frankly, I am making little progress on that front, am tied up elsewhere, and expect little progress in the forseeable future. If I were installing on Windows (and if I ever get access to a Windows box, I'll probably try it), I'd just fight with installing Glib and the GNU utilities, same as everybody else. thanks, jeffrey