Re: Commit auto-links in bugzilla comments

[Milan Crha]

On Wed, 2015-02-11 at 09:52 -0800, Jasper St. Pierre wrote:
> Out of curiosity, is there anything wrong with just copy/pasting a 
> link?

Hi,
I did that for the past few months. My comments in bugzilla sometimes 
look like:
   Created commit 123456 in evo master (x.y.z+) [1]
   Created commit 987654 in eds master (x.y.z+) [2]

   [1] link-to-evo-commit-123456
   [2] link-to-eds-commit-987654

where "x.y.z+" is version when the fix will be included first.

The thing is that since the update of the bugzilla the part of the 
text "Created commit  ..." was recognized and the commit number 
had been underlined (made click-able).

As you can see, one of the auto-links will be wrong in the example 
above, because one bug cannot be in both evolution-data-server and 
evolution. Such "false-positive" may make confusion to bug readers. 
That was the reason to start this thread.
Bye,
Milan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GSoC 2015 call for ideas

[Marina Zhurakhinskaya]

Dear GNOME hackers,

It's that time of the year again: Google Summer of Code is approaching. We've 
updated our program pages [1] to have the latest information and we need your 
help in creating a list of great project ideas. It's essential that we have a 
well-prepared ideas page when GNOME applies as a mentoring organization by next 
Friday, February 20.

So what should you do? Please visit the ideas page [2] and enter your project 
ideas under the "Untriaged Ideas" section.

 * Discuss your ideas with designers in #gnome-design to get their input and 
plan collaboration, especially if your ideas are related to one of the core 
GNOME modules. If you are not sure who to speak to, start with Allan Day (aday).
 * Consider manageable ideas consisting of multiple smaller features that share 
a common theme, in addition to single large feature ideas. See the information 
for mentors page [3] for more on preferred project formats and other mentoring 
resources.

If you are interested in being a mentor this year or at any point find yourself 
drafted to be one, please join soc-mentors-list [4] to receive future 
communications about GNOME's participation in GSoC, including the information 
about important deadlines.

The GNOME administrators for GSoC participation this year are Alexandre Franke, 
Christophe Fergeau, Ekaterina Gerasimova, Lasse Schuirmann, and Marina 
Zhurakhinskaya. Big thank you to Fabiano Fidencio, who was an administrator for 
the last two years! Welcome to Lasse Schuirmann, who was a GSoC participant 
last year!

Cheers,
The GNOME Google Summer of Code Administrators

[1] https://wiki.gnome.org/Outreach/SummerOfCode/2015
[2] https://wiki.gnome.org/Outreach/SummerOfCode/2015/Ideas
[3] https://live.gnome.org/Outreach/SummerOfCode/Mentors
[4] https://mail.gnome.org/mailman/listinfo/soc-mentors-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

switching applications

[Aydin K.]

Hello.

1. I switch to another workspace and this workspace has more then one
application. Then when i switch applications with shortcut "switch
applications" (quick pressing, without opening switcher meny) it switches
to applications that is in another workspace. Would it not make more sense
to make it switch between applications on the same workspace?

2. There is no option to assign shortcut directly to typing language. And i
have to cycle throw all the languages installed (i have four).

Thank you.

ayd
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[David Woodhouse]

On Wed, 2015-02-11 at 21:26 +, Simon McVittie wrote:
> On 11/02/15 21:10, Jasper St. Pierre wrote:
> > Another example: for some odd reason, GLocalFileInputStream isn't a
> > pollable output stream
> 
> (I assume you mean GLocalFileOutputStream.)
> 
> > Why was this done? I don't know.
> 
> AIUI, because all Unix kernels treat local I/O as arbitrarily fast, 
> hence "local" files (which might in fact be NFS-mounted from another 
> continent) are not usefully pollable.

It doesn't have to NFS-mounted to be slow.

The crappy SSD in this laptop also sometimes gets itself into a state
where writes are *extremely* slow, and you really notice the apps which
are writing to local files from their main loop.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[Simon McVittie]

On 11/02/15 21:10, Jasper St. Pierre wrote:

Another example: for some odd reason, GLocalFileInputStream isn't a
pollable output stream


(I assume you mean GLocalFileOutputStream.)


Why was this done? I don't know.


