Re: [E-devel] [EGIT] [core/elementary] master 01/03: cnp: Fixed build warning.

[Mike McCormack]

On 20/03/14 05:26, Gustavo Sverzut Barbieri wrote:
> On Wed, Mar 19, 2014 at 2:15 PM, Daniel Juyung Seo  
> wrote:
>
>>   static Eina_Bool
>> +#ifdef DEBUGON
>>   _x11_dnd_leave(void *data EINA_UNUSED, int etype EINA_UNUSED, void *ev)
>> +#else
>> +_x11_dnd_leave(void *data EINA_UNUSED, int etype EINA_UNUSED, void *ev 
>> EINA_UNUSED)
>> +#endif
>>   {
>>  cnp_debug("Leave %x\n", ((Ecore_X_Event_Xdnd_Leave *)ev)->win);
>
> better fix would be:
>
> #ifdef DEBUGON
> cnp_debug(...)
> #else
> (void)ev;
> #endif

An even better fix would be to define cnp_debug() to be an inline 
function that does nothing if DEBUGON is not defined, rather than an 
empty macro.

Mike



--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Ecore Glib Integration

[Mike McCormack]

On 08/08/2013 09:59 PM, Christopher Michael wrote:

> Are you ok if I fix this (use g_source_remove_poll there). Or are you
> already planning to fix this ??

Go ahead and fix it.  I've just started a new job, and am a bit short on 
time right now.  I did manage to get efl/ecore building (gah! bullet! 
dependencies! gah!) and will do some testing, but don't wait for me.

Mike



--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Ecore Glib Integration

[Mike McCormack]

On 08/08/2013 07:27 PM, Christopher Michael wrote:
> I believe that I have discovered a problem with the glib integration
> into ecore main loop. Basically the issue is this:
>
> _ecore_main_fdh_poll_add is calling g_source_add_poll (which seems correct)
>
> BUT
>
> _ecore_main_fdh_poll_del is callback g_source_add_poll also (which
> smells wrong).
>
> Shouldn't that be doing g_source_remove_poll ??

Yeah, it looks wrong to me too.  Looks like a copy and paste error 
introduced some time ago.

Are you guys going to use the g_main_loop integration for something 
serious, or did you just spot a bug?

thanks,

Mike


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: dear Mike,

[Mike McCormack]

On 03/21/2013 09:25 PM, Tom Hacohen wrote:

> Silencing warnings just for silencing is not good. We use them to spot
> bugs, that's why we like them so much. Silencing useful warnings is
> counter-productive.

Usually a developer, upon checking out a code base and building it on 
their system and observing a nice warning free compile will have a sense 
of confidence in a project.

Usually a developer, on making a modification to their code, checks for 
warnings and makes sure none have been introduced before pushing their code.

There are some people who wish to compile their code with every frickin 
warning in the world turned on, then proceed to ignore said warnings, 
and commit code with warnings to their revision control systems.

That gcc somehow changed which warnings it emits in a newer version 
changes none of the above.

Enjoy your warnings.

Mike


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/efl/src/bin: edbus edje

[Mike McCormack]

On 03/21/2013 01:28 PM, Lucas De Marchi wrote:

> And for those of you to insist in disagreeing, go complaint to GCC devs now:
>
> http://lwn.net/Articles/542920/
> " In addition, -pedantic has been deprecated (in favor of -Wpedantic),
> and -Wshadow has been fixed. -Wshadow now permits a common use-case
> certain kernel developers have long complained was erroneously flagged
> as invalid."
>
> With a link to exactly the same thread I pointed out.

So the only build configuration that should be warning free is bleeding 
edge Gentoo with the latest alpha of gcc or Tizen, right?

thanks,

Mike



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/efl/src/bin: edbus edje

[Mike McCormack]

On 01/14/2013 11:15 PM, Lucas De Marchi wrote:

> On Fri, Jan 11, 2013 at 7:40 PM, Enlightenment SVN
>  wrote:
>> Log:
>> efl: Avoid shadow warnings (signal -> sig)
>>
>>Signed-off-by: Mike McCormack 
>
>
> Though I don't care too much about changes this (and thus it's ok to
> let it like it is now), this is instead a GCC bug.  I'm not sure what
> is the version in which it was fixed... maybe 4.5 or 4.6.  Are you
> using GCC 4.4?

Hi Lucas,

I'm using Ubuntu 12.04.1 LTS with gcc version 4.6.3 (Ubuntu/Linaro 
4.6.3-1ubuntu5).

Whether it's a gcc bug or not, the point of having a warning free 
compile is to:

A) show other developers that having a warning free build is valued

B) help your developers find real problems exposed by warnings by 
keeping the warning noise as minimal as possible.

Using -Wshadow, -Wunused-parameter, -Wunused-result and other noise 
generating warnings is a waste of time unless you're prepared to fix all 
the warnings that are shown up, especially on commonly used systems like 
Ubuntu.

mike@thinkpad:~/e$ grep warning: e.build.log.20130113.log | grep -v 
relink | wc -l
87

thanks,

Mike


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/efl/src/lib/ecore_con

[Mike McCormack]

On 01/03/2013 08:09 AM, Michael Blumenkrantz wrote:
> On Wed, 2 Jan 2013 19:05:54 -0200
> "Eduardo Lima (Etrunko)"  wrote:

>>> -   dns_header(P)->arcount = 
>>> htons(ntohs(dns_header(P)->arcount) + 1);
>>> +   count = ntohs(dns_header(P)->arcount) + 1;
>>> +   dns_header(P)->arcount = ntohs(dns_header(P)->arcount) + 1;
>>>
>>
>> This last one looks weird, is it really correct?
>
> no, it is not.

Thanks for catching this.  Will fix in SVN if somebody has not beat me 
to it.

Mike


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e17 (and anything using efreet... and edbus) totally broken for now

[Mike McCormack]

On 12/29/2012 09:48 PM, Carsten Haitzler (The Rasterman) wrote:
> as for changes int he last 24hrs e17 no longer starts at all. nothing that 
> uses
> efreet and thus edbus works. we segv in edbus init (deep inside of dbus). i
> spent a while in a text console (which i partly rescued to run terminology so
> it was more useful) today rolling back my whole set of e17/efl/edje/etc. 
> trees.
> i ended up going back to 81802. something after this commit totally brought
> the world down and i havent had time to bisect what it was.
>
> so beware if you update...

E17 works for me (@81866, in Xephyr).

Mike



--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Spam

[Mike McCormack]

On 11/24/2012 04:31 PM, Daniel Juyung Seo wrote:
> Right. Each commit should be atomic/clean/lean/simple.
> +1 to bdilly
>
> But having huge amount of commits at once is annoying.
> It's hard to read/review.
> +1 to devilhorns

Surely smaller commits are easier to review?

Additionally, if a commit introduces a bug (it never happens, but... 
;-), it's easier to isolate and revert the offending commit, rather than 
reverting everything.

Lots of small commits is the git way, and probably not something that 
somebody who has been using SVN for a long time is used to...

Mike


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/efl/src/modules/evas/engines/gl_x11

[Mike McCormack]

On 11/20/2012 12:18 PM, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 19 Nov 2012 05:10:07 -0800 "Enlightenment SVN"
>  said:
>
>> - rects->x = x1;
>> - rects->y = y1;
>> - rects->w = x2 - x1;
>> - rects->h = y2 - y1;
>> + rects->x = p1.x;
>> + rects->y = p1.y;
>> + rects->w = p2.x - p2.x;
>> + rects->h = p2.y - p2.y;
>
> typoville!... resulting in wonderful blank black screen bugs... :)

Ooops...

Well, if you're going to break it, break it well! :)

Mike


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/efl/src/modules/evas/engines/gl_x11

[Mike McCormack]

On 11/20/2012 01:22 AM, Lucas De Marchi wrote:

> However it seems to be fixed in gcc now, so I think we can let people
> with older compilers to see the warnings and have the benefits brought
> by -Wshadow

I don't see any benefit to using -Wshadow.

There's not really a lot of point in turning lots of warnings on if 
we're not going to fix them for most recent compilers, because the whole 
point of fixing irrelevant warnings is so that the relevant ones are 
obvious.

Building everything simply with -Wall would be sufficient for me.

thanks,

Mike


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/ecore/src/lib/ecore

[Mike McCormack]

> That's quite a good patch, thanks ! Nice to see you having time
> contributing again :-)

Thanks Cedric.

There's some more work to do to make it all work with the glib based 
main loop.  I'm at least trying to keep it building and working, as time 
permits :-)

Mike



--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/e/src/modules/conf_randr

[Mike McCormack]

On 10/09/2012 09:00 AM, Christopher Michael wrote:

> Darn those "good practices" :P
>
> Going to make use of those tomorrow ;)

Always code like there's no tomorrow ;-)

Mike



--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/e/src/modules/conf_randr

[Mike McCormack]

On 10/02/2012 09:26 PM, Christopher Michael wrote:

> A little premature wrt adding the UNUSED here because they are soon to
> be used ;) But thanks for the fixes !! :)

Keeping good habits :-)

Mike



--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/ecore/src/lib/ecore

[Mike McCormack]

On 11/29/2011 07:08 PM, Vincent Torri wrote:

> changelog ?

Surely it's a bit redundant to write both a git/SVN commit message
and update the ChangeLog?

How about polishing the commit messages a bit, and using those for
the ChangeLog at some point?

thanks,

Mike

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] bug report related to Changeset 64721

[Mike McCormack]

Hello 이명재,

Index: src/lib/elm_entry.c
===
--- src/lib/elm_entry.c (revision 65568)
+++ src/lib/elm_entry.c (working copy)
@@ -579,6 +579,7 @@ _recalc_cursor_geometry(Evas_Object *obj)
 Evas_Coord cx, cy, cw, ch;
 edje_object_part_text_cursor_geometry_get(wd->ent, "elm.text",
   &cx, &cy, &cw, &ch);
+printf("[%s::%d] cx(%d) cy(%d) cw(%d) ch(%d) \n", __func__, __LINE__, 
cx, cy, cw, ch);
 if (wd->cur_changed)
   {
  elm_widget_show_region_set(obj, cx, cy, cw, ch, EINA_FALSE);

Is there some need to add printfs here?  How about removing them or using the 
EINA logging mechanism?

thanks,

Mike


On 11/25/2011 09:17 AM, 이명재 wrote:
> Dear, Tom, Raster and EFL people.
> 
> After applying the previous changeset 64721, the cursor geometry is wrong
> in a char-wrapped or a mixed mode entry contented in a scroller (not a
> scrolled entry).
> In other words, a word-wrapped entry or a scrolled entry (when
> elm_entry_scrollable_set is set to TRUE) doesn't have this problem.
> 
> Because the cursor geometry that comes from the
> evas_textblock_cursor_geometry_get function(en->cursor, ...) is wrong (w is
> fixed to small value and h is getting bigger when text is written
> horizontally), when we type texts into the entry near the top lines, entry
> is scrolled to the bottom lines.
> 
> Please apply attached patch file, "entry_test.patch.txt" (patch to
> elm_entry.c and test_entry.c files) and see what happens in the below test
> path.
> 
> Test path : 'Elementary Test' -> 'Entry 5' -> Insert any text into the 1st
> line
> Result : Entry is scrolled to the bottom line so inserted texts in the 1st
> line are not shown until entry is scrolled to the top
> 
> 
> I also attached a quick patch for this problem. ("elm_entry.patch.txt")
> In the patch file, I just changed the order of these 2 function calls and
> now it works fine in all line wrapping mode.
> 
>edje_object_size_min_restricted_calc(wd->ent, &fw, &fh, 0, 0);
>edje_object_size_min_restricted_calc(wd->ent, &minw, &minh, resw, 0);
> 
> It's really weird that changing the order of calling
> 'edje_object_size_min_restricted_calc' functions affects the size of
> textblock cursor geometry in entry.
> 
> Please look into this bug and if you find the main problem on textblock's
> side, please fix it.
> 
> If it takes time to fix this, please apply the attached quick patch file
> and fix it when you're available because we have some scroll issues with
> entry in scroller here at this moment.
> 
> Thank you.
> 
> 
> 
> --
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> 
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Add new elementary widget 'Multibuttonentry'

[Mike McCormack]

On 11/24/2011 01:34 PM, GoUn Lee wrote:

> Sorry for the wrong documentation. and I've attached patch file again that 
> includes removed documentation in header file.
> I'll modify documentation more and send it later.

Please provide a patch against the current SVN that fixes the documentation, 
not removes it.

thanks,

Mike

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/elementary: . data/objects data/themes data/themes/widgets src/bin src/lib

[Mike McCormack]

On 11/24/2011 11:12 AM, Daniel Juyung Seo wrote:
> This is not right.
> GoUn Lee sent a patch to mailing list for the code review and this is
> not reviewed enough on the mailing list.
> 
> And I don't think one year internal around means this code is correct
> and does not have to be reviewed enough even I know it works.
> 
> Impatient mike!
> Anyhow, I disagree with this decision. Once this happens, we can't
> guarantee this will not happen again. And GoUn will lose her chance to
> be reviewed her code enough by open source e-developers.

Goun is only the internal maintainer of this code, not the original author.

It has be contributed to by many people internally, which I have tried to
reflect in the commit message.

Most code committed to EFL (say 90%) is not reviewed on the mailing list.
Has code review suddenly become a priority? :-)

thanks,

Mike

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/elementary: . data/objects data/themes data/themes/widgets src/bin src/lib

[Mike McCormack]

On 11/24/2011 10:10 AM, Michael Blumenkrantz wrote:

> umm...unless I'm mistaken this was not given NEARLY enough time to be reviewed
> on the list. and as you are an author, you cannot self-review...

Sorry to rush.

My judgement is that this will go in one way or the other at some point.  It has
been around internally for one year, is in constant use, etc.

It's not a prototype that somebody thought up yesterday and is suddenly pushing 
today.

IMO, it should have been upstreamed and committed much sooner, so I'm a bit
impatient to get the damn thing merged.

Sorry to step on your toes.

I'll do my best to make sure that the review comments are addressed.

Mike

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Ecore --disable-largefile doesn't.

[Mike McCormack]

> So I can remove a few more bytes from my embedded project that does not
> need large file support, since the largest file is the 10MB OS itself.
> Anything with the word "large" in it seems like a good target to
> remove.  B-)

Presumably you've disabled large file support in your libc and/or kernel,
so the build should detect that, and the option should be unnecessary.

thanks,

Mike

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Ecore --disable-largefile doesn't.

[Mike McCormack]

On 11/24/2011 07:39 AM, David Seikel wrote:
> Ecore --disable-largefile doesn't.  As far as I can tell, the reason is

What is the point of the option?  Seems like bloat to me, why not delete it?

thanks,

Mike

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] The IMPOSSIBLE HAPPEN!

[Mike McCormack]

On 11/17/2011 04:47 PM, Cedric BAIL wrote:
> On Thu, Nov 17, 2011 at 4:07 AM, Mike McCormack
>  wrote:
>> Running elementary_test and clicking on the button test this morning gives a 
>> crash sometimes.
>>
>> Eina thread debugging on & using gmainloop.
> 
> After a quick look in evas_common_rgba_image_scalecache_do, we do have
> an issue there. The image lock is taken while calling sub function
> that don't expect it to be locked. I am just wondering why the lock is
> taken for so long on im->cache.lock, any reason ?

It only happened for the button test (if it click on it quickly as soon as 
elementary_test starts),
and even then not all the time.

thanks,

Mike

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] The IMPOSSIBLE HAPPEN!

[Mike McCormack]

Running elementary_test and clicking on the button test this morning gives a 
crash sometimes.

Eina thread debugging on & using gmainloop.

thanks,

Mike


mike@mike-desktop:~/git/e/evas$ gdb elementary_test
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/bin/elementary_test...done.
(gdb) run
Starting program: /usr/local/bin/elementary_test 
[Thread debugging using libthread_db enabled]
[New Thread 0xb6924b70 (LWP 24569)]
[Thread 0xb6924b70 (LWP 24569) exited]
*
* The IMPOSSIBLE HAPPEN *
* LOCK STILL TAKEN :*
*
lock 0x84923e8, locked: 1, by -1223465248
/usr/local/lib/libevas.so.1(evas_common_rgba_image_scalecache_do+0xad)[0xb7d6d8ed]
/usr/local/lib/evas/modules/engines/software_generic/linux-gnu-i686-1.1.0/module.so(+0x2c88)[0xb7fc8c88]
/usr/local/lib/libevas.so.1(+0x2975b)[0xb7cee75b]
/usr/local/lib/libevas.so.1(evas_render_mapped+0x63f)[0xb7d2f15f]
/usr/local/lib/libevas.so.1(+0x6d71c)[0xb7d3271c]
/usr/local/lib/libecore_evas.so.1(+0x118b7)[0xb7c818b7]
/usr/local/lib/libecore_evas.so.1(+0xcc7e)[0xb7c7cc7e]
/usr/local/lib/libecore.so.1(_ecore_idle_enterer_call+0xff)[0xb7ca13af]
/usr/local/lib/libecore.so.1(+0x14a04)[0xb7ca3a04]
/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x1c8)[0xb777aaa8]
/lib/i386-linux-gnu/libglib-2.0.so.0(+0x41270)[0xb777b270]
/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x17b)[0xb777b92b]
/usr/local/lib/libecore.so.1(ecore_main_loop_begin+0x34)[0xb7ca5584]
/usr/local/lib/libelementary-ver-pre-svn-09.so.0(elm_run+0x17)[0xb7f4a647]
/usr/local/bin/elementary_test[0x8055c76]
/usr/local/bin/elementary_test[0x8055d2f]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0xb7a5ce37]
/usr/local/bin/elementary_test[0x8054521]
*

