Port your module from g_memdup() to g_memdup2() now

Hi all, GLib 2.67.3 will be released shortly with a new g_memdup2() API to replace the old g_memdup() API. Please port to using g_memdup2() as soon as possible: g_memdup() will be deprecated in GLib 2.67.4. The old API took the size of the memory to duplicate as a guint, whereas most memory

Re: Reminder: action required when updating dependencies or build options

On Thu, 2021-01-14 at 11:57 +0100, Benjamin Berg wrote: > On Wed, 2021-01-13 at 15:57 -0600, Michael Catanzaro wrote: > On Wed, Jan 13, 2021 at 9:28 pm, Philip Withnall > wrote: > > Given that you’ve just committed to submitting MRs and waiting for > > CI > > t

Re: Reminder: action required when updating dependencies or build options

On Wed, 2021-01-13 at 15:15 -0600, Michael Catanzaro wrote: >  > And similar behaviour over the years where you seemed to be under > the >  > impression that I was the only person in GNOME that felt that > peer- >  > reviewed patches and CI-gated merge requests were a requirement. >  > >  > Until

Re: Reminder: action required when updating dependencies or build options

On Tue, 2021-01-12 at 09:31 -0600, Michael Catanzaro wrote: > Hi developers, > > Please remember that action is required when updating your > dependencies > or build options. You need to either make sure gnome-build-meta is OK > with your changes, or ask release team to investigate on your

Re: Changes to GitLab runners configuration

On Wed, 2020-02-19 at 13:14 -0600, Michael Catanzaro wrote: > On Wed, Feb 19, 2020 at 8:00 pm, Sam Thursfield > wrote: > > We've been using podman successfully to build the Tracker CI > > images. > > The exact build instructions are here: > > > > > >

Re: Maintainers should announce build-related changes in their modules

On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote: > On Thu, 12 Sep, 2019 at 19:08, Philip Withnall < > phi...@tecnocode.co.uk> wrote: > > That sounds like something people are going to forget to do. Would > > it be possible to use computers to automate this? >

Re: Maintainers should announce build-related changes in their modules

On Thu, 2019-09-12 at 18:54 +0100, Emmanuele Bassi via desktop-devel- list wrote: > Hi all; > > the 3.34 release is out of the door, but before we go into the 3.35 > development cycle, the release team would like to kindly ask **all** > GNOME maintainers to send an email to release-t...@gnome.org

gtester support deprecated in GLib

Hi all, A quick notification: the `gtester` utility, and support for its format for outputting results from unit tests, has been deprecated in GLib. https://gitlab.gnome.org/GNOME/glib/issues/1441 `gtester` is a test harness, and has been de-facto deprecated for a long time, but now it will

Re: GitLab postmortem

On Sun, 2018-12-23 at 17:21 +, Philip Withnall wrote: > On Wed, 2018-12-19 at 16:48 +0000, Philip Withnall wrote: > > On Wed, 2018-12-19 at 14:37 +0000, Philip Withnall wrote: > > > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > > > Hey, > > &

Re: GitLab postmortem