AIUI, because all Unix kernels treat local I/O as arbitrarily fast, 
hence "local" files (which might in fact be NFS-mounted from another 
continent) are not usefully pollable.


You can usefully poll pipes, fifos, sockets, most recent-ish Linux APIs 
(e.g. inotify, epoll, timerfd, kdbus), and probably their equivalents on 
non-Linux. Notably, "regular files" are not on that list (and I don't 
think directories are either).


--
Simon McVittie
Collabora Ltd. 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[Jasper St. Pierre]

That's one example of low-hanging fruit. Calling query_info_async is the
same thing. Creating a GFileMonitor for a GResourceFile (admittedly
nonsense, but arbitrary code that tries to watch any GFile passed into it
might hurt) will call query_info_async once every 5 seconds, creating a new
thread for each.

If we want to clean this up by playing whack-a-mole and writing a lot of
special-case code, we can certainly do that. I'm widely convinced doing so
is a waste of time.

Another example: for some odd reason, GLocalFileInputStream isn't a
pollable output stream, so calling write_async on it spawns a thread, even
when it should be using a write poll integrated with the mainloop. Why was
this done? I don't know. Should this be fixed? Yes.

On Wed, Feb 11, 2015 at 4:10 AM, Philip Withnall 
wrote:

> On Tue, 2015-02-10 at 10:30 -0800, Jasper St. Pierre wrote:
> > 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 equivalent of memcpy.
>
> That’s not good at all, and seems like it should be easy to fix by
> overriding the read_async vfunc for GResourceFile. Is there a bug filed
> about it?
>
> Philip
>
> > On Tue, Feb 10, 2015 at 8:49 AM, Jasper St. Pierre
> >  wrote:
> > 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 a large file, and then a small file, the large
> > file needs to fully complete before the small file is
> > dispatched from the async queue.
> >
> > Additionally, when profiling GNOME on ARM, I've been seeing a
> > lot of cases of users using g_file_read_async() "just in case"
> > for no particular reason, which causes several locks to be
> > taken, severely slowing performance.
> >
> >
> > We need to seriously improve our async performance before
> > asking people to use it.
> >
> >
> > On Tue, Feb 10, 2015 at 6:48 AM, Lennart Poettering
> >  wrote:
> > 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 dispatching things to
> > background threads, and
> > > > back...
> > >
> > > The problem is that GIO can’t know which accesses
> > are to small, local
> > > files, and which aren’t. It already optimises reads
> > from pollable
> > > streams (sockets) by keeping them in the main thread
> > and adding them
> > > into the main poll() call.
> >
> > Well, but the developer frequently knows that. He
> > knows that the
> > config file in ~/.config is not going to be more than
> > a few K. And
> > that it hence is fine to access it synchronously...
> >
> > > > Also, glib has wrappers for making mmaping
> > available to programs, to
> > > > improve seldom-accessed sparse databases
> > efficient, do you want to
> > > > prohibit that too?
> > >
> > > No, mmap() is clearly a tool for a different kind of
> > problem. If you’re
> > > accessing an mmap()ed file, you need to be sure it’s
> > local anyway, I
> > > think? GMappedFile doesn’t have async versions of
> > its methods,
> > > presumably for this reason.
> >
> > mmap() works pretty Ok these days over NFS. Concurrent
> > access
> > doesn't. But as long as you just want to access
> > something, it's
> > fine...
> >
> > That said it's probably not a good idea to use mmap()
> > for stuff below
> > $HOME...
> >
> > > As above, how about making that line the distinction
> > between calling
> > > functions from gstdio.h and using GIO? In the former
> >   

Re: Commit auto-links in bugzilla comments

[Xavier Claessens]

Le mercredi 11 février 2015 à 09:52 -0800, Jasper St. Pierre a écrit :
> Out of curiosity, is there anything wrong with just copy/pasting a
> link? You know, something like
> 
> https://git.gnome.org/browse/gnome-shell/commit/?id=d54b87c4559bd9d74fa10d3e3d1e38a933bea051

There is nothing wrong with copy/pasting the link, but then you have to
browse git.gnome.org to find the commit/branch link. The nice thing with
letting bugzilla build the link is that all you need to know is the
commit hash or branch name, and that info is in your terminal.

