Re: [E-devel] EFL Portability (need BSD, Solaris and Windows input!)
On Thu, Jan 03, 2013 at 04:40:02PM -0200, Lucas De Marchi wrote: > or you use "#include_next " inside Escape's libgen.h > and don't bother with never ever creating Escape.h > > http://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html > > > Not sure if other compilers support this, though It's not that portable. There is a strong overlap with platforms that have issues with standard headers and those that don't support #include_next. It shouldn't also really be needed. You can provide a subdirectory in the build tree with files containing only include guards for missing system headers and one "catch all" Evil.h that defines prototypes that might be missing on the system. That's essentially the idea of how NetBSD adjusts tools used in the bootstrap phase when cross-compiling from Linux/Solaris/... Joerg -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e] OpenBSD & shm_open()
On Tue, Dec 18, 2012 at 09:24:46AM +0900, Carsten Haitzler wrote: > a file on disk is specified to survive reboots.. UNLESS it is specifically in > part of the fs that is discarded on reboot. vast difference between them. Well, most systems clean up /tmp on boot, so they discard the content as well. > the shm_open impl on linux does ensure reboots == doesn't survive. That's not true. The shm_open implementation on Linux just ensures that it is using /dev/shm if available (or whatever they moved it to nowadays). It is up to the distribution to mount a tmpfs to that. Syncing to disk is often a *good* thing as it tends to significantly reduce the memory pressure *and* tends to provide more efficient reload behavior than swap. So yes, shm_open is pretty lame. Joerg -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e] OpenBSD & shm_open()
On Mon, Dec 17, 2012 at 07:57:36PM -0200, Gustavo Sverzut Barbieri wrote: > On Mon, Dec 17, 2012 at 7:43 PM, Joerg Sonnenberger > wrote: > > > On Mon, Dec 17, 2012 at 07:10:01PM -0200, Gustavo Sverzut Barbieri wrote: > > > Jokes aside, we appreciate to have E to run well on that, but it > > > cannot block development because features that is in the standard for > > > 12 years without being implemented. > > > > First of all, shm_open is an optional part of POSIX. One of the reasons > > for reluctantly implementing it is that it is extremely lame. The way > > Linux implements it provides ~0 advantage of just using open() with a > > file in /tmp. > > > > Not in our point of view. Anyway, you're free to add an eina wrapper that > does use a file in /tmp for BSD. We're not just doing that for Linux as > there is better way of doing it (that at guarantees it's never going to > disk). But it doesn't even guarantee that. It can still be swapped out for example. Joerg -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e] OpenBSD & shm_open()
On Mon, Dec 17, 2012 at 07:10:01PM -0200, Gustavo Sverzut Barbieri wrote: > Jokes aside, we appreciate to have E to run well on that, but it > cannot block development because features that is in the standard for > 12 years without being implemented. First of all, shm_open is an optional part of POSIX. One of the reasons for reluctantly implementing it is that it is extremely lame. The way Linux implements it provides ~0 advantage of just using open() with a file in /tmp. Joerg -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: etrunko trunk/efl
On Thu, Dec 06, 2012 at 11:02:26AM -0200, Gustavo Sverzut Barbieri wrote: > I disagree here, given that we never use the first operand as ! in any > of our checks, just yes/no, there is no harm. The benefit is reducing > the number of calls to test binary and also the resulting code size as > it's smaller. For any sane implement of sh, test is builtin. So at most it avoids a bunch of forks. Side note, the "x$foo" usage *is* obsolete and only for certain brain dead versions that have more issues already *cough* Solaris /bin/sh *cough*. Joerg -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] std=c99 for ecore_con dns.c got missing
On Thu, Dec 06, 2012 at 12:57:39PM +0100, Vincent Torri wrote: > so it's a problem with clang. Fix your CC, then Clang defaults to C99, so this should only happen if it was explicitly instructed otherwise... Joerg -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: englebass IN trunk/ecore/src/lib: ecore ecore_con ecore_config ecore_evas ecore_fb ecore_file ecore_imf ecore_ipc ecore_wayland ecore_win32 ecore_wince ecore_x/xcb ecore_x/xlib
On Fri, Nov 23, 2012 at 09:37:55PM +0100, Vincent Torri wrote: > please revert. All that stuff is not correct, as I said in one of the ticket > > see my previous mail. Also, ecore_getopt.c **already** have alloca > support... Please review the patches instead of appplying them blindly More importantly, please don't duplicate this across a hundred files. Joerg -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] mac os x
On Wed, Nov 14, 2012 at 03:25:35PM +0900, Carsten Haitzler wrote: > On Tue, 13 Nov 2012 21:43:45 -0800 Dave Ray said: > > wtf? somehting ADDED underscores in front of the symbols.. that is so wrong... > the src as it reads in svn atm anyway doent have these and i dont see how a > macro could do this as it'd need to replace each whole token not just _e and > _E... something odd with the compiler/linker here. Some platforms automatically prefix all external systems with _. a.out did this on UNIX, but ELF no longer does. Not sure about OSX. That said, you might be running into the default flat namespace on OSX, which is more strict than ELF. Joerg -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas sse3 SIGILL
On Wed, Nov 07, 2012 at 01:58:56PM -0200, Paulo Alcantara wrote: > 2) Since CPUID instruction was available on older x86 CPUS (like 486 > as demarchi just said), should we still keep NOT using CPUID at all ? This is not really true. CPUID was introduced with the Intel Pentium, but some later generations of i486 got it as well. Testing for the presence of CPUID is easy using the flags. Joerg -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e] Patch
On Thu, Oct 25, 2012 at 07:32:19PM +0200, rustyBSD wrote: > III. There is a problem with _e_fm_op_random_char(). > When wewant to randomize a string we do srand(time()) > foreachcharacter, so if the file is small enough > to be deleted inless than a second, it's not randomized. > And even if it's bigger, it's not goodly randomized.Sorry. Is that function really only called once? Otherwise the srand should really only happen on the first call. Joerg -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: caro trunk/e/src/bin
On Thu, Sep 27, 2012 at 07:10:29PM +0900, Carsten Haitzler wrote: > here's the question... this is pretty lame security-wise. shouldn't we be > military/cia/nsa spec and overwrite it at least 7 times? :) oh and this will > probably/possible get screwed by logging fs's or flash media that may shuffle > the blocks around on write :) ie it wont help. It's generally lame. Overwriting once with 0s is enough for pretty much any basic recovery attempt. Anything involving direct physical scans of the disk is *much* harder (if possible at all) to defend against. Joerg -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/embryo/src/bin
On Fri, Sep 07, 2012 at 11:49:18PM +0900, Carsten Haitzler wrote: > On Fri, 7 Sep 2012 11:45:35 -0300 Gustavo Sverzut Barbieri > said: > > > On Friday, September 7, 2012, Enlightenment SVN wrote: > > > > > Log: > > > vincent - try this on windows. > > > > > > If this fixes his problems, we may have a bug on windows code that > > GENERATES the string/array. The characters are stores in integers, yes, but > > for strings they should be in 0-255 > > i'm hunting it. this is an attempt to narrow down what exactly is causing it. > as such the array contains exactly the same bytes as in linux. now i'm > wondering by sign-extending the SIGNED char to an int, this causes the windows > is*() funcs to be different to linux. thus my little thing to avoid sign > extending. :) Calling is*() with char is wrong, if the char can be outside 0..127. Some systems provide versions that warn about the misuse (e.g. NetBSD), some magically "fix" it (e.g. Linux). Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Add Null Chekcing Routine in eet_lib
On Wed, Sep 05, 2012 at 04:39:23PM +0300, Tom Hacohen wrote: > On 05/09/12 16:26, Daniel Willmann wrote: > > Hi, > > > > On 09/05/2012 02:12 PM, Tom Hacohen wrote: > >> free, strlen and strcpy are just a few of the many examples that don't > >> accept NULL. Having sanity checks everywhere is not "safer", it just > > > > I agree with most things you said, just one note from the free() man > > page: "Otherwise, or if free(ptr) has already been called before, > > undefined behavior occurs. If ptr is NULL, no operation is performed." > > > > Yes, gnu libc implements it that way because of bullet #3 I mentioned > before, but it's not the same with old gnu libc implementations or with > other libc implementations. I think the standard (at least c89) has > undefined behaviour regarding NULL, but about that I'm not 100% sure. free(NULL) has been well defined since ANSI C89 at least. Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/terminology/src/bin
On Mon, Aug 06, 2012 at 09:51:04PM +0900, Carsten Haitzler wrote: > why MUST an option with a single - have a single char following? what rulebook > states this? it's an arbitrary distinction that is very gnu-ish, but it is not > a rule. who declares the law of what a long option is or is not when history > and our current ecosystem of apps disagrees? It's the getopt behavior, which should be assumed to be the default option handling mechanism unless there is a (bad) historic reason for not using that. getopt predates even GNU :) In fact, I'd say GNU is one of the earlier heavier abuser in this way. test and find are the exceptions in traditional UNIX userland... Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas]: Use of loop instead of memcpy
On Mon, Jul 30, 2012 at 07:11:48PM +0900, Carsten Haitzler wrote: > On Mon, 30 Jul 2012 02:38:18 -0400 (EDT) david.obo...@aliceadsl.fr said: > > > Hi, > > > > I wonder why the evas_blit_main.c, the copy is made by a loop instead of a > > memcpy. This is a problem with an architecture or with performance? > > at least in the past i have measured it as faster than memcpy. and the mmx/sse > ones even faster. :) maybe glibc has stopped being... so... crappy these days > :) The bigger question is whether GCC stopped inlining memcpy in ways optimised for i386... Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: glima trunk/elementary/src/lib
On Tue, May 29, 2012 at 02:07:24PM +0900, Daniel Juyung Seo wrote: > but it breaks applications when they use -Werror option. You can use -Wno-deprecated to selectively disable the warning or -Wno-error=deprecated to keep the warning, but don't assert on it. Make sure to put that after -Werror though. Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: hyoyoung trunk/elementary/src/lib
On Wed, May 23, 2012 at 05:56:10PM +0900, Bluezery wrote: > 2012/5/23 Hyoyoung Chang : > > Maybe it's best time to talk about sizeof(char) > > > > Do we need to sizeof(char)? I just that is problem of coding convention. > > such as (a == 0) and (!a). > > Is there any predefined convention about this case? > > sizeof(char) may be larger (in the future if we use unicode :p) than > 1. but I haven't seen yet. :) The C standard explicitly defines it as one. Are you thinking about wchar_t? Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH v2] Only unlink the temporary file created in evas_object_image_memfile_set on cleanup
On Mon, May 21, 2012 at 12:15:10AM -0300, Raphael Kubo da Costa wrote: > After talking about the previous version of the patch with raster on > IRC, I'm sending a more conservative version that does not change the > Linux behavior -- /dev/shm is expected to work on Linux, and the > non-Linux case works at the expense of leaving some files in /tmp if a > crash occurs before _cleanup_tmpf() is called. Can you not hard-code /tmp, but try to honor TMPDIR? Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/e/src/bin
On Sat, May 05, 2012 at 01:18:48PM +1000, David Seikel wrote: > Just ignoring the failed allocation and trying to use a NULL pointer > will likely crash you anyway, but that's just being lazy. Failing > gracefully is generally better than failing disgracefully. Part of the problem here is that it might *not* crash depending on the code path and arguments. E.g. if you allocate a large buffer and the first thing you do with the buffer is writing to an attacker controlled offset, it can be turned into an arbitary code exploit by making the buffer size large enough that the offset effectively becomes a pointer itself. Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/e/src/bin
On Fri, May 04, 2012 at 10:17:29AM +0900, Cedric BAIL wrote: > On Thu, May 3, 2012 at 8:57 PM, Vincent Torri wrote: > > is it normal that no check is done when calloc is called ? > > It's a good question. In E17, there isn't much handling of this > situation. I am wrong in assuming that on all unix supported by E17, > when it start returning NULL, it would be way to late ? > > Should we handle it ? You should check for it and fail deterministically at least. Doing something like fprintf(stderr, "oops\n"), exit(1); is perfectly valid. When malloc and friends fail depends somewhat on the setup. Memory overcommit makes the returned error unreliable in the sense that you can later get killed by OOM. Using resource limits (ulimit -d / -v etc) can result in malloc errors much earlier, but whether you can do something sane from that depends on the circumstances. E.g. if the user wants to open an image and you can't allocate a buffer, it makes sense to report an error for that as the image and therefore the buffer can be huge. Joerg -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Mon, Apr 23, 2012 at 03:05:09PM +0200, thomasg wrote: > XZs liblzma is LGPLv2.1 though. No, only the fallback support for limited platforms using gnulib is. The rest is PD. Joerg -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Thu, Mar 08, 2012 at 12:51:19AM +0900, Carsten Haitzler wrote: > On Wed, 7 Mar 2012 12:37:42 -0300 Gustavo Sverzut Barbieri > said: > > > On Wed, Mar 7, 2012 at 6:05 AM, Enlightenment SVN > > wrote: > > > Log: > > > to be paranoid - ensure umask for mkstemp allows no other uids oir > > > grps access. > > > > Ugh, isn't there any other way to do this? What you did break if > > people are using other threads to open files, and if they fork() they > > will inherit these values! TOO BAD :-( > > 1. umask is reset back immediately after creation so fork (unless its FROM > another thread which is incredibly odd) wont be a problem > 2. its changed for a very short period so yes - it could affect other threads > creating files too but its a very small condition, but yes - its possible > 3. no mk*temp libc funcs let u set mode so this is the only way other than > creating our own tmpfile name allocator. > > NOT doing this makes for a security hole. i'd rather this very "rare/odd" bug > than the security hole until someone spends the time to make a custom tmpfile > creator. mkstemp is supposed to create the file with 0600 permission, so is that really necessary? Joerg -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fixes for latest eina and eet
On Tue, Feb 21, 2012 at 11:33:51AM +0100, Vincent Torri wrote: > On Tue, Feb 21, 2012 at 9:50 AM, Joerg Sonnenberger > wrote: > > On Tue, Feb 21, 2012 at 07:23:36AM +0100, Vincent Torri wrote: > >> On Tue, Feb 21, 2012 at 1:18 AM, Joerg Sonnenberger > >> wrote: > >> > On Tue, Feb 21, 2012 at 12:10:47AM +0100, Vincent Torri wrote: > >> >> On Mon, Feb 20, 2012 at 11:38 PM, Joerg Sonnenberger > >> >> wrote: > >> >> > On Mon, Feb 20, 2012 at 11:28:28PM +0100, Lionel Orry wrote: > >> >> >> - eina: the __gnu_printf__ format attribute is only valid since GCC > >> >> >> 4.4. However, we can find __printf__ format before. I'm not sure they > >> >> >> are equivalent though, so any hints on the fix appreciated... (tested > >> >> >> with GCC 4.3.4) > >> >> > > >> >> > They are supposedly equivalent on Linux and HURD. They are not > >> >> > equivalent on other systems and arguably using any glibc extensions in > >> >> > EFL is a bug. > >> >> > >> >> Why is it a problem ? As it's tested in a GNUC environment, explain me > >> >> why it will fail, and on which system. > >> > > >> > Because other systems don't implement the glibc extensions for printf? > >> > >> that's a gcc problem. But you didn't list the systems for which > >> gnu_printf is not implemented, and for which the compilation *will > >> fail* > > > > You misunderstand. The problem is not that gnu_printf is not recognized > > by GCC, but that the underlaying printf implementation may not support > > the GNU extensions. So it is pretty pointless to mark eina_log_print as > > supporting the GNU extensions, if that it isn't true about printf. The > > most trivial example of a GNU extension for printf from memory is %m. > > ok. I had that problem for the Windows port. So I added in it a 'gnu' > version of printf, that is provided by the MinGW team (no licence > problem, it's PD). Windows is a bit special as Microsoft doesn't believe in C99 support. There are generally no excuses for using the GNU extensions for printf -- they are pretty much completely pointless. Joerg -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fixes for latest eina and eet
On Tue, Feb 21, 2012 at 07:23:36AM +0100, Vincent Torri wrote: > On Tue, Feb 21, 2012 at 1:18 AM, Joerg Sonnenberger > wrote: > > On Tue, Feb 21, 2012 at 12:10:47AM +0100, Vincent Torri wrote: > >> On Mon, Feb 20, 2012 at 11:38 PM, Joerg Sonnenberger > >> wrote: > >> > On Mon, Feb 20, 2012 at 11:28:28PM +0100, Lionel Orry wrote: > >> >> - eina: the __gnu_printf__ format attribute is only valid since GCC > >> >> 4.4. However, we can find __printf__ format before. I'm not sure they > >> >> are equivalent though, so any hints on the fix appreciated... (tested > >> >> with GCC 4.3.4) > >> > > >> > They are supposedly equivalent on Linux and HURD. They are not > >> > equivalent on other systems and arguably using any glibc extensions in > >> > EFL is a bug. > >> > >> Why is it a problem ? As it's tested in a GNUC environment, explain me > >> why it will fail, and on which system. > > > > Because other systems don't implement the glibc extensions for printf? > > that's a gcc problem. But you didn't list the systems for which > gnu_printf is not implemented, and for which the compilation *will > fail* You misunderstand. The problem is not that gnu_printf is not recognized by GCC, but that the underlaying printf implementation may not support the GNU extensions. So it is pretty pointless to mark eina_log_print as supporting the GNU extensions, if that it isn't true about printf. The most trivial example of a GNU extension for printf from memory is %m. Joerg -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fixes for latest eina and eet
On Tue, Feb 21, 2012 at 12:10:47AM +0100, Vincent Torri wrote: > On Mon, Feb 20, 2012 at 11:38 PM, Joerg Sonnenberger > wrote: > > On Mon, Feb 20, 2012 at 11:28:28PM +0100, Lionel Orry wrote: > >> - eina: the __gnu_printf__ format attribute is only valid since GCC > >> 4.4. However, we can find __printf__ format before. I'm not sure they > >> are equivalent though, so any hints on the fix appreciated... (tested > >> with GCC 4.3.4) > > > > They are supposedly equivalent on Linux and HURD. They are not > > equivalent on other systems and arguably using any glibc extensions in > > EFL is a bug. > > Why is it a problem ? As it's tested in a GNUC environment, explain me > why it will fail, and on which system. Because other systems don't implement the glibc extensions for printf? Joerg -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fixes for latest eina and eet
On Mon, Feb 20, 2012 at 11:28:28PM +0100, Lionel Orry wrote: > - eina: the __gnu_printf__ format attribute is only valid since GCC > 4.4. However, we can find __printf__ format before. I'm not sure they > are equivalent though, so any hints on the fix appreciated... (tested > with GCC 4.3.4) They are supposedly equivalent on Linux and HURD. They are not equivalent on other systems and arguably using any glibc extensions in EFL is a bug. Joerg -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Dec 07, 2011 at 02:29:17AM -0500, Christopher Michael wrote: > On 12/06/11 20:10, Enlightenment SVN wrote: > > Log: > > NO! you break api. you made my e sit here with a segv in a getenv. > >because now many libraries and api's don't have prototyopes for > >malloc/calloc and much more and this goes horribly wrong especially on > >64bit! the eina headers have provided these includes historically and > >removing them is a BREAK in api. apps that used to compile and run > >just fine now don't. it's unacceptable to break api. > > > >i'm stuck here in unity for crying out loud! this deservves a big FAT > >REVERT for that! :-P > > > AHMEN !!! To force ANYONE into Unity, is just extra pain that "we" > should not have to go through. Raster, I am with you on this one > regardless of the reason. To force something to use Unity is pain > enough...the fact that EFL in general would break this much is not > acceptible...period. Seriously, if you don't stop compilation on missing prototypes, you are doing something wrong. I do not consider this to be an API breakage. Headers should include just what they need -- e.g. if they directly use a type or macro. Joerg -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New EFL release cycle 1.1/1.5 BETA
On Sat, Dec 03, 2011 at 08:08:26AM +0900, Carsten Haitzler wrote: > On Fri, 2 Dec 2011 15:16:37 +0100 Joerg Sonnenberger > said: > > > On Fri, Dec 02, 2011 at 08:40:26AM +1000, David Seikel wrote: > > > On Thu, 1 Dec 2011 23:26:25 +0100 Joerg Sonnenberger > > > wrote: > > > > > > > On Mon, Nov 28, 2011 at 09:54:18PM +0900, Carsten Haitzler wrote: > > > > > http://download.enlightenment.org/releases/edje-1.1.0-beta.tar.gz > > > > > http://download.enlightenment.org/releases/edje-1.1.0-beta.tar.bz2 > > > > > > > > Default is installing the examples. This introduces a dependency on > > > > $(SRCDIR)/Vera.ttf, which is missing. > > > > > > Both of those have been fixed already. Default is no longer to install > > > the examples, and Vera.ttf should make it into the next tarball. > > > > Default seems to be to install the examples and in fact, the option to > > disable the installation seems to be broken in the release tarball... > > no - i removed the option. it's always installed now. You forgot half of it in configure.ac... Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc
On Fri, Dec 02, 2011 at 07:33:15PM -0200, Iván Briano (Sachiel) wrote: > 2011/12/2 Joerg Sonnenberger : > > On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote: > >> so why not just do a & 0xff instead of casting ? > > > > The cast is IMO cleaner in the intentions. It also has the theoretical > > advantage of working independent of CHAR_BIT==8. > > > > We are not reading from a file so there' won't really be an EOF, but I insist > on it. How does isspace() recognize EOF when you are casting to unsigned char? > Even if we don't need it now, it makes the whole deal smell to a nasty > hack covering > from some obscure bug. And if there's no bug, then what are fixing here? The input is a character stream. If you are storing EOF inside char *, you have already done something wrong. That's why e.g. fgetc() returns an int, so that you can distinguish them. The problem here is that (char)-128 is sign extended to (int)-128, which is quite different from (int)(unsigned char)-128, which is 0x80. A perfectly valid implementation of the ctype.h "functions" is #define isspace(x) (typetable[(x) + 1] & TYPE_SPACE) Without the cast, this can access memory before the start of the table. Some systems apply work arounds to let broken code pass. On Linux, it duplicates the upper half of the table below and uses 128 as offset. This doesn't penalize correct code, but implies incorrect results for 8bit clean locales. On OpenBSD, it internally compares to EOF (aka -1) and returns 0 explicitly. Same problem with the additional cost of a compare on platforms without unsigned char by default. What it all boils down to is that certain parts of the C standard libraries are interacting badly with platforms where char is signed. That's not something that can fixed easily. On the positive side, a macro definition like the above ensures that many compilers will warn about the incorrect instances. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc
On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote: > so why not just do a & 0xff instead of casting ? The cast is IMO cleaner in the intentions. It also has the theoretical advantage of working independent of CHAR_BIT==8. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor IN trunk/ecore/src/lib: ecore ecore_file
On Fri, Dec 02, 2011 at 08:05:43PM +0100, Sebastian Dransfeld wrote: > On 12/02/2011 04:33 AM, Enlightenment SVN wrote: > > Log: > > more trivial fixes from Joerg Sonnenberger > > This must be rubbish. isspace() takes int as argument, not unsigned char You are wrong. Please read the mail on the list. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New EFL release cycle 1.1/1.5 BETA
On Fri, Dec 02, 2011 at 08:40:26AM +1000, David Seikel wrote: > On Thu, 1 Dec 2011 23:26:25 +0100 Joerg Sonnenberger > wrote: > > > On Mon, Nov 28, 2011 at 09:54:18PM +0900, Carsten Haitzler wrote: > > > http://download.enlightenment.org/releases/edje-1.1.0-beta.tar.gz > > > http://download.enlightenment.org/releases/edje-1.1.0-beta.tar.bz2 > > > > Default is installing the examples. This introduces a dependency on > > $(SRCDIR)/Vera.ttf, which is missing. > > Both of those have been fixed already. Default is no longer to install > the examples, and Vera.ttf should make it into the next tarball. Default seems to be to install the examples and in fact, the option to disable the installation seems to be broken in the release tarball... Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc
On Fri, Dec 02, 2011 at 09:51:12PM +0900, Carsten Haitzler wrote: > > > 2. all the chasting and changing to unsigned char for passing into isspace > > > () - isspace() actually takes an int, not unsigned char, so this just > > > doesn't make sense. :( (well it does according to the manual page i have) > > > > Please read the manual again. ctype.h stuff takes an integer argument, > > but the value must be -1..255 (for 8bit char and EOF==-1). It is > > undefined behavior to pass anything else. Especially in programs using > > no such mention in the manual page at all. no limits on range. since an > integer > is the possible input, then it must handle all int values sensibly in some way > as the docs don't mention any limitations. :) > > > setlocale(), the result for 0xff as input byte can make a real > > difference for platforms with signed char. > > can you point me to these docs, as the manual page i have in front of me for > linux disagrees :) http://pubs.opengroup.org/onlinepubs/9699919799/functions/isspace.html Note the last paragraph in DESCRIPTION. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc
On Fri, Dec 02, 2011 at 03:37:30PM +0900, Carsten Haitzler wrote: > On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger > said: > > this is really late... and a lot of these patches i find questionable. i'll > question here (things not questioned seem ok): > > 1. __SUNPRO_C instead of __sun <- explain why you dont just ADD an extra || > defined(__SUNPRO_C) and why the check for __sun should be removed? I think you are reading the diff wrong. It replaces __SUNPRO_C (the compiler specific macro) with __sun (the platform specific macro). I don't mind using it as additional case though. > 2. all the chasting and changing to unsigned char for passing into isspace() - > isspace() actually takes an int, not unsigned char, so this just doesn't make > sense. :( (well it does according to the manual page i have) Please read the manual again. ctype.h stuff takes an integer argument, but the value must be -1..255 (for 8bit char and EOF==-1). It is undefined behavior to pass anything else. Especially in programs using setlocale(), the result for 0xff as input byte can make a real difference for platforms with signed char. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina 1.1.0beta patches for/from pkgsrc
On Fri, Dec 02, 2011 at 04:00:46PM +0900, Carsten Haitzler wrote: > On Thu, 1 Dec 2011 17:41:17 +0100 Joerg Sonnenberger > said: > > > Hi all, > > sorry for not finding the time for doing this earlier. Attached is a > > patch that sorts out a number of smaller issues with eina on NetBSD and > > Solaris. Some are noise, some are real bugs. This brings it down to one > > compiler warning for iconv, which is expected (and messy). > > ooh. and the dirfd check... looks just like something that would crash! so > that's actually not a valid check at all... well if it is run after compiling > to check feature existence :) It's not run. It's just supposed to compile and link correctly. Using a global variable just prevents surprising optimisations by the compiler. The problem is that the existing check using AC_CHECK_FUNCS won't work, if dirfd is just available as a macro. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fix for pulseaudio in e17 on !Linux
On Thu, Dec 01, 2011 at 10:29:12PM -0500, Michael Blumenkrantz wrote: > looks reasonable, but this doesn't exist in pulseaudio's code. is it patched > during build on bsd? The part in iochannel.c is conditionalized on HAVE_CREDS in pulseaudio. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New EFL release cycle 1.1/1.5 BETA
On Mon, Nov 28, 2011 at 09:54:18PM +0900, Carsten Haitzler wrote:
> http://download.enlightenment.org/releases/ecore-1.1.0-beta.tar.gz
> http://download.enlightenment.org/releases/ecore-1.1.0-beta.tar.bz2
First patch comments out a bunch of seemingly unused static functions.
Second and third patch fix the usage of ctype.h.
Joerg
--- src/lib/ecore_con/ecore_con_ssl.c.orig 2011-11-18 04:54:52.0 +
+++ src/lib/ecore_con/ecore_con_ssl.c
@@ -1678,11 +1678,13 @@ _ecore_con_ssl_server_prepare_none(Ecore
return ECORE_CON_SSL_ERROR_NONE;
}
+#if 0
static Ecore_Con_Ssl_Error
_ecore_con_ssl_server_upgrade_none(Ecore_Con_Server *svr __UNUSED__)
{
return ECORE_CON_SSL_ERROR_NOT_SUPPORTED;
}
+#endif
static Ecore_Con_Ssl_Error
_ecore_con_ssl_server_init_none(Ecore_Con_Server *svr __UNUSED__)
@@ -1740,11 +1742,13 @@ _ecore_con_ssl_server_write_none(Ecore_C
return -1;
}
+#if 0
static Ecore_Con_Ssl_Error
_ecore_con_ssl_client_upgrade_none(Ecore_Con_Client *cl __UNUSED__)
{
return ECORE_CON_SSL_ERROR_NOT_SUPPORTED;
}
+#endif
static Ecore_Con_Ssl_Error
_ecore_con_ssl_client_init_none(Ecore_Con_Client *cl __UNUSED__)
--- src/lib/ecore/ecore_getopt.c.orig 2011-12-01 19:26:56.0 +
+++ src/lib/ecore/ecore_getopt.c
@@ -130,7 +130,7 @@ _ecore_getopt_help_line(FILE *fp,
todo = len;
for (i = 0; i < todo; i++)
-if (isspace(text[i]))
+if (isspace((unsigned char)text[i]))
{
space = text + i;
break;
--- src/lib/ecore_file/ecore_file.c.orig 2011-12-01 19:23:31.0 +
+++ src/lib/ecore_file/ecore_file.c
@@ -859,7 +859,7 @@ ecore_file_app_exe_get(const char *app)
p = (char *)app;
restart:
- while ((*p) && (isspace(*p))) p++;
+ while ((*p) && (isspace((unsigned char)*p))) p++;
exe1 = p;
while (*p)
{
@@ -879,7 +879,7 @@ restart:
in_quot_sing = 1;
else if (*p == '\"')
in_quot_dbl = 1;
- if ((isspace(*p)) && (!((p > app) && (p[-1] != '\\'
+ if ((isspace((unsigned char)*p)) && ((p <= app) || (p[-1] == '\\')))
break;
}
p++;
@@ -974,7 +974,7 @@ restart:
in_quot_sing = 1;
else if (*p == '\"')
in_quot_dbl = 1;
- else if (isspace(*p))
+ else if (isspace((unsigned char)*p))
{
if (restart)
goto restart;
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fix for pulseaudio in e17 on !Linux
Self-explaining.
--- src/modules/mixer/pa.c.orig 2011-12-02 00:47:27.0 +
+++ src/modules/mixer/pa.c
@@ -350,7 +350,9 @@ con(Pulse *conn, int type __UNUSED__, Ec
INF("connected to %s", ecore_con_server_name_get(ev->server));
conn->fd = dup(ecore_con_server_fd_get(ev->server));
+#ifdef SO_PASSCRED
setsockopt(conn->fd, SOL_SOCKET, SO_PASSCRED, &on, sizeof(on));
+#endif
setsockopt(conn->fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
fcntl(conn->fd, F_SETFL, O_NONBLOCK | FD_CLOEXEC);
conn->fdh = ecore_main_fd_handler_add(conn->fd, ECORE_FD_WRITE,
(Ecore_Fd_Cb)fdh_func, conn, NULL, NULL);
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New EFL release cycle 1.1/1.5 BETA
On Mon, Nov 28, 2011 at 09:54:18PM +0900, Carsten Haitzler wrote: > http://download.enlightenment.org/releases/edje-1.1.0-beta.tar.gz > http://download.enlightenment.org/releases/edje-1.1.0-beta.tar.bz2 Default is installing the examples. This introduces a dependency on $(SRCDIR)/Vera.ttf, which is missing. Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New EFL release cycle 1.1/1.5 BETA
On Mon, Nov 28, 2011 at 09:54:18PM +0900, Carsten Haitzler wrote: > http://download.enlightenment.org/releases/eet-1.5.0-beta.tar.gz > http://download.enlightenment.org/releases/eet-1.5.0-beta.tar.bz2 Copyright question for this. Unlike eet 1.2, this now installs a bunch of example files by default. They don't include any license though. Can they be adjusted to either put them explicitly into PD or reference the normal license (inlined or as reference to the distributed COPYING). Joerg -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] eina 1.1.0beta patches for/from pkgsrc
Hi all,
sorry for not finding the time for doing this earlier. Attached is a
patch that sorts out a number of smaller issues with eina on NetBSD and
Solaris. Some are noise, some are real bugs. This brings it down to one
compiler warning for iconv, which is expected (and messy).
Joerg
Use the SunPro handling for Solaris, independent of the compiler used.
--- src/lib/eina_cpu.c.orig 2011-04-05 08:41:54.0 +
+++ src/lib/eina_cpu.c
@@ -24,7 +24,7 @@
# ifdef _WIN32
# define WIN32_LEAN_AND_MEAN
# include
-# elif defined (__SUNPRO_C) || defined(__GNU__)
+# elif defined (__sun) || defined(__GNU__)
# include
# elif defined (__FreeBSD__) || defined (__OpenBSD__) || \
defined (__NetBSD__) || defined (__DragonFly__) || defined (__MacOSX__) || \
@@ -140,7 +140,7 @@ EAPI int eina_cpu_count(void)
GetSystemInfo(&sysinfo);
return sysinfo.dwNumberOfProcessors;
-# elif defined (__SUNPRO_C) || defined(__GNU__)
+# elif defined (__sun) || defined(__GNU__)
/*
* _SC_NPROCESSORS_ONLN: number of processors that are online, that
is available when sysconf is called. The number
dirfd(3) is a macro at least on NetBSD.
--- configure.ac.orig 2011-11-26 11:33:53.0 +
+++ configure.ac
@@ -469,7 +469,25 @@ EFL_LINKER_FLAG([-fno-strict-aliasing])
### Checks for library functions
AC_ISC_POSIX
AC_FUNC_ALLOCA
-AC_CHECK_FUNCS([strlcpy dirfd openat fstatat fpathconf execvp])
+AC_CHECK_FUNCS([strlcpy openat fstatat fpathconf execvp])
+
+AC_MSG_CHECKING([dirfd])
+AC_LINK_IFELSE([
+
+#include
+
+DIR *dirp;
+
+int
+main(void)
+{
+ return dirfd(dirp);
+}
+], [ AC_MSG_RESULT([yes])
+ AC_DEFINE([HAVE_DIRFD], 1, [ Define to 1 if you have the `dirfd' function
or macro. ])
+ ],
+ [ AC_MSG_RESULT([no])]
+)
# dlopen and dladdr
dlopen_libs=""
Avoid warnings for casts between integer and pointer on LP64.
Using uintptr_t would be better, but requires more work for Windows.
--- src/lib/eina_magic.c.orig 2011-06-22 16:11:17.0 +
+++ src/lib/eina_magic.c
@@ -79,7 +79,7 @@ _eina_magic_strings_sort_cmp(const void
static int
_eina_magic_strings_find_cmp(const void *p1, const void *p2)
{
- Eina_Magic a = (Eina_Magic)p1;
+ Eina_Magic a = (Eina_Magic)(size_t)p1;
const Eina_Magic_String *b = p2;
return a - b->magic;
}
@@ -206,7 +206,7 @@ eina_magic_string_get(Eina_Magic magic)
_eina_magic_strings_dirty = 0;
}
- ems = bsearch((void *)magic, _eina_magic_strings,
+ ems = bsearch((void *)(size_t)magic, _eina_magic_strings,
_eina_magic_strings_count, sizeof(Eina_Magic_String),
_eina_magic_strings_find_cmp);
if (ems)
Fix ctype API usage.
--- src/lib/eina_simple_xml_parser.c.orig 2011-11-09 07:12:35.0 +
+++ src/lib/eina_simple_xml_parser.c
@@ -121,7 +121,7 @@ static inline const char *
_eina_simple_xml_whitespace_find(const char *itr, const char *itr_end)
{
for (; itr < itr_end; itr++)
- if (isspace(*itr)) break;
+ if (isspace((unsigned char)*itr)) break;
return itr;
}
@@ -129,7 +129,7 @@ static inline const char *
_eina_simple_xml_whitespace_skip(const char *itr, const char *itr_end)
{
for (; itr < itr_end; itr++)
- if (!isspace(*itr)) break;
+ if (!isspace((unsigned char)*itr)) break;
return itr;
}
@@ -137,7 +137,7 @@ static inline const char *
_eina_simple_xml_whitespace_unskip(const char *itr, const char *itr_start)
{
for (itr--; itr > itr_start; itr--)
- if (!isspace(*itr)) break;
+ if (!isspace((unsigned char)*itr)) break;
return itr + 1;
}
@@ -309,7 +309,7 @@ eina_simple_xml_parse(const char *buf, u
(!memcmp(itr + 2, "DOCTYPE",
sizeof("DOCTYPE") - 1)) &&
((itr[2 + sizeof("DOCTYPE") - 1] == '>') ||
-(isspace(itr[2 + sizeof("DOCTYPE") - 1]
+(isspace((unsigned char)itr[2 + sizeof("DOCTYPE") - 1]
{
type = EINA_SIMPLE_XML_DOCTYPE;
toff = sizeof("!DOCTYPE") - 1;
@@ -455,7 +455,7 @@ eina_simple_xml_tag_attributes_find(cons
for (; itr < itr_end; itr++)
{
-if (!isspace(*itr))
+if (!isspace((unsigned char)*itr))
{
/* user skip tagname and already gave it the attributes */
if (*itr == '=')
@@ -492,7 +492,7 @@ eina_simple_xml_attributes_parse(const c
key = p;
for (key_end = key; key_end < itr_end; key_end++)
- if ((*key_end == '=') || (isspace(*key_end))) break;
+ if ((*key_end == '=') || (isspace((unsigned char)*key_end))) break;
if (key_end == itr_end) return EINA_FALSE;
if (key_end == key) continue;
@@ -504,7 +504,7 @@ eina_simple_xml_attributes_parse(const c
value++;
}
for (; value < itr_end; value++)
-
Re: [E-devel] ABI break in eina ?
On Sun, Nov 13, 2011 at 07:25:48PM +0100, Vincent Torri wrote:
> Albin Tonerre (Lutin) told me that there is (maybe, i don't know much
> about that) an ABI break, with a move a function from a source code to an
> inline function. I can't remember the function, but Albin can retrieve it,
> I think.
It is an ABI break if you don't also force an explicit copy. Speaking
from a C99 background, there two ways to create inline functions:
static inline int foo(void) { ... }
inline int foo(void) { ... }
The former will ensure that code is always using the code from the
header file, even if it is creating a local non-inlined copy.
The second form provides an inline hint -- the compiler may or may not
decide to use it. If the code later provides an explicit non-inline
prototype, the compiler will provide the body. This means that the
library can have
int foo(void);
in one C file and it will provide an out-of-line copy.
Note that the traditional GNU inline semantic is slightly different.
Joerg
--
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] [elm_map] Fix up too many connections at the same time.
On Tue, Nov 01, 2011 at 06:11:29PM +0900, Kim Yunhan wrote: > But it already sent to map server, and it already made useless HTTP > connections. What about using HTTP pipelining? Joerg -- RSA® 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: discomfitor trunk/E-MODULES-EXTRA/notification/src
On Mon, Oct 31, 2011 at 12:09:48AM +0200, Tom Hacohen wrote: > On 30/10/11 23:45, Mike Blumenkrantz wrote: > > but it won't matter, because once there is a byte which differs it will stop > > comparing > > Never assume an internal implementation, especially when you are wrong. > :) The biggest advantage of using memcmp over strncmp is that it > *doesn't* always work per byte but using bigger chunks when possible. Actually, a good implementation of strncmp and strcmp will do the same if alignment permits. Joerg -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: discomfitor trunk/E-MODULES-EXTRA/notification/src
On Sun, Oct 30, 2011 at 06:28:03AM -0200, Gustavo Sverzut Barbieri wrote: > Tom is right. You just want to compare the prefix, but you're not sure > icon_path is >= 7 bytes thus strncmp() and not memcmp(). strncmp() is > to be used and not the traditional (strcmp()) as you just want the > prefix. If the icon_path is shorter, it will not match as it contains a NUL byte earlier. Joerg -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-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/evas_generic_loaders
On Fri, Apr 29, 2011 at 11:58:43AM +0200, Vincent Torri wrote: > I'm still wondering aboutefficiency : for example, for pdf rendering, > shouldn't the use of a pdf generic loader be slower than wht i can achieve > in eyesight ? Only if you fork once per page or something like that. Give it a minimal input processing like Ghostscript's X11 target and the overhead is going to mostly vanish. E.g. "open", "render $page $resolution" "close" should be good enough for most purposes. Joerg -- 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] --as-needed breaks EET on some platforms
On Sat, Apr 23, 2011 at 03:11:22PM -0400, Mike Blumenkrantz wrote: > On Sat, 23 Apr 2011 21:00:11 +0200 (CEST) > Vincent Torri wrote: > > > > > Hey > > > > On Sat, 23 Apr 2011, Mike Blumenkrantz wrote: > > > > > configure.ac:429, we add --as-needed and probably shouldn't? > > > > what do you mean by "it breaks" ? configuration problem ? compilation ? > > runtime ? > > > > Vincent > > ../../config/default/e.cfg config \ > e.src 1 > /opt/e17/bin/eet:/opt/e17/lib/libeina.so.1.999: undefined symbol > 'pthread_mutex_init' cinch lazy binding failed! > gmake[3]: *** [e.cfg] Segmentation fault (core dumped) That would be a bug in the libeina linkage and not in EET? Joerg -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric IN trunk/eina: . src/include src/lib
On Wed, Apr 13, 2011 at 11:14:43PM +0200, Cedric BAIL wrote: > >> > and that MAP_POPULATE does not need a too recent linux kernel ? > > > > This should be just conditionalized. > > Agreed. Both should be conditionalized with configure detection. #ifndef MAP_POPULATE #define MAP_POPULATE 0 #endif should be good enough. It's just a performance hint anyway. Joerg -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric IN trunk/eina: . src/include src/lib
On Wed, Apr 13, 2011 at 10:18:27PM +0200, Cedric BAIL wrote: > On Wed, Apr 13, 2011 at 8:36 PM, Vincent Torri wrote: > > On Wed, 13 Apr 2011, Vincent Torri wrote: > >> are you sure that O_CLOEXEC and ACCESSPERMS are portable ? > > I hope they are. It's a pretty basic feature, being able to > automatically close a fd on exec. As for ACCESSPERMS it's just a macro > that should be provided by any unix system (would only means something > on them, but not much in the considered case). Neither is portable. O_CLEXEC is a mostly Linux specific short-cut for fcntl. Unless you really want to save a system call for all cost, just go with the portable appracoh. > > and that MAP_POPULATE does not need a too recent linux kernel ? This should be just conditionalized. Joerg -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Compilation warnings in ecore_con
On Mon, Mar 14, 2011 at 10:15:07AM +0100, Mathieu Taillefumier wrote: > - gnutls_transport_set_ptr(cl->session, (gnutls_transport_ptr_t)cl->fd); > + gnutls_transport_set_ptr(cl->session,(gnutls_transport_ptr_t)(long) > cl->fd); s/long/uintptr_t/ you mean. Joerg -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: eina simple (and stupid) XML parser
On Mon, Feb 28, 2011 at 02:49:06PM -0300, Gustavo Sverzut Barbieri wrote: > How many HTML pages do you see declaring new entities? Of course > parsing HTML with it it's better to do using the SAX so you can handle > close-tags automatically as most people don't close things like > or . Actually, and are not closed in HTML. It has SGML semantic for tags without content. This is different from the XML based dialects. > >> going with JSON tends to be a much simpler option... > > No, if you have a choice, go with EET it's much simpler and efficient. For things you have control over and don't plan to exchange with anyone else: sure. > >> That doesn't work either. XML can't be parsed encoding neutral. Consider > >> documents in shift_jis for this. If you implement a fallback path to > >> handle all well formed XML documents using a full blown parser, you > >> haven't saved anything in terms of code complexity and the request for a > >> benchmark made in this thread is completely valid to justify the > >> *additional* complexity. > > Check out: /usr/share/hal/fdi/*/*.fdi and tell me what difference it > would make. How is that relevant? This attitude is exactly the source of the majority of all interoperability issues. "My files don't use this feature." The next one is going to use this XML parser because it is fast (hopefully) and simple for a different set of files. Oops. > That's my problem with XML people, they can't tell the difference > between theory and reality. In theory you can build all kinds of > corner cases to prove me wrong, but reality shows that we can do just > fine for what we need. Congratulation. You have just shown the attitude everyone condamned about the browser wars. Why do a proper implementation if you can get away with 80% to get your own test set to work. If you want to use it only for FDO files, get them to restrict the specification to well defined subset of XML. You don't even have the excuse that there is no ready made XML parser. If you use fontconfig, you already have one pulled in. I am not an XML advocat. But I do care about people pulling stupid short cuts. History consistently tells us that such assumptions are almost always broken at some point. > Reality is that you just need to find < and >, with the exception of > . Most people don't even use this cdata case. Most > files, although declared as UTF-8 are actually ASCII, with non-ASCII > converted to entities/escaped. If you can find out some case that > providing real UTF-8 strings would break it, then I'll care to fix it. Sorry, but I do have real world XML files using UTF-8, non-ASCII encodings, entities (both for plain characters and more). > Again, any real use case? As for entities, checking for them is more > harm than good: >- you waste time looking for them; >- you need to allocate memory to write the resulting bytes; >- you now have a new problem: which encoding should I write to? If > the document is in encoding ISO-8859-1, you'd need to convert it to > UTF-8 before doing entities? But what if user wants to keep in > ISO-8859-1? Do you convert back? What to do with unsupported chars in > this set? >- how about if your presentation handles entities for you? Like > Evas/Edje/Elementary? You did all of the above for what good? Variant 1: input is ISO-8859-1, program wants ISO-8859-1: no recoding needed. Entities not representable in ISO-8859-1 are invalid and should be flagged as error. Variant 2: input is ISO-8859-1, program wants UTF-8: recoding one the fly of the input. Entities not representable as valid Unicode Code Point are invalid and should be flagged as error. Variant 3: input is UTF-8, program wants UTF-8: no recoding, just consistency checks. Entities not representable as valid Unicode Code Point are invalid and should be flagged as error. Variant 4: input is UTF-8, program wants ISO-8859-1: recoding on the fly of the input. Entities or input characters not representable as ISO-8859-1 should be flagged as error. Not doing the validation in the XML parser typically just results in continuing to process arbitrary garbage. Examples for why this is bad would be the NUL validation in X.509 certificates, just to pick something used to commit fraud in the real world. If you are lucky, you run against an interface that actually validates and throws an error. You just lost all the position information for a proper error message. Or you have to duplicate the input validation logic in the application. Great simplification again. > Most of the times we'll be reading configuration files with it. Or > results of RPC-XML calls. Usually you'll know for sure fields you > could have them and what to replace. Example: if you're reading > something that you'll turn into URL, then just for that field you can > convert to %AB convention instead of converting to UTF-8 and then %AB > format. You know, you just mentioned the one big reason for why it is a bad idea. You think it is a good
Re: [E-devel] RFC: eina simple (and stupid) XML parser
On Mon, Feb 28, 2011 at 10:20:16AM -0300, Gustavo Sverzut Barbieri wrote:
> I've worked with expat before and it's way more complex to use and
> heavy. Sure, it will work and will handle namespace, and encoding...
> but many times you don't want or need it.
The point is that if you don't do that, you no longer have an XML
parser. So don't even call it that. If you explicitly want to use only a
subset, going with JSON tends to be a much simpler option...
> the current SAX-like api I'm calling is 1 single function that
> receives a buffer and a callback, calls you back with pointers to the
> buffer you handled it. It does not consider any form of encoding, thus
> it will never break, it's up to you. It will fallback nicely on
> unhandled conditions, like entity definitions are not handled, they
> are given to you as an open tag statement. That is because MOST of
> these files are ascii and do not use these xml nasty features such as
> entities & like.
That doesn't work either. XML can't be parsed encoding neutral. Consider
documents in shift_jis for this. If you implement a fallback path to
handle all well formed XML documents using a full blown parser, you
haven't saved anything in terms of code complexity and the request for a
benchmark made in this thread is completely valid to justify the
*additional* complexity.
> Even the escaping ({ or &) is not handled, at least with efl
> you're likely to not need it anyway as Evas already handles it for
> you.
This sounds like moving complexity to the wrong layer, too. Ignoring the
question of whether a document editor should preserve entities or not,
most of the users of a "simple" parser should see entities at all or
have to deal with them. There is a good reason for wanting to use them
by human editors.
In short: if it doesn't implement XML, it is not an XML parser. Most of
the configuration files sadly using XML are exactly that. Providing a
simplified interface is fine, it doesn't require throwing compatibility
over board. If you don't want XML, consider something like Apple's
proplib or just JSON. Don't retrofit it into existing file formats.
Joerg
--
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC: eina simple (and stupid) XML parser
On Sun, Feb 27, 2011 at 08:25:06PM -0300, Gustavo Sverzut Barbieri wrote: > Again, this is far from standards compliant as libxml2, but it's even > far from the bloat these xml libs carry. I'd propose it to be > integrated into Eina as it's very useful and small. The problem with most adhoc XML parser implementations is just that. They implement a (reasonable?) subset of XML, they work fine for a long time and then someone comes and breaks them by inserting a comment here or use one of the fancy encoding rules there. As such I would strongly recomment trying to reinvent the wheel. Expat is reasonable small, it is going to be around anyway, since libfontconfig uses it. It might help to provide a nicer interface on top for handling some simple input formats on top, but that's it. Joerg -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] with some options, eina compilation fails
On Wed, Feb 23, 2011 at 08:52:04PM +0100, Vincent Torri wrote:
> ../../src/modules/mp/chained_pool/eina_chained_mempool.c: In function
> 'eina_chained_mempool_free':
> ../../src/modules/mp/chained_pool/eina_chained_mempool.c:324: error: label at
> end of compound statement
>
> we can replace "goto on_error;" by a function containing what is after
> the label. Though i'm not sure it's the best soluiton
Or add a noop statement like do {} while (0);
Joerg
--
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] configure.ac change proposal
On Sun, Dec 19, 2010 at 02:20:21PM -0800, Michael Jennings wrote:
> On Sunday, 19 December 2010, at 22:30:18 (+0100),
> Joerg Sonnenberger wrote:
>
> > "grep -o" is not portable. Can't you do:
> >
> > svnversion -n "${SVN_REPO_PATH:-.}"| sed 's,^\([0-9]*\).*$,\1,'
>
> The spec files use:
>
> svnversion | sed 's/[^0-9].*$//' || echo
>
> which is portable.
One important differences is that it picks up M if you have any local
changes.
Joerg
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] configure.ac change proposal
On Sun, Dec 19, 2010 at 03:36:57PM -0500, Mike Blumenkrantz wrote:
> changed:
> svnversion -n "${SVN_REPO_PATH:-.}"|grep -Eo "^[0-9]+"
"grep -o" is not portable. Can't you do:
svnversion -n "${SVN_REPO_PATH:-.}"| sed 's,^\([0-9]*\).*$,\1,'
for much the same result?
Joerg
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/eina/src: include lib
On Sat, Oct 30, 2010 at 01:24:31PM +0200, Cedric BAIL wrote: > In fact lstat will do the trick. d_ino / d_fileno exist for the same reasons as d_type -- to avoid having to stat in first place. Joerg -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libvlc is GPL
On Tue, Oct 19, 2010 at 12:17:43AM +0200, Vincent Torri wrote: > > which means that emotion is GPL, iiuc. No, it just means that it has to be a GPL compatible license. The normal 2-clause BSD license or LGPL is fine. Joerg -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-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/eina/src/include
On Wed, Aug 25, 2010 at 10:22:19PM +0200, Vincent Torri wrote: > On Wed, 25 Aug 2010, Raphael Kubo da Costa wrote: > > FWIW, on FreeBSD at least, limits.h includes both sys/limits.h and > > sys/syslimits.h (the latter only if __POSIX_VISIBLE is defined). > > All versions ? At least down to FreeBSD 4.9. Unless you are doing silly things like using -pedantic, but in that case you get what you ask for. Joerg -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Wed, Aug 25, 2010 at 08:32:28PM +0200, Vincent Torri wrote: > > > On Mon, 23 Aug 2010, Joerg Sonnenberger wrote: > > >On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: > >>>-#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) > >>>&& \ > >>>- defined (__APPLE__)) > >>>-# include > >>>-#endif > >>>+#include > >> > >>Did Joerg try that on all the platforms that were in the #define ? If no, > >>revert this. I did ask people where the nedded constant were located, and > >>it was not in limits.h > > > >The original version before my change clearly doesn't work on POSIX > >compliant systems. For FreeBSD, sys/limits.h has been included by > >limits.h for at least 7 years and they did some header reorg at the > >time. I can't say for Darwin, but I would strongly surprised as I have > >enough code using PATH_MAX and co without ever including sys/limits.h. > >So can you demonstrate any breakage or is this just a theoretical > >remark? > > I was in contact with 2 mac os x users and one freebsd user. I try > to fixed the compilation, and limits.h was not sufficient. Not enough for WHAT? Given that Mac OS X is supposedly certified for POSIX compliants, that would be surprising. It would also disagree what I have been told today when asking exactly this question. Joerg -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/include
On Sun, Aug 22, 2010 at 06:08:38AM +0200, Vincent Torri wrote: > > -#if defined (__MacOSX__) || defined (__FreeBSD__) || (defined (__MACH__) > > && \ > > - defined (__APPLE__)) > > -# include > > -#endif > > +#include > > Did Joerg try that on all the platforms that were in the #define ? If no, > revert this. I did ask people where the nedded constant were located, and > it was not in limits.h The original version before my change clearly doesn't work on POSIX compliant systems. For FreeBSD, sys/limits.h has been included by limits.h for at least 7 years and they did some header reorg at the time. I can't say for Darwin, but I would strongly surprised as I have enough code using PATH_MAX and co without ever including sys/limits.h. So can you demonstrate any breakage or is this just a theoretical remark? Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ANNOUNCE: ALPHA Release of core EFL
On Sat, Aug 21, 2010 at 01:02:43PM +1000, Carsten Haitzler wrote: > releases of Eina, Eet, Evas, Ecore, Embryo, Edje, Efreet, E_Dbus and Eeze > from: ecore seems to have lost ECore_X_Screen_Size. It is still used in the xcb binding, but not defined anymore. Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING & spec files
On Mon, Aug 16, 2010 at 07:41:01AM +1000, Carsten Haitzler wrote:
> On Mon, 16 Aug 2010 00:33:33 +0200 Joerg Sonnenberger
>
> said:
>
> > On Mon, Aug 16, 2010 at 07:13:13AM +1000, Carsten Haitzler wrote:
> > > > edje:
> > > > The second paragraph is non-OSI and some parts are weird, e.g. the file
> > > > doesn't actually contain a copyright notice. I think the 2-clause BSD
> > > > license covers the intention and is OSI approved, but that's your call.
> > >
> > > if you only ship OSI approved software then you won't be shipping efl. :)
> > > but yes. copyright notice seems to have vanished. odd. need to fix that.
> > > anyway - the license is the 2 clause bsd with addendum that effectively
> > > makes it like lgpl which removes the gpl incompatibility. it provides no
> > > restrictions on apps or libs that link to the the efl lib. it provides for
> > > restrictions for people distributing the efl lib as stand-alone or
> > > statically compiled. if by incompatibility you mean either gpl apps using
> > > efl libraries OR gpl apps shipping along inside a distro package set with
> > > these efl apps.
> >
> > The 2-clause BSD license is GPL compatible. The primary difference
> > between 2-clause BSD license and MIT license is the clarification that
> > binary distributions have to provide the copyright notice separately in
> > text form. From the COPYING-PLAIN, I can't find a reason to not use the
> > straight forward 2-clause BSD license, if the above is your only concern.
>
> well the intent is to still get some kind of acknowledgment. be it via a
> simple
> "ldd" and see what it links to or a ls /usr/lib and see libevas.so* or via a
> notice in documentation, source code publication or email etc. - some
> mechanism
> to say "hey - we used your stuff". the 2 clause bsd doesn't. the 3 clause does
> but creates compat issues. the efl modified 3 clause should be issue-free.
To avoid confusion: http://opensource.org/licenses/bsd-license.php
is the canonical reference. 2-clause BSD license drops the "endorsement"
clause. The normal way to fulfill clause 2 ("Redistribution in binary
form") is to either also provide source code or to have a LEGAL file
somewhere. The difference to the original (4-clause) BSD license is that
you don't have to put it in the fine print of your ads or at the end of
the user manual. The difference to the (L)GPL is that you don't have to
provide the source code. The note in the place you would normally place
the (L)GPL source offer is good enough. In theory, putting it as file into
the flash of the machine or on the CD-ROM with the electronical manual is
good enough.
The legal hassle for this is reduced by having a single top-level file
like COPYING. It could get even easier if that file lists the exceptions
and that it is authoritive for the rest. E.g. Makefile.in and configure
are not covered by COPYING.
If you want a mechanism of "if you use this, you have to tell us about
it", you get the same problem with the GPL as the original BSD license.
Just to be clear, the difference here is that it requires actively
telling about the use and such it is considered by the FSF an additional
restriction.
Joerg
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING & spec files
On Mon, Aug 16, 2010 at 07:13:13AM +1000, Carsten Haitzler wrote: > > edje: > > The second paragraph is non-OSI and some parts are weird, e.g. the file > > doesn't actually contain a copyright notice. I think the 2-clause BSD > > license covers the intention and is OSI approved, but that's your call. > > if you only ship OSI approved software then you won't be shipping efl. :) but > yes. copyright notice seems to have vanished. odd. need to fix that. anyway - > the license is the 2 clause bsd with addendum that effectively makes it like > lgpl which removes the gpl incompatibility. it provides no restrictions on > apps or libs that link to the the efl lib. it provides for restrictions for > people distributing the efl lib as stand-alone or statically compiled. if by > incompatibility you mean either gpl apps using efl libraries OR gpl apps > shipping along inside a distro package set with these efl apps. The 2-clause BSD license is GPL compatible. The primary difference between 2-clause BSD license and MIT license is the clarification that binary distributions have to provide the copyright notice separately in text form. From the COPYING-PLAIN, I can't find a reason to not use the straight forward 2-clause BSD license, if the above is your only concern. Just by chance, edje_cache.c has a copyright and LGPL license header. It might be useful to carefully check for those as well :) Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] COPYING & spec files
Hi all, I'm just going over the various COPYING files to prepare tagging the appropiate licenses for pkgsrc. e_dbus: I'm not sure if this is intentional, but this is certainly not the MIT license and it looks like it is functionally equal or stronger than the original BSD license. E.g. it might not be GPL compatible. See the third paragraph (... its documentation and marketing & publicy materials, ...). So calling it a BSD license in the spec file is only partially true. ecore: License in spec should be MIT if RPM distinguishes this. edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. eet: Same as edje. efreet: Same as e_dbus. embryo: Same as edje. enlightenment: Same as edje evas: Same as edje Summary: Having two licenses that aren't OSI approved is suboptimal. It would make corporate usage at least somewhat easier to have only OSI approved licenses as there are a lot of guidelines dealing with those already. At the very least, it would be useful to only have a single non-LGPL license, in which case the (weaker) edje version is preferable. I'm bringing this up (again) now since having consistency useful for EFL 1.0.0. Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] efreet and icon loading
Hi all,
attached patch fixes two issues:
(1) If using a non-default prefix, share/pixmaps should be checked
before the hard-coded /usr/share/pixmaps fallback. This basically
restores symmetry with the other cases like share/icons.
(2) Do a fallback lookup if the theme is not valid or faked. This can
happen if only hicolor is installed and e17 decides to use Tango.
Before, e.g. gimp's icon wasn't picked up because the short cut was too
early.
Joerg
$NetBSD$
--- efreet_icon.c.orig 2010-05-18 06:45:13.0 +
+++ efreet_icon.c
@@ -549,14 +549,16 @@ efreet_icon_find_helper(Efreet_Icon_Them
efreet_icon_theme_cache_check(theme);
-/* go no further if this theme is fake */
-if (theme->fake || !theme->valid) return NULL;
/* limit recursion in finding themes and inherited themes to 256 levels */
if (recurse > 256) return NULL;
recurse++;
-value = efreet_icon_lookup_icon(theme, icon, size);
+/* go no further if this theme is fake */
+if (theme->fake || !theme->valid)
+ value = NULL;
+else
+ value = efreet_icon_lookup_icon(theme, icon, size);
/* we didin't find the image check the inherited themes */
if (!value || (value == NON_EXISTING))
@@ -861,6 +863,17 @@ efreet_icon_fallback_icon(const char *ic
}
}
+EINA_LIST_FOREACH(xdg_dirs, l, dir)
+{
+snprintf(path, PATH_MAX, "%s/pixmaps", dir);
+icon = efreet_icon_fallback_dir_scan(path, icon_name);
+if (icon)
+{
+efreet_icon_cache_add(efreet_icon_find_theme_check(NULL),
icon_name, 0, icon);
+return icon;
+}
+}
+
icon = efreet_icon_fallback_dir_scan("/usr/share/pixmaps", icon_name);
}
@@ -1260,6 +1273,12 @@ efreet_icon_theme_dir_scan_all(const cha
efreet_icon_theme_dir_scan(path, theme_name);
}
+EINA_LIST_FOREACH(xdg_dirs, l, dir)
+{
+snprintf(path, sizeof(path), "%s/pixmaps", dir);
+efreet_icon_theme_dir_scan(path, theme_name);
+}
+
efreet_icon_theme_dir_scan("/usr/share/pixmaps", theme_name);
}
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, Aug 14, 2010 at 11:35:13PM +0200, Albin Tonnerre wrote: > - If efreet returns an SVG icon when SVG rendering is not compiled in evas, >then you get no icon where an xpm icon (which could have been rendered >correctly) might have existed. OK > - Since there is no way to ask evas if SVG support is available (which I > think >is a mistake), you need to do some kind of runtime detection. Yes, that's bad. > - Right now, the only practical way to do that is using some voodoo: create a >dummy file and try to load it. Why not use install the dummy file to a known location and try loading it that way? share/enlightenment/data/icons/dummy.svg or so. Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Insecure SVG loader test
hi all, in src/bin/e_main.c there is this wonderful gem _e_main_test_svg_loader. Writting a hard-coded XML file to a known location is just asking for trouble. It basically means that anyone with write access to /tmp can make the E17 user overwrite a file with permissions of the user. It also creates race conditions for multiple users. Any reason why this piece of code is needed at all? While looking at seemingly redundant code: why is e_fm_mime_icon_get not using efreet? Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ecore's poll file manager
Hi all,
attached is a small bugfix for ecore. If the to-be-monitored path
doesn't exist, the poll monitor currently tries to remove an item from a
list which was never hooked up.
Joerg
$NetBSD$
--- src/lib/ecore_file/ecore_file_monitor_poll.c.orig 2010-08-14
16:48:51.0 +
+++ src/lib/ecore_file/ecore_file_monitor_poll.c
@@ -95,6 +95,8 @@ ecore_file_monitor_poll_add(const char *
em->data = data;
ECORE_FILE_MONITOR_POLL(em)->mtime = ecore_file_mod_time(em->path);
+ _monitors =
ECORE_FILE_MONITOR(eina_inlist_append(EINA_INLIST_GET(_monitors),
EINA_INLIST_GET(em)));
+
if (ecore_file_exists(em->path))
{
if (ecore_file_is_dir(em->path))
@@ -130,8 +132,6 @@ ecore_file_monitor_poll_add(const char *
return NULL;
}
- _monitors =
ECORE_FILE_MONITOR(eina_inlist_append(EINA_INLIST_GET(_monitors),
EINA_INLIST_GET(em)));
-
return em;
}
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.0.0 - ATTENTION
On Sat, Aug 14, 2010 at 08:36:57PM +1000, Carsten Haitzler wrote: > What: the march to EFL 1.0.0 - first stage "ALPHA" > Covers: eina evas ecore embryo edje efreet e_dbus > Extras: eet (going to 1.4.0 to be in sync with efl 1.0.0) > > it's been a while coming. but it's pretty much about time to go to 1.0.0. so > what i'm doing is calling a freeze in about 12 hours from now) - 0:00 GMT > sunday august 14th 2010. this is for all of the above libraries (including > eet). this means after freeze: Could you clarify if this is a freeze for the "alpha" version or final? E.g. do you plan a snapshot of all parts of EFL for easier testing on various platforms in prepartion for 1.0.0? Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Internationalisation support in Edje
On Fri, Jul 09, 2010 at 06:57:49PM +0200, Cedric BAIL wrote: >First to put some background around this proposal. We want to push > more the use of Edje for application layout (thanks to the always > improving Elementary external support). This mean that a lot of string > end up inside the Edje file. And they will depend on the Edje file > content. So it's not really acceptable to set the text from outside of > Edje. We want to distribute themes with their translation easily, we > have one efficient file to distribute, eet, and it should stay that > way. Seriously, does the gettext approach to translation buy you anything at all? The size argument is not really valid, libintl can be implemented quite efficiently (given the constraints). From I have seen in the past, "leaking" English due to a lack of translation is from an UI point often a lot worse than not having a native version at all. So why do you want to go to the trouble of using them? Joerg -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Add http basic auth to ecore_con_url
On Mon, Mar 01, 2010 at 12:13:03AM +0100, Vincent Torri wrote: > and, btw, no, it can't be achieve this way : vsnprintf does not > return the number of char if the buffer is not sufficiently arge > (contrary to the libc implentation on linux). It returns -1 in that > case If you mean the function on Windows: don't use it. Not sure about Windows, but on many other systems you can always implement snprintf in the crude way by using /dev/null with printf... Joerg -- 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] Add http basic auth to ecore_con_url
On Sun, Feb 28, 2010 at 10:02:25PM +, Rui Miguel Silva Seabra wrote: > The attached patch would seem to add http basic auth to ecore_con_url Does it work with usernames or passwords containing ":"? Joerg -- 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] *WARNING* disallowed the creation of a new page in Trac for registered users
On Sat, Feb 20, 2010 at 05:25:38PM +0100, Massimiliano Calamelli wrote: > Hello, i removed the permission to create a new page in Trac for > registered users to temporary stop the spam in Trac. Does Trac allow ACLs for that? E.g. pull all known-to-be-good users in a group that has the privilege and add users manually or on request? Joerg -- 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] EFL 1.0.0 alpha
On Tue, Jan 19, 2010 at 12:31:26PM -0200, Gustavo Sverzut Barbieri wrote: > This is not happening for reasons already said in this list. Summary > is that some cases it is worth to share installations amongst > different systems and architectures. I should add that it doesn't work as well for another trivial reason. It assumes that the same module can be used across different versions of the same OS. This is not true at the very least for FreeBSD, where each major version has a different libc major... Joerg -- 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] EFL 1.0.0 alpha
On Tue, Jan 19, 2010 at 12:31:26PM -0200, Gustavo Sverzut Barbieri wrote: > Why do you care about these names anyway? Distros will handle this for > you, and they should not have much work into getting these things > correct (debian allow wildcards in their *.install, gentoo handles > automatically, etc...) Because I am maintaining packages and the choosen combination is not as consistent as one might assume. For example, it is not the plain OS name, but how config.guess wants to mangle it. E.g. for NetBSD on i386, it will end up using netbsdelf. The other point was the directory choosing the version/ABI combination should be at the top, not the bottom. This is also a usability question in the even that you really want to mix them, as it makes it far easier to compare subtrees. Joerg -- 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] EFL 1.0.0 alpha
On Tue, Jan 19, 2010 at 08:01:38AM +0900, Carsten Haitzler wrote: > if there are patches pending - bring attention to them. if there are bugs - > speak up. Can you please drop OS name and platform from the module pathes in EVAS and co? It doesn't really buy anything as you can't trivially mix architectures that way anyway, but is slightly more annoying due to the assoicated changes between platforms. In fact, I would prefer if the ABI version is made the top-level path name, so that e.g. lib/evas/modules-1.0/savers/eet/module.so is used, instead of the more complicated lib/evas/modules/savers/eet/netbsd-x86_64-ver-1.0/module.so or so. Joerg -- 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: devilhorns trunk/edje/src/lib
On Thu, Dec 31, 2009 at 11:03:33AM +1100, Brett Nash wrote: > > %ld and unsigned int? You must be joking... Defining PRIdMAX and > > friends can be easily automated. > > Unfortunately although PRIdMAX is useful, I don't believe there is one > for size_t. Instead you use the %z modifier, which leads us back to > where we started. Well, you can easily define one and force platforms with ancient printf to a magically defined version matching int/long based on the platform settings. The code to compute integer sizes is part of autoconf already. Unless cross-compiling is used, it can be checked for trivially as well. Joerg -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/edje/src/lib
On Wed, Dec 30, 2009 at 10:44:23AM -0200, Gustavo Sverzut Barbieri wrote:
> > Unfortunately there is no safe way of printing it in C89 (ie windows).
> > The best way is:
> > printf("... %ld..",(unsigned int)blah);
%ld and unsigned int? You must be joking... Defining PRIdMAX and friends
can be easily automated.
> Given that in many places we use those for logging and logging should
> move to EINA_LOG and some systems do not handle "%s" with NULL (ie:
> Solaris, BSDs...), isn't it better to follow Glib/Gstreamer logging
> and provide our own printf() on these systems, doing clean C99 with
> GNU niceness (%s+NULL) and avoid ugly thing spread in code?
IMO it is still better to fix the programs. Besides, printf with NULL is
checked for on many systems (like the BSDs), the real problem is that
GCC sometimes decides to replace printf with fputs, which doesn't...
Joerg
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/TMP/st/elementary/src/lib
On Sun, Nov 15, 2009 at 06:22:45AM +0100, Vincent Torri wrote: > what they won't like is: > > int i1; > i1 = 4; > int i2; > > that is, not having all the variable declaration at the beginning of the > block Are pre-C99 compilers a desired platform for E17? Joerg -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Word-Wrapping and Long Chinese String
On Thu, Oct 29, 2009 at 08:53:47AM +0800, Brian Wang wrote: > On Wed, Oct 28, 2009 at 9:11 PM, Joerg Sonnenberger > wrote: > > On Wed, Oct 28, 2009 at 01:41:01PM +0100, Peter Wehrfritz wrote: > >> Your patch assumes that an UTF8 character initiates a new word. That is > >> wrong for the most European language, if not for all. So there must be > >> another solution. > > > > The best bet you can do is likely iswblank(x) || wcwidth(x) == 0. There > > is a common rule to include zero width characters for this purpose for > > languages like Chinese or Japanese, the only alternative would be > > dictionary based. > > Could you elaborate more about this? > Do you mean that the programmer needs to put a non-printable character > after each Chinese/European character? A non-printable character is a different concept from a zero width character. Think of the zero width character as hyphenation hint or word border. The rule of using blanks works well for Indogermanic languages. The zero width rule works as fallback for other languages that don't have a natural word boundary. The main point is that it doesn't affect the visual representation. Joerg -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Word-Wrapping and Long Chinese String
On Wed, Oct 28, 2009 at 01:41:01PM +0100, Peter Wehrfritz wrote: > Your patch assumes that an UTF8 character initiates a new word. That is > wrong for the most European language, if not for all. So there must be > another solution. The best bet you can do is likely iswblank(x) || wcwidth(x) == 0. There is a common rule to include zero width characters for this purpose for languages like Chinese or Japanese, the only alternative would be dictionary based. Joerg -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elementary with framebuffer backend font question
On Wed, Oct 07, 2009 at 08:50:35PM +0200, Marc Andre Tanner wrote: > Does anybody know how to correctly set up the Sans alias? Take a look at examples from fontconfig, e.g. 30-urw-aliases.conf. In fact, 45-latin.conf should do what you want. Joerg -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Tue, Sep 08, 2009 at 08:52:39PM -0300, Gustavo Sverzut Barbieri wrote: >- ultra-dirty hack to remove extra pointer. The hack bases on the > fact that we just use ->last from the first node, that always have the > ->prev == NULL. So we could have the first ->prev == ->last, but how > to know it's the first then, you might ask? Easy! Just use the fact > that valid addresses are multiple of sizeof(word) and you're done, no > supported platform uses less than 4 bytes, so ->prev = ->last | 1; > would work, and checks for ->last & 1 would tell you if it's the case > or not. Please don't. Unless you can demonstrate a use case where the impact is large enough to really, really matter. Joerg -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] possible truncation of variable values in eina_fixed_bitmap.c on 64 bits
On Wed, Aug 19, 2009 at 02:36:54PM +0200, Cedric BAIL wrote: > It's not gcc specific other decent compiler support this feature. But > apparently not suncc, so you can patch if needed. void arithmetic is NOT a feature. It is a historic accident and bug. Code using it is simply broken. Nothing less. Joerg -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] gadcon sities, efm2 slave fix, opinfo improvements
On Fri, Jun 26, 2009 at 12:30:02PM +0200, Vincent Torri wrote: >> The other (and IMO preferable option) is to use AC_SYS_LARGEFILE. > > i've just tried on my distro (ubuntu 32 bits), and that macro defines > only _FILE_OFFSET_BITS to 4. No _LARGEFILE_SOURCE or _LARGEFILE64_SOURCE. > > Is it a problem ? It should do the right thing. What is needed depends a lot on the OS, e.g. for the BSDs sanity is ensured and you don't need anything, the test differs for Linux, Solaris, AIX, HP-UX... You can check by looking at sizeof(off_t) :) Joerg -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] gadcon sities, efm2 slave fix, opinfo improvements
On Fri, Jun 26, 2009 at 03:27:45PM +1000, Carsten Haitzler wrote: > #define _LARGEFILE_SOURCE > #define _LARGEFILE64_SOURCE > #define _FILE_OFFSET_BITS 64 > #include > #include > #include > #include [snip] The other (and IMO preferable option) is to use AC_SYS_LARGEFILE. Joerg -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Add distinguish the target site to gadgets
On Wed, Jun 24, 2009 at 11:40:06PM +1000, Carsten Haitzler wrote: > > > unmapping should help give a hint... it also looks better in top/ps :) > > > > The first part is already done by using madvise. It doesn't forcefully > > trash the VM space though. > > neither does munmap() - it sits in cache. (as it does when mmaped()). but it > looks better when looking at mem footprint and provides an extra hint to the > kernel - if mapped, the kernel can assume that at some point you may need the > data - when not mapped, it can just put it in speculative cache and forget > about it. posix_madvise(2) with POSIX_MADV_DONTNEED provides the same effect with regard to caching as munmap(2) does. It does not force the overhead of changing the VM space though. This is especially visible on SMP systems. There are some other use cases of mmap(2) that should be avoided if possible, e.g. mapping read-write of the same file in multiple processes at different locations can be very expensive for some brain-damaged MMU designs (older ARMs *cough*). Basically, if you want to help the OS to to free the cache, madvise(2) is much easier from the programming point of view. It also reduces the number of possible errors. I'm not even sure how much is really gained by allowing the cache to drop out of memory. E.g. share/mime is 3MB on my system and the XML representation is not exactly storage efficient. Joerg -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Add distinguish the target site to gadgets
On Sat, Jun 20, 2009 at 09:25:59PM +1000, Carsten Haitzler wrote: > > Is it really usefull to unmap ? can't we trust the kernel to drop it > > when under presure ? > > unmapping should help give a hint... it also looks better in top/ps :) The first part is already done by using madvise. It doesn't forcefully trash the VM space though. Joerg -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] entrance portability to !Linux
On Fri, Jun 12, 2009 at 11:36:08AM -0300, Gustavo Sverzut Barbieri wrote:
> On Fri, Jun 12, 2009 at 11:08 AM, Joerg
> Sonnenberger wrote:
> > Hi all,
> > attached patch avoids the deprecated getopt_long_only functions. They
> > only exist in GNU libc, while getopt_long is also present e.g. in the
> > various BSD libcs.
>
> It would be great if you port them to ecore_getopt instead ;-)
Attached.
Joerg
Index: src/daemon/Entranced.h
===
--- src/daemon/Entranced.h (revision 41021)
+++ src/daemon/Entranced.h (working copy)
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
Index: src/daemon/util.c
===
--- src/daemon/util.c (revision 41021)
+++ src/daemon/util.c (working copy)
@@ -3,7 +3,7 @@
/* extern Entranced_Config config; */
-int entranced_debug_flag = 0;
+unsigned char entranced_debug_flag = 0;
void
entranced_debug(char *fmt, ...)
Index: src/daemon/spawner.c
===
--- src/daemon/spawner.c(revision 41021)
+++ src/daemon/spawner.c(working copy)
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
#include "Entranced.h"
#include "Entranced_Display.h"
#include "auth.h"
@@ -34,26 +35,32 @@
static int _event_cb_exited(void *, int, void *);
static int _event_cb_signal_exit(void *, int, void *);
+static const Ecore_Getopt options = {
+"entranced",
+NULL,
+PACKAGE_VERSION,
+"(C) 2009 Enlightenment, see AUTHORS.",
+"BSD with advertisement, see COPYING",
+"Launch Entrance Display Manager\n\n"
+"%prog manages the X session by itself. "
+"If you want to launch Entrance\nfrom an existing X session,"
+"launch it directly by typing \"entrance\".",
+1,
+{
+ ECORE_GETOPT_STORE_TRUE('D', "debug", "enable debug mode"),
+ ECORE_GETOPT_VERSION('V', "version"),
+ ECORE_GETOPT_COPYRIGHT('R', "copyright"),
+ ECORE_GETOPT_LICENSE('L', "license"),
+ ECORE_GETOPT_STORE_STR('c', "config", "specify config file for greeter"),
+ ECORE_GETOPT_STORE_STR('d', "display", "connect to an existing X
server"),
+ ECORE_GETOPT_STORE_TRUE('n', "nodaemon", "don't fork to background
(useful for init scripts)"),
+ ECORE_GETOPT_HELP('h', "help"),
+ ECORE_GETOPT_STORE_TRUE('a', "disable-xauth", "do not enable XAUTH"),
+ ECORE_GETOPT_STORE_TRUE('v', "verbose", "display extra debugging info"),
+ ECORE_GETOPT_SENTINEL
+}
+};
-void
-usage(char *name)
-{
- /* This should probably in a separate usage function, but bleh */
- printf("Entranced - Launcher for the Entrance Display Manager\n");
- printf("Usage: %s [OPTION] ...\n\n", name);
-
printf("--\n");
- printf(" -c CONFIG Specify config file for greeter\n");
- printf(" -d DISPLAY Connect to an existing X server\n");
- printf(" -help Display this help message\n");
- printf(" -verbose Display extra debugging info\n");
- printf(" -nodaemon Don't fork to background (useful for init
scripts)\n");
-
printf("==\n\n");
- printf("Note: if you're launching Entrance from within an existing X
session, don't\n");
- printf("try to use entranced or you may get unexpected results. Instead,
launch\n");
- printf("entrance directly by typing \"entrance\".\n\n");
- exit(0);
-}
-
/*
* Main function
*/
@@ -61,20 +68,29 @@
int
main(int argc, char **argv)
{
- int c;
- int nodaemon = 0;/* TODO: Config-ize this variable */
+ unsigned char exit_option = 0;
+ unsigned char debug_mode = 0;
+ char *config_file = NULL;
+ char *display = NULL;
+ unsigned char nodaemon = 0;
+ unsigned char disable_xauth = 0;
+
+ Ecore_Getopt_Value values[] = {
+ ECORE_GETOPT_VALUE_BOOL(debug_mode),
+ ECORE_GETOPT_VALUE_BOOL(exit_option),
+ ECORE_GETOPT_VALUE_BOOL(exit_option),
+ ECORE_GETOPT_VALUE_BOOL(exit_option),
+ ECORE_GETOPT_VALUE_STR(config_file),
+ ECORE_GETOPT_VALUE_STR(display),
+ ECORE_GETOPT_VALUE_BOOL(nodaemon),
+ ECORE_GETOPT_VALUE_BOOL(exit_option),
+ ECORE_GETOPT_VALUE_BOOL(disable_xauth),
+ ECORE_GETOP
Re: [E-devel] [PATCH] entrance portability to !Linux
On Fri, Jun 12, 2009 at 03:11:57PM -0300, Gustavo Sverzut Barbieri wrote: > > About ecore_getopt: > > > > Why is it using argv[0] in the help texts? That is (IMO) confusing, > > wouldn't basename(argv[0]) be better? > > just because most tools do that, i can change that if you wish. Please. It might generally be nice to have someone ecore_app_progname(), which returns argv[0] if it contains no / and strrchr(argv[0], '/') + 1 otherwise. > PS: I know of bugs of handling description print. Sometimes the output > is incorrectly truncated and it's weird, still usable... but I had no > time to fix it. It would be also good to have some kind of VERBATIM > flag so you can add pre-formated code like commands that will not > apply line break, and maybe respect \n as well. >From looking at it so far I have two issues with the output formating: (a) It doesn't allow real paragraphs with separating newline. (b) The default help texts should be capitalized for consistency. Joerg -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] entrance portability to !Linux
On Fri, Jun 12, 2009 at 11:36:08AM -0300, Gustavo Sverzut Barbieri wrote: > On Fri, Jun 12, 2009 at 11:08 AM, Joerg > Sonnenberger wrote: > > Hi all, > > attached patch avoids the deprecated getopt_long_only functions. They > > only exist in GNU libc, while getopt_long is also present e.g. in the > > various BSD libcs. > > It would be great if you port them to ecore_getopt instead ;-) About ecore_getopt: Why is it using argv[0] in the help texts? That is (IMO) confusing, wouldn't basename(argv[0]) be better? Joerg -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] entrance portability to !Linux
On Fri, Jun 12, 2009 at 04:56:29PM +0200, Vincent Torri wrote:
>>> That would be sys/time.h, but I am not sure how it works on Windows (or
>>> if it does at all). This is the version of minimal namespace pollution.
>>
>> let's Vincent say for windows :-)
>
> I don't think that entrance can be used on Windows, so forget that OS for
> entrance, do what you want :-)
Reattached the patch we are talking about, it is for ecore.
Joerg
$NetBSD$
--- src/lib/ecore/Ecore.h.orig 2009-06-12 01:36:30.0 +0200
+++ src/lib/ecore/Ecore.h
@@ -68,6 +68,8 @@
extern "C" {
#endif
+struct timeval;
+
#define ECORE_CALLBACK_CANCEL 0 /**< Return value to remove a callback */
#define ECORE_CALLBACK_RENEW 1 /**< Return value to keep a callback */
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] entrance portability to !Linux
Hi all,
attached patch avoids the deprecated getopt_long_only functions. They
only exist in GNU libc, while getopt_long is also present e.g. in the
various BSD libcs.
Joerg
Index: src/daemon/spawner.c
===
--- src/daemon/spawner.c(revision 41009)
+++ src/daemon/spawner.c(working copy)
@@ -44,9 +44,9 @@
printf("--\n");
printf(" -c CONFIG Specify config file for greeter\n");
printf(" -d DISPLAY Connect to an existing X server\n");
- printf(" -help Display this help message\n");
- printf(" -verbose Display extra debugging info\n");
- printf(" -nodaemon Don't fork to background (useful for init
scripts)\n");
+ printf(" --help Display this help message\n");
+ printf(" --verbose Display extra debugging info\n");
+ printf(" --nodaemon Don't fork to background (useful for init
scripts)\n");
printf("==\n\n");
printf("Note: if you're launching Entrance from within an existing X
session, don't\n");
printf("try to use entranced or you may get unexpected results. Instead,
launch\n");
@@ -95,7 +95,7 @@
/* Parse command-line options */
while (1)
{
- c = getopt_long_only(argc, argv, "c:d:nhvD", d_opt, NULL);
+ c = getopt_long(argc, argv, "c:d:nhvD", d_opt, NULL);
if (c == -1)
break;
switch (c)
Index: src/config/entrance_edit_main.c
===
--- src/config/entrance_edit_main.c (revision 41009)
+++ src/config/entrance_edit_main.c (working copy)
@@ -90,7 +90,7 @@
int c;
- while((c = getopt_long_only(argc, argv,
":a:A:b:d:e:g:hH:i:I:m:M:n:N:o:p:r:R:s:S:t:T:u:U:x:X:", d_opt, NULL)) != -1)
+ while((c = getopt_long(argc, argv,
":a:A:b:d:e:g:hH:i:I:m:M:n:N:o:p:r:R:s:S:t:T:u:U:x:X:", d_opt, NULL)) != -1)
{
switch(c)
{
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Allow building with !GNU make of entrance
Hi all,
the attached patch avoids a GNU-makeism. $< are only allowed in suffix
rules.
Joerg
Index: data/config/Makefile.am
===
--- data/config/Makefile.am (revision 41009)
+++ data/config/Makefile.am (working copy)
@@ -11,4 +11,4 @@
all: $(DB)
$(DB): $(SCRIPT)
- sh $< || :
+ sh ${SCRIPT} || :
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] i18n environment
Hi all,
e17 will curretly set LC_ALL as well as LANGUAGE and LANG. That is quite
annoying as at least on NetBSD LC_ALL overrides all other variables.
I am not aware of a system that doesn't use LANG or LANGUAGE if LC_* is
not specified, so the most sane behavior is to just drop LC_ALL, IMO.
Can this be included?
Joerg
--- e_intl.c.orig 2009-04-14 01:48:30.0 +0200
+++ e_intl.c
@@ -153,7 +153,6 @@ e_intl_language_set(const char *lang)
{
e_util_env_set("LC_MESSAGES", _e_intl_orig_lc_messages);
e_util_env_set("LANGUAGE", _e_intl_orig_language);
- e_util_env_set("LC_ALL", _e_intl_orig_lc_all);
e_util_env_set("LANG", _e_intl_orig_lang);
lang = getenv("LC_MESSAGES");
@@ -202,7 +201,6 @@ e_intl_language_set(const char *lang)
{
e_util_env_set("LANGUAGE", _e_intl_language);
e_util_env_set("LANG", _e_intl_language);
-e_util_env_set("LC_ALL", _e_intl_language);
e_util_env_set("LC_MESSAGES", _e_intl_language);
}
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Releases & Snaps!
On Thu, Apr 23, 2009 at 12:27:22AM +1000, Carsten Haitzler wrote: > Eet 1.2.0 release. > > Eina, Evas, Ecore, Embryo, Edje, E_Dbus, Efreet and Enlightenment 060 snap. > This is svn rev 40284. These are clean and pass ditcheck with proper sonames > and module versioning. > > see http://www.enlightenment.org/p.php?p=news/show&l=en&news_id=3 for news. Thanks! Joerg -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] NOTICE: svn feature freeze this weekend (April 17-19)
On Sun, Apr 19, 2009 at 08:46:31PM -0300, Gustavo Sverzut Barbieri wrote: > And freeze is over! Packagers should use revision 40244, I documented > this in http://trac.enlightenment.org/e/wiki/ReleaseSchedule Could you also just role a set of snapshot tarballs, please? Joerg -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] ecore aborts on EBADF
On Fri, Apr 10, 2009 at 05:47:43AM -0300, Andre Dieb wrote: > Here's a patch for handling EBADF (Bad file descriptor) error after select() > (following the thread "random abort caused by ecore"). I'm not sure F_GETFD exists everywhere, but what about using F_GETFL? Joerg -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric IN trunk/evas: m4 src/lib/canvas
On Fri, Feb 13, 2009 at 12:22:14AM +1100, Carsten Haitzler wrote: > technically you should memset() the entire sizeof(struct) to 0 first to ensure > it is 0. Technically that is only silencing Valgrind and redundant from the PoV of C. If that is the goal, memset is the right approach; packed is very, very bad as soon as you have platforms like SPARC where unaligned access is extremely expensive. Joerg -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
