Cedric BAIL schrieb:
>
> I think we didn't understand together. When I say slowly move stuff
> around, it include changing and improving Eina to fit our needs also.
> Eina is not a finished library, but an ongoing development. It's just
> a good starting point imho to get stuff done faster.
>
O
On Fri, Jul 11, 2008 at 11:11 AM, Peter Wehrfritz
<[EMAIL PROTECTED]> wrote:
> Cedric BAIL schrieb:
Putting eina now into cvs doesn't help anyone at the moment. There are
two ways we can go:
1. First we start with a little lib, where we put step by step code into
it,
Cedric BAIL schrieb:
>>> Putting eina now into cvs doesn't help anyone at the moment. There are two
>>> ways we can go:
>>>
>>> 1. First we start with a little lib, where we put step by step code into it,
>>> we agree with that it belongs into the common lib. That's what I tried with
>>> edt.
>>> 2
Jorge Luis Zapata Muga schrieb:
> On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>
>> Jorge Luis Zapata Muga schrieb:
>>
>>> Having a common agreement isnt easy but we should make one. Cedric
>>> ideas of providing a common API and just do some macros is useful,
Not directly related to shared-strings or data structures, but as a
relevant aside to the more general issue of useful 'core' kinds of libs,
there is one lib that Jorge and Hisham recently worked on that might be
of interest - namely, the timeline based animation lib "etch".
I'm not
On Wed, Jul 9, 2008 at 2:40 PM, Jorge Luis Zapata Muga
<[EMAIL PROTECTED]> wrote:
> On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>> Jorge Luis Zapata Muga schrieb:
>>>
>>> Having a common agreement isnt easy but we should make one. Cedric
>>> ideas of providing a commo
On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
> Jorge Luis Zapata Muga schrieb:
>>
>> Having a common agreement isnt easy but we should make one. Cedric
>> ideas of providing a common API and just do some macros is useful, i
>> agree that the structure of the code using
Jorge Luis Zapata Muga schrieb:
>
> Having a common agreement isnt easy but we should make one. Cedric
> ideas of providing a common API and just do some macros is useful, i
> agree that the structure of the code using might have to change, but
> either way a list API of any kind, is more or less c
On Tue, Jul 8, 2008 at 11:44 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
> Cedric BAIL schrieb:
>> On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>>
>>> Vincent Torri schrieb:
>>>
I think that Hisham wants you to put your code in edata, and not create
anoth
Hi all,
On Tue, Jul 8, 2008 at 12:24 PM, Vincent Torri <[EMAIL PROTECTED]> wrote:
>
>> But why didn't we just put eina inside the libs cvs directory (svn
>> checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And
>> start hacking from here. We can then slowly switch evas , ecore and
> But why didn't we just put eina inside the libs cvs directory (svn
> checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And
> start hacking from here. We can then slowly switch evas , ecore and
> eet to the data type eina provide or the one we add to eina. It should
> be easier to
Cedric BAIL schrieb:
> On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>
>> Vincent Torri schrieb:
>>
>>> I think that Hisham wants you to put your code in edata, and not create
>>> another lib.
>>>
>>>
>> Unfortunately, it isn't that easy. We have two (or
On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
> Vincent Torri schrieb:
>>
>> I think that Hisham wants you to put your code in edata, and not create
>> another lib.
>>
> Unfortunately, it isn't that easy. We have two (or with other counting 3
> or 4) list implementatio
Vincent Torri schrieb:
>
> I think that Hisham wants you to put your code in edata, and not create
> another lib.
>
>
Unfortunately, it isn't that easy. We have two (or with other counting 3
or 4) list implementations and two hash implementations. Since their API
is totally different, especia
On Tue, 8 Jul 2008, Peter Wehrfritz wrote:
> Hisham Mardam Bey schrieb:
>> On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>>
>>> I've put now the evas stringshare code into a standalone lib. I know
>>> that Nathan is working on improving ecore_hash, so that ecore_stri
Hisham Mardam Bey schrieb:
> On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>
>> I've put now the evas stringshare code into a standalone lib. I know
>> that Nathan is working on improving ecore_hash, so that ecore_string
>> becomes faster. We can still change the cod
On Mon, Jul 7, 2008 at 6:45 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
> I've put now the evas stringshare code into a standalone lib. I know
> that Nathan is working on improving ecore_hash, so that ecore_string
> becomes faster. We can still change the code later, since the API and
> ABI rema
Peter Wehrfritz schrieb:
> Yesterday we had a discussion on irc, if we should put abstract data
> types of ecore and of evas into a single standalone lib. The whole
> discussion came up because of the two implementations of the shared
> strings. And in fact if we really want to share strings eff
On Fri, 09 May 2008 19:21:43 +0200 Peter Wehrfritz <[EMAIL PROTECTED]>
babbled:
> The (only) one alloc is most probably the reason why has better results
> for adds and removes then the ecore counter-parts. It's probably
> possible somehow to improve the situation for ecore_hash, but it'd make
Carsten Haitzler (The Rasterman) schrieb:
> after. i've run the tests myself now.
>
> i'll add some stats. e17 maintains about 3000-4000 unique strings in
> evas_stringshare. in my tests. i also checked on number of adds, dels and
> lookups in evas_stringshare usage. about 6.48% of calls are for ad
On Wed, May 7, 2008 at 2:20 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
> Yesterday we had a discussion on irc, if we should put abstract data
> types of ecore and of evas into a single standalone lib. The whole
> discussion came up because of the two implementations of the shared
> strings. And
On Wed, 7 May 2008 20:55:40 -0500 "Nathan Ingersoll" <[EMAIL PROTECTED]>
babbled:
after. i've run the tests myself now.
i'll add some stats. e17 maintains about 3000-4000 unique strings in
evas_stringshare. in my tests. i also checked on number of adds, dels and
lookups in evas_stringshare usage.
Nathan Ingersoll schrieb:
> Were these numbers from ecore before or after cedric's changes this morning?
>
I updated ecore_data just before.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss t
Were these numbers from ecore before or after cedric's changes this morning?
On Wed, May 7, 2008 at 1:20 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
> Yesterday we had a discussion on irc, if we should put abstract data
> types of ecore and of evas into a single standalone lib. The whole
> di
Yesterday we had a discussion on irc, if we should put abstract data
types of ecore and of evas into a single standalone lib. The whole
discussion came up because of the two implementations of the shared
strings. And in fact if we really want to share strings efficient, we
have to share them ov
25 matches
Mail list logo