On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list wrote: > On Wed, 2018-12-19 at 14:37 +0000, Philip Withnall wrote: > > 3. I’d like to see continued movement towards disallowing direct > > pushes to git, and requiring all commits to go through MRs (and > &g

Re: GitLab postmortem

On Wed, 2018-12-19 at 16:48 +, Philip Withnall wrote: > On Wed, 2018-12-19 at 14:37 +0000, Philip Withnall wrote: > > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > > Hey, > > > It has been a few months since we moved to GitLab. Apart of > > >

Re: GitLab postmortem

On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > Hey, > > It has been a few months since we moved to GitLab. Apart of > > spurious issues, specific annoyances and frustrations, seems it has > > b

Re: GitLab postmortem

On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > Hey, > It has been a few months since we moved to GitLab. Apart of spurious > issues, specific annoyances and frustrations, seems it has been > generally good. I would like to gather some general feeling about it. > Things that really made

Re: [GitLab] Fast CI is now available for all projects under gitlab.gnome.org

Great, thanks to Packet.net, OSU and the sysadmin/GitLab team! Let’s test more things. On Fri, 2018-11-16 at 13:29 +0100, Carlos Soriano wrote: > We still have other donations that are very useful to us, as we > really shouldn't rely on a single or only a few sources. So still, > many thanks to

Heads up: potential hash table ordering changes in GLib

Hi all, As a heads up, we’ve just merged some performance improvements to GHashTable, done by Hans Petter Jansson: https://gitlab.gnome.org/GNOME/glib/merge_requests/208 https://gitlab.gnome.org/GNOME/glib/issues/1198 https://hpjansson.org/blag/2018/08/29/what-ails-ghashtable/

GLib BoF session at GUADEC

There will be a GLib BoF session all day on the 9th of July in room 2 of GUADEC, subverting part of the GTK+ BoF: https://wiki.gnome.org/GUADEC/2018/Hacking%20days/GtkBOF Come along if you’re interested in GLib, GIO, GObject. We’ll be assessing the status of the 2.58 release, and starting to

Re: GitLab CI runners for non-Linux systems

On Wed, 2018-05-30 at 00:59 +0800, 藍挺瑋 wrote: > 於 星期一，2018-05-28 於 12:09 -0400，xclae...@gmail.com 提到： > > Hi, > > > > We now have 6 arch tested for glib, all with Meson. > > > > - macosx-10.13-meson-x86_64 > > * Native macosx 10.13 build > > * Fails to build with --werror, if anyone wants to

Re: Migration of GNOME to GitLab is now completed

On Tue, 2018-05-29 at 19:00 +0200, Carlos Soriano wrote: > Hello all, > > I'm glad to announce that the GNOME migration to GitLab is now > completed! Big thanks Carlos! And thank you too to everyone else who helped out, including the sysadmins and the original team who looked at code hosting

Re: GitLab CI runners for non-Linux systems

On Wed, 2018-05-23 at 10:03 -0700, Alan Coopersmith wrote: > On 05/23/18 09:40 AM, Philip Withnall wrote: > > On Wed, 2018-05-23 at 16:19 +0200, Christoph Reiter wrote: > > > On Mon, May 21, 2018 at 5:54 PM, Alan Coopersmith > > > <alan.coopersm...@oracle.com> wr

Re: GitLab CI runners for non-Linux systems

On Wed, 2018-05-23 at 16:19 +0200, Christoph Reiter wrote: > On Mon, May 21, 2018 at 5:54 PM, Alan Coopersmith > <alan.coopersm...@oracle.com> wrote: > > On 05/18/18 02:52 AM, Philip Withnall wrote: > > > Can anybody else provide and maintain CI runner

Re: GitLab CI runners for non-Linux systems

On Sat, 2018-05-19 at 20:41 +1000, Jonathan Matthew wrote: > On Fri, May 18, 2018 at 10:52:18AM +0100, Philip Withnall wrote: > > > > Can anybody else provide and maintain CI runners for other > > platforms? > > I’d particularly like to see: > > • *BSD (probably

Re: GitLab CI runners for non-Linux systems

On Fri, 2018-05-18 at 09:21 -0400, philip.chime...@gmail.com wrote: > On Fri, May 18, 2018 at 5:52 AM Philip Withnall <phi...@tecnocode.co. > uk> wrote: > > Can anybody else provide and maintain CI runners for other > > platforms? > > I’d particularly like to see:

Re: GitLab CI runners for non-Linux systems

. I honestly don’t know whether that would be a little, or a lot, of work. Philip > Le vendredi 18 mai 2018 à 19:16 +0530, Arun Raghavan a écrit : > > On 18 May 2018 at 18:51, <philip.chime...@gmail.com> wrote: > > > On Fri, May 18, 2018 at 5:52 AM Philip Withnall <phil

GitLab CI runners for non-Linux systems

Hi all, tl;dr: Want to provide us with a GitLab CI runner for a non-Linux platform? There’s been a surge of interest recently, from various directions, in getting GLib better tested on non-Linux architectures. This is great, and we’ve got various people to thank for doing the thankless work of

Re: Dropping python 2.7 support in gtk-doc (requiring python 3.X)

On Fri, 2018-03-30 at 13:24 +0200, Stefan Sauer wrote: > To also give some extra motivation - Since a few month I am working > on > gtkdoc-mkhtml which is a pure python drop-in replacement for > gtkdoc-mkhtml+gtkdoc-fixxref. This is not using docbook xslt anymore > and > it won't shell out to

Re: Let's kill gnome-common!

On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote: > Hi Michael, > > Could you give some context and explanation on this? I could take the > gnome-autoar, but need to know why this is wanted and the alternative > to gnome-common. Handily all written up a while ago:

Re: About lib version and git

On Wed, 2018-01-17 at 11:49 +0100, Daniel Garcia Moreno wrote: > On Tue, Jan 16, 2018 at 9:35 PM, Philip Withnall <phi...@tecnocode.co > .uk> wrote: > > On Tue, 2018-01-16 at 12:17 -0600, Federico Mena Quintero wrote: > > > It doesn't really matter when you do it. T

Re: About lib version and git

On Tue, 2018-01-16 at 12:17 -0600, Federico Mena Quintero wrote: > It doesn't really matter when you do it. There are some important > things: > > * Make sure the new header files are parallel-installable with the > old > ones. > > * Make sure the soname in the library changes. Grep for

g_object_ref() now propagates types

Hi all, We just landed a patch in GLib which propagates the type from the argument of g_object_ref() to its return type: https://git.gnome.org/browse/glib/commit/?id=3fae39a5d https://bugzilla.gnome.org/show_bug.cgi?id=790697 The idea here is that it will catch invalid implicit casts which the

Re: Meson support in Continuous

On Fri, 2017-12-01 at 14:39 +, Emmanuele Bassi wrote: > On 29 November 2017 at 21:12, Emmanuele Bassi > wrote: > > > The build bot is currently busy rebuilding the whole of the > > manifest, > > and I'm going to babysit it for a little while, so don't start > > removing

Re: gtk-doc output options

On Sun, 2017-11-12 at 17:08 +0100, Stefan Sauer wrote: > Since people regular illy complain about the slowness of gtk-doc I'd > like to evaluate some options. First the slowness is due to using the > docbook-xsl stylesheets to produce html/pdf and optionally man pages. > One main to get a huge

Re: GitLab status update

On Fri, 2017-09-08 at 18:11 +0200, Carlos Soriano wrote: > Hey Philip, > > Glad you like it! :) > > A question from the ignorance, does two factor authentication plays a > role if you use LDAP? If not, probably it's not very useful for the > contributors here around, since we are supposed to use

Re: GitLab status update

On Mon, 2017-09-04 at 15:42 +0200, Carlos Soriano wrote: > Hello all, > > I'm happy to announce our GitLab instance at https://gitlab.gnome.org > /GNOME/ is now officially open to host GNOME projects! Yay! Thanks to everyone who’s worked on this. :-) A reminder that gitlab supports 2-factor

Re: Updating GNOME Goals?

On Thu, 2017-08-24 at 09:20 +0200, Daniel Mustieles García wrote: > Hi, > > Some additional comments: > > - /RemoveMarkupInMessages: it makes no sense to set a goal for this, > because a fixed module today might change tomorrow, introducing new > strings with markup. Maybe should be set as a

Re: GNOME Initiatives

On Tue, 2017-08-22 at 18:50 +, Sriram Ramkrishna wrote: > Looks like GNOME Initiatives could use with some updating as well. > There are some that are current and some that might need to be > revisited. For instance: > > Document Centric GNOME > Memory Reduction Memory reduction would be a

Re: Proposal to deploy GitLab on gnome.org

On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > In recent months we have got together to examine the possibilities > for GNOME’s development infrastructure. We’ve spent a lot of time on > this, because we want the community to have faith in our conclusions. > If you are interested in this,

Re: About maintenance of Bijiben

Hey, On Fri, 2017-03-03 at 06:09 +, Jonathan Kang wrote: > Michael Catanzaro mentioned that Bijiben(GNOME Notes) is the state of > lacking > maintenance in his post[1]. And I'd like to spend some time to make > it a better > application(at least one that CAN be released with GNOME release >

Re: GitHub Development Platform for GNOME

On Mon, 2017-04-10 at 14:09 -0400, Nicolas Dufresne wrote: > Le lundi 10 avril 2017 à 01:25 +0530, Nirbheek Chauhan a écrit : > > On Mon, Apr 10, 2017 at 1:14 AM, Walter Vargas > co > > m> wrote: > > > I want to share my humble opinion and thoughts about > > > GitHub/GitLab:

Re: GNOME goal candidates

On Wed, 2017-03-01 at 13:40 +, Emmanuele Bassi wrote: > On 1 March 2017 at 13:26, Michael Catanzaro <mcatanz...@gnome.org> > wrote: > > It sounds like most everyone else supports installed tests. OK, > > then. > > > > On Wed, 2017-03-01 at 10:22 +,

Re: GNOME goal candidates

On Wed, 2017-03-01 at 07:26 -0600, Michael Catanzaro wrote: > It sounds like most everyone else supports installed tests. OK, then. > > On Wed, 2017-03-01 at 10:22 +0000, Philip Withnall wrote: > > I agree that developers need to be engaged with adding more unit > > tests

Re: GNOME goal candidates

Hi, On Tue, 2017-02-28 at 17:12 -0600, Michael Catanzaro wrote: > Hi, *snip* > GtkBuilder validation looks like more gook to add to our Automake > files, when we really want less gook there. Even if it's only a small > amount of code, I'd rather it be implemented as an autoconf archive > macro

Re: GNOME goal candidates

On Tue, 2017-02-28 at 18:05 -0600, Michael Catanzaro wrote: > Ah yeah, don't cancel your plans for nautilus. > > Regarding coverage. Most of our modules are core modules; we have a > lot > of them. I don't think we have the resources right now to write tests > and obtain high coverage for more

Re: Documentation for build system setup

On Thu, 2017-02-09 at 08:52 -0600, Michael Catanzaro wrote: > On Thu, 2017-02-09 at 15:12 +0100, Sebastian Geiger (Lanoxx) wrote: > > One more question: > > > > The sample autogen.sh on https://wiki.gnome.org/Projects/GnomeCommo > > n/ > > Migration also explicitly calls aclocal like this: > > >

Re: Documentation for build system setup

tize --force --copy || exit 1 > > > > > > If you are still using the almost obsolete intltoolize, then add > > > the following line immediately before > > > autoreconf: > > > > > > intltoolize --force --copy --automake || exit 1 > > > >

Re: Documentation for build system setup

On Thu, 2017-02-09 at 10:32 +, Emmanuele Bassi wrote: > Hi; > > On 9 February 2017 at 09:56, Sebastian Geiger (Lanoxx) t> wrote: > > > It would be great to have an additional entry on this > > page that is maybe named "build automation" or "building the > > application" and

Re: Tracker as a security risks

Hey, On Mon, 2016-12-05 at 16:42 +0100, Carlos Garnacho wrote: > On Mon, Dec 5, 2016 at 3:01 PM, Hanno Böck wrote: > > On Mon, 5 Dec 2016 13:44:40 + > > Sam Thursfield wrote: > > > > > The design of Tracker takes the risks into account. Metadata > > >

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

On Mon, 2016-10-10 at 10:49 +0200, Sebastian Geiger (Lanoxx) wrote: > On 05/10/16 15:39, Michael Biebl wrote: > > > > > As much as I hate autotools and its arcane syntax, it does bring > > uniformity and consistency. > > Atm I'm counting waf (for some non-core modules), autotools, cmake and > >

Re: Testing for memory safety issues with Address Sanitizer

Hi, On Mon, 2016-09-19 at 12:03 +0200, Hanno Böck wrote: > I recently reported a couple of bugs to GNOME-components that were > easily discovered with a feature called Address Sanitizer (asan): > https://bugzilla.gnome.org/show_bug.cgi?id=762417 (glib) >

Re: g_log_structured() and introspection

Hey, On Sat, 2016-08-13 at 01:49 -0400, Ray Strode wrote: > > > > During the talk on GLib's new structured logging API at GUADEC > > today, > > it was pointed out that g_log_structured() (and the rest of the > > interesting bits of the new structured logging API) are not > > introspectable. > >

g_log_structured() and introspection

Hi all, During the talk on GLib's new structured logging API at GUADEC today, it was pointed out that g_log_structured() (and the rest of the interesting bits of the new structured logging API) are not introspectable. I'm not sure what we can do about this. The API is based around GLogField,

Re: librest API/ABI breakage

Hey, On Thu, 2016-07-14 at 14:55 +0200, Christophe Fergeau wrote: > This is just a headsup that we are about to merge some changes to > librest master which are going to break API/ABI. Main goal is to > change the async API to use GTask, but we are using this break as an > opportunity for more

Re: Keep shipping also generated gtk-doc html/ folder?

On Thu, 2016-06-23 at 10:35 +0200, Milan Crha wrote: > Hello, > while playing with developer documentation I noticed that the source > tarballs (eventually `make dist` result) contain also developer > documentation in generated form. These documentation html/ files are > not small, in case

Re: gettext

On Fri, 2016-04-22 at 08:49 +0100, Patrick Welche wrote: > All the docs for the maintainer side of i18n I found use intltool and > glib-gettext, yet I see bugzilla bugs open to use upstream gettext / > autopoint. > > Do you have a description of The Right Way(tm)? Upstream gettext and autopoint

Re: Developer experience (DX) hackfest 2016

Hi all, A reminder that the DX hackfest is happening in a little over a month, so please make sure you are signed up on the wiki page, and your transport and accommodation are sorted out! Philip On Sun, 2015-12-13 at 13:50 +, Philip Withnall wrote: > Hi all, > > Ther

Developer experience (DX) hackfest 2016

Hi all, There’s going to be a developer experience (DX) hackfest at the end of January 2016 (27–29th January) in Brussels, just before FOSDEM. This should be a really useful hackfest for pushing forward the roadmap for developer tools and toolkits in GNOME!

Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]

