Re: [E-devel] [Eet] patch to support cegcc compiler (Windows Mobile)
On Fri, 25 Jan 2008, Mike Frysinger wrote: On Friday 25 January 2008, Vincent Torri wrote: --- src/lib/Eet_private.h 29 Sep 2007 09:21:43 - 1.17 +++ src/lib/Eet_private.h 26 Jan 2008 00:04:53 - +#ifdef __CEGCC__ +# include windows.h +# define HAVE_BOOLEAN +# define XMD_H +# undef _LARGEFILE64_SOURCE #elif _WIN32 # include winsock2.h #endif --- src/lib/eet_lib.c 24 Jan 2008 08:41:23 - 1.85 +++ src/lib/eet_lib.c 26 Jan 2008 00:04:54 - #include sys/types.h -#ifndef _WIN32 -#include sys/mman.h +#if !defined (_WIN32) !defined (__CEGCC__) +# include sys/mman.h #endif -#ifndef _WIN32 +#if !defined (_WIN32) || defined (__CEGCC__) fcntl(fileno(ef-fp), F_SETFD, FD_CLOEXEC); #else /* FIXME: check if that code is needed / correct */ this is getting horrendous ... why cant you use proper autoconf checks ? what do you mean, exactly ? Vincent- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
#ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#elif _WIN32 -#include winsock2.h +# include netinet/in.h +#endif +#ifdef HAVE_WINSOCK2_H +# include winsock2.h #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? Please, revert what you committed. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Sat, 26 Jan 2008, Vincent Torri wrote: #ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#elif _WIN32 -#include winsock2.h +# include netinet/in.h +#endif +#ifdef HAVE_WINSOCK2_H +# include winsock2.h #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? Please, revert what you committed. more precisely, revert your changes when you check windows headers. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
On Fri, Jan 25, 2008 at 07:43:47AM -0300, Gustavo Sverzut Barbieri wrote: On Jan 25, 2008 12:40 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Fri, 25 Jan 2008 00:11:41 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Jan 24, 2008 11:42 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Jan 24, 2008 7:18 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: now i think this is a bit more generic a solution - but it adds overhead. so what about the pselect() method? anyone got input on that? Basically, pselect() is designed for exactly this situation. You block all of the signals you're going to handle during init or some other very early point, then you pass a mask of the signals you're going to unblock to pselect(). At this point, pselect() will atomically unblock the specified signals and call select() with the specified fd's, it also re-instates the original signal blocks after select() returns. Since this sequence is atomic, it prevents the race condition we currently have. Now the problem, this is a good solution on BSD and Solaris, but unfortunately Linux only fakes support for pselect() (unless this was fixed recently). On Linux pselect() is actually a wrapper exactly around the sequence sigprocmask(), select() sigprocmask(). So we still end up with a race condition between the first sigprocmask() call and the select() call. man page says: BUGS: Since version 2.1, glibc has provided an emulation of pselect() that is implemented using sigprocmask(2) and select(). This implementation remains vulnerable to the very race condition that pselect() was designed to prevent. On systems that lack pselect() reliable (and more portable) signal trapping can be achieved using the self-pipe trick (where a signal handler writes a byte to a pipe whose other end is monitored by select() in the main program.) however a bit earlier it says Linux has pselect(), and at least 2.6.23 implements it... so maybe this wrapper is just used as a fallback? that is the question - is it implemented kernel-wise widely enough to use it? or do we just stick to the old-fashioned self-pipe trick? I have not audited the Linux or GlibC code to check if that's the case (well implemented), but I truly believe that we can rely on this call for newer ( 2.6) kernels. Thanks for your comments and suggestions. I thinks I'll go with the pipe solution as I think there are too many unknowns with pselect: will it work if we build againts uclibc, newlib or klibc? or build on BSD or Solaris systems etc? Regards -- Lars Munch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Saturday 26 January 2008, Vincent Torri wrote: On Sat, 26 Jan 2008, Mike Frysinger wrote: On Saturday 26 January 2008, Vincent Torri wrote: #ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#elif _WIN32 -#include winsock2.h +# include netinet/in.h +#endif +#ifdef HAVE_WINSOCK2_H +# include winsock2.h #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? so you dont have to keep adding crap for every random windows related compiler. like the random windows mobile / ce / whatever microsoft puts out. do it once, do it right, and then you're done. You do not it right. Before doing that, I asked mingw devs on how to do that. I think that they know a bit more on how to do that than you. Please, revert what you committed. unless you can show this being incorrect, no With cegcc, I have to define / undefine macro (in Eet_private.h). So anyway I have to check whether or not cegcc is used or not. And as I told you, people that know a lot more than you on windows told me how I have to check things correctly. If you don't revert your changes, I'll do it myself and i would like you to ask me questions and waiting for my answers before commiting when dealing with windows stuff. I can do mistakes, and I would be glad to know them. But here, what i did here is correct. polluting multiple places with windows cruft that do the same thing over and over is not the way to go. if you want to maintain a mess of ifdefs, write it in *one* place and have all the other files pull it in. -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Saturday 26 January 2008, Vincent Torri wrote: #ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#elif _WIN32 -#include winsock2.h +# include netinet/in.h +#endif +#ifdef HAVE_WINSOCK2_H +# include winsock2.h #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? so you dont have to keep adding crap for every random windows related compiler. like the random windows mobile / ce / whatever microsoft puts out. do it once, do it right, and then you're done. Please, revert what you committed. unless you can show this being incorrect, no -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Sat, 26 Jan 2008, Mike Frysinger wrote: On Saturday 26 January 2008, Vincent Torri wrote: #ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#elif _WIN32 -#include winsock2.h +# include netinet/in.h +#endif +#ifdef HAVE_WINSOCK2_H +# include winsock2.h #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? so you dont have to keep adding crap for every random windows related compiler. like the random windows mobile / ce / whatever microsoft puts out. do it once, do it right, and then you're done. You do not it right. Before doing that, I asked mingw devs on how to do that. I think that they know a bit more on how to do that than you. Please, revert what you committed. unless you can show this being incorrect, no With cegcc, I have to define / undefine macro (in Eet_private.h). So anyway I have to check whether or not cegcc is used or not. And as I told you, people that know a lot more than you on windows told me how I have to check things correctly. If you don't revert your changes, I'll do it myself and i would like you to ask me questions and waiting for my answers before commiting when dealing with windows stuff. I can do mistakes, and I would be glad to know them. But here, what i did here is correct. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/ecore vapier
On Sat, 26 Jan 2008, Mike Frysinger wrote: On Saturday 26 January 2008, Vincent Torri wrote: On Sat, 26 Jan 2008, Mike Frysinger wrote: On Saturday 26 January 2008, Vincent Torri wrote: #ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#elif _WIN32 -#include winsock2.h +# include netinet/in.h +#endif +#ifdef HAVE_WINSOCK2_H +# include winsock2.h #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? so you dont have to keep adding crap for every random windows related compiler. like the random windows mobile / ce / whatever microsoft puts out. do it once, do it right, and then you're done. You do not it right. Before doing that, I asked mingw devs on how to do that. I think that they know a bit more on how to do that than you. Please, revert what you committed. unless you can show this being incorrect, no With cegcc, I have to define / undefine macro (in Eet_private.h). So anyway I have to check whether or not cegcc is used or not. And as I told you, people that know a lot more than you on windows told me how I have to check things correctly. If you don't revert your changes, I'll do it myself and i would like you to ask me questions and waiting for my answers before commiting when dealing with windows stuff. I can do mistakes, and I would be glad to know them. But here, what i did here is correct. polluting multiple places with windows cruft that do the same thing over and over is not the way to go. if you want to maintain a mess of ifdefs, write it in *one* place and have all the other files pull it in. for example, about the mmap and fcntl calls in eet_lib.c, you would suggest to write in eet_win32.c the ports of these functions and call them in eet_lib.c ? I'm not against it. I can do it. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Sat, 26 Jan 2008, Enlightenment CVS wrote: +#ifdef _WIN32F ^ is it a typo ? Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/ecore vapier
On Saturday 26 January 2008, Vincent Torri wrote: On Sat, 26 Jan 2008, Mike Frysinger wrote: On Saturday 26 January 2008, Vincent Torri wrote: On Sat, 26 Jan 2008, Mike Frysinger wrote: On Saturday 26 January 2008, Vincent Torri wrote: #ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#elif _WIN32 -#include winsock2.h +# include netinet/in.h +#endif +#ifdef HAVE_WINSOCK2_H +# include winsock2.h #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? so you dont have to keep adding crap for every random windows related compiler. like the random windows mobile / ce / whatever microsoft puts out. do it once, do it right, and then you're done. You do not it right. Before doing that, I asked mingw devs on how to do that. I think that they know a bit more on how to do that than you. Please, revert what you committed. unless you can show this being incorrect, no With cegcc, I have to define / undefine macro (in Eet_private.h). So anyway I have to check whether or not cegcc is used or not. And as I told you, people that know a lot more than you on windows told me how I have to check things correctly. If you don't revert your changes, I'll do it myself and i would like you to ask me questions and waiting for my answers before commiting when dealing with windows stuff. I can do mistakes, and I would be glad to know them. But here, what i did here is correct. polluting multiple places with windows cruft that do the same thing over and over is not the way to go. if you want to maintain a mess of ifdefs, write it in *one* place and have all the other files pull it in. for example, about the mmap and fcntl calls in eet_lib.c, you would suggest to write in eet_win32.c the ports of these functions and call them in eet_lib.c ? exactly ... where we can unify these pieces without touching common code the better. not sure if there's a core piece of e17 where we can move all of this, but if we had a few files that we could just drop into the different e libraries, that'd be a good start i think (think gnulib here). like a system.h where we stick all of the win32 ifdefs/includes and then everyone pulls that. your thoughts on mmap/fcntl sound like an excellent example. _e_mmap() / _e_fd_cloexec(). -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
exactly ... where we can unify these pieces without touching common code the better. not sure if there's a core piece of e17 where we can move all of this, but if we had a few files that we could just drop into the different e libraries, that'd be a good start i think (think gnulib here). I've tried to use gnulib once, for the port of the linux functions. It's a pain to install and to use. I'll never touch that beast anymore :) Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore pfritz
nash schrieb:
On Fri, 2008-01-25 at 13:28 -0500, Enlightenment CVS wrote:
Enlightenment CVS committal
Author : pfritz
Project : e17
Module : libs/ecore
===
RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore.h,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -3 -r1.57 -r1.58
--- Ecore.h 11 Jan 2008 07:33:56 - 1.57
+++ Ecore.h 25 Jan 2008 18:28:16 - 1.58
@@ -61,6 +61,9 @@
extern C {
#endif
+#define ECORE_CALLBACK_CANCEL 0; /** Return value to remove a callback */
+#define ECORE_CALLBACK_RENEW 1; /** Return value to keep a callback */
+
I'm guessing you don't mean for those two semi-colons to be there...
Yes, you are right. That was a mistake.
Thanks,
Peter
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
On Jan 26, 2008 6:13 AM, Lars Munch [EMAIL PROTECTED] wrote: On Fri, Jan 25, 2008 at 07:43:47AM -0300, Gustavo Sverzut Barbieri wrote: On Jan 25, 2008 12:40 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Fri, 25 Jan 2008 00:11:41 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Jan 24, 2008 11:42 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Jan 24, 2008 7:18 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: now i think this is a bit more generic a solution - but it adds overhead. so what about the pselect() method? anyone got input on that? Basically, pselect() is designed for exactly this situation. You block all of the signals you're going to handle during init or some other very early point, then you pass a mask of the signals you're going to unblock to pselect(). At this point, pselect() will atomically unblock the specified signals and call select() with the specified fd's, it also re-instates the original signal blocks after select() returns. Since this sequence is atomic, it prevents the race condition we currently have. Now the problem, this is a good solution on BSD and Solaris, but unfortunately Linux only fakes support for pselect() (unless this was fixed recently). On Linux pselect() is actually a wrapper exactly around the sequence sigprocmask(), select() sigprocmask(). So we still end up with a race condition between the first sigprocmask() call and the select() call. man page says: BUGS: Since version 2.1, glibc has provided an emulation of pselect() that is implemented using sigprocmask(2) and select(). This implementation remains vulnerable to the very race condition that pselect() was designed to prevent. On systems that lack pselect() reliable (and more portable) signal trapping can be achieved using the self-pipe trick (where a signal handler writes a byte to a pipe whose other end is monitored by select() in the main program.) however a bit earlier it says Linux has pselect(), and at least 2.6.23 implements it... so maybe this wrapper is just used as a fallback? that is the question - is it implemented kernel-wise widely enough to use it? or do we just stick to the old-fashioned self-pipe trick? I have not audited the Linux or GlibC code to check if that's the case (well implemented), but I truly believe that we can rely on this call for newer ( 2.6) kernels. Thanks for your comments and suggestions. I thinks I'll go with the pipe solution as I think there are too many unknowns with pselect: will it work if we build againts uclibc, newlib or klibc? or build on BSD or Solaris systems etc? Solaris was already said to work by Nathan, Linux kernel implements it, so uclibc and newlibc or klibc should support it, if not let's bug report and have it done ASAP. BSD I'm not sure, any users out there to reply about this (checking the man page should be enough)? -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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 2008-01-26 07:08:42 -0800
Build log for Enlightenment DR 0.17 on 2008-01-26 07:08:42 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: echo http://download.enlightenment.org/tests/logs/echo.log ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log edvi http://download.enlightenment.org/tests/logs/edvi.log engage http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.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: entice, esmart_rsvg, exorcist, penguin, 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, calendar, cpu, deskshow, eclair, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Jan 26, 2008 7:11 AM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : vapier Project : e17 Module : libs/ecore Dir : e17/libs/ecore/src/lib/ecore Modified Files: ecore_main.c ecore_private.h Log Message: relegate _WIN32 ifdef mess to ecore_private.h Thanks, I really love you. We could do more of this and avoid the macro-hell in some e-areas :-/ again, thanks -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Saturday 26 January 2008, Vincent Torri wrote: exactly ... where we can unify these pieces without touching common code the better. not sure if there's a core piece of e17 where we can move all of this, but if we had a few files that we could just drop into the different e libraries, that'd be a good start i think (think gnulib here). I've tried to use gnulib once, for the port of the linux functions. It's a pain to install and to use. I'll never touch that beast anymore :) it can be a beast, that's for sure. i'm not advocating the complexity there, just the idea: little chunks of .c/.h you can drop in and run with. since we seem to be on the same track now, if you want to revert the changes i made wrt windows.h/winsock2.h, feel free ... the other (non-windows) headers should stay the same of course though. -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Sat, 26 Jan 2008, Mike Frysinger wrote: I've tried to use gnulib once, for the port of the linux functions. It's a pain to install and to use. I'll never touch that beast anymore :) it can be a beast, that's for sure. i'm not advocating the complexity there, just the idea: little chunks of .c/.h you can drop in and run with. since we seem to be on the same track now, if you want to revert the changes i made wrt windows.h/winsock2.h, feel free ... the other (non-windows) headers should stay the same of course though. i'm writing an e_win32 (or efl_win32 ?) lib that ports some functions mostly fcntl, mmap, symlink, pipe and utility functions I use here and there). I'll revert the changes when I use that lib. I'm just wondering if should name the functions like the unix ones, or with an e_ prefix. If the latter, that would mean modifying the source code and do some defines for the unix calls. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore vapier
On Saturday 26 January 2008, Vincent Torri wrote: On Sat, 26 Jan 2008, Mike Frysinger wrote: I've tried to use gnulib once, for the port of the linux functions. It's a pain to install and to use. I'll never touch that beast anymore :) it can be a beast, that's for sure. i'm not advocating the complexity there, just the idea: little chunks of .c/.h you can drop in and run with. since we seem to be on the same track now, if you want to revert the changes i made wrt windows.h/winsock2.h, feel free ... the other (non-windows) headers should stay the same of course though. i'm writing an e_win32 (or efl_win32 ?) lib that ports some functions mostly fcntl, mmap, symlink, pipe and utility functions I use here and there). I'll revert the changes when I use that lib. I'm just wondering if should name the functions like the unix ones, or with an e_ prefix. If the latter, that would mean modifying the source code and do some defines for the unix calls. i guess it depends ... with mmap, the symbol doesnt exist on mingw/win32 symbols, so if you simply had a win32 implementation of mmap, i think that'd be ok. but for cases where the symbol exists but is deficient, dont really have an option with prefixing it ... -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][RFC] signal/select race problem in ecore_main
I checked the man page for Mac OS X as well. Looks like pselect() comes from FreeBSD in that case. On Jan 26, 2008 9:09 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Jan 26, 2008 6:13 AM, Lars Munch [EMAIL PROTECTED] wrote: On Fri, Jan 25, 2008 at 07:43:47AM -0300, Gustavo Sverzut Barbieri wrote: On Jan 25, 2008 12:40 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Fri, 25 Jan 2008 00:11:41 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Jan 24, 2008 11:42 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Jan 24, 2008 7:18 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: now i think this is a bit more generic a solution - but it adds overhead. so what about the pselect() method? anyone got input on that? Basically, pselect() is designed for exactly this situation. You block all of the signals you're going to handle during init or some other very early point, then you pass a mask of the signals you're going to unblock to pselect(). At this point, pselect() will atomically unblock the specified signals and call select() with the specified fd's, it also re-instates the original signal blocks after select() returns. Since this sequence is atomic, it prevents the race condition we currently have. Now the problem, this is a good solution on BSD and Solaris, but unfortunately Linux only fakes support for pselect() (unless this was fixed recently). On Linux pselect() is actually a wrapper exactly around the sequence sigprocmask(), select() sigprocmask(). So we still end up with a race condition between the first sigprocmask() call and the select() call. man page says: BUGS: Since version 2.1, glibc has provided an emulation of pselect() that is implemented using sigprocmask(2) and select(). This implementation remains vulnerable to the very race condition that pselect() was designed to prevent. On systems that lack pselect() reliable (and more portable) signal trapping can be achieved using the self-pipe trick (where a signal handler writes a byte to a pipe whose other end is monitored by select() in the main program.) however a bit earlier it says Linux has pselect(), and at least 2.6.23 implements it... so maybe this wrapper is just used as a fallback? that is the question - is it implemented kernel-wise widely enough to use it? or do we just stick to the old-fashioned self-pipe trick? I have not audited the Linux or GlibC code to check if that's the case (well implemented), but I truly believe that we can rely on this call for newer ( 2.6) kernels. Thanks for your comments and suggestions. I thinks I'll go with the pipe solution as I think there are too many unknowns with pselect: will it work if we build againts uclibc, newlib or klibc? or build on BSD or Solaris systems etc? Solaris was already said to work by Nathan, Linux kernel implements it, so uclibc and newlibc or klibc should support it, if not let's bug report and have it done ASAP. BSD I'm not sure, any users out there to reply about this (checking the man page should be enough)? -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: www dresb
Typo on frequently. On Jan 26, 2008 6:23 AM, Enlightenment CVS [EMAIL PROTECTED] wrote: +pFrecuently updated tutorials and guides for both users and developers./p - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Noob help - ETK part not working
Hi all,
Trying to get this transition to work. I want this image to change to
the other image... Im just not sure if i can do that with
etk/progress_bar... Is there a way to find out if these things are
possible? I was flicking through the source code for the progress bar
in etk and saw the part is indeed an edje_object so assumed it could
do all the regular edje stuff.
Thanks,
Toma-
-
group {
name: etk/progress_bar;
min: 120 18;
data {
item: filler_pulse_width 0.3;
}
parts {
part {
name: progress_bar;
description {
state: default 0.0;
rel1 {
relative: 0.0 0.5;
offset: 0 -9;
}
rel2 {
relative: 1.0 0.5;
offset: -1 8;
}
image {
normal: entry.png;
border: 4 4 4 4;
}
fill {
smooth: 0;
}
}
}
part {
name: clip;
type: RECT;
description {
state: default 0.0;
rel1 {
relative: 0.0 0.5;
offset: 0 -9;
}
rel2 {
relative: 1.0 0.5;
offset: -1 8;
}
}
}
part {
name: confine;
type: RECT;
description {
state: default 0.0;
visible: 0;
rel1 {
relative: 0.0 0.0;
offset: 2 0;
to: progress_bar;
}
rel2 {
relative: 1.0 1.0;
offset: -3 0;
to: progress_bar;
}
}
}
part {
name: etk.dragable.filler;
mouse_events: 0;
dragable {
confine: confine;
x: 1 1 1;
y: 0 0 0;
}
description {
state: default 0.0;
min: 0 14;
fixed: 1 1;
rel1 {
relative: 0.5 0.5;
offset: 0 0;
to: progress_bar;
}
rel2 {
relative: 0.5 0.5;
offset: 0 0;
to: progress_bar;
}
image {
normal: progress_plasma.png;
border: 5 5 5 5;
}
fill {
smooth: 1;
}
}
description {
state: active 0.0;
inherit: default 0.0;
image {
normal: progress_plasma1.png;
}
}
}
part {
name: etk.text.text;
type: TEXT;
clip_to: clip;
mouse_events: 0;
description {
state: default 0.0;
color: 255 255 255 255;
rel1 {
relative: 0.0 0.0;
offset: 4 3;
to: progress_bar;
}
rel2 {
relative: 1.0 1.0;
offset: -5 -3;
to: progress_bar;
}
text {
text: Text;
font: Vera;
size: 10;
align: 0.5 0.5;
}
}
}
GLINT_PART(etk.dragable.filler)
}
programs {
program {
name: glowon;
source: e.dragable.slider;
action: STATE_SET active 0.0;
transition: SINUSOIDAL 1.0;
target: etk.dragable.filler;
after: glowoff;
}
program {
name: glowoff;
action: STATE_SET default 0.0;
transition: SINUSOIDAL 1.0;
target: etk.dragable.filler;
after: glowon;
}
program {
name: progress_bar_init;
signal: load;
after: progress_bar_glint;
}
program {
name: progress_bar_glint;
signal: mouse,in;
source: etk.dragable.filler;
in: 4.0 2.0;
GLINT_ACTION
after: progress_bar_glint;
}
GLINT_PROGRAM
}
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