Program received signal SIGABRT, Aborted.
0xb7fe2832 in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0  0xb7fe2832 in ?? () from /lib/ld-linux.so.2
#1  0xb7a70e71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7a7434e in abort () at abort.c:92
#3  0xb7de942e in eina_threads_shutdown () at eina_main.c:368
#4  0xb7d425b1 in _evas_preload_thread_end (data=0x825e2e8) at evas_preload.c:58
#5  0xb7d42561 in _evas_preload_thread_done (target=0x825e2e8, 
type=EVAS_CALLBACK_MOUSE_IN, event_info=0x83003a0) at evas_preload.c:70
#6  0xb7d376e2 in evas_async_events_process () at evas_async_events.c:91
#7  0xb7d3f90a in evas_cache_image_load_data (im=0x84920a8) at 
evas_cache_image.c:1182
#8  0xb7d6e0f0 in evas_common_rgba_image_scalecache_do (ie=0x84920a8, 
dst=0x847ba40, dc=0x8235e60, smooth=1, src_region_x=0, src_region_y=0, 
src_region_w=48, src_region_h=67, 
dst_region_x=101, dst_region_y=69, dst_region_w=48, dst_region_h=67) at 
evas_image_scalecache.c:558
#9  0xb7fc8c88 in eng_image_draw (data=0x8363af8, context=0x8235e60, 
surface=0x847ba40, image=0x84920a8, src_x=0, src_y=0, src_w=48, src_h=67, 
dst_x=101, dst_y=69, dst_w=48, 
dst_h=67, smooth=1) at evas_engine.c:544
#10 0xb7cee75b in evas_object_image_render (obj=0xb697de60, output=0x8363af8, 
context=0x8235e60, surface=0x847ba40, x=0, y=0) at evas_object_image.c:3111
#11 0xb7d2f15f in evas_render_mapped (e=0x840a340, obj=0xb697de60, 
context=0x8235e60, surface=0x847ba40, off_x=0, off_y=0, mapped=0, ecx=0, ecy=0, 
ecw=320, ech=480)
at evas_render.c:1268
#12 0xb7d3271c in evas_render_updates_internal (e=, 
make_updates=1 '\001', do_draw=1 '\001') at evas_render.c:1585
#13 0xb7c818b7 in _ecore_evas_x_render (ee=0x810f2b8) at ecore_evas_x.c:256
#14 0xb7c7cc7e in _ecore_evas_idle_enter (data=0x0) at ecore_evas.c:52
#15 0xb7ca13af in _ecore_call_task_cb () at ecore_private.h:264
#16 _ecore_idle_enterer_call () at ecore_idle_enterer.c:164
#17 0xb7ca3a04 in _ecore_main_gsource_dispatch (source=0x80b9170, callback=0, 
user_data=0x0) at ecore_main.c:706
#18 0xb777aaa8 in g_main_dispatch (context=0x80ba280) at 
/build/buildd/glib2.0-2.28.6/./glib/gmain.c:2440
#19 g_main_context_dispatch (context=0x80ba280) at 
/build/buildd/glib2.0-2.28.6/./glib/gmain.c:3013
#20 0xb777b270 in g_main_context_iterate (context=0x80ba280, block=-1216825312, 
dispatch=1, self=) at 
/build/buildd/glib2.0-2.28.6/./glib/gmain.c:3091
#21 0xb777b92b in g_main_loop_run (loop=0x840cb18) at 
/build/buildd/glib2.0-2.28.6/./glib/gmain.c:3299
#22 0xb7ca5584 in ecore_main_loop_begin () at ecore_main.c:893
#23 0xb7f4a647 in elm_run () at elm_main.c:828
#24 0x08055c76 in elm_main (argc=1, argv=0xb2a4) at test.c:604
#25 0x08055d2f in main (argc=1, argv=0xb2a4) at test.c:613

-

Re: [E-devel] Eina_Clist - Request for clarifications

[Mike McCormack]

On 10/18/2011 05:43 PM, Tom Hacohen wrote:
> On 18/10/11 10:37, Carsten Haitzler (The Rasterman) wrote:
>> you don't have to use it... :)
> 
> That's hardly a valid point. :)
> Using the same logic, I might as well add a flight simulator to eina.
> 
> I only ask because I care about the amount of code/API we need to 
> maintain, efl's memory footprint, and not confusing users with 734 types 
> of list to choose from.
> 
> After seeing cedric's reply, I see it's a circular list, I guess that's 
> some justification for having it.

Hi Tom,

Sorry for the delayed reply, I was OOO for 2 weeks.

The clist code comes from Wine's linked list implementation:
http://source.winehq.org/git/wine.git/blob/HEAD:/include/wine/list.h

It's a circularly linked list with an anchor node.  The advantages of
using this over Eina_Inlist are:

 - uses less memory (two machine words per item)
 - allows removing items without knowing which list they're in using O(1) time
 - no need to keep updating the head pointer as the list is changed
 - insert and remove a slightly more efficient (no NULL pointer checks)

It's useful when you want to keep the same item in multiple lists, because you
don't need to keep track of which list it's in when you're removing it.

See this example of how to use it:
http://trac.enlightenment.org/e/changeset/64030/trunk/evas/src/lib/canvas/evas_object_smart.c

The catch is there's no NULL at the end of the list when iterating, so
you need to know the anchor node when moving along the list (unlike 
Eina_Inlist).

thanks,

Mike

--
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/elementary/src/lib

[Mike McCormack]

On 10/12/2011 05:32 PM, ChunEon Park wrote:
> If no one does agree this API by tomorrow, then I will remove it again. 
> Thanks. 

Seeing it is wrong, we should also remove it internally.

thanks,

Mike

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/elementary/src/lib

[Mike McCormack]

On 10/12/2011 03:30 PM, ChunEon Park wrote:
> Is this a proper API ?

Clearly, somebody thinks so otherwise they wouldn't have written it.
If you think it's wrong, please delete it.

thanks,

Mike

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/edje/src/bin

[Mike McCormack]

On 10/12/2011 04:14 AM, Gustavo Sverzut Barbieri wrote:
> ahahahahaha... this is funny. Aside from embryo code, it's trivial to
> regenerate the source. Actually editje willl use that function as it ignores
> the actual edc contents and creates from eet structures.

Yes, I know decompilation is trivial.  The purpose of the patch is to:

1) synchronize with a patch somebody wrote internally (not me)
2) allow saving some disk space 

Actually, the internal implementation was just to comment out the relevant code,
so I'm trying to clean it up.

thanks,

Mike

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] evas: Use inlists to store the render recalculation list

[Mike McCormack]

Rebuild eina first, otherwise this won't build.

thanks,

Mike
>From f36e1a67f8f58b65c1fd1452ca692e4f2edc87ee Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Wed, 12 Oct 2011 15:07:30 +0900
Subject: [PATCH] evas: Use inlists to store the render recalculation list

Signed-off-by: Mike McCormack 
---
 evas/src/lib/canvas/evas_main.c |3 +-
 evas/src/lib/canvas/evas_object_smart.c |   79 --
 evas/src/lib/include/evas_private.h |4 +-
 3 files changed, 35 insertions(+), 51 deletions(-)

diff --git a/evas/src/lib/canvas/evas_main.c b/evas/src/lib/canvas/evas_main.c
index d3e4c8c..c658fb1 100644
--- a/evas/src/lib/canvas/evas_main.c
+++ b/evas/src/lib/canvas/evas_main.c
@@ -120,6 +120,7 @@ evas_new(void)
e->viewport.h = 1;
e->hinting = EVAS_FONT_HINTING_BYTECODE;
e->name_hash = eina_hash_string_superfast_new(NULL);
+   eina_clist_init(&e->calc_list);
 
 #define EVAS_ARRAY_SET(E, Array)		\
eina_array_step_set(&E->Array, sizeof (E->Array), 4096);
@@ -253,8 +254,6 @@ evas_free(Evas *e)
EINA_LIST_FREE(e->touch_points, touch_point)
  free(touch_point);
 
-   eina_list_free(e->calc_list);
-   
e->magic = 0;
free(e);
 }
diff --git a/evas/src/lib/canvas/evas_object_smart.c b/evas/src/lib/canvas/evas_object_smart.c
index f516aa7..66f198e 100644
--- a/evas/src/lib/canvas/evas_object_smart.c
+++ b/evas/src/lib/canvas/evas_object_smart.c
@@ -11,7 +11,6 @@ struct _Evas_Object_Smart
void *data;
Eina_List*callbacks;
Eina_Inlist  *contained;
-   Eina_List*calc_node;
Evas_Smart_Cb_Description_Array callbacks_descriptions;
int   walking_list;
Eina_Bool deletions_waiting : 1;
@@ -551,38 +550,16 @@ evas_object_smart_need_recalculate_set(Evas_Object *obj, Eina_Bool value)
 
// XXX: do i need this?
if (obj->delete_me) return;
-  
+
+   /* remove this entry from any list it is in */
+   if (obj->calc_entry.next)
+ eina_clist_remove(&obj->calc_entry);
+   obj->calc_entry.next = NULL;
+
value = !!value;
if (value)
- {
-Evas *e = obj->layer->evas;
-
-if (o->need_recalculate)
-  {
- if ((o->calc_node) && (e->calc_list_current != o->calc_node))
-e->calc_list = eina_list_demote_list(e->calc_list,
- o->calc_node);
- else
-e->calc_list = eina_list_append(e->calc_list, obj);
-  }
-else
-   e->calc_list = eina_list_append(e->calc_list, obj);
-o->calc_node = eina_list_last(e->calc_list);
-  }
-   else
- {
-Evas *e = obj->layer->evas;
-
-if (o->need_recalculate)
-  {
- if ((o->calc_node) && (e->calc_list_current != o->calc_node))
-e->calc_list = eina_list_remove_list(e->calc_list,
- o->calc_node);
- o->calc_node = NULL;
- 
-  }
-  }
-   
+ eina_clist_add_tail(&obj->layer->evas->calc_list, &obj->calc_entry);
+
if (o->need_recalculate == value) return;
 
if (obj->recalculate_cycle > 256)
@@ -654,32 +631,42 @@ evas_smart_objects_calculate_count_get(const Evas *e)
 void
 evas_call_smarts_calculate(Evas *e)
 {
-   Evas_Object *obj;
-   Eina_List *l;
+   Eina_Clist processed = EINA_CLIST_INIT(processed);
 
 //   printf("+CALC---v\n");
evas_event_freeze(e);
e->in_smart_calc++;
-   
-   EINA_LIST_FOREACH(e->calc_list, l, obj)
+
+   while (!eina_clist_empty(&e->calc_list))
  {
-Evas_Object_Smart *o = obj->object_data;
-
+Evas_Object_Smart *o;
+Eina_Clist *elem = eina_clist_head(&e->calc_list);
+Evas_Object *obj = EINA_CLIST_ENTRY(elem, Evas_Object, calc_entry);
+
+/* move the item to the processed list */
+eina_clist_remove(&obj->calc_entry);
 if (obj->delete_me) continue;
-e->calc_list_current = l;
+eina_clist_add_tail(&processed, &obj->calc_entry);
+
+o = obj->object_data;
+
 if (o->need_recalculate)
   {
  o->need_recalculate = 0;
  obj->smart.smart->smart_class->calculate(obj);
   }
-if (o->calc_node == l) o->calc_node = NULL;
-e->calc_list_current = NULL;
  }
-   EINA_LIST_FREE(e->calc_list, obj)
+
+   while (!eina_clist_empty(&processed))
  {
+Eina_Clist *elem = eina_clist_head(&processed);
+Evas_Object *obj = EINA_CLIST_ENTRY(elem, Evas_Object, calc_entry);
+
 obj->recalculate_cycle = 0;
+eina_clist_rem

Re: [E-devel] ecore: remove bad macro from ecore.

[Mike McCormack]

Hi Cedric,

Did you even check that your code for the following two commits worked?

@62240
eina: add generic macro to generate error when outside of the main loop.

@62241
ecore: remove bad macro from ecore.

It's good to know that constant accusations of "broken" and "bad" code
come from somebody who doesn't even bother to check that things work.

So we fail if we're in the main loop thread and only if EINA_HAVE_DEBUG_THREADS
is enabled, which it isn't by default, which makes the checks I have added
for threads both disabled and borken.

FYI, we just hit a problem internally where somebody was calling 
ecore_event_add()
from a thread.  I guess we have to tell everybody to RTFM yet again rather
than fix the thinko in ecore.

thanks,

Mike



#ifdef EINA_HAVE_DEBUG_THREADS
# define EINA_MAIN_LOOP_CHECK_RETURN_VAL(val)   \
  do {  \
if (EINA_UNLIKELY(eina_main_loop_is())) \
  { \
eina_error_set(EINA_ERROR_NOT_MAIN_LOOP);   \



mike@mike-desktop:~/git/e$ elementary_test
ERR<22880>: ecore_app.c:40 ecore_app_args_set() You are calling 
ecore_app_args_set from outsideof the main loop threads in ecore_app.c at line 
40
ERR<22880>: ecore_app.c:40 ecore_app_args_set() You are calling 
ecore_app_args_set from outsideof the main loop threads in ecore_app.c at line 
40
ERR<22880>: ecore_app.c:62 ecore_app_args_get() You are calling 
ecore_app_args_get from outsideof the main loop threads in ecore_app.c at line 
62
Segmentation fault

--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/ecore/src/lib/ecore

[Mike McCormack]

On 08/12/2011 05:13 PM, Vincent Torri wrote:

> So my remark was more a question : should we check if eina has threads 
> enabled or not in ecore's configure.ac ?

It's a good idea.  I will have a go at doing that.

thanks,

Mike

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/ecore/src/lib/ecore

[Mike McCormack]

On 08/12/2011 02:28 PM, Vincent Torri wrote:
> 
> it seems to me that if eina is not build with threading support, there is 
> not a lot of thread safety in ecore

Seems correct to me...

If you don't want threads, then you don't need thread safety, right?

thanks,

Mike

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/29/2011 05:56 PM, Cedric BAIL wrote:

> Then take that pseudo example :
> 
> Eina_Bool _timer_in_main_loop(void *data)
> {
>;
 lock_data_mutex();
 if (!data_was_deleted)
   {
>free(data);
   }
 data_was_deleted = Eina_True;
 unlock_data_mutex();
>return 0;
> }
> 
> void bad_idea()
> {
>tuttut = ecore_timer_add(unlucky, _timer_in_main_loop, something);
>...;
> 
>if (bad_happen)
>   {
  lock_data_mutex();
  if (!data_was_deleted)
{
> ecore_timer_del(tuttut);
> free(something);
}
  data_was_deleted = Eina_True;
  unlock_data_mutex();
>   }
> }
> 
> This code will work just fine in the main loop. Now in a thread it's
> full of race condition and double free. Tell me how you can make it
> work ? 

Add a mutex. See above.

Nobody said threaded programming is easy.  I'm just adding one tool.
Maybe you don't want to use this tool, that's OK.  Maybe you want to
provide a different way to do it, that's OK too.  Maybe you want to
make a law against using threads with ecore in EFL code, that's OK too.
Saying the tool itself is bad is a non-started, IMO.

The fact is, people already write this kind of racy code.  They think
it works, and when it crashes in ecore, EFL gets the blame.

So you can stand stubbornly refuse to fix it, or move the problem to 
their code, so it will crash outside of ecore, and people will not
blame EFL.

Additionally, people who grok threads well (admittedly not many)
can write code that works with ecore main loop.

Support choice, and suggest the best way.

>As far as I know, Cocoa, GTK, Qt and Win32 are not thread safe, and
> nobody complain about that. 

I know Win32's main loop is thread safe.

thanks,

Mike

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 10:35 PM, Cedric BAIL wrote:
> As I don't want the grumpy guy that don't help. You now have
> ecore_main_loop_thread_safe_call that should be the base for your
> patch. And I am still not convinced that we need more than that.
> People should just use that function when they are doing thread stuff
> and we should advertise it in our thread spanking message.

OK, thanks for spending the time to write this.

If you know you're writing code that's in a thread your function is
great.  Call it, and then schedule some work in the main loop, it's 
good.

But for a library writer:

1) assume thread safety (1 line):

ecore_event_add(LIB_EVENT, e, my_event_free, NULL);


2) Using ecore_main_loop_thread_safe_call (5 lines)

static void _event_main_loop_callback(void *data)
{
   ecore_event_add(LIB_EVENT, e, my_event_free, NULL);
}

/* will always be marshalled through pipe, even when not necessary */
ecore_main_loop_thread_safe_call(&_event_main_loop_callback, NULL);


3) Using ecore_main_loop_thread_safe_call, trying to be a bit more
   efficient (8 lines)

static void _event_main_loop_callback(void *data)
{
   ecore_event_add(LIB_EVENT, e, my_event_free, NULL);
}

if (!ecore_is_main_loop_thread())  /* assuming this function exists */
  ecore_main_loop_thread_safe_call(&_event_main_loop_callback, NULL);
else
  _event_main_loop_callback();

Case 2 & 3 are more verbose, and you need to add such code for *every* 
call to ecore (in a library).

So you end up pushing responsibilities to the library writers and 
applications that are better handled in Ecore itself.

IOW, it makes writing ecore code with threads a pain in the butt,
and reduces the potential audience of EFL.

thanks,

Mike

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/ecore: . src/lib/ecore

[Mike McCormack]

On 07/28/2011 09:19 PM, Vincent Torri wrote:

> like cedric, i'm against such feature. Are you (or samsung ?) just 
> ignoring the opinions of other devs ?

Well, I have to say it's a bit frustrating that you guys take the attitude
that it's forbidden to add a feature that some guys think is beneficial.

True, this feature changes the rules a bit.

I don't think it's as harmful to performance as Cedric believes, or
difficult to debug, or obfuscates the code.

I added the code so you guys can see what I've done, review it, build it,
test it, and comment on it.  It's not enabled.  That is the EFL way.

I'm not a fan of threaded programming, and I avoid threads in my own 
programs, however I don't think forcing non-threaded style on everybody
is cool.

Recommend against threads, and don't use them -> GOOD
Prohibit use, and make sure that nobody can ever use a thread with Ecore -> BAD

Nobody in Samsung has pushed me to do this.  I have spent a lot of time
(>1 year) on main loop issues (integration with glib, recommending best
practices for main loops, etc) in Samsung, and based on that I created
this patch.

thanks,

Mike

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 09:31 PM, Cedric BAIL wrote:

> Before providing a benchmark, please revert your broken code and
> provide a working solution based on my discussion with gustavo (using
> Ecore_Pipe). Right know, and before doing benchmark, your solution
> doesn't work in all case and that's a no go for me. It's already
> painfull for us when we use thread that I don't want to dig why some
> user have weird behaviour due to this half working solution.

Hi Cedric,

I haven't gotten any mail to Gustavo from you.  Please resend it.

What is broken?  Which case does it not work for?

My code adds a single mutex, which only ecore can see.

The rules for use are fairly simple:
* lock the mutex on entering ecore code
* unlock the mutex on leaving ecore code
* don't call functions that lock the mutex from within ecore

Secondly, this code is disabled, so it shouldn't affect anything right now.
As I understand, it's normal in EFL development to add code that is disabled,
debug it, then enable it later when it works.

thanks,

Mike



--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 08:18 PM, Vincent Torri wrote:

>> I have already added code to print warnings.  It helps, but the response is
>> usually, "but why isn't EFL thread safe?"
> 
> tell them to read the preamble there :
> 
> http://docs.enlightenment.org/auto/ecore/Ecore_Main_Loop_Page.html

Well, after repeating myself N times, it's reasonable to wonder
whether we're violating the principle of least surprise, then go
fix/remove the surprise.

If you want me to run benchmarks to show performance impact of the
change, let me know which ones will be appropriate.

thanks,

Mike

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/28/2011 07:32 PM, Cedric BAIL wrote:

> Maybe stable, but the rendered scene will not make sense and be highly
> difficult to debug. So spank and point people to the right solution.

This is ecore, not evas.  Adding timers from a thread makes sense to me.

I'm not proposing this as a solution for Evas.  Perhaps adding a thread
check is better there... I haven't looked at it closely.

>> * nobody complained when I added checks to show that ecore calls are coming
>>  from the same thread, even though the performance "impact" would be 
>> comparable.
>>  (See ECORE_MAIN_LOOP_ASSERT)
> 
> Because if needed, we can turn it off without breaking application or
> any behaviour. Something that was working with it on will work with it
> off. It something that we could use in a development build and remove
> from the production build without the need to worry about it at all.

If you're worried about this, how about I add a function call that
can set the _ecore_lock() and _ecore_unlock() functions.  If they are
NULL, the won't be called.

Also, if you worry so much about performance, please let me know what
benchmarking you want done to show the overhead.

> I thing that this will get confusing and people will introduce more
> bug, because the barrier with thread safety will be blured, some
> function call will work, some won't. At the end, I think you are
> increasing the complexity of the EFL without any benefit, you will
> have more and more complex code to debug (because every thing will not
> be thread safe). I really am more for a macro that display a spank
> with backtrace and do nothing in all efl function call (including
> evas, edje and elementary), that point to Ecore_Thread documentation.
> In fact halt of that code is already provided by eina, I can provide
> it quickly if that feat your need. This will put the burden of the fix
> on the developer and not you. They will know exactly where and how to
> fix it.

I have already added code to print warnings.  It helps, but the response is
usually, "but why isn't EFL thread safe?"

Adding thread safety means:

* one whole class of API misuse and potential problems is gone
* people who think they know what they're doing can use threads without 
  worrying that ecore is a source of problems
* we offer the same features to 3rd parties as we want to use inside EFL.

It's a bit hypocritical to say "Well, the EVAS code can use threads, 
because we're E-lite developers, but users of our API should never be able
to use threads, and should get spanked for doing so."

thanks,

Mike


--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

On 07/27/2011 10:08 PM, Cedric BAIL wrote:

> So it will most of the time work, but in some racy case, not. Sounds
> to me like this doesn't change much from the current behaviour. I
> agree, it will work more often than previously, but still hidding bug
> until it's to late.

It is a change it goal.  The goal will be to make ecore calls thread safe,
and any non-thread safe behavior is a bug.

> People should never use things they don't understand... and so few
> people understand threads. Just one question, do they use ecore_thread
> or there own stuff ?

I disagree with "people should never use things they don't understand".

The whole point of a library or any other programming abstraction is
to hide details and save people reimplementing these things over and over
themselves.

Some developers in Samsung use ecore_thread, and some don't.  Honestly,
ECORE_MAIN_LOOP_ASSERT has shown up quite a few problems with code.
Though the majority of developers understand that EFL code should be
single threaded, there are still many crashes due to threading issues.
I think EFL will be seen as "more stable" if it is thread safe... thus
these patches.

> You can't make it work sanely, how are you planning to synchronize the
> rendering state with your request from a thread. It's just not

Let's stick to technical stuff rather than abstract ideas like sanity.

I'm only talking about ecore here.  Step by step... (Raster has big plans
for the rendering engine involving threads.)

