Re: [E-devel] [Update] Exchange library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 5 Oct 2008 15:10:46 -0700 Eric Sandall <[EMAIL PROTECTED]> wrote: > You're missing a file, I think. ;) > > $ NOCONFIGURE=X ./autogen.sh > Running aclocal... > /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of > AM_PATH_SMPEG /usr/share/aclocal/smpeg.m4:13: run info > '(automake)Extending aclocal' /usr/share/aclocal/smpeg.m4:13: or see > http://sources.redhat.com/automake/automake.html#Extending-aclocal > Running autoheader... Running autoconf... > Running libtoolize... > Running automake... > configure.ac:12: installing `./install-sh' > configure.ac:12: installing `./missing' > src/bin/Makefile.am: installing `./depcomp' > configure.ac:69: required file `exchange.pc.in' not found > > Can you add the file or remove the setup for exchange.pc? > > $ sed -i '/exchange.pc/d' configure.ac > $ sed -i '/exchange.pc/d' Makefile.am > > Thanks, > > - -sandalle You're right! Added now, thx for help. In few days i'll merge the exchange git tree into main source tree, in PROTO for now. Thx again Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFI6b+TleGEL56NNP4RAozwAKDEBD2/O13Oed1tkX1Sp5be72nBIACfZwAZ SIu7rxcUUMZxqCY241cTcSQ= =HeRD -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] UDP client/server support
On Sun, Oct 5, 2008 at 3:46 PM, Gustavo Sverzut Barbieri
<[EMAIL PROTECTED]> wrote:
> On Sun, Oct 5, 2008 at 12:27 AM, Matt Barclay <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> With this patch, ecore will have full UDP client/server support.
>> Tooling UDP into the framework wasn't the easiest thing in the world
>> because a UDP server has a single socket (i.e. file handle) that is
>> used to handle all clients, whereas a TCP server generates a new
>> socket for each client that encapsulates all the details of the
>> connection. So here's how I implemented it:
>>
>> UDP Server (Unicast and Multicast):
>> 1. When there is data on the socket, the callback uses recvfrom() to
>> read the datagram and client address (struct sockaddr_in)
>> 2. Create a new Ecore_Con_Client and save the client address
>> (sockaddr_in) details with the "data" field. Leave the "fd", "buf",
>> and "fd_handler" fields NULL.
>> 3. Create a new Ecore_Con_Event_Client_Data and save the datagram in
>> the "data" field, and the client in the "client" field
>> 4. ecore_con_client_send() is updated to check for a
>> client->server->type of ECORE_CON_REMOTE_UDP and use sendto() with
>> client->data as the destination instead of appending the buffer to
>> client->buf
>> 5. relevant portions of ecore_con_client_del() and
>> _ecore_con_event_client_data_free() are updated to ensure the client
>> and data memory are freed
>>
>> The use of recvfrom() and sendto() feels a little dirty to me, but I'm
>> not sure how else to preserve the client address so that packets can
>> be sent back to the client. AFAIK, there isn't any way to do an
>> accept() on a UDP socket such that a new file handle is created that
>> encapsulates the end points of the UDP socket. Would appreciate some
>> "enlightenment" on this topic if I'm wrong. ;)
>>
>> UDP Client support fits nicely into the framework as a new socket is
>> created each time ecore_con_server_connect() is called.
>>
>> A UDP Server example program is included with the patch, and examples
>> of multicast and UDP client support can be found in SVN:
>> TEST/orig/ecore/
> Looks good, but it was just an overview of the code, maybe someone
> will reply with more in-depth comments.
It meet the current code standard of ecore_con.
> As your complaing about recvfrom() and sendto(), I don't see any issue
> with that, udp requires us to do so. The best thing to do is to to
> make the ecore_con operate on callbacks ("virtuals") and have
> different implementations for each system, then you just have the
> "ifs" on the entry point, where you select the connection type, there
> you set the function pointers and use them directly next times.
As Arnaud is working on adding IPv6 support to ecore_con, more change
and cleanup are coming into it. So I don't think it's needed to put
this patch on hold, as change will come step by step inside ecore_con.
And if anything is broken, we will just fix it.
> One thing I noticed is that you leave trailing whitespaces on some
> lines, remove them before committing.
Yep, I removed them before committing the patch in svn.
--
Cedric BAIL
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch: add jpeg thumbnail format to epsilon
2008/10/6 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>: > On Sun, Sep 21, 2008 at 7:29 PM, Hendrik Siedelmann > <[EMAIL PROTECTED]> wrote: >> Okay here it is, this patch adds the possibility to epsilon to create >> thumbnails in jpg format. The thumbnails are saved in FDO naming >> convention, just with ending .jpg. Would be glad if you could give me >> some feedback so this could eventually be included in svn. Patch works >> for me, but there are some things to mention: > > Ok, better late than sorry, it's commited to SVN. As for your questions: Now that is great news, thanks. >> - default behaviour is like before, BUT epsilon_exists will also find >> jpg thumbs, so epsilon_thumb_file_get will return the jpg and >> epsilon_info_get will return nothing as the jpg contains no exif >> infos. >> >> - I don't know what happens in those HAVE_EPEG_H parts, only tested >> without epeg. > > EPEG was the old way to generate JPEGs in an efficient way. Then that > code was integrated into Evas, then I deprecated EPEG (moved to OLD) > when we changed to SVN. > > At the beginning, epsilon was not using Evas, but raster added that, > but I never checked that it was not generating JPEGs, just PNGs > because there was no option to select so. So is it save to assume epeg is never used and remove those parts? >> - new function epsilon_format_set which allows to set format to jpeg. > > It would be good to provide patch for > BINDINGS/python-efl/python-epsilon. If you are able to provide so, > mail it, otherwise I can do it for you. Sorry, never worked with python. >> - also changed epsilon_thumbd and added function >> epsilon_request_add_advanced which can also set format (and in the >> future hopefully custom sizes). >> >> - changed epsilon_thumb_test to accept the arguments -large and -jpg >> to request thumbnails with these options. >> >> >From my test the jpg output is at least two times as fast on my laptop >> and at least five times on the the freerunner. Also the resulting >> files are 10-20% the size of png thumbnails. > > yes, raster already provided such feedback to fdo guys, but they > blindly rejected so... damn it. Yeah would have been nice to have jpeg in the standard. But the way the jpegs are saved now makes it dead easy to implement for all programs that support the fdo spec. hendrik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eina
Hi devs, Here we are, eina (tool in Catalan) is now ready for prime time all over the EFL. Eina is provided with a test covering around 96% of the code, a doc written mostly by Vincent and a benchmark suite that make some attempt to mimic Enlightenment use of the data type. Runing the benchmark on two different computer let us discover some interesting fact. So I will give pointer to both result, where [a] will be an athlon 64 at 2.4Ghz with 512KB of cache and [b] will be Core 2 Duo 2.66Ghz with 6MB of cache. So what does Eina provides, first it provide some basic data type : - Shared string: provide a way to reduce the number of duplicated strings kept in ram. It's a replacement for both evas and ecore stringshare with the same API. It's faster and scale better than the original one and we are also faster than glib on this. [a] http://imagebin.org/28089 [b] http://imagebin.org/28091 - Array: provide an interface to replace evas array and in the same time some kind of a stack with push/pop mecanism. The destruction implementation should be faster and more adapted to evas use than the current one used by evas. [a] http://imagebin.org/28090 [b] http://imagebin.org/28092 - List: provide a double linked list with fast count and last like evas. I used sort to measure speed of this implementation, as all the implementation we will compare against use the same kind of merge sort, and it manipulate a lot of list pointers. [a] http://imagebin.org/28093 [b] http://imagebin.org/28094 - Hash: It provide a hash table, the API is more like ecore and provide a way to provide your own hash function. [a] http://imagebin.org/28095 [b] http://imagebin.org/28096 - Inlined list: provide list that should be included directly inside the structure of the object you want to manipulate. - Red Black tree: provide a binary tree implementation with insertion/removal/lookup that should be included directly inside the structure of the object of the tree. All this container come with an iterator (no removal authorized during iteration or it could break) and some of them with an accessor when it means something. As eina need for it's internal some function that could be usefull for other, we are also exposing and providing the following tool : - Convert: provide convertion function from integer to/from string and double to/from string. [a] http://imagebin.org/28097 [b] http://imagebin.org/28098 - Counter: provide a way to precisely mesure timing for benchmark typically. - Benchmark: provide the API used by eina benchmark suite to others. - File: provide some basic function usefull when manipulating directory listing. - Module: provide a set of function that should give every one what they wanted. - Error: provide an unified interface to error checking/generation. - Memory pool: provide function for testing impact of other mempool (speed and use). It is currently used in eina_list, but depending on your configuration it could be some time better to use the default one (It was the case for computer [b]). For best speed, eina should be compiled with CFLAGS="-pipe -O3" ./configure --disable-magic-debug and also with --disable-default-mempool for some system. So now, what remain in the TODO. Still some doc, but mainly compiling and running it on more computer/OS would be a good thing. Reviewing the API and it's internal too. It could be part of the autobuild too. And if nobody complain about it, eina should be moved out of PROTO at the end of the week. Perhaps making the autotools of each efl that could use it depend on eina in the same move, so that people working on it could easily replace old code with eina one. I already identified eet/evas/ecore/edje/efreet/e as the one that could benefit from a move (reduction in size code and speed improvement). Have fun ! -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch: add jpeg thumbnail format to epsilon
On Mon, Oct 6, 2008 at 6:11 AM, Hendrik Siedelmann <[EMAIL PROTECTED]> wrote: > 2008/10/6 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>: >> On Sun, Sep 21, 2008 at 7:29 PM, Hendrik Siedelmann >> <[EMAIL PROTECTED]> wrote: >>> - default behaviour is like before, BUT epsilon_exists will also find >>> jpg thumbs, so epsilon_thumb_file_get will return the jpg and >>> epsilon_info_get will return nothing as the jpg contains no exif >>> infos. >>> >>> - I don't know what happens in those HAVE_EPEG_H parts, only tested >>> without epeg. >> >> EPEG was the old way to generate JPEGs in an efficient way. Then that >> code was integrated into Evas, then I deprecated EPEG (moved to OLD) >> when we changed to SVN. >> >> At the beginning, epsilon was not using Evas, but raster added that, >> but I never checked that it was not generating JPEGs, just PNGs >> because there was no option to select so. > > So is it save to assume epeg is never used and remove those parts? those yes, now they can be handled with Evas. I'm not sure if you want to, but Epsilon requires some cleanup/refactory, making it evas only (and emotion for video). >>> - new function epsilon_format_set which allows to set format to jpeg. >> >> It would be good to provide patch for >> BINDINGS/python-efl/python-epsilon. If you are able to provide so, >> mail it, otherwise I can do it for you. > > Sorry, never worked with python. ok, ok :-) >>> - also changed epsilon_thumbd and added function >>> epsilon_request_add_advanced which can also set format (and in the >>> future hopefully custom sizes). >>> >>> - changed epsilon_thumb_test to accept the arguments -large and -jpg >>> to request thumbnails with these options. >>> >>> >From my test the jpg output is at least two times as fast on my laptop >>> and at least five times on the the freerunner. Also the resulting >>> files are 10-20% the size of png thumbnails. >> >> yes, raster already provided such feedback to fdo guys, but they >> blindly rejected so... damn it. > > Yeah would have been nice to have jpeg in the standard. But the way > the jpegs are saved now makes it dead easy to implement for all > programs that support the fdo spec. yeah -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore_con
Enlightenment SVN schrieb:
> Log:
> Another step toward IPv6 support with more cleanup.
>
> Patch from Arnaud de Turckheim.
>
>
> Author: cedric
> Date: 2008-10-06 09:40:01 -0700 (Mon, 06 Oct 2008)
> New Revision: 36483
>
> Modified:
> trunk/ecore/src/lib/ecore_con/ecore_con.c
> trunk/ecore/src/lib/ecore_con/ecore_con_info.c
>
> Modified: trunk/ecore/src/lib/ecore_con/ecore_con.c
> ===
> --- trunk/ecore/src/lib/ecore_con/ecore_con.c 2008-10-06 15:58:21 UTC (rev
> 36482)
> +++ trunk/ecore/src/lib/ecore_con/ecore_con.c 2008-10-06 16:40:01 UTC (rev
> 36483)
> @@ -26,21 +26,23 @@
> # include
> #endif
>
> -static void _ecore_con_cb_dns_lookup(void *data, struct hostent *he);
> -static void _ecore_con_cb_udp_dns_lookup(void *data, struct hostent *he);
> static void _ecore_con_cb_tcp_connect(void *data, Ecore_Con_Netinfo *info);
> static void _ecore_con_cb_udp_connect(void *data, Ecore_Con_Netinfo *info);
> static void _ecore_con_cb_tcp_listen(void *data, Ecore_Con_Netinfo *info);
> static void _ecore_con_cb_udp_listen(void *data, Ecore_Con_Netinfo *info);
> +
> static void _ecore_con_server_free(Ecore_Con_Server *svr);
> static void _ecore_con_client_free(Ecore_Con_Client *cl);
> +
> static int _ecore_con_svr_handler(void *data, Ecore_Fd_Handler *fd_handler);
> static int _ecore_con_cl_handler(void *data, Ecore_Fd_Handler *fd_handler);
> static int _ecore_con_cl_udp_handler(void *data, Ecore_Fd_Handler
> *fd_handler);
> static int _ecore_con_svr_udp_handler(void *data, Ecore_Fd_Handler
> *fd_handler);
> static int _ecore_con_svr_cl_handler(void *data, Ecore_Fd_Handler
> *fd_handler);
> +
> static void _ecore_con_server_flush(Ecore_Con_Server *svr);
> static void _ecore_con_client_flush(Ecore_Con_Client *cl);
> +
> static void _ecore_con_event_client_add_free(void *data, void *ev);
> static void _ecore_con_event_client_del_free(void *data, void *ev);
> static void _ecore_con_event_client_data_free(void *data, void *ev);
> @@ -57,8 +59,25 @@
>
> static Ecore_List *servers = NULL;
> static int init_count = 0;
> +
> #if USE_OPENSSL
> static int ssl_init_count = 0;
> +static int _ecore_con_init_ssl(Ecore_Con_Server *svr);
> +static int _ecore_con_shutdown_ssl(Ecore_Con_Server *svr);
> +static int _ecore_con_free_ssl(Ecore_Con_Server *svr);
> +
> +# define INIT_SSL(svr) _ecore_con_init_ssl(svr)
> +# define SHUTDOWN_SSL(svr) _ecore_con_shutdown_ssl(svr)
> +# define FREE_SSL(svr) _ecore_con_free_ssl(svr)
> +# define UNSET_SSL(svr) \
> + do { \
> +svr->ssl = NULL; \
> +svr->ssl_ctx = NULL; \
> + } while (0);
>
The point of using do {} while(0) in macros, fades away if you append a
semicolon.
> +#else
> +# define INIT_SSL(svr) 0
> +# define SHUTDOWN_SSL(svr) 0
> +# define FREE_SSL(svr) 0
> #endi
I haven't read the full code, but I think you are missing the
UNSET_SSL() for the !OPENSSL case.
Peter
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Update] Exchange library
On Mon, 6 Oct 2008 09:34:41 +0200 Massimiliano Calamelli <[EMAIL PROTECTED]> wrote: > On Sun, 5 Oct 2008 15:10:46 -0700 > Eric Sandall <[EMAIL PROTECTED]> wrote: > > > You're missing a file, I think. ;) > > > > $ NOCONFIGURE=X ./autogen.sh > > Running aclocal... > > /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of > > AM_PATH_SMPEG /usr/share/aclocal/smpeg.m4:13: run info > > '(automake)Extending aclocal' /usr/share/aclocal/smpeg.m4:13: or > > see > > http://sources.redhat.com/automake/automake.html#Extending-aclocal > > Running autoheader... Running autoconf... Running libtoolize... > > Running automake... > > configure.ac:12: installing `./install-sh' > > configure.ac:12: installing `./missing' > > src/bin/Makefile.am: installing `./depcomp' > > configure.ac:69: required file `exchange.pc.in' not found > > > > Can you add the file or remove the setup for exchange.pc? > > > > $ sed -i '/exchange.pc/d' configure.ac > > $ sed -i '/exchange.pc/d' Makefile.am > > > > Thanks, > > > > - -sandalle > > You're right! Added now, thx for help. > In few days i'll merge the exchange git tree into main source tree, in > PROTO for now. > > Thx again Anytime. :) I've updated our end to work with the added file, and will update again once moved to svn.enlightenment.org. ;) -sandalle -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 signature.asc Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
