>
> On Thu, Jun 23, 2016 at 02:03:45PM +0200, Pavel Grunt wrote:
> > Hi Christophe,
> >
> > they were patches changing spice common includes to use <> instead of "",
> > so I
> > would keep it.
>
> The generated code is in spice-common/common, so my understanding is
> that "" should be used ther
Was used as write variable only for testing.
Avoid usage of not constant globals.
Making globals constants avoid future race condition
usages.
Signed-off-by: Frediano Ziglio
---
server/event-loop.c | 6 +++---
server/red-common.h | 2 +-
server/tests/basic_event_loop.c
> Hi,
>
> what will happen if both '--server' and '--client' are used on the
> commandline?
> Only client's will be generated ?
>
> Pavel
>
Agreed, form the comment on code and code looks like you can specify both
(client and server) to have both processed, from your comments looks like
you c
Avoid not constant globals.
Signed-off-by: Frediano Ziglio
---
server/event-loop.c | 23 ++-
server/red-channel.c| 59 +++
server/red-common.h | 17
server/reds-private.h | 2 +-
server/reds.c
On Fri, Jun 24, 2016 at 03:02:34AM -0400, Frediano Ziglio wrote:
> >
> > On Thu, Jun 23, 2016 at 02:03:45PM +0200, Pavel Grunt wrote:
> > > Hi Christophe,
> > >
> > > they were patches changing spice common includes to use <> instead of "",
> > > so I
> > > would keep it.
> >
> > The generated c
>
> This commit adds autogeneration of a generated_client_marshallers.h
> header, which is then included in client_marshallers.h
>
> This allows to remove the SpiceMessageMarshallers struct from this file,
> which has to match what the generated code expects.
> ---
> Changes since v1:
> - Squashe
On Fri, Jun 24, 2016 at 04:04:36AM -0400, Frediano Ziglio wrote:
>
> > Hi,
> >
> > what will happen if both '--server' and '--client' are used on the
> > commandline?
> > Only client's will be generated ?
> >
> > Pavel
> >
>
> Agreed, form the comment on code and code looks like you can speci
>
> On Fri, Jun 24, 2016 at 04:04:36AM -0400, Frediano Ziglio wrote:
> >
> > > Hi,
> > >
> > > what will happen if both '--server' and '--client' are used on the
> > > commandline?
> > > Only client's will be generated ?
> > >
> > > Pavel
> > >
> >
> > Agreed, form the comment on code and co
On Thu, Jun 23, 2016 at 02:30:14PM +0200, Christophe Fergeau wrote:
> On Thu, Jun 23, 2016 at 02:19:22PM +0200, Christophe Fergeau wrote:
> > Actually there is a much bigger set of changes to the spice-gtk package when
> > I compare http://depot.flexvdi.com/sources/spice-gtk-flexvdi-2.2.2.tgz
> > w
>
> On Thu, Jun 23, 2016 at 02:19:22PM +0200, Christophe Fergeau wrote:
> > Actually there is a much bigger set of changes to the spice-gtk package
> > when
> > I compare http://depot.flexvdi.com/sources/spice-gtk-flexvdi-2.2.2.tgz
> > with the upstream spice-gtk 0.28 tarball (see attached patch).
On Fri, Jun 24, 2016 at 06:23:12AM -0400, Frediano Ziglio wrote:
> >
> > On Thu, Jun 23, 2016 at 02:19:22PM +0200, Christophe Fergeau wrote:
> > > Actually there is a much bigger set of changes to the spice-gtk package
> > > when
> > > I compare http://depot.flexvdi.com/sources/spice-gtk-flexvdi-2
Hi,
On Thu, Jun 23, 2016 at 07:37:45PM +0200, Victor Toso wrote:
> No need to inform of a problem under
> spice_file_transfer_task_completed() as the task will be finalized and
> we can send the error to the agent there.
>
> This change is related to split SpiceFileTransferTask from
> channel-main
Hi,
On Thu, Jun 23, 2016 at 03:39:58PM -0500, Jonathon Jongsma wrote:
> On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> > Introduced functions (private):
> > * void spice_file_transfer_task_init_task_async()
> > * GFileInfo *spice_file_transfer_task_init_task_finish()
> >
> > The in
Hi,
On Thu, Jun 23, 2016 at 02:31:47PM -0500, Jonathon Jongsma wrote:
> On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> > We can split from file_xfer_send_start_msg_async() the logic in
> > creating the SpiceFileTransferTasks; The rest of the function can be
> > handled at spice_main_file_
Introduced functions (private):
* void spice_file_transfer_task_init_task_async()
* GFileInfo *spice_file_transfer_task_init_task_finish()
The init process of SpiceFileTransferTask does initialize its
GFileInputStream (for reading the file) and also its GFileInfo
(necessary to protocol in or
Hi,
On Thu, Jun 23, 2016 at 06:05:51PM +0200, Lukas Venhoda wrote:
> Ping for pushing
Pushed the first two patches. Last one has g_mutex_init/clear pending
Best,
>
> On Thu, May 26, 2016 at 1:01 PM, Victor Toso wrote:
>
> > Hi,
> >
> > On Wed, May 25, 2016 at 03:51:42PM +0200, Lukáš Venhoda
Hi,
On Mon, Jun 13, 2016 at 07:54:34PM +0300, Snir Sheriber wrote:
> Compressed message type is CompressedData which contains compression
> type (1 byte) followed by the uncompressed data size (4 bytes-exists
> only if data was compressed) followed by the compressed data
>
> If SPICE_SPICEVMC_CAP_
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> Introduced functions (private):
> * void spice_file_transfer_task_read_async()
> * gssize spice_file_transfer_task_read_finish()
>
> For a better abstraction of how to read from SpiceFileTransferTask and
> handle with its data, following th
On Fri, 2016-06-24 at 17:32 +0200, Victor Toso wrote:
> Introduced functions (private):
> * void spice_file_transfer_task_init_task_async()
> * GFileInfo *spice_file_transfer_task_init_task_finish()
>
> The init process of SpiceFileTransferTask does initialize its
> GFileInputStream (for rea
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> * spice_file_transfer_task_read_async() will call the callback with
> error in case it is called on pending state
OK, this maintains behavior, since it just moves the error reporting down a
level to the called function.
>
> * on VD_AGENT_
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> By separating SpiceFileTransferTask from channel-main, we could choose
> where to put the handler for messages. With the approach based on
> spice_file_transfer_task_read_async(), we cannot have it under
> spice-file-transfer-task.c due the ne
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> file_xfer_flush_finish and file_xfer_data_flushed_cb are channel-main
> function and should not check for SpiceFileTransferTask internal
> errors.
OK, but I'd like some additional justification of why we can skip this without
causing problems
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> file_xfer_queue() function belongs to channel-main so it should not
> access SpiceFileTransferTask private struct (self->buffer).
>
> This patch changes:
> * rename function: file_xfer_queue -> file_xfer_queue_msg_to_agent
> As it makes mor
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> Each call to spice_main_file_copy_async will now create a
> FileTransferOperation which groups all SpiceFileTransferTasks of the
> copy operation in a GHashTable.
>
> To ease the review process, this first patch introduces the structure
> and
Acked-by: Jonathon Jongsma
On Thu, 2016-06-23 at 19:37 +0200, Victor Toso wrote:
> No need to inform of a problem under
> spice_file_transfer_task_completed() as the task will be finalized and
> we can send the error to the agent there.
>
> This change is related to split SpiceFileTransferTask
25 matches
Mail list logo