If the code is lacking in one area or the other, please point it out.
(Actually, some big bits, like locks around the idlers are missing from
the patch I sent.)

> I clearly disagree on that patch going in (and I am still not
> discussing the issue of performance here).

Well three points:

* nobody complained when I added checks to show that ecore calls are coming
  from the same thread, even though the performance "impact" would be 
comparable.
  (See ECORE_MAIN_LOOP_ASSERT)

* given that SMP is widely available these days, I would think that
  enabling simple thread based programming could dramatically improve
  performance of some code.

* I will provide a way to switch off thread safety at build time

Right now my thoughts are:

* support single main loop only
* add support for waking the main loop when timers, fds, etc. are added

thanks,

Mike

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] ecore: Add basic thread safety

[Mike McCormack]

Hi All,

This patch adds some level of thread safety to ecore.
It does not add thread awareness (i.e. adding a timer from a thread will not
wake a sleeping main loop).

In my experience, developers either are ignorant of the problems of threads, 
or expect libraries to magically work with threads.

I understand that some people think that thread safety is not necessary, but
IMO, the performance cost and complexity is easily outweighed by the benefit
of meeting developer expectation.

thanks,

Mike
>From a60fdaaa7830531a974e51cebc6efe45719e17bf Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Wed, 6 Jul 2011 20:20:11 +0900
Subject: [PATCH] ecore: Add basic thread safety

Signed-off-by: Mike McCormack 
---
 ecore/src/lib/ecore/ecore_events.c   |2 +
 ecore/src/lib/ecore/ecore_idle_enterer.c |6 +-
 ecore/src/lib/ecore/ecore_idle_exiter.c  |7 ++-
 ecore/src/lib/ecore/ecore_idler.c|7 ++-
 ecore/src/lib/ecore/ecore_main.c |   87 ++-
 ecore/src/lib/ecore/ecore_private.h  |3 +
 ecore/src/lib/ecore/ecore_thread.c   |   27 ++
 ecore/src/lib/ecore/ecore_timer.c|  141 --
 8 files changed, 208 insertions(+), 72 deletions(-)

diff --git a/ecore/src/lib/ecore/ecore_events.c b/ecore/src/lib/ecore/ecore_events.c
index c1f4658..d2ee983 100644
--- a/ecore/src/lib/ecore/ecore_events.c
+++ b/ecore/src/lib/ecore/ecore_events.c
@@ -690,7 +690,9 @@ _ecore_event_call(void)
handle_count++;
 
eh->references++;
+   _ecore_unlock();
ret = eh->func(eh->data, e->type, e->event);
+   _ecore_lock();
eh->references--;
 
if (!ret)
diff --git a/ecore/src/lib/ecore/ecore_idle_enterer.c b/ecore/src/lib/ecore/ecore_idle_enterer.c
index 9802895..9244cc5 100644
--- a/ecore/src/lib/ecore/ecore_idle_enterer.c
+++ b/ecore/src/lib/ecore/ecore_idle_enterer.c
@@ -154,8 +154,12 @@ _ecore_idle_enterer_call(void)
 Ecore_Idle_Enterer *ie = (Ecore_Idle_Enterer *)idle_enterer_current;
 if (!ie->delete_me)
   {
+ Eina_Bool ret;
  ie->references++;
- if (!ie->func(ie->data))
+ _ecore_unlock();
+ ret = ie->func(ie->data);
+ _ecore_lock();
+ if (!ret)
{
   if (!ie->delete_me) ecore_idle_enterer_del(ie);
}
diff --git a/ecore/src/lib/ecore/ecore_idle_exiter.c b/ecore/src/lib/ecore/ecore_idle_exiter.c
index c8abb87..1006e8d 100644
--- a/ecore/src/lib/ecore/ecore_idle_exiter.c
+++ b/ecore/src/lib/ecore/ecore_idle_exiter.c
@@ -126,8 +126,13 @@ _ecore_idle_exiter_call(void)
 Ecore_Idle_Exiter *ie = (Ecore_Idle_Exiter *)idle_exiter_current;
 if (!ie->delete_me)
   {
+ Eina_Bool ret;
+
  ie->references++;
- if (!ie->func(ie->data))
+ _ecore_unlock();
+ ret = ie->func(ie->data);
+ _ecore_lock();
+ if (!ret)
{
   if (!ie->delete_me) ecore_idle_exiter_del(ie);
}
diff --git a/ecore/src/lib/ecore/ecore_idler.c b/ecore/src/lib/ecore/ecore_idler.c
index af43c31..db77dcf 100644
--- a/ecore/src/lib/ecore/ecore_idler.c
+++ b/ecore/src/lib/ecore/ecore_idler.c
@@ -160,8 +160,13 @@ _ecore_idler_call(void)
 Ecore_Idler *ie = (Ecore_Idler *)idler_current;
 if (!ie->delete_me)
   {
+ Eina_Bool ret;
+
  ie->references++;
- if (!ie->func(ie->data))
+ _ecore_unlock();
+ ret = ie->func(ie->data);
+ _ecore_lock();
+ if (!ret)
{
   if (!ie->delete_me) ecore_idler_del(ie);
}
diff --git a/ecore/src/lib/ecore/ecore_main.c b/ecore/src/lib/ecore/ecore_main.c
index 53d7a8a..cf644d6 100644
--- a/ecore/src/lib/ecore/ecore_main.c
+++ b/ecore/src/lib/ecore/ecore_main.c
@@ -488,6 +488,7 @@ _ecore_main_gsource_prepare(GSource *source __UNUSED__, gint *next_time)
 {
gboolean ready = FALSE;
 
+   _ecore_lock();
in_main_loop++;
 
if (!ecore_idling && !_ecore_glib_idle_enterer_called)
@@ -566,6 +567,7 @@ _ecore_main_gsource_prepare(GSource *source __UNUSED__, gint *next_time)
 
in_main_loop--;
INF("leave, timeout = %d", *next_time);
+   _ecore_unlock();
 
/* ready if we're not running (about to quit) */
return ready;
@@ -576,6 +578,7 @@ _ecore_main_gsource_check(GSource *source __UNUSED__)
 {
gboolean ret = FALSE;
 
+   _ecore_lock();
in_main_loop++;
 
/* check if old timers expired */
@@ -615,6 +618,7 @@ _ecore_main_gsource_check(GSource *source __UNUSED__)
  ret = (0.0 == _ecore_timer_next_get());
 
in_main_loop--;
+   _ecore

Re: [E-devel] E SVN: devilhorns trunk/e/src/bin

[Mike McCormack]

On 07/26/2011 11:23 PM, Christopher Michael wrote:
> Heh yea :( pretty odd, but I haven't stopped to look into why yet :) I 
> just fixed it and moved on ;) Will look into 'why' later :)

Hopefully SVN @61783 will fix it.

thanks,

Mike

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/PROTO/elev8: data/javascript src/bin

[Mike McCormack]

On 07/21/2011 10:18 AM, Mike Blumenkrantz wrote:

>>   trunk/PROTO/elev8/data/javascript/clock.js 
>> trunk/PROTO/elev8/src/bin/elm.cc 
> are there // will there be docs for elev8? I have some people who would
> probably be interested in using/contributing to it...

What kind of docs are you looking for?  The javascript API is documented by 
example, and internally there's some comments on what I've tried to do.

thanks,

Mike

--
5 Ways to Improve & Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-deve][Patch] Animation gif patch

[Mike McCormack]

On 07/19/2011 03:49 AM, Jiyoun Park wrote:

> I made patch related with animation gif.

Hi Jiyoun,

I've suggested some changes (formatting & other) in the 
attached patch, which applies on top of yours.

thanks,

Mike
diff --git a/evas/src/lib/include/evas_common.h b/evas/src/lib/include/evas_common.h
index 7e33b96..e556985 100644
--- a/evas/src/lib/include/evas_common.h
+++ b/evas/src/lib/include/evas_common.h
@@ -511,7 +511,7 @@ struct _Image_Entry_Flags
Eina_Bool delete_me: 1;
Eina_Bool pending  : 1;
 #endif
-   Eina_Bool animated :1;
+   Eina_Bool animated : 1;
 };
 
 struct _Evas_Cache_Target
@@ -595,13 +595,12 @@ struct _Image_Entry
intchannel;
intload_error;
 
-   /* for animation feature */ 
+   /* for animation feature */
intframe_count;
Evas_Image_Animated_Loop_Hint loop_hint;
intloop_count;
intcur_frame;
-   Eina_List   *frames;
-
+   Eina_List *frames;
 };
 
 struct _Engine_Image_Entry
diff --git a/evas/src/modules/engines/software_generic/evas_engine.c b/evas/src/modules/engines/software_generic/evas_engine.c
index a66b65d..5396117 100644
--- a/evas/src/modules/engines/software_generic/evas_engine.c
+++ b/evas/src/modules/engines/software_generic/evas_engine.c
@@ -652,7 +652,7 @@ eng_image_scale_hint_get(void *data __UNUSED__, void *image)
 }
 
 static Eina_Bool
-eng_image_animated_get  (void *data __UNUSED__, void *image)
+eng_image_animated_get(void *data __UNUSED__, void *image)
 {
Image_Entry *im;
 
@@ -662,7 +662,7 @@ eng_image_animated_get  (void *data __UNUSED__, void *image)
 }
 
 static int
-eng_image_animated_frame_count_get (void *data __UNUSED__, void *image)
+eng_image_animated_frame_count_get(void *data __UNUSED__, void *image)
 {
Image_Entry *im;
 
@@ -673,7 +673,7 @@ eng_image_animated_frame_count_get (void *data __UNUSED__, void *image)
 }
 
 static Evas_Image_Animated_Loop_Hint
-eng_image_animated_loop_type_get (void *data __UNUSED__, void *image)
+eng_image_animated_loop_type_get(void *data __UNUSED__, void *image)
 {
Image_Entry *im;
 
@@ -684,7 +684,7 @@ eng_image_animated_loop_type_get (void *data __UNUSED__, void *image)
 }
 
 static int
-eng_image_animated_loop_count_get (void *data __UNUSED__, void *image)
+eng_image_animated_loop_count_get(void *data __UNUSED__, void *image)
 {
Image_Entry *im;
 
@@ -695,7 +695,7 @@ eng_image_animated_loop_count_get (void *data __UNUSED__, void *image)
 }
 
 static double
-eng_image_animated_frame_duration_get (void *data __UNUSED__, void *image, int start_frame, int frame_num)
+eng_image_animated_frame_duration_get(void *data __UNUSED__, void *image, int start_frame, int frame_num)
 {
Image_Entry *im;
 
@@ -706,7 +706,7 @@ eng_image_animated_frame_duration_get (void *data __UNUSED__, void *image, int s
 }
 
 static Eina_Bool
-eng_image_animated_frame_set (void *data __UNUSED__, void *image, int frame_index)
+eng_image_animated_frame_set(void *data __UNUSED__, void *image, int frame_index)
 {
Image_Entry *im;
 
@@ -714,7 +714,6 @@ eng_image_animated_frame_set (void *data __UNUSED__, void *image, int frame_inde
im = image;
if (!im->flags.animated) return EINA_FALSE;
if (im->cur_frame == frame_index) return EINA_FALSE;
-printf("[%s][%d] frame=%d  before: %d after: %d\n",__FUNCTION__,__LINE__,frame_index,im->cur_frame,frame_index);
im->cur_frame = frame_index;
return EINA_TRUE;
 }
diff --git a/evas/src/modules/loaders/gif/evas_image_load_gif.c b/evas/src/modules/loaders/gif/evas_image_load_gif.c
index 0f50951..e7e9afa 100644
--- a/evas/src/modules/loaders/gif/evas_image_load_gif.c
+++ b/evas/src/modules/loaders/gif/evas_image_load_gif.c
@@ -83,13 +83,13 @@ _find_frame(Image_Entry *ie, int frame_index, Gif_Frame **frame)
 static Eina_Bool
 _find_close_frame(Image_Entry *ie, int frame_index, Gif_Frame **frame)
 {
-  if (!ie) return EINA_FALSE;
-  if (!ie->frames) return EINA_FALSE;
-
   int i;
   Eina_Bool hit = EINA_FALSE;
   i = frame_index -1;
 
+  if (!ie) return EINA_FALSE;
+  if (!ie->frames) return EINA_FALSE;
+
   for ( ; i > 0 ; i--)
 {
hit = _find_frame(ie, i,frame );
@@ -102,16 +102,15 @@ _find_close_frame(Image_Entry *ie, int frame_index, Gif_Frame **frame)
 static Eina_Bool
 _evas_image_skip_frame(GifFileType *gif, int frame)
 {
-   Eina_Bool res = EINA_FALSE;
-   int remain_frame = 0;
+   Eina_Bool   res = EINA_FALSE;
+   int remain_frame = 0;
GifRecordType   rec;
 
if (!gif) return res;
-   if (frame == 0) return EINA_TRUE; //it is not need skip any thing
+   if (frame == 0) return EINA_TRUE; /* no need to skip */
if (frame < 0 || frame > FRAME_MAX) return EINA_FALSE;
 
remain_frame = frame;
-   static int ex_c=0, im_c=0 , im_f_c=0;
 
do
  {
@@ -119,8 +118,6 @@ _evas_image_skip_frame(GifFileType *gif, int frame)
 
 if (rec == EXTENSION_RECORD_T

Re: [E-devel] [PATCH] Display preedit in entry of E17

[Mike McCormack]

On 07/13/2011 12:56 PM, Jihoon Kim wrote:
> Hello, EFL developers.
> 
> The entry in E17 doesn't display preedit string.
> There has been no code to display the preedit string in e_entry.c.
> 
> This patch will make it be possible.
> 
> Would you please review this patch?

Committed to SVN @61389.

thanks,

Mike

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Add XIM module for ecore_imf

[Mike McCormack]

On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote:

> I attached some patches of XIM module of ecore_imf.
> 
> As far as I know, EFL has not having official ecore_imf module in E
> repository. And ecore_x has XIM code but is unavailable condition.
> So I moved XIM code of ecore_x as ecore_imf module.
> 
> please review this patches.

Committed to SVN:

@61257
@61258
@61259

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] elementary_test on WindowsXP

[Mike McCormack]

On 07/12/2011 10:01 AM, cnook wrote:

> 1. The elementary_test (based on Rev 61152) shows with black screen. but,
> the elementary_test of early of June (Rev 59900) shows properly.

Bisect it and find the faulty revision.  You can do this in git with 'git 
bisect'.

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] The bounce problem in the scroller.

[Mike McCormack]

On 07/11/2011 03:32 PM, Jaehwan Kim wrote:

> Please find the attachment. (patch file)

I think you forgot the attachment.

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/elementary/src: bin lib

[Mike McCormack]

On 07/11/2011 12:09 PM, Vincent Torri wrote:
> 
> 
> On Sun, 10 Jul 2011, Enlightenment SVN wrote:
> 
>> Log:
>> elementary: elementary_config.h is a local include
> 
> as -I$(top_builddir) is passed to CPPFLAGS, it's the same...

For some reason this #include  didn't work
for me last night when setting up a new machine.  Looks like
it might have been related to @61198 and @61193.

In any case we shouldn't use #include 
because we don't ever want the version from the system. 

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] fix _evas_jpeg_membuf_src_skip bug

[Mike McCormack]

On 07/09/2011 07:54 PM, Jiyoun Park wrote:

> There is an bug in _evas_jpeg_membuf_src_skip function. 
> 
>  
> 
> If file was corrupted , the size value of app frame is bigger than real file
> size. 
> 
> For example, if somebody change file using editor, the file start with (FF
> D8 FF E0 FF DB ..).
> 
> But rear file size can be small than (FF DB).
> 
>  
> 
> In that case, _evas_jpeg_membuf_src_skip set src->pub.bytes_in_buffer to
> negative value, it make crash later. 

Committed @r61222

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Add XIM module for ecore_imf

[Mike McCormack]

On 07/10/2011 02:51 AM, Naruto TAKAHASHI wrote:
> Hi Mike.
> 
> Thanks, feedback. I merged it to xim/Makefile.am.
> 
> I attach a source code for using XIM module debug.
> This program can check a below behaviors.
> 
>   - toggle enable and disable XIM
>   - commit string from XIM
> 
> Another test, by using Desktop Entry Editor's text field.
> (Enlightenment Main->Settings->Settings Panel->New Application)
> 
> When executing test program, set ECORE_IMF_MODULE=xim.

Hi Naruto,

I tried running the test program, but it crashes as below.  My XIM is Nabi.
Pressing a key in New application also crashes E (but only with 
ECORE_IMF_MODULE=xim).

thanks,

Mike


mike@mike-desktop:~/git/e/ecore$ cat /etc/issue
Ubuntu 10.04.1 LTS \n \l

mike@mike-desktop:~/git/e/ecore$ set | grep XIM
XIM=nabi
XIM_PROGRAM=/usr/bin/nabi

mike@mike-desktop:~/git/e/ecore$ grep ENABLE_XIM config.h
#define ENABLE_XIM 1

mike@mike-desktop:~/git/e/ecore$ echo $LANG
en_US.utf8

mike@mike-desktop:~/git/e/ecore$ ECORE_IMF_MODULE=xim gdb ./ecore_imf_test
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/mike/git/e/ecore/ecore_imf_test...(no debugging 
symbols found)...done.
(gdb) run
Starting program: /home/mike/git/e/ecore/ecore_imf_test 
[Thread debugging using libthread_db enabled]
** initializing ecore
** initializing ecore_evas
** initializing ecore_imf
** retrieving ecore_imf_context_available_ids_get
** available input methods: xim
** creating context

Program received signal SIGSEGV, Segmentation fault.
0x00632b2a in XCreateIC () from /usr/lib/libX11.so.6
(gdb) bt
#0  0x00632b2a in XCreateIC () from /usr/lib/libX11.so.6
#1  0x0094591f in get_ic (ctx=0x8092980, type=ECORE_IMF_EVENT_KEY_DOWN, 
event=0xbfffeec0)
at ecore_imf_xim.c:893
#2  _ecore_imf_context_xim_filter_event (ctx=0x8092980, 
type=ECORE_IMF_EVENT_KEY_DOWN, 
event=0xbfffeec0) at ecore_imf_xim.c:406
#3  0x003db79f in ecore_imf_context_filter_event (ctx=0xbfffecb4, 
type=ECORE_IMF_EVENT_KEY_DOWN, 
event=0xbfffeec0) at ecore_imf_context.c:735
#4  0x080490f8 in _e_entry_key_down_cb ()
#5  0x00147099 in evas_object_event_callback_call (obj=0xb7f77038, 
type=EVAS_CALLBACK_KEY_DOWN, 
event_info=0xbfffefa8) at evas_callbacks.c:224
#6  0x001498d6 in evas_event_feed_key_down (e=0x806bcd0, keyname=0x805c040 "b", 
key=0x805c042 "b", 
string=0x805c044 "b", compose=0x805c044 "b", timestamp=3267878762, 
data=0x0) at evas_events.c:1249
#7  0x00723cb4 in _ecore_event_evas_key (e=0x805c018, press=ECORE_DOWN) at 
ecore_input_evas.c:149
#8  0x002046e9 in _ecore_event_call () at ecore_events.c:693
#9  0x002089fb in _ecore_main_gsource_dispatch (source=0x804ef70, callback=0, 
user_data=0x0)
at ecore_main.c:656
#10 0x005275e5 in g_main_dispatch (context=0x804fe80)
at /build/buildd/glib2.0-2.24.0/glib/gmain.c:1960
#11 IA__g_main_context_dispatch (context=0x804fe80) at 
/build/buildd/glib2.0-2.24.0/glib/gmain.c:2513
#12 0x0052b2d8 in g_main_context_iterate (context=0x804fe80, block=, dispatch=1, 
self=0x806bf78) at /build/buildd/glib2.0-2.24.0/glib/gmain.c:2591
#13 0x0052b817 in IA__g_main_loop_run (loop=0x80819b0)
at /build/buildd/glib2.0-2.24.0/glib/gmain.c:2799
#14 0x002085d2 in ecore_main_loop_begin () at ecore_main.c:835
#15 0x080495db in main ()
(gdb) quit
A debugging session is active.

