Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sat, 12 Nov 2011 12:34:28 +0900 Carsten Haitzler (The Rasterman) wrote: > On Fri, 11 Nov 2011 22:28:44 -0500 Christopher Michael > said: > > > On 11/11/11 21:49, Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 11 Nov 2011 21:00:23 -0500 Christopher > > > Michael said: > > > > > >> On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote: > > >>> On Fri, 11 Nov 2011 20:08:09 -0500 Christopher > > >>> Michael said: > > >>> > > On 11/11/11 19:54, Enlightenment SVN wrote: > > > Log: > > > back to unsigned long. code was actually correct as-is. > > > > > If that's actually correct, then the 'fix' for the xcb version should > > be reverted also ;) > > >>> > > >>> yeah found it. fixed. :) thanks for reminding > > >>> > > >> No worries. Thanks for the fix ;) > > >> > > >>> fyi - notice that even with those changes.. a whole bunch of other funcs > > >>> in the same file were still using unsigned long * so the code was > > >>> inconsistently changed too... which is bad :) > > >>> > > >> Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd > > >> patch). No worries tho, it's straightened out now ;) > > > > > > oh sure - originally. i'm just pointing out that it was that way for a > > > reason :) much more code followed the same pattern. if you change 1 > > > instance of a pattern... you need to be sure you really do NEED to change > > > it. you didn't do it - just pointing it out to those watching :) > > > > > > > No worries, thanks for keeping an eye out ;) After quite a few years of > > efl/e development, I've actually managed to grow that 'thick skin' we > > used to talk about ;) so not taking it personally :) > > hu... porkrinds. > > you called? -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sat, 12 Nov 2011 07:53:02 +0100 (CET) Vincent Torri said: > > > On Sat, 12 Nov 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michael > > said: > > > >> On 11/11/11 19:54, Enlightenment SVN wrote: > >>> Log: > >>> back to unsigned long. code was actually correct as-is. > >>> > >> If that's actually correct, then the 'fix' for the xcb version should be > >> reverted also ;) > > > > yeah found it. fixed. :) thanks for reminding > > > > fyi - notice that even with those changes.. a whole bunch of other funcs in > > the same file were still using unsigned long * so the code was > > inconsistently changed too... which is bad :) > > forget my previous mail > > I do not agree. I don't see anywhere in the protocol specification where a > long is used: > > http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml > http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/sect1-9.xml protocol can never specify a long because longs are a variables size. protocol specifies 32bit integers (CARD32). the Xlib API packs 1 card32 into each long in the array. trust me on this... if you don't - get a 64bit machine and find out :) > Vincent > > > > >> dh > >> > >>> > >>> > >>> Author: raster > >>> Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011) > >>> New Revision: 65082 > >>> Trac: http://trac.enlightenment.org/e/changeset/65082 > >>> > >>> Modified: > >>>trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > >>> > >>> Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > >>> === > >>> --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > >>> 2011-11-11 21:59:02 UTC (rev 65081) +++ > >>> trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-12 > >>> 00:54:22 UTC (rev 65082) @@ -131,7 +131,7 @@ return -1; > >>> } > >>> for (i = 0; i< num_ret; i++) > >>> - val[i] = ((unsigned int *)prop_ret)[i]; > >>> + val[i] = ((unsigned long *)prop_ret)[i]; > >>> num = num_ret; > >>> *plst = val; > >>>} > >>> > >> > >> > >> -- > >> RSA(R) Conference 2012 > >> Save $700 by Nov 18 > >> Register now > >> http://p.sf.net/sfu/rsa-sfdev2dev1 > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > > -- > > RSA(R) Conference 2012 > > Save $700 by Nov 18 > > Register now > > http://p.sf.net/sfu/rsa-sfdev2dev1 > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sat, 12 Nov 2011, Carsten Haitzler (The Rasterman) wrote: > On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michael > > said: > >> On 11/11/11 19:54, Enlightenment SVN wrote: >>> Log: >>> back to unsigned long. code was actually correct as-is. >>> >> If that's actually correct, then the 'fix' for the xcb version should be >> reverted also ;) > > yeah found it. fixed. :) thanks for reminding > > fyi - notice that even with those changes.. a whole bunch of other funcs in > the > same file were still using unsigned long * so the code was inconsistently > changed too... which is bad :) forget my previous mail I do not agree. I don't see anywhere in the protocol specification where a long is used: http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/sect1-9.xml Vincent > >> dh >> >>> >>> >>> Author: raster >>> Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011) >>> New Revision: 65082 >>> Trac: http://trac.enlightenment.org/e/changeset/65082 >>> >>> Modified: >>>trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c >>> >>> Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c >>> === >>> --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c >>> 2011-11-11 21:59:02 UTC (rev 65081) +++ >>> trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c 2011-11-12 >>> 00:54:22 UTC (rev 65082) @@ -131,7 +131,7 @@ return -1; >>> } >>> for (i = 0; i< num_ret; i++) >>> - val[i] = ((unsigned int *)prop_ret)[i]; >>> + val[i] = ((unsigned long *)prop_ret)[i]; >>> num = num_ret; >>> *plst = val; >>>} >>> >> >> >> -- >> RSA(R) Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Fri, 11 Nov 2011, Christopher Michael wrote: > On 11/11/11 19:54, Enlightenment SVN wrote: >> Log: >> back to unsigned long. code was actually correct as-is. >> > If that's actually correct, then the 'fix' for the xcb version should be > reverted also ;) so, as I said, the last argument of the XCB function is an uint32_t, and as int is always 32 bits, there's no pb Vincent > > dh > >> >> >> Author: raster >> Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011) >> New Revision: 65082 >> Trac: http://trac.enlightenment.org/e/changeset/65082 >> >> Modified: >>trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c >> >> Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c >> === >> --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c 2011-11-11 >> 21:59:02 UTC (rev 65081) >> +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c 2011-11-12 >> 00:54:22 UTC (rev 65082) >> @@ -131,7 +131,7 @@ >>return -1; >> } >> for (i = 0; i< num_ret; i++) >> - val[i] = ((unsigned int *)prop_ret)[i]; >> + val[i] = ((unsigned long *)prop_ret)[i]; >> num = num_ret; >> *plst = val; >>} >> > > > -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Fri, 11 Nov 2011 22:28:44 -0500 Christopher Michael said: > On 11/11/11 21:49, Carsten Haitzler (The Rasterman) wrote: > > On Fri, 11 Nov 2011 21:00:23 -0500 Christopher > > Michael said: > > > >> On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote: > >>> On Fri, 11 Nov 2011 20:08:09 -0500 Christopher > >>> Michael said: > >>> > On 11/11/11 19:54, Enlightenment SVN wrote: > > Log: > > back to unsigned long. code was actually correct as-is. > > > If that's actually correct, then the 'fix' for the xcb version should be > reverted also ;) > >>> > >>> yeah found it. fixed. :) thanks for reminding > >>> > >> No worries. Thanks for the fix ;) > >> > >>> fyi - notice that even with those changes.. a whole bunch of other funcs > >>> in the same file were still using unsigned long * so the code was > >>> inconsistently changed too... which is bad :) > >>> > >> Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd > >> patch). No worries tho, it's straightened out now ;) > > > > oh sure - originally. i'm just pointing out that it was that way for a > > reason :) much more code followed the same pattern. if you change 1 instance > > of a pattern... you need to be sure you really do NEED to change it. you > > didn't do it - just pointing it out to those watching :) > > > > No worries, thanks for keeping an eye out ;) After quite a few years of > efl/e development, I've actually managed to grow that 'thick skin' we > used to talk about ;) so not taking it personally :) hu... porkrinds. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On 11/11/11 21:49, Carsten Haitzler (The Rasterman) wrote: > On Fri, 11 Nov 2011 21:00:23 -0500 Christopher Michael > said: > >> On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote: >>> On Fri, 11 Nov 2011 20:08:09 -0500 Christopher >>> Michael said: >>> On 11/11/11 19:54, Enlightenment SVN wrote: > Log: > back to unsigned long. code was actually correct as-is. > If that's actually correct, then the 'fix' for the xcb version should be reverted also ;) >>> >>> yeah found it. fixed. :) thanks for reminding >>> >> No worries. Thanks for the fix ;) >> >>> fyi - notice that even with those changes.. a whole bunch of other funcs in >>> the same file were still using unsigned long * so the code was >>> inconsistently changed too... which is bad :) >>> >> Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd >> patch). No worries tho, it's straightened out now ;) > > oh sure - originally. i'm just pointing out that it was that way for a > reason :) much more code followed the same pattern. if you change 1 instance > of a pattern... you need to be sure you really do NEED to change it. you > didn't do it - just pointing it out to those watching :) > No worries, thanks for keeping an eye out ;) After quite a few years of efl/e development, I've actually managed to grow that 'thick skin' we used to talk about ;) so not taking it personally :) dh -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Fri, 11 Nov 2011 21:00:23 -0500 Christopher Michael said: > On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote: > > On Fri, 11 Nov 2011 20:08:09 -0500 Christopher > > Michael said: > > > >> On 11/11/11 19:54, Enlightenment SVN wrote: > >>> Log: > >>> back to unsigned long. code was actually correct as-is. > >>> > >> If that's actually correct, then the 'fix' for the xcb version should be > >> reverted also ;) > > > > yeah found it. fixed. :) thanks for reminding > > > No worries. Thanks for the fix ;) > > > fyi - notice that even with those changes.. a whole bunch of other funcs in > > the same file were still using unsigned long * so the code was > > inconsistently changed too... which is bad :) > > > Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd > patch). No worries tho, it's straightened out now ;) oh sure - originally. i'm just pointing out that it was that way for a reason :) much more code followed the same pattern. if you change 1 instance of a pattern... you need to be sure you really do NEED to change it. you didn't do it - just pointing it out to those watching :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote: > On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michael > said: > >> On 11/11/11 19:54, Enlightenment SVN wrote: >>> Log: >>> back to unsigned long. code was actually correct as-is. >>> >> If that's actually correct, then the 'fix' for the xcb version should be >> reverted also ;) > > yeah found it. fixed. :) thanks for reminding > No worries. Thanks for the fix ;) > fyi - notice that even with those changes.. a whole bunch of other funcs in > the > same file were still using unsigned long * so the code was inconsistently > changed too... which is bad :) > Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd patch). No worries tho, it's straightened out now ;) dh -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michael said: > On 11/11/11 19:54, Enlightenment SVN wrote: > > Log: > > back to unsigned long. code was actually correct as-is. > > > If that's actually correct, then the 'fix' for the xcb version should be > reverted also ;) yeah found it. fixed. :) thanks for reminding fyi - notice that even with those changes.. a whole bunch of other funcs in the same file were still using unsigned long * so the code was inconsistently changed too... which is bad :) > dh > > > > > > > Author: raster > > Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011) > > New Revision: 65082 > > Trac: http://trac.enlightenment.org/e/changeset/65082 > > > > Modified: > >trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > > > > Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > > === > > --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > > 2011-11-11 21:59:02 UTC (rev 65081) +++ > > trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c 2011-11-12 > > 00:54:22 UTC (rev 65082) @@ -131,7 +131,7 @@ return -1; > > } > > for (i = 0; i< num_ret; i++) > > - val[i] = ((unsigned int *)prop_ret)[i]; > > + val[i] = ((unsigned long *)prop_ret)[i]; > > num = num_ret; > > *plst = val; > >} > > > > > -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On 11/11/11 19:54, Enlightenment SVN wrote: > Log: > back to unsigned long. code was actually correct as-is. > If that's actually correct, then the 'fix' for the xcb version should be reverted also ;) dh > > > Author: raster > Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011) > New Revision: 65082 > Trac: http://trac.enlightenment.org/e/changeset/65082 > > Modified: >trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > > Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c > === > --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-11 > 21:59:02 UTC (rev 65081) > +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-12 > 00:54:22 UTC (rev 65082) > @@ -131,7 +131,7 @@ >return -1; > } > for (i = 0; i< num_ret; i++) > - val[i] = ((unsigned int *)prop_ret)[i]; > + val[i] = ((unsigned long *)prop_ret)[i]; > num = num_ret; > *plst = val; >} > -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Tue, 3 May 2011 11:54:31 +0200 (CEST) Vincent Torri
said:
i was sitting in a text console without x. i havent written the changelog yet.
>
>
> On Tue, 3 May 2011, Enlightenment SVN wrote:
>
> > Log:
> > fix segv! wow. data was null.
>
> are you sure that you'll be able to find all the fixes that need o be
> back ported to 1.0 ??
>
> Vincent
>
> >
> >
> >
> > Author: raster
> > Date: 2011-05-03 02:46:55 -0700 (Tue, 03 May 2011)
> > New Revision: 59144
> > Trac: http://trac.enlightenment.org/e/changeset/59144
> >
> > Modified:
> > trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
> >
> > Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
> > ===
> > --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2011-05-03
> > 09:10:10 UTC (rev 59143) +++
> > trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2011-05-03
> > 09:46:55 UTC (rev 59144) @@ -1338,7 +1338,7 @@ {
> >Ecore_X_Event_Selection_Request *e;
> >Ecore_X_Selection_Intern *sd;
> > - void *data;
> > + void *data = NULL;
> >int len;
> >int typesize;
> >
> > @@ -1377,7 +1377,7 @@
> > &data, &len, &type, &typesize))
> > /* Refuse selection, conversion to requested target failed
> > */ property = None;
> > - else
> > + else if (data)
> >{
> > /* FIXME: This does not properly handle large data
> > transfers */ ecore_x_window_prop_property_set(
> >
> >
> > --
> > WhatsUp Gold - Download Free Network Management Software
> > The most intuitive, comprehensive, and cost-effective network
> > management toolset available today. Delivers lowest initial
> > acquisition cost and overall TCO of any competing solution.
> > http://p.sf.net/sfu/whatsupgold-sd
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
> >
>
> --
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Tue, 3 May 2011, Enlightenment SVN wrote:
> Log:
> fix segv! wow. data was null.
are you sure that you'll be able to find all the fixes that need o be
back ported to 1.0 ??
Vincent
>
>
>
> Author: raster
> Date: 2011-05-03 02:46:55 -0700 (Tue, 03 May 2011)
> New Revision: 59144
> Trac: http://trac.enlightenment.org/e/changeset/59144
>
> Modified:
> trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
>
> Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
> ===
> --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2011-05-03 09:10:10 UTC
> (rev 59143)
> +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2011-05-03 09:46:55 UTC
> (rev 59144)
> @@ -1338,7 +1338,7 @@
> {
>Ecore_X_Event_Selection_Request *e;
>Ecore_X_Selection_Intern *sd;
> - void *data;
> + void *data = NULL;
>int len;
>int typesize;
>
> @@ -1377,7 +1377,7 @@
> &data, &len, &type, &typesize))
> /* Refuse selection, conversion to requested target failed */
> property = None;
> - else
> + else if (data)
>{
> /* FIXME: This does not properly handle large data
> transfers */
> ecore_x_window_prop_property_set(
>
>
> --
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On 03/31/2011 06:36 AM, Enlightenment SVN wrote:
> Log:
> ahem! who put unused there? who? screen *IS* used!
>
For once, it wasn't me ;)
Disco Stu
dh
>
> Author: raster
> Date: 2011-03-31 03:36:20 -0700 (Thu, 31 Mar 2011)
> New Revision: 58224
> Trac: http://trac.enlightenment.org/e/changeset/58224
>
> Modified:
>trunk/ecore/src/lib/ecore_x/xlib/ecore_x_xinerama.c
>
> Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_xinerama.c
> ===
> --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_xinerama.c 2011-03-31
> 10:26:42 UTC (rev 58223)
> +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_xinerama.c 2011-03-31
> 10:36:20 UTC (rev 58224)
> @@ -39,7 +39,7 @@
> } /* ecore_x_xinerama_screen_count_get */
>
> EAPI Eina_Bool
> -ecore_x_xinerama_screen_geometry_get(int screen __UNUSED__, int *x, int *y,
> int *w, int *h)
> +ecore_x_xinerama_screen_geometry_get(int screen, int *x, int *y, int *w, int
> *h)
> {
> LOGFN(__FILE__, __LINE__, __FUNCTION__);
> #ifdef ECORE_XINERAMA
> @@ -82,5 +82,6 @@
> *h = DisplayHeight(_ecore_x_disp, 0);
>
> return EINA_FALSE;
> + screen = 0;
> } /* ecore_x_xinerama_screen_geometry_get */
>
>
>
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sun, Feb 28, 2010 at 9:58 PM, Peter Johnson wrote: > Ping? > > Would it be more convenient to send the patch and test programs directly to > the list? (I know people usually do this, but since it's a number of files, I > figured it might be cumbersome.) Sorry! I did forget about it :-( I committed a slightly changed version as r46700. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
Ping? Would it be more convenient to send the patch and test programs directly to the list? (I know people usually do this, but since it's a number of files, I figured it might be cumbersome.) pete On Thu, Feb 25, 2010 at 09:51:01PM -0500, Peter Johnson wrote: > Here's a tarball containing a prospective patch and a few commented test > programs: > > http://tam.hiddenrock.com/eina-log-default.tar.gz > > I haven't yet updated the documentation because I'm not entirely convinced > it's correct, but I'm not sure why, so I'd like a few second pairs of eyes on > it. Thanks. > > pete > > On Thu, Feb 25, 2010 at 05:18:10PM -0300, Gustavo Sverzut Barbieri wrote: > > On Thu, Feb 25, 2010 at 5:00 PM, Peter Johnson wrote: > > > Cool, thanks. > > > > > > My reading of those pages indicates that, were I to follow the > > > recommendations > > > contained therein, I would always use the EINA_LOG_DOM_*() macros and > > > never > > > the EINA_LOG_*() macros, because they use EINA_LOG_DOMAIN_GLOBAL, and as a > > > good developer I should have my own domain(s) for my project. > > > > > > I think it would be helpful to allow developers to specify a logging > > > domain > > > for an entire source file, which the EINA_LOG_*() macros would use. This > > > would cut down on typing and errors in consistency, and increase the SNR > > > of my > > > code. > > > > > > My suggestion: the EINA_LOG_*() macros always log to > > > EINA_LOG_DOMAIN_DEFAULT, > > > which would initially be set to EINA_LOG_DOMAIN_GLOBAL, and may be > > > overridden > > > by a developer in a particular file. The complication is that it would > > > have > > > to be reset for the next file. On the other hand, it could encourage > > > better > > > developer habits regarding header files and whatnot. > > > > Hum... this do make sense. I even like the short 3 letter macros, but > > doing this could be very helpful and backwards compatible! > > > > Could you send a patch doing that, with documentation updated? > > > > BR, > > > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -- > > MSN: barbi...@gmail.com > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sat, 27 Feb 2010 03:11:35 -0300 Gustavo Sverzut Barbieri
said:
> On Sat, Feb 27, 2010 at 3:03 AM, Vincent Torri wrote:
> >
> >
> > On Sat, 27 Feb 2010, Carsten Haitzler (The Rasterman) wrote:
> >
> >> On Fri, 26 Feb 2010 21:23:19 -0300 Gustavo Sverzut Barbieri
> >> said:
> >>
> >>> On Fri, Feb 26, 2010 at 3:02 AM, Carsten Haitzler
> >>> wrote:
>
> On Thu, 25 Feb 2010 15:01:02 -0300 Gustavo Sverzut Barbieri
> said:
>
> because eina_log doesnt do what i want. i'm busy tracking down issues
> not
> trying to get a gold star for using eina (which doesnt do what i want -
> i
> DONT want any code there if its turned off - no fn call - nothing, but i
> also dont ant to disable logging in general). eina ALWAYS adds logging
> code
> - ALWAYS. i dont want that. (either its a eina_log_print or a do while
> with
> an if in it to call the same fn).
> >>>
> >>> you can set maximum log level and define your func to be of that
> >>> level. in that case there will be code, but it will fall into 2
> >>> constant comparison and compilers will just remove the code into the
> >>> binary, like:
> >>>
> >>> if (5 > 4) { debug ... }
> >>>
> >>
> >> depends on optimisation level. also this would require i would have sat
> >> and
> >> hunted for such features in eina_log before doing this and that would
> >> presume
> >> it has what i was after - which it does not - i had more important things
> >> to do
> >> like actually find bugs/problems. also i dont want eina's log formatting
> >> with
> >> color
> >
> > you can set you own print function by using eina_log_print_cb_set()
> >
> > , and the output doesnt align columns for easy reading (notice my printf %
> >>
> >> 30s etc.)
> >
> > same as above
> >
> > Vincent
> >
> > so of course i'm not going to look at it as it's already "not what i
> >>
> >> want" :). in the end this will be turned on via compiling anyway
> >> - and disabled via compiling again - so the end result will be the same.
>
> and disable color and function/file name using envvars.
and all this extra work for... what gain? eh? :)
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sat, Feb 27, 2010 at 3:03 AM, Vincent Torri wrote:
>
>
> On Sat, 27 Feb 2010, Carsten Haitzler (The Rasterman) wrote:
>
>> On Fri, 26 Feb 2010 21:23:19 -0300 Gustavo Sverzut Barbieri
>> said:
>>
>>> On Fri, Feb 26, 2010 at 3:02 AM, Carsten Haitzler
>>> wrote:
On Thu, 25 Feb 2010 15:01:02 -0300 Gustavo Sverzut Barbieri
said:
because eina_log doesnt do what i want. i'm busy tracking down issues
not
trying to get a gold star for using eina (which doesnt do what i want -
i
DONT want any code there if its turned off - no fn call - nothing, but i
also dont ant to disable logging in general). eina ALWAYS adds logging
code
- ALWAYS. i dont want that. (either its a eina_log_print or a do while
with
an if in it to call the same fn).
>>>
>>> you can set maximum log level and define your func to be of that
>>> level. in that case there will be code, but it will fall into 2
>>> constant comparison and compilers will just remove the code into the
>>> binary, like:
>>>
>>> if (5 > 4) { debug ... }
>>>
>>
>> depends on optimisation level. also this would require i would have sat
>> and
>> hunted for such features in eina_log before doing this and that would
>> presume
>> it has what i was after - which it does not - i had more important things
>> to do
>> like actually find bugs/problems. also i dont want eina's log formatting
>> with
>> color
>
> you can set you own print function by using eina_log_print_cb_set()
>
> , and the output doesnt align columns for easy reading (notice my printf %
>>
>> 30s etc.)
>
> same as above
>
> Vincent
>
> so of course i'm not going to look at it as it's already "not what i
>>
>> want" :). in the end this will be turned on via compiling anyway
>> - and disabled via compiling again - so the end result will be the same.
and disable color and function/file name using envvars.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sat, 27 Feb 2010, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 26 Feb 2010 21:23:19 -0300 Gustavo Sverzut Barbieri
> said:
>
>> On Fri, Feb 26, 2010 at 3:02 AM, Carsten Haitzler
>> wrote:
>>> On Thu, 25 Feb 2010 15:01:02 -0300 Gustavo Sverzut Barbieri
>>> said:
>>>
>>> because eina_log doesnt do what i want. i'm busy tracking down issues not
>>> trying to get a gold star for using eina (which doesnt do what i want - i
>>> DONT want any code there if its turned off - no fn call - nothing, but i
>>> also dont ant to disable logging in general). eina ALWAYS adds logging code
>>> - ALWAYS. i dont want that. (either its a eina_log_print or a do while with
>>> an if in it to call the same fn).
>>
>> you can set maximum log level and define your func to be of that
>> level. in that case there will be code, but it will fall into 2
>> constant comparison and compilers will just remove the code into the
>> binary, like:
>>
>> if (5 > 4) { debug ... }
>>
>
> depends on optimisation level. also this would require i would have sat and
> hunted for such features in eina_log before doing this and that would presume
> it has what i was after - which it does not - i had more important things to
> do
> like actually find bugs/problems. also i dont want eina's log formatting with
> color
you can set you own print function by using eina_log_print_cb_set()
, and the output doesnt align columns for easy reading (notice my printf %
> 30s etc.)
same as above
Vincent
so of course i'm not going to look at it as it's already "not what i
> want" :). in the end this will be turned on via compiling anyway
> - and disabled via compiling again - so the end result will be the same.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Fri, 26 Feb 2010 21:23:19 -0300 Gustavo Sverzut Barbieri
said:
> On Fri, Feb 26, 2010 at 3:02 AM, Carsten Haitzler
> wrote:
> > On Thu, 25 Feb 2010 15:01:02 -0300 Gustavo Sverzut Barbieri
> > said:
> >
> > because eina_log doesnt do what i want. i'm busy tracking down issues not
> > trying to get a gold star for using eina (which doesnt do what i want - i
> > DONT want any code there if its turned off - no fn call - nothing, but i
> > also dont ant to disable logging in general). eina ALWAYS adds logging code
> > - ALWAYS. i dont want that. (either its a eina_log_print or a do while with
> > an if in it to call the same fn).
>
> you can set maximum log level and define your func to be of that
> level. in that case there will be code, but it will fall into 2
> constant comparison and compilers will just remove the code into the
> binary, like:
>
> if (5 > 4) { debug ... }
>
depends on optimisation level. also this would require i would have sat and
hunted for such features in eina_log before doing this and that would presume
it has what i was after - which it does not - i had more important things to do
like actually find bugs/problems. also i dont want eina's log formatting with
color, and the output doesnt align columns for easy reading (notice my printf %
30s etc.) so of course i'm not going to look at it as it's already "not what i
want" :). in the end this will be turned on via compiling anyway
- and disabled via compiling again - so the end result will be the same.
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Fri, Feb 26, 2010 at 3:02 AM, Carsten Haitzler wrote:
> On Thu, 25 Feb 2010 15:01:02 -0300 Gustavo Sverzut Barbieri
> said:
>
> because eina_log doesnt do what i want. i'm busy tracking down issues not
> trying to get a gold star for using eina (which doesnt do what i want - i DONT
> want any code there if its turned off - no fn call - nothing, but i also dont
> ant to disable logging in general). eina ALWAYS adds logging code - ALWAYS. i
> dont want that. (either its a eina_log_print or a do while with an if in it to
> call the same fn).
you can set maximum log level and define your func to be of that
level. in that case there will be code, but it will fall into 2
constant comparison and compilers will just remove the code into the
binary, like:
if (5 > 4) { debug ... }
so again, consider keeping the debugs with eina_log.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Thu, 25 Feb 2010 15:01:02 -0300 Gustavo Sverzut Barbieri said: because eina_log doesnt do what i want. i'm busy tracking down issues not trying to get a gold star for using eina (which doesnt do what i want - i DONT want any code there if its turned off - no fn call - nothing, but i also dont ant to disable logging in general). eina ALWAYS adds logging code - ALWAYS. i dont want that. (either its a eina_log_print or a do while with an if in it to call the same fn). > On Thu, Feb 25, 2010 at 9:19 AM, Enlightenment SVN > wrote: > > Log: > > add lots of logging functions - for trackign x overhead when u cant get > > symbols... booo! - disabled of course. > > damn raster, if you take so much time to do all this work, why don't > you take 5 minutes more to check out eina's logging API? > > If you did it, it would be clear that overhead would not be added, > you'd benefit from configurable logging and would avoid duplication of > code. > > If one want to avoid overhead with eina logging, just create another > domain or level and use the same as eina's "maximum log level". > > Anyway, let's try to avoid such things in future. > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
Here's a tarball containing a prospective patch and a few commented test programs: http://tam.hiddenrock.com/eina-log-default.tar.gz I haven't yet updated the documentation because I'm not entirely convinced it's correct, but I'm not sure why, so I'd like a few second pairs of eyes on it. Thanks. pete On Thu, Feb 25, 2010 at 05:18:10PM -0300, Gustavo Sverzut Barbieri wrote: > On Thu, Feb 25, 2010 at 5:00 PM, Peter Johnson wrote: > > Cool, thanks. > > > > My reading of those pages indicates that, were I to follow the > > recommendations > > contained therein, I would always use the EINA_LOG_DOM_*() macros and never > > the EINA_LOG_*() macros, because they use EINA_LOG_DOMAIN_GLOBAL, and as a > > good developer I should have my own domain(s) for my project. > > > > I think it would be helpful to allow developers to specify a logging domain > > for an entire source file, which the EINA_LOG_*() macros would use. This > > would cut down on typing and errors in consistency, and increase the SNR of > > my > > code. > > > > My suggestion: the EINA_LOG_*() macros always log to > > EINA_LOG_DOMAIN_DEFAULT, > > which would initially be set to EINA_LOG_DOMAIN_GLOBAL, and may be > > overridden > > by a developer in a particular file. The complication is that it would have > > to be reset for the next file. On the other hand, it could encourage better > > developer habits regarding header files and whatnot. > > Hum... this do make sense. I even like the short 3 letter macros, but > doing this could be very helpful and backwards compatible! > > Could you send a patch doing that, with documentation updated? > > BR, > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Thu, Feb 25, 2010 at 3:29 PM, Vincent Torri wrote: > On Thu, 25 Feb 2010, Gustavo Sverzut Barbieri wrote: > >> On Thu, Feb 25, 2010 at 9:19 AM, Enlightenment SVN >> wrote: >>> >>> Log: >>> add lots of logging functions - for trackign x overhead when u cant get >>> symbols... booo! - disabled of course. >> >> damn raster, if you take so much time to do all this work, why don't >> you take 5 minutes more to check out eina's logging API? >> >> If you did it, it would be clear that overhead would not be added, >> you'd benefit from configurable logging and would avoid duplication of >> code. >> >> If one want to avoid overhead with eina logging, just create another >> domain or level and use the same as eina's "maximum log level". >> >> Anyway, let's try to avoid such things in future. > > no : raster should modify what he did. Otherwise it will be a mess. In > addition, eina log will do exactly what he wants not just that, but would avoid replicating __FILE__, __LINE__ and __FUNCTION__ on every debug line ;-) really, there is already logging infrastructure there in ecore-x, if he wants another "domain", just create a new one and name macros differently, but use the standards and let's not require people to change private.h to define or not the debug :-/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Thu, Feb 25, 2010 at 5:00 PM, Peter Johnson wrote: > Cool, thanks. > > My reading of those pages indicates that, were I to follow the recommendations > contained therein, I would always use the EINA_LOG_DOM_*() macros and never > the EINA_LOG_*() macros, because they use EINA_LOG_DOMAIN_GLOBAL, and as a > good developer I should have my own domain(s) for my project. > > I think it would be helpful to allow developers to specify a logging domain > for an entire source file, which the EINA_LOG_*() macros would use. This > would cut down on typing and errors in consistency, and increase the SNR of my > code. > > My suggestion: the EINA_LOG_*() macros always log to EINA_LOG_DOMAIN_DEFAULT, > which would initially be set to EINA_LOG_DOMAIN_GLOBAL, and may be overridden > by a developer in a particular file. The complication is that it would have > to be reset for the next file. On the other hand, it could encourage better > developer habits regarding header files and whatnot. Hum... this do make sense. I even like the short 3 letter macros, but doing this could be very helpful and backwards compatible! Could you send a patch doing that, with documentation updated? BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
Cool, thanks. My reading of those pages indicates that, were I to follow the recommendations contained therein, I would always use the EINA_LOG_DOM_*() macros and never the EINA_LOG_*() macros, because they use EINA_LOG_DOMAIN_GLOBAL, and as a good developer I should have my own domain(s) for my project. I think it would be helpful to allow developers to specify a logging domain for an entire source file, which the EINA_LOG_*() macros would use. This would cut down on typing and errors in consistency, and increase the SNR of my code. My suggestion: the EINA_LOG_*() macros always log to EINA_LOG_DOMAIN_DEFAULT, which would initially be set to EINA_LOG_DOMAIN_GLOBAL, and may be overridden by a developer in a particular file. The complication is that it would have to be reset for the next file. On the other hand, it could encourage better developer habits regarding header files and whatnot. pete (My apologies if this has already been discussed.) On Thu, Feb 25, 2010 at 07:48:29PM +0100, Vincent Torri wrote: > > > On Thu, 25 Feb 2010, Peter Johnson wrote: > > >>really, there is already logging infrastructure there in ecore-x, if > >>he wants another "domain", just create a new one and name macros > >>differently, but use the standards and let's not require people to > >>change private.h to define or not the debug :-/ > > > >Where is this documented? > > http://docs.enlightenment.org/auto/eina/group__Eina__Log__Group.html > > http://docs.enlightenment.org/auto/eina/tutorial_log_page.html > > it's in the documentation page of the site > > Vincent -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
> really, there is already logging infrastructure there in ecore-x, if > he wants another "domain", just create a new one and name macros > differently, but use the standards and let's not require people to > change private.h to define or not the debug :-/ Where is this documented? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Thu, 25 Feb 2010, Gustavo Sverzut Barbieri wrote: On Thu, Feb 25, 2010 at 9:19 AM, Enlightenment SVN wrote: Log: add lots of logging functions - for trackign x overhead when u cant get symbols... booo! - disabled of course. damn raster, if you take so much time to do all this work, why don't you take 5 minutes more to check out eina's logging API? If you did it, it would be clear that overhead would not be added, you'd benefit from configurable logging and would avoid duplication of code. If one want to avoid overhead with eina logging, just create another domain or level and use the same as eina's "maximum log level". Anyway, let's try to avoid such things in future. no : raster should modify what he did. Otherwise it will be a mess. In addition, eina log will do exactly what he wants Vincent-- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Thu, Feb 25, 2010 at 3:48 PM, Vincent Torri wrote: > On Thu, 25 Feb 2010, Peter Johnson wrote: > >>> really, there is already logging infrastructure there in ecore-x, if >>> he wants another "domain", just create a new one and name macros >>> differently, but use the standards and let's not require people to >>> change private.h to define or not the debug :-/ >> >> Where is this documented? > > http://docs.enlightenment.org/auto/eina/group__Eina__Log__Group.html > > http://docs.enlightenment.org/auto/eina/tutorial_log_page.html > > it's in the documentation page of the site http://docs.enlightenment.org/auto/eina/group__Eina__Log__Group.html#ga00e2a10370282673064d2bd3579b463c documents the EINA_LOG_LEVEL_MAXIMUM usage to compile out stuff. This is in the eina_log.h -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Thu, 25 Feb 2010, Peter Johnson wrote: >> really, there is already logging infrastructure there in ecore-x, if >> he wants another "domain", just create a new one and name macros >> differently, but use the standards and let's not require people to >> change private.h to define or not the debug :-/ > > Where is this documented? http://docs.enlightenment.org/auto/eina/group__Eina__Log__Group.html http://docs.enlightenment.org/auto/eina/tutorial_log_page.html it's in the documentation page of the site Vincent -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Thu, Feb 25, 2010 at 9:19 AM, Enlightenment SVN wrote: > Log: > add lots of logging functions - for trackign x overhead when u cant get > symbols... booo! - disabled of course. damn raster, if you take so much time to do all this work, why don't you take 5 minutes more to check out eina's logging API? If you did it, it would be clear that overhead would not be added, you'd benefit from configurable logging and would avoid duplication of code. If one want to avoid overhead with eina logging, just create another domain or level and use the same as eina's "maximum log level". Anyway, let's try to avoid such things in future. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
On Sun, 17 Jan 2010 00:36:19 -0200 Fabiano Fidêncio
said:
fixed. i got myself some xi2 headers now.
> Hello, Raster.
>
> ecore_x_events.c has some troubles here. :-(.
> The output log is attached.
>
> []'s
>
> On Sat, Jan 16, 2010 at 11:33 PM, Enlightenment SVN <
> no-re...@enlightenment.org> wrote:
>
> > Log:
> > opcode -> _ecore_x_xi2_opcode
> >
> > Author: raster
> > Date: 2010-01-16 17:33:43 -0800 (Sat, 16 Jan 2010)
> > New Revision: 45236
> >
> > Modified:
> > trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
> >
> > Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
> > ===
> > --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2010-01-16 21:01:59
> > UTC (rev 45235)
> > +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2010-01-17 01:33:43
> > UTC (rev 45236)
> > @@ -439,7 +439,7 @@
> >
> > #ifdef ECORE_XI2
> >if (xevent->xcookie.type == GenericEvent &&
> > - xevent->xcookie.extension == opcode)
> > + xevent->xcookie.extension == _ecore_x_xi2_opcode)
> > {
> > if (XGetEventData(_ecore_x_disp &(xevent->xcookie)))
> > {
> >
> >
> >
> > --
> > Throughout its 18-year history, RSA Conference consistently attracts the
> > world's best and brightest in the field, creating opportunities for
> > Conference
> > attendees to learn about information security's most important issues
> > through
> > interactions with peers, luminaries and emerging and established companies.
> > http://p.sf.net/sfu/rsaconf-dev2dev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
>
>
>
> --
> Fabiano Fidêncio
> ProFUSION embedded systems
> http://www.profusion.mobi
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib
Hello, Raster.
ecore_x_events.c has some troubles here. :-(.
The output log is attached.
[]'s
On Sat, Jan 16, 2010 at 11:33 PM, Enlightenment SVN <
no-re...@enlightenment.org> wrote:
> Log:
> opcode -> _ecore_x_xi2_opcode
>
> Author: raster
> Date: 2010-01-16 17:33:43 -0800 (Sat, 16 Jan 2010)
> New Revision: 45236
>
> Modified:
> trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
>
> Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c
> ===
> --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2010-01-16 21:01:59
> UTC (rev 45235)
> +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_events.c 2010-01-17 01:33:43
> UTC (rev 45236)
> @@ -439,7 +439,7 @@
>
> #ifdef ECORE_XI2
>if (xevent->xcookie.type == GenericEvent &&
> - xevent->xcookie.extension == opcode)
> + xevent->xcookie.extension == _ecore_x_xi2_opcode)
> {
> if (XGetEventData(_ecore_x_disp &(xevent->xcookie)))
> {
>
>
>
> --
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
Fabiano Fidêncio
ProFUSION embedded systems
http://www.profusion.mobi
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /media/files/e17/trunk/ecore/missing --run autoheader)
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make all-recursive
make[1]: Entering directory `/media/files/e17/trunk/ecore'
Making all in doc
make[2]: Entering directory `/media/files/e17/trunk/ecore/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/media/files/e17/trunk/ecore/doc'
Making all in src
make[2]: Entering directory `/media/files/e17/trunk/ecore/src'
Making all in lib
make[3]: Entering directory `/media/files/e17/trunk/ecore/src/lib'
Making all in ecore
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore'
CC ecore.lo
CC ecore_anim.lo
CC ecore_app.lo
CC ecore_events.lo
CC ecore_getopt.lo
CC ecore_hash.lo
CC ecore_idle_enterer.lo
CC ecore_idle_exiter.lo
CC ecore_idler.lo
CC ecore_list.lo
CC ecore_main.lo
CC ecore_path.lo
CC ecore_pipe.lo
CC ecore_plugin.lo
CC ecore_poll.lo
CC ecore_sheap.lo
CC ecore_signal.lo
CC ecore_str.lo
CC ecore_strbuf.lo
CC ecore_time.lo
CC ecore_timer.lo
CC ecore_tree.lo
CC ecore_value.lo
CC ecore_thread.lo
CC ecore_glib.lo
CC ecore_exe.lo
CCLD libecore.la
make[4]: Leaving directory `/media/files/e17/trunk/ecore/src/lib/ecore'
Making all in ecore_input
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore_input'
CC ecore_input.lo
CCLD libecore_input.la
make[4]: Leaving directory `/media/files/e17/trunk/ecore/src/lib/ecore_input'
Making all in ecore_input_evas
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore_input_evas'
CC ecore_input_evas.lo
CCLD libecore_input_evas.la
make[4]: Leaving directory `/media/files/e17/trunk/ecore/src/lib/ecore_input_evas'
Making all in ecore_job
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore_job'
CC ecore_job.lo
CCLD libecore_job.la
make[4]: Leaving directory `/media/files/e17/trunk/ecore/src/lib/ecore_job'
Making all in ecore_txt
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore_txt'
CC ecore_txt.lo
CCLD libecore_txt.la
make[4]: Leaving directory `/media/files/e17/trunk/ecore/src/lib/ecore_txt'
Making all in ecore_fb
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore_fb'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/media/files/e17/trunk/ecore/src/lib/ecore_fb'
Making all in ecore_directfb
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore_directfb'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/media/files/e17/trunk/ecore/src/lib/ecore_directfb'
Making all in ecore_con
make[4]: Entering directory `/media/files/e17/trunk/ecore/src/lib/ecore_con'
CC ecore_con.lo
CC ecore_con_dns.lo
CC ecore_con_ssl.lo
ecore_con_ssl.c: In function ‘_ecore_con_ssl_server_init_gnutls’:
ecore_con_ssl.c:229: warning: cast to pointer from integer of different size
ecore_con_ssl.c: In function ‘_ecore_con_ssl_client_init_gnutls’:
ecore_con_ssl.c:357: war
