Re: [E-devel] E CVS: libs/ecore nash
On 10/25/07, Brett Nash <[EMAIL PROTECTED]> wrote:
> > >struct _Ecore_Exe_Event_Del /** Process exit event */
> > > {
> > > - pid_t pid; /**< The process ID of the process that exited */
> > > - intexit_code; /**< The exit code of the process */
> > > - Ecore_Exe *exe; /**< The handle to the exited process, or NULL if not
> > > found */
> > > - intexit_signal; /** < The signal that caused the process to
> > > exit */
> > > - char exited: 1; /** < set to 1 if the process exited of its
> > > own accord */
> > > - char signalled : 1; /** < set to 1 id the process exited due to
> > > uncaught signal */
> > > - void *ext_data; /**< Extension data - not used */
> > > - siginfo_t data; /**< Signal info */
> > > + pid_t pid; /**< The process ID of the process that exited */
> > > + int exit_code; /**< The exit code of the process */
> > > + Ecore_Exe*exe; /**< The handle to the exited process, or NULL if
> > > not found */
> > > + int exit_signal; /** < The signal that caused the process
> > > to exit */
> > > + unsigned char exited: 1; /** < set to 1 if the process exited of
> > > its own accord */
> > > + unsigned char signalled : 1; /** < set to 1 id the process exited due
> > > to uncaught signal */
> > > + void *ext_data; /**< Extension data - not used */
> > > + siginfo_t data; /**< Signal info */
> > > };
> >
> >
> > Shouldn't the bit-field members be placed at the end of the struct to be
> > useful ?
>
> Not sure exactly what you mean.. but there is no real reason to do
> anything except make sure the bitfields are adjacent in the structure.
>
> Otherwise it won't make any difference for size (the whole structure
> will be aligned, and since there is no small members to pack smaller
> than the natural machine alignment requirements no gain there).
>
> In any case, I'd rather just do the minimum change to remove the
> warning/unportable-declaration - which is add unsigned.
I think Vincent was wondering about my last commit to ETK, that I
tried to remove struct holes with information provided by pahole. In
your case it will contain these holes since structs will be aligned,
and things like [char][pointer] will be laid out effectively as
[long][pointer], same for int, long, ... in the place of [pointer].
For better use of memory, you should try to pack-a-hole (pahole
tool is meant for that) and even better: keep memory that is used
together within the same cacheline (pahole helps here to).
All in all is usually better to keep these bitfield as unsigned char
(or int, or short,...) at the end of the struct.
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2007-10-25 07:05:58 -0700
Build log for Enlightenment DR 0.17 on 2007-10-25 07:05:58 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Nightly build log for E17 on 2007-10-25 07:05:58 -0700
This is from the 'ecore' build log checking whether ecore_desktop module is to be built... checking for dlopen in -ldl... (cached) yes ... config.status: creating ecore-desktop.pc ... Optional Modules: Ecore_Desktop: no Since this doesnt get built, engage fails on the test system. Could it be a bug in the ecore makefile? On 25/10/2007, Nightly build system <[EMAIL PROTECTED]> wrote: > Build log for Enlightenment DR 0.17 on 2007-10-25 07:05:58 -0700 > Build logs are available at http://download.enlightenment.org/tests/logs > > Packages that failed to build: > engage http://download.enlightenment.org/tests/logs/engage.log > epdf http://download.enlightenment.org/tests/logs/epdf.log > evolve http://download.enlightenment.org/tests/logs/evolve.log > > Packages with no supported build system: > esmart_rsvg, exorcist, python-efl, > > Packages skipped: > camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, > Evas_Perl, > evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, > > Packages that build OK: > alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, > edje_viewer, edvi, eet, eflame, eflpp, efreet, elapse, elation, elicit, > elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, > engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, > entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, > estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, > exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, > imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, > mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, > snow, taskbar, tclock, uptime, weather, winselector, wlan, > > Debian GNU/Linux 4.0 \n \l > > Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 > GNU/Linux > > > See http://download.enlightenment.org/tests/ for details. > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Nightly build log for E17 on 2007-10-25 07:05:58 -0700
On Thu, Oct 25, 2007 at 11:21:58PM +0800, Toma wrote : > This is from the 'ecore' build log > > checking whether ecore_desktop module is to be built... checking for > dlopen in -ldl... (cached) yes > ... > config.status: creating ecore-desktop.pc > ... > Optional Modules: > Ecore_Desktop: no > > Since this doesnt get built, engage fails on the test system. Could it > be a bug in the ecore makefile? > > Ecore_Desktop is deprecated, superseded by efreet, and thus is disabled by configure unless told otherwise. Anyway, there's no real point in building engage for now, as it's (as far I can tell) completely broken. Cheers Albin > > On 25/10/2007, Nightly build system <[EMAIL PROTECTED]> wrote: > > Build log for Enlightenment DR 0.17 on 2007-10-25 07:05:58 -0700 > > Build logs are available at http://download.enlightenment.org/tests/logs > > > > Packages that failed to build: > > engage http://download.enlightenment.org/tests/logs/engage.log > > epdf http://download.enlightenment.org/tests/logs/epdf.log > > evolve http://download.enlightenment.org/tests/logs/evolve.log > > > > Packages with no supported build system: > > esmart_rsvg, exorcist, python-efl, > > > > Packages skipped: > > camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, > > Evas_Perl, > > evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, > > > > Packages that build OK: > > alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, > > edje_viewer, edvi, eet, eflame, eflpp, efreet, elapse, elation, elicit, > > elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, > > engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, > > entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, > > estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, > > exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, > > imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, > > mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, > > slideshow, > > snow, taskbar, tclock, uptime, weather, winselector, wlan, > > > > Debian GNU/Linux 4.0 \n \l > > > > Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 > > GNU/Linux > > > > > > See http://download.enlightenment.org/tests/ for details. > > > > > > - > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Nightly build log for E17 on 2007-10-25 07:05:58 -0700
> Ecore_Desktop is deprecated, superseded by efreet, and thus is disabled by > configure unless told otherwise. Anyway, there's no real point in building > engage > for now, as it's (as far I can tell) completely broken. > > Cheers How about moving engage to the skipped packages? Also, I think its been mentioned before, but poppler on 4.0 contains an API break http://packages.debian.org/sid/libpoppler-dev contains the magical /usr/include/poppler/UGooString.h file that will make epdf compile a little further. But i suspect along with engage, that its dead. Ta. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore nash
On Thu, 2007-10-25 at 08:58 -0300, Gustavo Sverzut Barbieri wrote:
> On 10/25/07, Brett Nash <[EMAIL PROTECTED]> wrote:
> > > >struct _Ecore_Exe_Event_Del /** Process exit event */
> > > > {
> > > > - pid_t pid; /**< The process ID of the process that exited */
> > > > - intexit_code; /**< The exit code of the process */
> > > > - Ecore_Exe *exe; /**< The handle to the exited process, or NULL if
> > > > not found */
> > > > - intexit_signal; /** < The signal that caused the process to
> > > > exit */
> > > > - char exited: 1; /** < set to 1 if the process exited of
> > > > its own accord */
> > > > - char signalled : 1; /** < set to 1 id the process exited due
> > > > to uncaught signal */
> > > > - void *ext_data; /**< Extension data - not used */
> > > > - siginfo_t data; /**< Signal info */
> > > > + pid_t pid; /**< The process ID of the process that exited */
> > > > + int exit_code; /**< The exit code of the process */
> > > > + Ecore_Exe*exe; /**< The handle to the exited process, or NULL
> > > > if not found */
> > > > + int exit_signal; /** < The signal that caused the process
> > > > to exit */
> > > > + unsigned char exited: 1; /** < set to 1 if the process exited
> > > > of its own accord */
> > > > + unsigned char signalled : 1; /** < set to 1 id the process exited
> > > > due to uncaught signal */
> > > > + void *ext_data; /**< Extension data - not used */
> > > > + siginfo_t data; /**< Signal info */
> > > > };
> >
> > In any case, I'd rather just do the minimum change to remove the
> > warning/unportable-declaration - which is add unsigned.
>
> I think Vincent was wondering about my last commit to ETK, that I
> tried to remove struct holes with information provided by pahole. In
> your case it will contain these holes since structs will be aligned,
> and things like [char][pointer] will be laid out effectively as
> [long][pointer], same for int, long, ... in the place of [pointer].
>For better use of memory, you should try to pack-a-hole (pahole
> tool is meant for that) and even better: keep memory that is used
> together within the same cacheline (pahole helps here to).
I seem to have unintentionally opened a can of worms here. Just to be
clear they were meant minimal patches - adding unsigned to 1-bit fields.
Additional changes were to make the code line up in the same way most of
the structures are aligned.
The reason I went after the bit fields is because they are totally
undefined in C - the valid range is exactly the value 0. They may not
even store a second value successfully (more specifically they may store
0 and -0, which both compare true to 0).
If anyone wants to sort the structures for packing or similar, feel
free, I'm happy to apply sane patches, and deal with carsten beating me
up later ;-)
Currently I'm trying to get the warnings and errors from the static
analysis tools we use under control, as well as make the code clean on
64 bit systems. This is both for the commercial version we support and
upstream.
> All in all is usually better to keep these bitfield as unsigned char
> (or int, or short,...) at the end of the struct.
And I'll generally agree with this. Although there is a counter
argument if you really want to optimise cache-line friendliness ;-)
(eg lists should always be {data, next, prev} not {next, prev, data}).
However that's way out of scope at this time ;-)
Regards,
nash
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore nash
On Fri, 26 Oct 2007 09:46:44 +1000 Brett Nash <[EMAIL PROTECTED]> babbled:
> > I think Vincent was wondering about my last commit to ETK, that I
> > tried to remove struct holes with information provided by pahole. In
> > your case it will contain these holes since structs will be aligned,
> > and things like [char][pointer] will be laid out effectively as
> > [long][pointer], same for int, long, ... in the place of [pointer].
> >For better use of memory, you should try to pack-a-hole (pahole
> > tool is meant for that) and even better: keep memory that is used
> > together within the same cacheline (pahole helps here to).
>
> I seem to have unintentionally opened a can of worms here. Just to be
> clear they were meant minimal patches - adding unsigned to 1-bit fields.
> Additional changes were to make the code line up in the same way most of
> the structures are aligned.
>
> The reason I went after the bit fields is because they are totally
> undefined in C - the valid range is exactly the value 0. They may not
> even store a second value successfully (more specifically they may store
> 0 and -0, which both compare true to 0).
though technically true... there isn't a platform i know of that we'd even want
to run on - let alone be able to, that does not do 2's compliment :)
> If anyone wants to sort the structures for packing or similar, feel
> free, I'm happy to apply sane patches, and deal with carsten beating me
> up later ;-)
can i beat you up anyway? just for giggles? :)
> Currently I'm trying to get the warnings and errors from the static
> analysis tools we use under control, as well as make the code clean on
> 64 bit systems. This is both for the commercial version we support and
> upstream.
>
> > All in all is usually better to keep these bitfield as unsigned char
> > (or int, or short,...) at the end of the struct.
>
> And I'll generally agree with this. Although there is a counter
> argument if you really want to optimise cache-line friendliness ;-)
> (eg lists should always be {data, next, prev} not {next, prev, data}).
> However that's way out of scope at this time ;-)
>
> Regards,
> nash
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> 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)[EMAIL PROTECTED]
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