Inferior 1 [process 16010] will be killed.

Quit anyway? (y or n) y

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Add XIM module for ecore_imf

[Mike McCormack]

On 07/08/2011 03:15 PM, Naruto TAKAHASHI wrote:
> Hi, All.
> 
> I attached some patches of XIM module of ecore_imf.
> 
> As far as I know, EFL has not having official ecore_imf module in E
> repository. And ecore_x has XIM code but is unavailable condition.
> So I moved XIM code of ecore_x as ecore_imf module.
> 
> please review this patches.

Hello Naruto,

Looks like nice work.

I applied your patches to my ecore and built, but there was a build error (fix 
below):

make[5]: Entering directory `/home/mike/git/e/ecore/src/modules/immodules/xim'
  CC xim_la-ecore_imf_xim.lo
ecore_imf_xim.c:5:18: error: Evas.h: No such file or directory
ecore_imf_xim.c: In function ‘_ecore_x_event_reverse_locks’:
ecore_imf_xim.c:359: warning: suggest braces around empty body in an ‘if’ 
statement
ecore_imf_xim.c: In function ‘preedit_start_callback’:
ecore_imf_xim.c:662: warning: unused parameter ‘xic’
ecore_imf_xim.c:664: warning: unused parameter ‘call_data’

How can I test it?

thanks,

Mike



diff --git a/ecore/src/modules/immodules/xim/Makefile.am 
b/ecore/src/modules/immodules/xim/Makefile.am
index 006035c..cc0682d 100644
--- a/ecore/src/modules/immodules/xim/Makefile.am
+++ b/ecore/src/modules/immodules/xim/Makefile.am
@@ -12,6 +12,7 @@ AM_CPPFLAGS = \
 -I$(top_builddir)/src/lib/ecore_imf \
 -DPACKAGE_LIB_DIR=\"$(libdir)\" \
 -DPACKAGE_DATA_DIR=\"$(datadir)/$(PACKAGE)\" \
+@EVAS_CFLAGS@ \
 @EINA_CFLAGS@
 
 pkgdir = $(libdir)/ecore/immodules


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] Add some APIs for supporting virtual keyboard in Ecore_IMF

[Mike McCormack]

On 07/07/2011 07:50 PM, Jihoon Kim wrote:
> Hi, raster and EFL developers.
> 
> At revision 59894 (http://trac.enlightenment.org/e/changeset/59894) that my
> patch is applied,
> the function declarations is applied in svn, but I missed the implementation
> code of some APIs.
> 
> Would you please review this patch?

Commited @61114

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: hermet trunk/elementary/src/lib

[Mike McCormack]

On 07/06/2011 09:05 AM, Daniel Juyung Seo wrote:
> Well, that was not my point.
> I was asking using comments like
> /// is ok in e world.

It's redundant and distracting.


 variables /


 g_my_value declaration 
int g_my_value;


 functions /


 the_function declaration //
void the_function(void)
{
// set the variable to one
g_my_value = 1
}


// Coding standard requires useless 3 comments
// per line of code...
// Coding standard requires stating the obvious.


In programming, redundancy should be avoided.

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Renaming elm_object_label_set/get

[Mike McCormack]

On 07/04/2011 04:41 PM, Tom Hacohen wrote:

> What do you guys think? Should I rename them to elm_object_text_part_set/get?

Hey Tom,

How about this:

elm_object_label_set -> elm_object_text_part_set
elm_object_label_get -> elm_object_text_part_get

but keeping the elm_object_text_set/get macros as they are. i.e.

EAPI void elm_object_text_part_set(Evas_Object *obj, const char *item, const 
char *label);
#define elm_object_text_set(obj, label) elm_object_text_part_set((obj), NULL, 
(label))

I like elm_object_text_set() for the default part as it's short and simple.
Using "label_set" for the name was to keep it separate from "text_set", but
I agree "text_part_set" is good.

thanks,

Mike

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
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 src/lib/canvas

[Mike McCormack]

On 06/18/2011 08:50 AM, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 17 Jun 2011 13:41:43 -0300 Rafael Antognolli
>  said:

>>> -
>>> +* Allow to get packign location of table child

 ^ typo

>>> + * Get packgin location of a child of table

^ typo

Not the most exciting task, I know... :-/

thanks,

Mike

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Windows Installer

[Mike McCormack]

On 06/17/2011 07:09 PM, Lionel Orry wrote:

> that said, if someone can clearly confirm whether glib is a dependency 
> (optional
> or mandatory) for any EFL lib, I would gladly appreciate since I'm not 100% 
> sure
> either.

glib is a dependency of ecore if you want the ecore main loop to integrate with
the gmainloop. 

i.e. configure ecore with --enable-glib-integration-always or 
--enable-g-main-loop

thanks,

Mike

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m trunk/PROTO/elev8/src/bin

[Mike McCormack]

On 06/15/2011 07:31 PM, Gustavo Sverzut Barbieri wrote:
> On Wed, Jun 15, 2011 at 4:28 AM, Enlightenment SVN
>  wrote:
>> +   out->Set(v8::String::New("_eo"), v8::External::Wrap(eo));
> 
> Mike,
> 
> A hint for you is to store common strings in a pool and use their
> reference later. Good cases are "_eo" and property names such as
> "size", "color"... this way you avoid creating/destroying lots of them
> for simple and common queries... and may avoid typo errors as well.

Hey Gustavo,

Thanks for the hint.  I will try optimize it a bit more once I get
the structure looking right.  Right now, I'm trying to make
setting a property on an object in JavaScript update that property
in Evas immediately.

thanks,

Mike

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Working on Docs

[Mike McCormack]

On 06/15/2011 12:36 AM, Carsten Haitzler (The Rasterman) wrote:

> uncrustify solves all the formatting issues, we just need to apply it, but to
> apply it we need to have no pending work, patches or branches as it basically
> goes and edits pretty much every line of code. 

While having consistently formatted code is nice, I don't think using a tool
to automatically reformat all the code is worth it.

It will break "blame" functionality of revision control and as you point out,
break any pending patches.

If there's something really ugly, then maybe it's worth identifying and fixing,
but otherwise, fixing as you go is good.  Commit hooks can be used for pointing
out the problem, but shouldn't block commits.

thanks,

Mike


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: mike_m IN trunk/PROTO/elev8/data: . javascript

[Mike McCormack]

On 06/07/2011 04:29 PM, Nicolas Aguirre wrote:

>> Added:
>>  trunk/PROTO/elev8/data/javascript/
>> trunk/PROTO/elev8/data/javascript/button.js

> Im' just curious, but what's this javascript stuff ? What's the difference
> with elixir ?

Hi Nicholas,

Elixir wraps EFL function by function, however elev8 will abstract away the 
detail
of writing EFL applications.  

For example, main loops, windows and backgrounds will be created automatically.

It's still in the prototyping phase at the moment, so if anybody has any flames
or suggestions, please fire away :-)

thanks,

Mike

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] Fix g_main_loop integration

[Mike McCormack]

Busticated by this commit:

commit 5cdc9988d84f57e8cd548e9916ff03d84e6b4c5d
Author: raster 
Date:   Sat May 14 03:26:28 2011 +

optimization: don't need to get loop time so often in ecore main loop.


diff --git a/trunk/ecore/src/lib/ecore/ecore_main.c 
b/trunk/ecore/src/lib/ecore/ecore_main.c
index fbf9698..fd8c180 100644
--- a/trunk/ecore/src/lib/ecore/ecore_main.c
+++ b/trunk/ecore/src/lib/ecore/ecore_main.c
@@ -479,6 +479,7 @@ _ecore_main_gsource_check(GSource *source)
ecore_fds_ready = (_ecore_main_fdh_poll_mark_active() > 0);
_ecore_main_fd_handlers_cleanup();
 
+   _ecore_time_loop_time = ecore_time_get();
_ecore_timer_enable_new();
 
in_main_loop--;

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] Ecore exe - check kill() return value.

[Mike McCormack]

On 04/18/2011 03:14 PM, Vincent Torri wrote:
> 
> 
> On Mon, 18 Apr 2011, Mike McCormack wrote:
> 
>> On 04/17/2011 03:44 PM, Tom Hacohen wrote:
>>> If it's needed/important, we can possibly add
>>> "ecore_exe_pause_" or something like that :P
>>
>> That would be nicer than an "errno" style thing.  Global error values have
>> re-entrancy and thread-safety issues.  In libc it's thread local.
> 
> as the EFL are not thread safe, it's not a big issue

There's a difference between not being thread-safe and designing an API that 
can 
never be thread safe.

At least plan for the possible future.

thanks,

Mike

--
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] [Patch] Ecore exe - check kill() return value.

[Mike McCormack]

On 04/17/2011 03:44 PM, Tom Hacohen wrote:
> If it's needed/important, we can possibly add
> "ecore_exe_pause_" or something like that :P

That would be nicer than an "errno" style thing.  Global error values have
re-entrancy and thread-safety issues.  In libc it's thread local.

EFL returns void in way too many places for my liking.  It would be a good thing
to return an error codes in 2.0, or add extra calls in 1.0 as per Tom's 
suggestion.

Last time this was brought up, Raster said that void is returned to simplify
and avoid error handling code.  Having the information available doesn't
mean you have to write error handling code... it just means you can.

thanks,

Mike

--
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

[E-devel] [PATCH] Remove SIGRT stuff

[Mike McCormack]

Unused, and doesn't work as it stands.  Delete...

>From 9c69d092477801a6f7e59241d5652e6390e66046 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 24 Jan 2011 20:59:37 +0900
Subject: [PATCH] Remove SIGRT stuff

---
 trunk/ecore/src/lib/ecore/ecore_signal.c |   86 --
 1 files changed, 0 insertions(+), 86 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_signal.c b/trunk/ecore/src/lib/ecore/ecore_signal.c
index 0a0c038..772e2dd 100644
--- a/trunk/ecore/src/lib/ecore/ecore_signal.c
+++ b/trunk/ecore/src/lib/ecore/ecore_signal.c
@@ -15,7 +15,6 @@
 /* make mono happy - this is evil though... */
 #undef SIGPWR
 /* valgrind in some versions/setups uses SIGRT's... hmmm */
-#undef SIGRTMIN
 
 static int _ecore_signal_pipe[2];
 
@@ -25,10 +24,6 @@ static void _ecore_signal_callback_set(int sig, Signal_Handler func);
 static void _ecore_signal_callback_ignore(int sig, siginfo_t *si, void *foo);
 static void _ecore_signal_callback_write_pipe(int sig, siginfo_t *si, void *foo);
 
-#ifdef SIGRTMIN
-static void _ecore_signal_callback_sigrt(int sig, siginfo_t *si, void *foo);
-#endif
-
 static Eina_Bool _ecore_signal_exe_exit_delay(void *data);
 
 //#define MAXSIGQ 256 // 32k
@@ -45,9 +40,6 @@ static volatile sig_atomic_t sigterm_count = 0;
 #ifdef SIGPWR
 static volatile sig_atomic_t sigpwr_count = 0;
 #endif
-#ifdef SIGRTMIN
-static volatile sig_atomic_t *sigrt_count = NULL;
-#endif
 
 static volatile siginfo_t sigchld_info[MAXSIGQ];
 static volatile siginfo_t sigusr1_info[MAXSIGQ];
@@ -59,17 +51,10 @@ static volatile siginfo_t sigterm_info[MAXSIGQ];
 #ifdef SIGPWR
 static volatile siginfo_t sigpwr_info[MAXSIGQ];
 #endif
-#ifdef SIGRTMIN
-static volatile siginfo_t *sigrt_info[MAXSIGQ];
-#endif
 
 void
 _ecore_signal_shutdown(void)
 {
-#ifdef SIGRTMIN
-   int i, num = SIGRTMAX - SIGRTMIN;
-#endif
-
_ecore_signal_callback_set(SIGPIPE, (Signal_Handler) SIG_DFL);
_ecore_signal_callback_set(SIGALRM, (Signal_Handler) SIG_DFL);
_ecore_signal_callback_set(SIGCHLD, (Signal_Handler) SIG_DFL);
@@ -94,29 +79,6 @@ _ecore_signal_shutdown(void)
 
close(_ecore_signal_pipe[0]);
close(_ecore_signal_pipe[1]);
-
-#ifdef SIGRTMIN
-   for (i = 0; i < num; i++)
- {
-_ecore_signal_callback_set(SIGRTMIN + i, (Signal_Handler) SIG_DFL);
-sigrt_count[i] = 0;
- }
-
-   if (sigrt_count)
- {
-free((sig_atomic_t *) sigrt_count);
-sigrt_count = NULL;
- }
-
-   for (i = 0; i < MAXSIGQ; i++)
- {
-if (sigrt_info[i])
-  {
- free((siginfo_t *) sigrt_info[i]);
- sigrt_info[i] = NULL;
-  }
- }
-#endif
 }
 
 Eina_Bool
@@ -197,9 +159,6 @@ _ecore_signal_pipe_read(void *data, Ecore_Fd_Handler *fdh)
 void
 _ecore_signal_init(void)
 {
-#ifdef SIGRTMIN
-   int i, num = SIGRTMAX - SIGRTMIN;
-#endif
int pfd[2];
int r;
 
@@ -224,20 +183,6 @@ _ecore_signal_init(void)
 #ifdef SIGPWR
_ecore_signal_callback_set(SIGPWR,  _ecore_signal_callback_write_pipe);
 #endif
-
-#ifdef SIGRTMIN
-   sigrt_count = calloc(1, sizeof(sig_atomic_t) * num);
-   assert(sigrt_count);
-
-   for (i = 0; i < MAXSIGQ; i++)
- {
-sigrt_info[i] = calloc(1, sizeof(siginfo_t) * num);
-assert(sigrt_info[i]);
- }
-
-   for (i = 0; i < num; i++)
-  _ecore_signal_callback_set(SIGRTMIN + i, _ecore_signal_callback_sigrt);
-#endif
 }
 
 int
@@ -249,9 +194,6 @@ _ecore_signal_count_get(void)
 void
 _ecore_signal_call(void)
 {
-#ifdef SIGRTMIN
-   int i, num = SIGRTMAX - SIGRTMIN;
-#endif
volatile sig_atomic_t n;
sigset_t oldset, newset;
 
@@ -269,10 +211,6 @@ _ecore_signal_call(void)
 #ifdef SIGPWR
sigaddset(&newset, SIGPWR);
 #endif
-#ifdef SIGRTMIN
-   for (i = 0; i < num; i++)
- sigaddset(&newset, SIGRTMIN + i);
-#endif
sigprocmask(SIG_BLOCK, &newset, &oldset);
if (sigchld_count > MAXSIGQ)
  WRN("%i SIGCHLD in queue. max queue size %i. losing "
@@ -494,30 +432,6 @@ _ecore_signal_call(void)
sigpwr_count = 0;
 #endif
 
-#ifdef SIGRTMIN
-   for (i = 0; i < num; i++)
- {
-if (sigrt_count[i] > MAXSIGQ)
-  WRN("%i SIGRT%i in queue. max queue size %i. losing "
-  "siginfo for extra signals.", i + 1, sigrt_count[i], MAXSIGQ);
-for (n = 0; n < sigrt_count[i]; n++)
-  {
- Ecore_Event_Signal_Realtime *e;
-
- if ((e = _ecore_event_signal_realtime_new()))
-   {
-  e->num = i;
-
-  if ((n < MAXSIGQ) && (sigrt_info[n][i].si_signo))
-e->data = sigrt_info[n][i];
-
-  ecore_event_add(ECORE_EVENT_SIGNAL_REALTIME, e, NULL, NULL);
-   }
- sig_count--;
-  }
-sigrt_count[i] = 0;
- }
-#endif
sigprocmask(SIG_SETMASK, &oldset, NULL);
 }
 
-- 
1.7.0.4

--

Re: [E-devel] [PATCH] Handle ecore signals with a pipe

[Mike McCormack]

On 01/31/2011 07:29 PM, Carsten Haitzler (The Rasterman) wrote:


got a cleaned up patch? yours doesnt apply at all. also i think you removed
most but not all the handlers. _ecore_signal_callback_sigrt still had a
prototype at any rate reading your diff.


Attached.

The handlers were all merged into one, which sends the signal information over
a pipe.

thanks,

Mike
>From a28d9b60d8a0f3e46fde1926c411a8398e74317b Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 24 Jan 2011 20:36:20 +0900
Subject: [PATCH] Handle ecore signals with a pipe

This removes a race condition in the main loop where
a signal could come after the signal check, and before
entering the select loop, possibly resulting in a hang.

In practice, this hang wouldn't be seen due to other activity
in the main loop.
---
 trunk/ecore/src/lib/ecore/ecore_signal.c |  269 --
 1 files changed, 110 insertions(+), 159 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_signal.c b/trunk/ecore/src/lib/ecore/ecore_signal.c
index f072c06..0a0c038 100644
--- a/trunk/ecore/src/lib/ecore/ecore_signal.c
+++ b/trunk/ecore/src/lib/ecore/ecore_signal.c
@@ -17,20 +17,13 @@
 /* valgrind in some versions/setups uses SIGRT's... hmmm */
 #undef SIGRTMIN
 
+static int _ecore_signal_pipe[2];
+
 typedef void (*Signal_Handler)(int sig, siginfo_t *si, void *foo);
 
 static void _ecore_signal_callback_set(int sig, Signal_Handler func);
 static void _ecore_signal_callback_ignore(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigchld(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigusr1(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigusr2(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sighup(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigquit(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigint(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigterm(int sig, siginfo_t *si, void *foo);
-#ifdef SIGPWR
-static void _ecore_signal_callback_sigpwr(int sig, siginfo_t *si, void *foo);
-#endif
+static void _ecore_signal_callback_write_pipe(int sig, siginfo_t *si, void *foo);
 
 #ifdef SIGRTMIN
 static void _ecore_signal_callback_sigrt(int sig, siginfo_t *si, void *foo);
@@ -99,6 +92,9 @@ _ecore_signal_shutdown(void)
sigterm_count = 0;
sig_count = 0;
 
+   close(_ecore_signal_pipe[0]);
+   close(_ecore_signal_pipe[1]);
+
 #ifdef SIGRTMIN
for (i = 0; i < num; i++)
  {
@@ -123,24 +119,110 @@ _ecore_signal_shutdown(void)
 #endif
 }
 
+Eina_Bool
+_ecore_signal_pipe_read(void *data, Ecore_Fd_Handler *fdh)
+{
+   siginfo_t si;
+   int sig = -1;
+   int r;
+   int n;
+
+   r = read(_ecore_signal_pipe[0], &si, sizeof si);
+   if (r != sizeof si)
+ {
+WRN("failed to read signal\n");
+return;
+ }
+
+   sig = si.si_signo;
+
+   switch (sig)
+ {
+  case SIGCHLD:
+ n = sigchld_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigchld_info[n] = si;
+ break;
+  case SIGUSR1:
+ n = sigusr1_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigusr1_info[n] = si;
+ break;
+  case SIGUSR2:
+ n = sigusr2_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigusr2_info[n] = si;
+ break;
+  case SIGHUP:
+ n = sighup_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sighup_info[n] = si;
+ break;
+  case SIGQUIT:
+ n = sigquit_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigquit_info[n] = si;
+ break;
+  case SIGINT:
+ n = sigint_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigint_info[n] = si;
+ break;
+  case SIGTERM:
+ n = sigterm_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigterm_info[n] = si;
+ break;
+#ifdef SIGPWR
+  case SIGPWR:
+ n = sigpwr_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigpwr_info[n] = si;
+ break;
+#endif
+  default:
+ ERR("unknown signal %d\n", sig);
+ break;
+ }
+}
+
 void
 _ecore_signal_init(void)
 {
 #ifdef SIGRTMIN
int i, num = SIGRTMAX - SIGRTMIN;
 #endif
+   int pfd[2];
+   int r;
+
+   r = pipe(_ecore_signal_pipe);
+   if (r < 0)
+ {
+   ERR("pipe failed (%d)\n", r);
+   exit(1);
+ }
+   ecore_main_fd_handler_add(_ecore_signal_pipe[0], ECORE_FD_READ,
+ &_ecore_signal_pipe_read, NULL, NULL, NULL);
 
_ecore_signal_callback_set(SIGPIPE, _ecore_signal_callback_ignore);
_ecore_signal_callback_set(SIGALRM, _ecore_signal_callback_ignore);
-   _ecore_signal_callback_set(SIGCHLD, _ecore_signal_callback

Re: [E-devel] [PATCH] Handle ecore signals with a pipe

[Mike McCormack]

On 01/25/2011 12:10 PM, Lucas De Marchi wrote:
> On Mon, Jan 24, 2011 at 9:56 AM, Mike McCormack
>   wrote:
>>
>> The way ecore handles signals is racy.
>> The attached patch uses a pipe to avoid races between signals and
>> select/poll().
>
> Couldn't we use signalfd instead? It's the most clean way I know.

Clean, but not portable, as I understand.  I could add it with a fallback
to the pipe method.

There's actually quite a bit of cleaning up to do for ecore signal handling.

I'm not even sure that it's a good idea for a library (or framework) to
be messing with signal handlers without an explicit request from the
application using it.

>> A fix for before or after 1.0...?
>
> After, for sure.

I agree.  Was testing the general consensus.  Will queue this and work on
cleaning up the rest of it.

thanks,

Mike

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] Handle ecore signals with a pipe

[Mike McCormack]

The way ecore handles signals is racy.
The attached patch uses a pipe to avoid races between signals and select/poll().

A fix for before or after 1.0...?

thanks,

Mike


btw. the SIGRTMIN is totally borken and probably should be deleted
>From 1a21c643e08e325b2773e53ecde27bcf46ca5148 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 24 Jan 2011 20:36:20 +0900
Subject: [PATCH] Handle ecore signals with a pipe

This removes a race condition in the main loop where
a signal could come after the signal check, and before
entering the select loop, possibly resulting in a hang.

In practice, this hang wouldn't be seen due to other activity
in the main loop.
---
 trunk/ecore/src/lib/ecore/ecore_signal.c |  269 --
 1 files changed, 110 insertions(+), 159 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_signal.c b/trunk/ecore/src/lib/ecore/ecore_signal.c
index f072c06..0a0c038 100644
--- a/trunk/ecore/src/lib/ecore/ecore_signal.c
+++ b/trunk/ecore/src/lib/ecore/ecore_signal.c
@@ -17,20 +17,13 @@
 /* valgrind in some versions/setups uses SIGRT's... hmmm */
 #undef SIGRTMIN
 
+static int _ecore_signal_pipe[2];
+
 typedef void (*Signal_Handler)(int sig, siginfo_t *si, void *foo);
 
 static void _ecore_signal_callback_set(int sig, Signal_Handler func);
 static void _ecore_signal_callback_ignore(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigchld(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigusr1(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigusr2(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sighup(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigquit(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigint(int sig, siginfo_t *si, void *foo);
-static void _ecore_signal_callback_sigterm(int sig, siginfo_t *si, void *foo);
-#ifdef SIGPWR
-static void _ecore_signal_callback_sigpwr(int sig, siginfo_t *si, void *foo);
-#endif
+static void _ecore_signal_callback_write_pipe(int sig, siginfo_t *si, void *foo);
 
 #ifdef SIGRTMIN
 static void _ecore_signal_callback_sigrt(int sig, siginfo_t *si, void *foo);
@@ -99,6 +92,9 @@ _ecore_signal_shutdown(void)
sigterm_count = 0;
sig_count = 0;
 
+   close(_ecore_signal_pipe[0]);
+   close(_ecore_signal_pipe[1]);
+
 #ifdef SIGRTMIN
for (i = 0; i < num; i++)
  {
@@ -123,24 +119,110 @@ _ecore_signal_shutdown(void)
 #endif
 }
 
+Eina_Bool
+_ecore_signal_pipe_read(void *data, Ecore_Fd_Handler *fdh)
+{
+   siginfo_t si;
+   int sig = -1;
+   int r;
+   int n;
+
+   r = read(_ecore_signal_pipe[0], &si, sizeof si);
+   if (r != sizeof si)
+ {
+WRN("failed to read signal\n");
+return;
+ }
+
+   sig = si.si_signo;
+
+   switch (sig)
+ {
+  case SIGCHLD:
+ n = sigchld_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigchld_info[n] = si;
+ break;
+  case SIGUSR1:
+ n = sigusr1_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigusr1_info[n] = si;
+ break;
+  case SIGUSR2:
+ n = sigusr2_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigusr2_info[n] = si;
+ break;
+  case SIGHUP:
+ n = sighup_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sighup_info[n] = si;
+ break;
+  case SIGQUIT:
+ n = sigquit_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigquit_info[n] = si;
+ break;
+  case SIGINT:
+ n = sigint_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigint_info[n] = si;
+ break;
+  case SIGTERM:
+ n = sigterm_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigterm_info[n] = si;
+ break;
+#ifdef SIGPWR
+  case SIGPWR:
+ n = sigpwr_count++;
+ sig_count++;
+ if (n < MAXSIGQ)
+   sigpwr_info[n] = si;
+ break;
+#endif
+  default:
+ ERR("unknown signal %d\n", sig);
+ break;
+ }
+}
+
 void
 _ecore_signal_init(void)
 {
 #ifdef SIGRTMIN
int i, num = SIGRTMAX - SIGRTMIN;
 #endif
+   int pfd[2];
+   int r;
+
+   r = pipe(_ecore_signal_pipe);
+   if (r < 0)
+ {
+   ERR("pipe failed (%d)\n", r);
+   exit(1);
+ }
+   ecore_main_fd_handler_add(_ecore_signal_pipe[0], ECORE_FD_READ,
+ &_ecore_signal_pipe_read, NULL, NULL, NULL);
 
_ecore_signal_callback_set(SIGPIPE, _ecore_signal_callback_ignore);
_ecore_signal_callback_set(SIGALRM, _ecore_signal_callback_ignore);
-   _ecore_signal_callback_set(SIGCHLD, _ecore_signal_callback_sigchld);
-   _ecore_signal_callback_set(SIGUSR1, _ecore_signal_callback_sigusr1);
-   _ecore_signal_callback_set(SIGUSR2, _ecore_signal_callbac

[E-devel] [PATCH 2/2] Zero is a valid fd value

[Mike McCormack]

ecore_config code may end up closing stdin, due to assuming 0 is a valid fd.

I know this code is deprecated, and it's being kept around "for reference".

Either:
A) this bug should still be fixed so bad code is not copied elsewhere

OR

B) ecore_config should be deleted so bad code is not copied elsewhere

thanks,

Mike
>From 0a3dd60144f2d268527a560987a5d359afedf59a Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 13 Dec 2010 16:23:58 +0900
Subject: [PATCH 2/2] Zero is a valid fd value

---
 trunk/ecore/src/lib/ecore_config/ecore_config.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_config/ecore_config.c b/trunk/ecore/src/lib/ecore_config/ecore_config.c
index ddfc64f..d8b587e 100644
--- a/trunk/ecore/src/lib/ecore_config/ecore_config.c
+++ b/trunk/ecore/src/lib/ecore_config/ecore_config.c
@@ -1636,7 +1636,7 @@ ecore_config_init_global(const char *name)
 	snprintf(buf, PATH_MAX, "%s/.ecore/%s/.global", p, name);
 	global = creat(buf, S_IRWXU);
 
-	if (global)
+	if (global >= 0)
 	   close(global);
 
 	free(buf);
-- 
1.7.0.4

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH 1/2] Zero is a valid fd

[Mike McCormack]

The ecore_fb keyboard code may end up closing stdin.
The attached patch fixes this bug.

thanks,

Mike

>From e8f8590fa52ea31021c02acf6603d5c5a40685cc Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Wed, 15 Dec 2010 12:25:14 +0900
Subject: [PATCH 1/2] Zero is a valid fd

---
 trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c b/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c
index 5d2a6a6..8dcd29d 100644
--- a/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c
+++ b/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c
@@ -121,7 +121,7 @@ static const char *_ecore_fb_btn_syms[128] =
  "0x7e", 
  "0x7f"
 };
-static int _ecore_fb_kbd_fd = 0;
+static int _ecore_fb_kbd_fd = -1;
 static int _ecore_fb_ctrl = 0;
 static int _ecore_fb_alt = 0;
 static int _ecore_fb_shift = 0;
@@ -296,7 +296,7 @@ ecore_fb_kbd_shutdown(void)
if (_ecore_fb_kbd_fd_handler_handle) 
   ecore_main_fd_handler_del(_ecore_fb_kbd_fd_handler_handle);
if (_ecore_fb_kbd_fd >= 0) close(_ecore_fb_kbd_fd);
-   _ecore_fb_kbd_fd = 0;
+   _ecore_fb_kbd_fd = -1;
_ecore_fb_kbd_fd_handler_handle = NULL;
_ecore_fb_ctrl = 0;
_ecore_fb_lock = 0;
-- 
1.7.0.4

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] some bug fix patches

[Mike McCormack]

On 01/21/2011 10:04 AM, Lucas De Marchi wrote:

> Patch 001_evas.patch.txt does not look right. Besides the trailing
> whitespaces, it doesn't make sense. Maybe you forgot to save your
> changes before sending?

-free(g);
-free(g->keyname);

I think the essence of the patch is that the above two lines are in the wrong 
order.

It would be clearer if whitespace changes were not mixed with fixes.

thanks,

Mike


--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] Add simple block game

[Mike McCormack]

Hi All,

This is a port of a simple game that I've used for testing in other projects 
before.

thanks,

Mike
>From 0e615abc1ee8c52e790aea7ace1685ded9291dcc Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Tue, 18 Jan 2011 15:05:40 +0900
Subject: [PATCH] Add simple block game

---
 trunk/GAMES/eblock/Makefile |   11 +
 trunk/GAMES/eblock/eblock.c |  461 +++
 2 files changed, 472 insertions(+), 0 deletions(-)
 create mode 100644 trunk/GAMES/eblock/Makefile
 create mode 100644 trunk/GAMES/eblock/eblock.c

diff --git a/trunk/GAMES/eblock/Makefile b/trunk/GAMES/eblock/Makefile
new file mode 100644
index 000..8ea60d6
--- /dev/null
+++ b/trunk/GAMES/eblock/Makefile
@@ -0,0 +1,11 @@
+CFLAGS += $(shell pkg-config --cflags elementary)
+LIBS += $(shell pkg-config --libs elementary)
+
+CFLAGS += -Wall -O2
+
+eblock: eblock.o
+	$(CC) -o $@ $< $(LIBS)
+
+clean:
+	rm -f eblock eblock.o
+
diff --git a/trunk/GAMES/eblock/eblock.c b/trunk/GAMES/eblock/eblock.c
new file mode 100644
index 000..0edc963
--- /dev/null
+++ b/trunk/GAMES/eblock/eblock.c
@@ -0,0 +1,461 @@
+/*
+ * A simple game for testing
+ *
+ * Copyright 2009 Thomas Horsten
+ * Copyright 2009-2011 Mike McCormack
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_WIDTH 10
+#define DEFAULT_HEIGHT 20
+#define DEFAULT_BLOCKSIZE 20
+#define PREVIEW_BLOCKSIZE 7
+
+#define BLACK 0
+#define CYAN 1
+
+Evas_Object *board[DEFAULT_WIDTH * DEFAULT_HEIGHT];
+
+int board_width = DEFAULT_WIDTH;
+int board_height = DEFAULT_HEIGHT;
+int block_size = DEFAULT_BLOCKSIZE;
+int interval = 1000;
+int piece_orientation = 0;
+int next_piece_type = 0;
+int piece_type = 0;
+int piece_color = CYAN;
+int piece_x = 0;
+int piece_y = 0;
+
+bool show_next_piece = true;
+int preview_pos_x = (DEFAULT_WIDTH * DEFAULT_BLOCKSIZE)-(5*PREVIEW_BLOCKSIZE)-1;
+int preview_pos_y = 1;
+
+bool game_over = false;
+
+int rgb_table[8][3] ={
+   { 0x00, 0x00, 0x00 },
+   { 0x00, 0xf0, 0xf0 },
+   { 0xf0, 0xa0, 0x00 },
+   { 0x00, 0x00, 0xf0 },
+   { 0xa0, 0x00, 0xf0 },
+   { 0x00, 0xf0, 0x00 },
+   { 0xf0, 0x00, 0x00 },
+   { 0xf0, 0xf0, 0x00 },
+};
+
+/*
+ * The pieces are stored in specially formatted 32-bit integers.
+ *
+ * The top 8 bits specify the x and y size of the piece (e.g. 0x41 for
+ * a 4*1 piece).  The lower (xsize*ysize) bits are a bitmap of the
+ * piece.  This is used instead of a fixed size e.g. 4x4, so that
+ * rotation can be done correctly relating to the piece size and
+ * prevents "wobbling" when rotating the pieces. When displaying,
+ * every piece is mapped (and centered) to a 5x5 area.
+ */
+const unsigned int piece[] = {
+   /* straight */
+   0x4100 | 0x0f,
+   /* bent left */
+   0x2300 | (0x3 << 4) | (0x1 << 2) | 0x1,
+   /* bent right */
+   0x2300 | (0x3 << 4) | (0x2 << 2) | 0x2,
+   /* T shaped */
+   0x3200 | (0x2 << 3) | 0x7,
+   /* dogleg left */
+   0x3200 | (0x3 << 3) | 0x6,
+   /* dogleg right */
+   0x3200 | (0x6 << 3) | 0x3,
+   /* square */
+   0x220f,
+};
+
+typedef void *block;
+
+void set_block_color(block b, unsigned long color)
+{
+   Evas_Object **eo = b;
+
+   if (!eo)
+ return;
+
+   evas_object_color_set(*eo, rgb_table[color][0],
+ rgb_table[color][1],
+ rgb_table[color][2], 255);
+}
+
+unsigned long get_block_color(block bl)
+{
+   Evas_Object **eo = bl;
+   int r = 0, g = 0, b = 0, a = 0;
+   int i;
+
+   if (!eo)
+ return CYAN;
+   evas_object_color_get(*eo, &r, &g, &b, &a);
+
+   for (i=0; i<8; i++)
+ if (r == rgb_table[i][0] &&
+ g == rgb_table[i][1] &&
+ b == rgb_table[i][2])
+   return i;
+
+   assert(!r && !b && !g);
+
+   return BLACK;
+}
+
+block get_block_ptr(int x, int y)
+{
+   if (x < 0 || x >= board_width)
+ return NULL;
+   if (y < 0 || y >= board_height)
+ return NULL;
+   return &board[y*board_width + x];
+}
+
+bool block_is_empty(int x, int y)
+{
+   block b = get_block_ptr(x, y);
+   return get_block_color(b) == BLACK;
+}
+
+bool piece_has_block(int type, int orientation, int x, int y)
+{
+   int size

Re: [E-devel] Exception handling with EFL

[Mike McCormack]

On 01/18/2011 10:20 AM, Vinícius dos Santos Oliveira wrote:
> Is there any implementation in Enlightenment to use exception handling in C?

Standard C doesn't support exception handling.  How do you propose it would 
work?

thanks,

Mike


--
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] [PATCH - embryo] Use const on input string

[Mike McCormack]

Embryo_Program *embryo_program_load(char *file);

looks like it's missing a const.  This patch adds it.

thanks,

Mike

>From 07e559fe0e9dbed9da55e7154e4b863ffc345008 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 17 Jan 2011 18:19:22 +0900
Subject: [PATCH] Use const on input string

---
 trunk/embryo/src/lib/Embryo.h |2 +-
 trunk/embryo/src/lib/embryo_amx.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/trunk/embryo/src/lib/Embryo.h b/trunk/embryo/src/lib/Embryo.h
index e7c1a72..1bfb1ec 100644
--- a/trunk/embryo/src/lib/Embryo.h
+++ b/trunk/embryo/src/lib/Embryo.h
@@ -120,7 +120,7 @@ extern "C" {
 
EAPI Embryo_Program  *embryo_program_new(void *data, int size);
EAPI Embryo_Program  *embryo_program_const_new(void *data, int size);
-   EAPI Embryo_Program  *embryo_program_load(char *file);
+   EAPI Embryo_Program  *embryo_program_load(const char *file);
EAPI void embryo_program_free(Embryo_Program *ep);
EAPI void embryo_program_native_call_add(Embryo_Program *ep, const char *name, Embryo_Cell (*func) (Embryo_Program *ep, Embryo_Cell *params));
EAPI void embryo_program_vm_reset(Embryo_Program *ep);
diff --git a/trunk/embryo/src/lib/embryo_amx.c b/trunk/embryo/src/lib/embryo_amx.c
index ab96ab7..ea71091 100644
--- a/trunk/embryo/src/lib/embryo_amx.c
+++ b/trunk/embryo/src/lib/embryo_amx.c
@@ -306,7 +306,7 @@ embryo_program_const_new(void *data, int size)
  * @ingroup Embryo_Program_Creation_Group
  */
 EAPI Embryo_Program *
-embryo_program_load(char *file)
+embryo_program_load(const char *file)
 {
Embryo_Program *ep;
Embryo_Header   hdr;
-- 
1.7.0.4

--
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] [PATCH] Don't use empty parameter lists in Elementary.h

[Mike McCormack]

In C, the following two prototypes are not the same:

void func();
void func(void);

Attached patch fixes occurrences of 1st in Elementary.h

thanks,

Mike

>From 5b42c9c1663df5de4ed62466ce77fb4dbed22a60 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 17 Jan 2011 16:53:16 +0900
Subject: [PATCH] Don't use empty parameter lists

---
 trunk/TMP/st/elementary/src/lib/Elementary.h.in |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/trunk/TMP/st/elementary/src/lib/Elementary.h.in b/trunk/TMP/st/elementary/src/lib/Elementary.h.in
index d84b65e..0e4c558 100644
--- a/trunk/TMP/st/elementary/src/lib/Elementary.h.in
+++ b/trunk/TMP/st/elementary/src/lib/Elementary.h.in
@@ -325,8 +325,8 @@ extern "C" {
EAPI const Eina_List *elm_font_overlay_list_get(void);
EAPI void elm_font_overlay_set(const char *text_class, const char *font, Evas_Font_Size size);
EAPI void elm_font_overlay_unset(const char *text_class);
-   EAPI void elm_font_overlay_apply();
-   EAPI void elm_font_overlay_all_apply();
+   EAPI void elm_font_overlay_apply(void);
+   EAPI void elm_font_overlay_all_apply(void);
 
EAPI Elm_Font_Properties *elm_font_properties_get(const char *font) EINA_ARG_NONNULL(1);
EAPI void elm_font_properties_free(Elm_Font_Properties *efp) EINA_ARG_NONNULL(1);
-- 
1.7.0.4

--
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

Re: [E-devel] [Patch] elm_map downloading progress info & bug fix

[Mike McCormack]

On 01/10/2011 03:45 PM, sangho park wrote:

> I added one new signal, one new API and fixed seg fault bug.

Separate changes are better submitted (and committed) as separate patches.

This way, rollbacks only affect bad changes, reviewing changes is easier,
some patches can be applied while you rework others, etc.

thanks,

Mike

--
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

[E-devel] [PATCH] ecore/src/lib/ecore_fb/ecore_fb_kbd.c - Zero is a valid fd

[Mike McCormack]

>From 91f35f479bec1d2a71630cf2dc5754bedcaeac34 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Wed, 15 Dec 2010 12:25:14 +0900
Subject: [PATCH 1/2] Zero is a valid fd

---
 trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c b/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c
index 5d2a6a6..8dcd29d 100644
--- a/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c
+++ b/trunk/ecore/src/lib/ecore_fb/ecore_fb_kbd.c
@@ -121,7 +121,7 @@ static const char *_ecore_fb_btn_syms[128] =
  "0x7e", 
  "0x7f"
 };
-static int _ecore_fb_kbd_fd = 0;
+static int _ecore_fb_kbd_fd = -1;
 static int _ecore_fb_ctrl = 0;
 static int _ecore_fb_alt = 0;
 static int _ecore_fb_shift = 0;
@@ -296,7 +296,7 @@ ecore_fb_kbd_shutdown(void)
if (_ecore_fb_kbd_fd_handler_handle) 
   ecore_main_fd_handler_del(_ecore_fb_kbd_fd_handler_handle);
if (_ecore_fb_kbd_fd >= 0) close(_ecore_fb_kbd_fd);
-   _ecore_fb_kbd_fd = 0;
+   _ecore_fb_kbd_fd = -1;
_ecore_fb_kbd_fd_handler_handle = NULL;
_ecore_fb_ctrl = 0;
_ecore_fb_lock = 0;
-- 
1.7.0.4

--
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

[E-devel] [PATCH] Deleting the same fdh twice is an error

[Mike McCormack]

>From 1ffcead31d05bd60918b7a9f3888215cbd1e5d2e Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 20 Dec 2010 17:47:19 +0900
Subject: [PATCH] Deleting the same fdh twice is an error

---
 trunk/ecore/src/lib/ecore/ecore_main.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_main.c b/trunk/ecore/src/lib/ecore/ecore_main.c
index eedcc9b..a27cd87 100644
--- a/trunk/ecore/src/lib/ecore/ecore_main.c
+++ b/trunk/ecore/src/lib/ecore/ecore_main.c
@@ -844,9 +844,11 @@ ecore_main_fd_handler_del(Ecore_Fd_Handler *fd_handler)
 return NULL;
  }
if (fd_handler->delete_me)
- /* FIXME: should this return NULL instead? */
- return fd_handler->data;
- 
+ {
+ERR("fdh %p deleted twice", fd_handler);
+return NULL;
+ }
+
fd_handler->delete_me = EINA_TRUE;
_ecore_main_fdh_poll_del(fd_handler);
fd_handlers_to_delete = eina_list_append(fd_handlers_to_delete, fd_handler);
-- 
1.7.0.4

--
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] ecore tests fail with beta3 tarballs

[Mike McCormack]

On 12/19/2010 09:26 PM, Thomas Sachau wrote:

> test the package. As already said, tests should not require external services 
> like X to run and if
> some tests need such a service, they should be skipped or there should be an 
> option to skip them.

You want to verify EFL, which is all about graphics, but you don't want to run 
X?

thanks,

Mike

--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore_con

[Mike McCormack]

On 12/17/2010 05:41 PM, Sebastian Dransfeld wrote:

On 12/17/2010 09:06 AM, Sebastian Dransfeld wrote:

On 12/17/2010 05:30 AM, Mike McCormack wrote:

On 12/17/2010 05:41 AM, Sebastian Dransfeld wrote:


num = read(svr->fd, buf, sizeof(buf));
- if ((num> 0) || (errno == EAGAIN))
+ if ((num>= 0) || (errno == EAGAIN))
lost_server = EINA_FALSE;


Sure this is right? a ret 0 an errno != EAGAIN is probably a lost
server.


0 is a successful return, so errno is not set in that case.

The above fix looks correct to me.


Depends on how the main loop works. We had this discussion a while ago,
and the result was:

http://trac.enlightenment.org/e/changeset/54209/trunk/ecore/src/lib/ecore_con/ecore_con.c




And:

http://stackoverflow.com/questions/2416944/can-read-function-on-a-connected-socket-return-zero-bytes


So 0 is _not_ a valid return value on a tcp socket.
 
read doesn't touch errno if it returns 0, as the attached test show.


If you think it behaves differently for a socket somehow, please extend the 
test and show me.

thanks,

Mike
/*
 * compile:
 * gcc -o read_zero -Wall read_zero.c
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
	int fd;
	char buf[1];
	char name[20] = "/tmp/.zerotestXX";
	int r;

	fd = mkstemp(name);
	if (fd < 0)
	{
		fprintf(stderr, "failed to create file");
		return 1;
	}

	printf("filename = %s\n", name);

	errno = EIO;
	r = read(fd, buf, sizeof buf);
	if (r)
	{
		printf("r = %d\n", r);
	}
	else if (errno == EIO)
	{
		printf("errno untouched\n");
	}

	close(fd);

	return 0;
}
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore_con

[Mike McCormack]

On 12/17/2010 05:41 AM, Sebastian Dransfeld wrote:

>>num = read(svr->fd, buf, sizeof(buf));
>> -if ((num>   0) || (errno == EAGAIN))
>> +if ((num>= 0) || (errno == EAGAIN))
>>  lost_server = EINA_FALSE;
>
> Sure this is right? a ret 0 an errno != EAGAIN is probably a lost server.

0 is a successful return, so errno is not set in that case.

The above fix looks correct to me.

thanks,

Mike

--
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

[E-devel] [PATCH] ecore_con: Fix fd leak

[Mike McCormack]

This patch fixes a potential fd leak in ecore_con.

thanks,

Mike
>From baece8fc38b147a93628eecfb3e303ada2f1ee0e Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Tue, 14 Dec 2010 18:01:02 +0900
Subject: [PATCH] Fix fd leak

---
 trunk/ecore/src/lib/ecore_con/ecore_con.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_con/ecore_con.c b/trunk/ecore/src/lib/ecore_con/ecore_con.c
index 49f1fae..111ac5b 100644
--- a/trunk/ecore/src/lib/ecore_con/ecore_con.c
+++ b/trunk/ecore/src/lib/ecore_con/ecore_con.c
@@ -1291,6 +1291,12 @@ _ecore_con_server_kill(Ecore_Con_Server *svr)
  ecore_main_fd_handler_del(svr->fd_handler);
 
svr->fd_handler = NULL;
+
+   if (svr->fd >= 0)
+ {
+close(svr->fd);
+svr->fd = -1;
+ }
 }
 
 static Eina_Bool
-- 
1.7.0.4

--
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

[E-devel] [PATCH 4/4] ecore_fb: Zero is a valid fd value

[Mike McCormack]

>From 89b15dbe521a04c0ff311cfc8a23f20750203247 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 13 Dec 2010 16:39:11 +0900
Subject: [PATCH 4/4] Zero is a valid fd value

---
 trunk/ecore/src/lib/ecore_fb/ecore_fb_vt.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_fb/ecore_fb_vt.c b/trunk/ecore/src/lib/ecore_fb/ecore_fb_vt.c
index 65f2013..ab94f83 100644
--- a/trunk/ecore/src/lib/ecore_fb/ecore_fb_vt.c
+++ b/trunk/ecore/src/lib/ecore_fb/ecore_fb_vt.c
@@ -7,8 +7,8 @@
 
 static int _ecore_fb_vt_do_switch = 0;
 
-static int _ecore_fb_vt_tty0_fd = 0;
-static int _ecore_fb_vt_tty_fd = 0;
+static int _ecore_fb_vt_tty0_fd = -1;
+static int _ecore_fb_vt_tty_fd = -1;
 static int _ecore_fb_vt_current_vt = 0;
 static int _ecore_fb_vt_prev_vt = 0;
 
@@ -95,7 +95,7 @@ _ecore_fb_vt_setup(void)
  return 0;
   }
 close(_ecore_fb_vt_tty0_fd);
-_ecore_fb_vt_tty0_fd = 0;
+_ecore_fb_vt_tty0_fd = -1;
 /* FIXME detach the process from current tty ? */
  }
else
@@ -109,6 +109,7 @@ _ecore_fb_vt_setup(void)
  {
 perror("[ecore_fb:vt_setup] can't set the mode to KD_GRAPHICS");
 close(_ecore_fb_vt_tty_fd);
+_ecore_fb_vt_tty_fd = -1;
 return 0;
  }
ioctl(_ecore_fb_vt_tty_fd, KDGKBMODE, &_ecore_fb_tty_prev_mode);
@@ -122,6 +123,7 @@ _ecore_fb_vt_setup(void)
  {
 perror("[ecore_fb:vt_setup] can't set the tty mode");
 close(_ecore_fb_vt_tty_fd);
+_ecore_fb_vt_tty_fd = -1;
 return 0;
  }
/* register signal handlers when alloc/detach of vt */
@@ -136,12 +138,14 @@ _ecore_fb_vt_setup(void)
  {
 perror("[ecore_fb:vt_setup] error on VT_ACTIVATE");
 close(_ecore_fb_vt_tty_fd);
+_ecore_fb_vt_tty_fd = -1;
 return 0;
  }
if(ioctl(_ecore_fb_vt_tty_fd, VT_WAITACTIVE, _ecore_fb_vt_current_vt) < 0)
  {
 perror("[ecore_fb:vt_setup] error on VT_WAITACTIVE");
 close(_ecore_fb_vt_tty_fd);
+_ecore_fb_vt_tty_fd = -1;
 return 0;
  }
/* FIXME assign the fb to the tty in case isn't setup */
@@ -200,7 +204,7 @@ void
 ecore_fb_vt_shutdown(void)
 {
/* restore the previous mode */
-   if (_ecore_fb_vt_tty_fd != 0)
+   if (_ecore_fb_vt_tty_fd != -1)
  {
 tcsetattr(_ecore_fb_vt_tty_fd, TCSAFLUSH, &_ecore_fb_tty_prev_tio_mode);
 ioctl(_ecore_fb_vt_tty_fd, KDSETMODE, _ecore_fb_tty_prev_kd_mode);
@@ -208,7 +212,7 @@ ecore_fb_vt_shutdown(void)
 ioctl(_ecore_fb_vt_tty_fd, VT_SETMODE, &_ecore_fb_vt_prev_mode);
 /* go back to previous vt */
 close(_ecore_fb_vt_tty_fd);
-_ecore_fb_vt_tty_fd = 0;
+_ecore_fb_vt_tty_fd = -1;
  }

if (_ecore_fb_user_handler) ecore_event_handler_del(_ecore_fb_user_handler);
-- 
1.7.0.4

--
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

[E-devel] [PATCH 3/4] ecore_con: Always close fd after remove fdh from main loop

[Mike McCormack]

>From 63280c232194e06103ed40e00127ad14b21451a5 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 13 Dec 2010 16:25:49 +0900
Subject: [PATCH 3/4] Always close fd after remove fdh from main loop

---
 trunk/ecore/src/lib/ecore_con/ecore_con_info.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_con/ecore_con_info.c b/trunk/ecore/src/lib/ecore_con/ecore_con_info.c
index 3585cd4..1d45712 100644
--- a/trunk/ecore/src/lib/ecore_con/ecore_con_info.c
+++ b/trunk/ecore/src/lib/ecore_con/ecore_con_info.c
@@ -366,8 +366,8 @@ _ecore_con_info_slave_free(CB_Data *cbdata)
info_slaves = (CB_Data *)eina_inlist_remove(EINA_INLIST_GET(info_slaves),
EINA_INLIST_GET(cbdata));
ecore_main_fd_handler_del(cbdata->fdh);
-   close(ecore_main_fd_handler_fd_get(cbdata->fdh));
ecore_event_handler_del(cbdata->handler);
+   close(ecore_main_fd_handler_fd_get(cbdata->fdh));
free(cbdata);
 }
 
-- 
1.7.0.4

--
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

[E-devel] [PATCH 2/4] ecore_config - Zero is a valid fd value

[Mike McCormack]

>From 64dc91c0fa0021335e973535acba5e86cd5faa6f Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 13 Dec 2010 16:23:58 +0900
Subject: [PATCH 2/4] Zero is a valid fd value

---
 trunk/ecore/src/lib/ecore_config/ecore_config.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_config/ecore_config.c b/trunk/ecore/src/lib/ecore_config/ecore_config.c
index ddfc64f..d8b587e 100644
--- a/trunk/ecore/src/lib/ecore_config/ecore_config.c
+++ b/trunk/ecore/src/lib/ecore_config/ecore_config.c
@@ -1636,7 +1636,7 @@ ecore_config_init_global(const char *name)
 	snprintf(buf, PATH_MAX, "%s/.ecore/%s/.global", p, name);
 	global = creat(buf, S_IRWXU);
 
-	if (global)
+	if (global >= 0)
 	   close(global);
 
 	free(buf);
-- 
1.7.0.4

--
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

[E-devel] [PATCH 1/4] ecore_con: Always close fd after remove fdh from main loop

[Mike McCormack]

>From c83bcffc5ac24154cbbf98df953b3b9121f4797b Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Mon, 13 Dec 2010 16:23:39 +0900
Subject: [PATCH 1/4] Always close fd after remove fdh from main loop

---
 trunk/ecore/src/lib/ecore_con/ecore_con.c |   31 +++-
 1 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore_con/ecore_con.c b/trunk/ecore/src/lib/ecore_con/ecore_con.c
index 9e8b50c..49f1fae 100644
--- a/trunk/ecore/src/lib/ecore_con/ecore_con.c
+++ b/trunk/ecore/src/lib/ecore_con/ecore_con.c
@@ -373,12 +373,12 @@ error:
  free(svr->path);
 
 #ifndef _WIN32
-   if (svr->fd >= 0)
- close(svr->fd);
-
if (svr->fd_handler)
  ecore_main_fd_handler_del(svr->fd_handler);
 
+   if (svr->fd >= 0)
+ close(svr->fd);
+
if (svr->write_buf)
  free(svr->write_buf);
 
@@ -494,12 +494,12 @@ error:
if (svr->path)
  free(svr->path);
 
-   if (svr->fd >= 0)
- close(svr->fd);
-
if (svr->fd_handler)
  ecore_main_fd_handler_del(svr->fd_handler);
 
+   if (svr->fd >= 0)
+ close(svr->fd);
+
ecore_con_ssl_server_shutdown(svr);
free(svr);
return NULL;
@@ -1184,9 +1184,6 @@ _ecore_con_server_free(Ecore_Con_Server *svr)
  unlink(svr->path);
 
ecore_con_ssl_server_shutdown(svr);
-   if (svr->fd >= 0)
- close(svr->fd);
-
if (svr->name)
  free(svr->name);
 
@@ -1199,6 +1196,9 @@ _ecore_con_server_free(Ecore_Con_Server *svr)
if (svr->fd_handler)
  ecore_main_fd_handler_del(svr->fd_handler);
 
+   if (svr->fd >= 0)
+ close(svr->fd);
+
servers = eina_list_remove(servers, svr);
svr->data = NULL;
free(svr);
@@ -1253,12 +1253,12 @@ _ecore_con_client_free(Ecore_Con_Client *cl)
if (cl->host_server->type & ECORE_CON_SSL)
  ecore_con_ssl_client_shutdown(cl);
 
-   if (cl->fd >= 0)
- close(cl->fd);
-
if (cl->fd_handler)
  ecore_main_fd_handler_del(cl->fd_handler);
 
+   if (cl->fd >= 0)
+ close(cl->fd);
+
if (cl->client_addr)
  free(cl->client_addr);
cl->client_addr = NULL;
@@ -1771,9 +1771,12 @@ _ecore_con_svr_tcp_handler(void*data,
return ECORE_CALLBACK_RENEW;
 
 error:
-   close(new_fd);
if (cl && cl->fd_handler)
- ecore_main_fd_handler_del(cl->fd_handler);
+ {
+ecore_main_fd_handler_del(cl->fd_handler);
+close(cl->fd);
+free(cl);
+ }
return ECORE_CALLBACK_RENEW;
 }
 
-- 
1.7.0.4

--
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] more fd insanity

[Mike McCormack]

On 12/12/2010 09:28 PM, Mike Blumenkrantz wrote:
> ERR<24447>:ecore ecore_main.c:316 _ecore_main_fdh_poll_mark_active() 
> epoll_wait failed 22
> ERR<24447>:ecore ecore_main.c:316 _ecore_main_fdh_poll_mark_active() 
> epoll_wait failed 22
> ERR<24447>:ecore ecore_main.c:316 _ecore_main_fdh_poll_mark_active() 
> epoll_wait failed 22
> ERR<24447>:ecore ecore_main.c:316 _ecore_main_fdh_poll_mark_active() 
> epoll_wait failed 22
> ERR<24447>:ecore ecore_main.c:316 _ecore_main_fdh_poll_mark_active() 
> epoll_wait failed 22
> ERR<24447>:ecore ecore_main.c:758 ecore_main_fd_handler_add() Failed to add 
> poll on fd 38 (errno = 22)!
> ERR<24447>:ecore ecore_main.c:758 ecore_main_fd_handler_add() Failed to add
> poll on fd 44 (errno = 22)!
>
>
> Woke up to 3gb of the first line logged to my disk this morning.  Suggestions?

Hey Mike,

Somewhere your epoll_fd is being closed.  We can add if(it_fails) recover();
everywhere or you can figure out who's closing random fds...

thanks,

Mike

--
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] ecore epoll bug fix? (http://trac.enlightenment.org/e/ticket/637)

[Mike McCormack]

On 12/09/2010 08:47 PM, Lucas De Marchi wrote:


Mike McCormack, why are we calling shutdown + init and reconstructing
the epoll? Is that because of the dup/fork thing?


fds are not always automatically removed from the epoll set when close() is 
called.
If the fd has been dup()'ed and closed, it can still be in the epoll set but not
removable.

This has been discussed on this list before.  Please read the list archives and
see the attached code, which I will repost to save you searching.

thanks,

Mike
/*
 * This program demonstrates the following problem with epoll:
 *
 * epoll refers to fds, but close only removes an fd from epoll
 *  if there are no other references to the filp
 *
 * After dup'ing the fd, adding it to epoll and then closing it,
 *  there is no way to remove it from epoll's fd set any more...
 *
 * Build with:  gcc -Wall -o epoll_dup epoll_dup.c
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static inline void die(int line, const char *str)
{
	fprintf(stderr, "%d %s %d\n", line, str, errno);
	exit(1);
}

#define DIE(str) die(__LINE__, str)

int main(int argc, char **argv)
{
	struct epoll_event ev = {0};
	int r, con, con2, efd;
	int count = 1;

	/* open something pollable */
	printf("open console\n");
	con = open("/dev/tty", O_RDWR);
	if (con < 0)
		DIE("open");

	efd = epoll_create(1);
	if (efd < 0)
		DIE("epoll_create");

	printf("dup console\n");
	con2 = dup(con);

	ev.events = EPOLLIN;
	ev.data.ptr = &main;
	r = epoll_ctl(efd, EPOLL_CTL_ADD, con, &ev);
	if (r < 0)
		DIE("epoll_ctl");

	r = close(con);
	if (r < 0)
		DIE("close");

	/*
	 * fd is now in epoll, but close didn't tell epoll that it's gone
	 * because there's still a filp around with another fd pointing to it
	 */

	/* can't remove it by it's old fd handle */
	ev.events = EPOLLIN;
	ev.data.ptr = &main;
	r = epoll_ctl(efd, EPOLL_CTL_DEL, con, &ev);
	if (r < 0)
		fprintf(stderr, "can't remove closed fd... (%d)\n", errno);

	/* can't remove it by the dup'ed handle */
	ev.events = EPOLLIN;
	ev.data.ptr = &main;
	r = epoll_ctl(efd, EPOLL_CTL_DEL, con2, &ev);
	if (r < 0)
		fprintf(stderr, "can't remove dup'ed fd... (%d)\n", errno);

	/* but it still works */
	printf("press enter\n");
	while (count--) {
		unsigned char ch;

		r = epoll_wait(efd, &ev, 1, -1);
		if (r < 0)
			DIE("fail");
		fprintf(stderr, "epoll ret = %d event = %08x data=%p\n", r, ev.events, ev.data.ptr);
		read(con2, &ch, 1);
	}

	close(efd);
	close(con2);

	return 0;
}
--
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] elm_transit patch

[Mike McCormack]

Hello Hermet,

Please avoid changing spacing in your patches, it makes them harder to read.
Additionally, I don't think Raster will appreciate you coming up with a
new indentation style for EFL...

Patches should contain the important pieces you want to change, and nothing 
else.

thanks,

Mike

-   transit->time.duration = duration;
-
-   transit->time.begin = ecore_loop_time_get();
+   
+   transit->time.duration = duration;
+   transit->time.begin = ecore_loop_time_get();




On 12/09/2010 02:28 PM, ChunEon Park wrote:
> Sorry, it filtered the patch file .
> try again.
>
>
> -Original Message-
> From: ChunEon Park [mailto:chuneon.p...@samsung.com]
> Sent: Thursday, December 09, 2010 2:23 PM
> To: 'enlightenment-devel@lists.sourceforge.net'
> Subject: elm_transit patch
>
> Hello, This is Hermet.
>
> Here is a first patch for the elm_transit.
>
> * deprecated elm_transit_event_block_set and added
> elm_transit_event_enabled_set
> * modified event_enabled = EINA_FALSE as a default
>
> Thanks.
>
>
>
> --
> 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


--
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] ecore epoll bug fix? (http://trac.enlightenment.org/e/ticket/637)

[Mike McCormack]

On 12/09/2010 11:57 AM, Mike Blumenkrantz wrote:

>>_ecore_main_loop_shutdown();
>>_ecore_main_loop_init();
>> }

> Okay, but the only place that _ecore_main_fdh_poll_del can be called from is
> ecore_main_fd_handler_del.  If a bad fd gets into epoll and then is selected 
> on
> without being removed, it will just loop infinitely without ever being able to
> be removed, just like we're seeing in this bug.  Might be good to add
> shutdown+init inside bads_rem if no bads are found, yes?

Getting a stale fd in epoll is a bug.  It means somebody closed the fd without
removing it from ecore_main_loop, and that should be fixed.

Rather than adding more bandaids, it would be better to fix the root cause of 
the problem.

thanks,

Mike


--
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] ecore epoll bug fix? (http://trac.enlightenment.org/e/ticket/637)

[Mike McCormack]

On 12/09/2010 10:31 AM, Mike Blumenkrantz wrote:

>>> Upon arriving at _ecore_main_fd_handlers_bads_rem, perhaps we should rebuild
>>> the epoll fd (ie close it, then reopen and add all fds again) as well by
>>> default? Or, if not by default, at least rebuild it if we don't find
>>> anything by looping over the inlist?
>>
>> It's already done.  See ecore/src/lib/ecore/ecore_main.c # 272
>>
>> thanks,
>>
>> Mike
>>
> Line 272 is this:
> if (!ECORE_MAGIC_CHECK(fdh, ECORE_MAGIC_FD_HANDLER))

I've still got patches floating on top of that file.  I meant here:

static inline void
_ecore_main_fdh_poll_del(Ecore_Fd_Handler *fdh)
...
if ((epoll_ctl(efd, EPOLL_CTL_DEL, fdh->fd, &ev) < 0))
  {
 if (errno == EBADF)
   {
  WRN("fd %d was closed, can't remove from epoll - reinit!",
  fdh->fd);
  _ecore_main_loop_shutdown();
  _ecore_main_loop_init();
   }

thanks,

Mike

--
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] ecore epoll bug fix? (http://trac.enlightenment.org/e/ticket/637)

[Mike McCormack]

On 12/09/2010 01:20 AM, Mike Blumenkrantz wrote:
> After some brainstorming in irc today, we arrived at an interesting question
> regarding the infinite loop bug after finding this
> http://stackoverflow.com/questions/883282/select-ebadf-which-fd-is-bad
>
> Upon arriving at _ecore_main_fd_handlers_bads_rem, perhaps we should rebuild
> the epoll fd (ie close it, then reopen and add all fds again) as well by
> default? Or, if not by default, at least rebuild it if we don't find anything
> by looping over the inlist?

It's already done.  See ecore/src/lib/ecore/ecore_main.c # 272

thanks,

Mike


--
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

[Mike McCormack]

On 12/02/2010 08:20 PM, Lucas De Marchi wrote:
> On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAIL  wrote:
>> Hi,
>>
>> On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormack  
>> wrote:
>>> Rather than using malloc'ed list entries in the mail loop, use a single
>>> linked in-place list.
>>>
>>> This avoid lots of mallocs and frees as the main loop iterates.
>>
>> I like the idea, but I fear that doing change to the core main loop
>> structure could break things. Maybe we should post pone this change to
>> 1.1. From my point of view we already did to much change to ecore main
>> loop during the beta cycle.
>
> I agree.
>
> How long are we for 1.0 release?

Come on guys.

The only reason that you're seeing this is that I don't commit directly to SVN.

This is a tweak on fixes that have been put in by others in the last few days.
If you object to this, please read the SVN commits list and object to the other
patches in the same area.

thanks,

Mike

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [PATCH] ecore main loop "fd_handlers_to_call" list optimization

[Mike McCormack]

Hi All,

Rather than using malloc'ed list entries in the mail loop, use a single linked 
in-place list.

This avoid lots of mallocs and frees as the main loop iterates.

thanks,

Mike
>From cd148e46e37f11b603df89faa5e0d86f7382ac9a Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Thu, 2 Dec 2010 14:58:50 +0900
Subject: [PATCH] Convert fd_handlers_to_call to a singly linked list

---
 trunk/ecore/src/lib/ecore/ecore_main.c |  120 +---
 1 files changed, 65 insertions(+), 55 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_main.c b/trunk/ecore/src/lib/ecore/ecore_main.c
index d6de0c7..0902146 100644
--- a/trunk/ecore/src/lib/ecore/ecore_main.c
+++ b/trunk/ecore/src/lib/ecore/ecore_main.c
@@ -61,6 +61,7 @@ struct _Ecore_Fd_Handler
 {
EINA_INLIST;
ECORE_MAGIC;
+   Ecore_Fd_Handler*next_ready;
int  fd;
Ecore_Fd_Handler_Flags   flags;
Ecore_Fd_Cb  func;
@@ -119,9 +120,9 @@ static Eina_List*fd_handlers_with_prep = NULL;
 static Eina_List*fd_handlers_with_buffer = NULL;
 static Eina_List*fd_handlers_to_delete = NULL;
 
-static Eina_List*fd_handlers_to_call = NULL;
-static Eina_List*fd_handlers_to_call_current;
-static Eina_List*fd_handlers_to_call_current_next;
+/* single linked list of ready fdhs, terminated by loop to self */
+static Ecore_Fd_Handler*fd_handlers_to_call;
+static Ecore_Fd_Handler*fd_handlers_to_call_current;
 
 #ifdef _WIN32
 static Ecore_Win32_Handler *win32_handlers = NULL;
@@ -154,6 +155,24 @@ static gboolean ecore_idling;
 static gboolean ecore_fds_ready;
 #endif
 
+static inline void
+_ecore_try_add_to_call_list(Ecore_Fd_Handler *fdh)
+{
+   /* check if this fdh is already in the list */
+   if (fdh->next_ready)
+ return;
+   if (fdh->read_active || fdh->write_active || fdh->error_active)
+ {
+/*
+ * make sure next_ready is non-null by pointing to ourselves
+ * use that to indicate this fdh is in the ready list
+ * insert at the head of the list to avoid trouble
+ */
+fdh->next_ready = fd_handlers_to_call ? fd_handlers_to_call : fdh;
+fd_handlers_to_call = fdh;
+ }
+}
+
 #ifdef HAVE_EPOLL
 static inline int
 _ecore_get_epoll_fd(void)
@@ -320,8 +339,7 @@ static inline int _ecore_main_fdh_poll_mark_active(void)
for (i = 0; i < ret; i++)
  {
 Ecore_Fd_Handler *fdh;
-Eina_Bool pst, st;
-
+
 fdh = ev[i].data.ptr;
 if (!ECORE_MAGIC_CHECK(fdh, ECORE_MAGIC_FD_HANDLER))
   {
@@ -334,15 +352,15 @@ static inline int _ecore_main_fdh_poll_mark_active(void)
  ERR("deleted fd in epoll");
  continue;
   }
-pst = st = fdh->read_active | fdh->write_active | fdh->error_active;
-if ((ev[i].events & EPOLLIN) && (!fdh->read_active))
- st = fdh->read_active = EINA_TRUE;
-if ((ev[i].events & EPOLLOUT) && (!fdh->write_active))
- st = fdh->write_active = EINA_TRUE;
-if ((ev[i].events & EPOLLERR) && (!fdh->error_active))
- st = fdh->error_active = EINA_TRUE;
-if (pst != st)
-  fd_handlers_to_call = eina_list_append(fd_handlers_to_call, fdh);
+
+if (ev[i].events & EPOLLIN)
+  fdh->read_active = EINA_TRUE;
+if (ev[i].events & EPOLLOUT)
+  fdh->write_active = EINA_TRUE;
+if (ev[i].events & EPOLLERR)
+  fdh->error_active = EINA_TRUE;
+
+_ecore_try_add_to_call_list(fdh);
  }
 
return ret;
@@ -353,7 +371,6 @@ static inline int _ecore_main_fdh_poll_mark_active(void)
 static inline int _ecore_main_fdh_poll_mark_active(void)
 {
Ecore_Fd_Handler *fdh;
-   Eina_Bool pst, st;
int ret = 0;
 
/* call the prepare callback for all handlers */
@@ -362,15 +379,15 @@ static inline int _ecore_main_fdh_poll_mark_active(void)
 if (fdh->delete_me)
continue;
 
-pst = st = fdh->read_active | fdh->write_active | fdh->error_active;
-if ((fdh->gfd.revents & G_IO_IN) && (!fdh->read_active))
- st = fdh->read_active = EINA_TRUE;
-if ((fdh->gfd.revents & G_IO_OUT) && (!fdh->write_active))
- st = fdh->write_active = EINA_TRUE;
-if ((fdh->gfd.revents & G_IO_ERR) && (!fdh->error_active))
- st = fdh->error_active = EINA_TRUE;
-if (pst != st)
-  fd_handlers_to_call = eina_list_append(fd_handlers_to_call, fdh);
+if (fdh->gfd.revents & G_IO_IN)
+   fdh->read_active = EINA_TRUE;
+if (fdh->gfd.revents & G_IO_OUT)
+   fdh->write_active = EINA_TRUE;
+if (fdh->gfd.revents & G_IO_ERR)
+   fdh->error_active = EINA_TRUE;
+
+_ecore_try_add_t

Re: [E-devel] [Patch] small patch for genlist parameter verification routine.

[Mike McCormack]

On 11/03/2010 11:09 AM, Carsten Haitzler (The Rasterman) wrote:

>> The advantage of adding a zero return code now would be that you can extend
>> APIs that return error codes more easily. e.g. the case in evas where you
>> currently only support a rectangular region but may support non-rectangular
>> regions in the future.
>
> there's another way to handle that :)

Yes... but checking versions to deal with API differences is broken...

thanks,

Mike

--
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware, 
phishing sites, and compromised hosts - saving your company time, 
money, and embarrassment.   Learn More! 
http://p.sf.net/sfu/hpdev2dev-nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] small patch for genlist parameter verification routine.

[Mike McCormack]

On 11/02/2010 06:05 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 02 Nov 2010 16:23:32 +0900 Mike McCormack
> said:
>
>>
>> btw. A nit of mine which I've mentioned before...
>>
>> Since you're going to check and "fail" it would be nice to return an
>> indication. That's a bit hard to do if everything returns void...  any plans
>> to fix that?
>
> no. as that'd break api. :)

In general, adding int return where there was void does not break API, because 
no code
could have relied on the undefined return.  Function pointers are a special case
for which it will cause a source break, but there's still no ABI break.

The advantage of adding a zero return code now would be that you can extend APIs
that return error codes more easily. e.g. the case in evas where you currently 
only
support a rectangular region but may support non-rectangular regions in the 
future.

>  there are environment vars that will cause aborts
> and prints/logging on errors for catching them, so return isnt needed as such
> as then every func needs the error catching done in the app - not in the lib.
> good luck getting everyone to check their errors. as such these kind of funcs
> should NEVER fail unless the user is literally mis-using them (bug in app - 
> and
> if its an app bug how do u trust the app to also check all errors properly?) 
> :)
> at least thats the topic here. recovering from potential segv/crash bugs at
> runtime by checking, allowing for even a buggy app to "survive longer" but it
> allows for catching the err if u set the env vars (and forcing a crash at that
> point).

Well, if you look at Daniel's suggestion, you can see there there's no way
to distinguish the "failed case" from the successful case, and the
failure is ignored.

  EAPI void
  elm_genlist_item_selected_set(Elm_Genlist_Item *it, Eina_Bool selected)
  {
+   if (!it) return;


According to what you're saying, it should be:

  EAPI void
  elm_genlist_item_selected_set(Elm_Genlist_Item *it, Eina_Bool selected)
  {
+   assert(it != NULL);

But that's kind of pointless, because you'll crash with a NULL pointer
dereference anyway.

thanks,

MIke

--
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware, 
phishing sites, and compromised hosts - saving your company time, 
money, and embarrassment.   Learn More! 
http://p.sf.net/sfu/hpdev2dev-nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] small patch for genlist parameter verification routine.

[Mike McCormack]

btw. A nit of mine which I've mentioned before...

Since you're going to check and "fail" it would be nice to return an indication.
That's a bit hard to do if everything returns void...  any plans to fix that?

That deosn't mean everything has to check for failure/non-failure, but it at
least should be possible, prevented by the API.

thanks,

Mike

On 11/02/2010 02:31 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 31 Oct 2010 12:55:15 +0900 Daniel Juyung Seo
> said:
>
> encouragement: good idea. indeed it hadn't been done because only until
> recently did items of an obj have any form of magic numbers/checking. it 
> should
> be done. it just had no infra before
>
> badness: i see you are checking... but your checks make some pretty big
> assumptions. they are going to be more likely to fail than catch an error and
> save the programmer from a crash. just think about it for a bit.
>
> normally the type checks are fairly conservative. they do depend on the 
> pointer
> pointing to "accessible memory". but that is all they depend on. they check 
> the
> first 4 bytes to see that it is an evas object at all (well evas does that) so
> as long as what you point to has its first 4 bytes accessible, the checks can
> gracefully fail (otherwise they will catch the error at some stage). so if it
> meets the magic number requirements (a chance of 1 in 4 billion that something
> could get past this check and NOT be an evas object. fairly small chance i'd
> say), then the other fields should be validly maintained, and it can follow
> this trail of breadcrumbs (check object type pointer, smart data pointer and
> more). each stage is a fairly solid "hard to get by without being caught" 
> layer.
>
> now have a look at your check. the first thing is good - it checks for a 
> common
> case. NULL. (the above do check it also first before anything else as well).
> but then the next step is really really really risky. you DEPEND on it 
> pointing
> to memory that has wd pointer at the right spot and this also being valid and
> pointing to an obj - then the series of safer checks begin. the 2 levels
> (depending on it ptr and wd ptr content to work) is really risky. no magic
> number check first for example etc. when doing checks generally you want the
> check to gracefully fail and catch the error without a crash as often as
> possible. if it doesn't at least if the pointer is invalid (pointing outside 
> of
> memory space) then its trivially catchable at that 1 dereference. you have 2
> derefs on the same line so which one will cause the crash when you have gdb
> attached? it's a bit harder to catch.
>
> (while i'm at it.. yes we COULd even filter out invalid pointers. we could add
> a pointer validity check in 1 of 2 ways. 1. look at /proc/self/maps and see if
> ptr is within any of the given ranges. if it isn't - its outside of memory
> space, or.. we can use the kernels trapping abilities and set custom sigsegv
> +sigbus handlers (save the old) when we check the magic number. which can 
> avoid
> a segv completely in this case at runtime, but the cost is non-trivial to set
> up such handlers all the time and restore them. it's going to slow down an app
> a lot at runtime so it's dubious if its a good idea, even if in theory its
> possible to do. we could make it enableable given an env var too - again, only
> useful then if env var on and then.,. we pay the slowdown cost too)
>
>> Hi there,
>>
>> This is a very small patch for genlist parameter verification.
>> Please review and apply this to upstream.
>>
>> Thank you.
>> Daniel Juyung Seo.
>
>


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [PATCH] Reinit main loop if somebody passes a closed fd to epoll

[Mike McCormack]

On 10/19/2010 10:19 PM, Gustavo Sverzut Barbieri wrote:

On Tue, Oct 19, 2010 at 11:16 AM, Mike McCormack
  wrote:

Hi Guys,

Superficially tested... issue is if somebody does:

close(fd);
ecore_main_fd_handler_del(fdh);

epoll can't remove the fd because it's already closed, so we get an EBADF
from the kernel.
Work around the broken case by issuing a WARN() and reinitializing ecore.


WARN takes no trailing \n


Ack.


other than that, why do we need to reinit it? Just let the fdh handle
be removed from the list and never be considered anymore. I don't see
why we need to reinit it.


Because the fd *may* still be in the epoll array.   If somebody happened
to dup() that fd, then the kernel will still have a filp hanging around
and the fd will not be automatically removed from the epoll set.  The
kernel only automatically removes an fd from epoll when its filp is
destroyed, not when the fd (which is just a reference to the filp) is
closed.

See the attached program for details.  Kernel guys are aware of this,
and say that it works as designed...

thanks,

Mike
/*
 * This program demonstrates the following problem with epoll:
 *
 * epoll refers to fds, but close only removes an fd from epoll
 *  if there are no other references to the filp
 *
 * After dup'ing the fd, adding it to epoll and then closing it,
 *  there is no way to remove it from epoll's fd set any more...
 *
 * Build with:  gcc -Wall -o epoll_dup epoll_dup.c
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static inline void die(int line, const char *str)
{
	fprintf(stderr, "%d %s %d\n", line, str, errno);
	exit(1);
}

#define DIE(str) die(__LINE__, str)

int main(int argc, char **argv)
{
	struct epoll_event ev = {0};
	int r, con, con2, efd;
	int count = 1;

	/* open something pollable */
	printf("open console\n");
	con = open("/dev/tty", O_RDWR);
	if (con < 0)
		DIE("open");

	efd = epoll_create(1);
	if (efd < 0)
		DIE("epoll_create");

	printf("dup console\n");
	con2 = dup(con);

	ev.events = EPOLLIN;
	ev.data.ptr = &main;
	r = epoll_ctl(efd, EPOLL_CTL_ADD, con, &ev);
	if (r < 0)
		DIE("epoll_ctl");

	r = close(con);
	if (r < 0)
		DIE("close");

	/*
	 * fd is now in epoll, but close didn't tell epoll that it's gone
	 * because there's still a filp around with another fd pointing to it
	 */

	/* can't remove it by it's old fd handle */
	ev.events = EPOLLIN;
	ev.data.ptr = &main;
	r = epoll_ctl(efd, EPOLL_CTL_DEL, con, &ev);
	if (r < 0)
		fprintf(stderr, "can't remove closed fd... (%d)\n", errno);

	/* can't remove it by the dup'ed handle */
	ev.events = EPOLLIN;
	ev.data.ptr = &main;
	r = epoll_ctl(efd, EPOLL_CTL_DEL, con2, &ev);
	if (r < 0)
		fprintf(stderr, "can't remove dup'ed fd... (%d)\n", errno);

	/* but it still works */
	printf("press enter\n");
	while (count--) {
		unsigned char ch;

		r = epoll_wait(efd, &ev, 1, -1);
		if (r < 0)
			DIE("fail");
		fprintf(stderr, "epoll ret = %d event = %08x data=%p\n", r, ev.events, ev.data.ptr);
		read(con2, &ch, 1);
	}

	close(efd);
	close(con2);

	return 0;
}
--
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

[E-devel] [PATCH] Reinit main loop if somebody passes a closed fd to epoll

[Mike McCormack]

Hi Guys,

Superficially tested... issue is if somebody does:

close(fd);
ecore_main_fd_handler_del(fdh);

epoll can't remove the fd because it's already closed, so we get an EBADF from 
the kernel.
Work around the broken case by issuing a WARN() and reinitializing ecore.

thanks,

Mike

>From bba7e843c58983278dbee18adee02e52da972207 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Tue, 19 Oct 2010 22:10:40 +0900
Subject: [PATCH 2/2] Reinit main loop if somebody passes a closed fd to epoll

---
 trunk/ecore/src/lib/ecore/ecore_main.c |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_main.c b/trunk/ecore/src/lib/ecore/ecore_main.c
index f9d142f..e518566 100644
--- a/trunk/ecore/src/lib/ecore/ecore_main.c
+++ b/trunk/ecore/src/lib/ecore/ecore_main.c
@@ -237,10 +237,18 @@ _ecore_main_fdh_poll_del(Ecore_Fd_Handler *fdh)
memset(&ev, 0, sizeof (ev));
INF("removing poll on %d", fdh->fd);
/* could get an EBADF if somebody closed the FD before removing it */
-   if ((epoll_ctl(efd, EPOLL_CTL_DEL, fdh->fd, &ev) < 0) &&
-   (errno != EBADF))
+   if ((epoll_ctl(efd, EPOLL_CTL_DEL, fdh->fd, &ev) < 0))
  {
-ERR("Failed to delete epoll fd %d! (errno=%d)", fdh->fd, errno);
+if (errno == EBADF)
+  {
+ WARN("fd %d was closed, can't remove from epoll - reinit!\n", fdh->fd);
+ _ecore_main_loop_shutdown();
+ _ecore_main_loop_init();
+  }
+else
+  {
+ ERR("Failed to delete epoll fd %d! (errno=%d)", fdh->fd, errno);
+  }
  }
 #elif USE_G_MAIN_LOOP
fdh->gfd.fd = fdh->fd;
-- 
1.7.0.4

--
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

[E-devel] [PATCH] Fix a build issue with both epoll and g_main_loop()

[Mike McCormack]

>From 4871c0fcc39192065e37eb0bfec8889ac759f01b Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Tue, 19 Oct 2010 22:04:38 +0900
Subject: [PATCH 1/2] Fix a build issue with both epoll and g_main_loop()

---
 trunk/ecore/src/lib/ecore/ecore_main.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_main.c b/trunk/ecore/src/lib/ecore/ecore_main.c
index 1b33a19..f9d142f 100644
--- a/trunk/ecore/src/lib/ecore/ecore_main.c
+++ b/trunk/ecore/src/lib/ecore/ecore_main.c
@@ -324,9 +324,8 @@ static inline int _ecore_main_fdh_poll_mark_active(void)
 
return ret;
 }
-#endif
 
-#ifdef USE_G_MAIN_LOOP
+#elif USE_G_MAIN_LOOP
 
 static inline int _ecore_main_fdh_poll_mark_active(void)
 {
@@ -350,6 +349,10 @@ static inline int _ecore_main_fdh_poll_mark_active(void)
return ret;
 }
 
+#endif
+
+#ifdef USE_G_MAIN_LOOP
+
 /* like we are about to enter main_loop_select in  _ecore_main_select */
 static gboolean
 _ecore_main_gsource_prepare(GSource *source, gint *next_time)
-- 
1.7.0.4

--
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] [PATCH] Reinit epoll when forking

[Mike McCormack]

On 10/19/2010 09:54 PM, Gustavo Sverzut Barbieri wrote:
> On Tue, Oct 19, 2010 at 10:47 AM, Mike McCormack
>   wrote:
>>
>> Hi Raster,
>>
>> This is an attempt to fix the epoll/fork() issue reported to me where
>> we end up with a single epoll fd shared between two processes after  a
>> fork() in E.
>>
>> I've tested with elementary test in epoll and non-epoll combinations,
>> and all appears to be well.  Please check it solves the issue you saw,
>> and reformat the code as you see fit... ;-)
>
> Well, it may work, but this is not the way to go with it. IMO the
> correct way would be to tell for sure ecore it is being executed from
> a fork, but another option is to use epoll_create1(EPOLL_CLOEXEC),
> then handle the EBADF in select, recreating it upon errors (just be
> warned that may happen that the fd number is reused by the app if it
> open fds before going back to main loop)

Well, the problem is that there's no exec().  Somewhere E does a fork()
and dlopen() to load a plugin quickly.

I could add checks around all the forks in the codebase, but this way seems
more reliable.

The EBADF problem can be solved by reinitializing epoll when we get that
return from epoll_add, though the root cause is closing an fd before
removing it from ecore.

thanks,

Mike

--
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

[E-devel] [PATCH] Reinit epoll when forking

[Mike McCormack]

Hi Raster,

This is an attempt to fix the epoll/fork() issue reported to me where
we end up with a single epoll fd shared between two processes after  a
fork() in E.

I've tested with elementary test in epoll and non-epoll combinations,
and all appears to be well.  Please check it solves the issue you saw,
and reformat the code as you see fit... ;-)

thanks,

Mike
>From af67c451dedbe35d4867f785c8267a2d59462801 Mon Sep 17 00:00:00 2001
From: Mike McCormack 
Date: Tue, 19 Oct 2010 21:27:50 +0900
Subject: [PATCH] Reinit epoll when forking

---
 trunk/ecore/src/lib/ecore/ecore_main.c |   69 ++--
 1 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/trunk/ecore/src/lib/ecore/ecore_main.c 
b/trunk/ecore/src/lib/ecore/ecore_main.c
index e5e9db0..1b33a19 100644
--- a/trunk/ecore/src/lib/ecore/ecore_main.c
+++ b/trunk/ecore/src/lib/ecore/ecore_main.c
@@ -133,10 +133,13 @@ static doublet2 = 0.0;
 
 #ifdef HAVE_EPOLL
 static int epoll_fd = -1;
-static GPollFD ecore_epoll_fd;
+static pid_t epoll_pid;
 #endif
 
 #ifdef USE_G_MAIN_LOOP
+#ifdef HAVE_EPOLL
+static GPollFD ecore_epoll_fd;
+#endif
 static GSource *ecore_glib_source;
 static guint ecore_glib_source_id;
 static GMainLoop* ecore_main_loop;
@@ -146,6 +149,33 @@ static gboolean ecore_fds_ready;
 
 #ifdef HAVE_EPOLL
 static inline int
+_ecore_get_epoll_fd(void)
+{
+   if (epoll_pid && epoll_pid != getpid())
+ {
+/* forked! */
+_ecore_main_loop_shutdown();
+ }
+   if (epoll_pid == 0 && epoll_fd < 0)
+ {
+_ecore_main_loop_init();
+ }
+   return epoll_fd;
+}
+
+static inline int
+_ecore_epoll_add(int efd, int fd, int events, void *ptr)
+{
+   struct epoll_event ev;
+
+   memset(&ev, 0, sizeof (ev));
+   ev.events = events;
+   ev.data.ptr = ptr;
+   INF("adding poll on %d %08x", fd, events);
+   return epoll_ctl(efd, EPOLL_CTL_ADD, fd, &ev);
+}
+
+static inline int
 _ecore_poll_events_from_fdh(Ecore_Fd_Handler *fdh)
 {
int events = 0;
@@ -179,13 +209,8 @@ _ecore_main_fdh_poll_add(Ecore_Fd_Handler *fdh)
 {
int r = 0;
 #ifdef HAVE_EPOLL
-   struct epoll_event ev;
-
-   memset(&ev, 0, sizeof (ev));
-   ev.events = _ecore_poll_events_from_fdh(fdh);
-   ev.data.ptr = fdh;
-   INF("adding poll on %d %08x", fdh->fd, ev.events);
-   r = epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fdh->fd, &ev);
+   r = _ecore_epoll_add(_ecore_get_epoll_fd(), fdh->fd,
+_ecore_poll_events_from_fdh(fdh), fdh);
 #elif USE_G_MAIN_LOOP
fdh->gfd.fd = fdh->fd;
fdh->gfd.events = _gfd_events_from_fdh(fdh);
@@ -207,11 +232,12 @@ _ecore_main_fdh_poll_del(Ecore_Fd_Handler *fdh)
 {
 #ifdef HAVE_EPOLL
struct epoll_event ev;
+   int efd = _ecore_get_epoll_fd();
 
memset(&ev, 0, sizeof (ev));
INF("removing poll on %d", fdh->fd);
/* could get an EBADF if somebody closed the FD before removing it */
-   if ((epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fdh->fd, &ev) < 0) &&
+   if ((epoll_ctl(efd, EPOLL_CTL_DEL, fdh->fd, &ev) < 0) &&
(errno != EBADF))
  {
 ERR("Failed to delete epoll fd %d! (errno=%d)", fdh->fd, errno);
@@ -237,12 +263,13 @@ _ecore_main_fdh_poll_modify(Ecore_Fd_Handler *fdh)
int r = 0;
 #ifdef HAVE_EPOLL
struct epoll_event ev;
+   int efd = _ecore_get_epoll_fd();
 
memset(&ev, 0, sizeof (ev));
ev.events = _ecore_poll_events_from_fdh(fdh);
ev.data.ptr = fdh;
INF("modifing epoll on %d to %08x", fdh->fd, ev.events);
-   r = epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fdh->fd, &ev);
+   r = epoll_ctl(efd, EPOLL_CTL_MOD, fdh->fd, &ev);
 #elif USE_G_MAIN_LOOP
fdh->gfd.fd = fdh->fd;
fdh->gfd.events = _gfd_events_from_fdh(fdh);
@@ -263,9 +290,10 @@ static inline int _ecore_main_fdh_poll_mark_active(void)
 {
struct epoll_event ev[32];
int i, ret;
+   int efd = _ecore_get_epoll_fd();
 
memset(&ev, 0, sizeof (ev));
-   ret = epoll_wait(epoll_fd, ev, sizeof(ev) / sizeof(struct epoll_event), 0);
+   ret = epoll_wait(efd, ev, sizeof(ev) / sizeof(struct epoll_event), 0);
if (ret < 0)
  {
 if (errno == EINTR) return -1;
@@ -475,6 +503,19 @@ _ecore_main_loop_init(void)
epoll_fd = epoll_create(1);
if (epoll_fd < 0)
   CRIT("Failed to create epoll fd!");
+   epoll_pid = getpid();
+
+   /* add polls on all our file descriptors */
+   Ecore_Fd_Handler *fdh;
+   EINA_INLIST_FOREACH(fd_handlers, fdh)
+ {
+if (fdh->delete_me)
+   continue;
+_ecore_epoll_add(epoll_fd, fdh->fd,
+ _ecore_poll_events_from_fdh(fdh), fdh);
+_ecore_main_fdh_poll_add(fdh);
+ }
+
 #endif
 
 #ifdef USE_G_MAIN_LOOP
@@ -514,6 +555,8 @@ _ecore_main_loop_shutdown(void)
 close(epoll_fd);
 epoll_fd = -1;
  }
+
+epoll_pid = 0;
 #endif
 }

Re: [E-devel] Small assorted changes to ecore_con_url

[Mike McCormack]

On 10/09/2010 10:52 AM, Gustavo Sverzut Barbieri wrote:

>> can you please attach them, not mail them as inline patches. they get
>> line-wrapped and re-formatted so they dont work anymore :(
>
> AFAIK he uses git send-email, that does the "right thing [tm]". All
> you need is a proper mail client, in Gmail we have "show original"
> that you can just copy&  paste it and commit... I even have a
> script[1] that svn add/svn rm files as required.

Try using the --attach flag with git format-patch:

git format-patch --stdout --attach -n origin  | mail

there's a way to dump patches to an imap Drafts folder too, so you can
add some comments at the top of the mail, or check your patches before sending:

git format-patch --stdout --attach origin | git imap-send

Some guy working on Wine implemented these a while back...

thanks,

Mike

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel