date:20111111



On Fri, 11 Nov 2011, Carsten Haitzler (The Rasterman) wrote:

 On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri vto...@univ-evry.fr
 said:


 Hey

 I'm talking a lot with an openBSD dev, and currently it's very hard for
 them to follow the changes in the trunk. What they would like to have is
 snapshots to provide easily patches for the EFL.

 how is that hard? svn checkout or update instead of wget. u also need to run
 autogen.sh.

i don't really know. They just say it's very hard for us.

 Would it be possible to have, during the freeze period, some daily
 snashots ? It would be nice to fix the openBSD port for the release.

 open to patches, but none have been submitted.

As I said, I'm discussing with an openBSD guy which send me a github link 
with all their patches (in #e.fr).

 if they require tarballs to
 test and can't just run svn instead to fetch the source... i don't have the
 time each day to make tarballs when they can just as easily fetch from svn.
 it's the same work on their part. making tarballs is MORE work on our part.

 Note that i discuss also with a Mageia e17 maintainer, and he told me that
 such snapshots will help him too.

 a snapshot has no more quality than an svn checkout, so other than a mental
 block thinking svn == totally unstable/unusable and an unwillingness to use it
 because of a mental block, i don't see the point.

 a release that has had quality assurance done on it is a different matter - 
 but
 we arent doing them every day. hell no - not with al the efl trees we have.
 only chance of that is if we stopped having separate libs and just merged them
 into a single efl tree.

but in the case of a freeze, that would also allow common user to test 
the code, I think, without having svn installed on their computer.

Vincent

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

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

On 11/11/2011 03:09 AM, Bluezery wrote:
 Dear all,

 I have modified the way curl used in ecore_con_url.c


Don't need to use both of the free functions.

+   EINA_LIST_FREE(_url_con_list, con_url) 
ecore_con_url_free(con_url);
+   eina_list_free(_url_con_list);

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

Re: [E-devel] E17 tablet recommendation / Android



On Fri, 11 Nov 2011, Andreas Volz wrote:

 Hello,

 could anyone recommend a good tablet pc for E17?

maybe archos

 Does anyone know if it's possible to run edje based applications
 (not E17 itself!) on Android based tablets? As Android supports native
 applications and has an OpenGL interface it should be possible, not?

ask chidambar, he is working in the Archos company

Vincent

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

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

It's my mistake.

fixed patch is attached again.
I have removed active flag also.
I use eina_list_data_find() instead.

On Fri, Nov 11, 2011 at 4:54 PM, Sebastian Dransfeld s...@tango.flipp.net 
wrote:
 On 11/11/2011 03:09 AM, Bluezery wrote:
 Dear all,

 I have modified the way curl used in ecore_con_url.c


 Don't need to use both of the free functions.

 +           EINA_LIST_FREE(_url_con_list, con_url)
 ecore_con_url_free(con_url);
 +           eina_list_free(_url_con_list);

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

Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c	(리비전 65035)
+++ src/lib/ecore_con/ecore_con_url.c	(작업 사본)
@@ -35,8 +35,6 @@ int ECORE_CON_EVENT_URL_COMPLETE = 0;
 int ECORE_CON_EVENT_URL_PROGRESS = 0;
 
 #ifdef HAVE_CURL
-static Eina_Bool _ecore_con_url_fd_handler(void *data,
-   Ecore_Fd_Handler *fd_handler);
 static Eina_Bool _ecore_con_url_perform(Ecore_Con_Url *url_con);
 static size_t_ecore_con_url_header_cb(void  *ptr,
   size_t size,
@@ -57,12 +55,11 @@ static size_t _ecore_con_url_read_cb(voi
  void  *stream);
 static void  _ecore_con_event_url_free(void *data __UNUSED__,
void  *ev);
-static int   _ecore_con_url_process_completed_jobs(
-  Ecore_Con_Url *url_con_to_match);
 static Eina_Bool _ecore_con_url_idler_handler(void *data);
+static Eina_Bool _ecore_con_url_fd_handler(void *data __UNUSED__, Ecore_Fd_Handler *fd_handler __UNUSED__);
 
-static Ecore_Idler *_fd_idler_handler = NULL;
 static Eina_List *_url_con_list = NULL;
+static Eina_List *_fd_hd_list = NULL;
 static CURLM *_curlm = NULL;
 static fd_set _current_fd_set;
 static int _init_count = 0;
@@ -113,51 +110,30 @@ EAPI int
 ecore_con_url_init(void)
 {
 #ifdef HAVE_CURL
-   _init_count++;
+   if (++_init_count  1) return _init_count;
 
-   if (_init_count  1)
- return _init_count;
-
-   if (!ECORE_CON_EVENT_URL_DATA)
- {
-ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
-ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
-ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
- }
+   if (!ECORE_CON_EVENT_URL_DATA) ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
+   if (!ECORE_CON_EVENT_URL_COMPLETE) ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
+   if (!ECORE_CON_EVENT_URL_PROGRESS) ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
 
if (!_curlm)
  {
 long ms;
 
-FD_ZERO(_current_fd_set);
-if (curl_global_init(CURL_GLOBAL_ALL))
-  {
- while (_url_con_list)
-   ecore_con_url_free(eina_list_data_get(_url_con_list));
- return 0;
-  }
+// curl_global_init() is not thread safe!
+if (curl_global_init(CURL_GLOBAL_ALL)) return --_init_count;
 
 _curlm = curl_multi_init();
-if (!_curlm)
-  {
- while (_url_con_list)
-   ecore_con_url_free(eina_list_data_get(_url_con_list));
-
- _init_count--;
- return 0;
-  }
+if (!_curlm)  return --_init_count;
 
 curl_multi_timeout(_curlm, ms);
-if (ms = 0)
-  ms = 1000;
+if (ms = 0) ms = 100;
 
-_curl_timeout =
-  ecore_timer_add((double)ms / 1000, _ecore_con_url_idler_handler,
-  (void *)0xACE);
+_curl_timeout = ecore_timer_add((double)ms / 1000, _ecore_con_url_idler_handler, (void *)0xACE);
 ecore_timer_freeze(_curl_timeout);
  }
 
-   return 1;
+   return _init_count;
 #else
return 0;
 #endif
@@ -167,34 +143,38 @@ EAPI int
 ecore_con_url_shutdown(void)
 {
 #ifdef HAVE_CURL
-   if (!_init_count)
- return 0;
-
-   _init_count--;
-
-   if (_init_count != 0)
- return _init_count;
-
-   if (_fd_idler_handler)
- ecore_idler_del(_fd_idler_handler);
-
-   _fd_idler_handler = NULL;
+   if (_init_count == 0) return 0;
 
-   if (_curl_timeout)
- ecore_timer_del(_curl_timeout);
-
-   _curl_timeout = NULL;
-
-   while (_url_con_list)
- ecore_con_url_free(eina_list_data_get(_url_con_list));
-
-   if (_curlm)
+   if (--_init_count == 0)
  {
-curl_multi_cleanup(_curlm);
-_curlm = NULL;
- }
+if (_curl_timeout)
+  {
+ ecore_timer_del(_curl_timeout);
+ _curl_timeout = NULL;
+  }
+
+FD_ZERO(_current_fd_set);
+if (_url_con_list)
+{
+

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

On 11/11/2011 03:09 AM, Bluezery wrote:
 Dear all,

 I have modified the way curl used in ecore_con_url.c

 1) A file descriptor of libcurl is not matched to any easy handles.
 We can get a file descriptor from curl_multi_fdset(), we do not
 guarantee that it is a socket of easy handle just performed.
 If libcurl multi handle uses pipeline, the number of file descriptors
 is just 1 or 2 even though the number of easy handles is numerous.
 So, I removed the fd, fd_handler, flags from _Ecore_Con_Url structure.

 2) There are no routines when return value is CURLM_CALL_MULTI_PERFORM
 or still_running is above 1.
 When return value is CURLM_CALL_MULTI_PERFORM, we just do
 curl_multi_perform() again. (do not curl_multi_fdset() or
 curl_multi_info_read() )
 In addition, there are case that curl_multi_perform() returns CURLM_OK
 but we cannot get fd and read any information.  (e.g., libcurl
 threaded resolver enabled)
 In such a case, current _ecore_con_url_perform() returns
 EINA_FALSE~~!!!. This is a problem.
 So, I added routines for each case.


 3) Error control should be added.
 It is not controlled when curl_multi_perform() returns error.

 Please review a attached patch.

You should read waht EINA_LIST_FREE does, and clean up list free'ing. 
Else the patch seems good.

S.

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

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

On 11/11/2011 09:41 AM, Bluezery wrote:
 It's my mistake.

 fixed patch is attached again.
 I have removed active flag also.
 I use eina_list_data_find() instead.

+   EINA_LIST_FOREACH_SAFE(_url_con_list, l, ll, url_con)
+ {
+CURLMcode ret;
+Ecore_Con_Event_Url_Complete *e;

+e = calloc(1, sizeof(Ecore_Con_Event_Url_Complete));
+if (e)
+  {
+ e-url_con = url_con;
+ e-status = 0;
+ _url_complete_push_event(ECORE_CON_EVENT_URL_COMPLETE, e);
+  }
+ret = curl_multi_remove_handle(_curlm, url_con-curl_easy);
+if (ret != CURLM_OK) ERR(curl_multi_remove_handle failed: %s, 
curl_multi_strerror(ret));
+_url_con_list = eina_list_remove(_url_con_list, url_con);
   }
+ eina_list_free(_url_con_list);
+ _url_con_list = NULL;

Why do you use foreach safe, remove elements from list and then free 
list? This is EINA_LIST_FREE.

Also, EINA_LIST_FREE sets list to NULL, no need to set to NULL afterwards.

Also no need to check list != NULL before EINA_LIST_FREE

S.

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

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

On 11/11/2011 09:41 AM, Bluezery wrote:
 It's my mistake.

 fixed patch is attached again.
 I have removed active flag also.
 I use eina_list_data_find() instead.

Also, there is used a lot of idlers. I think all idlers can be removed 
now, as we only do one multi perform on each fd handler ready.

The reason the idlers were added, was that we did multi_perform in loop 
for 0.1s (or something like that) which clogged the system.

Cedric was the one adding the idlers, Cedric???

S.

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

Re: [E-devel] E SVN: raster trunk/eina



On Fri, 11 Nov 2011, Enlightenment SVN wrote:

 Log:
 eina NEWS file has summary from changelog. damn we did a lot.



 Author:   raster
 Date: 2011-11-11 01:07:20 -0800 (Fri, 11 Nov 2011)
 New Revision: 65057
 Trac: http://trac.enlightenment.org/e/changeset/65057

 Modified:
  trunk/eina/NEWS

 Modified: trunk/eina/NEWS
 ===
 --- trunk/eina/NEWS   2011-11-11 08:11:16 UTC (rev 65056)
 +++ trunk/eina/NEWS   2011-11-11 09:07:20 UTC (rev 65057)
 @@ -0,0 +1,29 @@
 +1.1 Release Features
 +
 +* Fixed compilation problems with some configure options
 +* Fixed stat issue if file size is in bytes and serial number overran 32bits
 +* Fixed uninstall of mempool modules
 +* Fixed static build of buddy mempool
 +* Fixed stringshare multi-init bug
 +* Fixed windows port of eina_sched_prio_drop
 +* Fixed eina_hash_set to handle data being NULL like eina_hash_del
 +* Fixed static linking to eina (iconv can be avoided)
 +* Fixed eina_share_common_del and eina_share_common_ref unlock bug
 +* Improved scalability/speed improvements in Chained Mempool
 +* Added eina_unicode_strndup API
 +* Added EINA_INLIST_FOREACH_SAFE API
 +* Added Eina unicode UTF8 convenience calls API
 +* Added eina_list_move functions to move list nodes from list to list 
 directly
 +* Added simple SAX XML parser API added
 +* Added inlist sort and sorted insert API
 +* Added mempool repack API
 +* Added eina_file API for portable file memory-mapping with IO saffety traps
 +* Added thread locks, conditions etc. wrapper API for portability
 +* Added prefix API for apps or libs to find their runtime prefix location
 +* Added refcount macro API
 +* Added binbuf for binary extendable buffers API
 +* Added eina_hash_free_cb_set API
 +* Added eina_main_loop_is API
 +* Added eina_strbuf_manage_new and eina_ustrbuf_manage_new APIs
 +* Added eina_xattr API's
 +* Changed to stringshare as storage eina error strings now

maybe we should split file content into at least 2 parts : big changes, 
and API additions, like I did in ecore:


Changes since Eina 1.0:
--

New Features:
  - blahbblah blah

Important changes:
  - blahbblah blah

API Additions:
  - blahbblah blah


Vincent

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

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

I have done two more things.
Please check attached patch.
I have tested using elm_map. I works well.

1) EINA_LIST_FOREACH_SAFE is removed and EINA_LIST_FREE is used instead.
2) I removed complete idler and use ecore_event_add() directly.

However, ecore_main_fd_handler_del() sometimes give warnnings because
file descriptors cannot be controlled by ecore_con and only curl
controls those internally.
I think it can be ignored

On Fri, Nov 11, 2011 at 5:55 PM, Sebastian Dransfeld s...@tango.flipp.net 
wrote:
 On 11/11/2011 09:41 AM, Bluezery wrote:
 It's my mistake.

 fixed patch is attached again.
 I have removed active flag also.
 I use eina_list_data_find() instead.

 Also, there is used a lot of idlers. I think all idlers can be removed
 now, as we only do one multi perform on each fd handler ready.

 The reason the idlers were added, was that we did multi_perform in loop
 for 0.1s (or something like that) which clogged the system.

 Cedric was the one adding the idlers, Cedric???

 S.

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

Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c	(리비전 65035)
+++ src/lib/ecore_con/ecore_con_url.c	(작업 사본)
@@ -35,8 +35,6 @@ int ECORE_CON_EVENT_URL_COMPLETE = 0;
 int ECORE_CON_EVENT_URL_PROGRESS = 0;
 
 #ifdef HAVE_CURL