On Wed, 2015-11-25 at 21:40 +0100, Frederic Peters wrote: > Hi, > > Philip Withnall wrote: > > > On Wed, 2015-11-25 at 11:07 +0100, Frederic Peters wrote: > > > I'm a bit surprised by 1) but we could certainly automatically > > > produce > > > a list

Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]

On Wed, 2015-11-25 at 11:07 +0100, Frederic Peters wrote: > Bastien Nocera wrote: > > > > It's been some months we have those reminder emails sent to > > > devel-announce-list.  Maintainers, make sure you are subscribed. > > > > > > Maintainers (bis), please do try to respect the Monday 23:59

Re: Death of gnome-common

Hey, On Sun, 2015-08-16 at 11:31 +0200, Sébastien Wilmet wrote: On Thu, May 28, 2015 at 12:47:47PM +0100, Philip Withnall wrote: There’s a migration guide here: https://wiki.gnome.org/Projects/GnomeCommon/Migration We’ve tried to make the transition as easy and smooth as possible

Feedback from a happy user

One of my friends just sent me this, and I thought people might like to share in it: Since GNOME has turned 18 so is now eligible to die for its country and get a tattoo I thought it prudent to thank its developers for making my everyday computing experience a goddamn delight! Philip

Re: Death of gnome-common

