Re: [E-devel] [module mail] question or maybe a bug ?

2009-09-08 Thread Christopher Michael 
Sure, patches are always welcome :)

dh

Nicolas H. wrote:
>>> 2009/9/4 Christopher Michael >> >
>>>
>>> Nicolas H. wrote:
>>>  > Hello everyone here,
>>>  >
>>>  >
>>>  > I hope it's the right place to send this, I was recommended to do
>>> so on
>>>  > the #e irc.
>>>  >
>>>  > So, I already have used the mail module in the past and I
>>> remember it
>>>  > used to display the number of new (unread) e-mails of my mailbox,
>>> using
>>>  > pop3. This seems quite expected. I would be really surprised
>>> if I'm
>>>  > wrong about this.
>>>  >
>>>  > Yesterday I tried it again but this time instead of displaying
>>> the
>>>  > number of unread e-mails, it displays the total number of
>>> e-mails. Which
>>>  > I find weird (is it really the purpose of the mail module ?).
>>>  >
>>>  > So I checked the source code here :
>>>  > http://trac.enlightenment.org/e/browser … A/mail/src
>>>  >
>>>
>>> 
>>>  >
>>>  > and noticed that there is a field called num_new that is
>>> used... and
>>>  > because of its name, and because of the way it is used, I
>>> think it is
>>>  > intended to get the number of new messages.
>>>  >
>>>  > For instance, in e_mod_main.c :
>>>  >
>>>  >
>>>  > Code:
>>>  >
>>>  > 649void
>>>  > 650_mail_set_text (void *data)
>>>  > 651{
>>>  > 652  Instance *inst = data;
>>>  > 653  Eina_List *l;
>>>  > 654  char buf[1024];
>>>  > 655  int count = 0;
>>>  > 656
>>>  > 657  if (!inst)
>>>  > 658return;
>>>  > 659
>>>  > 660  for (l = inst->ci->boxes; l; l = l->next)
>>>  > 661{
>>>  > 662   Config_Box *cb;
>>>  > 663
>>>  > 664   cb = l->data;
>>>  > 665   if (!cb)
>>>  > 666 continue;
>>>  > 667   count += cb->num_new;
>>>  > 668}
>>>  > 669
>>>  > 670  if (count > 0)
>>>  > 671{
>>>  > ...
>>>  >
>>>  >
>>>  > The loop seems to count the sum of all new messages of the
>>> different
>>>  > mailboxes.
>>>  >
>>>  > In pop.c :
>>>  >
>>>  >
>>>  > Code:
>>>  >
>>>  > static void
>>>  > 215_mail_cb_mouse_down (void *data, Evas * e, Evas_Object
>>> * obj,
>>>  > 216 void *event_info)
>>>  > 217{
>>>  > ...
>>>  > 254  snprintf (buf, sizeof (buf), "%s: %d/%d",
>>> cb->name,
>>>  > cb->num_new,
>>>  > 255cb->num_total);
>>>  > ...
>>>  >
>>>  >
>>>  >
>>>  > this seems to be the code what displays the small pop-up with
>>> name of
>>>  > the mailbox, plus number of new messages and number of all
>>> messages
>>>  > (that can be expected to be usually different).
>>>  >
>>>  > Then here in pop.c :
>>>  >
>>>  >
>>>  > Code:
>>>  >
>>>  > 156static int
>>>  > 157_mail_pop_server_data (void *data, int type, void *event)
>>>  > 158{
>>>  > ...
>>>  > 203 case POP_STATE_STATUS_OK:
>>>  > 204  if (sscanf (in, "+OK %i %i", &num, &total) == 2)
>>>  > 205{
>>>  > 206  pc->config->num_new = num;
>>>  > 207  pc->config->num_total = num;
>>>  > 208}
>>>  >
>>>  >
>>>  >
>>>  > Here the data received from the pop3 server are "scanned" and
>>> weirdly,
>>>  > both fields num_new and num_total get the same value (num).
>>>  >
>>>  > Then I read the pop3 rfc (http://www.ietf.org/rfc/rfc1939.txt)
>>> and
>>>  > unfortunately it seems NOT to be possible to retrieve directly
>>> the
>>>  > number of new e-mails from the pop3 server. The sscanf (in, "+OK
>>> %i %i",
>>>  > &num, &total) actually gives the total number of e-mails to &num
>>> and the
>>>  > size of the mailbox to &total. So num_new gets the total
>>> number of
>>>  > e-mails and it's no surprise that the mail module displays this
>>> number
>>>  > instead of the number of new messages.
>>>  >
>>>  > So I am a bit confused. I am quite sure it used to work. Is there
>>> still
>>>  > a way to bring the mail module to display the number of new
>>> e-mails
>>>  > (using pop3) ? Or am I totally wrong and it is not intended to do
>>> so ??
>>>  >
>>>  > I hope I didn't bother you with a scilly question, but I couldn't
>>> find
>>>  > an answer to it anywhere else so far.
>>>  >
>>>  > I wish you a nice day,
>>>  >
>>>  >
>>>  >
>>>  > Nicolas Hainaux
>>>  >
>>> You are correct in your assumptions there. POP3 does not have a
>>> "total
>>> new" option.

Re: [E-devel] RFC eina inlist, list

2009-09-08 Thread Nathan Ingersoll 
On Tue, Sep 8, 2009 at 6:52 PM, Gustavo Sverzut
Barbieri wrote:
> Hello all, but specially Cedric and Jorge as one of you did initial
> eina_inlist and we're about to release eina as 1.0 so we need to know
> if things need/could be changed to improve things before that.
>
> Today eina_inlist does not keep an accounting member as its eina_list
> counterpart, instead it keeps a pointer to "last" that is just valid
> on the head member (as we'll not walk the list updating all ->last as
> we append stuff). That leaves us with a sizeof(pointer) lost in every
> member but the first.
>
> Two options with that:
>   - add accounting: suggested by raster, it does make sense as it
> would make eina_inlist_count() O(1) and behavior similar to eina_list,
> better use of that pointer.
>   - ultra-dirty hack to remove extra pointer. The hack bases on the
> fact that we just use ->last from the first node, that always have the
> ->prev == NULL. So we could have the first ->prev == ->last, but how
> to know it's the first then, you might ask? Easy! Just use the fact
> that valid addresses are multiple of sizeof(word) and you're done, no
> supported platform uses less than 4 bytes, so ->prev = ->last | 1;
> would work, and checks  for ->last & 1 would tell you if it's the case
> or not.
>
> The ultra dirty hack could be used to save the extra ->accounting from
> eina_list as well, and instead of adding last as said in the previous
> example, we could store accounting there. Dirty but useful, if people
> are using macros then we've almost no porting to do. As this uses
> ->prev (a not so used pointer in outer world) we don't have much work
> to do, just introduce EINA_LIST_FIRST_IS() and EINA_LIST_LAST_IS()
> (the last would still check for NULL, but just to make further changes
> easier).

We used this trick with callback pointers in EWL for quite a while. It
worked fine, but we eventually needed more than 2 bits for the flags.
During that time, I did receive quite a few complaints about it being
a little difficult to figure out what the macros were doing, but
people figured it out pretty quickly when they took the time to look
at it.

> What do you think? Should we change eina_inlist to have an accounting
> and still use 3 pointers per node? Should we move to the said trick?
> Also for eina_list? SAY IT SOON OR LIVE WITH THAT :-D

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] RFC eina inlist, list

2009-09-08 Thread Gustavo Sverzut Barbieri 
Hello all, but specially Cedric and Jorge as one of you did initial
eina_inlist and we're about to release eina as 1.0 so we need to know
if things need/could be changed to improve things before that.

Today eina_inlist does not keep an accounting member as its eina_list
counterpart, instead it keeps a pointer to "last" that is just valid
on the head member (as we'll not walk the list updating all ->last as
we append stuff). That leaves us with a sizeof(pointer) lost in every
member but the first.

Two options with that:
   - add accounting: suggested by raster, it does make sense as it
would make eina_inlist_count() O(1) and behavior similar to eina_list,
better use of that pointer.
   - ultra-dirty hack to remove extra pointer. The hack bases on the
fact that we just use ->last from the first node, that always have the
->prev == NULL. So we could have the first ->prev == ->last, but how
to know it's the first then, you might ask? Easy! Just use the fact
that valid addresses are multiple of sizeof(word) and you're done, no
supported platform uses less than 4 bytes, so ->prev = ->last | 1;
would work, and checks  for ->last & 1 would tell you if it's the case
or not.

The ultra dirty hack could be used to save the extra ->accounting from
eina_list as well, and instead of adding last as said in the previous
example, we could store accounting there. Dirty but useful, if people
are using macros then we've almost no porting to do. As this uses
->prev (a not so used pointer in outer world) we don't have much work
to do, just introduce EINA_LIST_FIRST_IS() and EINA_LIST_LAST_IS()
(the last would still check for NULL, but just to make further changes
easier).

What do you think? Should we change eina_inlist to have an accounting
and still use 3 pointers per node? Should we move to the said trick?
Also for eina_list? SAY IT SOON OR LIVE WITH THAT :-D

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [patch] esmart: Add autogen.sh to dist tarball

2009-09-08 Thread Simon Horman 
Is the following appropriate?

-

Subject: Add autogen.sh to dist tarball

autogen.sh is used by the debian packaging so it seems
appropriate to include it in the dist tarball

Index: esmart/Makefile.am
===
--- esmart.orig/Makefile.am 2009-09-09 09:12:57.0 +1000
+++ esmart/Makefile.am  2009-09-09 09:13:03.0 +1000
@@ -18,7 +18,7 @@ EXTRA_DIST = README AUTHORS COPYING esma
 esmart_text_entry.pc.in \
 esmart_thumb.pc.in \
 esmart_trans_x11.pc.in \
-esmart_xpixmap.pc.in
+esmart_xpixmap.pc.in autogen.sh
 
 pkgconfigdir = $(libdir)/pkgconfig
 

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] replace autogen.sh content by autoreconf

2009-09-08 Thread Vincent Torri 

Hey,

I think that it would be more correct if you use autoreconf in autogen.sh 
instead of all the commands. Indeed, especially with recent version of the 
autotools, it is sometimes necessary that some commands need to be run 
several times (it is the case for aclocal, for example).

And autoreconf takes care of all this.

So i'm wondering if we shouldn't use autoreconf (see Evil's configure.ac 
for example).

objections ? remarks ?

Vincent

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina segfaults after reinit

2009-09-08 Thread Peter Wehrfritz 
Andre Dieb wrote:
> I commited a fix, please try it.
>   

I can confirm that it works now :)

Peter

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel