On Fri, 12 Oct 2012 01:10:49 +0200 Cedric BAIL <moa.blueb...@gmail.com> said:
> Cedric Bail > On Oct 12, 2012 3:07 AM, "Gustavo Sverzut Barbieri" <barbi...@profusion.mobi> > wrote: > > > > On Thu, Oct 11, 2012 at 12:56 PM, Jorge Luis Zapata Muga > > <jorgeluis.zap...@gmail.com> wrote: > > > On Thu, Oct 11, 2012 at 4:56 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > >> On Thu, 11 Oct 2012 09:37:37 -0300 Gustavo Sverzut Barbieri > > >> <barbi...@profusion.mobi> said: > > >> > > >> the other eina mempool enignes arenot even compiled by default. in > fact all tat > > >> is compiled by default is one_big, and chained_pool. even passhtrough > isnt > > >> compiled by default (should be though), so it doesnt hurt to remove > them as any > > >> code using these could nver have depended on the non-compiled mempool > modules > > >> as eina could have been built without and you'd need to fallback > anyway. > > > > > > One thing is to disable something and another to remove something. If > > > any kind of module that can be conditionally compiled is disabled by > > > default, packagers can always provide them as part of another package. > > > > > > Also, I can always compile the modules that I need to make my software > > > work correctly. If my software can not find the buddy allocator or any > > > other allocator and it is mandatory to have it to work, then my > > > software wont work, which is ok, given its hard dependencies. No > > > fallback, no nothing, it just wont work and is ok from my software > > > point of view. But removing the code makes my software to *never* > > > work. > > > > > > Of course, as I said before, I can pick up the svn history, look for > > > it and copy it, or take it from the current "old" eina. I'm fine with > > > it. > > > > that's the life of who makes decisions, you need to make decisions and > > it may not please everyone. It will be a similar pain when we remove > > DirectFB, as there are 1-2 people in the world that uses it and will > > miss it. But in order to improve maintenance and quality we must > > remove things we do not support. > > > > Moreover, the software should fallback to some other allocator, it > > will not stop working. If that's not the case we can add these > > fallbacks to eina_mempool. > > I am a bit disappointed here, nobody did ask what was the use Jorge had for > that mempool and what was the benefit to use that one. My guess is enesim > and esvg stack use it. If that's the case maybe we should keep that menpool. even if enesm uses them - it cant depend on them as they are never there by default, so it HAS to have fallback code for other allocators anyway (since mempool creation will fail), so enesim has to work with others. the reason i called for them being removed - not just the option but remove the non-compiled allocators, is that they are not used in general and thus not tested and unlikely to be supported on any given installation, thus it's time to remove them. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
