Glib or no glib - we need a decision
Hey, As there are some guys here which want to stick with glib and some who doesn't want this. As each sites have some good arguments pro or contra glib I'll write some thoughs here down and would like to ask you to add your arguments here and discuss then these arguments on the list. Please note that we really need a decision :) pro: - glib has many preformed functions and we don't have to think about many issues as they are solved inside glib. - ... contra: - glib is huge and we only use a very small amount of functions. Rewriting this functions would make mc smaller and faster. This is important at least for embedded devices. - ... Please discuss on this as I would like to have this solved/out-of-the-world for 4.7 Greetings Winnie -- .''`. Patrick Winnertz patrick.winne...@skolelinux.org : :' : GNU/Linux Debian-Edu Developer `. `'` http://www.der-winnie.de http://d.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Glib or no glib - we need a decision
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Winnertz wrote: Hey, As there are some guys here which want to stick with glib and some who doesn't want this. As each sites have some good arguments pro or contra glib I'll write some thoughs here down and would like to ask you to add your arguments here and discuss then these arguments on the list. Please note that we really need a decision :) pro: - glib has many preformed functions and we don't have to think about many issues as they are solved inside glib. - ... contra: - glib is huge and we only use a very small amount of functions. Rewriting this functions would make mc smaller and faster. This is important at least for embedded devices. - ... I want to propose third variant... As for me, no different what write: - - mc_malloc|free|new_array|... - - or g_malloc|free|new_array|... - - or simply malloc|free|own_func_for_work_with_array I want to write a standard, without chaos, without #ifdef...#endif in any source file... in one coding style... What I mean: need to create some wrapper... like my first step to this in http://www.midnight-commander.org/ticket/125 For now, wrapper may have #define'd via pseudo-functions... but in future (if someone from 'contra' want) will realize own library (call it as you want: mcglib, mccore, mclib.so,...), and will add in ./configure.ac option '--without-glib' WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJZ1Dfb3oGR6aVLpoRApR8AJ4iKV04LbaItVjfo03SsfwfPdYoaQCdEFJU EvcIDZlDL7qy9DycVtojZbI= =EsAi -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Glib or no glib - we need a decision
* Patrick Winnertz win...@debian.org schrieb: contra: - glib is huge and we only use a very small amount of functions. Rewriting this functions would make mc smaller and faster. This is important at least for embedded devices. Note that there's many many places where the glib functions aren't needed at all. a) wrappers for (often inline'd) libc functions (g_strcasecmp(), etc) This actually costs resources, *at least* an extra far call up to loosing the chance of inline'ing. It's IMHO stupid to use glib here just to use it. b) unncessary string duplications c) often an static buffer on stack is cheaper d) g_strconcat(): unnecessarily expensive and unrobust (just forget the last NULL parameter and go straight to hell) - I've replaced it by several faster inlines in my branch e) many things can be expressed more clear, cheaper and more robust through a few little macros. f) some glib functions are simply broken and must be circumvented at all (eg. shell-escaping ...) So my vote is to at least get rid of the unncessary glib calls, then let's see what remains and wether it's worth to keep it just for that few things BTW: glib is far from being robust over several versions. Just look at the 1.*/2.* issue: they actually call the 2.* successor versions of 1.*, but they're totally different things that just happen to share the name and some ideas behind. And even within the 2.* line there've been major interface breaks. Keep that in mind! 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: Glib or no glib - we need a decision
* Slava Zanko slavaza...@gmail.com schrieb: Hi, What I mean: need to create some wrapper... like my first step to this in http://www.midnight-commander.org/ticket/125 Inspired by your idea, I've started writing some minimalistic helper library (./mhl/* - micro helper library) which actually just provides a bunch of macros and inlines. Meanwhile I've moved the whole memory management, string handling and even hashtable handling (using libhash) there. For now, wrapper may have #define'd via pseudo-functions... but in future (if someone from 'contra' want) will realize own library (call it as you want: mcglib, mccore, mclib.so,...), and will add in ./configure.ac option '--without-glib' Yes, that would be easy. But as I already wrote own (glib-free) implementations for that stuff, I doubt why we should glib at all ;-o 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
