lock this signal from
being delivered.
Mathieu
--
Mathieu Lacage
Tel: +33 4 9238 5056
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
does
the same.
Mathieu
--
Mathieu Lacage
Tel: +33 4 9238 5056
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Wed, 2010-03-17 at 12:41 +0200, Daniel Elstner wrote:
> Interesting approach. Just out of interest, how long would a typical
> randomization interval be? Also, as far as I'm aware this sort of
> pre-linking is not generally done on current desktop Linux distributions
> -- is that still correc
On Tue, 2010-03-16 at 23:32 +0200, Daniel Elstner wrote:
> > And oddly enough, the ARM compiler does away even with the object file
> > relocation entries for the table.
>
> At some point, it needs to fill the table. And if loading offsets are
> randomized for security, there is hardly any room
On Fri, 2009-06-26 at 12:09 +0300, Dirk-Jan Binnema wrote:
> For a little fs-specific trick on Linux: If you actually have to
> *open* the files (e.g, for sniffing), you can make things quite a bit
> faster by sorting the files in order of inode first, if you are on
> ext3 (and ext4 I suppose, as
On Fri, 2009-06-26 at 09:31 +0100, Bastien Nocera wrote:
> On Fri, 2009-06-26 at 10:25 +0200, Jernej Simončič wrote:
> > On Thu, 25 Jun 2009 12:12:05 +0200, Kristian Rietveld wrote:
> >
> > > As a side comment, I am not really sure how fair it is to compare a
> > > full blown GUI to a command line
On Wed, 2009-03-11 at 11:08 -0400, muppet wrote:
> Johan Dahlin wrote:
> > As far as I can see there aren't any easy solutions.
> > We're depending on libffi to calculate struct sizes for the typelib
> > which is very
> > much host and compiler dependent. g-ir-compile really needs to run on the
>
On Tue, 2008-09-16 at 13:56 -0700, Mathieu Lacage wrote:
> On Tue, 2008-09-16 at 15:45 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > On Mon, Sep 15, 2008 at 7:46 AM, Alexander Larsson <[EMAIL PROTECTED]>
> > wrote:
> > > If you dlopen cairo-glib and u
On Tue, 2008-09-16 at 15:45 -0400, Havoc Pennington wrote:
> Hi,
>
> On Mon, Sep 15, 2008 at 7:46 AM, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> > If you dlopen cairo-glib and use RTLD_LOCAL I think you avoid the symbol
> > lookup overhead. Maybe this is useful?
> >
>
> It breaks to RTLD_LOC
On Tue, 2008-09-16 at 05:55 +0200, Kai-Uwe Behrmann wrote:
> Am 15.09.08, 13:46 +0200 schrieb Alexander Larsson:
> > On Sat, 2008-09-13 at 15:05 -0400, Havoc Pennington wrote:
> > > Hi,
> > >
> > > On Sat, Sep 13, 2008 at 1:38 PM, Colin Walters <[EMAIL PROTECTED]> wrote:
> > > > Actually I just h
[trimming the mad CC list]
On Mon, 2008-09-08 at 07:42 +0200, Mikkel Kamstrup Erlandsen wrote:
> >>> typedef enum {
> >>>GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after
> >>> use */
> >>>GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it
> >>> is */
On Wed, 2008-08-06 at 21:07 +0200, Christian Dywan wrote:
> > > The following mail is about using the chance of breaking API with
> > > glib-3.0 for improving GArray and GList.
> > >
> >
> > I thought 3.0 had no API breaks in it?
>
> I suspect Mathias was actually referring to the option of dep
On Mon, 2008-08-04 at 12:22 +0200, Alexander Larsson wrote:
> On Sat, 2008-08-02 at 21:35 +0200, Alexander Larsson wrote:
>
> > * Some operations require an X window id, for example:
> >+ glXMakeCurrent()
> > so that you can draw into a window with opengl.
> > You can still draw t
On Wed, 2007-12-05 at 09:28 +0100, Alexander Larsson wrote:
> On Tue, 2007-12-04 at 15:59 -0500, Morten Welinder wrote:
> > > I added an extra check for ->write != NULL in the splice case (because
> > > write() already did that) and commited.
> >
> > I would be to avoid having struct members calle
On Fri, 2007-05-04 at 11:40 +0200, Alexander Larsson wrote:
> > 5) You seem to use void * in as the data pointers. All applications I
> > know use guchar * (some use gchar *) to handle data. From my stream
> > handling experience this is to encourage people to think about what
> > they pass to suc
On Thu, 2007-03-15 at 10:56 -0400, Owen Taylor wrote:
> Well, I could imagine (maybe, barely) that someone could show me numbers
> that showed that with a variety of long and complicated regular
> expressions, compiling them was still 10x as fast as matching them
> against very short strings.
>
>
On Thu, 2007-02-15 at 17:32 +0100, Alexander Larsson wrote:
> > You probably thought about it already, but why not
> > GSocket{Input|Output)Stream?
> >
> > In general I think naming works good if the interface is named with the
> > abstract concept, and the implementation is named:
> >
> >
On Mon, 2006-10-30 at 15:34 +0100, Tim Janik wrote:
> On Wed, 25 Oct 2006, Havoc Pennington wrote:
>
> > Hi,
> >
> > When coding dbus I thought I'd try a project with a focus on unit tests.
> > It has (or at least had for a while) exceptionally high test coverage,
> > around 75% of basic blocks ex
On Wed, 2006-09-20 at 13:52 +0200, Alexander Larsson wrote:
> > 1) Don't you think it might make sense to also add an io priority arg to
> > the sync functions ?
>
> Possibly. It wouldn't really be implementable for normal local files,
> but could help for e.g. vfs streams from the daemon. It see
On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
> Here is my current GInputStream:
very nice. Comments below.
>
> struct _GInputStreamClass
> {
> GObjectClass parent_class;
>
> /* Sync ops: */
>
Do you dislike the idea of moving the GError as a member of the
GInputStream in
On Tue, 2006-09-19 at 15:04 +0200, Alexander Larsson wrote:
> > > > We still need to support URIs too at least in some places, because of
> > > > '%u' in .desktop files. If GNOME apps switched to using '%f', then
> > > > konqueror (and old versions of GNOME) wouldn't be able to pass remote
> > > >
hi,
On Tue, 2006-09-19 at 13:15 +0200, Benedikt Meurer wrote:
> > We still need to support URIs too at least in some places, because of
> > '%u' in .desktop files. If GNOME apps switched to using '%f', then
> > konqueror (and old versions of GNOME) wouldn't be able to pass remote
> > files to the
hi,
I recently stumbled upon:
http://www.linuxdevices.com/news/NS4663700447.html which outlines the
ALP platform. A GTK+/gstreamer stack is included in it and I see no X
server. I assume this means that they plan to either port GTK+ to this
platform's low-level APIs or use an existing technology s
I won't comment on the patches because they are really big. Most
notably, you included in the patches a bunch of space-related changes
which do not contain any semantic information and large amounts of
mechanic additions for tags which I am not really
interested in reviewing. It would make a lot
I understand that this might not be high on the todo list of the gtk+
developers but I would appreciate an answer to that email.
regards,
Mathieu
On Fri, 2005-05-27 at 13:57 +0200, Mathieu Lacage wrote:
> On Thu, 2005-05-26 at 09:49 -0400, Matthias Clasen wrote:
> > The problem with m
d Griffiths
Eric Lemings <[EMAIL PROTECTED]>
Fabrice Bauzac [EMAIL PROTECTED]
Federico Mena Quintero
Hans Breuer
Havoc Pennington
James Henstridge
Jared Lash
Jonathan Blandford
[EMAIL PROTECTED]
Josh Parsons
Linux Walleij
Mariano Suárez-Alvarez
Mark Jones
Martin Schulze
Martyn Russell
Mathieu L
On Thu, 2005-05-26 at 09:49 -0400, Matthias Clasen wrote:
> > > I would be happy if someone could approve the other patch attached
> > > (license.patch):
> > > - re-add the list of contributors in a separate chapter at the end of
> > > the gobject-doc.sgml file.
> > > - add a copyright stateme
47 - 1.1961
+++ ChangeLog 26 May 2005 11:48:14 -
@@ -1,3 +1,8 @@
+2005-05-26 Mathieu Lacage <[EMAIL PROTECTED]>
+
+ * docs/reference/gobject/tut_*.xml: fix a lot of typos,
+ some of which were reported by Leonardo Boshell.
+
Wed May 25 15:33:51 2005 Manish Singh <[EMAIL PROTECTE
On Wed, 2005-04-06 at 10:40 +0200, Stefan Kost wrote:
> the question now is which way to go?
> I've a gnome cvs account, thus I can check files in CVS, but I have no shell
> account to do it.
For now, as I told you already in my last email, it should be okay to
checkin your changes to the gobjec
On Mon, 2005-04-04 at 12:33 -0400, Owen Taylor wrote:
> I think the question is whether advantages of the use of custom
> tools ... whether specialized or extensions to gtk-doc ... is worth the
> hassle of maintaining those tools, compared to just writing straight-up
> docbook. Sure, it's painful t
On Mon, 2005-04-04 at 09:11 +0200, Stefan Kost wrote:
> Hi Mathieu and others,
> >
> > [snip]
> >
> >>Keeping the CVS history is indeed a probelm and would require manual
> >>surgery on
> >>the server. I (personaly) would discontinue the stand-alone document.
> >
> >
> > I don't mind disconti
On Mon, 2005-04-04 at 09:04 +0200, Stefan Kost wrote:
> Hi Mathieu,
> > [snip]
> >
> >>3) links from description [extra doxbook xml files] to API docs
> >
> >
> > As I already pointed out in an old private mail to you on function
> > links, I would like to see you use a small script to generate
On Thu, 2005-03-31 at 16:46 +0200, Stefan Kost wrote:
> Owen Taylor and Tim Janik agreed that it would be useful to integrate it.
> Although I need to appologise, I should have asked you explicitely (I've been
No need to ask. Just keep me updated: I don't want to discourage you
from contributing
hi stefan,
I am sorry if I have missed something but would you mind telling me
exactly what deal has been agreed upon and by who ? i.e., have the glib
maintainers expressed interest in this ? So far, I have not seen any
public reply to your gtk-devel emails which is why I wonder how all of
this is
hi,
The attached patch appears to fix the build of the glib-2-6 branch for
me.
regards,
Mathieu
--
Mathieu Lacage <[EMAIL PROTECTED]>
? a.out-20752.func-dump
? a.out-30008.func-dump
? a.out-3164.func-dump
? a.out-5228.func-dump
? patch
Index: Cha
35 matches
Mail list logo
