Alexander Larsson schrieb:
On Mon, 2009-05-11 at 10:49 -0400, Dan Winship wrote:
On 05/11/2009 10:30 AM, Stefan Kost wrote:
Alexander Larsson schrieb:
GResolver is already in gio, yes. NameResolver isn't really less generic
than GResolver though. What else would it resolve but names? Could be
On Fri, 2009-05-15 at 20:59 +0300, Stefan Kost wrote:
I just wanted to bring up SAT resolvers to just notice that they are called
SAT
solvers :) http://en.wikipedia.org/wiki/Boolean_satisfiability_problem
If noone else has any likely candidate then from my side the name is yours :)
We
On Sun, 10 May 2009 17:29:48 +0300
Stefan Kost enso...@hora-obscura.de wrote:
Alexander Larsson schrieb:
With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people instead of
On 05/12/2009 05:22 AM, Paul LeoNerd Evans wrote:
Speaking of GResolver, in the API (which I'm currently staring at here:
http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolverid=05507dce1f540581028e8be0e220e68c44fade2f
) I don't see any attempt at the gai()-style hostname +
On Tue, May 12, 2009 at 09:41:53AM -0400, Dan Winship wrote:
On 05/12/2009 05:22 AM, Paul LeoNerd Evans wrote:
Speaking of GResolver, in the API (which I'm currently staring at here:
http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolverid=05507dce1f540581028e8be0e220e68c44fade2f
On Sun, 2009-05-10 at 17:29 +0300, Stefan Kost wrote:
Alexander Larsson schrieb:
With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people instead of on bugzilla in order to
Alexander Larsson schrieb:
On Sun, 2009-05-10 at 17:29 +0300, Stefan Kost wrote:
Alexander Larsson schrieb:
With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people
On 05/11/2009 10:30 AM, Stefan Kost wrote:
Alexander Larsson schrieb:
GResolver is already in gio, yes. NameResolver isn't really less generic
than GResolver though. What else would it resolve but names? Could be
GDNSResolver though.
That sounds good. I was just wondering as there are
Am Mon, 11 May 2009 10:49:31 -0400
schrieb Dan Winship d...@gnome.org:
On 05/11/2009 10:30 AM, Stefan Kost wrote:
Alexander Larsson schrieb:
GResolver is already in gio, yes. NameResolver isn't really less
generic than GResolver though. What else would it resolve but
names? Could be
Le lundi 11 mai 2009 à 19:26 +0200, Alexander Larsson a écrit :
On Mon, 2009-05-11 at 10:49 -0400, Dan Winship wrote:
On 05/11/2009 10:30 AM, Stefan Kost wrote:
Alexander Larsson schrieb:
GResolver is already in gio, yes. NameResolver isn't really less generic
than GResolver though.
On Mon, 2009-05-11 at 10:49 -0400, Dan Winship wrote:
On 05/11/2009 10:30 AM, Stefan Kost wrote:
Alexander Larsson schrieb:
GResolver is already in gio, yes. NameResolver isn't really less generic
than GResolver though. What else would it resolve but names? Could be
GDNSResolver though.
On Mon, 2009-05-11 at 15:08 -0300, Vovo ^^ wrote:
Also will it always resolve names using only DNS?
Not sure if this was rhetorical or not but no, GResolver uses NSS so
could end up using LDAP, mDNS and so on.
Ross
--
Ross Burton mail: r...@burtonini.com
Alexander Larsson schrieb:
With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people instead of on bugzilla in order to get
feedback from others who may be interested but
On Mon, 2009-04-27 at 22:16 +0200, Alexander Larsson wrote:
On Mon, 2009-04-27 at 11:39 -0400, Ryan Lortie wrote:
Going forward from this point, you argue that there should be a massive
reduction in the number of classes. I think that your decision-making
here is influenced by the fact
On Mon, 2009-04-27 at 17:28 -0700, Dave Benson wrote:
In libsoup it's also important because it's thread-safe/non-racy. That
may not be a relevant criterion for GSocket, although the source
returned by g_socket_create_source() could create similar problems; you
need to be certain that any
On Mon, 2009-04-27 at 23:32 +0300, Tor Lillqvist wrote:
I remember reading recently that there was all kinds of issues with
local pipes on win32, but I don't remember any details. It was on some
gnome list, maybe even this.
It was on the dbus list. Quoting myself and Thiago Macieira:
On Mon, 2009-04-27 at 17:16 -0400, Dan Winship wrote:
Alexander Larsson wrote:
On Mon, 2009-04-27 at 13:22 -0400, Dan Winship wrote:
g_socket_finalize closes socket even if g_socket_close() is already
closed, need to add an is_closed variable. We should also check this in
all operations
With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people instead of on bugzilla in order to get
feedback from others who may be interested but unaware of this work.
This review is
On 04/27/2009 09:53 AM, Alexander Larsson wrote:
With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people instead of on bugzilla in order to get
feedback from others who may be
Alexander Larsson wrote:
GIOStream.c:
This is currently an interface, while the related GInputStream and
GOutputStreams are base classes. This isn't necessarily wrong by itself,
but looks a bit weird. There are also other reasons (see below) why it
would be nice if it was a class,
Hi,
On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbod beh...@behdad.org wrote:
There is a lot of G_UNLIKELY() calls in places that really are not in
any way performance sensitive. I'm not sure I like this, since it makes
the code harder to read for very little gain. Like, it probably makes
On 04/27/2009 11:40 AM, Havoc Pennington wrote:
Hi,
On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbodbeh...@behdad.org wrote:
There is a lot of G_UNLIKELY() calls in places that really are not in
any way performance sensitive. I'm not sure I like this, since it makes
the code harder to read
On Mon, Apr 27, 2009 at 8:40 AM, Havoc Pennington
havoc.penning...@gmail.com wrote:
Hi,
On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbod beh...@behdad.org wrote:
There is a lot of G_UNLIKELY() calls in places that really are not in
any way performance sensitive. I'm not sure I like this,
(I still haven't read all of gnio, so I'm mostly only commenting on
Alex's comments, plus GSocket, since I have read that.)
Alexander Larsson wrote:
Every time I've done socket code I've enabled SO_REUSEADDR
Yeah, Ryan and I had this exact conversation (including the same link)
on IRC
John McCutchan wrote:
On Mon, Apr 27, 2009 at 8:40 AM, Havoc Pennington
havoc.penning...@gmail.com wrote:
I don't really know much about modern processors or compilation, but
my understanding is that the penalty for being wrong on G_UNLIKELY()
is quite high. And as we know from the old
Hi,
On Mon, Apr 27, 2009 at 1:20 PM, John McCutchan j...@johnmccutchan.com wrote:
It's good practice to avoid using hints unless you have a firm grasp
on the odds of the branch being taken.
The thing I find kind of intractable, is that you have to not only
know the odds, but think your grasp
On Mon, 2009-04-27 at 11:39 -0400, Ryan Lortie wrote:
Alexander Larsson wrote:
GIOStream.c:
This is currently an interface, while the related GInputStream and
GOutputStreams are base classes. This isn't necessarily wrong by itself,
but looks a bit weird. There are also
On Mon, 2009-04-27 at 11:55 -0400, Dan Winship wrote:
Ryan Lortie wrote:
Not sure I agree. See shutdown() syscall. The fact that this call
exists means that the designers of [unix or tcp or whatever] went out of
their way because they disagreed with you.
I can't think of any time I've
On Mon, 2009-04-27 at 13:22 -0400, Dan Winship wrote:
There are also other flags we might want to think about. In libsoup, all
sockets get marked FD_CLOEXEC because of a long-ago bug. (The Red Carpet
daemon used librpm to do stuff, and librpm would spawn postinstall
scripts without doing the
I remember reading recently that there was all kinds of issues with
local pipes on win32, but I don't remember any details. It was on some
gnome list, maybe even this.
It was on the dbus list. Quoting myself and Thiago Macieira:
Em Terça-feira 21 Abril 2009, às 16:32:15, Tor Lillqvist
On Mon, 2009-04-27 at 15:24 -0400, Havoc Pennington wrote:
Limiting it to one-time-or-should-never-happen, or inner loops that
have in fact been profiled, would seem to follow the no premature
optimization rule.
This seems like a good rule of thumb to me.
Alexander Larsson wrote:
On Mon, 2009-04-27 at 13:22 -0400, Dan Winship wrote:
g_socket_finalize closes socket even if g_socket_close() is already
closed, need to add an is_closed variable. We should also check this in
all operations so that we don't accidentally call stuff on an fd that
may
Dan Winship wrote:
Alexander Larsson wrote:
On Mon, 2009-04-27 at 13:22 -0400, Dan Winship wrote:
g_socket_finalize closes socket even if g_socket_close() is already
closed, need to add an is_closed variable. We should also check this in
all operations so that we don't accidentally
In libsoup it's also important because it's thread-safe/non-racy. That
may not be a relevant criterion for GSocket, although the source
returned by g_socket_create_source() could create similar problems; you
need to be certain that any such sources are destroyed before you call
34 matches
Mail list logo
