Re: [E-devel] Exterminator - Simple Task Manager in Elementary
Not directly. Obviously 100% CPU is bad for power usage. However a process that wakes up 1 / second for 0.1 seconds will use significantly less power than a process that wakes up 1000 times a second for 0.0001 seconds; even though they both have 10% CPU usage. In this case frequent wake-ups are the problem. Something like powertop is great for this. Integrating even wakeups/second into Exterminator would really be a selling point for it. Regards, nash On 25 February 2015 at 19:27, Jeff Hoogland jeffhoogl...@linux.com wrote: I've never heard of having a power column per-application, this isn't something the Gnome, KDE, or LXDE task managers do. Shouldn't an application's power usage be linked directly to how much it is making the CPU work? On Wed, Feb 25, 2015 at 4:35 PM, Leif Middelschulte leif.middelschu...@gmail.com wrote: Hi Jeff, Cool to see this! Would be great if it has a column for power usage too. The consumption in average and at the moment. Because that's what matters if you're on the road with your laptop and need to save some battery to keep working. Maybe have a look at powertop's code for help? Cheers, Leif Am 24.02.2015 um 20:27 schrieb Jeff Hoogland jeffhoogl...@linux.com: Spent last night cleaning up some code I started last year. Simple, functional, task manager - Exterminator: http://jeffhoogland.github.io/Exterminator/ -- ~Jeff Hoogland http://jeffhoogland.com/ My Projects on GitHub https://github.com/JeffHoogland -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ~Jeff Hoogland http://jeffhoogland.com/ My Projects on GitHub https://github.com/JeffHoogland -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Deprecating evas_object_event_callback_del() and the likes
Please don't kill _del. A documentation fix or guarantee on what it deletes would be nice[1] (I recall it used to delete the most recently added item that matched). Del allows you to remove a callback without having to keep track of the data pointer, which is useful, if you know the lifecycle of the datapointer is safe. In particular since the name of the callback is a global name it is easy to discover/keep track of, but the data pointer would require extra access. Regards, nash [1] It may be there, in either case, not relevant to the topic at hand. On 10 February 2015 at 09:16, Tom Hacohen tom.haco...@samsung.com wrote: Hey, I'd like to raise another issue which has been bugging me for a while and I was just reminded of thanks to T2077: evas_object_event_callback_del() and the such. The failure cases are not that common, but they can happen. This API is already gone in Eo. So what is it? There are two ways to delete a callback: del() and del_full(). The former accepts type and function, the latter type, function and data pointer. As you can guess from the signature, del() doesn't take the data pointer into account. This means, that this code: add(TYPE1, func1, data); add(TYPE1, func1, other_data); del(TYPE1, func1); is undefined. This for example could manifest if there's a general helper function that can be used as a callback for some common operations (with a different data pointer that controls the behaviour) used by two people controlling the object. A very good example would be a widget adding a callback on itself and edje/the user/elm doing the same. Another good example is if two different parts of the code implement filtering on an entry using callbacks and use the same helper (regex helper?) function with two different data pointers. We are obviously not going to kill this API before EFL 2.0, but it's better I'd like to mark it as deprecated, to at least prevent new usages. We'll have to deal with the newly added warnings as we go, as I suspect there'll be some uses across the EFL/enlightenment (I'll do my best fixing all the ones I can without deep understanding of the code). Any thoughts on the matter? Please don't +1/-1, thoughtful replies or none at all. :) Thanks, Tom. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Windows issue with Eina_Thread type
You don't always need a 64bit number, you need a int which is the size of a pointer. Hence why I suggested uintptr_t (or intptr_t for that matter). On 23 December 2014 at 15:19, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 23 Dec 2014 18:35:20 +0100 (CET) Michelle Legrand michelle.legr...@openwide.fr said: So if I understood correctly, I should replace in src/lib/eina/eina_thread.h: typedef unsigned long int Eina_Thread; by : typedef uintptr_t Eina_Thread; like Nash suggested ? or just unsigned long long - which in any sane world will always be 64bit. Regards, Michelle Le Grand - Mail original - De: Nicolas Aguirre aguirre.nico...@gmail.com À: Enlightenment developer list enlightenment-devel@lists.sourceforge.net Envoyé: Vendredi 19 Décembre 2014 09:03:49 Objet: Re: [E-devel] Windows issue with Eina_Thread type 2014-12-19 3:00 GMT+01:00 Carsten Haitzler ras...@rasterman.com: i'd go for the abi break. votes? +1 -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://www.calaos.fr Blog: http://dev.enlightenment.fr/~captainigloo/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Windows issue with Eina_Thread type
I think the type you want is either a intptr_t or a uintptr_t, an integer the same size[1] as a pointer. Regards, nash [1] Off hand I don't recall if it's defined to be the same size or the same size or larger. Either case works for this On 18 December 2014 at 09:31, Michelle Legrand michelle.legr...@openwide.fr wrote: Hello, I am facing an issue with Enventor on Windows which leads Enventor to crash immediately with a segmentation fault at launch. The error tracked by GDB is in the following assignement in enventor/src/lib/auto_comp.c ( https://git.enlightenment.org/tools/enventor.git/tree/src/lib/auto_comp.c) : ad-init_thread = ecore_thread_run(init_thread_cb, init_thread_end_cb, init_thread_cancel_cb, ad); We found out that this segmentation fault is due to the type Eina_Thread being defined by a unsigned long int which on Windows seems to have an unsuffisant size. The reason is that Windows uses the LLP64 data models as described on http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models. There would be two solutions to correct this problem. One would be to define Eina_Thread as unsigned long long int for Win32 exclusively, or we could use a standard integer type as uint64_t. I would like to have your opinion about this and what would be the best solution to adopt. Regards, Michelle LE GRAND -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH]: Kill my (extremely) old email address.
Just a minor update to authors. From d5d8a2e28415ca0c699c1d6e90a08ea54996b505 Mon Sep 17 00:00:00 2001 From: Brett Nash n...@nash.id.au Date: Sat, 26 Apr 2014 21:55:45 +1000 Subject: [PATCH] Fix my email address --- AUTHORS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AUTHORS b/AUTHORS index 6a0d634..b2121ab 100644 --- a/AUTHORS +++ b/AUTHORS @@ -83,7 +83,7 @@ Evas Carsten Haitzler ras...@rasterman.com Till Adam t...@adam-lilienthal.de Steve Ireland sirel...@pobox.com -Brett Nash n...@fluffyspider.com.au +Brett Nash n...@nash.id.au Tilman Sauerbeck til...@code-monkey.de Corey Donohoe at...@atmos.org Yuri Hudobin glassy_...@users.sourceforge.net -- 1.9.1 -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH]: Kill my (extremely) old email address.
Indeed, I've been in other strange lands. Finally got E back on my desktop, so may be time to clean up some of my old messes and make some more. ;-) On 26/04/14 22:49, Daniel Juyung Seo wrote: Done! Thanks Brett Nash. How are you? It's been so long to see you here. Daniel Juyung Seo (SeoZ) On Sat, Apr 26, 2014 at 9:01 PM, Brett Nash n...@nash.id.au wrote: Just a minor update to authors. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Proxy Image
Definitely a bug, and I'll see if I can take a look at it soon. Do you have a bug # or a reproduction case? Regards, nash [Rising from the dead] Oh, my god, he is alive ! ALIVE ! I'm actually just a good copy of the other me. But no one but the dog down the road notices the difference. Regards, nash -- 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] Proxy Image
Hello, I tested the proxy image for using it. I expected the proxy image is shown whole ,even if the source object is clipped. But if the source object is clipped, the proxy image is clipped too. I want to show the whole copied image regardless of the clip of the source object. I think this request is necessary. Please help me. ok - sorry for the delay. your'e one of my older to get to mails. clipping and proxy/map: clips that are OUTSIDE of an object (outside a smart object for example) should not apply to the rendering of the map buffer proxy uses. i spent a lot of effort in the rendering code to ensure this doesnt happen. for map - which is the same basis for proxy... BUT.. i think they have different render paths... and this may have a bug. right now this needs to get chalked up as a bug. if you have a test case to reproduce - that would be good. and right now... given the size of my backlog... this is going to have to just go on a long list of bugs to fix. one way to put it on my list is to file a bug on trac... another is to send another email here with the reproduction case and i'll mark it and it'll sit in my queue :) Definitely a bug, and I'll see if I can take a look at it soon. Do you have a bug # or a reproduction case? Regards, nash [Rising from the dead] -- 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] evas_filter_software_get() undefined
On Tue, 2011-04-19 at 17:46 +0200, Vincent Torri wrote: Hey evas_filter_software_get() is used in the engine software_generic but is not exported (see its declaration i evas_private.h). Hence undef ref on Windows. we must add EAPI. In that case, is it reasonable to move the declaration in evas_common.h ? It would be a bit strange to be there: it's really part of the internal filter calls, so either leave it, or move it and all the other filter calls. Otherwise it could be moved in to part of the software engine, and use it from there. The latter may be a better call. Any other thoughts, I have no particular attachment to it's current location to be honest? Regards, nash -- 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: raster trunk/evas/src/lib/canvas
On Tue, 2011-04-19 at 18:22 -0700, Enlightenment SVN wrote: Log: oh dear... way too many warnings. added a whole bunch of fixme's too for later. I'll sort out the fixme's shortly. Just to be clear; the warnings are mostly unused params? Because it compiles cleanly for me[1], and my flags are -Wall and -Wextra. However I do set -Wno-sign-compare[2], and -Wno-unused-paramater Regards, nash [1] I checked, multiple times. [2] I do this because of otherwise enums nearly always give you the stupid unsigned vs signed comparison, and C gives you no portable way of avoiding it[3]. [3] The cast both sides isn't portable in the general case. -- 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: raster trunk/evas/src/modules/engines/gl_common/shader
On Wed, 2011-04-20 at 00:12 -0700, Enlightenment SVN wrote: Log: start fixing shader mess. at least add mask compile to scripts. need to do filters. Is there a summary of the method to do this somewhere? Regards, nash -- 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: raster IN trunk: evas/src/lib evas/src/lib/canvas expedite/src/bin
On Wed, 2011-04-20 at 01:13 -0700, Enlightenment SVN wrote: Log: and fix filter api to be consistent with evas.. letalone all of efl. VERB AT END (get/set/whatever) Is there any othere typed getters/setters in EFL? I did the verb_type call, ala OpenGL. nash -- 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: raster IN trunk: evas/src/lib evas/src/lib/canvas expedite/src/bin
On 21/04/2011, at 11:49 AM, Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Thu, 21 Apr 2011 01:09:44 +1000 Brett Nash n...@nash.id.au said: On Wed, 2011-04-20 at 01:13 -0700, Enlightenment SVN wrote: Log: and fix filter api to be consistent with evas.. letalone all of efl. VERB AT END (get/set/whatever) Is there any othere typed getters/setters in EFL? I did the verb_type call, ala OpenGL. off the top of my head, no - but verb goes at end. latin. :) The reason I usually put types at the end is so when you have a language with type inspection (lua/JavaScript) or overloading (c++) the function then becomes foo_set (from foo_set_int) when you do the binding. Hence it (hopefully) leads to a cleaner overall API. It's not a massive issue, but it just feels to me the type is an artifact of c, so should go behind the real method name. Regards, Nash -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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: discomfitor trunk/eina/src/include
On Tue, 2011-04-12 at 20:08 -0700, Enlightenment SVN wrote: Log: class is a reserved word. SPANK SPANK SPANK cedric!!! Are you confusing C and C++ by any chance? Class isn't reserved in C (kr, ansi, or c99). Having said that it's best to avoid it so people can through a c++ compiler at your header I suppose. Not really worth a spank. Regards, nash -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ 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/bin/epp
On Thu, Mar 24, 2011 at 08:43:01PM -0400, Mike Blumenkrantz wrote: LMAO, na don't worry about that...I can break things just as well :P dh good, cuz I'm gonna be insanely busy for the next few weeks and probably won't have time to break anything :/ Don't worry, I have a big set of patches waiting. Regards, nash -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/edje/src/lib
struct _Edje
{
+ Evas_Object *clipper; /* a big rect to clip this Edje to */
+ Evas *evas; /* the Evas this Edje belongs to */
This is a bit dangerous and not recommended as you'd have to keep in
sync. Technically it's fine as they have the same layout, but I'd have
as first field:
You are entirely correct. The reason I did that way (at first) was to
minimise the delta for the change and testing (and I was just happy[1] it
worked first go).
I'll punt it over.
Regards,
nash
[1] For values of happy best described as 'surprised and confused'.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/ensure
PKG_CHECK_MODULES([ELEMENTARY], elementary) +AC_LIBTOOL_DLOPEN you will have the terrible libltdl stuff. You really want it ? oh god no. All I really want is for the autoconf to do that really tricky thing I used to do manually in the makefile... you know put -ldl at the end of link line (which only works on every platform known to man). Whats the magic for that? Just the later line below? nash [who misses the old days, when men where men, women where women, small furry creatures from alpha centauri where small furry creatures from alpha centauri and build systems were makefiles] Vincent +AC_CHECK_LIB([dl], [dlopen], [],AC_ERROR([Usable libdl not found! Apollo port not yet complete.])) AC_OUTPUT(Makefile src/Makefile -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ enlightenment-svn mailing list enlightenment-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Elm fileselector bug
Hello, I just noticed that elm_fileselector_is_save_[sg]et contradict. Set uses: elm_object_disabled_set(wd-filename_entry, !is_save); whereas get uses: return elm_object_disabled_get(wd-filename_entry); I'm happy to patch, just want to check the later one should be: return !elm_object_disabled_get(wd-filename_entry); Or is my brain in reverse. Regards, nash -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk/evas: . src/lib src/lib/canvas src/lib/engines/common src/lib/include src/modules/engines/gl_common/shader src/modules/engines/gl_x11 src/modules/engines/software_ge
On 11/02/2011, at 2:22 PM, Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 07 Feb 2011 12:49:48 +1100 Brett Nash n...@nash.id.au said: you missed lots of other cases. i fixed most that i could find and now the gl engine has 2 abort()'s with fixme: nash in them. the code there will only work with 4 point maps. you made it n points but no code to handle n point maps was put into the patch/commit - can you please fix that? Shall do. Manually remedying missing parches at the moment. I still want to know how I broke git-svn so well. also - where are test cases for the proxy code? eg - expedite? :) how do we even know this feature works at all? I'll push them up on the weekend too. With a fresh checkout first. Regards, nash [Still with paper bag] -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas build failure - fresh checkout
On Tue, 2011-02-08 at 22:08 -0200, Fabiano Fidêncio wrote: On Tue, Feb 8, 2011 at 8:48 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Tue, Feb 8, 2011 at 4:19 PM, Fabiano Fidêncio fabi...@fidencio.org wrote: On Tue, Feb 8, 2011 at 3:14 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Oops. I got the same error with that option. Someone needs to be spanked :( evas_common_map4_rgba was changed to evas_common_map_rgba, with one more parameter (n points) by nash (in r56777). This was fixed by raster in r56805: http://trac.enlightenment.org/e/changeset/56805 Maybe I'm smoking a lot of crack but, at least here, it isn't fixed. Please, see the pastebin and check if you have the same output: http://pastebin.com/SrZZxgYW I'll submit (untested) fix for DirectFB and SDL shortly. Regards, nash -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas build failure - fresh checkout
On Tue, 2011-02-08 at 22:08 -0200, Fabiano Fidêncio wrote: On Tue, Feb 8, 2011 at 8:48 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Tue, Feb 8, 2011 at 4:19 PM, Fabiano Fidêncio fabi...@fidencio.org wrote: On Tue, Feb 8, 2011 at 3:14 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Oops. I got the same error with that option. Someone needs to be spanked :( evas_common_map4_rgba was changed to evas_common_map_rgba, with one more parameter (n points) by nash (in r56777). This was fixed by raster in r56805: http://trac.enlightenment.org/e/changeset/56805 Maybe I'm smoking a lot of crack but, at least here, it isn't fixed. Please, see the pastebin and check if you have the same output: http://pastebin.com/SrZZxgYW Try now. Mail me directly if if doesn't work. Regards, nash -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Enlightenment Error
On Mon, 2011-02-07 at 16:59 +0900, Daniel Juyung Seo wrote: Hello, Whiling using E17 as my Desktop Manager, I got 'Enlightenment Error' popup and my system got crashed. I can't go back to my E17. What can I do here? For more information, I'm using latest E17 from SVN. I updated SVN this morning and I failed building evas due to evas build error. Let me know if you have any reason to suspect it's evas. The evas build should be fixed now (well it works for me anyway)[1]. Eina, eet are built and installed though. Any ideas? Without a backtrace or anything, it's hard to say. Can you attach a debugger at the console or via ssh and see where it is dead? Regards, nash [1] And in future big commits will be patched manually by me. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk/evas: . src/lib src/lib/canvas src/lib/engines/common src/lib/include src/modules/engines/gl_common/shader src/modules/engines/gl_x11 src/modules/engines/software_ge
It's there. Unfortunately it is a different commit. Regards, nash On Sun, 2011-02-06 at 19:21 -0500, Mike Blumenkrantz wrote: On Mon, 7 Feb 2011 00:56:46 +0100 (CET) Vincent Torri vto...@univ-evry.fr wrote: On Sun, 6 Feb 2011, Enlightenment SVN wrote: Log: Support for Proxy Objects (and others) Proxy objects allow you to use another image as the source of an image. Essentially allowing the same object to be rendered multiple times. One object (the source) is the original, each additional 'copy' is an image with evas_object_image_source_set. This is complete. Also add partially working arbitrary maps, and arbitrary clipping. Unfortunately both have some issues yet to be resolved (waiting on the next feature to get merged together). Author: nash Date: 2011-02-06 15:52:17 -0800 (Sun, 06 Feb 2011) New Revision: 56777 Trac: http://trac.enlightenment.org/e/changeset/56777 Added: trunk/evas/src/modules/engines/gl_common/shader/.gitignore trunk/evas/src/modules/engines/gl_common/shader/img_mask_frag.h trunk/evas/src/modules/engines/gl_common/shader/img_mask_frag.shd trunk/evas/src/modules/engines/gl_common/shader/img_mask_vert.h trunk/evas/src/modules/engines/gl_common/shader/img_mask_vert.shd Modified: trunk/evas/.gitignore trunk/evas/src/lib/Evas.h trunk/evas/src/lib/canvas/evas_map.c trunk/evas/src/lib/canvas/evas_object_image.c trunk/evas/src/lib/canvas/evas_object_proxy.c trunk/evas/src/lib/canvas/evas_render.c trunk/evas/src/lib/engines/common/evas_convert_colorspace.c trunk/evas/src/lib/engines/common/evas_map_image.c trunk/evas/src/lib/engines/common/evas_map_image.h trunk/evas/src/lib/engines/common/evas_pipe.h trunk/evas/src/lib/include/evas_common.h trunk/evas/src/lib/include/evas_private.h trunk/evas/src/modules/engines/gl_x11/evas_engine.c trunk/evas/src/modules/engines/software_generic/evas_engine.c Modified: trunk/evas/.gitignore === --- trunk/evas/.gitignore 2011-02-06 23:51:58 UTC (rev 56776) +++ trunk/evas/.gitignore 2011-02-06 23:52:17 UTC (rev 56777) @@ -7,6 +7,7 @@ Makefile Makefile.in *.so +.*.sw[po] /README /aclocal.m4 /autom4te.cache/ @@ -25,3 +26,5 @@ /ltmain.sh /missing /stamp-h1 +tags +cscope.out Modified: trunk/evas/src/lib/Evas.h === --- trunk/evas/src/lib/Evas.h 2011-02-06 23:51:58 UTC (rev 56776) +++ trunk/evas/src/lib/Evas.h 2011-02-06 23:52:17 UTC (rev 56777) @@ -164,7 +164,7 @@ EVAS_COLORSPACE_YCBCR422P601_PL, /** YCbCr 4:2:2 Planar, ITU.BT-601 specifications. The data poitned to is just an array of row pointer, pointing to the Y rows, then the Cb, then Cr rows */ EVAS_COLORSPACE_YCBCR422P709_PL,/** YCbCr 4:2:2 Planar, ITU.BT-709 specifications. The data poitned to is just an array of row pointer, pointing to the Y rows, then the Cb, then Cr rows */ EVAS_COLORSPACE_RGB565_A5P, /** 16bit rgb565 + Alpha plane at end - 5 bits of the 8 being used per alpha byte */ - EVAS_COLORSPACE_GRY8 /** 8bit grayscale */ + EVAS_COLORSPACE_GRY8, /** 8bit grayscale */ remove that comma, please (same below) Vincent I did it for him in case he's away from email. On another note, changelog? -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk/evas: . src/lib src/lib/canvas src/lib/engines/common src/lib/include src/modules/engines/gl_common/shader src/modules/engines/gl_x11 src/modules/engines/software_ge
On Mon, 2011-02-07 at 10:25 +0900, Carsten Haitzler wrote: On Mon, 07 Feb 2011 11:38:51 +1100 Brett Nash n...@nash.id.au said: what'd be awesome is.. if your commit didnt totally break evas building at all. have u tried to update and build?: evas_object_proxy.c: In function ‘_proxy_render’: evas_object_proxy.c:427: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:428: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:429: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:430: error: ‘RGBA_Map_Point’ has no member named ‘x3’ evas_object_proxy.c:430: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:431: error: ‘RGBA_Map_Point’ has no member named ‘y3’ evas_object_proxy.c:431: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c: In function ‘_proxy_can_map’: evas_object_proxy.c:607: warning: unused parameter ‘obj’ make[5]: ***[evas_object_proxy.lo] Error 1 make[5]: Leaving directory `/home/raster/C/svn/ssh +svn/e/trunk/evas/src/lib/canvas' Yeah. Fixing now. My bad. I'm not sure what I did wrong, but my pre-commit worked, after the commit it broke horribly. And I though I deleted that file... Regards, nash -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk/evas: . src/lib src/lib/canvas src/lib/engines/common src/lib/include src/modules/engines/gl_common/shader src/modules/engines/gl_x11 src/modules/engines/software_ge
On Mon, 2011-02-07 at 12:27 +1100, Brett Nash wrote: On Mon, 2011-02-07 at 10:25 +0900, Carsten Haitzler wrote: On Mon, 07 Feb 2011 11:38:51 +1100 Brett Nash n...@nash.id.au said: what'd be awesome is.. if your commit didnt totally break evas building at all. have u tried to update and build?: evas_object_proxy.c: In function ‘_proxy_render’: evas_object_proxy.c:427: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:428: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:429: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:430: error: ‘RGBA_Map_Point’ has no member named ‘x3’ evas_object_proxy.c:430: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c:431: error: ‘RGBA_Map_Point’ has no member named ‘y3’ evas_object_proxy.c:431: error: invalid operands to binary (have ‘double’ and ‘int’) evas_object_proxy.c: In function ‘_proxy_can_map’: evas_object_proxy.c:607: warning: unused parameter ‘obj’ make[5]: ***[evas_object_proxy.lo] Error 1 make[5]: Leaving directory `/home/raster/C/svn/ssh +svn/e/trunk/evas/src/lib/canvas' Yeah. Fixing now. My bad. I'm not sure what I did wrong, but my pre-commit worked, after the commit it broke horribly. And I though I deleted that file... Okay: I've fixed the build issue, once again my apologies. I'll try and work out what happened to half my patches this morning, and get proxy working happily. Regards, nash -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/TMP/st/elementary/src/lib
On Thu, 2011-01-13 at 15:04 -0800, Enlightenment SVN wrote: Log: Elm: Entry: cno: Add support for using text only in entries. By default it's text only for single line entries (you can toggle it back on if you want to). Otherwise images are enabled for multiline entries. I realised I forgot to credit 장효영/Hyoyoung Chang hyoyoung.ch...@samsung.com with this part of the patch set. There were some tweaks here, but the original patch is his (the typo's are mine for instance). Regards, nash -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Recent(-ish) changes to elm genlist? elm.swallow.icon
Hello, So I have a simple app the displays a list of things in a genlist in a format vaguely like: Key value Where key is the main item, and value is stored using a .icon_get callback. In it I do code along the lines of: if (strcmp(elm.swallow.end,part)) != 0) return NULL; o = elm_label_add(obj); elm_label_label_set(o, calculated_value(yadda, yadda)); evas_object_show(o); return o; This used to work, but with a recent update it stopped working. If I chance elm.swallow.end: to elm.swallow.icon it works fine (albeit backwards value: key). Unfortunately I can't find any examples using a label in the end position, but it used to work (I have a screenshot, so I know I'm not crazy ;-) Anyone have any ideas what I need to do to make it work, or an alternate suggestion to make the equivalent work? Regards, nash -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ 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/lib
sure, as i mentioned them when i compiled with suncc. Otherwise, with gcc, from http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options -Wpointer-arith Warn about anything that depends on the .size of. a function type or of void. GNU C assigns these types a size of 1, for convenience in calculations with void * pointers and pointers to functions. In C++, warn also when an arithmetic operation involves NULL. This warning is also enabled by -pedantic. so not enabled with one of your flags. Now that is strange. I swear that used to part of -Wextra, although the documentation indicates I am mistaken (a couple of 4's and 3's checked there). I personally despise that gcc extension. Regards, nash -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ 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/lib
I don't understand why raster is so reluctant in having them. Especially if we enable them only during a development cycle, and not in a release. Indeed... several projects I work with enable tons of -W when configured with --enable-maintainer-mode (even -Werror). I don't see a point against doing this. There are a few points. First if you are on a different arch to the maintainers suddenly you can find yourself in warning hell. Similarly different compiler versions have the same effect[1]. -Werror is even worse for this (especially when you are adding a new feature and you know what/why a warning is but you don't want to fix it for some reason). As a person who always uses a 64bit machine + more warnings the most, adding a -Werror is a nightmare for me. Third reason is it messes with peoples existing warning flags. For instance I use[2][3]: -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter A -Wall at the end resets my other flags, which is really annoying. However the main problem is the simple philosophical one. Don't tell people how to code. Don't tell them what editor, don't tell them what compiler, don't tell them what architecture to use, don't tell them what C flags. Having said that: People with no CFLAGS should probably be given a default set, and suggestions of CFLAGS to use is a good idea. Regards, nash [1] I was the first in my company to upgrade to gcc 4 at the time with 'mandatory' CFLAGS, and found myself in hundreds of warnings when the previous version was warning free. [2] I'll probably be adding void arithmetic to this soon. [3] I used to have more. I turned some off due to too many warnings elsewhere. -- 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] Proposal Font Set Size only
On Thu, 2010-12-09 at 09:31 -0200, Iván Briano (Sachiel) wrote: 2010/12/9 Brett Nash n...@nash.id.au: Hello, Quick proposal: evas_object_text_font_set(Evas_Object *text, const char *font, Evas_Font_Size size)' Currently rejects a NULL font or non-positive size. So calling: evas_object_text_font_set(label, NULL, 12); is an (expensive) no-op. I propose that calling it with a NULL font just changes the size, using the current font. What about calling it with a font and size = 0? Does it make sense to have a 0 sized font, or should it keep the current one while setting the new font? Assuming it's not doing that already. Sorry if I wasn't clear. Currently passing in _either_ a NULL font or a 0 size font just causes the function to fail. And you are correct that a 0 point font is down right silly. So yes, a call to set the font, and NOT the size would also work. My experience in past has been setting the font size is common, but changing the font without changing the size is less common. But that may be conceit to the way I program ;-) Regards, nash -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ 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
+/* Why do this? Well PATH_MAX may vary from when eina itself is compiled + * to when the app using eina is compiled. exposing the path buffer below + * cant safely and portably vary based on how/when you compile. it should + * always be the same for both eina inside ANd for apps outside that use eina + * so define this ti 8192 minus ther other struct bits so that + * Eina_File_Direct_Info can take a nice round 2 pages. */ +#define EINA_PATH_MAX (8192 - (sizeof(size_t) * 3) - sizeof(Eina_File_Type)) Doesn't this logic only make sense if: - You use external tracking for your mallocs, or - You use a pool allocator? Since neither is true in the general case you've just made EINA_PATH_MAX incompatible with every path max on the planet, in return for a gain that will won't happen for anyway. Considering the only time it's used is INSIDE another structure... There is never a gain. So the result is more complex, always incompatible, and never a gain. Regards, nash -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Proposal Font Set Size only
Hello, Quick proposal: evas_object_text_font_set(Evas_Object *text, const char *font, Evas_Font_Size size)' Currently rejects a NULL font or non-positive size. So calling: evas_object_text_font_set(label, NULL, 12); is an (expensive) no-op. I propose that calling it with a NULL font just changes the size, using the current font. FROs: (Frequently Raised Objections): So who is going to write this magical and revolutionary code? If people think it's a good idea, I'll do the patch _and_ update the currently non-existent documentation. How does this affect current code? Code currently calling it with NULL args and expecting nothing to happen will break. This code should be taken out an shot. Well behaved code will not be affected. And this helps how? Changing font size no longer needs to do a font_get followed by a font_set. Is there another way? Sure; add a specific font_size_set call, but why add an extra call when an obvious extension to the existing API will do the job. Could we do it for Evas 1.1 instead? Yep, in which case I'll write the patch, and apply it later. Is this an argument? No, an argument is a connected series of statements intended to establish a proposition. Regards, nash -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] ecore main loop fd_handlers_to_call list optimization
Hi Mike, Excuse my stupidity, but I don't suppose you could put this as a table with something like: Time %Dropped Original Ecore Cur Ecore + MikeM I don't fully understand your data, but your argument seems to be that the final patch from mike continues to: - Improves Performance - Reduces % of connections dropped So I'm not sure what the issue with accepting a small patch to change 1 week old. Except the for the old e-devel list of rejecting small patches, but letting the big ones sail straight through. Regards, nash , This change absolutely must go through before 1.0 if we want to have a respectable main loop, and the following data will prove it. This data can easily be replicated using the client/server_bench.c files in ecore/examples. ecore revision 54616: === 25000 fd test: Connection lost! #10400! ^C Time elapsed for 25000 connections: 371.606825 seconds # specimen experiment time starting time ending time 1 645014268 3993714 649007982 ./bench_client 4.38s user 0.70s system 1% cpu 6:11.76 total (Note: at this point I killed it because after 10400 fds, ecore stopped and no longer processed any connections) 1 fd test: Connection lost! #8933! ^C Time elapsed for 1 connections: 443.156038 seconds # specimen experiment time starting time ending time 1 746600745 3902720 750503465 ./bench_client 0.55s user 0.28s system 0% cpu 7:23.28 total (Note: at this point I killed it because after 8933 fds, ecore stopped and no longer processed any connections) 5000 fd test: Time elapsed for 5000 connections: 45.284662 seconds # specimen experiment time starting time ending time 1 259416526 3992216 263408742 ./bench_client 0.14s user 0.16s system 0% cpu 45.331 total 2000 fd test: Time elapsed for 2000 connections: 3.086964 seconds # specimen experiment time starting time ending time 1 101628352 3916119 105544471 ./bench_client 0.05s user 0.07s system 3% cpu 3.107 total 1000 fd test: Time elapsed for 1000 connections: 0.048472 seconds # specimen experiment time starting time ending time 1 472029003945319 51148219 ./bench_client 0.02s user 0.03s system 96% cpu 0.060 total A note about the above results: The numbers for the first two tests were the best that I could achieve. I ran both tests multiple times to attempt the highest number of connections possible. When ecore showed no further connections after a full minute, I ended the test. The reason why the 25k fd test achieves more connections is because it sends more attempts in the same amount of time, allowing for more to be successfully picked up (like throwing a bunch of marbles at something far away, only a few will hit). Here are the exact same tests once again. ecore revision HEAD: === 25000 fd test with printf disabled: Time elapsed for 25000 connections: 1.141623 seconds # specimen experiment time starting time ending time 1 1136243319 3866130 1140109449 ./bench_client 0.43s user 0.91s system 98% cpu 1.356 total 25000 fd test: Time elapsed for 25000 connections: 3.439958 seconds # specimen experiment time starting time ending time 1 -892811351 3977067 -34284 ./bench_client 0.44s user 0.94s system 37% cpu 3.651 total 1 fd test: Time elapsed for 1 connections: 0.479854 seconds # specimen experiment time starting time ending time 1 470182903 3876967 474059870 ./bench_client 0.17s user 0.38s system 97% cpu 0.567 total 5000 fd test: Time elapsed for 5000 connections: 0.247735 seconds # specimen experiment time starting time ending time 1 237503799 3889656 241393455 ./bench_client 0.10s user 0.18s system 95% cpu 0.295 total 2000 fd test: Time elapsed for 2000 connections: 0.096664 seconds # specimen experiment time starting time ending time 1 941698423970562 98140404 ./bench_client 0.04s user 0.07s system 95% cpu 0.119 total 1000 fd test: Time elapsed for 1000 connections: 0.047393 seconds # specimen experiment time starting time ending time 1 468595923859111 50718703 ./bench_client 0.02s user 0.04s system 97% cpu 0.060 total I think the data here speaks for itself, and this is only showing current svn HEAD. 25000 fd test with Mike's newest patch: Time elapsed for 25000 connections: 1.131604 seconds # specimen experiment time starting time ending time 1 1127458798 3833513 1131292311 ./bench_client 0.43s user 0.91s system 99% cpu 1.345 total Again, a clear, though smaller, improvement. Regardless of whether this specific patch makes it into 1.0, our policy here should definitely not be how fast can we revert the work on ecore?, it should be how fast and efficiently can we test/fix
Re: [E-devel] E SVN: bdilly trunk/TMP/st/elementary/src/lib
On Mon, 18 Oct 2010 11:15:59 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: Fixes for clang warnings Author: bdilly Date: 2010-10-18 11:15:59 -0700 (Mon, 18 Oct 2010) New Revision: 53576 Modified: trunk/TMP/st/elementary/src/lib/elm_cnp_helper.c trunk/TMP/st/elementary/src/lib/elm_menu.c Modified: trunk/TMP/st/elementary/src/lib/elm_cnp_helper.c === --- trunk/TMP/st/elementary/src/lib/elm_cnp_helper.c 2010-10-18 18:05:22 UTC (rev 53575) +++ trunk/TMP/st/elementary/src/lib/elm_cnp_helper.c 2010-10-18 18:15:59 UTC (rev 53576) @@ -1160,7 +1160,7 @@ int i; /* Skip it */ - if (enter-num_types == 0 || enter-types == NULL) return true; + if (!enter || !enter-num_types || !enter-types) return EINA_TRUE; The function argument should be annotated here, it's an appropriate place for a not null as it's a callback. If ecore is sending NULL to it's callbacks, all bets are off. insert standard automated tools disclaimer regarding symptom and problem Regards, nash -- 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: lucas trunk/TMP/st/elementary/src/lib
Modified: trunk/TMP/st/elementary/src/lib/elm_thumb.c
===
--- trunk/TMP/st/elementary/src/lib/elm_thumb.c 2010-10-18
23:19:13 UTC (rev 53587) +++
trunk/TMP/st/elementary/src/lib/elm_thumb.c 2010-10-19
02:17:37 UTC (rev 53588) @@ -624,11 +624,8 @@ ELM_CHECK_WIDTYPE(obj,
widtype); Widget_Data *wd = elm_widget_data_get(obj);
- if (setting ELM_THUMB_ANIMATION_START ||
- setting = ELM_THUMB_ANIMATION_LAST)
- {
+ if (setting = ELM_THUMB_ANIMATION_LAST)
return;
- }
wd-anim_setting = setting;
if (setting == ELM_THUMB_ANIMATION_LOOP)
I've seen this warning dozens of times, but I didn't think it was safe
to remove.
My understanding (C90 knowledge here) is that unfortunately
the enum may be signed or unsigned, C doesn't guarantee either unless
you have a value that can only be represented by signed or unsigned
values. (Be careful here, the enumeration _values_ are 'int', the
enumeration itself may not be).
So this means a different compiler or a different architecture (say one
that doesn't do unsigned numbers well) may generate code as signed,
meaning the entire test could now be invalidated.
I also don't know a way to shut up GCC in a sane manner, aside from
a swath of casts: which is also extremely ugly.
Regards,
nash
--
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] beta EFL 1.0.0???
Should be fixed now... Along with some other plain text issues. Also fixed the stupid case that it will ask for a format that it can't handle. Regards, nash On Sun, 26 Sep 2010 14:36:22 +0200 Tom Hacohen tom.haco...@partner.samsung.com wrote: On Sun, 2010-09-26 at 21:28 +0900, Carsten Haitzler wrote: elm_cnp_helper.c: Atom text/html matches elm_cnp_helper.c: Sending request for text/html elm_cnp_helper.c: selection notify callback: 3 elm_cnp_helper.c: Target is text/html Ignored: No handler! No idea what's wrong, I wish someone else would test it as well. The only one working on elm_cnp lately was nash iirc, but it can be anyone... (maybe even something outside of elm broke it, no idea). -- Tom. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] beta EFL 1.0.0???
No idea, it just doesn't work for me anymore (just noticed), I get: elm_cnp_helper.c: selection notify callback: 3 elm_cnp_helper.c: Target is TARGETS elm_cnp_helper.c: Found something: TARGETS elm_cnp_helper.c: text/uri 605 elm_cnp_helper.c: text/uri-list 526 elm_cnp_helper.c: text/x-vcard 720 elm_cnp_helper.c: image/png 606 elm_cnp_helper.c: image/jpeg 607 elm_cnp_helper.c: application/x-elementary-markup 608 elm_cnp_helper.c: text/html;charset=utf-8 609 elm_cnp_helper.c: text/html 529 elm_cnp_helper.c: Atom text/html matches elm_cnp_helper.c: Sending request for text/html elm_cnp_helper.c: selection notify callback: 3 elm_cnp_helper.c: Target is text/html Ignored: No handler! No idea what's wrong, I wish someone else would test it as well. The only one working on elm_cnp lately was nash iirc, but it can be anyone... (maybe even something outside of elm broke it, no idea). Taking a look now. But then again it's not part of the beta anyway ;-) Regards, nash -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/TMP/st/elementary/src/lib
No, that's just backwards.
I contribute to multiple projects, I don't want to have to set up
multiple vim rcs just to edit e files. And I'm sure as hell not going
to convert multiple groups coding standards (if so, E loses BTW).
_IF_ moodelines were significantly different between different versions
of vim, it may be an issue, but really it's not. Modelines means I can
just open up a file and edit without futzing around working out the
appropriate coding standard.
Especially since maintaining modelines to follow the one true standard
is really easy: A perl oneliner can update all the modelines in a
porject _really_ easily.
Keeping a central 'this is the correct modeline' would be nice.
Regards,
nash
On Mon, 20 Sep 2010 08:07:40 -0300
Lucas De Marchi lucas.demar...@profusion.mobi wrote:
On Sat, Sep 18, 2010 at 11:30 PM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Modified: trunk/TMP/st/elementary/src/lib/Elementary.h.in
===
--- trunk/TMP/st/elementary/src/lib/Elementary.h.in 2010-09-19
02:28:09 UTC (rev 52446) +++
trunk/TMP/st/elementary/src/lib/Elementary.h.in 2010-09-19
02:30:14 UTC (rev 52447) @@ -1,6 +1,6 @@ /*
*
- * vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
+ * vim:ts=8:sw=3:sts=3:expandtab:cino=5n-2f0^-2{2(0W1st0
Please, don't do this. This is the right vim modeline, but putting it
on each file will just lead to different vim configurations spread all
over svn. So, keep it in your editor's configuration ($HOME/.vimrc or
$HOME/.vim/ftplugin/c.vim or whatever).
I remember that some time ago I removed all vim modelines... :-\
Lucas De Marchi
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas utf8 functions: Deprecated or entirely removed.
So there are these declerations in evas_font.h: EINA_DEPRECATED EAPI int evas_common_font_utf8_get_next (const unsigned char *buf, int *iindex); EINA_DEPRECATED EAPI int evas_common_font_utf8_get_prev (const unsigned char *buf, int *iindex); EINA_DEPRECATED EAPI int evas_common_font_utf8_get_last (const unsigned char *buf, int buflen); EINA_DEPRECATED EAPI int evas_common_font_utf8_get_len (const unsigned char *buf); Yes, I realise they are deprecated... but shouldn't they you know... exist: aware:~Evas % grep evas_common_font_utf8_ **/*.c src/lib/canvas/evas_object_textblock.c: * ch = evas_common_font_utf8_get_next((unsigned char *)str, twrap); aware:~Evas % (the one match is in a comment BTW) Regards, nash -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Elm Thumb and ifdef
So I just found this define in Elementary.h. #ifdef ELM_ETHUMB EAPI Ethumb_Client *elm_thumb_ethumb_client_get(void); #else EAPI void *elm_thumb_ethumb_client_get(void); #endif How are you supposed to use it in an application without an #ifdef? Well I suppose you could declare your pointer as a void *, and go from there, but then we kill the need for the #ifdef in Elm.h. Otherwise if you need an ifdef in the application anyway, why not just get rid of the API call entirely when ifdefed out? What is even worse of course is the application needs an ifdef around the type decleration _or_ always uses a void pointer? Suggestions: - change it to always return NULL - change it to always return struct _Ethumb_Client * (since opaque structures don't need to be declared? Regards, nash -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elm Thumb and ifdef
#ifdef ELM_ETHUMB EAPI Ethumb_Client *elm_thumb_ethumb_client_get(void); #else EAPI void *elm_thumb_ethumb_client_get(void); #endif How are you supposed to use it in an application without an #ifdef? Well I suppose you could declare your pointer as a void *, and go from there, but then we kill the need for the #ifdef in Elm.h. Otherwise if you need an ifdef in the application anyway, why not just get rid of the API call entirely when ifdefed out? What is even worse of course is the application needs an ifdef around the type decleration _or_ always uses a void pointer? Suggestions: - change it to always return NULL - change it to always return struct _Ethumb_Client * (since opaque structures don't need to be declared? Regards, nash Hi You can compile elementary without EThumb library support, so in this case you maybe have not Ethumb.h present and Ethumb_Client is unknown. Yeah I got that bit. Please read my email again: Do you see the issue? To use this API in an application I need to either use an #ifdef thereby defeating the purpose of the #ifdef/#else combo in elm.h Or I need t to use only a void * as my type. The issue needs to be fixed. It's wrong. There is a small error in my 2 suggestions: the first should be: - Change it to always return void * Regards, nash -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk: TMP/st/elementary/src/lib ecore/src/lib/ecore_x
On Mon, 13 Sep 2010 08:28:12 -0300 Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Mon, Sep 13, 2010 at 6:16 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Add a semicolon. GCC: This ones for you. Where's the semicolon??!? Well if you pasted the patch: - const void *data) + const void *data); Right there. But yes, I committed another file by mistake as well. Regards, nash -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/eio/src/lib
On Mon, 13 Sep 2010 06:44:24 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: * eio: callback are allowed to modify their own data. Don't know how I wrote this non sense. That's easy: C is stupid ;-) But a small suggestion: Maybe cast once when you assign to async-ls.common.data. That way you only have one cast (although it means you need to make it clear it's user data in the structure there). Regards, nash -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/eio/src/lib
On Mon, 13 Sep 2010 15:57:05 +0200 Cedric BAIL cedric.b...@free.fr wrote: But a small suggestion: Maybe cast once when you assign to async-ls.common.data. That way you only have one cast (although it means you need to make it clear it's user data in the structure there). Nah, the idea of this const is to prevent the code in Eio to modify data. I want it in my structure to give a chance to the compiler to spank me before it's too late. Ahh... but it's a void pointer, you can't write through it to the user data without a cast (or assignment to another structure). And now you have the habit of casting all the const void *s anyway, so you'd probably just shoosh it automatically. But I just hate casts ;-) Regards, nash -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: morlenxus trunk/E-MODULES-EXTRA/wlan/src
On Thu, 09 Sep 2010 23:32 -0300, Fabiano Fidêncio fiden...@profusion.mobi wrote: On Thu, Sep 9, 2010 at 11:51 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: fix recent menu api break Still broken here! SEGV when click with mouse's right button. At least for iBar, iBox, mixer. econnman, temperature, cpu, places ... Can anyone confirm? Make sure you get carstens most recent commit 52119. We tracked down the same issue here, and fixed with that revision. Regards, nash -- Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/TMP/st/elementary/src/lib
I'm sort of changing the stuff in elm_photo with a number of FIXMEs and
hard coded numbers linking
in cnp too.
Maybe -Wno-unused-parameter?
Regards,
nash
On Thu, 09 Sep 2010 12:39 -0700, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
some -Wall -Wextra warning cleanups.
elm_cnp_helper.c warnings were not fixed as they look like
implementation nash will do soon.
Author: barbieri
Date: 2010-09-09 12:39:30 -0700 (Thu, 09 Sep 2010)
New Revision: 52102
Modified:
trunk/TMP/st/elementary/src/lib/elm_config.c
trunk/TMP/st/elementary/src/lib/elm_entry.c
trunk/TMP/st/elementary/src/lib/elm_photo.c
Modified: trunk/TMP/st/elementary/src/lib/elm_config.c
===
--- trunk/TMP/st/elementary/src/lib/elm_config.c2010-09-09
19:35:53 UTC (rev 52101)
+++ trunk/TMP/st/elementary/src/lib/elm_config.c2010-09-09
19:39:30 UTC (rev 52102)
@@ -30,7 +30,6 @@
#define ATOM_COUNT 5
static Ecore_X_Atom _atom[ATOM_COUNT];
static Ecore_X_Atom _atom_config = 0;
-static Ecore_X_Atom _atom_config_specific = 0;
static const char *_atom_names[ATOM_COUNT] =
{
ENLIGHTENMENT_SCALE,
Modified: trunk/TMP/st/elementary/src/lib/elm_entry.c
===
--- trunk/TMP/st/elementary/src/lib/elm_entry.c 2010-09-09 19:35:53 UTC
(rev 52101)
+++ trunk/TMP/st/elementary/src/lib/elm_entry.c 2010-09-09 19:39:30 UTC
(rev 52102)
@@ -1274,7 +1274,7 @@
static Eina_Bool
-_drag_drop_cb(void *data, Evas_Object *obj, Elm_Drop_Data *drop)
+_drag_drop_cb(void *data __UNUSED__, Evas_Object *obj, Elm_Drop_Data
*drop)
{
Widget_Data *wd;
Eina_Bool rv;
Modified: trunk/TMP/st/elementary/src/lib/elm_photo.c
===
--- trunk/TMP/st/elementary/src/lib/elm_photo.c 2010-09-09 19:35:53 UTC
(rev 52101)
+++ trunk/TMP/st/elementary/src/lib/elm_photo.c 2010-09-09 19:39:30 UTC
(rev 52102)
@@ -107,7 +107,7 @@
}
static void
-_mouse_down(void *data, Evas *e, Evas_Object *obj, void *event_info)
+_mouse_down(void *data, Evas *e __UNUSED__, Evas_Object *obj __UNUSED__,
void *event_info __UNUSED__)
{
Widget_Data *wd = elm_widget_data_get(data);
@@ -117,7 +117,7 @@
}
static void
-_mouse_up(void *data, Evas *e __UNUSED__, Evas_Object *obj, void
*event_info __UNUSED__)
+_mouse_up(void *data, Evas *e __UNUSED__, Evas_Object *obj __UNUSED__,
void *event_info __UNUSED__)
{
Widget_Data *wd = elm_widget_data_get(data);
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: davemds trunk/TMP/st/elementary/src/bin
On Thu, 09 Sep 2010 01:09 +0200, Dave Andreoli d...@gurumeditation.it wrote: elementary_test Animation elementary_test Box Vert 2 will open the given test on startup... saving you LOTS of time ;) If you think this is too hackish feel free to revert, or just ask me to do so. It's gold. A simple change that should have been there ages ago really ;-) Well done keep it. Regards, nash -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] fixing typos
package-name-doesnt-match-soname-package-name-doesn't-match-soname package-name-doesnt-match-sonames-package-name-doesn't-match-sonames That smells more like some sort of symbol rather than a typo. Regards, nash -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk: TMP/st/elementary TMP/st/elementary/src/bin TMP/st/elementary/src/edje_externals TMP/st/elementary/src/lib ecore/src/lib/ecore_x/xlib edje edje/src/lib enlil/doc
Gah.
didn't mean to merge all this all at once.
For peoples information big changes related to freezy things:
- Add some extra cursors to edje:
- 2 for Input methods: This is required to do CJK input
- 2 for general users: Needed for DND (well 1 is, add 2 anyway)
- Add a new call to edje to allow the cursor to positioned from x,y
coords
(needed for Drag and drop)
- Remove some wacky consts
- Add a return value to a one path
- some doco on a function i just got tripped on
Minor stuff:
- ELM DND stuff (provisional)
- .gitignores all over
Let me know if you need some any anything else in particular.
regards,
nash
On Mon, 06 Sep 2010 23:56 -0700, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Merge branch 'elmdnd'
Conflicts:
trunk/TMP/st/elementary/.gitignore
Author: nash
Date: 2010-09-06 23:56:16 -0700 (Mon, 06 Sep 2010)
New Revision: 51935
Added:
trunk/TMP/st/elementary/src/bin/test_drag.c trunk/edje/.gitignore
trunk/enlil/doc/.gitignore
Removed:
trunk/enlil/doc/Makefile.in
Modified:
trunk/TMP/st/elementary/.gitignore
trunk/TMP/st/elementary/src/bin/Makefile.am
trunk/TMP/st/elementary/src/bin/test.c
trunk/TMP/st/elementary/src/bin/test_entry.c
trunk/TMP/st/elementary/src/bin/test_gengrid.c
trunk/TMP/st/elementary/src/edje_externals/elm_notify.c
trunk/TMP/st/elementary/src/lib/elm_cnp_helper.c
trunk/TMP/st/elementary/src/lib/elm_entry.c
trunk/TMP/st/elementary/src/lib/elm_priv.h
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_drawable.c
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_selection.c
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window.c
trunk/edje/src/lib/Edje.h trunk/edje/src/lib/edje_cache.c
trunk/edje/src/lib/edje_entry.c trunk/edje/src/lib/edje_private.h
trunk/edje/src/lib/edje_util.c
Modified: trunk/TMP/st/elementary/.gitignore
===
--- trunk/TMP/st/elementary/.gitignore 2010-09-06 23:36:40 UTC (rev
51934)
+++ trunk/TMP/st/elementary/.gitignore 2010-09-07 06:56:16 UTC (rev
51935)
@@ -1,5 +1,5 @@
+*.lo
*.o
-*.lo
*.la
.libs
.deps
@@ -30,3 +30,14 @@
/ltmain.sh
/missing
/stamp-h1
+core
+cscope.out
+doc/elementary.dox
+elementary.spec
+m4/libtool.m4
+m4/ltoptions.m4
+m4/ltsugar.m4
+m4/ltversion.m4
+m4/lt~obsolete.m4
+src/lib/Elementary.h
+tags
Modified: trunk/TMP/st/elementary/src/bin/Makefile.am
===
--- trunk/TMP/st/elementary/src/bin/Makefile.am 2010-09-06 23:36:40 UTC
(rev 51934)
+++ trunk/TMP/st/elementary/src/bin/Makefile.am 2010-09-07 06:56:16 UTC
(rev 51935)
@@ -80,7 +80,8 @@
test_floating.c \
test_launcher.c \
test_anim.c \
-test_calendar.c
+test_calendar.c \
+test_drag.c
elementary_test_LDADD = $(top_builddir)/src/lib/libelementary.la
@ELEMENTARY_EWEATHER_LIBS@
elementary_test_LDFLAGS =
Modified: trunk/TMP/st/elementary/src/bin/test.c
===
--- trunk/TMP/st/elementary/src/bin/test.c 2010-09-06 23:36:40 UTC
(rev 51934)
+++ trunk/TMP/st/elementary/src/bin/test.c 2010-09-07 06:56:16 UTC
(rev 51935)
@@ -81,6 +81,9 @@
void test_launcher3(void *data, Evas_Object *obj, void *event_info);
void test_anim(void *data, Evas_Object *obj, void *event_info);
+void test_drag_source(void *data, Evas_Object *obj, void *event_info);
+void test_drag_dest(void *data, Evas_Object *obj, void *event_info);
+void test_drag_genlist(void *data, Evas_Object *obj, void *event_info);
struct elm_test
{
@@ -202,6 +205,10 @@
tests = NULL;
#define ADD_TEST(name_, cb_) elm_test_add(tests, name_, cb_)
+ ADD_TEST(Drag Source, test_drag_source);
+ ADD_TEST(Drag Destination, test_drag_dest);
+ ADD_TEST(Drag GenList, test_drag_genlist);
+
ADD_TEST(Bg Plain, test_bg_plain);
ADD_TEST(Bg Image, test_bg_image);
ADD_TEST(Icon Transparent, test_icon);
Modified: trunk/TMP/st/elementary/src/bin/test_entry.c
===
--- trunk/TMP/st/elementary/src/bin/test_entry.c2010-09-06
23:36:40 UTC (rev 51934)
+++ trunk/TMP/st/elementary/src/bin/test_entry.c2010-09-07
06:56:16 UTC (rev 51935)
@@ -579,7 +579,7 @@
void
test_entry3(void *data, Evas_Object *obj, void *event_info)
{
- Evas_Object *win, *bg, *bx, *bx2, *bt, *en, *en_p, *sp;
+ Evas_Object *win, *bg, *bx, *bx2, *bt, *en;
win = elm_win_add(NULL, entry3, ELM_WIN_BASIC);
elm_win_title_set(win, Entry 3);
@@ -1206,7 +1206,7 @@
void
test_entry5(void *data, Evas_Object *obj, void *event_info)
{
- Evas_Object *win, *bg, *bx, *bx2, *bt, *en, *en_p, *sp;
+ Evas_Object *win, *bg, *bx, *bx2, *bt, *en;
win = elm_win_add(NULL, entry5, ELM_WIN_BASIC);
elm_win_title_set(win, Entry 5);
Modified:
[E-devel] Eina Arg Not NULL should die
Hello All, I'm proposing we remove all the EINA_ARG_NOTNULLs floating around in public headers. In short they may generate a warning, but they subvert any checks we have in the API, and can cause valid code to break. The not null macro expands to the GCC attribute notnull. From the GCC documentation[1]: The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. This means (with optimisations on) that GCC will remove any calls of the form if (arg == NULL) return err; Because you have told it that arg will NEVER be NULL. But we don't make that guarantee at all. Instead we say that people calling this function MAY get a warning if they pass a NULL pointer. So we cripple all our magic checks. Hence we really should kill the not nulls, they don't do what we want, they may give us a small performance boost, but at the unacceptably high cost of generating broken code. Regards, nash [1] http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/eina/src/lib
On Sat, 31 Jul 2010 08:56:43 -0300
Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote:
Test it 2 (you must compare pointers before or out-of-bounds access
will happen)
Test case: NULL, 0
test case2: {'a'}, 1
And really, add the test case to our suite.
Done. So I also added tests for the rest of the file, and found quite
a few other errors too (fixed as well).
Regards,
nash
[Moral: Always do large patches: No one looks at them.
_Everyone_ looks at the little ones]
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] VCS usage poll, no discussion
problem is just to convert and keep the whole history, if you do keep from now and on, then it is as simple. BR, Couldn't you get it started by doing a svn checkout of an early revision and using a bash script to incrementally commit each svn revision by separate to the git repository? It would take time and bandwidth but you only have to do it once. (disclamer: not a git or svn wizard) Easiest is to just do it on one of the e servers... Then it's just CPU cycles and disk space. Once it is cloned the entire repo could be moved. Regards, nash -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/eina/src/lib
On Sat, 31 Jul 2010 08:56:43 -0300
Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote:
Test it 2 (you must compare pointers before or out-of-bounds access
will happen)
Test case: NULL, 0
test case2: {'a'}, 1
And really, add the test case to our suite.
I was actually going to do so.
In my defense, the whole file is essentially untested, so it's not a 5
minute job to do in the middle of a weekend with other concerns (I
can't just drop in a single test for it). I need to work out how to add
a new set of tests eina, and essentially write tests for all the
functions. Expect something monday afternoon.
And the first test fails on quite a few strnlen implementations
(although it probably shouldn't ;-)
Regards,
nash
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk/eina/src: include lib
Brett Nash n...@nash.id.au
On 30/07/2010, at 10:28 PM, Peter Wehrfritz peter.wehrfr...@web.de wrote:
+EAPI size_t
+eina_unicode_strnlen(const Eina_Unicode *ustr, int n)
+{
+ const Eina_Unicode *end;
+ for (end = ustr; *end; end++)
+ ;
+ return end - ustr;
+}
The function doesn't seem to respect n in any way
You are entirely correct. I'll push the actual working code tomorrow.
Thanks.
Regards,
Nash
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tasn IN trunk/evas: . src/lib/canvas src/lib/engines/common src/lib/imaging src/lib/include src/modules/engines/direct3d src/modules/engines/directfb src/modules/engines/gl_glew s
#if defined(METRIC_CACHE) || defined(WORD_CACHE) - /* A fast (portable) strNlen would be nice (there is a wcsnlen strangely) */ - if ((p = memchr(text, 0, WORD_CACHE_MAXLEN))) - len = p - text; - else - len = WORD_CACHE_MAXLEN; + /* A fast strNlen would be nice (there is a wcsnlen strangely) */ + len = evas_common_econding_unicode_strlen(text); Can I just point out these are not really semantically equivalent. Also neither evas_common_econding_unicode_strlen (as committed) or evas_common_encoding_strlen seem to exist. I assume you meant eina_unicode_strlen()? And can I ask why you removed the word 'portable' from the comment? (Which tells me you took the time to read the code...) nash [Confused] -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eina_Binshare and Eina_Stringshare thoughts.
On Sun, 25 Jul 2010 10:54:21 +0300 Tom Hacohen tom.haco...@partner.samsung.com wrote: Hi all, I started writing Eina_Binshare (well actually adjusting Eina_Stringshare). The guys who wrote Eina_Stringshare cared a lot about speed, I mean, everything is split to special (common) cases that speed the whole thing up, for example, the case of 1 char strings. If I were you I'd do some benchmarks and see what falls out. For instance eina_strinshare add has a wacky +3 to the strlen, which means the common case of a aligned string gets a hit on architectures using sse optimised strlens or 64 bit arches using plain register compares. Stringshare can't be used for Binshare (because of the null termination) but, if we give up on the 1 char strings special case, we can save a lot of code duplication. That smells like a win to me. Even better if we have one cache, rather the two at run time. I honestly don't know enough about the usage of the stringshare functions around the e code, nor did I do a research on the subject. If anyone here knows why I should/shouldn't do what suggested above, plesae let me know. Looking at how things stand at the moment, I'm going to do it, and just wrap around binshare with inline stringshare functions. Just do some benchmarks, if the optimisations are not a gain or small gain and get in your way, drop them. Well that's my thoughts. Regards, nash -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/evas/src/lib/engines/common
On Tue, 20 Jul 2010 05:09:46 -0700 Enlightenment SVN no-re...@enlightenment.org wrote: Log: * evas: font config access is not thread safe at all. Don't forget to call FTLOCK/FTUNLOCK around each FT_* call. Author: cedric Date: 2010-07-20 05:09:46 -0700 (Tue, 20 Jul 2010) New Revision: 50379 Thanks for all these! Regards, nash -- 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] E SVN: raster trunk/e/src/bin
Good to know I'm not the only one who spams the world with
miss-committed printfs...
svn needs add --interactive ;-)
Author: raster
Date: 2010-07-13 16:56:47 -0700 (Tue, 13 Jul 2010)
New Revision: 50240
Modified:
trunk/e/src/bin/e_dpms.c
Modified: trunk/e/src/bin/e_dpms.c
===
--- trunk/e/src/bin/e_dpms.c 2010-07-13 23:36:32 UTC (rev
50239) +++ trunk/e/src/bin/e_dpms.c 2010-07-13 23:56:47 UTC
(rev 50240) @@ -6,6 +6,7 @@
static Ecore_Event_Handler *_e_dpms_handler_config_mode = NULL;
static Ecore_Event_Handler *_e_dpms_handler_border_fullscreen = NULL;
static Ecore_Event_Handler *_e_dpms_handler_border_unfullscreen =
NULL; +static Ecore_Event_Handler *_e_dpms_handler_border_remove =
NULL; static int _e_dpms_fullscreen_count = 0;
static Eina_Bool
@@ -19,6 +20,7 @@
_e_dpms_handler_border_fullscreen_cb(void *data __UNUSED__, int type
__UNUSED__, void *event __UNUSED__) {
_e_dpms_fullscreen_count++;
+printf(incremented fs_count: %d\n, _e_dpms_fullscreen_count);
if (_e_dpms_fullscreen_count == 1) e_dpms_init();
return ECORE_CALLBACK_PASS_ON;
}
@@ -27,17 +29,33 @@
_e_dpms_handler_border_unfullscreen_cb(void *data __UNUSED__, int
type __UNUSED__, void *event __UNUSED__) {
_e_dpms_fullscreen_count--;
+printf(decremented fs_count: %d\n, _e_dpms_fullscreen_count);
if (_e_dpms_fullscreen_count == 0) e_dpms_init();
else if (_e_dpms_fullscreen_count 0) _e_dpms_fullscreen_count =
0; return ECORE_CALLBACK_PASS_ON;
}
+static Eina_Bool
+_e_dpms_handler_border_remove_cb(void *data __UNUSED__, int type
__UNUSED__, void *event) +{
+ E_Event_Border_Remove *ev = event;
+
+ if (ev-border-fullscreen) {
+ _e_dpms_fullscreen_count--;
+printf(decremented fs_count from remove: %d\n,
_e_dpms_fullscreen_count);
+ if (_e_dpms_fullscreen_count == 0) e_dpms_init();
+ else if (_e_dpms_fullscreen_count 0)
_e_dpms_fullscreen_count = 0;
+ }
+ return ECORE_CALLBACK_PASS_ON;
+}
+
EAPI int
e_dpms_init(void)
{
int standby=0, suspend=0, off=0;
int enabled = ((e_config-dpms_enable)
(!e_config-mode.presentation) (_e_dpms_fullscreen_count = 0));
+printf(checking fs_count and if enabled: %d, %d\n,
_e_dpms_fullscreen_count, enabled);
if (!_e_dpms_handler_config_mode)
_e_dpms_handler_config_mode = ecore_event_handler_add
@@ -51,6 +69,10 @@
_e_dpms_handler_border_unfullscreen = ecore_event_handler_add
(E_EVENT_BORDER_UNFULLSCREEN,
_e_dpms_handler_border_unfullscreen_cb, NULL);
+ if (!_e_dpms_handler_border_remove)
+ _e_dpms_handler_border_remove = ecore_event_handler_add
+ (E_EVENT_BORDER_REMOVE, _e_dpms_handler_border_remove_cb,
NULL); +
ecore_x_dpms_enabled_set(enabled);
if (!enabled)
return 1;
--
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-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
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] [PATCH] Using const in elm_widget_drag_*_get functions
On Sat, 10 Jul 2010 03:11:34 -0300 Leif Middelschulte leif.middelschu...@gmail.com wrote: Hey, when reading part of EFL I also encountered those (forgotten?) const-keywords. If you take 'type const name' vs. 'const type name' into account as well, those misstakes are all over the place. Somebody told me to not care too much about it, but I'd be with you just because of 'correctness'. But maybe this coccinelle stuff (lucas) can help us fixing this formaility all over EFL? But what are even more important, are the opinions of the lead devs on this. For what it's worth I'm all for them. Callbacks are annoying with them (const void * in - void * out et al) and I really dislike having to cast. However they can improve performance, and even better can avoid real programmer bugs (const char * == not free, char * == I need to free etc ;-). For real fun, some heavy use of restrict would also be a major asset, but that takes real effort as you are making a quite strong set of guarantees to the compiler. Regards, nash -- 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] eet pkgconfig./include change
On Thu, 8 Jul 2010 13:08:06 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: for your consideration i changed eet to put Eet.h inside an eet-1 dir - like eian-0 for eina. pkg-config etc. is updated so compiles will work. packaging should work if it just includes everything in include/* recursively - which it should. but let me know what u think. i think we should do this for the rest of efl core? also one thing i didn't do is rename eet.pc to eet-1.pc - i think this is unnecessary as if there is every an eet 2.0 we can make it eet-2.pc then. My 2cents is: Yay! And yes, do it for the rest. I think we can agree that pkg-config is a requirement for such things. Having to put version numbers of dependencies in code sucks: Put it in the build system. Regards, nash -- 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] eet pkgconfig./include change
sure. it allows parallel installs of multiple eet major versions. this should in general do so for all of efl. only thing i am willing to maybe throw up in the air is the eet.pc vs eet-1.pc (we have eina-0.pc right now - and wel that obviously will being eina-1.pc - what should we do here. chaning it to eet-1.pc will mean everything that builds needs changes to adapt. i am happy to wait until eet 2.0 for eet-2.pc - and so on - ans similar for the rest of efl - with eina the exception with eina-1.pc) In that case: I'd say leave the number off until there is a second one to worry about. Alternatively both.. Regards, nash -- 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] E SVN: nash trunk/evas/src/lib/engines/common
Oh... personal attacks. I knew this thread was missing something. Short answer: If checking the return of alloca is so important to you then either commit a fix or send a patch. I still am of the opionion that checking the return of alloca means you don't know what it does. In the specific case you mentioned the code also called free on the return of alloca. So my little rule did indeed catch a real bug. nash On Sun, 4 Jul 2010 14:12:54 -0700 Michael Jennings m...@kainx.org wrote: On Sunday, 04 July 2010, at 02:45:37 (-0400), Jose Gonzalez wrote: In any case, you may want to bring this discussion up with the author of: evas/src/lib/engines/common/evas_map_image_internal.c where around line 78 you'll find some code that reads: // // allocate some spans to hold out span list spans = alloca((yend - ystart + 1) * sizeof(Line)); if (!spans) return; Good advice. If you're going to be a douche, know whom you're being a douche to. :-) As for platforms where alloca() can return NULL: http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devwin32/alloca_xml.html http://www.mkssoftware.com/docs/man3/alloca.3.asp http://www.ousob.com/ng/turboc/ng5738.php I also found a number of alloca() implementations which return NULL if asked to alloca(0), which could result if the parameter is an arithmetic expression (or if someone's trying to take your advice about how to get the stack pointer). But whatever. It's not like E/EFL code would ever run on any new or obscure platforms, appliances, or anything like that. And checking for NULL simply takes far too many cycles. Michael -- 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] E SVN: nash trunk/evas/src/lib/engines/common
On Sun, 04 Jul 2010 02:45:37 -0400 Jose Gonzalez jose_...@juno.com wrote: Brett Nash wrote: Until then, I'm going to continue to put people checking the alloca return value in the category of doesn't know what alloca does, and unable to read documentation. People can make oversights now and then, even change their code from a malloc to an alloca and forget they've done so, etc. How can you be so certain why they're checking for the return value. I actually agree. The reason I made (what I thought was) a humorous comment in a commit, and NOT raised on it on the mailing list was because I'm aware of such things. The code in question has been modified multiple times by multiple people. I'm not even sure who did what, as the commit history for the code is rather complex (beyond my svn fu). I attempted to find the person who I had thought created the code privately, but he rightly pointed out it wasn't him. My commit message reads: Don't check alloca, it's like checking the stack exists. Strangely however somebody (not yourself) would rather quote non-existent standards at me and make personal insults on a mailing list rather then actually check the code committed, which removed various bad uses of alloca, including following (heavily edited for clarity): unicode_out = (FriBidiChar *)alloca(sizeof(FriBidiChar) * (len + 1)); ... /* ERROR HANDLING */ -error6: - free(unicode_out); In any case, you may want to bring this discussion up with the author of: evas/src/lib/engines/common/evas_map_image_internal.c where around line 78 you'll find some code that reads: Strangely... I did. In fact he was about 1m away when I made the commit, and I specifically mentioned it to him at the time. Just to be clear, this was not part of some 'remove all alloca return checks' crusade: In this case I looked at the function (trying to trace down what was triggering another bug) and saw the check for alloca. This made me suspicious so I checked the whole function, and found the free on the alloca return. Which I fixed. If anyone is really bothered by the fact that turboc or some other obscure platform can return null, they are welcome to fix it. Otherwise I don't believe I have anything else to say on the issue. Regards, nash -- 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] E SVN: nash trunk/evas/src/lib/engines/common
Hmm.. thought I replied to this already, but the mail seems to have gone to lala land. My apologies if people get two replied. On Friday, 02 July 2010, at 01:31:13 (-0700), Enlightenment SVN wrote: Log: Don't check alloca, it's like checking the stack exists. It can't fail on *GNU* libc, but there's nothing in the standard that stops it from returning NULL on stack overflow. In fact, the man page implies that other platforms do exactly that. So did you read the man page you are quoting? Alloca is not part of any major standard. As the alloca man page on linux says: This function is not in POSIX.1-2001. Which also tells us it's not part of C89. It's not part of C99 (VLAs are instead). It's not part of SUS either. At this point we are pretty much out of useful standards. So I'm not sure which is the standard you refer too. Alloca is generally implemented as single adjustment of the stack pointer (hence alloca(0)[1] is a well known technique to get the address of the stack pointer). To call the OS to check if there is enough stack pointer kinda ruins the whole point as it's meant to fast. As for other platforms: Linux: Probably get a SIGSEGV: No NULLs FreeBSD: May give you pointers to other memory: No NULLs Solaris: 'Undefined' if too large: Maybe a NULL, also may execute /usr/games/nethack, or a case of nasal demons. Windows: Generates a structured exception: Doesn't return a NULL. Glib: Wraps it in a macro. Point out it never returns NULL[2] If you do know of a platform which can return a null[3], I'd be interested to hear. As it would be an essentially unique implementation, or using a malloc and garbage collection. Until then, I'm going to continue to put people checking the alloca return value in the category of doesn't know what alloca does, and unable to read documentation. So this change is likely wrong. So nope, it's likely correct. nash [1] Which is broken by the autofoo work-around for systems without alloca. [2] http://library.gnome.org/devel/glib/stable/glib-Memory-Allocation.html#g-alloca [3] I suppose you could do: alloca((size_t)alloca(0)); But then it's returning NULL as a success. -- 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
[E-devel] Neon fixes
Hello, For anyone using neon, I've fixed one error in the rendering that was affecting at least one user (Thanks Daniel Seo!). If anyone has any other crashes, could they please send me a backtrace or core file or something... Regards, nash -- 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] Evas built with threads enabled causes enlightenment to hang.
On Sun, 20 Jun 2010 19:47:41 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: I found another warning which needs attention and is likely to cause problems on 64-bit systems and is probably not visible on a 32-bit system. It might be related or not, but certainly a potential source for segfaults. In e/src/modules/comp/e_mod_config.c e_mod_config.c: In function '_style_demo': e_mod_config.c:246: warning: cast from pointer to integer of different size e_mod_config.c:248: warning: cast to pointer from integer of different size It's the only one of this kind for enlightenment and all it's dependencies. it's safe. i knew i was casting a pointer. it will be fine on any number of bits :) (32,, 64.. or more). Maybe cast the pointer-integer through a intptr_t or a uintptr_t? A little uglier, but it gets rid of all the size warnings on any size arch. int foo = (int)(intptr_t)voidthingy; Also avoids mailing list posts on the topic, which is even better ;-) Regards, nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Font rendering glitches on OMAP3 platforms
On Fri, 18 Jun 2010 14:17:48 +0200 Koen Kooi k...@dominion.thruhere.net wrote: Hi, Sorry for not using the mailinglist, but I'm not subscribed to it. I can confirm that the rendering bugs and crashes disappear when neon is disabled. Don't suppose you can send a back trace of the crash then? Preferably a core dump (upload someone, don't email), or something. I don't see the problem at all. Regards, nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/lib
Seems to be few little bugs here.
Nailed one little one... but can you check the rest?
+EAPI Evas_Object *
+elm_hover_content_unset(Evas_Object *obj, const char *swallow)
+{
+ ELM_CHECK_WIDTYPE(obj, widtype);
+ Widget_Data *wd = elm_widget_data_get(obj);
+ Subinfo *si;
+ Evas_Object *content;
+ const Eina_List *l;
+ char buf[1024];
+ if (!wd) return NULL;
+ snprintf(buf, sizeof(buf), elm.swallow.slot.%s, swallow);
+ EINA_LIST_FOREACH(wd-subs, l, si)
+ {
+ if (!strcmp(buf, si-swallow))
+ {
+ if (!si-obj) return NULL;
+ content = si-obj;
+ elm_widget_sub_object_del(obj, si-obj);
+ edje_object_part_unswallow(wd-cov, si-obj);
+ si-obj = NULL;
+ break;
+ }
+ }
+ return content;
+}
'content' may not be initialised.
And why not return when you get it?
Modified: trunk/TMP/st/elementary/src/lib/elm_layout.c
===
--- trunk/TMP/st/elementary/src/lib/elm_layout.c 2010-06-16
20:58:01 UTC (rev 49705) +++
trunk/TMP/st/elementary/src/lib/elm_layout.c 2010-06-16
20:58:09 UTC (rev 49706) @@ -211,6 +211,10 @@ /**
* Set the layout content
*
+ * Once the content object is set, a previously set one will be
deleted.
+ * If you want to keep that old content object, use the
+ * elm_layout_content_unset() function.
+ *
* @param obj The layout object
* @param swallow The swallow group name in the edje file
* @param content The content will be filled in this layout object
@@ -230,7 +234,8 @@
if (!strcmp(swallow, si-swallow))
{
if (content == si-obj) return;
- elm_widget_sub_object_del(obj, si-obj);
+ evas_object_del(si-obj);
+ si-obj = NULL;
break;
}
}
@@ -245,11 +250,46 @@
si-swallow = eina_stringshare_add(swallow);
si-obj = content;
wd-subs = eina_list_append(wd-subs, si);
- _request_sizing_eval(obj);
}
+ _request_sizing_eval(obj);
}
/**
+ * Unset the layout content
+ *
+ * Unparent and return the content object which was set for this
widget
+ *
+ * @param obj The layout object
+ * @param swallow The swallow group name in the edje file
+ * @return The content that was being used
+ *
+ * @ingroup Layout
+ */
+EAPI Evas_Object *
+elm_layout_content_unset(Evas_Object *obj, const char *swallow)
+{
+ ELM_CHECK_WIDTYPE(obj, widtype) NULL;
+ Widget_Data *wd = elm_widget_data_get(obj);
+ Subinfo *si;
+ Evas_Object *content;
+ const Eina_List *l;
+ if (!wd) return NULL;
+ EINA_LIST_FOREACH(wd-subs, l, si)
+ {
+ if (!strcmp(swallow, si-swallow))
+ {
+ if (!si-obj) return NULL;
+ content == si-obj;
+ elm_widget_sub_object_del(obj, si-obj);
+ edje_object_part_unswallow(wd-lay, si-obj);
+ si-obj = NULL;
+ break;
+ }
+ }
+ return content;
I fixed the ==.
But 'content' again.
Modified: trunk/TMP/st/elementary/src/lib/elm_list.c
===
--- trunk/TMP/st/elementary/src/lib/elm_list.c2010-06-16
20:58:01 UTC (rev 49705) +++
trunk/TMP/st/elementary/src/lib/elm_list.c2010-06-16 20:58:09
UTC (rev 49706) @@ -1296,6 +1296,10 @@ /**
* Sets the left side icon associated with the item.
*
+ * Once the icon object is set, a previously set one will be deleted.
+ * You probably don't want, then, to have the bsame/b icon
object set
+ * for more than one item of the list.
+ *
* @param it The list item
* @param icon The left side icon object to associate with @p it
*
@@ -1307,13 +1311,22 @@
ELM_LIST_ITEM_CHECK_DELETED_RETURN(it);
if (it-icon == icon) return;
if (it-dummy_icon !icon) return;
- if (it-dummy_icon) evas_object_del(it-icon);
+ if (it-dummy_icon)
+ {
+ evas_object_del(it-icon);
+ it-dummy_icon = EINA_FALSE;
Is this right?
+ }
if (!icon)
{
icon =
evas_object_rectangle_add(evas_object_evas_get(it-obj));
evas_object_color_set(icon, 0, 0, 0, 0); it-dummy_icon = EINA_TRUE;
}
+ if (it-icon)
+ {
+ evas_object_del(it-icon);
+ it-icon = NULL;
+ }
it-icon = icon;
if (it-base)
edje_object_part_swallow(it-base, elm.swallow.icon, icon);
@@ -1336,8 +1349,12 @@
}
Regards,
nash
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Font rendering glitches on OMAP3 platforms
On Tue, 15 Jun 2010 15:50:39 +0200 Benjamin Zores b...@geexbox.org wrote: http://www.sakoman.com/test/font-corruption.png There is some speculation that this began around the time neon optimizations were introduced, but I haven't confirmed that. This would explain the too-good-to-be-true score I had with expedite on font tests a few weeks ago. Not at all. The problem in the screenshot is an over render on a thin character. Which, if anything, should slow the performance down. Additionally you got insane results for text rendering in expedite without neon. Also the font rendering was pretty bad too. Thanks for the heads up then. nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Font rendering glitches on OMAP3 platforms
On Tue, 15 Jun 2010 06:34:38 -0700 Steve Sakoman sako...@gmail.com wrote: I'm seeing some font issues with svn49660 on OMAP3 platforms (Beagle, Overo) Here's a screen shot demonstrating the problem: http://www.sakoman.com/test/font-corruption.png There is some speculation that this began around the time neon optimizations were introduced, but I haven't confirmed that. If you could confirm it is neon it would be good. If so it's pretty much my issue to fix :-/ Looking at the screenshot it only appears to be the letter 'l' and 'i' that is causing problems? The word cache patches may also cause problems, but they are disabled by default as they aren't fully ready for prime time. Any ideas? I'll take a quick look. Best guess is a misscount on a short run. Regards, nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/ecore/src/lib/ecore_x/xlib
On Tue, 8 Jun 2010 09:55:40 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: -//#define LOGFNS 1 +#define LOGFNS 1 is it on purpose that you uncomment that line ? Just committing that fix now... It's on purpose I uncommented it for me. It's just me being a bloody idiot that I committed it. I blame SVN ;-) Dumb question: Is there the equiv of git commit --interactive for svn? Regards, nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/ecore/src/lib/ecore_x/xlib
On Tue, 8 Jun 2010 16:08:29 +0800 Brett Nash n...@nash.nu wrote: On Tue, 8 Jun 2010 09:55:40 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: -//#define LOGFNS 1 +#define LOGFNS 1 is it on purpose that you uncomment that line ? Just committing that fix now... It's on purpose I uncommented it for me. And someone beat me too it... ;-) Regards, nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/edje/src/lib
On Thu, 3 Jun 2010 07:26:43 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Thu, 3 Jun 2010, Carsten Haitzler (The Rasterman) wrote: On Wed, 2 Jun 2010 20:24:28 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: all other callback adds use const void *data - and that's correct as it means the add doesnt do anything to what data points to (doesn't modify) but the callback itself that is passed this pointer gets void * as the callback can modiy what it points to. but it breaks the 'const' chain. In that case, there is no interest of using any const pointers (for me).I like the C++ way of using const: if you pass a const pointer, at some point, you are sure that is it never modified later. Unfortunately C doesn't have the correct way to describe what we are after (this call won't modify the data, but you can do what you want to it, since it's yours). If we really really wanted to preserve appropriate const attributes we'd need two versions of each function: one for const data, and one for non-const, and even then it would fail to indicate EFL doesn't modify the data. Note the C standard library has _exactly_ the same problem. [I'm sure either the c89 or c99 rational document described this, but I can't find it anywhere - maybe a defect notice] Examples: char *strstr(const char *, const char *); Which returns you a non const version of the const paramater, so C (and C++) programmers should be aware of the problem. And since the users of the library then DON'T need to cast their modifiable data or the unmodifiable data (as long as their types are correct), it's all fine. Regards, nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EVAS build error on ARM/NEON after r48733
On Wed, 2 Jun 2010 09:08:56 +0200 Benjamin Zores b...@geexbox.org wrote: On Wed, Jun 2, 2010 at 5:58 AM, Brett Nash n...@nash.id.au wrote: Can you just rebuild evas _without_ neon enabled (you only need to recompile evas, doesn't effect any other library). Looking at the ratios to my tests, my feeling is neon isn't working I have to say. How could that be ? If it's compiled in, it's getting use, right ? There is the --enable-cpu-neon arg to configure, and a run time check. As long as they both pass, it will use neon. If you really want to check open one of the _neon files in blend, shove a printf there and make sure it gets printed (then get rid of it because your performance will then suck ;-) If only it was that good ;-) Yeah well, the scores are better than the one I experienced on N900. FYI, I've tried expedite on N900 months ago, either with my or Raster pre-built EFLs and I had results 5x slower than the one on raster's website. As raster said: Head expedite uses a weighted average. I think it was mostly to make sure neon doesn't look too good on the massive speed ups in image blending tests ;-) Regards, nash -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EVAS build error on ARM/NEON after r48733
On Wed, 2 Jun 2010 09:39:30 +0200 Benjamin Zores b...@geexbox.org wrote: On Wed, Jun 2, 2010 at 9:23 AM, Carsten Haitzler ras...@rasterman.com wrote: async != neon. neon requires a --enable. async rendering wont help you unless you have more than 1 core. and yes - it needs an env var set. its in the README. Yeah I'm fully aware of that. Though, as I used the enable-neon flag, that configures confirmed that and that *_neon.c files gets compiled in, I can't see a reason why it wouldn't be used, as pointed by Brett. Can you rebuild with it disabled, and try against the non-neonized evas? I just was expecting some better numbers... but without a baseline they are bit meaningless. Regards, nash -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EVAS build error on ARM/NEON after r48733
On Wed, 2 Jun 2010 22:01:43 +0200 Benjamin Zores b...@geexbox.org wrote: On Wed, Jun 2, 2010 at 10:45 AM, Benjamin Zores b...@geexbox.org wrote: On Wed, Jun 2, 2010 at 10:35 AM, Brett Nash n...@nash.id.au wrote: Can you rebuild with it disabled, and try against the non-neonized evas? I just was expecting some better numbers... but without a baseline they are bit meaningless. Yes, that's planned for tonight. So here are the new benchs. Same board, IGEPv2 @ 720 MHz, using software_x11, without (left) and with (right) NEON optimizations. Those numbers look about right, and similar improvements to what I have. A couple of regressions I don't have: Not using the gcc args to allow neon slows gcc down by about 1-3%, so neon generally claws that back with substantial interest. Regarding Textblock Intl, there used to be an issue because of Expedite not using right datadir when cross-compiled that I fixed (and all PNGs, TTFs, fonts.dir and fonts.alias files are present at the right place according to strace) but the too-big-to-be-true score remains. Good to see neon improved crazy performance to absolutely absurd performance ;-) Anyhow, NEON optimizations add a 30.2% boost. See http://geexbox.org/~ben/expedite-neon-omap3-igepv2.html Thanks for that. Regards, nash -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EVAS build error on ARM/NEON after r48733
On Sun, 23 May 2010 11:05:12 +0200 Benjamin Zores b...@geexbox.org wrote: On Sun, May 23, 2010 at 5:03 AM, Brett Nash n...@nash.id.au wrote: Hello Ben, Good to see someone finally testing this. Obviously works for me, but that doesn't count ;-) Sure :p Attachment didn't come through. Try the change below first, otherwise can you either put it on the web somewhere or mail it to me? Else just paste 5 lines around 8166 8304. A first guess however: There are two ldr.32 instructions, which may be the issue. The .32 is redundant, so try changing them to ldr. The lines are: 72 235 of op_blend_mask_color_neon.c One can say you know your good damn well :p This was indeed the issue, without having to see the generated assembly. Attached (hopefully this time) is your patch. I'll apply tomorrow morning. The error was quasi-obvious from the compiler message. I'm curious as to why code sourcery's gcc lets it pass without comment however. If you have time, I'd love to see any benchmarks you can generate ;-) Regards, nash -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EVAS build error on ARM/NEON after r48733
SVN-ised. Also removed the commented out vldr instruction as well. Thanks again, Regards, nash On Sun, 23 May 2010 11:05:12 +0200 Benjamin Zores b...@geexbox.org wrote: On Sun, May 23, 2010 at 5:03 AM, Brett Nash n...@nash.id.au wrote: Hello Ben, Good to see someone finally testing this. Obviously works for me, but that doesn't count ;-) Sure :p Attachment didn't come through. Try the change below first, otherwise can you either put it on the web somewhere or mail it to me? Else just paste 5 lines around 8166 8304. A first guess however: There are two ldr.32 instructions, which may be the issue. The .32 is redundant, so try changing them to ldr. The lines are: 72 235 of op_blend_mask_color_neon.c One can say you know your good damn well :p This was indeed the issue, without having to see the generated assembly. Attached (hopefully this time) is your patch. The flags in the commit message are needed: -mfloat-abi=softfp -mfpu=neon Also make sure you set the appropriate CPU[1] -mcpu=cortex-a8 They obviously were used :-) Thx, Ben -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EVAS build error on ARM/NEON after r48733
Hello Ben, Good to see someone finally testing this. Obviously works for me, but that doesn't count ;-) On Sat, 22 May 2010 23:46:56 +0200 Benjamin Zores b...@geexbox.org wrote: Hi, I'm no longer able to build evas on ARM Cortex-A8 (using NEON optimizations) after r48733 (see http://trac.enlightenment.org/e/changeset/48733 the one with NEON optimizations actually). Below is GCC output: b...@q6600:~/GeeXboX/geexbox/build.arm.eglibc/evas-r49141/src/lib/engines/common$ /home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/bin/armv7-geexbox-linux-gnueabi-gcc SNIP In file included from evas_op_blend_main_.c:92: ./evas_op_blend/op_blend_mask_color_neon.c: In function '_op_blend_mas_c_dp_neon': ./evas_op_blend/op_blend_mask_color_neon.c:8: warning: unused variable 'alpha' ./evas_op_blend/op_blend_mask_color_neon.c:7: warning: unused variable 'e' ./evas_op_blend/op_blend_mask_color_neon.c: In function '_op_blend_mas_can_dp_neon': ./evas_op_blend/op_blend_mask_color_neon.c:169: warning: unused variable 'alpha' ./evas_op_blend/op_blend_mask_color_neon.c:168: warning: unused variable 'tmp' /tmp/cccYHaUV.s: Assembler messages: /tmp/cccYHaUV.s:8166: Error: invalid neon suffix for non neon instruction /tmp/cccYHaUV.s:8304: Error: invalid neon suffix for non neon instruction Attached is the bzip'ed generated assembly file. Attachment didn't come through. Try the change below first, otherwise can you either put it on the web somewhere or mail it to me? Else just paste 5 lines around 8166 8304. A first guess however: There are two ldr.32 instructions, which may be the issue. The .32 is redundant, so try changing them to ldr. The lines are: 72 235 of op_blend_mask_color_neon.c Evas is cross-compiled using: - GCC 4.4.4 - Binutils 2.20.51.0.8 - eGlibc 2.11 Any idea how to fix this bug ? Any special CFLAGS to be added maybe (though it used to compile just fine before) ? The flags in the commit message are needed: -mfloat-abi=softfp -mfpu=neon Also make sure you set the appropriate CPU[1] -mcpu=cortex-a8 The build have been tested on gcc 4.4.1 from code sourcery before. Regards, nash [1] And if anyone wants to tell me to use -march -mtune etc... go away. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elementary GenList example problem
On Tue, 18 May 2010 22:01:57 +0200
Andreas Volz li...@brachttal.net wrote:
Hello,
I noticed a problem in the Elementary GenList example code:
static Elm_Genlist_Item_Class itc1;
char *gl_label_get(const void *data, Evas_Object *obj, const char
*part) {
char buf[256];
snprintf(buf, sizeof(buf), Item # %i, (int)data);
return strdup(buf);
}
static void
gl_sel(void *data, Evas_Object *obj, void *event_info)
{
printf(sel item data [%p] on genlist obj [%p], item pointer
[%p]\n, data, obj, event_info);
printf (data val: %i\n, (int) data);
}
void
test_genlist(void *data, Evas_Object *obj, void *event_info
{
int i;
...
for (i = 0; i 2000; i++)
{
gli = elm_genlist_item_append(gl, itc1,
(void *)i/* item data */,
NULL/* parent */,
ELM_GENLIST_ITEM_NONE,
gl_sel/* func */,
(void *)(i * 10)/* func data
*/); ...
}
While wrapping GenList to C++ I noticed that something really bad
happens here. The value of 'i' and 'i*10' is casted into a pointer
type and later casted back to int. I'm really sure this code isn't
covered by the C standard and not portable in any way. This code
needs the int type to have the same size as a pointer type. But there
may be architectures/compilers where this isn't the case. And even if
this works here it may bring someone to the idea to do the same with
other integral types where this won't work for sure. Not a smart idea
in a public example...
If you think this is correct code and I'm wrong please enlighten
me. :-)
It's technically not correct. Yes it hits something undefined in there.
Practically however it's only a problem if sizeof(int) sizeof(ptr) or
some weird platform which doesn't support odd pointers or something
(cray I's?). Don't think efl runs on any of those platforms ;-)
Pratically it's fine. A slight improvement may be to cast it to an
intptr_t which will protect it against different size void/int's (And
will reduce warnings too).
If not I'll change the example to hold two int arrays in the correct
scope and work with pointer type data.
Or do that ;-)
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Fri, 2 Apr 2010 07:47:45 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Fri, 2 Apr 2010, Carsten Haitzler (The Rasterman) wrote: On Fri, 2 Apr 2010 08:56:26 +0800 Tom Haste tomha...@gmail.com said: So... We're adding a patch that packagers use to make LUA install correctly, so wouldnt that make E more difficult to package? Since its effecting the install of LUA? Its early in the morning here so it may just be my squishy morning brain not understanding the idea. no no no.. WE are not adding the patch. WE are just assuming the lua install is sane (ie provides a .pc file etc.) and expect the installed lua to be patched and set up properly. :) technically speaking, the problem is the same than zlib or libjpeg, and we never complained that they don't have a .pc file. It would be easier, of course, to have one (btw, zlib 1.2.4 has one, now. The libjpeg maintainer does not want to add one, though) At least you don't need to patch their Makefile to get dynamic libraries however. And Lua _removed_ the .pc that was there. Regards, nash -- Download Intel#174; 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] ecore_txt - deprecation
On Mon, 22 Feb 2010 09:45:13 +0100 Atton Jonathan jonathan.at...@gmail.com wrote: And exml is still using ecore_list. Exml should be taken out and shot. It is: - Unmaintained - Documentation doesn't match code (see exml_next()) - Essentially unused. Regards, nash -- Download Intel#174; 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] Massive Valgrind Memory Check Warnings
you said it for me. the onyl things to really worry about are the definitely losts. indirectly lost - cant remember. need to check. as such the definitely losts in efl are quite small and limited to 1-offs. if they were recurring - they'd be fixed. OK. Though, it's quite troubling as the actual leaks may blend into the massive listing of valgrind output. Those warnings were not there and that's bugging me. Turn off show-reachable I believe - there is an option to suppress them. Otherwise manually suppress the worst of them, then run again. Regards, nash -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Massive Valgrind Memory Check Warnings
On Thu, 11 Feb 2010 11:35:26 +0800 Brian Wang brian.wang.0...@gmail.com wrote: Hello all, I'm using Elementary with recent svn. I got lots of valgrind memory check warning at program exit such as: ==6296== 5 bytes in 1 blocks are possibly lost in loss record 10 of 1,788 ==6296==at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==6296==by 0x429FC8F: strdup (strdup.c:43) ==6296==by 0x406A19E: evas_key_modifier_add (evas_key.c:172) ==6296==by 0x47355EC: ecore_event_window_register (ecore_input_evas.c:88) ==6296==by 0x4180B73: ecore_evas_software_x11_new (ecore_evas_x.c:2603) ==6296==by 0x41CA91A: elm_win_add (elm_win.c:361) ==6296==by 0x80500B3: win_standard_populate (app.c:2036) ==6296==by 0x8050570: win_mode_player_populate_delay (app.c:2148) ==6296==by 0x8050646: win_mode_switch (app.c:2193) ==6296==by 0x805074E: startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) ==6296== 8 bytes in 1 blocks are possibly lost in loss record 59 of 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) ==6296==by 0x4084B38: evas_object_rectangle_new (evas_object_rectangle.c:134) ==6296==by 0x4084A13: evas_object_rectangle_init (evas_object_rectangle.c:109) ==6296==by 0x40849E1: evas_object_rectangle_add (evas_object_rectangle.c:95) ==6296==by 0x41EB134: elm_pager_add (elm_pager.c:222) ==6296==by 0x804E4E1: control_pager_add (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) ==6296==by 0x805074E: startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) ==6296== ==6296== 8 bytes in 1 blocks are possibly lost in loss record 60 of 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) ==6296==by 0x4084B38: evas_object_rectangle_new (evas_object_rectangle.c:134) ==6296==by 0x4084A13: evas_object_rectangle_init (evas_object_rectangle.c:109) ==6296==by 0x40849E1: evas_object_rectangle_add (evas_object_rectangle.c:95) ==6296==by 0x41EB171: elm_pager_add (elm_pager.c:226) ==6296==by 0x804E4E1: control_pager_add (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) ==6296==by 0x805074E: startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) ==6296== ==6296== 8 bytes in 1 blocks are possibly lost in loss record 61 of 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) ==6296==by 0x4084B38: evas_object_rectangle_new (evas_object_rectangle.c:134) ==6296==by 0x4084A13: evas_object_rectangle_init (evas_object_rectangle.c:109) ==6296==by 0x40849E1: evas_object_rectangle_add (evas_object_rectangle.c:95) ==6296==by 0x43E532E: _edje_add (edje_main.c:211) ==6296==by 0x43E86F8: _edje_smart_add (edje_smart.c:65) ==6296==by 0x4085D83: evas_object_smart_add (evas_object_smart.c:346) ==6296==by 0x43E86D4: edje_object_add (edje_smart.c:56) ==6296==by 0x41D1A75: elm_button_add (elm_button.c:222) ==6296==by 0x804C6B6: button_add (app.c:442) ==6296==by 0x804E2FD: elapsed_bar_add (app.c:1228) ==6296==by 0x804E535: control_pager_add (app.c:1270) There are lots of more. The summary is quite scary: ==6671== LEAK SUMMARY: ==6671==definitely lost: 1,016 bytes in 12 blocks ==6671==indirectly lost: 4,340 bytes in 217 blocks ==6671== possibly lost: 2,915,620 bytes in 5,119 blocks ==6671==still reachable: 584,490 bytes in 6,969 blocks ==6671== suppressed: 0 bytes in 0 blocks I'm not sure how possible possibly lost means. Is it safe to ignore? I believe those warnings were not there. But my memory might be at fault. Possibly lost means it wasn't freed at exit generally. Ignore them. The OS is a hell of a lot better (and faster) at cleaning such things up[1]. Regards, nash [1] Deleting an entire address space is great cleanup method[2] ;-) [2] And doesn't need you to thrash your TLB and swap following free memory lists too. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-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
Unfortunately there is no safe way of printing it in C89 (ie windows). The best way is: printf(... %ld..,(unsigned int)blah); note that, on Windows 64 bits, a long is of size 32 bits :) Why do people use this again? ;-) I assume neither inttypes.h or stdint.h don't exist either? Regards, nash [Noting his printf was meant to be (unsigned long), and still wrong] -- 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, 30 Dec 2009 22:25:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de wrote: 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. I noted that I got it wrong in my follow up post - unsigned long is the correct cast (Sent almost 12 hours before your email). 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... GCC only does the printf-puts replacement if the first arg if at compile time it can be sure that: - fmt does not contain any %'s - And printf has no extra arguments. The printf-puts replacement is this only an issue if you are doing: printf(NULL); In which case I'd argue there is something wrong with your code anyway. The issue which gustavo correctly raised is the problem of printf(...%s...,NULL); Which will never trip a puts replacement. Regards, nash -- 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, 30 Dec 2009 22:25:17 +0100 Joerg Sonnenberger jo...@britannica.bec.de wrote: 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. 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. Regards, nash -- 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, 30 Dec 2009 07:51:01 +0100 (CET) Vincent Torri vto...@univ-evry.fr wrote: On Wed, 30 Dec 2009, Vincent Torri wrote: On Wed, 30 Dec 2009, Gustavo Sverzut Barbieri wrote: On Wed, Dec 30, 2009 at 12:07 AM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Fix printing of size_t value(s). (removes compiler warning). They invented z modifier for that, see man 3 printf it is also a gnu extension: http://swoolley.org/man.cgi/3/printf glibc 2.1 adds length modifiers hh,j,t,z and conversion characters a,A. %z is part of C99. So for C99 it's %zi of %zd. C99 also has the PRIx macros for printing all integer types safely. Unfortunately there is no safe way of printing it in C89 (ie windows). The best way is: printf(... %ld..,(unsigned int)blah); Regards, nash -- 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 IN trunk/efreet/src: bin lib
On Wed, 23 Dec 2009 18:14:57 -0500 Christopher Michael cpmicha...@comcast.net wrote: On 12/23/2009 06:01 PM, Vincent Torri wrote: On Wed, 23 Dec 2009, Enlightenment SVN wrote: Log: When using snprintf or fgets, etc, do not use PATH_MAX directly as the size of the variable...use sizeof() compiler directive (lots of these). that's something i don't understand. char buf[PATH_MAX] is an array of size PATH_MAX in bytes and sizeof(buf) returns the size of buf in bytes, which is also PATH_MAX so what is the interest of using sizeof() instead of PATH_MAX ? Vincent A little while ago I had changed snprintf's in several spots todo just that...PATH_MAX rather than sizeof()...raster suggested against it and had a valid reason (can't remember it now, but if you grep the mailing list archives I am sure you will find the discussion) If someone changes char buf[PATH_MAX] to char buf[BUFSIZ] there is no chance of forgetting to change the snprintf. Essentially the eternal principle of only saying something once in code. Regards, nash -- 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 IN trunk/efreet/src: bin lib
Also, doing sizeof() is a compiler directive so does not incur any performance hits...plus it matches the rest of EFL. using a macro does not involved any performance hit too as PATH_MAX is directly replaced by its value before the compilation. Yes, but it's a damn big performance hit when someone changes one size, but not the other and the whole thing falls over in a steaming heap... ;-) Regards, nash -- 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] Eina is broken (patrch submit)
On Wed, 14 Oct 2009 07:52:08 +0200 (CEST) Vincent Torri vto...@univ-evry.fr wrote: On Wed, 14 Oct 2009, Brett Nash wrote: The easier fix is to upgrade your automake to 1.10 or later. It works fine then. 1.9 gives the error reported below. Can you give the value of builddir and abs_builddir in Makefile (in src/lib) with automake 1.9 ? Nothing... Not assigned to anywhere. grep finds me this gem: $(builddir)/ eina_amalgamation.c: $(sources_used) Makefile grep abs_builddir **/Makefile returns nothing For grep abs_builddir **/*(.) autom4te.cache/output.0:ac_abs_builddir=$ac_pwd$ac_dir_suffix autom4te.cache/output.0:ac_abs_builddir=$ac_pwd$ac_dir_suffix autom4te.cache/output.0:s@abs_builddir@$ac_abs_builddir;t t autom4te.cache/output.1:ac_abs_builddir=$ac_pwd$ac_dir_suffix autom4te.cache/output.1:ac_abs_builddir=$ac_pwd$ac_dir_suffix autom4te.cache/output.1:s@abs_builddir@$ac_abs_builddir;t t autom4te.cache/traces.1:m4trace:configure.ac:445: -1- AC_SUBST_TRACE([abs_builddir]) config.status:ac_abs_builddir=$ac_pwd$ac_dir_suffix config.status:s@abs_builddir@$ac_abs_builddir;t t configure:ac_abs_builddir=$ac_pwd$ac_dir_suffix configure:ac_abs_builddir=$ac_pwd$ac_dir_suffix configure:s@abs_builddir@$ac_abs_builddir;t t top_builddir is set in each makefile to be a ../ repeated enough to get back to . Regards, nash Vincent __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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] Eina is broken (patrch submit)
The easier fix is to upgrade your automake to 1.10 or later. It works fine then. 1.9 gives the error reported below. Regards, nash [Sending patch shortly] On Tue, 13 Oct 2009 11:25:46 +0800 cantona cant...@cantona.no-ip.org wrote: Hi all, Eina is broken...I attached a patch which fixed the problem. - cantona --- cd . /bin/sh /home/cantona/e17_src/eina/missing --run autoheader rm -f stamp-h1 touch config.h.in cd . /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive make[1]: Entering directory `/home/cantona/e17_src/eina' Making all in src make[2]: Entering directory `/home/cantona/e17_src/eina/src' Making all in lib make[3]: Entering directory `/home/cantona/e17_src/eina/src/lib' rm -f /eina_amalgamation.c /bin/sh: /eina_amalgamation.c: Permission denied make[3]: *** [eina_amalgamation.c] Error 1 make[3]: Leaving directory `/home/cantona/e17_src/eina/src/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cantona/e17_src/eina/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cantona/e17_src/eina' make: *** [all] Error 2 -- 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 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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] Eina is broken (patrch submit)
Hello All, Attached is a patch to check the automake minor version. Yes, I'm sure there are more versions that need checking, but this tripped me, and apparently cantona up.. so it's probably worth the check. Tested against automake 1.4, 1.9 and 1.10 (debian). Regards, nash On Tue, 13 Oct 2009 11:25:46 +0800 cantona cant...@cantona.no-ip.org wrote: Hi all, Eina is broken...I attached a patch which fixed the problem. - cantona --- cd . /bin/sh /home/cantona/e17_src/eina/missing --run autoheader rm -f stamp-h1 touch config.h.in cd . /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive make[1]: Entering directory `/home/cantona/e17_src/eina' Making all in src make[2]: Entering directory `/home/cantona/e17_src/eina/src' Making all in lib make[3]: Entering directory `/home/cantona/e17_src/eina/src/lib' rm -f /eina_amalgamation.c /bin/sh: /eina_amalgamation.c: Permission denied make[3]: *** [eina_amalgamation.c] Error 1 make[3]: Leaving directory `/home/cantona/e17_src/eina/src/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cantona/e17_src/eina/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cantona/e17_src/eina' make: *** [all] Error 2 -- 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 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __Index: autogen.sh === --- autogen.sh (revision 42995) +++ autogen.sh (working copy) @@ -3,6 +3,16 @@ rm -rf autom4te.cache rm -f aclocal.m4 ltmain.sh +# Ignore the major version for now +AUTOMAKE_MINOR_NEEDED=10 + +AUTOMAKE_MINOR_VER=`automake --version | + sed -n 's,^automake (GNU automake) 1\.\([0-9]*\).*,\1,p'` +if [ $AUTOMAKE_MINOR_VER -lt $AUTOMAKE_MINOR_NEEDED ]; then + echo Need automake 1.10 or later; + exit 1 +fi + echo Running aclocal... ; aclocal $ACLOCAL_FLAGS -I m4 || exit 1 echo Running autoheader... ; autoheader || exit 1 echo Running autoconf... ; autoconf || exit 1 -- 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] License questions
On Mon, 21 Jul 2008 13:45:47 +0200 Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: Hi all, I dont pretend to start a flamewar, if you do, please dont answer this thread.The thing is that right now, the EFL has arrived to a place where different companies are using this software, and several of us are working on a company using the efl (raster, gustavo, cedric, me, anyone else?). Me? From a closed source company POV, BSD license is great because they dont need to give us anything back (fancypants example?); I'm not quite sure where you get the idea that FST (ie FancyPants) doesn't give anything to the community. I personally have contributed[1] (on company time, with company approval) in the past 12 months, bug reports, bug fixes, compilation fixes, a rendering engine and given a talk on e17 related technologies at LCA. There are other contributions, not all code, and not all is on the public record for a variety of reasons - especially the fact I know I can save time by emailing people patches and other comments directly. I can think of another individual who did a lot of work on evas, ecore edje in 2003 on FSTs time (with full company backing). FST doesn't make a large song and dance about these contributions - maybe we should if people think we are just taking a free ride? However I personally think doing it without making a fuss is much healthier for the community in the long term (this goes for the other companies who contribute to e17 as well). On the flip side it's not a secret that we use e17 technologies in our products, _all_ our customers (for those products) are aware of this, and not just something buried in a README.txt either. companies that do want to build an opensource initiative based on the EFL, BSD is not so great, because their code can be stolen from others; so whats your opinion on this? Well to be frank, even if we never gave a single line of code back (which as I just said, we have), it still wouldn't be stealing. FST (and I personally) take our licencing obligations very seriously. We do follow the licence requirements for the parts of e17 we use, the original author is well aware of the fact we use the software, and how we use it. In fact it was his original suggestion (and he had to convince quite a few people here) that FST use the technology. Regards, nash [aka [EMAIL PROTECTED] [1] I don't want to turn this into a contest on number of lines or any such garbage. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/edje raster
On Tue, 2007-11-27 at 05:50 -0500, Enlightenment CVS wrote: Modified Files: edje_cc_sources.c Log Message: terminate strings properly? You mean over-terminate strings properly. snprintf will always terminate strings correctly. It writes no more then N characters including the terminating null byte. (That last bit from the C standard). This means the following code is silly (double terminates): char buf[BUFSIZ]; snprintf(buf, BUFSIZ - 1, ...); as is snprintf(buf, BUFSIZ, ...); buf[BUFSIZ - 1] = 0; The first makes your buffer too small, the second sets a nil over a guaranteed nil. Of course they are broken implementations... but that's another story. char buf[10]; snprintf(buf,10,Long String Longer then 10 bytes); puts(buf); Should print: Long Stri As an aside: - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ Do these marketing people even know what sourceforge is? Regards, nash - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/e_dbus ravenlock
On Mon, 2007-11-19 at 17:38 -0600, Nathan Ingersoll wrote: On 11/19/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 17 Nov 2007 11:11:55 -0600 Nathan Ingersoll [EMAIL PROTECTED] babbled: personally i like defensive programming. it's better than every process having to trap its segv's/aborts and give u a debug trace and suddenly lose all your work/state. i think a compile or runtime definable please btich to stdout/err about these problems is the best way to go (all of evas and ecore are very defensively programmed - set environment variables to turn on bitch mode and you can also enable abort mode for aborting on caught failures). Yep, I agree and EWL follows the same model. We have tons of parameter and type checks and they can be passed a command line flag (maybe an env variable too) to trigger an abort mode. So can we combine the two, and get EWL to play nice with EVAS_DEBUG_SHOW and EVAS_DEBUG_ABORT? Currently creating a single widget generates 20+ warnings... 95% are NULL warnings to be fair... but it's hard to see what the other 5% are due to the number. I'm willing to do some of the if (obj != NULL) evas_object_show(obj); if people are happy for me to commit them. Regards, nash [Venting on a little pet peeve he has with EWL] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/e_dbus ravenlock
On Mon, 2007-11-19 at 19:54 -0500, dan sinclair wrote: I'm not seeing this when I have full debug on with Ewl. Can you please post an example program that shows this behavour? We've been trying to cleanup as many of the warnings as we can in the system. There are a few warnings spit but not many. That I find surprising. Obviously your set up is distinctly different to mine. The easiest example I have is exhibit. I updated using easy_e17.sh on the 14th of this month: % export EVAS_DEBUG_SHOW=1 % export LD_LIBRARY_PATH=/opt/e17/libs/ % exhibit | grep 'EVAS ERROR' | wc -l 814 % That's opening my home directory. Jumping to a different machine (same update date), I get: % ./ewl_embed_test | grep 'EVAS ERROR' | wc -l 60 Starting ewl_test and exiting gives: % ./ewl_test | grep 'EVAS ERROR' | wc -l 105 I have another program which uses ewl (galaxie from thousandparsec) which embeds EWL widgets, which generates ~160 warnings when creating two ewl_tree, four icons, some labels, and a some various boxes and layout widgets. However the others should be easier to test ;-) No special setup on either, using whatever the defaults are as installed on both applications. Regards, nash - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] strange bug with Ecore and timers
On Thu, 2007-11-01 at 23:22 +0100, Mathieu SCHROETER wrote: Hello, I've a strange bug with Ecore when I will add a timer after the ecore_main_loop_begin (); when this main_loop is in a pthread. To the best of my knowledge, ecore's main loop doesn't really handle events being posted in other threads. In fact ecore is not really thread safe or re-entrant. Any problems from there are fundamental issues with the intended design and usage of the library. Regards nash - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore nash
On Thu, 2007-10-25 at 08:58 -0300, Gustavo Sverzut Barbieri wrote:
On 10/25/07, Brett Nash [EMAIL PROTECTED] wrote:
struct _Ecore_Exe_Event_Del /** Process exit event */
{
- pid_t pid; /** The process ID of the process that exited */
- intexit_code; /** The exit code of the process */
- Ecore_Exe *exe; /** The handle to the exited process, or NULL if
not found */
- intexit_signal; /** The signal that caused the process to
exit */
- char exited: 1; /** set to 1 if the process exited of
its own accord */
- char signalled : 1; /** set to 1 id the process exited due
to uncaught signal */
- void *ext_data; /** Extension data - not used */
- siginfo_t data; /** Signal info */
+ pid_t pid; /** The process ID of the process that exited */
+ int exit_code; /** The exit code of the process */
+ Ecore_Exe*exe; /** The handle to the exited process, or NULL
if not found */
+ int exit_signal; /** The signal that caused the process
to exit */
+ unsigned char exited: 1; /** set to 1 if the process exited
of its own accord */
+ unsigned char signalled : 1; /** set to 1 id the process exited
due to uncaught signal */
+ void *ext_data; /** Extension data - not used */
+ siginfo_t data; /** Signal info */
};
In any case, I'd rather just do the minimum change to remove the
warning/unportable-declaration - which is add unsigned.
I think Vincent was wondering about my last commit to ETK, that I
tried to remove struct holes with information provided by pahole. In
your case it will contain these holes since structs will be aligned,
and things like [char][pointer] will be laid out effectively as
[long][pointer], same for int, long, ... in the place of [pointer].
For better use of memory, you should try to pack-a-hole (pahole
tool is meant for that) and even better: keep memory that is used
together within the same cacheline (pahole helps here to).
I seem to have unintentionally opened a can of worms here. Just to be
clear they were meant minimal patches - adding unsigned to 1-bit fields.
Additional changes were to make the code line up in the same way most of
the structures are aligned.
The reason I went after the bit fields is because they are totally
undefined in C - the valid range is exactly the value 0. They may not
even store a second value successfully (more specifically they may store
0 and -0, which both compare true to 0).
If anyone wants to sort the structures for packing or similar, feel
free, I'm happy to apply sane patches, and deal with carsten beating me
up later ;-)
Currently I'm trying to get the warnings and errors from the static
analysis tools we use under control, as well as make the code clean on
64 bit systems. This is both for the commercial version we support and
upstream.
All in all is usually better to keep these bitfield as unsigned char
(or int, or short,...) at the end of the struct.
And I'll generally agree with this. Although there is a counter
argument if you really want to optimise cache-line friendliness ;-)
(eg lists should always be {data, next, prev} not {next, prev, data}).
However that's way out of scope at this time ;-)
Regards,
nash
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore nash
struct _Ecore_Exe_Event_Del /** Process exit event */
{
- pid_t pid; /** The process ID of the process that exited */
- intexit_code; /** The exit code of the process */
- Ecore_Exe *exe; /** The handle to the exited process, or NULL if not
found */
- intexit_signal; /** The signal that caused the process to
exit */
- char exited: 1; /** set to 1 if the process exited of its
own accord */
- char signalled : 1; /** set to 1 id the process exited due to
uncaught signal */
- void *ext_data; /** Extension data - not used */
- siginfo_t data; /** Signal info */
+ pid_t pid; /** The process ID of the process that exited */
+ int exit_code; /** The exit code of the process */
+ Ecore_Exe*exe; /** The handle to the exited process, or NULL if
not found */
+ int exit_signal; /** The signal that caused the process to
exit */
+ unsigned char exited: 1; /** set to 1 if the process exited of
its own accord */
+ unsigned char signalled : 1; /** set to 1 id the process exited due
to uncaught signal */
+ void *ext_data; /** Extension data - not used */
+ siginfo_t data; /** Signal info */
};
Shouldn't the bit-field members be placed at the end of the struct to be
useful ?
Not sure exactly what you mean.. but there is no real reason to do
anything except make sure the bitfields are adjacent in the structure.
Otherwise it won't make any difference for size (the whole structure
will be aligned, and since there is no small members to pack smaller
than the natural machine alignment requirements no gain there).
In any case, I'd rather just do the minimum change to remove the
warning/unportable-declaration - which is add unsigned.
Regards,
nash
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
