Re: Abstracting away glib?
* Mourad De Clerck mou...@aquazul.com schrieb: Hi, a) memory requirements - as you probably know glib is being used for a lot of projects, to the point that it's hard to avoid at all, even on embedded; on platforms with really constrained memory (easy to OOM) glib is probably not ideal, but to be honest, I can't imagine running mc on those either; We're actually using only a *very* small percentage of glib - all we need easily fits in a bunch of .h files. Glib is just a fat blob which makes more hassle than it's worth it, IMHO ;-p b) performance - Enrico Weigelt mentioned some ways in which glib is underperforming or adding unnecessary abstractions. I'd argue that if it's just the implementation, it should be fixed in glib itself; In theory you're right. But from my own experience I can tell you that this won't happen (unless we're doing our own fork ;-o). c) possible interface breaks - I think every library has those, but I also think glib has been better than most in maintaining the compatibility since their last major API break 7 years ago. In recent years, I've experienced enough glib trouble (not just interface breaks) for disliking it, especially when it's not really needed. But I'd expected you to start using more of glib, instead of less. For what ? Where exactly is the benefit ? these; stuff like GIO/GVFS, No, please not. GVFS is yet another fat blob, and even worse: it runs everything over dbus. (dbus itself - IMHO - is an really stupid invention for things where an simple fs protocol like 9P would fit much better). We're currently in process of moving to libmvfs step by step, there's already a branch waiting for commit, which adds several libmvfs-based fs'es, like 9P. Once all of mc's own fs'es have been ported to libmvfs, we can replace mcvfs by libmvfs. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Abstracting away glib?
Hello, a) memory requirements - as you probably know glib is being used for a lot of projects, to the point that it's hard to avoid at all, even on embedded; on platforms with really constrained memory (easy to OOM) glib is probably not ideal, but to be honest, I can't imagine running mc on those either; We're actually using only a *very* small percentage of glib - all we need easily fits in a bunch of .h files. Glib is just a fat blob which makes more hassle than it's worth it, IMHO ;-p Not really; It makes the code cleaner, and it makes the code more maintainable as people that already have experience with glib are able to pick up easily and start contributing effectively from the get-go as opposed to learning a new internal API for basic stuff. But if memory consumption is that much of a concern to you, you are free to pull the Embedded GLIB which is an MIT X11 licensed version of the glib API designed for embedded systems. It is part of Mono's source code. For a project that does not get a lot of contributors: maintenance always comes first. b) performance - Enrico Weigelt mentioned some ways in which glib is underperforming or adding unnecessary abstractions. I'd argue that if it's just the implementation, it should be fixed in glib itself; In theory you're right. But from my own experience I can tell you that this won't happen (unless we're doing our own fork ;-o). Are you guys being serious? A file manager spends most of its time doing file I/O and any glib abstraction over g_malloc or whatever else is negligible. c) possible interface breaks - I think every library has those, but I also think glib has been better than most in maintaining the compatibility since their last major API break 7 years ago. In recent years, I've experienced enough glib trouble (not just interface breaks) for disliking it, especially when it's not really needed. Which interface breaks? That is nonsense. Glib has been API stable since Gnome 2.0 came out. If you have had problems document them. I for one doubt your statement very much. But I'd expected you to start using more of glib, instead of less. For what ? Where exactly is the benefit ? Open Source Development 101: * Someone else maintains the code * Someone else fixes the bugs. * We benefit from both. * Less work on our plate. * Easier for newcomers with previous experience to pick it up. * Minimize number of bugs. * Reduce maintenance cost. * Shared development cost. * Shared code in memory with other processes. * Improvements in glib, improve mc directly (better hashtables, we benefit, better allocation, we benefit). Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Abstracting away glib?
On Monday 2009-02-02 13:15, Mourad De Clerck wrote:
Now, don't get me wrong: if glib gets in the way of your esthetic
senses, or you dislike it for some other reasons, feel free to toss it;
I'm already grateful people are taking an interest in mc at all. But I'd
expected you to start using more of glib, instead of less. Because it's
well tested and in wide use, and because you can take advantage of
features that glib implements so you don't have to implement or maintain
these; stuff like GIO/GVFS, win32 portability, etc.
As an mc user, I do not really care how much glib is used or not.
But I used to rip glib out of pam_mount for I did not very art-ful.
A gem from a few years ago:
/* FIXME: getting rid of the const is silly, but I didn't write
g_tree_insert */
g_tree_insert(x-fillers, (char *) key, (char *) val);
Also, the typedef definitions are really worrisome. I think someone
was too eager in ensuring portability. Why define gconstpointer if
your compiler has const void *? Obviously, gconstpointer is there for
compilers that have no void. But then again, glib does not even
support such compilers in the first place, and neither would I
suggest such a prehistoric compiler to anyone.
static gint _cmp(gconstpointer a, gconstpointer b) {
...
}
x = g_tree_new(_cmp);
Or take this:
return g_spawn_async_with_pipes(wd, (char **)argv, (char **)envp,
flags, cs, data, pid, istdin, istdout, istderr, err);
Which reminds me of
http://mirror.linux.org.au/linux.conf.au/2008/Fri/mel8-137.ogg
(preferably not too many args).
That provided enough reasons for me to do without glib and instead
use my own.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Abstracting away glib?
Hi all, I was very happy to see renewed interest and development in mc, probably one of the programs I use most often. I've seen Patrick Winnertz mention this on his blog, and was wondering about the reasoning behind it: * Added a micro helper library in order to go slowly avay from glib I thought this was a bit surprising - from what I understand from the mailing list archives, the reasons for this are: a) memory requirements - as you probably know glib is being used for a lot of projects, to the point that it's hard to avoid at all, even on embedded; on platforms with really constrained memory (easy to OOM) glib is probably not ideal, but to be honest, I can't imagine running mc on those either; b) performance - Enrico Weigelt mentioned some ways in which glib is underperforming or adding unnecessary abstractions. I'd argue that if it's just the implementation, it should be fixed in glib itself; I also wonder what kind of performance gains we're talking about here, whether they're worth it. c) possible interface breaks - I think every library has those, but I also think glib has been better than most in maintaining the compatibility since their last major API break 7 years ago. Considering the number of projects using it, they're more than careful not to do anything crazy. Things get added and deprecated, obviously (like the g_strcasecmp() Enrico mentioned, deprecated since 2.2 six years ago); but that's a good thing, I think. Now, don't get me wrong: if glib gets in the way of your esthetic senses, or you dislike it for some other reasons, feel free to toss it; I'm already grateful people are taking an interest in mc at all. But I'd expected you to start using more of glib, instead of less. Because it's well tested and in wide use, and because you can take advantage of features that glib implements so you don't have to implement or maintain these; stuff like GIO/GVFS, win32 portability, etc. Either way, thanks for picking the Midnight Commander up - I look forward to the new releases. Mourad ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
