On Tue, 10.02.15 13:59, Philip Withnall (phi...@tecnocode.co.uk) wrote:
I am pretty sure if you do async IO like gio does for every single
file access you'll just complicate your program and make it
substantially slower. For small files normal, synchronous disk access
is a ton faster than
On Mon, 2015-02-02 at 12:19 +0100, Olav Vitters wrote:
On Mon, Feb 02, 2015 at 08:05:00AM +, Philip Withnall wrote:
It was suggested that I send the presentation to DDL, since it might be
of general interest. I haven’t modified it from the hackfest version, so
please let me know if you
On Tue, Feb 10, 2015, at 01:00 PM, Ekaterina Gerasimova wrote:
https://wiki.gnome.org/HowDoI/Jhbuild is the one that seems to be
preferred by most docs newcomers and team members so from my point of
view it would be good that the final result resembles it and works
just as well.
jhbuilding
On 11/02/15 12:28, Michael Hill wrote:
On Tue, Feb 10, 2015, at 01:00 PM, Ekaterina Gerasimova wrote:
https://wiki.gnome.org/HowDoI/Jhbuild is the one that seems to be
preferred by most docs newcomers and team members so from my point of
view it would be good that the final result resembles
Right now the way g_file_read_async works is by scheduling a task on a
worker thread, having the worker thread do the async read, and then
returning a result.
As such, it's impossible to have two async reads done at the same time,
which is really unfortunate from my understanding. If I'm reading
On Tue, Feb 10, 2015 at 08:38:39AM +0100, Milan Crha wrote:
Is there a way to tell the comment parser that the commit itself
belongs to another product than the one the bug is filled for?
I could add support for something like:
module $FOO commit $BAR
Just as now you can do:
comment 13
On Tue, Feb 10, 2015 at 9:29 AM, Oliver Propst oliver.pro...@gmail.com wrote:
On Mon, Feb 9, 2015 at 11:50 PM, Sriram Ramkrishna s...@ramkrishna.me wrote:
I just want to thank everyone on the sysadmin team for this. This has
been a long time coming and took quite amount of work due to the fact
On Tue, Feb 10, 2015 at 09:58:49AM +0100, Alexandre Franke wrote:
As I already told Sri on IRC yesterday, if anything is wrong with our
current bugzilla, you should start by filing bugs. Then we can start
looking for solutions and someone to implement them. Otherwise we
can't guess what you
On Tue, Feb 10, 2015 at 9:56 AM, Olav Vitters o...@vitters.nl wrote:
On Tue, Feb 10, 2015 at 08:38:39AM +0100, Milan Crha wrote:
Is there a way to tell the comment parser that the commit itself
belongs to another product than the one the bug is filled for?
I could add support for something
On Mon, 09.02.15 10:47, Philip Withnall (phi...@tecnocode.co.uk) wrote:
Hi all,
From some feedback from real-world users of GLib/GIO (see the ‘Feedback
from downstreams’ thread), and just from looking at our own code in
GNOME, it seems that people persistently use sync versions of APIs in
Sriram Ramkrishna s...@ramkrishna.me wrote:
The upgrade has been finalized and the machine is back to production.
A special thank you goes to Andre Klapper and Krzesimir Nowak for
their hard work to make this happen.
...
I just want to thank everyone on the sysadmin team for this.
Same here!
On Tue, 2015-02-10 at 10:20 +0100, Alexandre Franke wrote:
First of all, I'd like to point that the bug report for this feature
is still open at https://bugzilla.gnome.org/show_bug.cgi?id=559537
We started discussing the commit in another product issue there,
so maybe we can continue
On Mon, 2015-02-09 at 14:55 +0100, Bastien Nocera wrote:
On Mon, 2015-02-09 at 13:42 +, Philip Withnall wrote:
On Mon, 2015-02-09 at 14:02 +0100, Bastien Nocera wrote:
On Mon, 2015-02-09 at 12:53 +, Emmanuele Bassi wrote:
snip
I do agree with Philip's proposal of warning if
On Tue, 2015-02-10 at 11:20 +0100, Lennart Poettering wrote:
On Mon, 09.02.15 10:47, Philip Withnall (phi...@tecnocode.co.uk) wrote:
Hi all,
From some feedback from real-world users of GLib/GIO (see the ‘Feedback
from downstreams’ thread), and just from looking at our own code in
One quick example: calling g_file_read_async on a GResourceFile spawns a
new thread and does a synchronous stream read from a block already in
memory.
It should just be a single g_bytes_ref, but we have three different classes
created, a thread spawned, and a large amount of locks to do the
Problem: we have many pages on jhbuild documentation
We want to eliminate all of this and have
https://wiki.gnome.org/GnomeLove/BuildGnome
There seems to be some objections to removing some of the more
in-depth jhbuild documentation. I think overall this is a little
confusing, they are also
Allan Day wrote:
People will always come across the official manual on
developer.gnome.org, since this ranks highly in search results. So, if
you really want people to easily find the introductory documentation,
it will have to live as a part of the official manual. I get the
The most
Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3. https://wiki.gnome.org/GnomeLove/BuildGnome
4. https://wiki.gnome.org/GnomeLove/JhbuildIntroduction
On 10/02/2015, Sriram Ramkrishna s...@ramkrishna.me wrote:
Problem: we have many pages on jhbuild documentation
We want to eliminate all of this and have
https://wiki.gnome.org/GnomeLove/BuildGnome
There seems to be some objections to removing some of the more
in-depth jhbuild
Hi,
On Tue, Feb 10, 2015 at 11:27:11AM -0800, Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3. https://wiki.gnome.org/GnomeLove/BuildGnome
4.
In particular, we should identify material from the HowDoI/Jhbuild page
(which conflicts with the guidance on the BuildGnome page) that we want
to keep, and merge it into the BuildGnome page. We should not have
competing pages with competing advice; it's way too confusing for
newcomers.
Sébastien Wilmet wrote:
Hi,
On Tue, Feb 10, 2015 at 11:27:11AM -0800, Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3.
On 10/02/2015, Frederic Peters fpet...@gnome.org wrote:
Allan Day wrote:
People will always come across the official manual on
developer.gnome.org, since this ranks highly in search results. So, if
you really want people to easily find the introductory documentation,
it will have to live as
On Tue, Feb 10, 2015 at 1:06 PM, Allan Day allanp...@gmail.com wrote:
Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3.
For anyone who might be interested: git-bz stopped working for me with
the upgrade. However, I was pointed to the following branch, which
does work:
http://cgit.collabora.com/git/user/pwith/git-bz.git/tree/git-bz?h=bugzilla-4.4
Allan
___
25 matches
Mail list logo