-static Eina_Bool _ecore_con_url_fd_handler(void *data,
-   Ecore_Fd_Handler *fd_handler);
 static Eina_Bool _ecore_con_url_perform(Ecore_Con_Url *url_con);
 static size_t_ecore_con_url_header_cb(void  *ptr,
   size_t size,
@@ -57,50 +55,17 @@ static size_t _ecore_con_url_read_cb(voi
  void  *stream);
 static void  _ecore_con_event_url_free(void *data __UNUSED__,
void  *ev);
-static int   _ecore_con_url_process_completed_jobs(
-  Ecore_Con_Url *url_con_to_match);
 static Eina_Bool _ecore_con_url_idler_handler(void *data);
+static Eina_Bool _ecore_con_url_fd_handler(void *data __UNUSED__, Ecore_Fd_Handler *fd_handler __UNUSED__);
 
-static Ecore_Idler *_fd_idler_handler = NULL;
 static Eina_List *_url_con_list = NULL;
+static Eina_List *_fd_hd_list = NULL;
 static CURLM *_curlm = NULL;
 static fd_set _current_fd_set;
 static int _init_count = 0;
 static Ecore_Timer *_curl_timeout = NULL;
 static Eina_Bool pipelining = EINA_FALSE;
 
-typedef struct _Ecore_Con_Url_Event Ecore_Con_Url_Event;
-struct _Ecore_Con_Url_Event
-{
-   int   type;
-   void *ev;
-};
-
-static Eina_Bool
-_url_complete_idler_cb(void *data)
-{
-   Ecore_Con_Url_Event *lev;
-
-   lev = data;
-   ecore_event_add(lev-type, lev-ev, _ecore_con_event_url_free, NULL);
-   free(lev);
-
-   return ECORE_CALLBACK_CANCEL;
-}
-
-static void
-_url_complete_push_event(int   type,
- void *ev)
-{
-   Ecore_Con_Url_Event *lev;
-
-   lev = malloc(sizeof(Ecore_Con_Url_Event));
-   lev-type = type;
-   lev-ev = ev;
-
-   ecore_idler_add(_url_complete_idler_cb, lev);
-}
-
 #endif
 
 /**
@@ -113,51 +78,30 @@ EAPI int
 ecore_con_url_init(void)
 {
 #ifdef HAVE_CURL
-   _init_count++;
+   if (++_init_count  1) return _init_count;
 
-   if (_init_count  1)
- return _init_count;
-
-   if (!ECORE_CON_EVENT_URL_DATA)
- {
-ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
-ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
-ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
- }
+   if (!ECORE_CON_EVENT_URL_DATA) ECORE_CON_EVENT_URL_DATA = ecore_event_type_new();
+   if (!ECORE_CON_EVENT_URL_COMPLETE) ECORE_CON_EVENT_URL_COMPLETE = ecore_event_type_new();
+   if (!ECORE_CON_EVENT_URL_PROGRESS) ECORE_CON_EVENT_URL_PROGRESS = ecore_event_type_new();
 
if (!_curlm)
  {
 long ms;
 
-FD_ZERO(_current_fd_set);
-if (curl_global_init(CURL_GLOBAL_ALL))
-  {
- while (_url_con_list)
-   ecore_con_url_free(eina_list_data_get(_url_con_list));
- return 0;
-  }
+// curl_global_init() is not thread safe!
+if (curl_global_init(CURL_GLOBAL_ALL)) return --_init_count;
 
 _curlm = curl_multi_init();
-if (!_curlm)
-  {
- while (_url_con_list)
-   ecore_con_url_free(eina_list_data_get(_url_con_list));
-
- _init_count--;
- return 0;
-  }
+if (!_curlm)  return --_init_count;
 
 curl_multi_timeout(_curlm, ms);
-if (ms = 0)
-  ms = 1000;
+if (ms = 0) ms = 100;
 
-

Re: [E-devel] E SVN: raster trunk/eina

On Fri, 11 Nov 2011 10:17:45 +0100 (CET) Vincent Torri vto...@univ-evry.fr
said:

 
 
 On Fri, 11 Nov 2011, Enlightenment SVN wrote:
 
  Log:
  eina NEWS file has summary from changelog. damn we did a lot.
 
 
 
  Author:   raster
  Date: 2011-11-11 01:07:20 -0800 (Fri, 11 Nov 2011)
  New Revision: 65057
  Trac: http://trac.enlightenment.org/e/changeset/65057
 
  Modified:
   trunk/eina/NEWS
 
  Modified: trunk/eina/NEWS
  ===
  --- trunk/eina/NEWS 2011-11-11 08:11:16 UTC (rev 65056)
  +++ trunk/eina/NEWS 2011-11-11 09:07:20 UTC (rev 65057)
  @@ -0,0 +1,29 @@
  +1.1 Release Features
  +
  +* Fixed compilation problems with some configure options
  +* Fixed stat issue if file size is in bytes and serial number overran
  32bits +* Fixed uninstall of mempool modules
  +* Fixed static build of buddy mempool
  +* Fixed stringshare multi-init bug
  +* Fixed windows port of eina_sched_prio_drop
  +* Fixed eina_hash_set to handle data being NULL like eina_hash_del
  +* Fixed static linking to eina (iconv can be avoided)
  +* Fixed eina_share_common_del and eina_share_common_ref unlock bug
  +* Improved scalability/speed improvements in Chained Mempool
  +* Added eina_unicode_strndup API
  +* Added EINA_INLIST_FOREACH_SAFE API
  +* Added Eina unicode UTF8 convenience calls API
  +* Added eina_list_move functions to move list nodes from list to list
  directly +* Added simple SAX XML parser API added
  +* Added inlist sort and sorted insert API
  +* Added mempool repack API
  +* Added eina_file API for portable file memory-mapping with IO saffety
  traps +* Added thread locks, conditions etc. wrapper API for portability
  +* Added prefix API for apps or libs to find their runtime prefix location
  +* Added refcount macro API
  +* Added binbuf for binary extendable buffers API
  +* Added eina_hash_free_cb_set API
  +* Added eina_main_loop_is API
  +* Added eina_strbuf_manage_new and eina_ustrbuf_manage_new APIs
  +* Added eina_xattr API's
  +* Changed to stringshare as storage eina error strings now
 
 maybe we should split file content into at least 2 parts : big changes, 
 and API additions, like I did in ecore:

i'm open for debate there - i ordered them actually with fixes first,
improvements then additions assuming fixes are more important, changes are
important and additions are nice extras you didn't have before so are less
important. additions and api additions are the same really - no?


 
 Changes since Eina 1.0:
 --
 
 New Features:
   - blahbblah blah
 
 Important changes:
   - blahbblah blah
 
 API Additions:
   - blahbblah blah
 
 
 Vincent
 
 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] Ecore_processing mtdev events

On Fri, 11 Nov 2011 13:18:20 +0530 HariHara Sudhan h...@emo2.com said:

 OK thank you, I think i have a lead. I will work on a solution.

let me know what's happening - i find it odd that evas would just skip events
unless it was specifically meant to - eg event happened outside that obj, grabs
were in effect or there were no callbacks set.

 On Fri, Nov 11, 2011 at 12:25 PM, Carsten Haitzler ras...@rasterman.com
 wrote:
  On Fri, 4 Nov 2011 20:11:12 +0530 HariHara Sudhan h...@emo2.com said:
 
  timestamp doesn't matter. it calls the callbacks on the objects the events
  are going to go to. if the mouse is grabbed (first press grabs mouse to the
  objects pressed) then callbacks are reported relative to grabbed objects
  until last finger is released. if (obj-callbacks) checks to see if object
  has any cb's at all. if it doesn't - don't other doing anything. the target
  object(s) don't have callbacks set at all. if inside your callbacks you are
  deleting objects or changing their callbacks.. you may get this. if objects
  are hidden, clipped out or otherwise not visible - they wont be called
  either. evas is checking for geometry and visibility here for the events.
 
  As you Said ecore process all the events, and passes on to evas.
  In evas at two points events are filtered.
 
  1. evas_event_feed_multi_move()
  2.evas_object_event_callback_call()
 
  in evas_object_event_calback_call the if(obj-callbacks) fail for
  events two consecutive events at same time.
  only one of them returns value the other one returns NULL.
 
  in evas_event_feed_multi_move(), the if condition to check for
  checking objects in position,visibility and etc fails for several
  events.
 
  i'm not able to find why the condition fails in both these points.
  Is the reason due to pouring events for the same timestamp?
  any possible solutions?
 
 
  thanks in advance
 
  Regards
  HariHaraSudhan
 
  On Fri, Nov 4, 2011 at 4:58 AM, Carsten Haitzler ras...@rasterman.com
  wrote:
   On Thu, 3 Nov 2011 19:36:11 +0530 HariHara Sudhan h...@emo2.com said:
  
   Mouse gives events on a minimum of 8ms gap, but i get 2-3 touch events
   within a ms.
   So that is a lot of events.
   But some events generated on ecore side, which are pushed into event
   queue using _ecore_mouse_move are not reflected as evas_callbacks.
   Some times it generates 3-4 events on ecore side but i get only one
   callback on evas side.
   here is the sample
  
  
   evas id=2 x=578 y=66
   eCore id=2 x=577 y=66
  
   evas id=2 x=577 y=66
   eCore id=2 x=577 y=65
   eCore id=2 x=578 y=65
  
   evas id=2 x=577 y=65
  
   evas id=2 x=578 y=65
   eCore id=1 x=153 y=50
   eCore id=1 x=153 y=51
  
   evas id=1 x=153 y=51
   eCore id=2 x=578 y=64
   eCore id=1 x=153 y=52
   eCore id=2 x=578 y=65
   eCore id=1 x=153 y=53
   eCore id=2 x=579 y=65
   eCore id=1 x=153 y=54
   eCore id=2 x=579 y=66
   eCore id=2 x=579 y=67
  
   evas id=2 x=579 y=67
   eCore id=1 x=153 y=55
   eCore id=2 x=580 y=67
   eCore id=1 x=153 y=56
   eCore id=1 x=153 y=57
   eCore id=1 x=152 y=57
   eCore id=2 x=580 y=68
   eCore id=2 x=581 y=68
  
  
   this is where my problem is,a lot of ecore events are generated but on
   eas side i get only few.
  
   I couldn't find why some events are not reflected in evas_callbacks.
  
   is there a way to process the touch events as a seperate thread in
   ecore_event_procesing? or any other solution for this problem?
  
   threads have nothing to do with this other than complicating things. they
   don't solve anything, and won't. (unless u are spending large amounts of
   cpu just handling the input event stream and making ecore events out of
   it).  so you get ecore events - fine, but evas isnt calling back for all
   events... that shouldn't happen (unless position hasn't changed etc.)
  
   Regards
   HariHaraSudhan
  
   On Thu, Nov 3, 2011 at 6:34 PM, HariHara Sudhan h...@emo2.com wrote:
Sent from my Windows Phone
From: Carsten Haitzler
Sent: 11/3/2011 4:20 PM
To: Enlightenment developer list
Cc: HariHara Sudhan
Subject: Re: [E-devel] Ecore_processing mtdev events
On Wed, 2 Nov 2011 19:38:09 +0530 HariHara Sudhan h...@emo2.com
said:
   
Hi all,
I've lately added mtdev to receive touch events and process them as
ecore mouse events( as mpx).
i get the window id by the original mouse movements and use that id
for passing touch events for that window.
   
i get the slot id from mtdev. Passing the slot id(starting from 1)
makes ecore think it as mpx style events and the callbacks for single
finger touch are also working fine. But when using two or more
fingers lots of events are generated. When getting data from
callback of EVAS_CALLBACK_MULTI_MOVE, lot of touch move events
aren't properly received for both the touch points.
   
I'm not sure why some events are discarded when using two or more
fingers,but i think it might be discarded due to ecore queue

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

But do you need the other idler? _ecore_con_url_idler_handler ?

Couldn't the fd wakeup just perform curl handling directly?

S.

On 11/11/2011 11:12 AM, Bluezery wrote:
 I have done two more things.
 Please check attached patch.
 I have tested using elm_map. I works well.

 1) EINA_LIST_FOREACH_SAFE is removed and EINA_LIST_FREE is used instead.
 2) I removed complete idler and use ecore_event_add() directly.

 However, ecore_main_fd_handler_del() sometimes give warnnings because
 file descriptors cannot be controlled by ecore_con and only curl
 controls those internally.
 I think it can be ignored

 On Fri, Nov 11, 2011 at 5:55 PM, Sebastian Dransfelds...@tango.flipp.net  
 wrote:
 On 11/11/2011 09:41 AM, Bluezery wrote:
 It's my mistake.

 fixed patch is attached again.
 I have removed active flag also.
 I use eina_list_data_find() instead.

 Also, there is used a lot of idlers. I think all idlers can be removed
 now, as we only do one multi perform on each fd handler ready.

 The reason the idlers were added, was that we did multi_perform in loop
 for 0.1s (or something like that) which clogged the system.

 Cedric was the one adding the idlers, Cedric???

 S.

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



 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1


 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


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

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

_ecore_con_url_idler_handler() is remained because fd is not set when
the return value is CURLM_CALL_MULTI_PERFORM.

On Fri, Nov 11, 2011 at 7:52 PM, Sebastian Dransfeld s...@tango.flipp.net 
wrote:
 But do you need the other idler? _ecore_con_url_idler_handler ?

 Couldn't the fd wakeup just perform curl handling directly?

 S.

 On 11/11/2011 11:12 AM, Bluezery wrote:
 I have done two more things.
 Please check attached patch.
 I have tested using elm_map. I works well.

 1) EINA_LIST_FOREACH_SAFE is removed and EINA_LIST_FREE is used instead.
 2) I removed complete idler and use ecore_event_add() directly.

 However, ecore_main_fd_handler_del() sometimes give warnnings because
 file descriptors cannot be controlled by ecore_con and only curl
 controls those internally.
 I think it can be ignored

 On Fri, Nov 11, 2011 at 5:55 PM, Sebastian Dransfelds...@tango.flipp.net  
 wrote:
 On 11/11/2011 09:41 AM, Bluezery wrote:
 It's my mistake.

 fixed patch is attached again.
 I have removed active flag also.
 I use eina_list_data_find() instead.

 Also, there is used a lot of idlers. I think all idlers can be removed
 now, as we only do one multi perform on each fd handler ready.

 The reason the idlers were added, was that we did multi_perform in loop
 for 0.1s (or something like that) which clogged the system.

 Cedric was the one adding the idlers, Cedric???

 S.

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



 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1


 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


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


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

Re: [E-devel] E SVN: raster trunk/eina




On Fri, 11 Nov 2011, Carsten Haitzler (The Rasterman) wrote:


On Fri, 11 Nov 2011 10:17:45 +0100 (CET) Vincent Torri vto...@univ-evry.fr
said:




On Fri, 11 Nov 2011, Enlightenment SVN wrote:


Log:
eina NEWS file has summary from changelog. damn we did a lot.



Author:   raster
Date: 2011-11-11 01:07:20 -0800 (Fri, 11 Nov 2011)
New Revision: 65057
Trac: http://trac.enlightenment.org/e/changeset/65057

Modified:
 trunk/eina/NEWS

Modified: trunk/eina/NEWS
===
--- trunk/eina/NEWS 2011-11-11 08:11:16 UTC (rev 65056)
+++ trunk/eina/NEWS 2011-11-11 09:07:20 UTC (rev 65057)
@@ -0,0 +1,29 @@
+1.1 Release Features
+
+* Fixed compilation problems with some configure options
+* Fixed stat issue if file size is in bytes and serial number overran
32bits +* Fixed uninstall of mempool modules
+* Fixed static build of buddy mempool
+* Fixed stringshare multi-init bug
+* Fixed windows port of eina_sched_prio_drop
+* Fixed eina_hash_set to handle data being NULL like eina_hash_del
+* Fixed static linking to eina (iconv can be avoided)
+* Fixed eina_share_common_del and eina_share_common_ref unlock bug
+* Improved scalability/speed improvements in Chained Mempool
+* Added eina_unicode_strndup API
+* Added EINA_INLIST_FOREACH_SAFE API
+* Added Eina unicode UTF8 convenience calls API
+* Added eina_list_move functions to move list nodes from list to list
directly +* Added simple SAX XML parser API added
+* Added inlist sort and sorted insert API
+* Added mempool repack API
+* Added eina_file API for portable file memory-mapping with IO saffety
traps +* Added thread locks, conditions etc. wrapper API for portability
+* Added prefix API for apps or libs to find their runtime prefix location
+* Added refcount macro API
+* Added binbuf for binary extendable buffers API
+* Added eina_hash_free_cb_set API
+* Added eina_main_loop_is API
+* Added eina_strbuf_manage_new and eina_ustrbuf_manage_new APIs
+* Added eina_xattr API's
+* Changed to stringshare as storage eina error strings now


maybe we should split file content into at least 2 parts : big changes,
and API additions, like I did in ecore:


i'm open for debate there - i ordered them actually with fixes first,
improvements then additions assuming fixes are more important, changes are
important and additions are nice extras you didn't have before so are less
important. additions and api additions are the same really - no?


I've attached an example of NEWS file based on what I did in ecore.

of course, you can change it a bit, fill it, etc...

Note that there is a missing entry : a new hash stuff by billiob, iirc 
(this week)


Vincent
Index: NEWS
===
--- NEWS	(revision 65059)
+++ NEWS	(working copy)
@@ -1,29 +1,45 @@
-1.1 Release Features
+Eina 1.1
 
-* Fixed compilation problems with some configure options
-* Fixed stat issue if file size is in bytes and serial number overran 32bits
-* Fixed uninstall of mempool modules
-* Fixed static build of buddy mempool
-* Fixed stringshare multi-init bug
-* Fixed windows port of eina_sched_prio_drop
-* Fixed eina_hash_set to handle data being NULL like eina_hash_del
-* Fixed static linking to eina (iconv can be avoided)
-* Fixed eina_share_common_del and eina_share_common_ref unlock bug
-* Improved scalability/speed improvements in Chained Mempool
-* Added eina_unicode_strndup API
-* Added EINA_INLIST_FOREACH_SAFE API
-* Added Eina unicode UTF8 convenience calls API
-* Added eina_list_move functions to move list nodes from list to list directly
-* Added simple SAX XML parser API added
-* Added inlist sort and sorted insert API
-* Added mempool repack API
-* Added eina_file API for portable file memory-mapping with IO saffety traps
-* Added thread locks, conditions etc. wrapper API for portability
-* Added prefix API for apps or libs to find their runtime prefix location
-* Added refcount macro API
-* Added binbuf for binary extendable buffers API
-* Added eina_hash_free_cb_set API
-* Added eina_main_loop_is API
-* Added eina_strbuf_manage_new and eina_ustrbuf_manage_new APIs
-* Added eina_xattr API's
-* Changed to stringshare as storage eina error strings now
+Changes since Eina 1.0
+--
+
+New Features:
+
+ -
+
+API Additions:
+
+* core
+ - eina_unicode_strndup()
+ - EINA_INLIST_FOREACH_SAFE
+ - Eina unicode to UTF8 convenience calls
+ - eina_list_move functions to move list nodes from list to list directly
+ - simple SAX XML parser
+ - inlist sort and sorted insert
+ - eina_file calls for portable file memory-mapping with IO safety traps
+ - thread locks, conditions etc. wrapper API for portability
+ - prefix calls for apps or libs to find their runtime prefix location
+ - refcount macros
+ - binbuf for binary extendable buffers
+ - eina_hash_free_cb_set()
+ - eina_main_loop_is()
+ -

Re: [E-devel] E SVN: raster trunk/eina



On Fri, 11 Nov 2011, Carsten Haitzler (The Rasterman) wrote:

 On Fri, 11 Nov 2011 10:17:45 +0100 (CET) Vincent Torri vto...@univ-evry.fr
 said:



 On Fri, 11 Nov 2011, Enlightenment SVN wrote:

 Log:
 eina NEWS file has summary from changelog. damn we did a lot.



 Author:   raster
 Date: 2011-11-11 01:07:20 -0800 (Fri, 11 Nov 2011)
 New Revision: 65057
 Trac: http://trac.enlightenment.org/e/changeset/65057

 Modified:
  trunk/eina/NEWS

 Modified: trunk/eina/NEWS
 ===
 --- trunk/eina/NEWS 2011-11-11 08:11:16 UTC (rev 65056)
 +++ trunk/eina/NEWS 2011-11-11 09:07:20 UTC (rev 65057)
 @@ -0,0 +1,29 @@
 +1.1 Release Features
 +
 +* Fixed compilation problems with some configure options
 +* Fixed stat issue if file size is in bytes and serial number overran
 32bits +* Fixed uninstall of mempool modules
 +* Fixed static build of buddy mempool
 +* Fixed stringshare multi-init bug
 +* Fixed windows port of eina_sched_prio_drop
 +* Fixed eina_hash_set to handle data being NULL like eina_hash_del
 +* Fixed static linking to eina (iconv can be avoided)
 +* Fixed eina_share_common_del and eina_share_common_ref unlock bug
 +* Improved scalability/speed improvements in Chained Mempool
 +* Added eina_unicode_strndup API
 +* Added EINA_INLIST_FOREACH_SAFE API
 +* Added Eina unicode UTF8 convenience calls API
 +* Added eina_list_move functions to move list nodes from list to list
 directly +* Added simple SAX XML parser API added
 +* Added inlist sort and sorted insert API
 +* Added mempool repack API
 +* Added eina_file API for portable file memory-mapping with IO saffety
 traps +* Added thread locks, conditions etc. wrapper API for portability
 +* Added prefix API for apps or libs to find their runtime prefix location
 +* Added refcount macro API
 +* Added binbuf for binary extendable buffers API
 +* Added eina_hash_free_cb_set API
 +* Added eina_main_loop_is API
 +* Added eina_strbuf_manage_new and eina_ustrbuf_manage_new APIs
 +* Added eina_xattr API's
 +* Changed to stringshare as storage eina error strings now

 maybe we should split file content into at least 2 parts : big changes,
 and API additions, like I did in ecore:

 i'm open for debate there - i ordered them actually with fixes first,
 improvements then additions assuming fixes are more important, changes are
 important and additions are nice extras you didn't have before so are less
 important. additions and api additions are the same really - no?

what would be just additions ? configure options ? Well, I think that this 
kind of additions should in another part, like

miscellaneous additions

but people are more interested by API additions, so imho it's better to 
split and have 2 parts : API additions and others additions

Vincent

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

Re: [E-devel] About release, snapshots and openBSD port

2011-11-11 Thread Jonathan Armani

Hi,

On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com wrote:
 On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri vto...@univ-evry.fr
 said:


 Hey

 I'm talking a lot with an openBSD dev, and currently it's very hard for
 them to follow the changes in the trunk. What they would like to have is
 snapshots to provide easily patches for the EFL.

 how is that hard? svn checkout or update instead of wget. u also need to run
 autogen.sh.

 Would it be possible to have, during the freeze period, some daily
 snashots ? It would be nice to fix the openBSD port for the release.

 open to patches, but none have been submitted.

Are you kidding ? I though you were reading the svn log. I take a lot
of my time pushing / polishing these diff (special thanks to vtorrin,
bluebugs and billiob).
So you come from nowhere and make all this work looking bad, here and
on irc, that's amazing.

if they require tarballs to
 test and can't just run svn instead to fetch the source... i don't have the
 time each day to make tarballs when they can just as easily fetch from svn.
 it's the same work on their part. making tarballs is MORE work on our part.

You missed the point, we want to be sure that the final archive will be ok.
I'm not asking for snapshot on a daily basis, only some rc before the
final archive.
(Wait no project did alpha  rc, right ?)



 Note that i discuss also with a Mageia e17 maintainer, and he told me that
 such snapshots will help him too.

 a snapshot has no more quality than an svn checkout, so other than a mental
 block thinking svn == totally unstable/unusable and an unwillingness to use it
 because of a mental block, i don't see the point.

yeah a mental block, I think you don't want to know how many time I
have to reroll a dist to get all working and how frustating it is.


 a release that has had quality assurance done on it is a different matter - 
 but
 we arent doing them every day. hell no - not with al the efl trees we have.
 only chance of that is if we stopped having separate libs and just merged them
 into a single efl tree.

 Vincent

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



 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)    ras...@rasterman.com


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


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

Re: [E-devel] About release, snapshots and openBSD port

2011-11-11 Thread Bruno Dilly

On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net wrote:
 Hi,

 On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com 
 wrote:
 On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri vto...@univ-evry.fr
 said:


 Hey

 I'm talking a lot with an openBSD dev, and currently it's very hard for
 them to follow the changes in the trunk. What they would like to have is
 snapshots to provide easily patches for the EFL.

 how is that hard? svn checkout or update instead of wget. u also need to run
 autogen.sh.

 Would it be possible to have, during the freeze period, some daily
 snashots ? It would be nice to fix the openBSD port for the release.

 open to patches, but none have been submitted.

 Are you kidding ? I though you were reading the svn log. I take a lot
 of my time pushing / polishing these diff (special thanks to vtorrin,
 bluebugs and billiob).
 So you come from nowhere and make all this work looking bad, here and
 on irc, that's amazing.

Sometimes he acts this way. Don't take it personal, don't let it demotivate you.
Keep the good work ! =)


 if they require tarballs to
 test and can't just run svn instead to fetch the source... i don't have the
 time each day to make tarballs when they can just as easily fetch from svn.
 it's the same work on their part. making tarballs is MORE work on our part.

 You missed the point, we want to be sure that the final archive will be ok.
 I'm not asking for snapshot on a daily basis, only some rc before the
 final archive.
 (Wait no project did alpha  rc, right ?)



 Note that i discuss also with a Mageia e17 maintainer, and he told me that
 such snapshots will help him too.

 a snapshot has no more quality than an svn checkout, so other than a mental
 block thinking svn == totally unstable/unusable and an unwillingness to use 
 it
 because of a mental block, i don't see the point.

 yeah a mental block, I think you don't want to know how many time I
 have to reroll a dist to get all working and how frustating it is.


 a release that has had quality assurance done on it is a different matter - 
 but
 we arent doing them every day. hell no - not with al the efl trees we have.
 only chance of that is if we stopped having separate libs and just merged 
 them
 into a single efl tree.

 Vincent

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



 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)    ras...@rasterman.com


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


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




-- 
Bruno Dilly
Senior Developer
ProFUSION embedded systems
http://profusion.mobi

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

Re: [E-devel] About release, snapshots and openBSD port

2011-11-11 Thread Thanatermesis

2011/11/11 Bruno Dilly bdi...@profusion.mobi

 On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net
 wrote:
  Hi,
 
  On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com
 wrote:
  On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri 
 vto...@univ-evry.fr
  said:
 
 
  Hey
 
  I'm talking a lot with an openBSD dev, and currently it's very hard for
  them to follow the changes in the trunk. What they would like to have
 is
  snapshots to provide easily patches for the EFL.
 
  how is that hard? svn checkout or update instead of wget. u also need
 to run
  autogen.sh.
 
  Would it be possible to have, during the freeze period, some daily
  snashots ? It would be nice to fix the openBSD port for the release.
 
  open to patches, but none have been submitted.
 
  Are you kidding ? I though you were reading the svn log. I take a lot
  of my time pushing / polishing these diff (special thanks to vtorrin,
  bluebugs and billiob).
  So you come from nowhere and make all this work looking bad, here and
  on irc, that's amazing.

 Sometimes he acts this way. Don't take it personal, don't let it
 demotivate you.
 Keep the good work ! =)


Procedure:
http://www.spankingpaddles.co.uk/wp-content/uploads/2010/08/paddle-spank.gif



 
  if they require tarballs to
  test and can't just run svn instead to fetch the source... i don't have
 the
  time each day to make tarballs when they can just as easily fetch from
 svn.
  it's the same work on their part. making tarballs is MORE work on our
 part.
 
  You missed the point, we want to be sure that the final archive will be
 ok.
  I'm not asking for snapshot on a daily basis, only some rc before the
  final archive.
  (Wait no project did alpha  rc, right ?)
 
 
 
  Note that i discuss also with a Mageia e17 maintainer, and he told me
 that
  such snapshots will help him too.
 
  a snapshot has no more quality than an svn checkout, so other than a
 mental
  block thinking svn == totally unstable/unusable and an unwillingness to
 use it
  because of a mental block, i don't see the point.
 
  yeah a mental block, I think you don't want to know how many time I
  have to reroll a dist to get all working and how frustating it is.
 
 
  a release that has had quality assurance done on it is a different
 matter - but
  we arent doing them every day. hell no - not with al the efl trees we
 have.
  only chance of that is if we stopped having separate libs and just
 merged them
  into a single efl tree.
 
  Vincent
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 



 --
 Bruno Dilly
 Senior Developer
 ProFUSION embedded systems
 http://profusion.mobi


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

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

Re: [E-devel] [Patch][elm_map] Bug fix: use safe iterator instead

2011-11-11 Thread ChunEon Park

 
fine. in svn - 65069
 
Thank you so much. 
 

-Regards, Hermet-
 
-Original Message-
From: Bluezerylt;ohpo...@gmail.comgt; 
To: Enlightenment developer 
listlt;enlightenment-devel@lists.sourceforge.netgt;
Cc: 
Sent: 11-11-11(금) 13:32:04
Subject: [E-devel] [Patch][elm_map] Bug fix: use safe iterator instead
Hi,
There are bugs that map removes list elements when using
EINA_LIST_FOREACH or EINA_LIST_REVERSE_FOREACH.
We should use EINA_LIST_FOREACH_SAFE or EINA_LIST_REVERSE_FOREACH_SAFE
instead for above case.
Please review belows
Index: src/lib/elm_map.c
===
--- src/lib/elm_map.c (리비전 65041)
+++ src/lib/elm_map.c (작업 사본)
@@ -1240,7 +1240,7 @@ _process_download_list(Evas_Object *obj)
{
ELM_CHECK_WIDTYPE(obj, widtype);
Widget_Data *wd = elm_widget_data_get(obj);
- Eina_List *l;
+ Eina_List *l, *ll;
Evas_Coord ox, oy, ow, oh, cvx, cvy, cvw, cvh, tx, ty, gw, gh, xx,
yy, ww, hh;
Grid_Item *gi;
@@ -1250,7 +1250,7 @@ _process_download_list(Evas_Object *obj)
gw = wd-size.w;
gh = wd-size.h;
- EINA_LIST_FOREACH(wd-download_list, l, gi)
+ EINA_LIST_FOREACH_SAFE(wd-download_list, l, ll, gi)
{
xx = gi-out.x;
yy = gi-out.y;
@@ -1279,7 +1279,7 @@ _process_download_list(Evas_Object *obj)
}
}
- EINA_LIST_REVERSE_FOREACH(wd-download_list, l, gi)
+ EINA_LIST_REVERSE_FOREACH_SAFE(wd-download_list, l, ll, gi)
{
if (gi-wd-download_num = MAX_CONCURRENT_DOWNLOAD)
break;
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

On Fri, Nov 11, 2011 at 8:49 AM, Bruno Dilly bdi...@profusion.mobi wrote:

 On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net
 wrote:
  Hi,
 
  On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com
 wrote:
  On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri 
 vto...@univ-evry.fr
  said:
 
 
  Hey
 
  I'm talking a lot with an openBSD dev, and currently it's very hard for
  them to follow the changes in the trunk. What they would like to have
 is
  snapshots to provide easily patches for the EFL.
 
  how is that hard? svn checkout or update instead of wget. u also need
 to run
  autogen.sh.
 
  Would it be possible to have, during the freeze period, some daily
  snashots ? It would be nice to fix the openBSD port for the release.
 
  open to patches, but none have been submitted.
 
  Are you kidding ? I though you were reading the svn log. I take a lot
  of my time pushing / polishing these diff (special thanks to vtorrin,
  bluebugs and billiob).
  So you come from nowhere and make all this work looking bad, here and
  on irc, that's amazing.

 Sometimes he acts this way. Don't take it personal, don't let it
 demotivate you.
 Keep the good work ! =)

Reminds me of some of the stuff I've been saying...
As for don't have time to do tarballs everyday.. well, that's why there's
something called scripts and cron jobs.. those things exist, might be
good to use these awesome technologies.


 
  if they require tarballs to
  test and can't just run svn instead to fetch the source... i don't have
 the
  time each day to make tarballs when they can just as easily fetch from
 svn.
  it's the same work on their part. making tarballs is MORE work on our
 part.
 
  You missed the point, we want to be sure that the final archive will be
 ok.
  I'm not asking for snapshot on a daily basis, only some rc before the
  final archive.
  (Wait no project did alpha  rc, right ?)
 
 
 
  Note that i discuss also with a Mageia e17 maintainer, and he told me
 that
  such snapshots will help him too.
 
  a snapshot has no more quality than an svn checkout, so other than a
 mental
  block thinking svn == totally unstable/unusable and an unwillingness to
 use it
  because of a mental block, i don't see the point.
 
  yeah a mental block, I think you don't want to know how many time I
  have to reroll a dist to get all working and how frustating it is.
 
 
  a release that has had quality assurance done on it is a different
 matter - but
  we arent doing them every day. hell no - not with al the efl trees we
 have.
  only chance of that is if we stopped having separate libs and just
 merged them
  into a single efl tree.
 
  Vincent
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 



 --
 Bruno Dilly
 Senior Developer
 ProFUSION embedded systems
 http://profusion.mobi


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

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

Re: [E-devel] sound api plan

Carsten, a few people have noted their disappointment (and anger) at this
being merged and some requested it to be reverted, you didn't even take the
time to answer them and address their concerns.. Could you please take the
time to do that, since you obviously had time to respond to David with such
a long email, it looks bad for you to respond to only what you want and
ignore everyone else.

On Fri, Nov 11, 2011 at 1:33 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Thu, 10 Nov 2011 18:50:45 +1000 David Seikel onef...@gmail.com said:

  On Tue, 8 Nov 2011 16:33:42 +0900 Carsten Haitzler (The Rasterman)
  ras...@rasterman.com wrote:
 
   On Tue, 8 Nov 2011 07:23:27 +0100 (CET) Vincent Torri
   vto...@univ-evry.fr said:
  
   
   
On Mon, 7 Nov 2011, Carsten Haitzler (The Rasterman) wrote:
   
 attached. this was a sample edc that would be able to play audio,
 not just single samples but whole sequences across multiple
 tracks as well as control specific channels and tracks. it didn't
 specify looping params yet or other additional stuff.
   
i've never heard about that sound plan before the commit. The patch
was not public and we could not have discussed about it before the
commit. So I really don't like the way it came into edje.
  
   i'm not sure this is much different from anything else that goes on
   in efl. i have done work for a decade+ without discussing patches on
   the mailing list first. so have most developers. as such this patch
   this time was going through me. the comments on the patch so far
   havent actually commented on the edc api it adds at all which
   everyone is up in arms about for release. so since everyone
   complaining isn't actually talking about that... i'll write it here
   in short form. it adds: sounds {
 sample {
name: NAME ENCODING;
source: SAMPLE_FILE;
 }
 ...
 tone: NAME FREQ;
 ...
  }
   and 2 more actions:
  PLAY_SAMPLE NAME SPEED;
  PLAY_TONE NAME DURATION;
  
   that's it. unfortunately to make this WORK u need a chunk of infra
   like being able to load and encode samples into edj files, decode
   them, play and mix them, resample them, etc. all of which is opaque
   to the api.
 
  /me picks a spot in this thread to actually discuss the API.  Here
  seems the best.

 hooray! :)

  A quick look over it, and the example, and the plan, and it seems
  mostly sane. One thing that stands out straight away in the examples is
  the way that a bit of music was defined.
 
  First thing is that you are using something that looks like a typical
  tracker, which is fine in itself.  Lots of people are familiar with
  that.  It's a bit verbose though.

 well my hope actually was that later we can provide a mod/xm/s3m converter
 that
 can load one of these files and produce a bunch of edc to include. the only
 reason i didn't go right to use libmikmod and just inline mods in your
 edj was
 that these mod formats don't support ogg/mp3 etc. style sample compression
 and i
 really want that for space efficiency reasons. i actually wasn't expecting
 peolpe to write music in edc. it's POSSIBLE and to be honest - when i did
 tracking you literallly did almost what the edc says in text. u arrow down
 7,
 hit a key to play the sample at that speed (c-3/b-3/f#-2 etc.). you'd
 literally just have the sound  played at that time as the added bonus.. :)

  I think it would be great to also provide an alternative that is more
  like MIDI, as that is also used by a lot of people.  Have both, that
  would cover most things.  Actually, the plan includes using a program
  per note, which is a bit more MIDI like, but even more verbose than the
  pattern style.

 a program per note would be bad. programs dont guarantee any timings of any
 sort. if u want N channels synced you're in trouble. :( but if u want to
 use
 embryo.lua then u can write CODE to play but u'll be writing code to have a
 timer and call play funcs... maybe from a passed in table/array.. but it'll
 boil down to the same thing.

 can you expand on the midi thing with some details? last i knew of midi it
 was
 roughly the same as a single track of a tracker with no defined length -
 just
 commands to play instr id X at note Y like thngs - much like a tracker.

  Can we cut the verbosity levels?  Though I guess edje has a similar
  problem, and the solution is to go to embryo, or lua (which so far
  seems to end up being about half as verbose as embryo, though YMMV).

 i'd say the verbosity is on par with a tracker... is that bad?

  Second is what you are doing to provide a scale.  I see you are
  basically dividing an octave into 7 equal parts, then doing maths to
  arrive at the numbers to feed into the system.  Now I'll admit that

 oh.. thats just making use of edje_cc's math handler. speed is 1.0 for
 play
 note at given samplerate ie - if sample is 44.1khz - then play at
 44.1khz. 2.0
 == play at 88.2khz. 0.5

Re: [E-devel] About release, snapshots and openBSD port

2011/11/11 Youness Alaoui kakar...@kakaroto.homelinux.net:
 On Fri, Nov 11, 2011 at 8:49 AM, Bruno Dilly bdi...@profusion.mobi wrote:

 On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net
 wrote:
  Hi,
 
  On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com
 wrote:
  On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri 
 vto...@univ-evry.fr
  said:
 
 
  Hey
 
  I'm talking a lot with an openBSD dev, and currently it's very hard for
  them to follow the changes in the trunk. What they would like to have
 is
  snapshots to provide easily patches for the EFL.
 
  how is that hard? svn checkout or update instead of wget. u also need
 to run
  autogen.sh.
 
  Would it be possible to have, during the freeze period, some daily
  snashots ? It would be nice to fix the openBSD port for the release.
 
  open to patches, but none have been submitted.
 
  Are you kidding ? I though you were reading the svn log. I take a lot
  of my time pushing / polishing these diff (special thanks to vtorrin,
  bluebugs and billiob).
  So you come from nowhere and make all this work looking bad, here and
  on irc, that's amazing.

 Sometimes he acts this way. Don't take it personal, don't let it
 demotivate you.
 Keep the good work ! =)

 Reminds me of some of the stuff I've been saying...
 As for don't have time to do tarballs everyday.. well, that's why there's
 something called scripts and cron jobs.. those things exist, might be
 good to use these awesome technologies.


The problem with that is guaranteeing that the entire thing builds.
Doing tarballs out of any random checkout is not unlike doing the
actual checkout yourself.

Now, to be fair, what the OpenBSD guys are asking for are some rc
tarballs before the release to make sure that everything is building
fine for them on the actual release, not daily tarballs, and this whole
thing got to this point out of not stating things clearly in the first place.


 
  if they require tarballs to
  test and can't just run svn instead to fetch the source... i don't have
 the
  time each day to make tarballs when they can just as easily fetch from
 svn.
  it's the same work on their part. making tarballs is MORE work on our
 part.
 
  You missed the point, we want to be sure that the final archive will be
 ok.
  I'm not asking for snapshot on a daily basis, only some rc before the
  final archive.
  (Wait no project did alpha  rc, right ?)
 
 
 
  Note that i discuss also with a Mageia e17 maintainer, and he told me
 that
  such snapshots will help him too.
 
  a snapshot has no more quality than an svn checkout, so other than a
 mental
  block thinking svn == totally unstable/unusable and an unwillingness to
 use it
  because of a mental block, i don't see the point.
 
  yeah a mental block, I think you don't want to know how many time I
  have to reroll a dist to get all working and how frustating it is.
 
 
  a release that has had quality assurance done on it is a different
 matter - but
  we arent doing them every day. hell no - not with al the efl trees we
 have.
  only chance of that is if we stopped having separate libs and just
 merged them
  into a single efl tree.
 
  Vincent
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)    ras...@rasterman.com
 
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
 --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 



 --
 Bruno Dilly
 Senior Developer
 ProFUSION embedded systems
 http://profusion.mobi


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

Re: [E-devel] About release, snapshots and openBSD port

2011-11-11 Thread Thanatermesis

This has not much sense, its the same a rc tarball than get it from an
actual svn checkout, I say that because if there's release candidate
tarballs, and something (related to how it builds) needs to be changed, no
matters if previously was made a tarball or not, so it becomes to have no
value at all.

2011/11/11 Iván Briano (Sachiel) sachi...@gmail.com

 2011/11/11 Youness Alaoui kakar...@kakaroto.homelinux.net:
  On Fri, Nov 11, 2011 at 8:49 AM, Bruno Dilly bdi...@profusion.mobi
 wrote:
 
  On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net
  wrote:
   Hi,
  
   On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler 
 ras...@rasterman.com
  wrote:
   On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri 
  vto...@univ-evry.fr
   said:
  
  
   Hey
  
   I'm talking a lot with an openBSD dev, and currently it's very hard
 for
   them to follow the changes in the trunk. What they would like to
 have
  is
   snapshots to provide easily patches for the EFL.
  
   how is that hard? svn checkout or update instead of wget. u also need
  to run
   autogen.sh.
  
   Would it be possible to have, during the freeze period, some daily
   snashots ? It would be nice to fix the openBSD port for the release.
  
   open to patches, but none have been submitted.
  
   Are you kidding ? I though you were reading the svn log. I take a lot
   of my time pushing / polishing these diff (special thanks to vtorrin,
   bluebugs and billiob).
   So you come from nowhere and make all this work looking bad, here and
   on irc, that's amazing.
 
  Sometimes he acts this way. Don't take it personal, don't let it
  demotivate you.
  Keep the good work ! =)
 
  Reminds me of some of the stuff I've been saying...
  As for don't have time to do tarballs everyday.. well, that's why
 there's
  something called scripts and cron jobs.. those things exist, might be
  good to use these awesome technologies.
 

 The problem with that is guaranteeing that the entire thing builds.
 Doing tarballs out of any random checkout is not unlike doing the
 actual checkout yourself.

 Now, to be fair, what the OpenBSD guys are asking for are some rc
 tarballs before the release to make sure that everything is building
 fine for them on the actual release, not daily tarballs, and this whole
 thing got to this point out of not stating things clearly in the first
 place.

 
  
   if they require tarballs to
   test and can't just run svn instead to fetch the source... i don't
 have
  the
   time each day to make tarballs when they can just as easily fetch
 from
  svn.
   it's the same work on their part. making tarballs is MORE work on our
  part.
  
   You missed the point, we want to be sure that the final archive will
 be
  ok.
   I'm not asking for snapshot on a daily basis, only some rc before the
   final archive.
   (Wait no project did alpha  rc, right ?)
  
  
  
   Note that i discuss also with a Mageia e17 maintainer, and he told
 me
  that
   such snapshots will help him too.
  
   a snapshot has no more quality than an svn checkout, so other than a
  mental
   block thinking svn == totally unstable/unusable and an unwillingness
 to
  use it
   because of a mental block, i don't see the point.
  
   yeah a mental block, I think you don't want to know how many time I
   have to reroll a dist to get all working and how frustating it is.
  
  
   a release that has had quality assurance done on it is a different
  matter - but
   we arent doing them every day. hell no - not with al the efl trees we
  have.
   only chance of that is if we stopped having separate libs and just
  merged them
   into a single efl tree.
  
   Vincent
  
  
 
 --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
   --
   - Codito, ergo sum - I code, therefore I am
 --
   The Rasterman (Carsten Haitzler)ras...@rasterman.com
  
  
  
 
 --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
 
 --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

2011/11/11 Thanatermesis thanatermesis.e...@gmail.com:
 This has not much sense, its the same a rc tarball than get it from an
 actual svn checkout, I say that because if there's release candidate
 tarballs, and something (related to how it builds) needs to be changed, no
 matters if previously was made a tarball or not, so it becomes to have no
 value at all.


It does have value. Once everything is ready for the release, you make
a pre-release tarball that they can make sure it builds fine on OpenBSD.
They are working on it now, but that last check is to ensure that no change
at the end that they missed or didn't get to test makes the released version
to break.

I'm all for doing that.

 2011/11/11 Iván Briano (Sachiel) sachi...@gmail.com

 2011/11/11 Youness Alaoui kakar...@kakaroto.homelinux.net:
  On Fri, Nov 11, 2011 at 8:49 AM, Bruno Dilly bdi...@profusion.mobi
 wrote:
 
  On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net
  wrote:
   Hi,
  
   On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler 
 ras...@rasterman.com
  wrote:
   On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri 
  vto...@univ-evry.fr
   said:
  
  
   Hey
  
   I'm talking a lot with an openBSD dev, and currently it's very hard
 for
   them to follow the changes in the trunk. What they would like to
 have
  is
   snapshots to provide easily patches for the EFL.
  
   how is that hard? svn checkout or update instead of wget. u also need
  to run
   autogen.sh.
  
   Would it be possible to have, during the freeze period, some daily
   snashots ? It would be nice to fix the openBSD port for the release.
  
   open to patches, but none have been submitted.
  
   Are you kidding ? I though you were reading the svn log. I take a lot
   of my time pushing / polishing these diff (special thanks to vtorrin,
   bluebugs and billiob).
   So you come from nowhere and make all this work looking bad, here and
   on irc, that's amazing.
 
  Sometimes he acts this way. Don't take it personal, don't let it
  demotivate you.
  Keep the good work ! =)
 
  Reminds me of some of the stuff I've been saying...
  As for don't have time to do tarballs everyday.. well, that's why
 there's
  something called scripts and cron jobs.. those things exist, might be
  good to use these awesome technologies.
 

 The problem with that is guaranteeing that the entire thing builds.
 Doing tarballs out of any random checkout is not unlike doing the
 actual checkout yourself.

 Now, to be fair, what the OpenBSD guys are asking for are some rc
 tarballs before the release to make sure that everything is building
 fine for them on the actual release, not daily tarballs, and this whole
 thing got to this point out of not stating things clearly in the first
 place.

 
  
   if they require tarballs to
   test and can't just run svn instead to fetch the source... i don't
 have
  the
   time each day to make tarballs when they can just as easily fetch
 from
  svn.
   it's the same work on their part. making tarballs is MORE work on our
  part.
  
   You missed the point, we want to be sure that the final archive will
 be
  ok.
   I'm not asking for snapshot on a daily basis, only some rc before the
   final archive.
   (Wait no project did alpha  rc, right ?)
  
  
  
   Note that i discuss also with a Mageia e17 maintainer, and he told
 me
  that
   such snapshots will help him too.
  
   a snapshot has no more quality than an svn checkout, so other than a
  mental
   block thinking svn == totally unstable/unusable and an unwillingness
 to
  use it
   because of a mental block, i don't see the point.
  
   yeah a mental block, I think you don't want to know how many time I
   have to reroll a dist to get all working and how frustating it is.
  
  
   a release that has had quality assurance done on it is a different
  matter - but
   we arent doing them every day. hell no - not with al the efl trees we
  have.
   only chance of that is if we stopped having separate libs and just
  merged them
   into a single efl tree.
  
   Vincent
  
  
 
 --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
   --
   - Codito, ergo sum - I code, therefore I am
 --
   The Rasterman (Carsten Haitzler)    ras...@rasterman.com
  
  
  
 
 --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port




On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:


2011/11/11 Youness Alaoui kakar...@kakaroto.homelinux.net:

On Fri, Nov 11, 2011 at 8:49 AM, Bruno Dilly bdi...@profusion.mobi wrote:


On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net
wrote:

Hi,

On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com

wrote:

On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri 

vto...@univ-evry.fr

said:



Hey

I'm talking a lot with an openBSD dev, and currently it's very hard for
them to follow the changes in the trunk. What they would like to have

is

snapshots to provide easily patches for the EFL.


how is that hard? svn checkout or update instead of wget. u also need

to run

autogen.sh.


Would it be possible to have, during the freeze period, some daily
snashots ? It would be nice to fix the openBSD port for the release.


open to patches, but none have been submitted.


Are you kidding ? I though you were reading the svn log. I take a lot
of my time pushing / polishing these diff (special thanks to vtorrin,
bluebugs and billiob).
So you come from nowhere and make all this work looking bad, here and
on irc, that's amazing.


Sometimes he acts this way. Don't take it personal, don't let it
demotivate you.
Keep the good work ! =)


Reminds me of some of the stuff I've been saying...
As for don't have time to do tarballs everyday.. well, that's why there's
something called scripts and cron jobs.. those things exist, might be
good to use these awesome technologies.



The problem with that is guaranteeing that the entire thing builds.


make distcheck...

Vincent


Doing tarballs out of any random checkout is not unlike doing the
actual checkout yourself.

Now, to be fair, what the OpenBSD guys are asking for are some rc
tarballs before the release to make sure that everything is building
fine for them on the actual release, not daily tarballs, and this whole
thing got to this point out of not stating things clearly in the first place.





if they require tarballs to

test and can't just run svn instead to fetch the source... i don't have

the

time each day to make tarballs when they can just as easily fetch from

svn.

it's the same work on their part. making tarballs is MORE work on our

part.


You missed the point, we want to be sure that the final archive will be

ok.

I'm not asking for snapshot on a daily basis, only some rc before the
final archive.
(Wait no project did alpha  rc, right ?)





Note that i discuss also with a Mageia e17 maintainer, and he told me

that

such snapshots will help him too.


a snapshot has no more quality than an svn checkout, so other than a

mental

block thinking svn == totally unstable/unusable and an unwillingness to

use it

because of a mental block, i don't see the point.


yeah a mental block, I think you don't want to know how many time I
have to reroll a dist to get all working and how frustating it is.



a release that has had quality assurance done on it is a different

matter - but

we arent doing them every day. hell no - not with al the efl trees we

have.

only chance of that is if we stopped having separate libs and just

merged them

into a single efl tree.


Vincent



--

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




--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)    ras...@rasterman.com




--

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





--

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





--
Bruno Dilly
Senior Developer
ProFUSION embedded systems
http://profusion.mobi


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


--
RSA(R) Conference 2012
Save

Re: [E-devel] sound api plan

On Fri, 11 Nov 2011 11:50:08 -0500 Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:

 Carsten, a few people have noted their disappointment (and anger) at
 this being merged and some requested it to be reverted, you didn't
 even take the time to answer them and address their concerns.. Could
 you please take the time to do that, since you obviously had time to
 respond to David with such a long email, it looks bad for you to
 respond to only what you want and ignore everyone else.

Actually, raster has replied a couple of times to those concerns in
this thread.

For the record, I'm not really interested in whether or not it goes in
for this release or not.  It does not do anything for me within the time
frame of this release that I had not already done for the relevant
projects.  For future projects I'm planning, sure it will be great.  So
my efforts are on the let's actually talk about the API, and not
saying anything about it's release timing.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

2011/11/11 Vincent Torri vto...@univ-evry.fr:
 The problem with that is guaranteeing that the entire thing builds.

 make distcheck...


And if it doesn't build you have the script keep trying? There's the OBS
for that, though I don't know if it provides the tarballs too.

 Vincent


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

Re: [E-devel] About release, snapshots and openBSD port




On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:


2011/11/11 Vincent Torri vto...@univ-evry.fr:

The problem with that is guaranteeing that the entire thing builds.


make distcheck...



And if it doesn't build you have the script keep trying? There's the OBS
for that, though I don't know if it provides the tarballs too.


make distcheck || exit 1

that way, the script exits on error. So really, there is no problem at 
all. You can also retrieve the error code, and let the script displaying 
message, sending a mail, etc.. and exiting cleanly


Vincent




Vincent



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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

2011-11-11 Thread Gustavo Sverzut Barbieri

On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr wrote:
 On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:
 2011/11/11 Vincent Torri vto...@univ-evry.fr:

 The problem with that is guaranteeing that the entire thing builds.

 make distcheck...


 And if it doesn't build you have the script keep trying? There's the OBS
 for that, though I don't know if it provides the tarballs too.

 make distcheck || exit 1

 that way, the script exits on error. So really, there is no problem at all. 
 You can also retrieve the error code, and let the script displaying message, 
 sending a mail, etc.. and exiting cleanly

Let's remember that if it build, ship it is not a good one. Many
things may fail even if they compile, like some incorrect string that
was changed with a typo.

I agree with Sachiel and think they want some guaranteed-to-work (at
least on Linux) tarballs, that they can use and assume all problems
found are OpenBSD specific and not bug on the generic parts.


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

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

Re: [E-devel] About release, snapshots and openBSD port

On Fri, 11 Nov 2011 14:19:12 +0100 Jonathan Armani d...@asystant.net said:

Hi,

On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri vto...@univ-evry.fr
said:

Hey

I'm talking a lot with an openBSD dev, and currently it's very hard for
them to follow the changes in the trunk. What they would like to have is
snapshots to provide easily patches for the EFL.

how is that hard? svn checkout or update instead of wget. u also need to run
autogen.sh.

Would it be possible to have, during the freeze period, some daily
snashots ? It would be nice to fix the openBSD port for the release.

open to patches, but none have been submitted.

Are you kidding ? I though you were reading the svn log. I take a lot
of my time pushing / polishing these diff (special thanks to vtorrin,
bluebugs and billiob).
So you come from nowhere and make all this work looking bad, here and
on irc, that's amazing.

you don't have commit access. so you can't be committing. i see zero emails
from you on e-devel with patches... the first i saw of any patches was when
vtorri pointed me to them. no - i'm not reading every commit mail. this is the
first email from you on this list... you've never poked up with a question that
i have ever seen related to your patches, which definitely went off and did the
wrong thing.

and yes - many of the patches were bad. what made you think changing
evas_object_color_get() to use unsigned char *'s instead of int *'s was good?

https://github.com/jarmani/mystuff/blob/master/x11/e17/evas/patches/patch-src_lib_canvas_evas_object_main_c

it looks bad. it *IS* bad. that's an instant api and abi break just on openbsd.
i'm not allowed to say that that is bad? many of the patches to evas, edje, and
more were to adjust for this api/abi break to a stable abi. there isn't anything
there to fix in changing that. you just make sure that applications built
correctly will have bugs/crashes/errors on openbsd by doing this.

also patching more libs to not used chained_mempool because you disabled it in
eina's build wasn't a great move. you should have kept it enabled and if you
thought that it's pool allocator was just a repeat of bsd's libc one - just
patched chained_mempool to straight through use bsd malloc/free. it would have
been a simpler, less invasive patch.

in addition you're patching configure scripts and Makefiles as opposed to their
source (configure.ac, Makefile.am) which may just patch over your immediate
problem, but won't work in the long run as every time you run autogen.sh you
overwrite your changes. a change in autoconf or m4 macro sources can instantly
nullify the patch. it also will break for releases too per new release. it's
much better to identify the source in the Makefile.am or configure.ac and find
out why its generating something that doesn't work for you and fix it at the
source (well that or in autoconf or automake directly itself and maybe its
macros and templates).

i saw these and yes - i said it was bad and i wish you didn't do things like
break api's on openbsd without talking to use first and at least asking why
something is how it is.

if they require tarballs to
test and can't just run svn instead to fetch the source... i don't have the
time each day to make tarballs when they can just as easily fetch from svn.
it's the same work on their part. making tarballs is MORE work on our part.

You missed the point, we want to be sure that the final archive will be ok.
I'm not asking for snapshot on a daily basis, only some rc before the
final archive.
(Wait no project did alpha rc, right ?)

the final archive will be what's in svn - as per make dist. make distcheck
ensures that you ship what you are meant to. the rest is ensuring the source in
svn has bugs fixes and documentation is up to date. there isn't an rc or alpha
because there's still things to be done before that and they are being done. i
was going through news files today as well as some bugfixes.

Note that i discuss also with a Mageia e17 maintainer, and he told me that
such snapshots will help him too.

a snapshot has no more quality than an svn checkout, so other than a mental
block thinking svn == totally unstable/unusable and an unwillingness to use
it because of a mental block, i don't see the point.

yeah a mental block, I think you don't want to know how many time I
have to reroll a dist to get all working and how frustating it is.

and equally having to make dist tarballs every day is frustrating, eats up time
and is no better quality than an svn checkout unless it sucks up even MORE
time. vincent suggested daily snapshot tarballs. i say that that is the same as
svn checkout so where is the value in doing the extra work?

i get the message OMG! he dissed my patches and isn't giving me what i ask
for! i'm going to make an issue about it!.

your patches were bad. they committed a

Re: [E-devel] About release, snapshots and openBSD port

On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui
kakar...@kakaroto.homelinux.net said:

 Reminds me of some of the stuff I've been saying...
 As for don't have time to do tarballs everyday.. well, that's why there's
 something called scripts and cron jobs.. those things exist, might be
 good to use these awesome technologies.

hooray for your snide comments. wonderful attitude. you were not there on irc,
nor did you even seem to have read the material at hand (the patches).
seriously, what's up with you?

do i suddenly have to be mr. nice to everything? oh wow! how wonderful! so
awesome that you broke evas's api on your openbsd packages. so great to see.
we'll love hearing the app developers ask us for help about their apps not
working on openbsd, when we will have zero clue that it was an api/abi breakage
added specifically on openbsd. that's just awesome. please - make more patches
just like that!.

if its bad, it's bad. reasons were explicitly given for it being bad.

and as for well just use scripts - have to write and test those too. and if
its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT. that was
my point... which you failed to read. if you don't sit down and spend at least
some qa time on the tarballs... then its pointless. this is my point on a
mental block. i keep hearing it from people omg  svn trunk must be so
unstable!!! how can i use it? - it's the image that just because its in trunk
(or head/master/whatever) that it must be so unstable and a tarball made every
day is going to be better. it's a RELEASE process of freezing and fixing just
bugs that improves quality... not make dist; scp *.tar.gz 

   if they require tarballs to
   test and can't just run svn instead to fetch the source... i don't have
  the
   time each day to make tarballs when they can just as easily fetch from
  svn.
   it's the same work on their part. making tarballs is MORE work on our
  part.
  
   You missed the point, we want to be sure that the final archive will be
  ok.
   I'm not asking for snapshot on a daily basis, only some rc before the
   final archive.
   (Wait no project did alpha  rc, right ?)
  
  
  
   Note that i discuss also with a Mageia e17 maintainer, and he told me
  that
   such snapshots will help him too.
  
   a snapshot has no more quality than an svn checkout, so other than a
  mental
   block thinking svn == totally unstable/unusable and an unwillingness to
  use it
   because of a mental block, i don't see the point.
  
   yeah a mental block, I think you don't want to know how many time I
   have to reroll a dist to get all working and how frustating it is.
  
  
   a release that has had quality assurance done on it is a different
  matter - but
   we arent doing them every day. hell no - not with al the efl trees we
  have.
   only chance of that is if we stopped having separate libs and just
  merged them
   into a single efl tree.
  
   Vincent
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
   --
   - Codito, ergo sum - I code, therefore I am --
   The Rasterman (Carsten Haitzler)ras...@rasterman.com
  
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 
 
  --
  Bruno Dilly
  Senior Developer
  ProFUSION embedded systems
  http://profusion.mobi
 
 
  --
  RSA(R) Conference 2012
  Save $700 by Nov 18
  Register now
  http://p.sf.net/sfu/rsa-sfdev2dev1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___

Re: [E-devel] About release, snapshots and openBSD port

On Fri, 11 Nov 2011 14:50:34 -0200 Iván Briano (Sachiel) sachi...@gmail.com
said:

 2011/11/11 Youness Alaoui kakar...@kakaroto.homelinux.net:
  On Fri, Nov 11, 2011 at 8:49 AM, Bruno Dilly bdi...@profusion.mobi wrote:
 
  On Fri, Nov 11, 2011 at 11:19 AM, Jonathan Armani d...@asystant.net
  wrote:
   Hi,
  
   On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler ras...@rasterman.com
  wrote:
   On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri 
  vto...@univ-evry.fr
   said:
  
  
   Hey
  
   I'm talking a lot with an openBSD dev, and currently it's very hard for
   them to follow the changes in the trunk. What they would like to have
  is
   snapshots to provide easily patches for the EFL.
  
   how is that hard? svn checkout or update instead of wget. u also need
  to run
   autogen.sh.
  
   Would it be possible to have, during the freeze period, some daily
   snashots ? It would be nice to fix the openBSD port for the release.
  
   open to patches, but none have been submitted.
  
   Are you kidding ? I though you were reading the svn log. I take a lot
   of my time pushing / polishing these diff (special thanks to vtorrin,
   bluebugs and billiob).
   So you come from nowhere and make all this work looking bad, here and
   on irc, that's amazing.
 
  Sometimes he acts this way. Don't take it personal, don't let it
  demotivate you.
  Keep the good work ! =)
 
  Reminds me of some of the stuff I've been saying...
  As for don't have time to do tarballs everyday.. well, that's why there's
  something called scripts and cron jobs.. those things exist, might be
  good to use these awesome technologies.
 
 
 The problem with that is guaranteeing that the entire thing builds.
 Doing tarballs out of any random checkout is not unlike doing the
 actual checkout yourself.

thanks man for actually reading what i wrote. :) yup. make distcheck is per
tree. so fine. have to now write script to do for I in eina eet ; do
done - but it has to also do the3 upload, generate announce email/news file,
and currently.. i don't have that script - so i have to write it, test it, etc.

 Now, to be fair, what the OpenBSD guys are asking for are some rc
 tarballs before the release to make sure that everything is building
 fine for them on the actual release, not daily tarballs, and this whole
 thing got to this point out of not stating things clearly in the first place.

sure, BUT... vincent's mail says some daily snashots (yes - missing a p -
that's fine. i got the message) and i asked how an svn checkout/update is hard?
i'm definitely going to say no to daily snapshots between now and release
because of the same thing you said. it's no better than a random svn checkout
anyway so all it has achieved is wasting time. tarballs can be made when
desired, and useful, but not just daily because it's simply an aversion to
using svn co XXX; ./autogen.sh... vs wget http://; ./configure... :)

 
  
   if they require tarballs to
   test and can't just run svn instead to fetch the source... i don't have
  the
   time each day to make tarballs when they can just as easily fetch from
  svn.
   it's the same work on their part. making tarballs is MORE work on our
  part.
  
   You missed the point, we want to be sure that the final archive will be
  ok.
   I'm not asking for snapshot on a daily basis, only some rc before the
   final archive.
   (Wait no project did alpha  rc, right ?)
  
  
  
   Note that i discuss also with a Mageia e17 maintainer, and he told me
  that
   such snapshots will help him too.
  
   a snapshot has no more quality than an svn checkout, so other than a
  mental
   block thinking svn == totally unstable/unusable and an unwillingness to
  use it
   because of a mental block, i don't see the point.
  
   yeah a mental block, I think you don't want to know how many time I
   have to reroll a dist to get all working and how frustating it is.
  
  
   a release that has had quality assurance done on it is a different
  matter - but
   we arent doing them every day. hell no - not with al the efl trees we
  have.
   only chance of that is if we stopped having separate libs and just
  merged them
   into a single efl tree.
  
   Vincent
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
   --
   - Codito, ergo sum - I code, therefore I am --
   The Rasterman (Carsten Haitzler)    ras...@rasterman.com
  
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1

Re: [E-devel] About release, snapshots and openBSD port

On Fri, 11 Nov 2011 15:36:07 -0200 Gustavo Sverzut Barbieri
barbi...@profusion.mobi said:

 On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr wrote:
  On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:
  2011/11/11 Vincent Torri vto...@univ-evry.fr:
 
  The problem with that is guaranteeing that the entire thing builds.
 
  make distcheck...
 
 
  And if it doesn't build you have the script keep trying? There's the OBS
  for that, though I don't know if it provides the tarballs too.
 
  make distcheck || exit 1
 
  that way, the script exits on error. So really, there is no problem at all.
  You can also retrieve the error code, and let the script displaying
  message, sending a mail, etc.. and exiting cleanly
 
 Let's remember that if it build, ship it is not a good one. Many
 things may fail even if they compile, like some incorrect string that
 was changed with a typo.
 
 I agree with Sachiel and think they want some guaranteed-to-work (at
 least on Linux) tarballs, that they can use and assume all problems
 found are OpenBSD specific and not bug on the generic parts.

yup. we'll make some alpha tarballs once its ready - as such we still need to
fix up readme's, news files etc. anyway, and i was going to disable multisense
in edje - but haven't gone there yet, so just haven't done it yet. definitely no
daily snapshots - you can do per minute snaps if u want from svn :) tarballs
will come. :)

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] About release, snapshots and openBSD port




On Fri, 11 Nov 2011, Gustavo Sverzut Barbieri wrote:


On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr wrote:

On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:

2011/11/11 Vincent Torri vto...@univ-evry.fr:


The problem with that is guaranteeing that the entire thing builds.


make distcheck...



And if it doesn't build you have the script keep trying? There's the OBS
for that, though I don't know if it provides the tarballs too.


make distcheck || exit 1

that way, the script exits on error. So really, there is no problem at all. You 
can also retrieve the error code, and let the script displaying message, 
sending a mail, etc.. and exiting cleanly


Let's remember that if it build, ship it is not a good one. Many
things may fail even if they compile, like some incorrect string that
was changed with a typo.


same problem when we release, so... Release is basically : we update 
version, some file, make distcheck, we copy the tarball somewhere.


Vincent


I agree with Sachiel and think they want some guaranteed-to-work (at
least on Linux) tarballs, that they can use and assume all problems
found are OpenBSD specific and not bug on the generic parts.--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

2011/11/11 Vincent Torri vto...@univ-evry.fr:


 On Fri, 11 Nov 2011, Gustavo Sverzut Barbieri wrote:

 On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr
 wrote:

 On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:

 2011/11/11 Vincent Torri vto...@univ-evry.fr:

 The problem with that is guaranteeing that the entire thing builds.

 make distcheck...


 And if it doesn't build you have the script keep trying? There's the OBS
 for that, though I don't know if it provides the tarballs too.

 make distcheck || exit 1

 that way, the script exits on error. So really, there is no problem at
 all. You can also retrieve the error code, and let the script displaying
 message, sending a mail, etc.. and exiting cleanly

 Let's remember that if it build, ship it is not a good one. Many
 things may fail even if they compile, like some incorrect string that
 was changed with a typo.

 same problem when we release, so... Release is basically : we update
 version, some file, make distcheck, we copy the tarball somewhere.


Nah, you usually test releases to make sure they actually work, instead
of just firing make and uploading the package if it didn't fail.

 Vincent

 I agree with Sachiel and think they want some guaranteed-to-work (at
 least on Linux) tarballs, that they can use and assume all problems
 found are OpenBSD specific and not bug on the generic parts.

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



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

Re: [E-devel] About release, snapshots and openBSD port




On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:


2011/11/11 Vincent Torri vto...@univ-evry.fr:



On Fri, 11 Nov 2011, Gustavo Sverzut Barbieri wrote:


On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr
wrote:


On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:


2011/11/11 Vincent Torri vto...@univ-evry.fr:


The problem with that is guaranteeing that the entire thing builds.


make distcheck...



And if it doesn't build you have the script keep trying? There's the OBS
for that, though I don't know if it provides the tarballs too.


make distcheck || exit 1

that way, the script exits on error. So really, there is no problem at
all. You can also retrieve the error code, and let the script displaying
message, sending a mail, etc.. and exiting cleanly


Let's remember that if it build, ship it is not a good one. Many
things may fail even if they compile, like some incorrect string that
was changed with a typo.


same problem when we release, so... Release is basically : we update
version, some file, make distcheck, we copy the tarball somewhere.



Nah, you usually test releases to make sure they actually work, instead
of just firing make and uploading the package if it didn't fail.


we can say : hey, here are dayly snapshot, these are compiling but must 
not work correctly. And you gave the list of dayly snapshot


note that i wanted to do that for the freeze period. I don't see why 
you're relunctant to an automated process that requires 0s of work, except 
the basic shell script.


But when that thread will end, the freeze period will be over...

Vincent




Vincent


I agree with Sachiel and think they want some guaranteed-to-work (at
least on Linux) tarballs, that they can use and assume all problems
found are OpenBSD specific and not bug on the generic parts.


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




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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

2011-11-11 Thread Jonathan Armani

On Fri, Nov 11, 2011 at 6:42 PM, Carsten Haitzler ras...@rasterman.com wrote:
 On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

 Reminds me of some of the stuff I've been saying...
 As for don't have time to do tarballs everyday.. well, that's why there's
 something called scripts and cron jobs.. those things exist, might be
 good to use these awesome technologies.

 hooray for your snide comments. wonderful attitude. you were not there on irc,
 nor did you even seem to have read the material at hand (the patches).
 seriously, what's up with you?

 do i suddenly have to be mr. nice to everything? oh wow! how wonderful! so
 awesome that you broke evas's api on your openbsd packages. so great to see.
 we'll love hearing the app developers ask us for help about their apps not
 working on openbsd, when we will have zero clue that it was an api/abi 
 breakage
 added specifically on openbsd. that's just awesome. please - make more patches
 just like that!.

 if its bad, it's bad. reasons were explicitly given for it being bad.

I accept without problem the critisism on these diff (note and look at
the commit these are
not from me). But that is my personnal git, and it contains
experimental diff and these will never
go in tree if they are not ok.

I never asked a review of these ...

But yeah once again you're right, all this work is shit on shit and
the OpenBSD team is only capable
of breaking your stuff.


 and as for well just use scripts - have to write and test those too. and if
 its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT. that was
 my point... which you failed to read. if you don't sit down and spend at least
 some qa time on the tarballs... then its pointless. this is my point on a
 mental block. i keep hearing it from people omg  svn trunk must be so
 unstable!!! how can i use it? - it's the image that just because its in trunk
 (or head/master/whatever) that it must be so unstable and a tarball made every
 day is going to be better. it's a RELEASE process of freezing and fixing just
 bugs that improves quality... not make dist; scp *.tar.gz 

   if they require tarballs to
   test and can't just run svn instead to fetch the source... i don't have
  the
   time each day to make tarballs when they can just as easily fetch from
  svn.
   it's the same work on their part. making tarballs is MORE work on our
  part.
  
   You missed the point, we want to be sure that the final archive will be
  ok.
   I'm not asking for snapshot on a daily basis, only some rc before the
   final archive.
   (Wait no project did alpha  rc, right ?)
  
  
  
   Note that i discuss also with a Mageia e17 maintainer, and he told me
  that
   such snapshots will help him too.
  
   a snapshot has no more quality than an svn checkout, so other than a
  mental
   block thinking svn == totally unstable/unusable and an unwillingness to
  use it
   because of a mental block, i don't see the point.
  
   yeah a mental block, I think you don't want to know how many time I
   have to reroll a dist to get all working and how frustating it is.
  
  
   a release that has had quality assurance done on it is a different
  matter - but
   we arent doing them every day. hell no - not with al the efl trees we
  have.
   only chance of that is if we stopped having separate libs and just
  merged them
   into a single efl tree.
  
   Vincent
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
   --
   - Codito, ergo sum - I code, therefore I am --
   The Rasterman (Carsten Haitzler)    ras...@rasterman.com
  
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
  --
   RSA(R) Conference 2012
   Save $700 by Nov 18
   Register now
   http://p.sf.net/sfu/rsa-sfdev2dev1
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 
 
  --
  Bruno Dilly
  Senior Developer
  ProFUSION embedded systems
  http://profusion.mobi
 
 
  --
  RSA(R) Conference 2012
  Save $700 by Nov 18

Re: [E-devel] [Patch][ecore_con] Refactoring curl port

2011-11-11 Thread Cedric BAIL

Yop,

On Fri, Nov 11, 2011 at 9:55 AM, Sebastian Dransfeld s...@tango.flipp.net 
wrote:
 On 11/11/2011 09:41 AM, Bluezery wrote:
 It's my mistake.

 fixed patch is attached again.
 I have removed active flag also.
 I use eina_list_data_find() instead.

 Also, there is used a lot of idlers. I think all idlers can be removed
 now, as we only do one multi perform on each fd handler ready.

 The reason the idlers were added, was that we did multi_perform in loop
 for 0.1s (or something like that) which clogged the system.

 Cedric was the one adding the idlers, Cedric???

Yup, the idler are here to reschedule the handling of data later so
that the UI continue to be responsive even in a storm of data on a
slow machine. I think they should be kept around as this will always
be the case.
-- 
Cedric BAIL

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

Re: [E-devel] About release, snapshots and openBSD port

2011/11/11 Vincent Torri vto...@univ-evry.fr:


 On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:

 2011/11/11 Vincent Torri vto...@univ-evry.fr:


 On Fri, 11 Nov 2011, Gustavo Sverzut Barbieri wrote:

 On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr
 wrote:

 On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:

 2011/11/11 Vincent Torri vto...@univ-evry.fr:

 The problem with that is guaranteeing that the entire thing builds.

 make distcheck...


 And if it doesn't build you have the script keep trying? There's the
 OBS
 for that, though I don't know if it provides the tarballs too.

 make distcheck || exit 1

 that way, the script exits on error. So really, there is no problem at
 all. You can also retrieve the error code, and let the script
 displaying
 message, sending a mail, etc.. and exiting cleanly

 Let's remember that if it build, ship it is not a good one. Many
 things may fail even if they compile, like some incorrect string that
 was changed with a typo.

 same problem when we release, so... Release is basically : we update
 version, some file, make distcheck, we copy the tarball somewhere.


 Nah, you usually test releases to make sure they actually work, instead
 of just firing make and uploading the package if it didn't fail.

 we can say : hey, here are dayly snapshot, these are compiling but must not
 work correctly. And you gave the list of dayly snapshot

 note that i wanted to do that for the freeze period. I don't see why you're
 relunctant to an automated process that requires 0s of work, except the
 basic shell script.

 But when that thread will end, the freeze period will be over...


I'm not reluctant to doing that, I'm keeping this within the context of
the original request. The freeze for the release ends next week, so the
release will happen around that time. I don't think setting up such a
system now makes sense within that context, but if it gets done for
the long term it's fine.

 Vincent


 Vincent

 I agree with Sachiel and think they want some guaranteed-to-work (at
 least on Linux) tarballs, that they can use and assume all problems
 found are OpenBSD specific and not bug on the generic parts.


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




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


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



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

Re: [E-devel] sound api plan

2011-11-11 Thread Mike Blumenkrantz

On Fri, 11 Nov 2011 11:50:08 -0500
Youness Alaoui kakar...@kakaroto.homelinux.net wrote:

 Carsten, a few people have noted their disappointment (and anger) at this
 being merged and some requested it to be reverted, you didn't even take the
 time to answer them and address their concerns.. Could you please take the
 time to do that, since you obviously had time to respond to David with such
 a long email, it looks bad for you to respond to only what you want and
 ignore everyone else.
He's a busy guy, and this is a serious issue that he can't just reply off the
top of his head like he's been doing with his other mails. Relax.
 
 On Fri, Nov 11, 2011 at 1:33 AM, Carsten Haitzler ras...@rasterman.comwrote:
 
  On Thu, 10 Nov 2011 18:50:45 +1000 David Seikel onef...@gmail.com said:
 
   On Tue, 8 Nov 2011 16:33:42 +0900 Carsten Haitzler (The Rasterman)
   ras...@rasterman.com wrote:
  
On Tue, 8 Nov 2011 07:23:27 +0100 (CET) Vincent Torri
vto...@univ-evry.fr said:
   


 On Mon, 7 Nov 2011, Carsten Haitzler (The Rasterman) wrote:

  attached. this was a sample edc that would be able to play audio,
  not just single samples but whole sequences across multiple
  tracks as well as control specific channels and tracks. it didn't
  specify looping params yet or other additional stuff.

 i've never heard about that sound plan before the commit. The patch
 was not public and we could not have discussed about it before the
 commit. So I really don't like the way it came into edje.
   
i'm not sure this is much different from anything else that goes on
in efl. i have done work for a decade+ without discussing patches on
the mailing list first. so have most developers. as such this patch
this time was going through me. the comments on the patch so far
havent actually commented on the edc api it adds at all which
everyone is up in arms about for release. so since everyone
complaining isn't actually talking about that... i'll write it here
in short form. it adds: sounds {
  sample {
 name: NAME ENCODING;
 source: SAMPLE_FILE;
  }
  ...
  tone: NAME FREQ;
  ...
   }
and 2 more actions:
   PLAY_SAMPLE NAME SPEED;
   PLAY_TONE NAME DURATION;
   
that's it. unfortunately to make this WORK u need a chunk of infra
like being able to load and encode samples into edj files, decode
them, play and mix them, resample them, etc. all of which is opaque
to the api.
  
   /me picks a spot in this thread to actually discuss the API.  Here
   seems the best.
 
  hooray! :)
 
   A quick look over it, and the example, and the plan, and it seems
   mostly sane. One thing that stands out straight away in the examples is
   the way that a bit of music was defined.
  
   First thing is that you are using something that looks like a typical
   tracker, which is fine in itself.  Lots of people are familiar with
   that.  It's a bit verbose though.
 
  well my hope actually was that later we can provide a mod/xm/s3m converter
  that
  can load one of these files and produce a bunch of edc to include. the only
  reason i didn't go right to use libmikmod and just inline mods in your
  edj was
  that these mod formats don't support ogg/mp3 etc. style sample compression
  and i
  really want that for space efficiency reasons. i actually wasn't expecting
  peolpe to write music in edc. it's POSSIBLE and to be honest - when i did
  tracking you literallly did almost what the edc says in text. u arrow down
  7,
  hit a key to play the sample at that speed (c-3/b-3/f#-2 etc.). you'd
  literally just have the sound  played at that time as the added bonus.. :)
 
   I think it would be great to also provide an alternative that is more
   like MIDI, as that is also used by a lot of people.  Have both, that
   would cover most things.  Actually, the plan includes using a program
   per note, which is a bit more MIDI like, but even more verbose than the
   pattern style.
 
  a program per note would be bad. programs dont guarantee any timings of any
  sort. if u want N channels synced you're in trouble. :( but if u want to
  use
  embryo.lua then u can write CODE to play but u'll be writing code to have a
  timer and call play funcs... maybe from a passed in table/array.. but it'll
  boil down to the same thing.
 
  can you expand on the midi thing with some details? last i knew of midi it
  was
  roughly the same as a single track of a tracker with no defined length -
  just
  commands to play instr id X at note Y like thngs - much like a tracker.
 
   Can we cut the verbosity levels?  Though I guess edje has a similar
   problem, and the solution is to go to embryo, or lua (which so far
   seems to end up being about half as verbose as embryo, though YMMV).
 
  i'd say the verbosity is on par with a tracker... is that bad?
 
   Second is what you are doing to provide a scale.

Re: [E-devel] About release, snapshots and openBSD port




On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:


2011/11/11 Vincent Torri vto...@univ-evry.fr:



On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:


2011/11/11 Vincent Torri vto...@univ-evry.fr:



On Fri, 11 Nov 2011, Gustavo Sverzut Barbieri wrote:


On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr
wrote:


On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:


2011/11/11 Vincent Torri vto...@univ-evry.fr:


The problem with that is guaranteeing that the entire thing builds.


make distcheck...



And if it doesn't build you have the script keep trying? There's the
OBS
for that, though I don't know if it provides the tarballs too.


make distcheck || exit 1

that way, the script exits on error. So really, there is no problem at
all. You can also retrieve the error code, and let the script
displaying
message, sending a mail, etc.. and exiting cleanly


Let's remember that if it build, ship it is not a good one. Many
things may fail even if they compile, like some incorrect string that
was changed with a typo.


same problem when we release, so... Release is basically : we update
version, some file, make distcheck, we copy the tarball somewhere.



Nah, you usually test releases to make sure they actually work, instead
of just firing make and uploading the package if it didn't fail.


we can say : hey, here are dayly snapshot, these are compiling but must not
work correctly. And you gave the list of dayly snapshot

note that i wanted to do that for the freeze period. I don't see why you're
relunctant to an automated process that requires 0s of work, except the
basic shell script.

But when that thread will end, the freeze period will be over...



I'm not reluctant to doing that, I'm keeping this within the context of
the original request. The freeze for the release ends next week, so the
release will happen around that time. I don't think setting up such a
system now makes sense within that context, but if it gets done for
the long term it's fine.


the plan was to integrate such process in ebuilder, a program written in 
ruby  by Philippe Caseiro to compile on several hosts, with different 
options to configure, sending mails if something wrong happens, with 
beautiful html pages which shows the problems, and plenty of other stuff


It's not finished. If some people know ruby and want to help, contact 
Philippe


Vincent




Vincent




Vincent


I agree with Sachiel and think they want some guaranteed-to-work (at
least on Linux) tarballs, that they can use and assume all problems
found are OpenBSD specific and not bug on the generic parts.



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





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



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




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

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] sound api plan

On Fri, Nov 11, 2011 at 12:18 PM, David Seikel onef...@gmail.com wrote:

 On Fri, 11 Nov 2011 11:50:08 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:

  Carsten, a few people have noted their disappointment (and anger) at
  this being merged and some requested it to be reverted, you didn't
  even take the time to answer them and address their concerns.. Could
  you please take the time to do that, since you obviously had time to
  respond to David with such a long email, it looks bad for you to
  respond to only what you want and ignore everyone else.

 Actually, raster has replied a couple of times to those concerns in
 this thread.


I checked before writing that, he only replied to Vincent's mail with :
   i'm not sure this is much different from anything else that goes on in
efl. i
have done work for a decade+ without discussing patches on the mailing
list
first. so have most developers. as such this patch this time was going
through
me.
which isn't let's talk about your concerns but rather a it's fine,I've
always done that.
Then Mike, Gustavo, Tom and Rafael all responded, agreeing with Vincent and
adding their own concerns, and I haven't seen an answer to any of their
mails.



 For the record, I'm not really interested in whether or not it goes in
 for this release or not.  It does not do anything for me within the time
 frame of this release that I had not already done for the relevant
 projects.  For future projects I'm planning, sure it will be great.  So
 my efforts are on the let's actually talk about the API, and not
 saying anything about it's release timing.


I personally like the API, it is probably too complex for what most people
would use it for, but as long as you can do the simple things easily but
use more complex constructs for complex stuff, I'm fine with that (I
haven't actually looked at how easy it would be for a simple play this
.wav when the button is clicked, so can't see if the easy requirement is
satisfied).

One issue though is that from what I was told, the sound engine is modular
inside edje and an alsa module was written. I find this completely absurd
to have a sound abstraction module inside edje. It clearly should go into
ecore (ecore_sound or something) and have edje use that, because then you'd
have people writing alsa/oss/pulse/ps3 modules for edje, but noone can use
them outside of edje. That's a big design flaw right there and that's
something I disagree with.

I am truly excited about having something powerful like that in edje
though, but I see Mike/Gustavo/Tom/Rafael's concerns + some of the stuff
said on IRC and I have to agree with them. While this is cool, it is not
the right time for it to get merged, the API should have been discussed,
and it's an important feature that needs to be matured before a release and
the 2 week feature freeze is definitely not enough to mature it. Its place
is in edje 1.2 or whatever and not to be thrown into svn right before the
deadline. While the feature freeze means you can't add new features, it
doesn't mean that you can add anything just before it. This isn't the right
way of doing things, and it feels like this feature might have been
committed at the last minute out of pressions from samsung rather than from
a consensus of this is needed and it's the right thing to do amongst the
EFL developers.

Just my 2 cents.
KaKaRoTo



 --
 A big old stinking pile of genius that no one wants
 coz there are too many silver coated monkeys in the world.


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


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

Re: [E-devel] About release, snapshots and openBSD port

2011-11-11 Thread Cedric BAIL

On Fri, Nov 11, 2011 at 6:50 PM, Carsten Haitzler ras...@rasterman.com wrote:
 On Fri, 11 Nov 2011 15:36:07 -0200 Gustavo Sverzut Barbieri
 barbi...@profusion.mobi said:

 On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri vto...@univ-evry.fr wrote:
  On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote:
  2011/11/11 Vincent Torri vto...@univ-evry.fr:
 
  The problem with that is guaranteeing that the entire thing builds.
 
  make distcheck...
 
 
  And if it doesn't build you have the script keep trying? There's the OBS
  for that, though I don't know if it provides the tarballs too.
 
  make distcheck || exit 1
 
  that way, the script exits on error. So really, there is no problem at all.
  You can also retrieve the error code, and let the script displaying
  message, sending a mail, etc.. and exiting cleanly

 Let's remember that if it build, ship it is not a good one. Many
 things may fail even if they compile, like some incorrect string that
 was changed with a typo.

 I agree with Sachiel and think they want some guaranteed-to-work (at
 least on Linux) tarballs, that they can use and assume all problems
 found are OpenBSD specific and not bug on the generic parts.

 yup. we'll make some alpha tarballs once its ready - as such we still need to
 fix up readme's, news files etc. anyway, and i was going to disable multisense
 in edje - but haven't gone there yet, so just haven't done it yet. definitely 
 no
 daily snapshots - you can do per minute snaps if u want from svn :) tarballs
 will come. :)

If you want, I will have time Sunday to do an alpha tarball of all
that stuff. It's still an open source project and all developers can
help you get this out, no need to put everything on you.
-- 
Cedric BAIL

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

Re: [E-devel] EFL 1.1 freeze

On Thu, 3 Nov 2011 17:27:55 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com wrote:

 On Thu, 3 Nov 2011 18:15:35 +1000 David Seikel onef...@gmail.com
 said:
 
  On Thu, 03 Nov 2011 03:01:17 -0400 Christopher Michael
  cpmicha...@comcast.net wrote:
  
   On 11/02/11 22:42, David Seikel wrote:
On Thu, 3 Nov 2011 08:49:46 +0900 Carsten Haitzler (The
Rasterman) ras...@rasterman.com  wrote:
   
On Wed, 2 Nov 2011 12:14:07 -0400 Mike Blumenkrantz
m...@zentific.com  said:
   
Hi,
   
It has been two weeks since the git 'er done mail from
raster, so I am calling his bluff. Effective immediately, we
are in a 2 week feature freeze for EFL 1.1.
   
no - freeze starts monday :) from my original mail:
   
merge window starts next monday (24th of october). that means
from the 7th to the 20th no new features can be added to
trunk, only bug fixes.
   
so people have until sunday night...
   
So I have until Sunday to badger raster into just letting me
commit the new edje lua stuff?  It would really help me a lot
if what I have done so far is in the next release.  That
includes the basic text object support I did last night,
   
   approved.. Slip it in onefang ;)
  
  Hey wait, you are not listed as one of the edje authors.  So that
  don't count.  :-P
 
 lets talk this weekend.

Making sure that lua images only come from within the same file, or even
looking for images in edje files, looks a bit tricky to me.  I'm hoping
someone with more edje experience than me can at least show me the way.

At the moment it looks like there is a whole bunch of private code that
edje_calc.c has to do it.  Don't like duplicating that much code.  Not
to mention that it seems to deal with stuff I don't have.

My next task is to properly subclass the evas metatable stuff for
images, text, etc.  Then implement that argument parsing and returning
thing I have a FIXME for in the source.  No API changes, just making it
all neater internally.

After those two I want to make a bunch of macros for taking care of the
boilerplate.  That will make future API (after the freeze) additions
much easier.

I think that's all that's needed for the edje lua freeze.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: caro trunk/ecore/src/lib/ecore_x/xcb

On 11/11/11 13:51, Enlightenment SVN wrote:
 Log:
 Ecore: Fix warning: large integer implicitly truncated to unsigned type 
 inecore_x/xcb

xcb_get_property_unchecked() requires an uint32_t as last parameter, so use
UINT_MAX instead of LONG_MAX

Patch from OpenBSD via Jonathan Armani


 Author:   caro
 Date: 2011-11-11 10:51:53 -0800 (Fri, 11 Nov 2011)
 New Revision: 65073
 Trac: http://trac.enlightenment.org/e/changeset/65073

 Modified:
trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c 
 trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c   2011-11-11 18:11:10 UTC 
 (rev 65072)
 +++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c   2011-11-11 18:51:53 UTC 
 (rev 65073)
 @@ -63,7 +63,7 @@
  cookie =
xcb_get_property_unchecked(_ecore_xcb_conn, 0, win,
   ECORE_X_ATOM_MOTIF_WM_HINTS,
 -ECORE_X_ATOM_MOTIF_WM_HINTS, 0, LONG_MAX);
 +ECORE_X_ATOM_MOTIF_WM_HINTS, 0, UINT_MAX);
  reply = xcb_get_property_reply(_ecore_xcb_conn, cookie, NULL);
  if (!reply) return EINA_FALSE;
  if ((reply-format != 32) || (reply-value_len == 0))

 Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c   2011-11-11 
 18:11:10 UTC (rev 65072)
 +++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c   2011-11-11 
 18:51:53 UTC (rev 65073)
 @@ -405,7 +405,7 @@

  cookie =
xcb_get_property_unchecked(_ecore_xcb_conn, 0, win,
 -property, type, 0, LONG_MAX);
 +property, type, 0, UINT_MAX);
  reply = xcb_get_property_reply(_ecore_xcb_conn, cookie, NULL);
  if (!reply) return 0;
  if ((reply-format != size) || (reply-value_len == 0))



I have no problems with these changes, so not trying to start any flame 
wars here !! but I do have a question ... What list are these patches 
being sent to ?? because I did not see these come across the e-dev list, 
and am just wondering if I am missing a list where I should be 
subscribed to.

Cheers,
dh

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

Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_x/xlib



On Fri, 11 Nov 2011, Enlightenment SVN wrote:

 Log:
 Ecore_X: If malloc fails (when trying to get a window property list),
  then return -1 to indicate failure. Add some missing parens in the
  formatting.



 Author:   devilhorns
 Date: 2011-11-11 11:11:35 -0800 (Fri, 11 Nov 2011)
 New Revision: 65074
 Trac: http://trac.enlightenment.org/e/changeset/65074

 Modified:
  trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-11 
 18:51:53 UTC (rev 65073)
 +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-11 
 19:11:35 UTC (rev 65074)
 @@ -118,13 +118,18 @@
   bytes_after, prop_ret) != Success)
  return -1;

 -   if (type_ret != XA_CARDINAL || format_ret != 32)
 +   if ((type_ret != XA_CARDINAL) || (format_ret != 32))
  num = -1;
 -   else if (num_ret == 0 || !prop_ret)
 +   else if ((num_ret == 0) || (!prop_ret))
  num = 0;
else
  {
 val = malloc(num_ret * sizeof(unsigned int));
 +if (!val)
 +  {
 + if (prop_ret) XFree(prop_ret);
 + return -1;
 +  }
 for (i = 0; i  num_ret; i++)
   val[i] = ((unsigned long *)prop_ret)[i];

val is an array of unsigned int. Problem on 64 bits if you use long

Vincent

 num = num_ret;


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



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

Re: [E-devel] E SVN: caro trunk/ecore/src/lib/ecore_x/xcb

On 11/11/11 14:10, Vincent Torri wrote:


 On Fri, 11 Nov 2011, Christopher Michael wrote:

 On 11/11/11 13:51, Enlightenment SVN wrote:
 Log:
 Ecore: Fix warning: large integer implicitly truncated to unsigned type 
 inecore_x/xcb

 xcb_get_property_unchecked() requires an uint32_t as last parameter, so 
 use
 UINT_MAX instead of LONG_MAX

 Patch from OpenBSD via Jonathan Armani


 Author:   caro
 Date: 2011-11-11 10:51:53 -0800 (Fri, 11 Nov 2011)
 New Revision: 65073
 Trac: http://trac.enlightenment.org/e/changeset/65073

 Modified:
 trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c 
 trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c 2011-11-11 18:11:10 UTC 
 (rev 65072)
 +++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_mwm.c 2011-11-11 18:51:53 UTC 
 (rev 65073)
 @@ -63,7 +63,7 @@
   cookie =
 xcb_get_property_unchecked(_ecore_xcb_conn, 0, win,
ECORE_X_ATOM_MOTIF_WM_HINTS,
 -ECORE_X_ATOM_MOTIF_WM_HINTS, 0, LONG_MAX);
 +ECORE_X_ATOM_MOTIF_WM_HINTS, 0, UINT_MAX);
   reply = xcb_get_property_reply(_ecore_xcb_conn, cookie, NULL);
   if (!reply) return EINA_FALSE;
   if ((reply-format != 32) || (reply-value_len == 0))

 Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c 2011-11-11 
 18:11:10 UTC (rev 65072)
 +++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c 2011-11-11 
 18:51:53 UTC (rev 65073)
 @@ -405,7 +405,7 @@

   cookie =
 xcb_get_property_unchecked(_ecore_xcb_conn, 0, win,
 -property, type, 0, LONG_MAX);
 +property, type, 0, UINT_MAX);
   reply = xcb_get_property_reply(_ecore_xcb_conn, cookie, NULL);
   if (!reply) return 0;
   if ((reply-format != size) || (reply-value_len == 0))



 I have no problems with these changes, so not trying to start any flame
 wars here !! but I do have a question ... What list are these patches
 being sent to ?? because I did not see these come across the e-dev list,
 and am just wondering if I am missing a list where I should be
 subscribed to.

 private discussion on #e.fr with OpenBSD guys. it's faster than mail

 Vincent


Fair enough, Thanks for the reply :)

I would request tho, that if you are not around for a 'private 
discussion' with them, that they send the patches to the e-dev mailing 
list so that others may review/commit as some of their patches may have 
to do with other people's work. For instance, I did the xcb port(s) for 
evas/ecore (based on previous work from vtorri) and am interested in any 
patches/fixes that may need to go in simply because I am still 
maintaining it. Granted, this change was incredibly minor (in the grand 
scheme of things), but future changes may not be so I think it would be 
if others could review them also. Again, not trying to start any fights, 
just interested in code changes that may need to be done wrt stuff I've 
worked on ;)

Cheers,
dh



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

Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_x/xlib

On 11/11/11 14:13, Vincent Torri wrote:


 On Fri, 11 Nov 2011, Enlightenment SVN wrote:

 Log:
 Ecore_X: If malloc fails (when trying to get a window property list),
   then return -1 to indicate failure. Add some missing parens in the
   formatting.



 Author:   devilhorns
 Date: 2011-11-11 11:11:35 -0800 (Fri, 11 Nov 2011)
 New Revision: 65074
 Trac: http://trac.enlightenment.org/e/changeset/65074

 Modified:
   trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c   2011-11-11 
 18:51:53 UTC (rev 65073)
 +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c   2011-11-11 
 19:11:35 UTC (rev 65074)
 @@ -118,13 +118,18 @@
bytes_after,prop_ret) != Success)
   return -1;

 -   if (type_ret != XA_CARDINAL || format_ret != 32)
 +   if ((type_ret != XA_CARDINAL) || (format_ret != 32))
   num = -1;
 -   else if (num_ret == 0 || !prop_ret)
 +   else if ((num_ret == 0) || (!prop_ret))
   num = 0;
 else
   {
  val = malloc(num_ret * sizeof(unsigned int));
 +if (!val)
 +  {
 + if (prop_ret) XFree(prop_ret);
 + return -1;
 +  }
  for (i = 0; i  num_ret; i++)
val[i] = ((unsigned long *)prop_ret)[i];

 val is an array of unsigned int. Problem on 64 bits if you use long

 Vincent

Indeed :)

As stated in a different email, I have no problems w/ the patch..good 
catch :)

dh

  num = num_ret;




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

Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_x/xlib

On 11/11/11 14:27, Christopher Michael wrote:
 On 11/11/11 14:13, Vincent Torri wrote:


 On Fri, 11 Nov 2011, Enlightenment SVN wrote:

 Log:
 Ecore_X: If malloc fails (when trying to get a window property list),
then return -1 to indicate failure. Add some missing parens in the
formatting.



 Author:   devilhorns
 Date: 2011-11-11 11:11:35 -0800 (Fri, 11 Nov 2011)
 New Revision: 65074
 Trac: http://trac.enlightenment.org/e/changeset/65074

 Modified:
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c  2011-11-11 
 18:51:53 UTC (rev 65073)
 +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c  2011-11-11 
 19:11:35 UTC (rev 65074)
 @@ -118,13 +118,18 @@
 bytes_after,prop_ret) != Success)
return -1;

 -   if (type_ret != XA_CARDINAL || format_ret != 32)
 +   if ((type_ret != XA_CARDINAL) || (format_ret != 32))
num = -1;
 -   else if (num_ret == 0 || !prop_ret)
 +   else if ((num_ret == 0) || (!prop_ret))
num = 0;
  else
{
   val = malloc(num_ret * sizeof(unsigned int));
 +if (!val)
 +  {
 + if (prop_ret) XFree(prop_ret);
 + return -1;
 +  }
   for (i = 0; i   num_ret; i++)
 val[i] = ((unsigned long *)prop_ret)[i];

 val is an array of unsigned int. Problem on 64 bits if you use long

 Vincent

 Indeed :)

 As stated in a different email, I have no problems w/ the patch..good
 catch :)

 dh

Sorry, wrong reply. I see what you meant now. Fixed in svn ;)

dh

   num = num_ret;


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

Re: [E-devel] About release, snapshots and openBSD port

On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

  Reminds me of some of the stuff I've been saying...
  As for don't have time to do tarballs everyday.. well, that's why
 there's
  something called scripts and cron jobs.. those things exist, might be
  good to use these awesome technologies.

 hooray for your snide comments. wonderful attitude. you were not there on
 irc,
 nor did you even seem to have read the material at hand (the patches).
 seriously, what's up with you?

It wasn't my remarks, it was the remarks from someone who wants to
contribute to the project and who got offended by the way you talked to
him. All I did was point out what I said before in the hopes that you'll
realize that your own attitude is a problem.


 do i suddenly have to be mr. nice to everything? oh wow! how wonderful! so
 awesome that you broke evas's api on your openbsd packages. so great to
 see.
 we'll love hearing the app developers ask us for help about their apps not
 working on openbsd, when we will have zero clue that it was an api/abi
 breakage
 added specifically on openbsd. that's just awesome. please - make more
 patches
 just like that!.

 if its bad, it's bad. reasons were explicitly given for it being bad.


This has nothing to do with the patches, I didn't know there were patches,
I didn't see any patches, and I don't care about them either. My point is
you should learn how to talk to people if you don't want to drive away all
the contributors and end up alone in the project.




 and as for well just use scripts - have to write and test those too. and
 if
 its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT. that
 was
 my point... which you failed to read. if you don't sit down and spend at
 least
 some qa time on the tarballs... then its pointless. this is my point on a
 mental block. i keep hearing it from people omg  svn trunk must be so
 unstable!!! how can i use it? - it's the image that just because its in
 trunk
 (or head/master/whatever) that it must be so unstable and a tarball made
 every
 day is going to be better. it's a RELEASE process of freezing and fixing
 just
 bugs that improves quality... not make dist; scp *.tar.gz 


For you it's no better than a random svn checkout, good, but if they want a
tarball, give them a tarball, as for what if it doesn't build, well it
should always build, noone should even commit anything without testing his
work and making sure it doesn't break anything.. while breakage does
happen, it's not something that happens 10 times a day, and it's still
fine, if a tarball is fucked, then you can always say use the one from
tomorrow.
There is a difference between having a build system do a wget and a build
system do a svn checkout, maybe that's why they need tarballs, so they
prepare their build system and when the release is out, they just change
the URL instead of changing the whole system of downloading the image...
And it's not about svn is unstable mentality, it's about tarballs are
more convenient.
As for the scripts, no you don't have to write and test those, you can say
ok fine, someone write it and we'll put it on the server as a cron job,
if noone does write the script for you, then too bad for them, it's not
your responsability. If you wanted, I would have made the script myself..
we already have a script that creates a svn tarball everyday for aMSN, you
could reuse the same script basically, and I could adapt it to the EFL.
It's the same as svn? yeah, so what? it's better to help them by giving out
the tarball even if it's the same as svn rather than telling them to fuck
off.



if they require tarballs to
test and can't just run svn instead to fetch the source... i don't
 have
   the
time each day to make tarballs when they can just as easily fetch
 from
   svn.
it's the same work on their part. making tarballs is MORE work on
 our
   part.
   
You missed the point, we want to be sure that the final archive will
 be
   ok.
I'm not asking for snapshot on a daily basis, only some rc before the
final archive.
(Wait no project did alpha  rc, right ?)
   
   
   
Note that i discuss also with a Mageia e17 maintainer, and he told
 me
   that
such snapshots will help him too.
   
a snapshot has no more quality than an svn checkout, so other than a
   mental
block thinking svn == totally unstable/unusable and an
 unwillingness to
   use it
because of a mental block, i don't see the point.
   
yeah a mental block, I think you don't want to know how many time I
have to reroll a dist to get all working and how frustating it is.
   
   
a release that has had quality assurance done on it is a different
   matter - but
we arent doing them every day. hell no - not with al the efl trees
 we
   have.
only chance of that is if we stopped having separate

Re: [E-devel] About release, snapshots and openBSD port

Here, I just wrote a script :
http://svn.enlightenment.org/svn/e/trunk/devs/kakaroto/create_tarballs.sh

It defaults to building tarballs for eina eet evas ecore embryo edje efreet
e_dbus eeze (list suggested by Vincent), but you can specify any libs you
want as arguments.
It does the svn export (no .svn dirs) autogens then tars them. I didn't
make it do a make distcheck because that requires a Makefile, which
requires configure to run, which itself will require dependent libraries.
This should be enough for the purposes of providing a simple mechanism (a
tarball) to those who do not want to bother with checking out svn.
If this could go into whatever server as a cron job, and make it dump the
tarballs to a directory somewhere (and let the web server's indexing take
care of listing the files), I think that should be enough.
Jonathan, let me know if that's all you need or if you need something else.
And if Carsten was right and you need a guarantee that those tarballs are
'tested and stable', then let the answer be yes, and let's just assume it
is stable, the code in svn should be stable and we are in feature freeze
already.. also that's what we all use daily so it should be fine.

I hope that helps.
Youness.


On Fri, Nov 11, 2011 at 2:55 PM, Youness Alaoui 
kakar...@kakaroto.homelinux.net wrote:



 On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler 
 ras...@rasterman.comwrote:

 On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

  Reminds me of some of the stuff I've been saying...
  As for don't have time to do tarballs everyday.. well, that's why
 there's
  something called scripts and cron jobs.. those things exist, might
 be
  good to use these awesome technologies.

 hooray for your snide comments. wonderful attitude. you were not there on
 irc,
 nor did you even seem to have read the material at hand (the patches).
 seriously, what's up with you?

 It wasn't my remarks, it was the remarks from someone who wants to
 contribute to the project and who got offended by the way you talked to
 him. All I did was point out what I said before in the hopes that you'll
 realize that your own attitude is a problem.


 do i suddenly have to be mr. nice to everything? oh wow! how wonderful!
 so
 awesome that you broke evas's api on your openbsd packages. so great to
 see.
 we'll love hearing the app developers ask us for help about their apps not
 working on openbsd, when we will have zero clue that it was an api/abi
 breakage
 added specifically on openbsd. that's just awesome. please - make more
 patches
 just like that!.

 if its bad, it's bad. reasons were explicitly given for it being bad.


 This has nothing to do with the patches, I didn't know there were patches,
 I didn't see any patches, and I don't care about them either. My point is
 you should learn how to talk to people if you don't want to drive away all
 the contributors and end up alone in the project.




 and as for well just use scripts - have to write and test those too.
 and if
 its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT.
 that was
 my point... which you failed to read. if you don't sit down and spend at
 least
 some qa time on the tarballs... then its pointless. this is my point on a
 mental block. i keep hearing it from people omg  svn trunk must be so
 unstable!!! how can i use it? - it's the image that just because its in
 trunk
 (or head/master/whatever) that it must be so unstable and a tarball made
 every
 day is going to be better. it's a RELEASE process of freezing and fixing
 just
 bugs that improves quality... not make dist; scp *.tar.gz 


 For you it's no better than a random svn checkout, good, but if they want
 a tarball, give them a tarball, as for what if it doesn't build, well it
 should always build, noone should even commit anything without testing his
 work and making sure it doesn't break anything.. while breakage does
 happen, it's not something that happens 10 times a day, and it's still
 fine, if a tarball is fucked, then you can always say use the one from
 tomorrow.
 There is a difference between having a build system do a wget and a build
 system do a svn checkout, maybe that's why they need tarballs, so they
 prepare their build system and when the release is out, they just change
 the URL instead of changing the whole system of downloading the image...
 And it's not about svn is unstable mentality, it's about tarballs are
 more convenient.
 As for the scripts, no you don't have to write and test those, you can say
 ok fine, someone write it and we'll put it on the server as a cron job,
 if noone does write the script for you, then too bad for them, it's not
 your responsability. If you wanted, I would have made the script myself..
 we already have a script that creates a svn tarball everyday for aMSN, you
 could reuse the same script basically, and I could adapt it to the EFL.
 It's the same as svn? yeah, so what? it's better to help them

Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_x/xlib

2011-11-11 Thread Kim Woelders

On Fri, 11 Nov 2011 20:43:04 +0100, Enlightenment SVN  
no-re...@enlightenment.org wrote:

 Log:
 Ecore_X: Fix array problem for 64-bit (unsigned long vs unsigned int).
   Thanks vtorri ;)

 Author:   devilhorns
 Date: 2011-11-11 11:43:04 -0800 (Fri, 11 Nov 2011)
 New Revision: 65076
 Trac: http://trac.enlightenment.org/e/changeset/65076

 Modified:
   trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-11  
 19:12:36 UTC (rev 65075)
 +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-11  
 19:43:04 UTC (rev 65076)
 @@ -131,7 +131,7 @@
   return -1;
}
  for (i = 0; i  num_ret; i++)
 -  val[i] = ((unsigned long *)prop_ret)[i];
 +  val[i] = ((unsigned int *)prop_ret)[i];
  num = num_ret;
  *plst = val;
   }

This fix is incorrect - man XGetWindowProperty.

... and if it weren't there are four more occurrences of ((unsigned long  
*)prop_ret)[i] in the file.

/Kim

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

Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_x/xlib



On Fri, 11 Nov 2011, Kim Woelders wrote:

 On Fri, 11 Nov 2011 20:43:04 +0100, Enlightenment SVN
 no-re...@enlightenment.org wrote:

 Log:
 Ecore_X: Fix array problem for 64-bit (unsigned long vs unsigned int).
   Thanks vtorri ;)

 Author:   devilhorns
 Date: 2011-11-11 11:43:04 -0800 (Fri, 11 Nov 2011)
 New Revision: 65076
 Trac: http://trac.enlightenment.org/e/changeset/65076

 Modified:
   trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c   2011-11-11
 19:12:36 UTC (rev 65075)
 +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c   2011-11-11
 19:43:04 UTC (rev 65076)
 @@ -131,7 +131,7 @@
   return -1;
}
  for (i = 0; i  num_ret; i++)
 -  val[i] = ((unsigned long *)prop_ret)[i];
 +  val[i] = ((unsigned int *)prop_ret)[i];
  num = num_ret;
  *plst = val;
   }

 This fix is incorrect - man XGetWindowProperty.

then val is wrong

Vincent


 ... and if it weren't there are four more occurrences of ((unsigned long
 *)prop_ret)[i] in the file.

 /Kim

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



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

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib

On 11/11/11 19:54, Enlightenment SVN wrote:
 Log:
 back to unsigned long. code was actually correct as-is.

If that's actually correct, then the 'fix' for the xcb version should be 
reverted also ;)

dh



 Author:   raster
 Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011)
 New Revision: 65082
 Trac: http://trac.enlightenment.org/e/changeset/65082

 Modified:
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-11 
 21:59:02 UTC (rev 65081)
 +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c2011-11-12 
 00:54:22 UTC (rev 65082)
 @@ -131,7 +131,7 @@
return -1;
 }
   for (i = 0; i  num_ret; i++)
 -  val[i] = ((unsigned int *)prop_ret)[i];
 +  val[i] = ((unsigned long *)prop_ret)[i];
   num = num_ret;
   *plst = val;
}



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

Re: [E-devel] About release, snapshots and openBSD port

On Fri, 11 Nov 2011 15:55:46 -0500 Youness Alaoui
kakar...@kakaroto.homelinux.net said:

so you've basically proven my point - it's the same as an svn checkout... and
that script still doesn't upload them, or make any announcement that they have
been created. it's actually less useful than make distc (or distcheck) and much
longer. there is no quality checking there... and which point it's busywork.

 Here, I just wrote a script :
 http://svn.enlightenment.org/svn/e/trunk/devs/kakaroto/create_tarballs.sh
 
 It defaults to building tarballs for eina eet evas ecore embryo edje efreet
 e_dbus eeze (list suggested by Vincent), but you can specify any libs you
 want as arguments.
 It does the svn export (no .svn dirs) autogens then tars them. I didn't
 make it do a make distcheck because that requires a Makefile, which
 requires configure to run, which itself will require dependent libraries.
 This should be enough for the purposes of providing a simple mechanism (a
 tarball) to those who do not want to bother with checking out svn.
 If this could go into whatever server as a cron job, and make it dump the
 tarballs to a directory somewhere (and let the web server's indexing take
 care of listing the files), I think that should be enough.
 Jonathan, let me know if that's all you need or if you need something else.
 And if Carsten was right and you need a guarantee that those tarballs are
 'tested and stable', then let the answer be yes, and let's just assume it
 is stable, the code in svn should be stable and we are in feature freeze
 already.. also that's what we all use daily so it should be fine.
 
 I hope that helps.
 Youness.
 
 
 On Fri, Nov 11, 2011 at 2:55 PM, Youness Alaoui 
 kakar...@kakaroto.homelinux.net wrote:
 
 
 
  On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler
  ras...@rasterman.comwrote:
 
  On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui
  kakar...@kakaroto.homelinux.net said:
 
   Reminds me of some of the stuff I've been saying...
   As for don't have time to do tarballs everyday.. well, that's why
  there's
   something called scripts and cron jobs.. those things exist, might
  be
   good to use these awesome technologies.
 
  hooray for your snide comments. wonderful attitude. you were not there on
  irc,
  nor did you even seem to have read the material at hand (the patches).
  seriously, what's up with you?
 
  It wasn't my remarks, it was the remarks from someone who wants to
  contribute to the project and who got offended by the way you talked to
  him. All I did was point out what I said before in the hopes that you'll
  realize that your own attitude is a problem.
 
 
  do i suddenly have to be mr. nice to everything? oh wow! how wonderful!
  so
  awesome that you broke evas's api on your openbsd packages. so great to
  see.
  we'll love hearing the app developers ask us for help about their apps not
  working on openbsd, when we will have zero clue that it was an api/abi
  breakage
  added specifically on openbsd. that's just awesome. please - make more
  patches
  just like that!.
 
  if its bad, it's bad. reasons were explicitly given for it being bad.
 
 
  This has nothing to do with the patches, I didn't know there were patches,
  I didn't see any patches, and I don't care about them either. My point is
  you should learn how to talk to people if you don't want to drive away all
  the contributors and end up alone in the project.
 
 
 
 
  and as for well just use scripts - have to write and test those too.
  and if
  its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT.
  that was
  my point... which you failed to read. if you don't sit down and spend at
  least
  some qa time on the tarballs... then its pointless. this is my point on a
  mental block. i keep hearing it from people omg  svn trunk must be so
  unstable!!! how can i use it? - it's the image that just because its in
  trunk
  (or head/master/whatever) that it must be so unstable and a tarball made
  every
  day is going to be better. it's a RELEASE process of freezing and fixing
  just
  bugs that improves quality... not make dist; scp *.tar.gz 
 
 
  For you it's no better than a random svn checkout, good, but if they want
  a tarball, give them a tarball, as for what if it doesn't build, well it
  should always build, noone should even commit anything without testing his
  work and making sure it doesn't break anything.. while breakage does
  happen, it's not something that happens 10 times a day, and it's still
  fine, if a tarball is fucked, then you can always say use the one from
  tomorrow.
  There is a difference between having a build system do a wget and a build
  system do a svn checkout, maybe that's why they need tarballs, so they
  prepare their build system and when the release is out, they just change
  the URL instead of changing the whole system of downloading the image...
  And it's not about svn is unstable mentality, it's about tarballs are
  more convenient.

Re: [E-devel] About release, snapshots and openBSD port

On Fri, 11 Nov 2011 14:55:14 -0500 Youness Alaoui
kakar...@kakaroto.homelinux.net said:

 On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler
 ras...@rasterman.comwrote:
 
  On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui
  kakar...@kakaroto.homelinux.net said:
 
   Reminds me of some of the stuff I've been saying...
   As for don't have time to do tarballs everyday.. well, that's why
  there's
   something called scripts and cron jobs.. those things exist, might be
   good to use these awesome technologies.
 
  hooray for your snide comments. wonderful attitude. you were not there on
  irc,
  nor did you even seem to have read the material at hand (the patches).
  seriously, what's up with you?
 
 It wasn't my remarks, it was the remarks from someone who wants to

reminds me... wasn't?

 contribute to the project and who got offended by the way you talked to
 him. All I did was point out what I said before in the hopes that you'll
 realize that your own attitude is a problem.

maybe you should read this:

http://www.enlightenment.org/~raster/e.fr.txt

whatever. i was asked to review - i was talking to vtorri about the patches and
going eh? wtf? why did they change api? that's really bad! why do all this
work to disable chained_mempool?... armani turned up and got offended at me
having ... oh dear.. a negative opinion of the patches... gasp. shock. horror.
how dare someone think negatively of them~ yes. everyone is a hero and everyone
is #1. no one can ever do anything bad/wrong. we must praise everyone at all
times.

if you actually READ the exchange my comments boiled down to:
* evaluating patches with some level of bewilderment at many of them.
* expressing exasperation that these patches were being used for openbsd builds
and breaking api without talking to us - wishing they'd come and discuss.
remember this is the FIRST i saw of these patches when vincent pointed me to
them to have a look/review.
* saying that tarballs and svn checkouts are the same and you have to invest
time to make tarballs, test, make announcements etc. to raise the quality and
that isn't appreciably better than an svn checkout.
* saying that i was still at work, busy and i have no time and then being given
the well i'm a cto and you have a haughty tone lines. if anything i should be
offended at someone pretty much not caring that i'm busy and pulling the  well
i'm busy too line implying that it's irrelevant and i should just do as
requested.

of course without any knowledge of the conversation you are instantly deciding
i'm going off and saying things i didn't. i didn't say anything like you are a
bunch of useless people or you'll never get those patches right - give up. i
gave a frank and direct evaluation without sugarcoating. people who cannot
handle that are going to have trouble in every FOSS project out there. the
patch evaluations from them are pretty much the same as what i did.

  do i suddenly have to be mr. nice to everything? oh wow! how wonderful! so
  awesome that you broke evas's api on your openbsd packages. so great to
  see.
  we'll love hearing the app developers ask us for help about their apps not
  working on openbsd, when we will have zero clue that it was an api/abi
  breakage
  added specifically on openbsd. that's just awesome. please - make more
  patches
  just like that!.
 
  if its bad, it's bad. reasons were explicitly given for it being bad.
 
 
 This has nothing to do with the patches, I didn't know there were patches,
 I didn't see any patches, and I don't care about them either. My point is
 you should learn how to talk to people if you don't want to drive away all
 the contributors and end up alone in the project.

you need to learn to actually understand the topic before spouting your
opinions. you were not there for the conversation. for your reference i linked
to it above. you didn't see the patches being reviewed so again - how can you
comment? how can you know that the review was justified based on the content?

  and as for well just use scripts - have to write and test those too. and
  if
  its just a cron job... then its NO BETTER THAN A RANDOM SVN CHECKOUT. that
  was
  my point... which you failed to read. if you don't sit down and spend at
  least
  some qa time on the tarballs... then its pointless. this is my point on a
  mental block. i keep hearing it from people omg  svn trunk must be so
  unstable!!! how can i use it? - it's the image that just because its in
  trunk
  (or head/master/whatever) that it must be so unstable and a tarball made
  every
  day is going to be better. it's a RELEASE process of freezing and fixing
  just
  bugs that improves quality... not make dist; scp *.tar.gz 
 
 
 For you it's no better than a random svn checkout, good, but if they want a
 tarball, give them a tarball, as for what if it doesn't build, well it
 should always build, noone should even commit anything without testing his
 work and making sure it doesn't break anything.. while

Re: [E-devel] E SVN: devilhorns trunk/ecore/src/lib/ecore_x/xlib

On Fri, 11 Nov 2011 22:23:35 +0100 (CET) Vincent Torri vto...@univ-evry.fr
said:

 
 
 On Fri, 11 Nov 2011, Kim Woelders wrote:
 
  On Fri, 11 Nov 2011 20:43:04 +0100, Enlightenment SVN
  no-re...@enlightenment.org wrote:
 
  Log:
  Ecore_X: Fix array problem for 64-bit (unsigned long vs unsigned int).
Thanks vtorri ;)
 
  Author:   devilhorns
  Date: 2011-11-11 11:43:04 -0800 (Fri, 11 Nov 2011)
  New Revision: 65076
  Trac: http://trac.enlightenment.org/e/changeset/65076
 
  Modified:
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 
  Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
  ===
  --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
  2011-11-11 19:12:36 UTC (rev 65075)
  +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
  2011-11-11 19:43:04 UTC (rev 65076)
  @@ -131,7 +131,7 @@
return -1;
 }
   for (i = 0; i  num_ret; i++)
  -  val[i] = ((unsigned long *)prop_ret)[i];
  +  val[i] = ((unsigned int *)prop_ret)[i];
   num = num_ret;
   *plst = val;
}
 
  This fix is incorrect - man XGetWindowProperty.
 
 then val is wrong

no it's not. leave it alone. leave it as it was. it was that way because longs
tend to change between 32 and 64bits. ints tend to stay 32bits. yes we can have
arguments over some architectures where int variest between 16 and 32bits, and
some where long is always 32bits. reality is that on the architectures we work
on/support (linux/the vast majority of unixes/mingw32 etc) int == 32bit, long
== 32/64 bit. X11 protocol specifies that the 32bit cardinal IS 32bits. its not
related to size of long. xlib used long because way back in those horrible
1980's sometimes ints were 16bit and thus you lost half your bits...

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib

On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michael cpmicha...@comcast.net
said:

 On 11/11/11 19:54, Enlightenment SVN wrote:
  Log:
  back to unsigned long. code was actually correct as-is.
 
 If that's actually correct, then the 'fix' for the xcb version should be 
 reverted also ;)

yeah  found it. fixed. :) thanks for reminding

fyi - notice that even with those changes.. a whole bunch of other funcs in the
same file were still using unsigned long * so the code was inconsistently
changed too... which is bad :)

 dh
 
 
 
  Author:   raster
  Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011)
  New Revision: 65082
  Trac: http://trac.enlightenment.org/e/changeset/65082
 
  Modified:
 trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 
  Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
  ===
  --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
  2011-11-11 21:59:02 UTC (rev 65081) +++
  trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c  2011-11-12
  00:54:22 UTC (rev 65082) @@ -131,7 +131,7 @@ return -1;
  }
for (i = 0; i  num_ret; i++)
  -  val[i] = ((unsigned int *)prop_ret)[i];
  +  val[i] = ((unsigned long *)prop_ret)[i];
num = num_ret;
*plst = val;
 }
 
 
 
 --
 RSA(R) Conference 2012
 Save $700 by Nov 18
 Register now
 http://p.sf.net/sfu/rsa-sfdev2dev1
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xcb

On 11/11/11 20:40, Enlightenment SVN wrote:
 Log:
 also revert long -  int change in xcb



 Author:   raster
 Date: 2011-11-11 17:40:51 -0800 (Fri, 11 Nov 2011)
 New Revision: 65083
 Trac: http://trac.enlightenment.org/e/changeset/65083

 Modified:
trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_window_prop.c


Thanks mate ;)

Cheers,
dh


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

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib

On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote:
 On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michaelcpmicha...@comcast.net
 said:

 On 11/11/11 19:54, Enlightenment SVN wrote:
 Log:
 back to unsigned long. code was actually correct as-is.

 If that's actually correct, then the 'fix' for the xcb version should be
 reverted also ;)

 yeah  found it. fixed. :) thanks for reminding

No worries. Thanks for the fix ;)

 fyi - notice that even with those changes.. a whole bunch of other funcs in 
 the
 same file were still using unsigned long * so the code was inconsistently
 changed too... which is bad :)

Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd 
patch). No worries tho, it's straightened out now ;)

dh

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

[E-devel] eyesight configure error

2011-11-11 Thread Tomas Cech


Hi,

I met this issue during building eyesight (search for GlobalParams.h):

+ ./configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu 
--program-prefix= --prefix=/usr --exec-prefix=/u sr --bindir=/usr/bin 
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
--includedir=/usr/include --libdir=/usr/lib64 - -libexecdir=/usr/lib 
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man 
--infodir=/usr/share/info --disable -static --with-pdf-backend=poppler
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for x86_64-unknown-linux-gnu-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no

checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld
checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld...  yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands +=... yes
checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r
checking for x86_64-unknown-linux-gnu-objdump... no
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for x86_64-unknown-linux-gnu-ar... no
checking for ar... ar
checking for x86_64-unknown-linux-gnu-strip... no
checking for strip... strip
checking for x86_64-unknown-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m
elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether mupdf CJK fonts are enabled... 
checking whether to build eyesight binary... yes

checking for x86_64-unknown-linux-gnu-gcc... gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
checking for x86_64-unknown-linux-gnu-g++... no
checking for x86_64-unknown-linux-gnu-c++... no
checking for x86_64-unknown-linux-gnu-gpp... no
checking for x86_64-unknown-linux-gnu-aCC... no
checking for x86_64-unknown-linux-gnu-CC... no
checking for x86_64-unknown-linux-gnu-cxx... no
checking for x86_64-unknown-linux-gnu-cc++... no
checking for x86_64-unknown-linux-gnu-cl.exe... no
checking for x86_64-unknown-linux-gnu-FCC... no
checking for x86_64-unknown-linux-gnu-KCC... no
checking for x86_64-unknown-linux-gnu-RCC... no
checking for x86_64-unknown-linux-gnu-xlC_r... no
checking for x86_64-unknown-linux-gnu-xlC... no
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no

Re: [E-devel] eyesight configure error

On 11/11/11 21:04, Tomas Cech wrote:
 Hi,

 I met this issue during building eyesight (search for GlobalParams.h):

 + ./configure --host=x86_64-unknown-linux-gnu
 --build=x86_64-unknown-linux-gnu --program-prefix= --prefix=/usr
 --exec-prefix=/u sr --bindir=/usr/bin --sbindir=/usr/sbin
 --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
 --libdir=/usr/lib64 - -libexecdir=/usr/lib --localstatedir=/var
 --sharedstatedir=/usr/com --mandir=/usr/share/man
 --infodir=/usr/share/info --disable -static --with-pdf-backend=poppler
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for style of include used by make... GNU
 checking for x86_64-unknown-linux-gnu-gcc... no
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables... checking whether we are cross
 compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... gcc3
 checking for a sed that does not truncate output... /usr/bin/sed
 checking for grep that handles long lines and -e... /usr/bin/grep
 checking for egrep... /usr/bin/grep -E
 checking for fgrep... /usr/bin/grep -F
 checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld
 checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes
 checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
 checking the name lister (/usr/bin/nm -B) interface... BSD nm
 checking whether ln -s works... yes
 checking the maximum length of command line arguments... 1572864
 checking whether the shell understands some XSI constructs... yes
 checking whether the shell understands +=... yes
 checking for /usr/x86_64-suse-linux/bin/ld option to reload object
 files... -r
 checking for x86_64-unknown-linux-gnu-objdump... no
 checking for objdump... objdump
 checking how to recognize dependent libraries... pass_all
 checking for x86_64-unknown-linux-gnu-ar... no
 checking for ar... ar
 checking for x86_64-unknown-linux-gnu-strip... no
 checking for strip... strip
 checking for x86_64-unknown-linux-gnu-ranlib... no
 checking for ranlib... ranlib
 checking command to parse /usr/bin/nm -B output from gcc object... ok
 checking how to run the C preprocessor... gcc -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking for dlfcn.h... yes
 checking for objdir... .libs
 checking if gcc supports -fno-rtti -fno-exceptions... no
 checking for gcc option to produce PIC... -fPIC -DPIC
 checking if gcc PIC flag -fPIC -DPIC works... yes
 checking if gcc static flag -static works... yes
 checking if gcc supports -c -o file.o... yes
 checking if gcc supports -c -o file.o... (cached) yes
 checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m
 elf_x86_64) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... no
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... no
 checking whether mupdf CJK fonts are enabled... checking whether to
 build eyesight binary... yes
 checking for x86_64-unknown-linux-gnu-gcc... gcc
 checking whether we are using the GNU C compiler... (cached) yes
 checking whether gcc accepts -g... (cached) yes
 checking for gcc option to accept ISO C89... (cached) none needed
 checking dependency style of gcc... (cached) gcc3
 checking how to run the C preprocessor... gcc -E
 checking for x86_64-unknown-linux-gnu-g++... no
 checking for x86_64-unknown-linux-gnu-c++... no
 checking for x86_64-unknown-linux-gnu-gpp... no
 checking for x86_64-unknown-linux-gnu-aCC... no
 checking for x86_64-unknown-linux-gnu-CC... no
 checking for x86_64-unknown-linux-gnu-cxx... no
 checking for x86_64-unknown-linux-gnu-cc++... no
 checking for x86_64-unknown-linux-gnu-cl.exe... no
 checking for x86_64-unknown-linux-gnu-FCC... no
 checking for x86_64-unknown-linux-gnu-KCC... no
 checking for x86_64-unknown-linux-gnu-RCC... no
 checking for x86_64-unknown-linux-gnu-xlC_r... no
 checking for

Re: [E-devel] E SVN: onefang trunk/edje/src/lib

2011-11-11 Thread Thomas Gstädtner

On Fr 11 Nov 2011 22:32:15 CET, Enlightenment SVN wrote:
 Log:
 Add some inheritance.
   

 Author:   onefang
 Date: 2011-11-11 13:32:15 -0800 (Fri, 11 Nov 2011)
 New Revision: 65079
 Trac: http://trac.enlightenment.org/e/changeset/65079

 Modified:
   trunk/edje/src/lib/edje_lua2.c 

 Modified: trunk/edje/src/lib/edje_lua2.c
 ===
 --- trunk/edje/src/lib/edje_lua2.c2011-11-11 20:55:07 UTC (rev 65078)
 +++ trunk/edje/src/lib/edje_lua2.c2011-11-11 21:32:15 UTC (rev 65079)
 @@ -192,8 +192,10 @@
  // // LATER: box and table calls
  // // LATER: perspective stuff change
  //
 -static const char *_elua_meta_edje = meta_edje;
 -static const struct luaL_reg _elua_edje_api [] =
 +
 +static const char *_elua_edje_api = edje;
 +static const char *_elua_edje_meta = edje_meta;
 +static const struct luaL_reg _elua_edje_funcs [] =
  {
 // add an echo too to make it more shelly
   {echo, _elua_echo}, // test func - echo (i know we have 
 print. test)
 @@ -236,8 +238,9 @@
   {NULL, NULL} // end
  };
  
 -static const char *_elua_meta_evas = meta_evas;
 -static const struct luaL_reg _elua_edje_evas_obj [] =
 +static const char *_elua_evas_api = evas;
 +static const char *_elua_evas_meta = evas_meta;
 +static const struct luaL_reg _elua_evas_funcs [] =
  {
 // generic object methods
   {del,  _elua_obj_del}, // generic del any object created for 
 edje (evas objects, timers, animators, transitions... everything)
 @@ -269,28 +272,6 @@
  
  // {color_class,  _elua_object_color_class}, // get or set object 
 color class
  
 -
 -   // FIXME: make these into a subclass of this evas table using meta table 
 magic.
 -   // text object specific
 - {font, _elua_text_font}, // get or set text font
 - {text, _elua_text_text}, // get or set text
 -// {text_class, _elua_object_text_class}, // get or set object text 
 class
 -
 -   // image object specific
 - {image,_elua_image_image},  // get or set image
 - {fill, _elua_image_fill},   // get or set the fill parameters
 - {filled,   _elua_image_filled}, // get or set the filled state 
 (overrides fill())
 -
 -   // edje object specific
 - {file, _elua_edje_file}, // get or set edje file and group
 -
 -   // line object specific
 - {xy, _elua_line_xy}, // get or set line coords
 -
 -   // polygon object specific
 - {point, _elua_polygon_point}, // add a polygon point
 - {clear, _elua_polygon_clear}, // clear all polygon points
 -
 // FIXME: set callbacks (mouse down, up, blah blah blah)
 //
 // FIXME: set scale (explicit value)
 @@ -307,9 +288,45 @@
   {NULL, NULL} // end
  };
  
 -static const char *_elua_meta_map = meta_map;
 -static const struct luaL_reg _elua_evas_map_obj [] =
 +static const char *_elua_evas_edje_api = evas_edje;
 +static const char *_elua_evas_edje_meta = evas_edje_meta;
 +static const char *_elua_evas_edje_parent = evas_edje_parent;
 +static const struct luaL_reg _elua_evas_edje_funcs [] =
  {
 +   // edje object specific
 + {file, _elua_edje_file}, // get or set edje file and group
 +
 + {NULL, NULL} // end
 +};
 +
 +static const char *_elua_evas_image_api = evas_image;
 +static const char *_elua_evas_image_meta = evas_image_meta;
 +static const char *_elua_evas_image_parent = evas_image_parent;
 +static const struct luaL_reg _elua_evas_image_funcs [] =
 +{
 +   // image object specific
 + {image,_elua_image_image},  // get or set image
 + {fill, _elua_image_fill},   // get or set the fill parameters
 + {filled,   _elua_image_filled}, // get or set the filled state 
 (overrides fill())
 +
 + {NULL, NULL} // end
 +};
 +
 +static const char *_elua_evas_line_api = evas_line;
 +static const char *_elua_evas_line_meta = vas_line_meta;
 +static const char *_elua_evas_line_parent = evas_line_parent;
 +static const struct luaL_reg _elua_evas_line_funcs [] =
 +{
 +   // line object specific
 + {xy, _elua_line_xy}, // get or set line coords
 +
 + {NULL, NULL} // end
 +};
 +
 +static const char *_elua_evas_map_api = ewas_map;
 +static const char *_elua_evas_map_meta = evas_map_meta;
 +static const struct luaL_reg _elua_evas_map_funcs [] =
 +{
   {alpha, _elua_map_alpha},
  // {dup,   _elua_map_dup},  // not sure of proper api for this.
   {clockwise, _elua_map_clockwise},
 @@ -328,8 +345,33 @@
   {NULL, NULL} // end
  };
  
 -static const struct luaL_reg _elua_edje_meta [] =
 +static const char *_elua_evas_polygon_api = evas_polygon;
 +static const char *_elua_evas_polygon_meta = evas_polygon_meta;
 +static const char *_elua_evas_polygon_parent = evas_polygon_parent;
 +static const struct luaL_reg _elua_evas_polygon_funcs [] =
  {
 +   // polygon object specific
 + {point, _elua_polygon_point}, // add a

Re: [E-devel] E SVN: onefang trunk/edje/src/lib

On Sat, 12 Nov 2011 02:49:44 +0100 Thomas Gstädtner
tho...@gstaedtner.net wrote:

 On Fr 11 Nov 2011 22:32:15 CET, Enlightenment SVN wrote:
  Log:
  Add some inheritance.

 
  Author:   onefang
  Date: 2011-11-11 13:32:15 -0800 (Fri, 11 Nov 2011)
  New Revision: 65079
  Trac: http://trac.enlightenment.org/e/changeset/65079
 
  Modified:
trunk/edje/src/lib/edje_lua2.c 

snipping, don't need the entire damn diff

 02:39  Hawkwind Just did a fresh checkout of E, and getting this 
 error when using easy_e17.sh: http://pastebin.com/nfAyd5p6
 
 I think that should have been EINA_TRUE and EINA_FALSE instead of
 TRUE and FALSE

Yep, knew I forgot something.  And just after another commit.  Patching
that up now.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eyesight configure error

2011-11-11 Thread Tomas Cech


On Fri, Nov 11, 2011 at 09:10:49PM -0500, Christopher Michael wrote:

On 11/11/11 21:04, Tomas Cech wrote:
 configure: WARNING: Xpdf headers not found. Verify that poppler is
 configured with the option --enable-xpdf-headers
 checking whether to enable PDF module built... no

Perhaps this offers a clue ?? ;)



Nope. I use same package on my system and configure works. It is
probably dependency issue, but not Xpdf headers.

Best regards,

Tomas Cech
L3


pgp73m7k4dXef.pgp
Description: PGP signature
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] About release, snapshots and openBSD port

On Fri, Nov 11, 2011 at 8:37 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Fri, 11 Nov 2011 14:55:14 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

  On Fri, Nov 11, 2011 at 12:42 PM, Carsten Haitzler
  ras...@rasterman.comwrote:
 
   On Fri, 11 Nov 2011 11:47:32 -0500 Youness Alaoui
   kakar...@kakaroto.homelinux.net said:
  
Reminds me of some of the stuff I've been saying...
As for don't have time to do tarballs everyday.. well, that's why
   there's
something called scripts and cron jobs.. those things exist,
 might be
good to use these awesome technologies.
  
   hooray for your snide comments. wonderful attitude. you were not there
 on
   irc,
   nor did you even seem to have read the material at hand (the patches).
   seriously, what's up with you?
  
  It wasn't my remarks, it was the remarks from someone who wants to

 reminds me... wasn't?

reminds me was about a different thread that I suppose (hope) you
remember, which correlates what this guy's opinion was.


  contribute to the project and who got offended by the way you talked to
  him. All I did was point out what I said before in the hopes that you'll
  realize that your own attitude is a problem.

 maybe you should read this:

 http://www.enlightenment.org/~raster/e.fr.txt

 whatever. i was asked to review - i was talking to vtorri about the
 patches and
 going eh? wtf? why did they change api? that's really bad! why do all this
 work to disable chained_mempool?... armani turned up and got offended at
 me
 having ... oh dear.. a negative opinion of the patches... gasp. shock.
 horror.
 how dare someone think negatively of them~ yes. everyone is a hero and
 everyone
 is #1. no one can ever do anything bad/wrong. we must praise everyone at
 all
 times.

I don't need to read that (and I have better things to do than fight an
endless war on who is right).
And again, it's not about your criticism of the patches, it's about the way
you say it. I don't know how you said it, but in the end, the contributor
was offended, and my point was that the way you said it offends people.



 if you actually READ the exchange my comments boiled down to:
 * evaluating patches with some level of bewilderment at many of them.
 * expressing exasperation that these patches were being used for openbsd
 builds
 and breaking api without talking to us - wishing they'd come and discuss.
 remember this is the FIRST i saw of these patches when vincent pointed me
 to
 them to have a look/review.
 * saying that tarballs and svn checkouts are the same and you have to
 invest
 time to make tarballs, test, make announcements etc. to raise the quality
 and
 that isn't appreciably better than an svn checkout.
 * saying that i was still at work, busy and i have no time and then being
 given
 the well i'm a cto and you have a haughty tone lines. if anything i
 should be
 offended at someone pretty much not caring that i'm busy and pulling the
  well
 i'm busy too line implying that it's irrelevant and i should just do as
 requested.

 of course without any knowledge of the conversation you are instantly
 deciding
 i'm going off and saying things i didn't. i didn't say anything like you
 are a
 bunch of useless people or you'll never get those patches right - give
 up. i
 gave a frank and direct evaluation without sugarcoating. people who cannot
 handle that are going to have trouble in every FOSS project out there. the
 patch evaluations from them are pretty much the same as what i did.

It doesn't matter if your comments were right or not, the way you say them
is bad, that's all I'm saying, and I'm not the only one saying that.




   do i suddenly have to be mr. nice to everything? oh wow! how
 wonderful! so
   awesome that you broke evas's api on your openbsd packages. so great to
   see.
   we'll love hearing the app developers ask us for help about their apps
 not
   working on openbsd, when we will have zero clue that it was an api/abi
   breakage
   added specifically on openbsd. that's just awesome. please - make more
   patches
   just like that!.
  
   if its bad, it's bad. reasons were explicitly given for it being bad.
  
 
  This has nothing to do with the patches, I didn't know there were
 patches,
  I didn't see any patches, and I don't care about them either. My point is
  you should learn how to talk to people if you don't want to drive away
 all
  the contributors and end up alone in the project.

 you need to learn to actually understand the topic before spouting your
 opinions. you were not there for the conversation. for your reference i
 linked
 to it above. you didn't see the patches being reviewed so again - how can
 you
 comment? how can you know that the review was justified based on the
 content?

Again, nothing to do with the review, the end result is what I commented
on, the guy was pissed/annoyed/offended/whatever, and that is the end
result that I'm talking about. Whether your comments were justified or not

[E-devel] [PATCH] eyesight: add gradient.png to sources

2011-11-11 Thread Tomas Cech

Add gradient.png to eyesight_SOURCES so it will be in the tarball result
of make dist-bzip2.
---
 PROTO/eyesight/src/bin/Makefile.am |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/PROTO/eyesight/src/bin/Makefile.am 
b/PROTO/eyesight/src/bin/Makefile.am
index 174d3a7..fb32ab0 100644
--- a/PROTO/eyesight/src/bin/Makefile.am
+++ b/PROTO/eyesight/src/bin/Makefile.am
@@ -20,7 +20,7 @@ bin_PROGRAMS += eyesight
 
 endif
 
-eyesight_SOURCES = eyesight.c eyesight_popup.c eyesight_popup.h
+eyesight_SOURCES = eyesight.c eyesight_popup.c eyesight_popup.h gradient.png
 
 eyesight_LDADD = @EYESIGHT_BIN_LIBS@ $(top_builddir)/src/lib/libeyesight.la
 
-- 
1.7.7


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

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib

On Fri, 11 Nov 2011 21:00:23 -0500 Christopher Michael cpmicha...@comcast.net
said:

 On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote:
  On Fri, 11 Nov 2011 20:08:09 -0500 Christopher
  Michaelcpmicha...@comcast.net said:
 
  On 11/11/11 19:54, Enlightenment SVN wrote:
  Log:
  back to unsigned long. code was actually correct as-is.
 
  If that's actually correct, then the 'fix' for the xcb version should be
  reverted also ;)
 
  yeah  found it. fixed. :) thanks for reminding
 
 No worries. Thanks for the fix ;)
 
  fyi - notice that even with those changes.. a whole bunch of other funcs in
  the same file were still using unsigned long * so the code was
  inconsistently changed too... which is bad :)
 
 Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd 
 patch). No worries tho, it's straightened out now ;)

oh sure - originally. i'm just pointing out that it was that way for a
reason :) much more code followed the same pattern. if you change 1 instance
of a pattern... you need to be sure you really do NEED to change it. you
didn't do it - just pointing it out to those watching :)

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] About release, snapshots and openBSD port

On Fri, 11 Nov 2011 21:43:37 -0500 Youness Alaoui
kakar...@kakaroto.homelinux.net said:

 I don't need to read that (and I have better things to do than fight an
 endless war on who is right).

then this ends this topic. if you don't want to look at the facts, there is no
point in this discussion. there is nothing to talk about with you.

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib

On Fri, 11 Nov 2011 22:28:44 -0500 Christopher Michael cpmicha...@comcast.net
said:

 On 11/11/11 21:49, Carsten Haitzler (The Rasterman) wrote:
  On Fri, 11 Nov 2011 21:00:23 -0500 Christopher
  Michaelcpmicha...@comcast.net said:
 
  On 11/11/11 20:42, Carsten Haitzler (The Rasterman) wrote:
  On Fri, 11 Nov 2011 20:08:09 -0500 Christopher
  Michaelcpmicha...@comcast.net  said:
 
  On 11/11/11 19:54, Enlightenment SVN wrote:
  Log:
  back to unsigned long. code was actually correct as-is.
 
  If that's actually correct, then the 'fix' for the xcb version should be
  reverted also ;)
 
  yeah  found it. fixed. :) thanks for reminding
 
  No worries. Thanks for the fix ;)
 
  fyi - notice that even with those changes.. a whole bunch of other funcs
  in the same file were still using unsigned long * so the code was
  inconsistently changed too... which is bad :)
 
  Indeed. Was a patch from *bsd people (see commit from vtorri wrt bsd
  patch). No worries tho, it's straightened out now ;)
 
  oh sure - originally. i'm just pointing out that it was that way for a
  reason :) much more code followed the same pattern. if you change 1 instance
  of a pattern... you need to be sure you really do NEED to change it. you
  didn't do it - just pointing it out to those watching :)
 
 
 No worries, thanks for keeping an eye out ;) After quite a few years of 
 efl/e development, I've actually managed to grow that 'thick skin' we 
 used to talk about ;) so not taking it personally :)

hu... porkrinds.


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


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

Re: [E-devel] EFL 1.1 freeze

On Sat, 12 Nov 2011 04:27:16 +1000 David Seikel onef...@gmail.com
wrote:

 On Thu, 3 Nov 2011 17:27:55 +0900 Carsten Haitzler (The Rasterman)
 ras...@rasterman.com wrote:
 
  On Thu, 3 Nov 2011 18:15:35 +1000 David Seikel onef...@gmail.com
  said:
  
   On Thu, 03 Nov 2011 03:01:17 -0400 Christopher Michael
   cpmicha...@comcast.net wrote:
   
On 11/02/11 22:42, David Seikel wrote:
 On Thu, 3 Nov 2011 08:49:46 +0900 Carsten Haitzler (The
 Rasterman) ras...@rasterman.com  wrote:

 On Wed, 2 Nov 2011 12:14:07 -0400 Mike Blumenkrantz
 m...@zentific.com  said:

 Hi,

 It has been two weeks since the git 'er done mail from
 raster, so I am calling his bluff. Effective immediately, we
 are in a 2 week feature freeze for EFL 1.1.

 no - freeze starts monday :) from my original mail:

 merge window starts next monday (24th of october). that
 means from the 7th to the 20th no new features can be added
 to trunk, only bug fixes.

 so people have until sunday night...

 So I have until Sunday to badger raster into just letting me
 commit the new edje lua stuff?  It would really help me a lot
 if what I have done so far is in the next release.  That
 includes the basic text object support I did last night,

approved.. Slip it in onefang ;)
   
   Hey wait, you are not listed as one of the edje authors.  So that
   don't count.  :-P
  
  lets talk this weekend.
 
 Making sure that lua images only come from within the same file, or
 even looking for images in edje files, looks a bit tricky to me.  I'm
 hoping someone with more edje experience than me can at least show me
 the way.
 
 At the moment it looks like there is a whole bunch of private code
 that edje_calc.c has to do it.  Don't like duplicating that much
 code.  Not to mention that it seems to deal with stuff I don't have.
 
 My next task is to properly subclass the evas metatable stuff for
 images, text, etc.  Then implement that argument parsing and returning
 thing I have a FIXME for in the source.  No API changes, just making
 it all neater internally.

Done and done.

 After those two I want to make a bunch of macros for taking care of
 the boilerplate.  That will make future API (after the freeze)
 additions much easier.

Part done.

 I think that's all that's needed for the edje lua freeze.

Sleep now.  zz

Wake me if I broke SVN again.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

2011-11-11 Thread ChunEon Park

It's silly to say, but it's twice mistake.

-Regards, Hermet-
 
-Original Message-
From: Enlightenment SVNlt;no-re...@enlightenment.orggt; 
To: enlightenment-...@lists.sourceforge.net
Cc: 
Sent: 11-11-12(토) 01:47:05
Subject: E SVN: hermet trunk/elementary/src/bin
Log:
 elementary/test_map.c - Those test code should not be committed.
 
 maybe raster you. 
 
 
Author: hermet
Date: 2011-11-11 08:47:05 -0800 (Fri, 11 Nov 2011)
New Revision: 65071
Trac: http://trac.enlightenment.org/e/changeset/65071
Modified:
 trunk/elementary/src/bin/test_map.c 
Modified: trunk/elementary/src/bin/test_map.c
===
--- trunk/elementary/src/bin/test_map.c 2011-11-11 16:34:14 UTC (rev 65070)
+++ trunk/elementary/src/bin/test_map.c 2011-11-11 16:47:05 UTC (rev 65071)
@@ -711,7 +711,7 @@
 void
 test_map(void *data __UNUSED__, Evas_Object *obj __UNUSED__, void *event_info 
__UNUSED__)
 {
- Evas_Object *win, *bg, *map, *tab, *r, *en;
+ Evas_Object *win, *bg, *map;
 int idx = 0;
 
 win = elm_win_add(NULL, map, ELM_WIN_BASIC);
@@ -723,19 +723,6 @@
 elm_win_resize_object_add(win, bg);
 evas_object_show(bg);
 
- tab = elm_table_add(win);
- evas_object_size_hint_weight_set(tab, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
- elm_win_resize_object_add(win, tab);
- evas_object_show(tab);
-
- r = evas_object_rectangle_add(evas_object_evas_get(win));
- evas_object_color_set(r, 20, 40, 60, 255);
- evas_object_size_hint_min_set(r, 200, 200);
- evas_object_size_hint_weight_set(r, EVAS_HINT_EXPAND, 0);
- evas_object_size_hint_fill_set(r, EVAS_HINT_FILL, EVAS_HINT_FILL);
- elm_table_pack(tab, r, 0, 0, 1, 1);
- evas_object_show(r);
- 
 map = elm_map_add(win);
 if (map)
 {
@@ -749,9 +736,7 @@
 printf(]\n);
 
 evas_object_size_hint_weight_set(map, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
- evas_object_size_hint_fill_set(map, EVAS_HINT_FILL, EVAS_HINT_FILL);
- elm_table_pack(tab, map, 0, 2, 1, 1);
-// elm_win_resize_object_add(win, map);
+ elm_win_resize_object_add(win, map);
 evas_object_data_set(map, window, win);
 
 //
@@ -842,14 +827,6 @@
 
 evas_object_show(map);
 }
- en = elm_entry_add(win);
- elm_entry_scrollable_set(en, EINA_TRUE);
- elm_entry_single_line_set(en, 1);
- evas_object_size_hint_weight_set(en, EVAS_HINT_EXPAND, 0.0);
- evas_object_size_hint_align_set(en, EVAS_HINT_FILL, 0.1);
- elm_table_pack(tab, en, 0, 1, 1, 1);
- evas_object_show(en);
- 
 
 evas_object_resize(win, 800, 800);
 evas_object_show(win);
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib



On Fri, 11 Nov 2011, Christopher Michael wrote:

 On 11/11/11 19:54, Enlightenment SVN wrote:
 Log:
 back to unsigned long. code was actually correct as-is.

 If that's actually correct, then the 'fix' for the xcb version should be
 reverted also ;)

so, as I said, the last argument of the XCB function is an uint32_t, and 
as int is always 32 bits, there's no pb

Vincent


 dh



 Author:   raster
 Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011)
 New Revision: 65082
 Trac: http://trac.enlightenment.org/e/changeset/65082

 Modified:
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c   2011-11-11 
 21:59:02 UTC (rev 65081)
 +++ trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c   2011-11-12 
 00:54:22 UTC (rev 65082)
 @@ -131,7 +131,7 @@
return -1;
 }
   for (i = 0; i  num_ret; i++)
 -  val[i] = ((unsigned int *)prop_ret)[i];
 +  val[i] = ((unsigned long *)prop_ret)[i];
   num = num_ret;
   *plst = val;
}



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



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

[E-devel] [Patch][elm_map] Remove unnecessary flags

Hi,

There are too may flags in elm_map. Most of them are duplicated and unnecessary.
I have removed want, download, have variables.

I use gi-job instead of want  download.
I use ecore_file_exists() instead of have flags.

Please review attached patch file.
Index: src/lib/elm_map.c
===
--- src/lib/elm_map.c	(리비전 65087)
+++ src/lib/elm_map.c	(작업 사본)
@@ -250,9 +250,7 @@ struct _Grid_Item
struct {
 int x, y, w, h;
} src, out;
-   Eina_Bool want : 1;
-   Eina_Bool download : 1;
-   Eina_Bool have : 1;
+
Ecore_File_Download_Job *job;
int try_num;
 };
@@ -1154,14 +1152,12 @@ grid_clear(Evas_Object *obj, Grid *g)
 //evas_object_del(gi-txt);
 
 wd-download_list = eina_list_remove(wd-download_list, gi);
-gi-want = EINA_FALSE;
 
 if (gi-job)
   {
  DBG(DOWNLOAD abort %s, gi-file);
  ecore_file_download_abort(gi-job);
  ecore_file_remove(gi-file);
- gi-have = EINA_FALSE;
  gi-job = NULL;
  wd-try_num--;
   }
@@ -1182,24 +1178,19 @@ grid_clear(Evas_Object *obj, Grid *g)
 static void
 _tile_update(Grid_Item *gi)
 {
-   gi-want = EINA_FALSE;
-   gi-download = EINA_FALSE;
evas_object_image_file_set(gi-img, gi-file, NULL);
if (evas_object_image_load_error_get(gi-img) != EVAS_LOAD_ERROR_NONE)
  {
 ERR(Image loading error (%s), gi-file);
 ecore_file_remove(gi-file);
-gi-have = EINA_FALSE;
-return;
  }
-
-   obj_rotate_zoom(gi-wd-obj, gi-img);
-   evas_object_show(gi-img);
-
-   //evas_object_text_text_set(gi-txt, gi-file);
-   //evas_object_show(gi-txt);
-
-   gi-have = EINA_TRUE;
+   else
+ {
+   obj_rotate_zoom(gi-wd-obj, gi-img);
+   evas_object_show(gi-img);
+   //evas_object_text_text_set(gi-txt, gi-file);
+   //evas_object_show(gi-txt);
+ }
 }
 
 static void
@@ -1207,32 +1198,28 @@ _tile_downloaded(void *data, const char
 {
Grid_Item *gi = data;
 
-   gi-wd-download_num--;
-   gi-download = EINA_FALSE;
gi-job = NULL;
 
-   if ((gi-want)  (status == 200))
+   if (status == 200)
  {
+DBG(Download success from %s to %s, gi-source, gi-file);
 _tile_update(gi);
-DBG(DOWNLOAD done %s, gi-file);
  }
-
-   if (status != 200)
+   else
  {
-DBG(Download failed %s (%d) , gi-file, status);
+DBG(Download failed from %s to %s (%d) , gi-source, gi-file, status);
 ecore_file_remove(gi-file);
-gi-have = EINA_FALSE;
  }
-   else
- gi-wd-finish_num++;
 
+   gi-wd-finish_num++;
+   gi-wd-download_num--;
evas_object_smart_callback_call(gi-wd-obj, SIG_DOWNLOADED, NULL);
if (!gi-wd-download_num)
  {
 edje_object_signal_emit(elm_smart_scroller_edje_object_get(gi-wd-scr), elm,state,busy,stop, elm);
 evas_object_smart_callback_call(gi-wd-obj, SIG_LOADED_DETAIL, NULL);
  }
-   _process_download_list(gi-wd-obj);
+   //_process_download_list(gi-wd-obj);
 }
 
 static void
@@ -1274,19 +1261,16 @@ _process_download_list(Evas_Object *obj)
  ww, hh,
  cvx, cvy, cvw, cvh))
   {
- gi-download = EINA_FALSE;
  wd-download_list = eina_list_remove(wd-download_list, gi);
   }
  }
 
EINA_LIST_REVERSE_FOREACH_SAFE(wd-download_list, l, ll, gi)
  {
-if (gi-wd-download_num = MAX_CONCURRENT_DOWNLOAD)
-  break;
+if (gi-wd-download_num = MAX_CONCURRENT_DOWNLOAD) break;
 
 Eina_Bool ret = ecore_file_download_full(gi-source, gi-file, _tile_downloaded, NULL, gi, (gi-job), wd-ua);
-if (!ret || !gi-job)
-  WRN(Can't start to download %s to %s, gi-source, gi-file);
+if (!ret || !gi-job) ERR(Can't start to download from %s to %s, gi-source, gi-file);
 else
   {
  gi-wd-download_num++;
@@ -1304,8 +1288,7 @@ _add_download_list(Evas_Object *obj, Gri
ELM_CHECK_WIDTYPE(obj, widtype);
Widget_Data *wd = elm_widget_data_get(obj);
 
-   wd-download_list = eina_list_remove(wd-download_list, gi);
-   wd-download_list = eina_list_append(wd-download_list, gi);
+   if (!eina_list_data_find(wd-download_list, gi)) wd-download_list = eina_list_append(wd-download_list, gi);
_process_download_list(obj);
 }
 
@@ -1393,33 +1376,20 @@ grid_load(Evas_Object *obj, Grid *g)
  ww, hh,
  cvx, cvy, cvw, cvh))
   {
- if (gi-want)
+ if (ecore_file_exists(gi-file))
{
   evas_object_hide(gi-img);
-  //evas_object_hide(gi-txt);
   evas_object_image_file_set(gi-img, NULL, NULL);
-  gi-want = EINA_FALSE;
-  gi-have = EINA_FALSE;
-
-  if (gi-job)
-{
-   DBG(DOWNLOAD

Re: [E-devel] E SVN: raster trunk/ecore/src/lib/ecore_x/xlib



On Sat, 12 Nov 2011, Carsten Haitzler (The Rasterman) wrote:

 On Fri, 11 Nov 2011 20:08:09 -0500 Christopher Michael 
 cpmicha...@comcast.net
 said:

 On 11/11/11 19:54, Enlightenment SVN wrote:
 Log:
 back to unsigned long. code was actually correct as-is.

 If that's actually correct, then the 'fix' for the xcb version should be
 reverted also ;)

 yeah  found it. fixed. :) thanks for reminding

 fyi - notice that even with those changes.. a whole bunch of other funcs in 
 the
 same file were still using unsigned long * so the code was inconsistently
 changed too... which is bad :)

forget my previous mail

I do not agree. I don't see anywhere in the protocol specification where a 
long is used:

http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/encoding.xml
http://cgit.freedesktop.org/xorg/proto/xproto/tree/specs/sect1-9.xml

Vincent


 dh



 Author:   raster
 Date: 2011-11-11 16:54:22 -0800 (Fri, 11 Nov 2011)
 New Revision: 65082
 Trac: http://trac.enlightenment.org/e/changeset/65082

 Modified:
trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c

 Modified: trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 ===
 --- trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c
 2011-11-11 21:59:02 UTC (rev 65081) +++
 trunk/ecore/src/lib/ecore_x/xlib/ecore_x_window_prop.c  2011-11-12
 00:54:22 UTC (rev 65082) @@ -131,7 +131,7 @@ return -1;
 }
   for (i = 0; i  num_ret; i++)
 -  val[i] = ((unsigned int *)prop_ret)[i];
 +  val[i] = ((unsigned long *)prop_ret)[i];
   num = num_ret;
   *plst = val;
}



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



 -- 
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


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



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

Re: [E-devel] eyesight configure error



On Sat, 12 Nov 2011, Tomas Cech wrote:

 Hi,

 I met this issue during building eyesight (search for GlobalParams.h):

there is a warning in the configure output (see below) :

configure: WARNING: Xpdf headers not found. Verify that poppler is configured 
with the option --enable-xpdf-headers

Vincent


 + ./configure --host=x86_64-unknown-linux-gnu 
 --build=x86_64-unknown-linux-gnu --program-prefix= --prefix=/usr 
 --exec-prefix=/u sr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 - 
 -libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com 
 --mandir=/usr/share/man --infodir=/usr/share/info --disable -static 
 --with-pdf-backend=poppler
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for style of include used by make... GNU
 checking for x86_64-unknown-linux-gnu-gcc... no
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables... checking whether we are cross 
 compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... gcc3
 checking for a sed that does not truncate output... /usr/bin/sed
 checking for grep that handles long lines and -e... /usr/bin/grep
 checking for egrep... /usr/bin/grep -E
 checking for fgrep... /usr/bin/grep -F
 checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld
 checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld...  yes
 checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
 checking the name lister (/usr/bin/nm -B) interface... BSD nm
 checking whether ln -s works... yes
 checking the maximum length of command line arguments... 1572864
 checking whether the shell understands some XSI constructs... yes
 checking whether the shell understands +=... yes
 checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... 
 -r
 checking for x86_64-unknown-linux-gnu-objdump... no
 checking for objdump... objdump
 checking how to recognize dependent libraries... pass_all
 checking for x86_64-unknown-linux-gnu-ar... no
 checking for ar... ar
 checking for x86_64-unknown-linux-gnu-strip... no
 checking for strip... strip
 checking for x86_64-unknown-linux-gnu-ranlib... no
 checking for ranlib... ranlib
 checking command to parse /usr/bin/nm -B output from gcc object... ok
 checking how to run the C preprocessor... gcc -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking for dlfcn.h... yes
 checking for objdir... .libs
 checking if gcc supports -fno-rtti -fno-exceptions... no
 checking for gcc option to produce PIC... -fPIC -DPIC
 checking if gcc PIC flag -fPIC -DPIC works... yes
 checking if gcc static flag -static works... yes
 checking if gcc supports -c -o file.o... yes
 checking if gcc supports -c -o file.o... (cached) yes
 checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m
 elf_x86_64) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... no
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... no
 checking whether mupdf CJK fonts are enabled... checking whether to build 
 eyesight binary... yes
 checking for x86_64-unknown-linux-gnu-gcc... gcc
 checking whether we are using the GNU C compiler... (cached) yes
 checking whether gcc accepts -g... (cached) yes
 checking for gcc option to accept ISO C89... (cached) none needed
 checking dependency style of gcc... (cached) gcc3
 checking how to run the C preprocessor... gcc -E
 checking for x86_64-unknown-linux-gnu-g++... no
 checking for x86_64-unknown-linux-gnu-c++... no
 checking for x86_64-unknown-linux-gnu-gpp... no
 checking for x86_64-unknown-linux-gnu-aCC... no
 checking for x86_64-unknown-linux-gnu-CC... no
 checking for x86_64-unknown-linux-gnu-cxx... no
 checking for x86_64-unknown-linux-gnu-cc++... no
 checking for x86_64-unknown-linux-gnu-cl.exe... no
 checking for

Re: [E-devel] eyesight configure error



On Sat, 12 Nov 2011, Tomas Cech wrote:

 On Fri, Nov 11, 2011 at 09:10:49PM -0500, Christopher Michael wrote:
 On 11/11/11 21:04, Tomas Cech wrote:
  configure: WARNING: Xpdf headers not found. Verify that poppler is
  configured with the option --enable-xpdf-headers
  checking whether to enable PDF module built... no
 
 Perhaps this offers a clue ?? ;)
 

 Nope. I use same package on my system and configure works. It is
 probably dependency issue, but not Xpdf headers.

the problem is how poppler is compiled. You *have to* compile yourself 
poppler, so you have to download the source code, configure it with the 
options mentioned in the warning and install it before compiling eyesight

Vincent

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

Re: [E-devel] [PATCH] eyesight: add gradient.png to sources