On Tue, 2015-06-23 at 22:24 -0500, Michael Catanzaro wrote: On Tue, 2015-06-23 at 08:33 +0100, Philip Withnall wrote: As Kalev says, we should ensure this still builds with various distros. RHEL7 is fine. Debian stable (Jessie) has 1.14. Fedora has had ≥ 1.13 for a long time. Arch has

Re: Death of gnome-common

On Wed, 2015-06-24 at 22:38 +0200, Michael Biebl wrote: 2015-06-24 9:56 GMT+02:00 Emmanuele Bassi eba...@gmail.com: On 23 June 2015 at 23:41, Philip Withnall phi...@tecnocode.co.uk wrote: What if your module uses glib-gettext, gtk-doc, or intltool? I do hope that, if you're using

Re: Death of gnome-common

On Wed, 2015-06-24 at 08:57 -0500, Michael Catanzaro wrote: On Wed, 2015-06-24 at 14:17 +0100, Emmanuele Bassi wrote: Sadly, it's still in use for AppData XML, but for that (and any other XML-based format) there's itstool, which is also used by the documentation team for the application

Re: Death of gnome-common

On Wed, 2015-06-24 at 08:31 -0500, Michael Catanzaro wrote: On Wed, 2015-06-24 at 09:21 +0100, Philip Withnall wrote: libtoolize complains about it: libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. But I guess libtoolize is wrong

Re: Death of gnome-common

On Mon, 2015-06-22 at 10:44 -0500, Michael Catanzaro wrote: On Mon, 2015-06-22 at 16:36 +0100, Philip Withnall wrote: Do we require automake 1.13 though? Looks like it was released January 1, 2013... so we should. We *could*; doesn’t necessarily mean we *should*. Automake 2.0 isn’t out

Re: Death of gnome-common

]. Philip (the other Philip) [0]: https://bugzilla.gnome.org/show_bug.cgi?id=744864 On 23 June 2015 at 16:54, Philip Chimento philip.chime...@gmail.com wrote: On Mon, Jun 22, 2015 at 12:01 AM, Philip Withnall phi...@tecnocode.co.uk wrote: On Sun, 2015-06-21 at 17:56 -0700, Jasper St

Re: Death of gnome-common

On Sun, 2015-06-21 at 19:54 -0500, Michael Catanzaro wrote: OK, next problem. The porting guide says: Firstly, add AC_CONFIG_MACRO_DIR([m4]) to your configure.ac, and ACLOCAL_AMFLAGS = --install -I m4 ${ACLOCAL_FLAGS} to your top-level Makefile.am, regardless of which of the two

Re: Death of gnome-common

On Sun, 2015-06-21 at 17:56 -0700, Jasper St. Pierre wrote: On Thu, May 28, 2015 at 9:05 AM, Philip Withnall phi...@tecnocode.co.uk wrote: See literally the first migration item on https://wiki.gnome.org/Projects/GnomeCommon/Migration tl;dr: You can open-code it with essentially

Re: Death of gnome-common

On Sat, 2015-05-30 at 08:09 -0500, Michael Catanzaro wrote: This is a nit, but I think the 'set -x' to 'set +x' at the end of the sample autogen.sh is too expansive, since it results in the conditional tests being printed as independent statements: Good nit. Please feel free to update the wiki

Death of gnome-common

Hi all, This cycle, Dave and I are planning for the last ever release of gnome-common. A lot of its macros for deprecated technologies (scrollkeeper?!) have been removed, and the remainder of its macros have found better replacements in autoconf-archive[1], where they can be used by everyone, not

Re: Death of gnome-common

?action=showredirect=GnomeGoals 2015-05-28 13:47 GMT+02:00 Philip Withnall phi...@tecnocode.co.uk: Hi all, This cycle, Dave and I are planning for the last ever release of gnome-common. A lot of its macros for deprecated technologies

Re: Death of gnome-common

. gnome-autogen.sh On Thu, May 28, 2015 at 6:55 AM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Ok, thanks for clarifying! :) 2015-05-28 14:40 GMT+02:00 Philip Withnall phi...@tecnocode.co.uk: It’s already sort of tracked as part of the ModernAutotools goal, although

Re: Current status of the GNOME Github mirror

On Fri, 2015-05-08 at 18:47 +0200, Andrea Veri wrote: I still have to find out a way to map maintainers with their Github account as it probably differs in many cases from their respective GNOME handle. The first thing to come to mind is another element in the DOAP file, similar to how we have