> I find that trying to remember crazy syntax and exceptions is a bit
> difficult. Does it work inside parens with immediate closing like
> "(see also comment #13)"? Does it work with and without the number
> sign? After a line-break, one like Bugzilla likes to auto-add? I've
> ran into so many exceptions it's hard to remember what's valid.

It's indeed hidden secret, and the regex isn't always perfect the first
time. Nobody is forced to use it, but IMO it's nice little trick that
doesn't cost us much, does it? 

> On Wed, Feb 11, 2015 at 9:43 AM, Xavier Claessens 
> wrote:
> Le mardi 10 février 2015 à 08:38 +0100, Milan Crha a écrit :
> > Hello,
> > I'd like to ask: how does the auto-links for commits in the
> new
> > bugzilla work? I mean, if I write something like:
> >commit abcde12345
> > then the "abcde12345" will become a link to the sources in
> the product
> > the current bug is filled for. It works similarly to bug
> auto-link
> > references, which is nice.
> 
> Related to this, I've proposed to also link "branch wip/..."
> in this
> bug: https://bugzilla.gnome.org/show_bug.cgi?id=744068
> 
> > My problem is when one change for a product A requires also
> a change
> > in product B and I reference commits for both products
> within one bug
> > report. That may cause one of the commit links invalid.
> >
> > 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?
> 
> If we come with a way to specify the module, would be nice to
> adapt my
> patch likewise :)
> 
> Regards,
> Xavier Claessens.
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> 
> 
> -- 
>   Jasper
> 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Canonical jhbuild documentation

[Sriram Ramkrishna]

On Wed, Feb 11, 2015 at 4:33 AM, Allan Day  wrote:
> Sriram Ramkrishna  wrote:
> ...
>>> Seems like you should talk this through with Carlos and Ryan - they're
>>> the effective maintainers of the wiki pages in question. I know that
>>> Carlos is keen to reduce the amount of duplication.
>>
>> Yes, I sent this email after consulting with him and Fred.
>
> I assume that "him" is Carlos? Maybe you should talk to Ryan also, if
> that's the case.

Indeed.

>
>>> 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
>>> impression that there has been resistance to this in the past, due to
>>> the desire to keep Jhbuild as a somewhat generic tool. However, I
>>> don't see how the two use cases (Jhbuild for new GNOME contributors,
>>> and Jhbuild for everyone else) couldn't be satisfied by structuring
>>> the manual according to audience.
>>
>> This is precisely what I'm advocating.
>
> Um, I don't think it is. You originally said:
>
> "So Proposal is: https://wiki.gnome.org/GnomeLove/BuildGnome
>
> is the only documentation on wiki.gnome.org, the rest gets retired and
> merged into jhbuild documentation."
>
> What I'm suggesting, and what Fred and Carlos seem to have done, is
> that BuildGnome gets merged into the official manual. This makes the
> manual the canonical place for documentation, whether it is for new
> GNOME contributors, or for more generic JHBuild usage.
>

Ah, sorry I was confused.  I think the reason I was confused is that
the documentation BuildGnome is separate wiki space from the manual.
So while maybe that content is in the manual it wasn't obvious to me
from what was presented.

I think though, as someone else further in the thread said, we want to
make a distinction between 'quick start' and the manual.

So, let's try to get something actionable.  Do folks agree that we
should have two pieces - the manual and the quick start where the
quickstart is the BuildGnome documentation maintained by Carlos and
the JHBuild manual supported by the community.

If we agree, then we can work with the folks in gnome-love to archive
the old documentation and merge the content into the manual.

sri

> Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[Jim Nelson]

One of Philip's earlier suggestions was to print a console warning if a 
sync call is used.  That seems like overkill to me, but it does lead to 
another possibility.


Technically the issue is long synchronous calls blocking the event 
loop, but in practice the problem is GTK+'s events being starved.  
Perhaps a more feasible solution would be to issue a console warning 
when a paint or resize event sits on the event loop for too long.


At the end of the day, async is something you design for, it doesn't 
just happen (especially in straight-up imperative languages like C and 
C++).  No matter how many console warnings, documentation exclamation 
marks, or API changes are made, it's all about getting developers to 
treat I/O like event-driven programming.  I know Jasper wishes apps 
would only paint in the draw signal; getting everyone on-board with 
pure-async code is a similar crusade.


-- Jim


On Wed, Feb 11, 2015 at 7:04 AM, Ross Lagerwall 
 wrote:
On Wed, Feb 11, 2015 at 2:46 PM, Ray Strode  
wrote:

 Hi,

 On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall 
 wrote:
 It might turn out that runtime checks are just not feasible, but 
in that
 case I think we still need some way of solving the original 
problem:

 that people are using sync calls and blocking up the main loop.

 I'm all for discouraging sync use in the main thread after the
 application is up, but
 are stalled applications actually a wide spread problem? I don't
 really remember any
 apps I use regularly locking up (except for maybe hexchat when 
connecting to my

 irc proxy).  Granted, it's harder to notice these days now that we
 have a compositor
 and applications don't need to redraw after getting uncovered, so it
 could be it's
 happening more than is obvious.  But, I just wonder if we really 
need

 to do anything.
 It seems like the bad/obvious cases would get bug reports and fixes
 pretty quickly,
 and so the problem should regulate itself.



There are quite often gvfs or Nautilus bug reports that say "network 
mount

causes desktop to slow down". I tracked it down to some gnome-shell
extension which somehow does sync calls to the remote fs which makes
everything crawl.

In general though I think severe warnings on the documentation for 
each sync

call is better than runtime warnings or compile-time warnings.

Ross
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Commit auto-links in bugzilla comments

[Jasper St. Pierre]

Out of curiosity, is there anything wrong with just copy/pasting a link?
You know, something like

https://git.gnome.org/browse/gnome-shell/commit/?id=d54b87c4559bd9d74fa10d3e3d1e38a933bea051

I find that trying to remember crazy syntax and exceptions is a bit
difficult. Does it work inside parens with immediate closing like "(see
also comment #13)"? Does it work with and without the number sign? After a
line-break, one like Bugzilla likes to auto-add? I've ran into so many
exceptions it's hard to remember what's valid.

On Wed, Feb 11, 2015 at 9:43 AM, Xavier Claessens 
wrote:

> Le mardi 10 février 2015 à 08:38 +0100, Milan Crha a écrit :
> > Hello,
> > I'd like to ask: how does the auto-links for commits in the new
> > bugzilla work? I mean, if I write something like:
> >commit abcde12345
> > then the "abcde12345" will become a link to the sources in the product
> > the current bug is filled for. It works similarly to bug auto-link
> > references, which is nice.
>
> Related to this, I've proposed to also link "branch wip/..." in this
> bug: https://bugzilla.gnome.org/show_bug.cgi?id=744068
>
> > My problem is when one change for a product A requires also a change
> > in product B and I reference commits for both products within one bug
> > report. That may cause one of the commit links invalid.
> >
> > 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?
>
> If we come with a way to specify the module, would be nice to adapt my
> patch likewise :)
>
> Regards,
> Xavier Claessens.
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Commit auto-links in bugzilla comments

[Xavier Claessens]

Le mardi 10 février 2015 à 08:38 +0100, Milan Crha a écrit :
> Hello,
> I'd like to ask: how does the auto-links for commits in the new 
> bugzilla work? I mean, if I write something like:
>commit abcde12345
> then the "abcde12345" will become a link to the sources in the product 
> the current bug is filled for. It works similarly to bug auto-link 
> references, which is nice.

Related to this, I've proposed to also link "branch wip/..." in this
bug: https://bugzilla.gnome.org/show_bug.cgi?id=744068

> My problem is when one change for a product A requires also a change 
> in product B and I reference commits for both products within one bug 
> report. That may cause one of the commit links invalid.
> 
> 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?

If we come with a way to specify the module, would be nice to adapt my
patch likewise :)

Regards,
Xavier Claessens.



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Commit auto-links in bugzilla comments

[Xavier Claessens]

Le mardi 10 février 2015 à 08:38 +0100, Milan Crha a écrit :
> Hello,
> I'd like to ask: how does the auto-links for commits in the new 
> bugzilla work? I mean, if I write something like:
>commit abcde12345
> then the "abcde12345" will become a link to the sources in the product 
> the current bug is filled for. It works similarly to bug auto-link 
> references, which is nice.

Related to this, I've proposed to also link "branch wip/..." in this
bug: https://bugzilla.gnome.org/show_bug.cgi?id=744068

> My problem is when one change for a product A requires also a change 
> in product B and I reference commits for both products within one bug 
> report. That may cause one of the commit links invalid.
> 
> 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?

If we come with a way to specify the module, would be nice to adapt my
patch likewise :)

Regards,
Xavier Claessens.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[Ross Lagerwall]

On Wed, Feb 11, 2015 at 2:46 PM, Ray Strode  wrote:
> Hi,
>
> On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall  
> wrote:
>> It might turn out that runtime checks are just not feasible, but in that
>> case I think we still need some way of solving the original problem:
>> that people are using sync calls and blocking up the main loop.
> I'm all for discouraging sync use in the main thread after the
> application is up, but
> are stalled applications actually a wide spread problem? I don't
> really remember any
> apps I use regularly locking up (except for maybe hexchat when connecting to 
> my
> irc proxy).  Granted, it's harder to notice these days now that we
> have a compositor
> and applications don't need to redraw after getting uncovered, so it
> could be it's
> happening more than is obvious.  But, I just wonder if we really need
> to do anything.
> It seems like the bad/obvious cases would get bug reports and fixes
> pretty quickly,
> and so the problem should regulate itself.
>

There are quite often gvfs or Nautilus bug reports that say "network mount
causes desktop to slow down". I tracked it down to some gnome-shell
extension which somehow does sync calls to the remote fs which makes
everything crawl.

In general though I think severe warnings on the documentation for each sync
call is better than runtime warnings or compile-time warnings.

Ross
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[Ray Strode]

Hi,

On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall  wrote:
> It might turn out that runtime checks are just not feasible, but in that
> case I think we still need some way of solving the original problem:
> that people are using sync calls and blocking up the main loop.
I'm all for discouraging sync use in the main thread after the
application is up, but
are stalled applications actually a wide spread problem? I don't
really remember any
apps I use regularly locking up (except for maybe hexchat when connecting to my
irc proxy).  Granted, it's harder to notice these days now that we
have a compositor
and applications don't need to redraw after getting uncovered, so it
could be it's
happening more than is obvious.  But, I just wonder if we really need
to do anything.
It seems like the bad/obvious cases would get bug reports and fixes
pretty quickly,
and so the problem should regulate itself.

--Ray
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feedback from downstreams presentation from DX hackfest 2015

[Bastien Nocera]

On Wed, 2015-02-11 at 14:21 +0100, Murray Cumming wrote:
> On Tue, 2015-02-10 at 16:11 +, Philip Withnall wrote:
> > Problems building SQL and SPARQL queries
> >  • https://bugzilla.gnome.org/show_bug.cgi?id=741777
> >  • SQLite: can’t think of a decent way of fixing this
> 
> libgda has the GdaSQLBuilder API. It's a bit odd, but it works, and
> handles different SQL dialects:
> https://developer.gnome.org/libgda/stable/GdaSqlBuilder.html#GdaSqlBuilder.description
> 
> I think it's a bit nicer in the (my) C++ wrapper, though it's
> documentation there is a bare minimum:
> https://developer.gnome.org/libgdamm/unstable/classGnome_1_1Gda_1_1SqlBuilder.html#details
> 
> I use the C++ version lots in Glom.
> 
> At the least, it's a big help to avoid SQL injection that can creep in
> when you just concatenate strings.
> 
> I would never use any database API without using some abstraction layer
> such as libgda. They are all far too strange. I'd rather port one day
> from one sane abstraction layer to another sane abstraction layer than
> from some gnarly specific database API to one that's just gnarly in
> another way.

I tried using libgda from both C and Javascript, and it was an absolute
pain to get going. Which is why I ended up working on gom.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feedback from downstreams presentation from DX hackfest 2015

[Murray Cumming]

On Tue, 2015-02-10 at 16:11 +, Philip Withnall wrote:
> Problems building SQL and SPARQL queries
>  • https://bugzilla.gnome.org/show_bug.cgi?id=741777
>  • SQLite: can’t think of a decent way of fixing this

libgda has the GdaSQLBuilder API. It's a bit odd, but it works, and
handles different SQL dialects:
https://developer.gnome.org/libgda/stable/GdaSqlBuilder.html#GdaSqlBuilder.description

I think it's a bit nicer in the (my) C++ wrapper, though it's
documentation there is a bare minimum:
https://developer.gnome.org/libgdamm/unstable/classGnome_1_1Gda_1_1SqlBuilder.html#details

I use the C++ version lots in Glom.

At the least, it's a big help to avoid SQL injection that can creep in
when you just concatenate strings.

I would never use any database API without using some abstraction layer
such as libgda. They are all far too strange. I'd rather port one day
from one sane abstraction layer to another sane abstraction layer than
from some gnarly specific database API to one that's just gnarly in
another way.

-- 
Murray Cumming
murr...@murrayc.com
www.murrayc.com



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Canonical jhbuild documentation

[Ekaterina Gerasimova]

On 11/02/2015, Frederic Peters  wrote:
> Allan Day wrote:
>
>> > It would be nice if somebody could contact the authors:
>> >   James Henstridge 
>> >   C.J. Adams-Collier 
>> >   Frederic Peters (ok, done)
>> >   David Turner (Cillian64, from GHOP, back in 2007/2008, I can't
>> > find an email)
>>
>> Oh that's great - thanks Fred. Is there a bug or some other place
>> where the license update is being tracked? We'll need a way to record
>> the consent of the original authors, if I'm not mistaken.
>
> There's no tracking for that, but yes there should be.

When re-licensing documentation, the docs team usually files a bug
with a relicense patch attached. All the original authors are then
asked to sign off this patch and re-upload it.

For an example, see https://bugzilla.gnome.org/show_bug.cgi?id=703238
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Canonical jhbuild documentation

[Frederic Peters]

Allan Day wrote:

> > It would be nice if somebody could contact the authors:
> >   James Henstridge 
> >   C.J. Adams-Collier 
> >   Frederic Peters (ok, done)
> >   David Turner (Cillian64, from GHOP, back in 2007/2008, I can't
> > find an email)
> 
> Oh that's great - thanks Fred. Is there a bug or some other place
> where the license update is being tracked? We'll need a way to record
> the consent of the original authors, if I'm not mistaken.

There's no tracking for that, but yes there should be.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Canonical jhbuild documentation

[Frederic Peters]

Germán Poo-Caamaño wrote:

> IMHO, the jhbuild documentation is more like a reference manual, whereas
> the information for newcomers is like a tutorial (or expected to be).

Indeed it's mostly like that at the moment.


> Maybe both could be in the same documentation/place, but the separation
> between both approaches should be clear.

That's what I tried, doing at the same time the conversion from
docbook to mallard, https://people.gnome.org/~fpeters/jhbuild-mallard/

The introduction text could be make shorter, to bring the "getting
started" part closer to the top.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Canonical jhbuild documentation

[Germán Poo-Caamaño]

On Wed, 2015-02-11 at 12:33 +, Allan Day wrote:
> Sriram Ramkrishna  wrote:
> [...]
> Um, I don't think it is. You originally said:
> 
> "So Proposal is: https://wiki.gnome.org/GnomeLove/BuildGnome
> 
> is the only documentation on wiki.gnome.org, the rest gets retired and
> merged into jhbuild documentation."
> 
> What I'm suggesting, and what Fred and Carlos seem to have done, is
> that BuildGnome gets merged into the official manual. This makes the
> manual the canonical place for documentation, whether it is for new
> GNOME contributors, or for more generic JHBuild usage.

IMHO, the jhbuild documentation is more like a reference manual, whereas
the information for newcomers is like a tutorial (or expected to be).

Maybe both could be in the same documentation/place, but the separation
between both approaches should be clear.

A reference manual is not as useful as a tutorial when somebody is
giving its first steps on a learning process.

-- 
Germán Poo-Caamaño
http://calcifer.org/

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Canonical jhbuild documentation

[Allan Day]

Sriram Ramkrishna  wrote:
...
>> Seems like you should talk this through with Carlos and Ryan - they're
>> the effective maintainers of the wiki pages in question. I know that
>> Carlos is keen to reduce the amount of duplication.
>
> Yes, I sent this email after consulting with him and Fred.

I assume that "him" is Carlos? Maybe you should talk to Ryan also, if
that's the case.

>> 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
>> impression that there has been resistance to this in the past, due to
>> the desire to keep Jhbuild as a somewhat generic tool. However, I
>> don't see how the two use cases (Jhbuild for new GNOME contributors,
>> and Jhbuild for everyone else) couldn't be satisfied by structuring
>> the manual according to audience.
>
> This is precisely what I'm advocating.

Um, I don't think it is. You originally said:

"So Proposal is: https://wiki.gnome.org/GnomeLove/BuildGnome

is the only documentation on wiki.gnome.org, the rest gets retired and
merged into jhbuild documentation."

What I'm suggesting, and what Fred and Carlos seem to have done, is
that BuildGnome gets merged into the official manual. This makes the
manual the canonical place for documentation, whether it is for new
GNOME contributors, or for more generic JHBuild usage.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Canonical jhbuild documentation

[Allan Day]

Frederic Peters  wrote:
...
> I believe this is no longer a problem; when I tried to merge the
> by-then new "BuildGnome" page into the manual, and converting it to
> Mallard, the primary problem was of license incompatibility between
> the contents from the wiki and the existing manual.
>
> It would be nice if somebody could contact the authors:
>   James Henstridge 
>   C.J. Adams-Collier 
>   Frederic Peters (ok, done)
>   David Turner (Cillian64, from GHOP, back in 2007/2008, I can't
> find an email)


Oh that's great - thanks Fred. Is there a bug or some other place
where the license update is being tracked? We'll need a way to record
the consent of the original authors, if I'm not mistaken.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[Philip Withnall]

On Tue, 2015-02-10 at 15:48 +0100, Lennart Poettering wrote:
> > > Also, glib has wrappers for making mmaping available to programs, to
> > > improve seldom-accessed sparse databases efficient, do you want to
> > > prohibit that too?
> > 
> > No, mmap() is clearly a tool for a different kind of problem. If you’re
> > accessing an mmap()ed file, you need to be sure it’s local anyway, I
> > think? GMappedFile doesn’t have async versions of its methods,
> > presumably for this reason.
> 
> mmap() works pretty Ok these days over NFS. Concurrent access
> doesn't. But as long as you just want to access something, it's
> fine...
> 
> That said it's probably not a good idea to use mmap() for stuff below
> $HOME...

OK, that’s good to know. In any case, GMappedFile doesn’t have async
methods, so it’s a moot point.

> > As above, how about making that line the distinction between calling
> > functions from gstdio.h and using GIO? In the former case, you know
> > you’re operating on local files. In the latter, you could be operating
> > on files from the moon.
> 
> I'd always leave some freedom for the developers. It is certainly good
> to document things and push people into the right directions, but I
> think there are many cases where the developer should have every right
> to prefer sync access for valid reasons, even from the main loop...

I understand where you’re coming from; we should not be irritating
experienced developers. I completely agree.

What do you think of the proposal to use sync gstdio.h for
small/local/pseudo-file-system I/O and async GIO for all other I/O?

It might turn out that runtime checks are just not feasible, but in that
case I think we still need some way of solving the original problem:
that people are using sync calls and blocking up the main loop.

Philip


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Discouraging use of sync APIs

[Philip Withnall]

On Tue, 2015-02-10 at 10:30 -0800, Jasper St. Pierre wrote:
> 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 equivalent of memcpy.

That’s not good at all, and seems like it should be easy to fix by
overriding the read_async vfunc for GResourceFile. Is there a bug filed
about it?

Philip

> On Tue, Feb 10, 2015 at 8:49 AM, Jasper St. Pierre
>  wrote:
> 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 a large file, and then a small file, the large
> file needs to fully complete before the small file is
> dispatched from the async queue.
> 
> Additionally, when profiling GNOME on ARM, I've been seeing a
> lot of cases of users using g_file_read_async() "just in case"
> for no particular reason, which causes several locks to be
> taken, severely slowing performance.
> 
> 
> We need to seriously improve our async performance before
> asking people to use it.
> 
> 
> On Tue, Feb 10, 2015 at 6:48 AM, Lennart Poettering
>  wrote:
> 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 dispatching things to
> background threads, and
> > > back...
> >
> > The problem is that GIO can’t know which accesses
> are to small, local
> > files, and which aren’t. It already optimises reads
> from pollable
> > streams (sockets) by keeping them in the main thread
> and adding them
> > into the main poll() call.
> 
> Well, but the developer frequently knows that. He
> knows that the
> config file in ~/.config is not going to be more than
> a few K. And
> that it hence is fine to access it synchronously...
> 
> > > Also, glib has wrappers for making mmaping
> available to programs, to
> > > improve seldom-accessed sparse databases
> efficient, do you want to
> > > prohibit that too?
> >
> > No, mmap() is clearly a tool for a different kind of
> problem. If you’re
> > accessing an mmap()ed file, you need to be sure it’s
> local anyway, I
> > think? GMappedFile doesn’t have async versions of
> its methods,
> > presumably for this reason.
> 
> mmap() works pretty Ok these days over NFS. Concurrent
> access
> doesn't. But as long as you just want to access
> something, it's
> fine...
> 
> That said it's probably not a good idea to use mmap()
> for stuff below
> $HOME...
> 
> > As above, how about making that line the distinction
> between calling
> > functions from gstdio.h and using GIO? In the former
> case, you know
> > you’re operating on local files. In the latter, you
> could be operating
> > on files from the moon.
> 
> I'd always leave some freedom for the developers. It
> is certainly good
> to document things and push people into the right
> directions, but I
> think there are many cases where the developer should
> have every right
> to prefer sync access for valid reasons, even from the
> main loop...
> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat
> ___
> deskto

Re: Discouraging use of sync APIs

[Philip Withnall]

On Tue, 2015-02-10 at 08:49 -0800, Jasper St. Pierre wrote:
> 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 a large file, and then a small file, the large file needs to
> fully complete before the small file is dispatched from the async
> queue.

From my reading of the GTask code, it should support 10 parallel reads
(or other operations) since it uses a thread pool with maximum 10
threads. See g_task_thread_pool_init(). Is this not the case?

> Additionally, when profiling GNOME on ARM, I've been seeing a lot of
> cases of users using g_file_read_async() "just in case" for no
> particular reason, which causes several locks to be taken, severely
> slowing performance.

I guess the particular reason depends on what’s being read, as discussed
in the rest of the thread.

> We need to seriously improve our async performance before asking
> people to use it.

That’s important, but I wouldn’t say it’s a blocker. The original idea
of this thread was to try and address the situation where non-expert
developers are using sync APIs when they should be using async ones, and
then tying themselves in all sorts of knots. I suspect that hitting
these sorts of performance problems is not going to be an issue for them
— but freezing up the main loop is.

I could be wrong, but that’s how I see it.

Philip

> On Tue, Feb 10, 2015 at 6:48 AM, Lennart Poettering
>  wrote:
> 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 dispatching things to background
> threads, and
> > > back...
> >
> > The problem is that GIO can’t know which accesses are to
> small, local
> > files, and which aren’t. It already optimises reads from
> pollable
> > streams (sockets) by keeping them in the main thread and
> adding them
> > into the main poll() call.
> 
> Well, but the developer frequently knows that. He knows that
> the
> config file in ~/.config is not going to be more than a few K.
> And
> that it hence is fine to access it synchronously...
> 
> > > Also, glib has wrappers for making mmaping available to
> programs, to
> > > improve seldom-accessed sparse databases efficient, do you
> want to
> > > prohibit that too?
> >
> > No, mmap() is clearly a tool for a different kind of
> problem. If you’re
> > accessing an mmap()ed file, you need to be sure it’s local
> anyway, I
> > think? GMappedFile doesn’t have async versions of its
> methods,
> > presumably for this reason.
> 
> mmap() works pretty Ok these days over NFS. Concurrent access
> doesn't. But as long as you just want to access something,
> it's
> fine...
> 
> That said it's probably not a good idea to use mmap() for
> stuff below
> $HOME...
> 
> > As above, how about making that line the distinction between
> calling
> > functions from gstdio.h and using GIO? In the former case,
> you know
> > you’re operating on local files. In the latter, you could be
> operating
> > on files from the moon.
> 
> I'd always leave some freedom for the developers. It is
> certainly good
> to document things and push people into the right directions,
> but I
> think there are many cases where the developer should have
> every right
> to prefer sync access for valid reasons, even from the main
> loop...
> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> 
> 
> -- 
>   Jasper
> 



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list