The use of low-level interfaces such as Efl.Io.Reader and
Efl.Io.Writer are not that user-friendly as they can handle partial
data.
Classes such as Efl.Io.Copier makes them easy to use, but they need a
reader (source) or writer (destination) and in our examples we used
fixed buffers or some existing streams (stdin/stdout/stderr,
networking...).
However, if interactively we need to produce some data to be sent,
such as implementing some networking protocols, we'd have to write our
own Efl.Io.Reader and Efl.Io.Writer classes to handle the buffering.
Not anymore! With Efl.Io.Queue you can write stuff to it and it will
buffer to memory. Once stuff is read, it will automatically remove
those bytes from buffer.
This class implements the Efl.Net.Dialer interface using libcurl to
perform HTTP requests. That means it's an Efl.Net.Dialer,
Efl.Net.Socket, Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus
being usable with Efl.Io.Copier as demonstrated in the
efl_io_copier_example.c
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
These interfaces allows generic operations on objects that can store
or provide data, such as a file or a buffer.
With well defined interfaces and events we can create code such as
Efl.Io.Copier, that will link a source with a destination and
progressively copy data as they appear.
This reverts commit 546ff7bbba788ec834c5608361c0834853f2d5d7.
It seems that eo_del() is useful and removing it was creating bugs.
The issue is that the way we defined parents in eo, both the parent and
the programmer share a reference to the object. When we eo_unref() that
reference as the programmer, eo has no way to know it's this specific
reference we are freeing, and not a general one, so in some
circumstances, for example:
eo_ref(child);
eo_unref(child); // trying to delete here
eo_unref(container); // container is deleted here
eo_unref(child); // child already has 0 refs before this point.
We would have an issue with references and objects being freed too soon
and in general, issue with the references.
Having eo_del() solves that, because this one explicitly unparents if
there is a parent, meaning the reference ownership is explicitly taken
by the programmer.
eo_del() is essentially a convenience function around "check if has
parent, and if so unparent, otherwise, unref". Which should be used when
you want to delete an object although it has a parent, and is equivalent
to eo_unref() when it doesn't have one.
We used to have eo_del() as the mirrored action to eo_add(). No longer,
now you just always eo_unref() to delete an object. This change makes it
so the reference of the parent is shared with the reference the
programmer has. So eo_parent_set(obj, NULL) can free an object, and so
does eo_unref() (even if there is a parent).
This means Eo no longer complains if you have a parent during deletion.
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
Summary:
The socket API is different on Windows and on Linux.
This is the perfect example where we need to abstract the socket API in Eina :
1) to avoid all these includes specific to sockets
2) to avoid on Windows undefined behavior : close(socket); is undefined behavior if socket is indeed a socket
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D3441
Summary:
Checking if client is NULL before freeing is not of much use. If it is NULL, it would have crashed before when it was dereferenced in printf. So checking NULL before dereferencing.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3151
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Checking if client is NULL before freeing is not of much use. If it is NULL, it would have crashed before when it was dereferenced in printf. So checking NULL before dereferencing.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3088
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
pd was dereferenced and then checked for NULL. If it was NULL, the program would crash much before. So fixed that.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3031
Summary:
cd was dereferenced and then was checked for NULL. If cd is NULL, it would crash before itself. So checking for NULL before dereferencing cd.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3009
Summary:
Relating to D3010. This patch is code cleanup. Have done dos2unix. After this will update D3010 bug.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3025
Summary:
Ecore_Buffer is abstraction of graphic buffer.
it supports backend of shm, x11_dri2 and x11_dri3 for now,
and this library also provides method to share buffers between processes.
Ecore_Buffer_Provider and Ecore_Buffer_Consumer is for this, sharing buffer.
provider draws something in to Ecore_Buffer, and consumer receives and displays it.
the binary, bq_mgr is a connection maker for buffer provider and consumer.
it can be included Enlightenment as a deamon later.
@feature
Test Plan:
1. Configure with --enable-ecore-buffer and --enable-always-build-examples to build examples.
2. Run bq_mgr, it connects consumer and provider.
3. Run ecore_buffer_provider_example and ecore_buffer_consumer_example
Reviewers: lsj119, gwanglim, cedric, zmike, jpeg, raster, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2197
This was not really useful and against the Eolian guidelines.
While I promised I won't break things until the 27th, I was ill
(still am), so I'm giving myself a 1 day pass. :P
Summary: add ecore_evas_extn_socket_events_block_set/get
Test Plan: add mouse event callback, and check whether it could get event or not
Reviewers: raster, woohyun, jaehwan, Sergeant_Whitespace
Reviewed By: Sergeant_Whitespace
Subscribers: Sergeant_Whitespace, seoz, cedric
Differential Revision: https://phab.enlightenment.org/D2268
Summary:
Without ecore_main_loop_quit the example won't end. So added that and as ecore_init is done in ecore_con_init removed that.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2399
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Added example for ftp upload. In the .gitignore only 2 files added which were missing. The differences it is showing is cos of reordering. I did ls and redirected the file to gitignore. So the files got reordered.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2223
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
recived Error that object already deleted in the following files:
In evas-object-manipulation-eo.c: d.clipper and d.bg where created with
eo_add ( 1 ref ) but where unrefd twice: once explicity and once when
d.ee were deleted.
In ecore_indler_example: ctxt->idler were again explicity unrefd and
again unrefd by ecore_shutdown.
@fix
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2093
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
When the examples were compiled they used to through the below warning
$ gcc -o ecore_con_client_simple_example ecore_con_client_simple_example.c `pkg-config --libs --cflags ecore ecore-con eina`
ecore_con_client_simple_example.c:11:0: warning: "EINA_UNUSED" redefined
# define EINA_UNUSED
^
In file included from /usr/include/eina-1/Eina.h:215:0,
from /usr/include/ecore-1/Ecore.h:304,
from ecore_con_client_simple_example.c:5:
/usr/include/eina-1/eina/eina_types.h:112:0: note: this is the location of the previous definition
# define EINA_UNUSED __attribute__ ((__unused__))
^
So removed these defines as they are no longer required now.
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1919
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Add ecore_evas_cursor_unset function.
Use the new function in the ecore_evas_object_example.
@feature
Test Plan: ecore_evas_object_example
Reviewers: raster, cedric, seoz, Hermet
CC: cedric
Differential Revision: https://phab.enlightenment.org/D812
Summary:
Mainly from the examples but also from libunibreak and tests/eet.
I'm not sure if it's really worth to remove warnings from the examples
-- because it adds pedantic-ness to something supposed to be didatic,
but I leave for you guys to judge.
Reviewers: tasn, cedric
CC: felipealmeida, raster, smohanty, cedric
Differential Revision: https://phab.enlightenment.org/D896
Signed-off-by: Cedric Bail <cedric.bail@free.fr>