Re: Current status of the GNOME Github mirror

On Wed, 2015-05-06 at 10:10 +1000, Ben Finney wrote: Philip Withnall phi...@tecnocode.co.uk writes: […] given the choice between: • a contributor giving up because Bugzilla is another account to create and another tool to learn; • a contributor using Bugzilla but badly

Re: Current status of the GNOME Github mirror

On Tue, 2015-05-05 at 18:51 +0200, Andrea Veri wrote: That said, I would like to invite anyone interested to include the sample file above on the module/s they contribute to. If you have a different opinion on how this should be managed, please follow up to this thread. I used to think that

Re: Binary compatibility and padding

On Sat, 2015-04-11 at 15:43 +0200, Juan R. Garcia Blanco wrote: Hi, In GNOME Dictionary 3.16.0, _GdictDefboxClass provided four members that are function pointers 'for future expansion'. If I understand this correctly, these four extra members act as a place holder in case we want to add a

Re: Discouraging use of sync APIs

On Thu, 2015-02-12 at 12:55 -0800, Philip Chimento wrote: On Thu, Feb 12, 2015 at 5:22 AM, Philip Withnall phi...@tecnocode.co.uk wrote: On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote: On ons, 2015-02-11 at 12:17 +, Philip Withnall wrote

Re: Discouraging use of sync APIs

On Fri, 2015-02-13 at 04:52 -0500, Colin Walters wrote: On Wed, Feb 11, 2015, at 02:33 PM, Jim Nelson wrote: 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.

Re: Discouraging use of sync APIs

On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote: On ons, 2015-02-11 at 12:17 +, Philip Withnall wrote: 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

Re: Discouraging use of sync APIs

wrote: On Wed, Feb 11, 2015 at 2:46 PM, Ray Strode halfl...@gmail.com wrote: Hi, On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall phi...@tecnocode.co.uk wrote: It might turn out that runtime checks are just not feasible, but in that case I

Re: Discouraging use of sync APIs

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 phi...@tecnocode.co.uk wrote: On Tue, 2015-02-10 at 10:30

Re: Discouraging use of sync APIs

is. I could be wrong, but that’s how I see it. Philip On Tue, Feb 10, 2015 at 6:48 AM, Lennart Poettering mzta...@0pointer.de 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

Re: Discouraging use of sync APIs

asking people to use it. On Tue, Feb 10, 2015 at 6:48 AM, Lennart Poettering mzta...@0pointer.de wrote: On Tue, 10.02.15 13:59, Philip Withnall (phi...@tecnocode.co.uk) wrote: I am pretty

Re: Discouraging use of sync APIs

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

Re: Feedback from downstreams presentation from DX hackfest 2015

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

Re: Discouraging use of sync APIs

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

Re: Discouraging use of sync APIs

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

Re: Discouraging use of sync APIs

On Mon, 2015-02-09 at 10:57 +, Debarshi Ray wrote: On Mon, Feb 09, 2015 at 10:47:37AM +, Philip Withnall wrote: I guess there are two approaches: making async APIs easier to use; and discouraging use of sync ones. I think the GAsyncResult framework we?ve got is pretty good, and I

Discouraging use of sync APIs

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 the main thread when they should be using async ones.* How can we fix this? I

Re: Discouraging use of sync APIs

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 the sync API is called inside the default main context, even if there's the obvious issue of console-only code that still

