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
Re: glib or not glib?
Andrew Borodin schrieb: On Wed, 7 Jan 2009 09:35:25 +0100 Enrico Weigelt wrote: * MC Ticket System tick...@midnight-commander.org schrieb: Why the _strcatdup() function is used instead of g_strconcat() one? First tiny step to get rid if glib. It's very strange. Do you think than mc must be free of glib? glib or not glib? I want to keep it. If we got rid of it, we would have to do everything glib does by hand. It comes very handy when dealing with data structures like lists, strings and so on. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: glib or not glib? (was: Re: [Midnight Commander] #150: [PATCH] More FHS-compliant install directories)
* Andrew Borodin aboro...@vmail.ru schrieb: Hi, First tiny step to get rid if glib. It's very strange. Do you think than mc must be free of glib? Yes, because glib is a fat blob we don't really need (the few things we currently use can be easily done w/ a bunch of macros or inline's). Isn't it rather absurd to maintain an stripped-down branch of slang for embedded systems, but at the same time import glib ? ;-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
Re: glib or not glib?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Illig wrote: glib or not glib? I want to keep it. +1 In source code some functions (part of functions) is a duplicate of glib-functional... I think, we need to review source code for more using of glib functions... BTW, is we need to keep compatibility with glib-1.2? WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklknGYACgkQb3oGR6aVLpqeQQCeL+PGxPCKK3ZcoQbfxOBP1yMr YSEAnjNNRYbBeeIzceKblMhbmCi6V40t =2Q// -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: glib or not glib?
On Wed, 7 Jan 2009 13:11:56 +0100 Enrico Weigelt wrote: * Andrew Borodin schrieb: First tiny step to get rid if glib. It's very strange. Do you think than mc must be free of glib? Yes, because glib is a fat blob we don't really need (the few things we currently use can be easily done w/ a bunch of macros or inline's). Other developers are disagree with you. glib provides many useful functions and data structures and allows us do not reinvent the wheel. And glib is portable library. Isn't it rather absurd to maintain an stripped-down branch of slang for embedded systems, but at the same time import glib ? ;-O mc for embedded systems can be linked statically. -- Regards, Andrew. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