Re: Feedback from downstreams presentation from DX hackfest 2015

On Mon, 2015-02-02 at 16:31 +0100, Olav Vitters wrote: On Mon, Feb 02, 2015 at 02:37:32PM +, Philip Withnall wrote: What do you mean by reaching out to the advisory board? Reaching out for further feedback from them as downstreams, or reaching out for resources to fix such issues? I

Re: Feedback from downstreams presentation from DX hackfest 2015

On Mon, 2015-02-02 at 17:11 +0100, Sébastien Wilmet wrote: On Mon, Feb 02, 2015 at 04:51:32PM +0100, Aleksander Morgado wrote: Devhelp could also have a 'next' or 'latest' default profile which could sync the daily? built documentation from gnome.org. Although not sure how useful this could

Re: Feedback from downstreams presentation from DX hackfest 2015

On Mon, 2015-02-02 at 19:56 -0800, Philip Chimento wrote: On Mon, Feb 2, 2015 at 6:37 AM, Philip Withnall phi...@tecnocode.co.uk wrote: On Mon, 2015-02-02 at 12:19 +0100, Olav Vitters wrote: On Mon, Feb 02, 2015 at 08:05:00AM +, Philip Withnall wrote

Re: Feedback from downstreams presentation from DX hackfest 2015

On Tue, 2015-02-03 at 11:26 +0100, Murray Cumming wrote: On Tue, 2015-02-03 at 09:23 +0100, Murray Cumming wrote: Searching of gtkmm documentation has been working in devhelp for years, and I've just tested it here both in regular Ubuntu and in jhbuild. I mean, searching of the index, of

Re: Feedback from downstreams presentation from DX hackfest 2015

On Mon, 2015-02-02 at 14:47 +0100, Bastien Nocera wrote: On Mon, 2015-02-02 at 08:05 +, Philip Withnall wrote: At the DX hackfest last week[1] I gave an informal presentation about some of the work Collabora has been doing with GLib, GStreamer, Clutter, GTK+ and related technologies

Re: Feedback from downstreams presentation from DX hackfest 2015

On Mon, 2015-02-02 at 07:55 -0800, Jasper St. Pierre wrote: On Feb 2, 2015 6:37 AM, Philip Withnall phi...@tecnocode.co.uk wrote: 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

Feedback from downstreams presentation from DX hackfest 2015

At the DX hackfest last week[1] I gave an informal presentation about some of the work Collabora has been doing with GLib, GStreamer, Clutter, GTK+ and related technologies on client projects, specifically focusing on the feedback from two client projects, and the problems we encountered

Re: Installing DBus interface files for services

On Wed, 2015-01-28 at 20:59 +0100, Lennart Poettering wrote: On Tue, 13.01.15 10:43, Cosimo Cecchi (cosi...@gnome.org) wrote: Hi all, I was wondering if there's any reason we typically don't install on the system DBus XML interface files for services. On my system, I can see a bunch

Re: Proposal for personal WIP branches in git

On Thu, 2015-01-29 at 10:03 +0100, Jens Georg wrote: There’s a bit of discussion going on at the DX hackfest about personal branches of other people’s modules. People here agree that it would be pretty good if we standardised on: wip/$nick/$branch_name as the name for your

Re: Search Providers

On Fri, 2015-01-30 at 09:43 -0500, Erick Pérez Castellanos wrote: You could get the best of both worlds by doing what gnome-documents does (ie. use an inactivity-timeout): https://git.gnome.org/browse/gnome-documents/tree/src/application.js#n133 That way, your process does not linger for

Re: Installing DBus interface files for services

On Thu, 2015-01-15 at 14:40 +0800, Cosimo Cecchi wrote: On Tue, Jan 13, 2015 at 4:08 PM, Philip Withnall phi...@tecnocode.co.uk wrote: I can’t think of any reasons why not. Perhaps a GDBus automake snippet could be installed by GLib which: 1

  1   2   >