Re: Glib::Threads:Private

[John Emmas]

On 20/02/2019 15:26, Paul Davis wrote:


On Wed, Feb 20, 2019 at 1:17 AM John Emmas <mailto:j...@creativepost.co.uk>> wrote:


I realise it's a deprecated interface but can anyone explain what
Glib::Threads:Private does?

[...]


It means that each thread that accesses the variable sees a distinct 
or "thread-local" version of it.

.


Thanks Paul - so would a typical use case be for static members of a 
class? In normal circumstances, a static class member has the same value 
for all instances of the class. But maybe (in this case) 2 objects 
running in different threads could each have different values?


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

Re: Glib::Threads:Private

[Paul Davis]

On Wed, Feb 20, 2019 at 1:17 AM John Emmas  wrote:

> I realise it's a deprecated interface but can anyone explain what
> Glib::Threads:Private does?
>
> Does it guarantee that 'SomeObject' can only be accessed by code running
> in a particular thread?  And if so, does it do that by creating a
> specific thread for the object - or does it use whichever thread was
> running when Glib::Threads:Private got called?  Hope that makes sense
>

It means that each thread that accesses the variable sees a distinct or
"thread-local" version of it.
The language runtime creates memory for thread-local storage at program
startup, and each thread has its own section (inaccessible from other
threads) where these "thread-local" variables are allocated.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Glib::Threads:Private

[John Emmas]

I realise it's a deprecated interface but can anyone explain what 
Glib::Threads:Private does?


Does it guarantee that 'SomeObject' can only be accessed by code running 
in a particular thread?  And if so, does it do that by creating a 
specific thread for the object - or does it use whichever thread was 
running when Glib::Threads:Private got called?  Hope that makes sense


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

Re: glib gitlab tag

[Patrick Welche]

On Mon, Sep 03, 2018 at 12:15:20PM +0100, Philip Withnall wrote:
> On Mon, 2018-09-03 at 10:09 +0100, Patrick Welche wrote:
> > but I don't see the 2.58.0 tag!
> 
> I pushed the wrong tag, sorry. Trying to fix it now, but it will need
> sysadmin involvement because the git server (rightfully) doesn???t allow
> tags to be deleted or changed.
> 
> The release commit you should build is
> c138b98e363df8b95c2ee3eac214649b2908ad68; or just build from the glib-
> 2-58 branch.

I see it's all fixed now! Thanks,

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

Re: glib gitlab tag

[Philip Withnall]

On Mon, 2018-09-03 at 10:09 +0100, Patrick Welche wrote:
> I just pointed my local glib repository from git.gnome.org to
> gitlab.gnome.org.  I did the usual pull --rebase. I see
> 
> Author: Philip Withnall 
> Date:   Thu Aug 30 14:40:04 2018 +0100
> 
> 2.58.0
> 
> Signed-off-by: Philip Withnall 
> 
> 
> but I don't see the 2.58.0 tag!
> 
> ...
> 2.55.0
> 2.55.1
> 2.56.0
> 2.56.1
> 2.56.2
> 2.57.1
> 2.57.2
> 2.57.3
> EAZEL-NAUTILUS-MS-AUG07
> FOR_GNOME_0_99_1
> GLIB_1_1_0
> GLIB_1_1_1
> GLIB_1_1_10
> GLIB_1_1_11
> ...
> 
> It is listed at https://gitlab.gnome.org/GNOME/glib/tags
> 
> What am I missing?

I pushed the wrong tag, sorry. Trying to fix it now, but it will need
sysadmin involvement because the git server (rightfully) doesn’t allow
tags to be deleted or changed.

The release commit you should build is
c138b98e363df8b95c2ee3eac214649b2908ad68; or just build from the glib-
2-58 branch.

Philip

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

glib gitlab tag

[Patrick Welche]

I just pointed my local glib repository from git.gnome.org to
gitlab.gnome.org.  I did the usual pull --rebase. I see

Author: Philip Withnall 
Date:   Thu Aug 30 14:40:04 2018 +0100

2.58.0

Signed-off-by: Philip Withnall 


but I don't see the 2.58.0 tag!

...
2.55.0
2.55.1
2.56.0
2.56.1
2.56.2
2.57.1
2.57.2
2.57.3
EAZEL-NAUTILUS-MS-AUG07
FOR_GNOME_0_99_1
GLIB_1_1_0
GLIB_1_1_1
GLIB_1_1_10
GLIB_1_1_11
...

It is listed at https://gitlab.gnome.org/GNOME/glib/tags

What am I missing?

Cheers,

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

GLib BoF session at GUADEC

[Philip Withnall]

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 plan for
2.60.

Ta,
Philip

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

Re: Proposal: Recommend meson for glib 2.58.0

[xclaesse]

Le vendredi 15 juin 2018 à 17:41 +0100, Emmanuele Bassi a écrit :
> Note that the doc is built and uploaded as part of glib's CI for
> > each
> > tag, so it can be taken from artifacts. I don't know if it gets
> > published from there, but we could do something. Emmanuele Bassi
> > probably knows more about this mechanism.

Oh... but it's broken: https://gitlab.gnome.org/GNOME/glib/-/jobs/35826

the CI is missing "ninja gobject-doc" and "ninja gio-doc" commands, but
they fail: https://github.com/mesonbuild/meson/issues/3745
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Emmanuele Bassi]

On Fri, 15 Jun 2018 at 16:34,  wrote:

> Le vendredi 08 juin 2018 à 20:25 +0100, Tim-Philipp Müller a écrit :
> > Just to make sure everyone is aware of this, this also means distros
> > will always need to always build the documentation with gtk-doc,
> > since
> > "ninja dist" won't include generated html files in the tarball. It
> > just
> > includes whatever is checked into git (they could be checked into git
> > of course if that was a deal-breaker for some reason).
>
> Note that the doc is built and uploaded as part of glib's CI for each
> tag, so it can be taken from artifacts. I don't know if it gets
> published from there, but we could do something. Emmanuele Bassi
> probably knows more about this mechanism.
>

It doesn't get published, only built and stored as artefacts – though it's
mostly a demonstration of what could be done.

The main issue with using GitLab pages is that publishing wipes out the
deployment every time, so we cannot have things like "publish the API
reference for master under unstable/ and the API reference for for each
branch under branchname/ and then publish the test suite coverage under
coverage/".

The only way to achieve this would be to build the API reference then push
it to some other repository, and have a CI hook that deploys everything.
This would allow building different versions of the API reference, and
additionally have things like coverage (per branch) and a simple website.
I've started looking into this, but it's kind of complicated, as it
requires creating a new `glib-docs` user and repo; generate SSH keys for
it; and then have the CI infrastructure store the SSH keys as secrets and
use them during the CI build.

Alternatively, we'd need a place accessible from the CI infra to copy our
files into, that would get published automatically on our web servers.

Ideally, this would also serve as the replacement for developer.gnome.org.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[xclaesse]

Le vendredi 08 juin 2018 à 20:25 +0100, Tim-Philipp Müller a écrit :
> Just to make sure everyone is aware of this, this also means distros
> will always need to always build the documentation with gtk-doc,
> since
> "ninja dist" won't include generated html files in the tarball. It
> just
> includes whatever is checked into git (they could be checked into git
> of course if that was a deal-breaker for some reason).

Note that the doc is built and uploaded as part of glib's CI for each
tag, so it can be taken from artifacts. I don't know if it gets
published from there, but we could do something. Emmanuele Bassi
probably knows more about this mechanism.

Now that I think about this, the CI could be used to publish
Windows/MacOSX doc as well, I think that's something we never could do
before.

Regards,
Xavier Claessens.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Philip Withnall]

On Fri, 2018-06-08 at 14:59 -0400, xclae...@gmail.com wrote:
> Le vendredi 08 juin 2018 à 18:59 +0100, Philip Withnall a écrit :
> > How about:
> > 1) Starting from 2.57.2, create release tarballs with `ninja dist`,
> > but
> > recommend that distributions still build with autotools (unless
> > they
> > want to dogfood with Meson early).
> > 2) From 2.57.3, switch to recommending that distributions build
> > with
> > Meson.
> 
> Yeah, why not, let's start it slow. What I like with that step is we
> can easily roll new tarballs with "make distcheck" if packagers have
> any issues.

Yup.

> Btw, when is 2.58.0 due? And how many dev release do we plan in
> between?

Due after GUADEC; as many dev releases as we want.

https://wiki.gnome.org/Schedule

Philip

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

Re: Proposal: Recommend meson for glib 2.58.0

[philip . chimento]

On Sat, Jun 9, 2018 at 8:02 AM Nirbheek Chauhan 
wrote:

> On Sun, Jun 3, 2018 at 1:13 AM  wrote:
> >
> > Before making the switch please be aware of
> https://github.com/mesonbuild/meson/issues/3077 and
> https://github.com/mesonbuild/meson/issues/2121 which make Meson-built
> libraries mostly broken on macOS, particularly with regard to g-ir-scanner.
> >
>
> I have a fix for this: https://github.com/mesonbuild/meson/pull/3691
>
> I'll wait till Monday or Tuesday for people to comment and then push
> it. It will be in the 0.47 release which is scheduled for 24th June.
>

That's fantastic news, thank you Nirbheek!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Nirbheek Chauhan]

On Sun, Jun 3, 2018 at 1:13 AM  wrote:
>
> Before making the switch please be aware of 
> https://github.com/mesonbuild/meson/issues/3077 and 
> https://github.com/mesonbuild/meson/issues/2121 which make Meson-built 
> libraries mostly broken on macOS, particularly with regard to g-ir-scanner.
>

I have a fix for this: https://github.com/mesonbuild/meson/pull/3691

I'll wait till Monday or Tuesday for people to comment and then push
it. It will be in the 0.47 release which is scheduled for 24th June.

Cheers,
Nirbheek
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Tim-Philipp Müller]

On Fri, 2018-06-08 at 18:59 +0100, Philip Withnall wrote:

Hi,

> > My proposal would be:
> > 1) Starting from 2.57.2 (next dev release), create release tarballs
> > using "ninja dist" and recommend disto to build with Meson 0.46.1.
> > This would mean that './configure' in a release tarball won't work,
> > people still wanting to use autotools will have to update their
> > scripts to use "./autogen.sh" instead and adjust their build deps.
> > IMHO, forcing a small change is a good incentive to have most of
> > our users switch to meson. This would give us good feedback while
> > still keeping the door open to rollback if any blocker bug appears.
> > 2) Starting from 2.59.1 (next dev cycle), drop autotools completely
> > from our git repository.
> 
> How about:
> 1) Starting from 2.57.2, create release tarballs with `ninja dist`,
> but recommend that distributions still build with autotools (unless
> they want to dogfood with Meson early).

Just to make sure everyone is aware of this, this also means distros
will always need to always build the documentation with gtk-doc, since
"ninja dist" won't include generated html files in the tarball. It just
includes whatever is checked into git (they could be checked into git
of course if that was a deal-breaker for some reason).

Cheers
-Tim
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[xclaesse]

Le vendredi 08 juin 2018 à 18:59 +0100, Philip Withnall a écrit :
> How about:
> 1) Starting from 2.57.2, create release tarballs with `ninja dist`,
> but
> recommend that distributions still build with autotools (unless they
> want to dogfood with Meson early).
> 2) From 2.57.3, switch to recommending that distributions build with
> Meson.

Yeah, why not, let's start it slow. What I like with that step is we
can easily roll new tarballs with "make distcheck" if packagers have
any issues.

Btw, when is 2.58.0 due? And how many dev release do we plan in
between?

> 3) Starting from 2.59.0 (the actual start of next dev cycle), drop
> autotools completely; assuming that steps 1 and 2 have gone OK.

Of course, each step is conditional to the previous going fine.

> I want to make sure that distributions only start building GLib using
> Meson for their unstable/development releases, rather than for stable
> releases. There have only recently been bugs about code which was
> compiled with autotools not being built with Meson (the FAM file
> monitor comes to mind), which doesn’t give me enough confidence to
> jump
> to recommending building with Meson right yet.

+1

> BTW, why are you recommending 0.46.1? The dependency in our top-level
> meson.build is currently 0.46.0.

Because 0.46.1 is what we have in our CIs, the .1 is only for bug
fixing.

Regards,
Xavier Claessens.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Philip Withnall]

Hey,

On Fri, 2018-06-01 at 11:10 -0400, xclae...@gmail.com wrote:
> Things are looking pretty well with meson in GLib master. We have CI
> working for pretty much all interesting platforms (more to come) and
> there are only a few remaining issues with "Meson" tag in gitlab[1].
> 
> I think the longer we keep 2 build systems, the more time we waste on
> useless tasks. So I would like to discuss a roadmap that would lead
> to
> dropping autotools.

Yes, it would be good to clarify the roadmap. A roadmap was planned at
the GTK+ hackfest at FOSDEM earlier this year, and I blogged about it,
but it looks like my blog had dropped off planet.gnome.org at the time,
so I doubt anyone saw the post. ☹

https://tecnocode.co.uk/2018/02/06/gtk-hackfest-and-fosdem-outcomes/

tl;dr: The plan from FOSDEM was to support autotools and Meson in
parallel for 2.58 (with feature parity between the two), then keep both
systems in parallel for a ‘release or two’, before dropping autotools
as soon as we can be satisfied there are no regressions for our
features or supported platforms.

As a reminder, here’s the set of supported platforms for GLib:

https://wiki.gnome.org/Projects/GLib/SupportedPlatforms

> My proposal would be:
> 1) Starting from 2.57.2 (next dev release), create release tarballs
> using "ninja dist" and recommend disto to build with Meson 0.46.1.
> This
> would mean that './configure' in a release tarball won't work, people
> still wanting to use autotools will have to update their scripts to
> use
> "./autogen.sh" instead and adjust their build deps. IMHO, forcing a
> small change is a good incentive to have most of our users switch to
> meson. This would give us good feedback while still keeping the door
> open to rollback if any blocker bug appears.
> 2) Starting from 2.59.1 (next dev cycle), drop autotools completely
> from our git repository.  

How about:
1) Starting from 2.57.2, create release tarballs with `ninja dist`, but
recommend that distributions still build with autotools (unless they
want to dogfood with Meson early).
2) From 2.57.3, switch to recommending that distributions build with
Meson.
3) Starting from 2.59.0 (the actual start of next dev cycle), drop
autotools completely; assuming that steps 1 and 2 have gone OK.

I want to make sure that distributions only start building GLib using
Meson for their unstable/development releases, rather than for stable
releases. There have only recently been bugs about code which was
compiled with autotools not being built with Meson (the FAM file
monitor comes to mind), which doesn’t give me enough confidence to jump
to recommending building with Meson right yet.

Note that on some platforms, we may drop support for autotools early.
Notably the maintainers of the GLib builds on Windows have already
fully switched to Meson, and there is a merge request open about making
 configure error out on Windows.

I could imagine the same happening for other platforms where we’re in
direct contact with the small set of packagers for those platforms (for
example, MacPorts and the *BSDs).

BTW, why are you recommending 0.46.1? The dependency in our top-level
meson.build is currently 0.46.0.

Philip

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

Re: Proposal: Recommend meson for glib 2.58.0

[philip . chimento]

Before making the switch please be aware of
https://github.com/mesonbuild/meson/issues/3077 and
https://github.com/mesonbuild/meson/issues/2121 which make Meson-built
libraries mostly broken on macOS, particularly with regard to g-ir-scanner.

Regards,
Philip C

On Sat, Jun 2, 2018 at 12:08 PM Ignacio Casal Quinteiro <
nacho.r...@gmail.com> wrote:

> On the gvsbuild side we are already building with meson for a while and
> things are ok. I just fear the case where we do not have python 3 on rhel 6
> and sles 11...
>
> On Fri, Jun 1, 2018 at 10:51 PM, Emmanuele Bassi  wrote:
>
>> With Python 2.x getting EOL in less than 2 years, I suspect that
>> commercial distros will need to provide Python 3 pretty quickly.
>>
>> Ciao,
>>  Emmanuele.
>>
>> On Fri, 1 Jun 2018 at 21:10, Christian Hergert 
>> wrote:
>>
>>> On 06/01/2018 08:10 AM, xclae...@gmail.com wrote:
>>> > Disclaimer: I'm not a GLib maintainer so this email is only about
>>> > opening the discussion. There is no decision made yet.
>>> >
>>> > Opinions?
>>>
>>> I think the risk area is python3 support on some commercially supported
>>> distributions. Although, that is probably in better shape now than it
>>> was a year ago.
>>>
>>> Also not a maintainer, but +1 for the switch.
>>>
>>> -- Christian
>>> ___
>>> gtk-devel-list mailing list
>>> gtk-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>>
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>>
>
>
> --
> Ignacio Casal Quinteiro
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Ignacio Casal Quinteiro]

On the gvsbuild side we are already building with meson for a while and
things are ok. I just fear the case where we do not have python 3 on rhel 6
and sles 11...

On Fri, Jun 1, 2018 at 10:51 PM, Emmanuele Bassi  wrote:

> With Python 2.x getting EOL in less than 2 years, I suspect that
> commercial distros will need to provide Python 3 pretty quickly.
>
> Ciao,
>  Emmanuele.
>
> On Fri, 1 Jun 2018 at 21:10, Christian Hergert 
> wrote:
>
>> On 06/01/2018 08:10 AM, xclae...@gmail.com wrote:
>> > Disclaimer: I'm not a GLib maintainer so this email is only about
>> > opening the discussion. There is no decision made yet.
>> >
>> > Opinions?
>>
>> I think the risk area is python3 support on some commercially supported
>> distributions. Although, that is probably in better shape now than it
>> was a year ago.
>>
>> Also not a maintainer, but +1 for the switch.
>>
>> -- Christian
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>


-- 
Ignacio Casal Quinteiro
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Emmanuele Bassi]

With Python 2.x getting EOL in less than 2 years, I suspect that commercial
distros will need to provide Python 3 pretty quickly.

Ciao,
 Emmanuele.

On Fri, 1 Jun 2018 at 21:10, Christian Hergert  wrote:

> On 06/01/2018 08:10 AM, xclae...@gmail.com wrote:
> > Disclaimer: I'm not a GLib maintainer so this email is only about
> > opening the discussion. There is no decision made yet.
> >
> > Opinions?
>
> I think the risk area is python3 support on some commercially supported
> distributions. Although, that is probably in better shape now than it
> was a year ago.
>
> Also not a maintainer, but +1 for the switch.
>
> -- Christian
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Proposal: Recommend meson for glib 2.58.0

[Christian Hergert]

On 06/01/2018 08:10 AM, xclae...@gmail.com wrote:
> Disclaimer: I'm not a GLib maintainer so this email is only about
> opening the discussion. There is no decision made yet.
> 
> Opinions?

I think the risk area is python3 support on some commercially supported
distributions. Although, that is probably in better shape now than it
was a year ago.

Also not a maintainer, but +1 for the switch.

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

Proposal: Recommend meson for glib 2.58.0

[xclaesse]

Hi,

Things are looking pretty well with meson in GLib master. We have CI
working for pretty much all interesting platforms (more to come) and
there are only a few remaining issues with "Meson" tag in gitlab[1].

I think the longer we keep 2 build systems, the more time we waste on
useless tasks. So I would like to discuss a roadmap that would lead to
dropping autotools.

My proposal would be:
1) Starting from 2.57.2 (next dev release), create release tarballs
using "ninja dist" and recommend disto to build with Meson 0.46.1. This
would mean that './configure' in a release tarball won't work, people
still wanting to use autotools will have to update their scripts to use
"./autogen.sh" instead and adjust their build deps. IMHO, forcing a
small change is a good incentive to have most of our users switch to
meson. This would give us good feedback while still keeping the door
open to rollback if any blocker bug appears.
2) Starting from 2.59.1 (next dev cycle), drop autotools completely
from our git repository.

Disclaimer: I'm not a GLib maintainer so this email is only about
opening the discussion. There is no decision made yet.

Opinions?

Regards,
Xavier Claessens.

[1] https://gitlab.gnome.org/GNOME/glib/issues?scope=all&utf8=%E2%9C%93
&state=opened&label_name[]=Meson
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Python error when building gdbus-codegen stuff (in glib / gio)

[Philip Withnall]

On Wed, 2018-01-17 at 16:07 +, John Emmas wrote:
> On 17/01/2018 11:04, John Emmas wrote:
> > 
> > I'll look a bit further into this and see if I can figure out
> > what's 
> > gone wrong.
> > 
> 
> This turned out to be a problem with TortoiseGit.  Some of glib's
> python 
> files contain lines looking like this:-
> 
>from .whatever import something
> 
> For some reason, I always need to edit them to remove the period -
> i.e.
> 
>from whatever import something
> 
> So typically, I can have 4 or 5 such conflicts in any given python 
> script.  TortoiseGit has an option which effectively means "resolve
> all 
> conflicted lines using my version".  But I've just realised that it 
> doesn't confine itself to overwriting the conflicted lines - it
> actually 
> substitutes my whole file (and therefore loses any non-conflicted
> changes!!)

Good to hear you’ve resolved that problem.

> Now I'm past that point I've encountered a new problem (when
> compiling 
> the recently added 'gnetworkmonitorwindows.c').  On my system (MSVC)
> it 
> seems to be #including the wrong version of "iphlpapi.h" and is 
> consequently failing to pick up one of the symbols
> (IP_ADDRESS_PREFIX) 
> which is needed by function 'win_network_monitor_get_ip_info()'.

When you get a chance to investigate it, can you add your findings to
https://bugzilla.gnome.org/show_bug.cgi?id=685442 please? That’s where
we’re working on the Windows network monitor.

Thanks,
Philip

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

Re: Python error when building gdbus-codegen stuff (in glib / gio)

[John Emmas]

On 17/01/2018 11:04, John Emmas wrote:


I'll look a bit further into this and see if I can figure out what's 
gone wrong.




This turned out to be a problem with TortoiseGit.  Some of glib's python 
files contain lines looking like this:-


  from .whatever import something

For some reason, I always need to edit them to remove the period - i.e.

  from whatever import something

So typically, I can have 4 or 5 such conflicts in any given python 
script.  TortoiseGit has an option which effectively means "resolve all 
conflicted lines using my version".  But I've just realised that it 
doesn't confine itself to overwriting the conflicted lines - it actually 
substitutes my whole file (and therefore loses any non-conflicted changes!!)


Now I'm past that point I've encountered a new problem (when compiling 
the recently added 'gnetworkmonitorwindows.c').  On my system (MSVC) it 
seems to be #including the wrong version of "iphlpapi.h" and is 
consequently failing to pick up one of the symbols (IP_ADDRESS_PREFIX) 
which is needed by function 'win_network_monitor_get_ip_info()'.


That'll have to wait for another day though... :-(

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

Re: Python error when building gdbus-codegen stuff (in glib / gio)

[John Emmas]

On 17/01/2018 10:38, Philip Withnall wrote:


What’s the output of `git status`?



For both 'codegen_main.py' and 'codegen_docbook.py' I see this output:-

# On branch master
# Your branch is ahead of 'upstream/master' by 260 commits.
#
nothing to commit (working directory clean)

(I think that's because I push things to my own repo).

I'll look a bit further into this and see if I can figure out what's 
gone wrong. Thanks,


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

Re: Python error when building gdbus-codegen stuff (in glib / gio)

[Philip Withnall]

On Wed, 2018-01-17 at 10:26 +, John Emmas wrote:
> On 17/01/2018 09:51, Philip Withnall wrote:
> > Exactly what commit are you building?
> > 
> > > [...]
> > > 
> > 
> > That’s not what the code currently looks like:
> > 
> 
> Thanks for the quick response Philip.  The latest commit here is 
> #5fba62ade by Benjamin Berg on 15 Jan 2018 (gmessages: Flush output 
> stream after logging messages).
> 
> My last 'pull' did flag up some conflicts though - so maybe I didn't
> fix 
> one of them correctly? (or did that change come after the above
> commit?)

Perhaps. What’s the output of `git status`?

Philip

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

Re: Python error when building gdbus-codegen stuff (in glib / gio)

[John Emmas]

On 17/01/2018 09:51, Philip Withnall wrote:

Exactly what commit are you building?


[...]


That’s not what the code currently looks like:



Thanks for the quick response Philip.  The latest commit here is 
#5fba62ade by Benjamin Berg on 15 Jan 2018 (gmessages: Flush output 
stream after logging messages).


My last 'pull' did flag up some conflicts though - so maybe I didn't fix 
one of them correctly? (or did that change come after the above commit?)


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

Re: Python error when building gdbus-codegen stuff (in glib / gio)

[Philip Withnall]

On Wed, 2018-01-17 at 09:44 +, John Emmas wrote:
> I'm not yet building with meson so forgive me if this is just down to
> my 
> build system being out-of-date !!
> 
> The problem happens when I try to build glib/gio from yesterday's
> git 
> master.

Exactly what commit are you building?

> But in the file 'gdbus-2.0/codegen/codegen_main.py' it seems to be 
> getting called like this, at line 186:-
> 
>docbook_gen = 
> codegen_docbook.DocbookCodeGenerator(all_ifaces, docbook, outdir);

That’s not what the code currently looks like:

https://git.gnome.org/browse/glib/tree/gio/gdbus-2.0/codegen/codegen_ma
in.py#n226

Is your git checkout completely up to date?

Philip

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

Python error when building gdbus-codegen stuff (in glib / gio)

[John Emmas]

I'm not yet building with meson so forgive me if this is just down to my 
build system being out-of-date !!


The problem happens when I try to build glib/gio from yesterday's git 
master.  More specifically it happens when building the 'gdbus-codegen' 
stuff.  'The file 'gdbus-2.0/codegen/codegen_docbook.py' contains this 
at line 33:-


  class DocbookCodeGenerator:
  def __init__(self, ifaces):  // <--- NOTE THIS CHANGE !!
  self.ifaces = ifaces

  // etc. . .

Previously it looked like this:-

  class DocbookCodeGenerator:
  def __init__(self, ifaces, docbook, outdir):  //<--- ORIGINAL 
LINE !!

  self.ifaces = ifaces

  // etc. . .

But in the file 'gdbus-2.0/codegen/codegen_main.py' it seems to be 
getting called like this, at line 186:-


  docbook_gen = 
codegen_docbook.DocbookCodeGenerator(all_ifaces, docbook, outdir);


(which hasn't changed AFAICT).  Python is complaining that too many 
parameters are getting passed here.


Once again - apologies if this is all due to my build system being 
out-of-date...


John Emmas
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLIB Port on QNX

[Emmanuele Bassi]

Hi;

On 8 January 2018 at 13:20, Nitin Jain  wrote:

> Is there any QNX port available for glib .

We don't manage packaging of GLib ourselves, if that's what you're
asking. We usually defer to whatever downstreams exist for any given
platform.

> Any pointers will be very helpful if we want to port GLIB on  QNX 6.6 .  As
> per understanding , QNX is posix compliant  and most of the functionality
> .of glibc shall be available on QNX.

These are our toolchain requirements:

https://wiki.gnome.org/Projects/GLib/CompilerRequirements

and these are our supported platforms, as well as our support policy:

https://wiki.gnome.org/Projects/GLib/SupportedPlatforms

We currently do not build, nor test, GLib on QNX. If you're willing to
set up and maintain an automatic CI system that verifies we won't
unintentionally regress on that platform, we'd be very happy to help.
Additionally, if you're willing to help us out on ensuring that GLib
works appropriately on QNX, by fixing regressions and implementing
functionality that is platform-specific, then it would be great.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLIB Port on QNX

[Nitin Jain]

Hi ,


Is there any QNX port available for glib .

Any pointers will be very helpful if we want to port GLIB on  QNX 6.6 .  As
per understanding , QNX is posix compliant  and most of the functionality
.of glibc shall be available on QNX.

Thanks in advance. !


Regards
Nitin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib may busy loop on invalid file descriptors

[Dan Winship]

On 12/22/2017 06:09 AM, Benjamin Berg wrote:
> Hi,
> 
> I ran into an issue the other day where abrtd was polling an invalid
> file descriptor. Obviously, there must be a bug in abrtd which closed
> the wrong FD even though it was still registered with the mainloop
> using g_io_channel_unix_new and g_io_add_watch. However, the failure
> mode of GLib to simply busy loop seems quite bad.
> 
> Should g_io_unix_check maybe react to (G_IO_HUP | G_IO_ERR | G_IO_NVAL)
> in a way that results in an error and the removal of the source? That
> is, effectively run a fallback handler application is watching these
> error conditions.
> 
> A viable solution might be:
>  * Return TRUE from g_io_unix_check by always checking for the errors
>  * Test again in g_io_unix_dispatch but log an error and return FALSE
>if none of the requested conditions match.
> 
> Thoughts?

FWIW I suggested more or less the same thing a long time ago but
eventually convinced myself was the wrong fix:
https://bugzilla.gnome.org/show_bug.cgi?id=321746

-- Dan

> Benjamin
> 
> PS: https://github.com/abrt/abrt/issues/1280 has some info on the
> specific issue.
> 
> 
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

glib make error: syntax error near unexpected token `('

[Jaytirth Khairatkar]

I am trying to install glib from source code on an embedded linux platform.

I am getting the following error on doing ‘make’:

Make[4]: Entering directory ‘/glib-2.55.0/gobject’

/bin/sh: -c: line 0: syntax error near unexpected token `(‘

/bin/sh: -c: line 0: `echo “ CCLD “ libgobject-2.0.la;/bin/sh ../libtool
–silent –tag=CC --mode=link gcc –Wall –Wstr’

Makefile: 1170: recipe for target ‘libgobject-2.0.la’ failed

line 1169 and 1170 of the Makefile are these:

1169:

libgobject-2.0.la: $(libgobject_2_0_la_OBJECTS)

  $(libgobject_2_0_la_DEPENDENCIES)

  $(EXTRA_libgobject_2_0_la_DEPENDENCIES)

1170:

$(AM_V_CCLD) $(libgobject_2_0_la_LINK) -rpath $(libdir)

  $(libgobject_2_0_la_OBJECTS) $(libgobject_2_0_la_LIBADD) $(LIBS)

In the Makefile line 1169 is in a single line and line 1170 is in another
separate single line. Here due to formatting constraints I had to split it.

When I join 1169 and 1170, I get a different error which is:

*** No rule to make target '@echo', needed by 'libobject-2.0.la'. Stop.

What is causing this error? Do I have to set some environment variable? I
am especially confused because it says line 0. How do I resolve this errors?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Build Gtk+ by Meson with locally installed Glib

[Andrey Ponomarenko]

This is helpful. PATH=/path/to/glib/2.55.0/bin:$PATH PKG_CONFIG_PATH=/path/to/glib/2.55.0/lib/pkgconfig meson . build_dir --prefix=/ Also, installing to a local directory requires setting of the DESTDIR variable: PATH=/path/to/glib/2.55.0/bin:$PATH ninjaDESTDIR=/install/path ninja install Thanks a lot!  29.12.2017, 15:13, "Daniel Boles" :I'd think the simplest option is to put your local GLib in your PATH with higher priority, so that the non-absolute invocation of g-c-r finds your one instead of the system one.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Build Gtk+ by Meson with locally installed Glib

[Daniel Boles]

I'd think the simplest option is to put your local GLib in your PATH with
higher priority, so that the non-absolute invocation of g-c-r finds your
one instead of the system one.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Build Gtk+ by Meson with locally installed Glib

[Andrey Ponomarenko]

Hi,

How can I build Gtk+ 3.93.0 by Meson with locally installed Glib 2.55.0?

I have tried pkgconfig:

PKG_CONFIG_PATH=/path/to/glib/2.55.0/lib/pkgconfig meson -Ddisable-modules=true 
-Denable-wayland-backend=false -Dintrospection=false -Ddemos=false 
-Dbuild-tests=false -Ddocumentation=false --buildtype debug . build_dir 
--prefix="/install/path"
cd build_dir
ninja

But this results to:

[1/661] Generating gdkresources_h with a custom command.
[2/661] Generating gdkresources_c with a custom command.
FAILED: gdk/gdkresources.c 
glib-compile-resources gdk/gdk.gresource.xml --sourcedir ../gdk/. --sourcedir 
../gdk --c-name _gdk --internal --generate --target gdk/gdkresources.c 
--manual-register --dependency-file gdk/gdkresources.c.d
Unknown option --dependency-file
...

I.e. it uses old system's glib instead of local one (in /path/to/glib/2.55.0/).

How can I tell meson/ninja to use local Glib install tree?

Meson: 0.44.0
Ninja: 1.8.2

Thank you.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Glib make error

[Jaytirth Khairatkar]

am getting the following error on doing ‘make’:



Make[4]: Entering directory ‘/glib-2.55.0/gobject’

/bin/sh: -c: line 0: syntax error near unexpected token `(‘

/bin/sh: -c: line 0: `echo “ CCLD  “ libgobject-2.0.la;/bin/sh ../libtool
–silent –tag=CC  --mode=link gcc –Wall –Wstr’

Makefile: 1170: recipe for target ‘libgobject-2.0.la’ failed



How do I resolve this error.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib may busy loop on invalid file descriptors

[Frediano Ziglio]

> 
> Hi,
> 
> I ran into an issue the other day where abrtd was polling an invalid
> file descriptor. Obviously, there must be a bug in abrtd which closed
> the wrong FD even though it was still registered with the mainloop
> using g_io_channel_unix_new and g_io_add_watch. However, the failure
> mode of GLib to simply busy loop seems quite bad.
> 
> Should g_io_unix_check maybe react to (G_IO_HUP | G_IO_ERR | G_IO_NVAL)
> in a way that results in an error and the removal of the source? That
> is, effectively run a fallback handler application is watching these
> error conditions.
> 
> A viable solution might be:
>  * Return TRUE from g_io_unix_check by always checking for the errors
>  * Test again in g_io_unix_dispatch but log an error and return FALSE
>if none of the requested conditions match.
> 
> Thoughts?
> 
> Benjamin
> 
> PS: https://github.com/abrt/abrt/issues/1280 has some info on the
> specific issue.

The problem is similar to a double free. In that case I would personally
abort the program. If GLib really care about security trying to recovery
is a bad idea.

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

GLib may busy loop on invalid file descriptors

[Benjamin Berg]

Hi,

I ran into an issue the other day where abrtd was polling an invalid
file descriptor. Obviously, there must be a bug in abrtd which closed
the wrong FD even though it was still registered with the mainloop
using g_io_channel_unix_new and g_io_add_watch. However, the failure
mode of GLib to simply busy loop seems quite bad.

Should g_io_unix_check maybe react to (G_IO_HUP | G_IO_ERR | G_IO_NVAL)
in a way that results in an error and the removal of the source? That
is, effectively run a fallback handler application is watching these
error conditions.

A viable solution might be:
 * Return TRUE from g_io_unix_check by always checking for the errors
 * Test again in g_io_unix_dispatch but log an error and return FALSE
   if none of the requested conditions match.

Thoughts?

Benjamin

PS: https://github.com/abrt/abrt/issues/1280 has some info on the
specific issue.

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

Re: glib compilation problems when building from git master with MSVC

[Philip Withnall]

On Fri, 2017-11-03 at 14:54 +, John Emmas wrote:
> When trying to build glib (git master) I've hit a few compilation
> snags 
> arising from commit #53bd6a359f (29th Sept 2017)

Thanks for reporting these problems. I’ve reopened the bug (#788180)
which added this code; let’s discuss things there. I’ve subscribed you
to it.

Philip

> 1) Firstly (in gstdio.c) the function:-
> '_g_win32_readlink_utf16_raw()' 
> uses a value called "IO_REPARSE_TAG_SYMLINK".  This doesn't seem to
> be 
> defined for MSVC - at least not in my version (VC8).
> 
> 2) gstdio.c uses some other identifiers too - notably, 
> 'FILE_STANDARD_INFO' and 'FILE_NAME_NORMALIZED'.  These seem to be 
> declared in winbase.h which should (in theory) be getting #included
> by 
> windows.h.  However, MSVC reports them both as undeclared
> identifiers 
> (even if I specifically #include winbase.h !!)
> 
> Is there some new #define needed which I maybe don''t know about ??
> 
> John
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

glib compilation problems when building from git master with MSVC

[John Emmas]

When trying to build glib (git master) I've hit a few compilation snags 
arising from commit #53bd6a359f (29th Sept 2017)


1) Firstly (in gstdio.c) the function:- '_g_win32_readlink_utf16_raw()' 
uses a value called "IO_REPARSE_TAG_SYMLINK".  This doesn't seem to be 
defined for MSVC - at least not in my version (VC8).


2) gstdio.c uses some other identifiers too - notably, 
'FILE_STANDARD_INFO' and 'FILE_NAME_NORMALIZED'.  These seem to be 
declared in winbase.h which should (in theory) be getting #included by 
windows.h.  However, MSVC reports them both as undeclared identifiers 
(even if I specifically #include winbase.h !!)


Is there some new #define needed which I maybe don''t know about ??

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

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

[范君維]

Hi John,


John Emmas 於 2017/9/17 上午 12:05 寫道:
For Windows programming, I've always been wary of trying to 
"mix-and-match" between different MSVC libraries (regardless of that 
Microsoft says!).  So how about this for a compromise...


If the idea is to drop support for Win-XP (and yet retain support for 
VS2005) we could achieve it with some quite simple changes. Only 2 or 
3 files would need to get changed and it's mostly just stuff like this...


Unfortunately, it is unlikely that patches of this sort can be accepted 
upstream, because one of the main reasons for the drop of XP support is 
to also clean up the code base, so that block you were mentioning is 
likely to be dropped soon for the master branch (hence the reason "I 
think it is the best to make such bumps early in the cycle", so people 
can test and check their code).


Note that even when you use the SDK that comes with Visual Studio 2005, 
your code still links to the various system DLLs that are already 
present on your system that are either there when you installed Windows, 
or installed via an update, i.e. the same DLLs that will be linked with 
the Server 2008/Windows 7 SDKs.  Note also, the .lib's that link to DLLs 
are essentially the ones that tell the linker "make this code call this 
DLL that I am indicating here to carry out the things needed from this 
library".  I think there are no separate copies of a system DLL that 
link to different Microsoft CRTs.  I think your best bet is to try your 
code built with Visual Studio 2005 using the Server 2008 and/or Windows 
7 SDKs, and see how your code runs.  If that is not an option, I think 
you will need to maintain your own private build compatibility layer 
that your code will compile (and link) to (especially that you used your 
own VS 2005 projects).  There are more and more projects that simply do 
not (or stopped) supporting XP.


Hope this helps.

With blessings, and cheers!

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

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

[John Emmas]

On 16/09/2017 02:41, Chun-wei Fan (范君維) wrote:


John Emmas 於 2017/9/16 上午 03:00 寫道:


I'm assuming you're referring to this SDK?


Yes, this is the SDK I was mentioning.  It does work for Visual Studio 
2005, see https://msdn.microsoft.com/en-us/windowsserver/bb986638.aspx 
under "Supported Compiler, Platform and related software".




Thanks Fanc (I'm never quite sure what to call you !)

For Windows programming, I've always been wary of trying to 
"mix-and-match" between different MSVC libraries (regardless of that 
Microsoft says!).  So how about this for a compromise...


If the idea is to drop support for Win-XP (and yet retain support for 
VS2005) we could achieve it with some quite simple changes. Only 2 or 3 
files would need to get changed and it's mostly just stuff like this...


wherever we currently use this:-

#if _WIN32_WINNT < 0x0600

we'd change it to this:-

#if (_WIN32_WINNT < 0x0600 || (defined(_MSC_VER) && _MSC_VER < 
1500))


I'd be happy to produce a full patch if you like.  I've already tried it 
here with VS2005 and glib is now building fine again.  Best regards,


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

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

[范君維]

Hi John,

John Emmas 於 2017/9/16 上午 03:00 寫道:
It looks like I have VS2005 installed and also the corresponding 
DirectX SDK.  I can't see any other SDK's that are specific to VS2005.


This means that you are using the Windows SDK that came with your Visual 
Studio 2005



I'm assuming you're referring to this SDK?


Yes, this is the SDK I was mentioning.  It does work for Visual Studio 
2005, see https://msdn.microsoft.com/en-us/windowsserver/bb986638.aspx 
under "Supported Compiler, Platform and related software".


For the Windows 7 (7.1) SDK, see 
https://www.microsoft.com/en-us/download/details.aspx?id=8279&751be11f-ede8-5a0c-058c-2ee190a24fa6=True&e6b34bbe-475b-1abd-2c51-b5034bcdd6d2=True 
under "System Requirements".  I think it might be best for you to use 
the 7.1 SDK.


https://stackoverflow.com/questions/171816/vc9-and-vc8-lib-compatibility

2005 and 2008 will use different CRT modules and you can't normally 
link stuff to two different CRT libraries.   I'd be a bit surprised if 
they're compatible... :-(


This is true for non-Windows-system code, but note that the DLLs 
provided by the system (i.e. those that is linked by the SDK) link to 
msvcrt.dll, not msvcr90.dll.  Note that the SDK provides headers and 
..lib's (this is the same as what MinGW/MSYS does, but from a GCC on 
Windows perspective), not the system DLLs since they are already on your 
system since the time you installed Windows and any applicable updates.


Hope this clears things up.

With blessings, and cheers!


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

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

[John Emmas]

On 15/09/2017 17:25, Chun-wei Fan (范君維) wrote:


Are you using the Windows SDK that came with your Visual Studio 2005?  
These items that you mentioned are in the Server 2008 (7.0) SDKs, 
which work with Visual Studio 2005 (and the Windows 7 (7.1) SDKs does 
work with 2005 as well)




Thanks for the quick response.

It looks like I have VS2005 installed and also the corresponding DirectX 
SDK.  I can't see any other SDK's that are specific to VS2005.


I'm assuming you're referring to this SDK?

https://www.microsoft.com/en-us/download/details.aspx?id=11310

If so, it seems to depend on VS2008 SP1 so are you really sure those 
SDK's would be compatible with VS2005?  StackOverflow suggests they 
aren't...


https://stackoverflow.com/questions/171816/vc9-and-vc8-lib-compatibility

2005 and 2008 will use different CRT modules and you can't normally link 
stuff to two different CRT libraries.   I'd be a bit surprised if 
they're compatible... :-(


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

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

[范君維]

Hi John,

John Emmas 於 2017/9/15 下午 08:44 寫道:
I just tried building Glib from git master (non-meson build at the 
moment).


In 'config.h.win32.in' it looks like the value of _WIN32_WINNT got 
increased to 0x601.  This means that when building 'glib/gmessages.c' 
the struct _FILE_NAME_INFO is no longer defined. However... it's still 
getting referenced in the function 'win32_is_pipe_tty()'


Similarly... HAVE_IF_NAMETOINDEX is defined to '1' in a couple of 
places - which means that in 'gio/gsocket.c' the function 
'if_nametoindex()' is NOT defined.  But again it gets called in a 
couple of places.  It looks like the Glib definition was maybe 
intended to support older versions of MSVC (I'm using VC-8).  So does 
this mean that VC-8 will be getting dropped soon?  Thanks,


The items you mentioned are done as fallbacks as XP did not support 
these items, hence we mimic them in the code, so yes, the plan is to 
drop these *XP fallbacks* (but not necessarily *Visual Studio 2005*, at 
the moment).


It has been brought up on quite a number of occasions (and over quite 
some time) that XP support should have been dropped, and nowadays 
Windows 7 is the oldest supported version of Windows by Microsoft, hence 
the bump of _WIN32_WINNT to 0x0601.  I think it is best to do this kind 
of bump early on in the cycle to reduce surprises to people.


Are you using the Windows SDK that came with your Visual Studio 2005?  
These items that you mentioned are in the Server 2008 (7.0) SDKs, which 
work with Visual Studio 2005 (and the Windows 7 (7.1) SDKs does work 
with 2005 as well)--I built GLib-2.54.0 with Meson-generated *config.h 
files (which also had #define _WIN32_WINNT 0x0601) with Visual C++ 2008 
against the Server 2008 and ran the test programs and they work better 
than builds using the the older *config.h files.  Code-wise, as long as 
there is no drop of the 2008~2012 projects (or things like a 
sufficiently C99-compliant compiler is required), 2005 should most 
probably work (with these later SDKs installed and used).


Hope this clears up things.

With blessings, and cheers!


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

Re: FILE_NAME_INFO struct in 'glib/gmessages.c'

[LRN]

On 9/15/2017 3:44 PM, John Emmas wrote:
> I just tried building Glib from git master (non-meson build at the moment).
> 
> In 'config.h.win32.in' it looks like the value of _WIN32_WINNT got 
> increased to 0x601.  This means that when building 'glib/gmessages.c' 
> the struct _FILE_NAME_INFO is no longer defined. However... it's still 
> getting referenced in the function 'win32_is_pipe_tty()'


In MinGW _FILE_NAME_INFO is declared in winbase.h, ifdefed under _WIN32_WINNT
>= 0x0600, whereas winbase.h is included from windows.h, which gmessages.c does
include. I'm assuming that MSVC SDK has similar header layout, so it should 
work.

Anyway, i'll let fanc answer this one, as he's the MSVC guy around here.

-- 
O< ascii ribbon - stop html email! - http://arc.pasp.de/


0x8DADE9276759BA74.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

FILE_NAME_INFO struct in 'glib/gmessages.c'

[John Emmas]

I just tried building Glib from git master (non-meson build at the moment).

In 'config.h.win32.in' it looks like the value of _WIN32_WINNT got 
increased to 0x601.  This means that when building 'glib/gmessages.c' 
the struct _FILE_NAME_INFO is no longer defined. However... it's still 
getting referenced in the function 'win32_is_pipe_tty()'


Similarly... HAVE_IF_NAMETOINDEX is defined to '1' in a couple of places 
- which means that in 'gio/gsocket.c' the function 'if_nametoindex()' is 
NOT defined.  But again it gets called in a couple of places.  It looks 
like the Glib definition was maybe intended to support older versions of 
MSVC (I'm using VC-8).  So does this mean that VC-8 will be getting 
dropped soon?  Thanks,


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

Re: Generating glib-genmarshal

[Emmanuele Bassi]

On 7 September 2017 at 16:35, John Emmas  wrote:

> gdk-pixbuf and gdk+2 both built fine for me.  The only odd thing I noticed
> was when building gtk (from gtk-2-24) I saw quite a few warning messages
> looking like this:-
>
>   WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
>   WARNING: The token "NONE" is deprecated; use "VOID" instead
>
> They're probably nothing to worry about (I think they might be coming from
> 'gtk/gtkmarshal.list').  In fact it's possible they've always been there but
> I don't remember noticing them before...

No, the deprecation warnings are new, and were added with the rewrite to Python.

The `BOOL` and `NONE` keywords have been deprecated for 17 years —
they were deprecated when glib-genmarshal was added to the GLib
repository. Older versions of GTK+ still use those keywords because
they haven't been touched in years, and people cargo-culted their way
out of these things.

The deprecation warnings are there to let people know that
copy-pasting from old projects does not imply that things will never
change. :-)

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Generating glib-genmarshal

[John Emmas]

On 07/09/2017 08:44, John Emmas wrote:

On 07/09/2017 03:59, Chun-wei Fan (范君維) via gtk-devel-list wrote:


p.s. Were you able to build GDK-Pixbuf succesfully?



I'm going through the process of adapting my MSVC projects to 
accommodate the fact that some old perl scripts are now python scripts 
(and glib-genmarshal is now a python script too). Gdk-pixbuf (and 
Gtk+2) are both on my radar for this afternoon so I'll let you know 
how I get on!




Hi Chun-wei,

gdk-pixbuf and gdk+2 both built fine for me.  The only odd thing I 
noticed was when building gtk (from gtk-2-24) I saw quite a few warning 
messages looking like this:-


  WARNING: The token "BOOL" is deprecated; use "BOOLEAN" instead
  WARNING: The token "NONE" is deprecated; use "VOID" instead

They're probably nothing to worry about (I think they might be coming 
from 'gtk/gtkmarshal.list').  In fact it's possible they've always been 
there but I don't remember noticing them before...


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

Re: Generating glib-genmarshal

[John Emmas]

On 07/09/2017 03:59, Chun-wei Fan (范君維) via gtk-devel-list wrote:


p.s. Were you able to build GDK-Pixbuf succesfully?



Hi Chun-wei,

I'm going through the process of adapting my MSVC projects to 
accommodate the fact that some old perl scripts are now python scripts 
(and glib-genmarshal is now a python script too). Gdk-pixbuf (and Gtk+2) 
are both on my radar for this afternoon so I'll let you know how I get 
on! Regards,


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

Re: Generating glib-genmarshal

[范君維]

Hi John,

Thanks for pointing this out (oversight on my side), the fix for this 
has been pushed to master.


p.s. Were you able to build GDK-Pixbuf succesfully?

With blessings, and cheers!

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

Re: Generating glib-genmarshal

[John Emmas]

On 06/09/2017 17:37, Emmanuele Bassi wrote:

In GLib 2.52, glib-genmarshal is a C program. In GLib master, which
will become GLib 2.54 soon, glib-genmarshal is a Python program.



Ah... possibly the error message needs to change then at line 35 of 
'win32/gen_util_scripts.py' (in master) ?


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

Re: Generating glib-genmarshal

[Emmanuele Bassi]

In GLib 2.52, glib-genmarshal is a C program. In GLib master, which
will become GLib 2.54 soon, glib-genmarshal is a Python program.

The change from C to Python will *not* be backported to GLib 2.52.

Ciao,
 Emmanuele.


On 6 September 2017 at 16:41, John Emmas  wrote:
> Hi guys...
>
>   python  win32/gen_util_scripts.py --type=glib-genmarshal
> --version=
>
> If I'm building glib from git master, the above command works fine (if I
> issue it from a DOS window or from my MSVC project file). However... it
> produces an error if I try to build from the 'glib-2-52' branch.  Is that to
> be expected?
>
> In case it helps, the error message that I see is:-
>
> File "win32/gen_util_scripts.py", line 30, in main
>raise ValueError('Type must be glib-mkenums or gdbus-codegen')
>
> It's probably something that's been changed in 2-52 but not merged into
> master yet.  Anyway... just flagging it up,
>
> Thanks, John
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Generating glib-genmarshal

[John Emmas]

Hi guys...

  python  win32/gen_util_scripts.py --type=glib-genmarshal 
--version=


If I'm building glib from git master, the above command works fine (if I 
issue it from a DOS window or from my MSVC project file). However... it 
produces an error if I try to build from the 'glib-2-52' branch.  Is 
that to be expected?


In case it helps, the error message that I see is:-

File "win32/gen_util_scripts.py", line 30, in main
   raise ValueError('Type must be glib-mkenums or gdbus-codegen')

It's probably something that's been changed in 2-52 but not merged into 
master yet.  Anyway... just flagging it up,


Thanks, John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 24/08/2017 18:46, Emmanuele Bassi wrote:

Could you please open a bug?

Thanks Emmanuele. *Bug 786785* 
 submitted this morning.


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

Re: Building glib-genmarshal (while building glib)

[Emmanuele Bassi]

Could you please open a bug?

Ciao,
 Emmanuele.

On 24 August 2017 at 18:37, John Emmas  wrote:
> On 19/08/2017 12:16, John Emmas wrote:
>
>
> I still don't understand why this line (in commit #fe2a9887a8):-
>
> elif os.name == 'nt'
>
> got changed to this:-
>
> elif os.basename(filedir) == 'bin'
>
> They clearly don't do the same thing...
>
> Any thoughts anyone?
>
>
> Was it maybe intended to be this..?
>
> elif os.basename(filedir) != 'bin'
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 19/08/2017 12:16, John Emmas wrote:


I still don't understand why this line (in commit #fe2a9887a8):-

elif os.name == 'nt'

got changed to this:-

elif os.basename(filedir) == 'bin'

They clearly don't do the same thing...

Any thoughts anyone?


Was it maybe intended to be this..?

elif os.basename(filedir) != 'bin'
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 18/08/2017 08:38, John Emmas wrote:


AFAICT this problem got introduced by commit #fe2a9887a8 - in 
particular the change to 'gdbus-codegen.in' (line 30) which previously 
looked like this:-


elif os.name == 'nt':

but it got changed to this:-

elif os.basename(filedir) == 'bin'

Changing that line back again fixes the problem for me.



Maybe this'll make sense to someone... just after the following line (in 
'gdbus-codegen.in'):-


  sys.path.insert(0, os.path.abspath(path))

I inserted another line, like so:-

  print(sys.path)

On my system, this outputs a path string which happens to start with the 
following folder (notice the double backslashes):-


  F:\\GTK-SOURCES\\gnu-windows\\src\\MB3Glib\\gio\\gdbus-2.0

AFAICT the double-backslashes aren't contributing to the problem. The 
problem only occurs if that specific path is in my list of path strings 
(any other paths work fine).


I guess this could end up being a problem on my particular system - or 
maybe that specific path causes some build problem (an infinite loop maybe?)


Having said all that, I still don't understand why this line (in commit 
#fe2a9887a8):-


elif os.name == 'nt'

got changed to this:-

elif os.basename(filedir) == 'bin'

They clearly don't do the same thing...

Any thoughts anyone?  John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 17/08/2017 16:48, John Emmas wrote:


Any other Windows devs able to reproduce this or is it just me..?  
I've tried with python2.7, python3.1 and python3.3 and I see the same 
problem with all of them  :-(




AFAICT this problem got introduced by commit #fe2a9887a8 - in particular 
the change to 'gdbus-codegen.in' (line 30) which previously looked like 
this:-


elif os.name == 'nt':

but it got changed to this:-

elif os.basename(filedir) == 'bin'

Changing that line back again fixes the problem for me.  I haven't yet 
tried linking anything to the built libraries - but the build itself now 
completes successfully.  My guess is that whoever made that change is 
possibly cross-building (from Linux?) whereas a genuine Windows build 
won't work any more.


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 16/08/2017 09:11, John Emmas wrote:


Am I right in thinking that the gdbus-godegen stuff does still need to 
get built (i.e. generated)?


[...].

The script ran fine with my older version of gdbus-codegen (and still 
does)  But it won't work with the latest version  :-(


In case it's any help, it seems to be bombing out at line 196 of 
'codegen_main.py' - where I get this output:-


  line 196, in codegen_main
gen = codegen.CodeGenerator(all_ifaces,
  AttributeError: 'module' object has no attribute 'CodeGenerator'



Any other Windows devs able to reproduce this or is it just me..?  I've 
tried with python2.7, python3.1 and python3.3 and I see the same problem 
with all of them  :-(


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 15/08/2017 11:56, John Emmas wrote:




if I modify that command to substitute the new 'gdbus-codegen' 
(rather than the older 'gdbus-codegen.in') I get build errors. I'm 
guessing that maybe the command itself needs to be modified now?  Or 
if it looks okay to you guys, I'll supply some more information about 
the errors I'm seeing.




Am I right in thinking that the gdbus-godegen stuff does still need to 
get built (i.e. generated)?  Here's the command that I'm using:-


  python "gdbus-2.0/codegen/gdbus-codegen" --interface-prefix org. \
 --generate-c-code gdbus-daemon-generated --c-namespace 
_G dbus-daemon.xml


Is there anyone building on Windows who could try that command for me? 
As long as the relevant paths are set up, it'll work from a Command 
Prompt (though you'd need to get rid of the backslash and put everything 
on the same line).


I run it from this folder:-

  \Glib\gio

The script ran fine with my older version of gdbus-codegen (and still 
does)  But it won't work with the latest version  :-(


In case it's any help, it seems to be bombing out at line 196 of 
'codegen_main.py' - where I get this output:-


  line 196, in codegen_main
gen = codegen.CodeGenerator(all_ifaces,
  AttributeError: 'module' object has no attribute 'CodeGenerator'

Thanks...

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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 14/08/2017 16:47, Chun-wei Fan (范君維) wrote:


Take a look at this commit in GLib[1] for glib-genmarshal.  So, for 
Windows, after running the script to generate glib-genmarshal, 
assuming that you are running it in cmd.exe or your Visual Studio 
projects, instead of running it as "glib-genmarshal(.exe) arguments to it>", you do " glib-genmarshal> ", as you would running a 
Python script.  Note that I dropped the projects to build 
glib-genmarshal.exe from the Visual Studio projects.


You have to do likewise for glib-mkenums, by changing "interpretor>  ..." to " 
 ..."




Ah, I get it now!  Thanks guys.

Two of the three python scripts are working fine now but there's a 
problem with gdbus-codegen.  Here's the command I previously used with 
the older file (gdbus-codegen.in) :-


  python "gdbus-2.0/codegen/gdbus-codegen.in" --interface-prefix org. \
 --generate-c-code gdbus-daemon-generated --c-namespace 
_G dbus-daemon.xml


but if I modify that command to substitute the new 'gdbus-codegen' 
(rather than the older 'gdbus-codegen.in') I get build errors.  I'm 
guessing that maybe the command itself needs to be modified now?  Or if 
it looks okay to you guys, I'll supply some more information about the 
errors I'm seeing.  Thanks again,


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

Re: Building glib-genmarshal (while building glib)

[范君維]

Hi John,

Take a look at this commit in GLib[1] for glib-genmarshal.  So, for 
Windows, after running the script to generate glib-genmarshal, assuming 
that you are running it in cmd.exe or your Visual Studio projects, 
instead of running it as "glib-genmarshal(.exe) ", 
you do "  arguments to it>", as you would running a Python script.  Note that I 
dropped the projects to build glib-genmarshal.exe from the Visual Studio 
projects.


You have to do likewise for glib-mkenums, by changing "interpretor>  ..." to " 
 ..."


With blessings, and cheers!

[1]: 
https://git.gnome.org/browse/glib/commit/?id=a00e7ed32e510791016725ce0a3dc08f59b9a443



John Emmas 於 2017/8/13 上午 01:34 寫道:

On 12/08/2017 17:51, Bastien Nocera wrote:

There's no C to generate, it's been ported to Python.

So 'glib-genmarshal.exe' doesn't need to get generated any more? When 
I read about the port to python, I assumed it was just that the 
original perl scripts had been ported to python.


For glib-mkenums, the 'C' files are still getting generated, I think 
(gioenumtypes.c + gioenumtypes.h) ?.  Maybe I'm wrong about that...


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


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 12/08/2017 17:51, Bastien Nocera wrote:

There's no C to generate, it's been ported to Python.

So 'glib-genmarshal.exe' doesn't need to get generated any more? When I 
read about the port to python, I assumed it was just that the original 
perl scripts had been ported to python.


For glib-mkenums, the 'C' files are still getting generated, I think 
(gioenumtypes.c + gioenumtypes.h) ?.  Maybe I'm wrong about that...


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

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 12/08/2017 17:42, Ignacio Casal Quinteiro wrote:

Hey John,

Have u thought about using gvsbuild so we unite efforts building stuff 
with msvc?




Hi Ignacio,

At the moment I'm still building GTK+2 so it might not be relevant?  
Maybe a year or two ago, Microsoft itself was planning to release an 
"official" version of the GTK stack for Windows. Dunno whatever happened 
to it...


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

Re: Building glib-genmarshal (while building glib)

[Bastien Nocera]

On Sat, 2017-08-12 at 16:45 +0100, John Emmas wrote:
> On 12/08/2017 14:04, Sébastien Wilmet wrote:
> > >From the news file for version 2.53.4:
> > 
> > https://git.gnome.org/browse/glib/tree/NEWS
> > 
> > * glib-genmarshal and glib-mkenums have been rewritten in python.
> >   Every effort has been made to keep compatibility. Please report
> >   problems related to these tools
> > 
>  
> Thanks Sebastien,
> 
> Although I'm building with MSVC I don't use the official MSVC
> projects (mostly because I need to build 3 x targets:- 1) Debug
> build, 2) Release build and 3) Debuggable Release build).  I've
> figured out how to generate the file called "glib-genmarshal" -
> namely,

It'll be generated by configure, simply replace the python executable:
https://git.gnome.org/browse/glib/tree/gobject/glib-genmarshal.in

> python.exe  gen_util_scripts.py --type=glib-genmarshal --
> version=$(GlibVersion)
> 
> But I'm then stuck...  I can't figure out how to use that file to
> generate 'glib-genmarshal.c' (and/or any other files which need to
> get generated from it).

There's no C to generate, it's been ported to Python.

>   Can someone tell me the relevant command?  It isn't likely that
> this issue will affect anyone else.  Thanks,
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[Ignacio Casal Quinteiro]

Hey John,

Have u thought about using gvsbuild so we unite efforts building stuff with
msvc?

Cheers

El 12 ago. 2017 5:46 p. m., "John Emmas"  escribió:

> On 12/08/2017 14:04, Sébastien Wilmet wrote:
>
> >From the news file for version 2.53.4:
> https://git.gnome.org/browse/glib/tree/NEWS
>
> * glib-genmarshal and glib-mkenums have been rewritten in python.
>   Every effort has been made to keep compatibility. Please report
>   problems related to these tools
>
>
>
> Thanks Sebastien,
>
> Although I'm building with MSVC I don't use the official MSVC projects
> (mostly because I need to build 3 x targets:- 1) Debug build, 2) Release
> build and 3) Debuggable Release build).  I've figured out how to generate
> the file called "glib-genmarshal" - namely,
>
> python.exe  gen_util_scripts.py --type=glib-genmarshal
> --version=$(GlibVersion)
>
> But I'm then stuck...  I can't figure out how to use that file to generate
> 'glib-genmarshal.c' (and/or any other files which need to get generated
> from it).  Can someone tell me the relevant command?  It isn't likely that
> this issue will affect anyone else.  Thanks,
>
> John
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[John Emmas]

On 12/08/2017 14:04, Sébastien Wilmet wrote:

>From the news file for version 2.53.4:

https://git.gnome.org/browse/glib/tree/NEWS

* glib-genmarshal and glib-mkenums have been rewritten in python.
   Every effort has been made to keep compatibility. Please report
   problems related to these tools



Thanks Sebastien,

Although I'm building with MSVC I don't use the official MSVC projects 
(mostly because I need to build 3 x targets:- 1) Debug build, 2) Release 
build and 3) Debuggable Release build).  I've figured out how to 
generate the file called "glib-genmarshal" - namely,


python.exe  gen_util_scripts.py --type=glib-genmarshal 
--version=$(GlibVersion)


But I'm then stuck...  I can't figure out how to use that file to 
generate 'glib-genmarshal.c' (and/or any other files which need to get 
generated from it).  Can someone tell me the relevant command?  It isn't 
likely that this issue will affect anyone else.  Thanks,


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

Re: Building glib-genmarshal (while building glib)

[Tim-Philipp Müller]

On Sat, 2017-08-12 at 13:54 +0100, John Emmas wrote:

Hi John,

> What's happened to 'glib-genmarshal.c'?  It seems to have been
> removed from git master - although (AFAICT) it doesn't get auto-
> generated. A new file does get generated (gobject/glib-genmarshal)
> but i can't see how that gets used to generate glib-
> genmarshal.c..  What am I missing??  
> (I'm building on Windows BTW).

It has been rewritten in python, so there's nothing to compile any
more.

Cheers
 -Tim
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib-genmarshal (while building glib)

[Sébastien Wilmet]

On Sat, Aug 12, 2017 at 01:54:29PM +0100, John Emmas wrote:
> What's happened to 'glib-genmarshal.c'?  It seems to have been removed from
> git master - although (AFAICT) it doesn't get auto-generated.  A new file
> does get generated (gobject/glib-genmarshal) but i can't see how that gets
> used to generate glib-genmarshal.c..  What am I missing??  (I'm building on
> Windows BTW).

>From the news file for version 2.53.4:

https://git.gnome.org/browse/glib/tree/NEWS

* glib-genmarshal and glib-mkenums have been rewritten in python.
  Every effort has been made to keep compatibility. Please report
  problems related to these tools

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Building glib-genmarshal (while building glib)

[John Emmas]

What's happened to 'glib-genmarshal.c'?  It seems to have been removed 
from git master - although (AFAICT) it doesn't get auto-generated.  A 
new file does get generated (gobject/glib-genmarshal) but i can't see 
how that gets used to generate glib-genmarshal.c..  What am I missing??  
(I'm building on Windows BTW).


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

Re: Functional programming with GLib

[Joël Krähemann]

Hi

Why not doing a different approach? Provide serialization to your list
and pass it to AgsFunction?

I would love to see something alike in GSequencer. Thus I did a boxed
type AgsComplex.
The mention object above shall be able to solve mathematical equations.

Note I is not implemented for now. But feel free to provide solver strategies ;)
The goal is to let the user describe its synth by a formula.

nongnu.org/gsequencer

Bests,
Joël


On Sun, Apr 23, 2017 at 8:46 PM, Dirk-Jan C. Binnema
 wrote:
>
> Hi All,
>
> A while back, I wrote some functions for functional-flavored programming
> with GLib. It's fully documented[1], has tests, etc.
>
> It would (for me at least) be useful to have some of these functions in
> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager to
> accept contributions to GList... anyway, perhaps its useful for others.
>
> As a simple example, suppose we want to calculate the sum of primes up
> to 100 (a common task after all):
>
> ,
> | intsum;
> | GList *nums, *primes;
> |
> | nums   = gx_list_iota (100, 1, 1);
> | primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> | sum= gx_list_sum (primes); /* => 1060 */
> |
> | g_list_free (nums);
> | g_list_free (primes);
> `
>
> There's also folding, mapping etc. See a short article about this:
>http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> (2015?! time does fly). Am still developing it though.
>
> Repo: https://github.com/djcb/gxlib
> Docs: http://www.djcbsoftware.nl/code/gxlib/
>
> Best wishes,
> Dirk.
>
> --
> Dirk-Jan C. Binnema  Helsinki, Finland
> e:d...@djcbsoftware.nl   w:www.djcbsoftware.nl
> pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Stefan Sauer]

Am 09.05.2017 um 10:59 schrieb Tristan Van Berkom:
> On Mon, 2017-05-01 at 19:09 -0400, Matthias Clasen wrote:
>>
>>
>> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi 
>> wrote:
>>> For command line parsing I'd actually favour a slightly bolder
>>> approach of deprecating GOptionContext, and having something
>>> slightly
>>> more modern — in terms of being bindable in other languages, and
>>> well-integrated with API like GApplication.
>>>
>>
>> What is lacking in the current incarnation of commandline option
>> support in GApplication? 
> 
> Since this was raised here and I've currently been working with
> python's click library and trying to make some enhancements there, just
> thought I'd throw some things out there.
> 
> Some things that I'm finding important for CLI apps:
> 
> A.) Automatic generation of man pages and similar documentation,
> especially generating separate man pages for each separate sub
> command.
> 
> I'm not even sure, do we have this already ?

You can document your man page using gtkdoc (with a PROGRAM section). More
introspection would be nice though.

> 
> B.) Built-in support for bash completions, allowing optional overrides
> for the application to implement custom completion suggestions
> for selected options/arguments.
> 
> 
> This is all probably possible without completely replacing the API with
> a new one, though.
> 
> Cheers,
> -Tristan
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 

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

Re: [PATCH v2] glib/gpoll: Remove if conditional

[Alistair Francis]

On Wed, Jul 26, 2017 at 3:35 PM, Bastien Nocera  wrote:
> Patches are best attached to bugzilla. You can use "git-bz" to file the bug 
> and attach your path directly there.
>
> Don't hesitate to reply if you have trouble filing the bug or attaching the 
> patch.

Thanks, after pinging this I did some searching and found that
Bugzilla. I have opened a case there. Thanks for pointing that out
though.

Thanks,
Alistair

>
> Cheers
>
>> On 26 Jul 2017, at 22:16, Alistair Francis  wrote:
>>
>> On Fri, Jul 7, 2017 at 11:02 AM, Alistair Francis
>>  wrote:
>>> The original ready < nhandles - 1 can be re-written as ready + 1 < nhandles
>>> which is the same confition that we are checking on the first
>>> itteration of the for loop. This means we can remove the if statement
>>> and let the for loop check the code.
>>>
>>> This also has the side effect of removing an invalid check as
>>> WAIT_OBJECT_0 was not subtracted from ready in the if statement.
>>>
>>> Signed-off-by: Alistair Francis 
>>
>> Ping!
>>
>>> ---
>>> v2:
>>> - Rebase on master
>>> - Remove the first patch in the series as it was incorrect
>>>
>>> glib/gpoll.c | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/glib/gpoll.c b/glib/gpoll.c
>>> index 265cb9210..b6c83d8ed 100644
>>> --- a/glib/gpoll.c
>>> +++ b/glib/gpoll.c
>>> @@ -235,9 +235,8 @@ poll_rest (gboolean  poll_msgs,
>>>{
>>>  /* Remove the handle that fired */
>>>  int i;
>>> - if (ready < nhandles - 1)
>>> -   for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
>>> - handles[i-1] = handles[i];
>>> + for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
>>> +   handles[i-1] = handles[i];
>>>  nhandles--;
>>>  recursed_result = poll_rest (FALSE, handles, nhandles, fds, nfds, 
>>> 0);
>>>  return (recursed_result == -1) ? -1 : 1 + recursed_result;
>>> --
>>> 2.11.0
>>>
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH v2] glib/gpoll: Remove if conditional

[Bastien Nocera]

Patches are best attached to bugzilla. You can use "git-bz" to file the bug and 
attach your path directly there.

Don't hesitate to reply if you have trouble filing the bug or attaching the 
patch.

Cheers

> On 26 Jul 2017, at 22:16, Alistair Francis  wrote:
> 
> On Fri, Jul 7, 2017 at 11:02 AM, Alistair Francis
>  wrote:
>> The original ready < nhandles - 1 can be re-written as ready + 1 < nhandles
>> which is the same confition that we are checking on the first
>> itteration of the for loop. This means we can remove the if statement
>> and let the for loop check the code.
>> 
>> This also has the side effect of removing an invalid check as
>> WAIT_OBJECT_0 was not subtracted from ready in the if statement.
>> 
>> Signed-off-by: Alistair Francis 
> 
> Ping!
> 
>> ---
>> v2:
>> - Rebase on master
>> - Remove the first patch in the series as it was incorrect
>> 
>> glib/gpoll.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> 
>> diff --git a/glib/gpoll.c b/glib/gpoll.c
>> index 265cb9210..b6c83d8ed 100644
>> --- a/glib/gpoll.c
>> +++ b/glib/gpoll.c
>> @@ -235,9 +235,8 @@ poll_rest (gboolean  poll_msgs,
>>{
>>  /* Remove the handle that fired */
>>  int i;
>> - if (ready < nhandles - 1)
>> -   for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
>> - handles[i-1] = handles[i];
>> + for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
>> +   handles[i-1] = handles[i];
>>  nhandles--;
>>  recursed_result = poll_rest (FALSE, handles, nhandles, fds, nfds, 
>> 0);
>>  return (recursed_result == -1) ? -1 : 1 + recursed_result;
>> --
>> 2.11.0
>> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

Re: [PATCH v2] glib/gpoll: Remove if conditional

[Alistair Francis]

On Fri, Jul 7, 2017 at 11:02 AM, Alistair Francis
 wrote:
> The original ready < nhandles - 1 can be re-written as ready + 1 < nhandles
> which is the same confition that we are checking on the first
> itteration of the for loop. This means we can remove the if statement
> and let the for loop check the code.
>
> This also has the side effect of removing an invalid check as
> WAIT_OBJECT_0 was not subtracted from ready in the if statement.
>
> Signed-off-by: Alistair Francis 

Ping!

> ---
> v2:
>  - Rebase on master
>  - Remove the first patch in the series as it was incorrect
>
>  glib/gpoll.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/glib/gpoll.c b/glib/gpoll.c
> index 265cb9210..b6c83d8ed 100644
> --- a/glib/gpoll.c
> +++ b/glib/gpoll.c
> @@ -235,9 +235,8 @@ poll_rest (gboolean  poll_msgs,
> {
>   /* Remove the handle that fired */
>   int i;
> - if (ready < nhandles - 1)
> -   for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
> - handles[i-1] = handles[i];
> + for (i = ready - WAIT_OBJECT_0 + 1; i < nhandles; i++)
> +   handles[i-1] = handles[i];
>   nhandles--;
>   recursed_result = poll_rest (FALSE, handles, nhandles, fds, nfds, 
> 0);
>   return (recursed_result == -1) ? -1 : 1 + recursed_result;
> --
> 2.11.0
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib-2 2.46.2 unittest regex fails

[Ross Burton]

On 4 July 2017 at 08:03, Nikita Gupta  wrote:

> I am using Yocto poky Distro version 1.8.1 to build my image.
> And have used Glib-2 version 2.46.2 package.
>

Yocto 1.8.1 doesn't come with 2.46.2.  Did you do the upgrade yourself, or
backport the upgrade from a later Yocto release?

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

Glib-2 2.46.2 unittest regex fails

[Nikita Gupta]

Hi All,

I am using Yocto poky Distro version 1.8.1 to build my image.
And have used Glib-2 version 2.46.2 package.

While testing glib-2 unittests, one of the test case "glib/regex.test"
failed with below logs:

# ERROR:../../../glib-2.46.2/glib/tests/regex.c:129:test_new_fail:
assertion failed (error == (g-regex-error-quark, 142)): Error while
compiling regular expression (?(?___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Matthias Clasen]

On Tue, May 9, 2017 at 4:59 AM, Tristan Van Berkom <
tristan.vanber...@codethink.co.uk> wrote:

>
> Some things that I'm finding important for CLI apps:
>
> A.) Automatic generation of man pages and similar documentation,
> especially generating separate man pages for each separate sub
> command.
>
> I'm not even sure, do we have this already ?
>

I fail to see the value of a man page that just repeats what --help already
tells me.  Why is this useful ?


> B.) Built-in support for bash completions, allowing optional overrides
> for the application to implement custom completion suggestions
> for selected options/arguments.
>

This on the other hand, is very useful. But hard to do in a way that is
generic enough for all possible styles of
commandline interface that people have built with GOption. Do you have a
suggestion for this ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Tristan Van Berkom]

On Mon, 2017-05-01 at 19:09 -0400, Matthias Clasen wrote:
> 
> 
> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi 
> wrote:
> > For command line parsing I'd actually favour a slightly bolder
> > approach of deprecating GOptionContext, and having something
> > slightly
> > more modern — in terms of being bindable in other languages, and
> > well-integrated with API like GApplication.
> > 
> 
> What is lacking in the current incarnation of commandline option
> support in GApplication? 

Since this was raised here and I've currently been working with
python's click library and trying to make some enhancements there, just
thought I'd throw some things out there.

Some things that I'm finding important for CLI apps:

A.) Automatic generation of man pages and similar documentation,
    especially generating separate man pages for each separate sub
    command.

    I'm not even sure, do we have this already ?

B.) Built-in support for bash completions, allowing optional overrides
    for the application to implement custom completion suggestions
    for selected options/arguments.


This is all probably possible without completely replacing the API with
a new one, though.

Cheers,
    -Tristan

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

Re: Functional programming with GLib

[Emmanuele Bassi]

On 2 May 2017 at 00:09, Matthias Clasen  wrote:

> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi  wrote:
>>
>> For command line parsing I'd actually favour a slightly bolder
>> approach of deprecating GOptionContext, and having something slightly
>> more modern — in terms of being bindable in other languages, and
>> well-integrated with API like GApplication.
>>
>
> What is lacking in the current incarnation of commandline option support in
> GApplication?

In general, a nicer API that does not rely on
GOptionEntry/GOptionGroup, which are barely introspectable, or that
does not rely on calling g_application_add_main_option() for every
single option in order to avoid the memory management weirdness of
GOptionEntry.

The other issue is that the command line options are accessible using
the GVariant API as a dictionary, which requires additional
translation into application data structures; you need to use
g_variant_dict_lookup(), which is not the nicest API in the world;
high level languages may be able to unpack the GVariantDict, but I'm
not entirely sure if that's actually the case.

Adding command line parsing in JavaScript based on the GLib API (since
JS does not have a "native" module to do that, like Python's
ArgParser) is usually pretty rough; I'd like to see something better
in that area.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Matthias Clasen]

On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi  wrote:

> For command line parsing I'd actually favour a slightly bolder
> approach of deprecating GOptionContext, and having something slightly
> more modern — in terms of being bindable in other languages, and
> well-integrated with API like GApplication.
>
>
What is lacking in the current incarnation of commandline option support in
GApplication?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Dirk-Jan C. Binnema]

Hi Philip,

On Thursday Apr 27 2017, Philip Withnall wrote:

> Hey,
>
> The general policy for GLib is that utility functions which are useful
> (and used in) several projects are considered for being added to GLib.
>
> To me, a functional programming approach using GLists is not something
> which every project is going to use. Is there any harm in keeping it as
> a separate library? There’s nothing stopping projects from linking to
> GLib *and* GXLib. :-)

> The command line parsing stuff you have looks a bit more widely
> applicable. Were you considering merging those into GLib?
>
> http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html
>
> Anyway, nice work on GXLib. It looks well documented.

Thanks! Yeah, the functional approach may not be for everyone, though of
course one could argue that that didn't stop C++, Rust etc., but true,
there's value in keeping GLib lean.

The command-line stuff is an attempt to trick the GLib option-parser
into working with sub-commands, and it's been quite a time-saver for
some of my projects. Still, it is a bit clumsy in places, since it the
GLib option parser doesn't expose some of the details that would be
useful.

But as Emmanuele mentions, perhaps some bigger/braver effort would be
better.

Anyway, I'll keep GXLib around for my own projects and for whomever. In
fact, I'd happily take contributions for "GLibberish" code that doesn't
quite fit into GLib.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema  Helsinki, Finland
e:d...@djcbsoftware.nl   w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Philip Withnall]

I was thinking about that, but then fell into the trap of worrying
about suggesting it because someone might expect me to implement it.

I agree though; a reworking of GOptionContext which integrates better
with GApplication, supports sub-commands and supports custom argument
formats more easily would be lovely. Drawing inspiration from python-
argparse would also be good.

Philip

On Thu, 2017-04-27 at 15:29 +0100, Emmanuele Bassi wrote:
> For command line parsing I'd actually favour a slightly bolder
> approach of deprecating GOptionContext, and having something slightly
> more modern — in terms of being bindable in other languages, and
> well-integrated with API like GApplication.
> 
> For instance, something similar to [clap.rs][0].
> 
> Ciao,
>  Emmanuele.
> 
> [0]: https://clap.rs/
> 
> On 27 April 2017 at 15:15, Philip Withnall 
> wrote:
> > Hey,
> > 
> > The general policy for GLib is that utility functions which are
> > useful
> > (and used in) several projects are considered for being added to
> > GLib.
> > 
> > To me, a functional programming approach using GLists is not
> > something
> > which every project is going to use. Is there any harm in keeping
> > it as
> > a separate library? There’s nothing stopping projects from linking
> > to
> > GLib *and* GXLib. :-)
> > 
> > The command line parsing stuff you have looks a bit more widely
> > applicable. Were you considering merging those into GLib?
> > 
> > http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.ht
> > ml
> > 
> > Anyway, nice work on GXLib. It looks well documented.
> > 
> > Philip
> > 
> > On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
> > > Hi All,
> > > 
> > > A while back, I wrote some functions for functional-flavored
> > > programming
> > > with GLib. It's fully documented[1], has tests, etc.
> > > 
> > > It would (for me at least) be useful to have some of these
> > > functions
> > > in
> > > GLib-proper, but I suspect the GLib-maintainers are not /too/
> > > eager
> > > to
> > > accept contributions to GList... anyway, perhaps its useful for
> > > others.
> > > 
> > > As a simple example, suppose we want to calculate the sum of
> > > primes
> > > up
> > > to 100 (a common task after all):
> > > 
> > > ,
> > > > intsum;
> > > > GList *nums, *primes;
> > > > 
> > > > nums   = gx_list_iota (100, 1, 1);
> > > > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> > > > sum= gx_list_sum (primes); /* => 1060 */
> > > > 
> > > > g_list_free (nums);
> > > > g_list_free (primes);
> > > 
> > > `
> > > 
> > > There's also folding, mapping etc. See a short article about
> > > this:
> > >    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> > > (2015?! time does fly). Am still developing it though.
> > > 
> > > Repo: https://github.com/djcb/gxlib
> > > Docs: http://www.djcbsoftware.nl/code/gxlib/
> > > 
> > > Best wishes,
> > > Dirk.
> > > 
> > 
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> > 
> 
> 
> 

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

Re: Functional programming with GLib

[Emmanuele Bassi]

For command line parsing I'd actually favour a slightly bolder
approach of deprecating GOptionContext, and having something slightly
more modern — in terms of being bindable in other languages, and
well-integrated with API like GApplication.

For instance, something similar to [clap.rs][0].

Ciao,
 Emmanuele.

[0]: https://clap.rs/

On 27 April 2017 at 15:15, Philip Withnall  wrote:
> Hey,
>
> The general policy for GLib is that utility functions which are useful
> (and used in) several projects are considered for being added to GLib.
>
> To me, a functional programming approach using GLists is not something
> which every project is going to use. Is there any harm in keeping it as
> a separate library? There’s nothing stopping projects from linking to
> GLib *and* GXLib. :-)
>
> The command line parsing stuff you have looks a bit more widely
> applicable. Were you considering merging those into GLib?
>
> http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html
>
> Anyway, nice work on GXLib. It looks well documented.
>
> Philip
>
> On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
>> Hi All,
>>
>> A while back, I wrote some functions for functional-flavored
>> programming
>> with GLib. It's fully documented[1], has tests, etc.
>>
>> It would (for me at least) be useful to have some of these functions
>> in
>> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager
>> to
>> accept contributions to GList... anyway, perhaps its useful for
>> others.
>>
>> As a simple example, suppose we want to calculate the sum of primes
>> up
>> to 100 (a common task after all):
>>
>> ,
>> > intsum;
>> > GList *nums, *primes;
>> >
>> > nums   = gx_list_iota (100, 1, 1);
>> > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
>> > sum= gx_list_sum (primes); /* => 1060 */
>> >
>> > g_list_free (nums);
>> > g_list_free (primes);
>>
>> `
>>
>> There's also folding, mapping etc. See a short article about this:
>>http://www.djcbsoftware.nl/2015/10/04/functional-glists/
>> (2015?! time does fly). Am still developing it though.
>>
>> Repo: https://github.com/djcb/gxlib
>> Docs: http://www.djcbsoftware.nl/code/gxlib/
>>
>> Best wishes,
>> Dirk.
>>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Philip Withnall]

Hey,

The general policy for GLib is that utility functions which are useful
(and used in) several projects are considered for being added to GLib.

To me, a functional programming approach using GLists is not something
which every project is going to use. Is there any harm in keeping it as
a separate library? There’s nothing stopping projects from linking to
GLib *and* GXLib. :-)

The command line parsing stuff you have looks a bit more widely
applicable. Were you considering merging those into GLib?

http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html

Anyway, nice work on GXLib. It looks well documented.

Philip

On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
> Hi All,
> 
> A while back, I wrote some functions for functional-flavored
> programming
> with GLib. It's fully documented[1], has tests, etc.
> 
> It would (for me at least) be useful to have some of these functions
> in
> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager
> to
> accept contributions to GList... anyway, perhaps its useful for
> others.
> 
> As a simple example, suppose we want to calculate the sum of primes
> up
> to 100 (a common task after all):
> 
> ,
> > intsum;
> > GList *nums, *primes;
> > 
> > nums   = gx_list_iota (100, 1, 1);
> > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> > sum= gx_list_sum (primes); /* => 1060 */
> > 
> > g_list_free (nums);
> > g_list_free (primes);
> 
> `
> 
> There's also folding, mapping etc. See a short article about this:
>    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> (2015?! time does fly). Am still developing it though.
> 
> Repo: https://github.com/djcb/gxlib
> Docs: http://www.djcbsoftware.nl/code/gxlib/
> 
> Best wishes,
> Dirk.
> 

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

Functional programming with GLib

[Dirk-Jan C. Binnema]

Hi All,

A while back, I wrote some functions for functional-flavored programming
with GLib. It's fully documented[1], has tests, etc.

It would (for me at least) be useful to have some of these functions in
GLib-proper, but I suspect the GLib-maintainers are not /too/ eager to
accept contributions to GList... anyway, perhaps its useful for others.

As a simple example, suppose we want to calculate the sum of primes up
to 100 (a common task after all):

,
| intsum;
| GList *nums, *primes;
|
| nums   = gx_list_iota (100, 1, 1);
| primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
| sum= gx_list_sum (primes); /* => 1060 */
|
| g_list_free (nums);
| g_list_free (primes);
`

There's also folding, mapping etc. See a short article about this:
   http://www.djcbsoftware.nl/2015/10/04/functional-glists/
(2015?! time does fly). Am still developing it though.

Repo: https://github.com/djcb/gxlib
Docs: http://www.djcbsoftware.nl/code/gxlib/

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:d...@djcbsoftware.nl   w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib on MinGW

[Anton Shepelev]

I wrote:

> When building Glib in MinGW I get these errors:
>
>   /bin/sh: dumpbin.exe: command not found
>
>   Digital Mars Librarian Version 8.02n
>   Copyright (C) Digital Mars 2000-2007 All Rights Reserved
>   http://www.digitalmars.com/ctg/lib.html
>
>   Error: unrecognized switch '-machine:X86'
>
> dumpbin.exe is a proprietary Microsoft tool.  Must
> Glib depend on it?

I have mustered all my patience and installed  these
tools  from  MS  Visual  Studio 2010 express.  Now I
have this error while building:

  ginetaddress.c: In function 'inet_ntop':
  ginetaddress.c:432:26: warning: comparison between pointer and integer
 if (ws2funcs.pInetNtop != NULL)
^
  ginetaddress.c:433:12: error: called object is not a function or function 
pointer
   return ws2funcs.pInetNtop (family, addr, addr_str, size);
  ^
  ginetaddress.c: In function 'inet_pton':
  ginetaddress.c:423:1: warning: control reaches end of non-void function 
[-Wreturn-type]
   }
   ^

This is Glib 2.52.1.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building glib on MinGW

[Nirbheek Chauhan]

On Mon, Apr 10, 2017 at 12:12 AM, Anton Shepelev  wrote:
> I don't know what lib.exe is, but it may also  be  a
> Microsoft tool:
>
> https://msdn.microsoft.com/en-us/library/0xb6w1f8.aspx
>
> Can I build Glib in MinGW without these tools?
>

lib.exe is probably used for creating MSVC-compatible import
libraries. You can't really use dlltool for that because of a binutils
bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12633

You might be able to replace dumpbin with objdump. Try it out and see
if it can be done?

Cheers,
Nirbheek
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Building glib on MinGW

[Anton Shepelev]

Hello, all

When building Glib in MinGW I get these errors:

  /bin/sh: dumpbin.exe: command not found

  Digital Mars Librarian Version 8.02n
  Copyright (C) Digital Mars 2000-2007 All Rights Reserved
  http://www.digitalmars.com/ctg/lib.html

  Error: unrecognized switch '-machine:X86'

dumpbin.exe  is  a proprietary Microsoft tool.  Must
Glib depend on it?

I don't know what lib.exe is, but it may also  be  a
Microsoft tool:

https://msdn.microsoft.com/en-us/library/0xb6w1f8.aspx

Can I build Glib in MinGW without these tools?

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

(glib) Lock Manager

[Nodar Nutsubidze]

Hi everyone,

Preface:
I have been working in C for many years and GLIB is the best thing since
sliced bread for C programming. The one thing that I've wanted for some
time is a way to abstract locks to a single lock and just use them in a
session. I've also have ran into issues with other programs which have had
deadlock issues and such and would always have wanted a way to see what
locks are taken and by whom but in a deadlock scenario your only options
are gdb and long story short that is not fun (could go in detail but its
more fun to stare at grass while its growing).

Made a program for this which is a lock manager which incorporates the
GMutex, GRecMutex and GRWLock into a single GLock. Below is a link to my
github with examples of this as well as usage in main.c. I wrote this with
the hopes that if its useful it could be incorporated into GLib.

If there is something already for this that I missed please let me know.

Do you feel that this is something that would be useful for GLib if so let
me know how I can help.

Link:
https://github.com/Darless/GLockManager

Thanks,

Nodar Nutsubidze
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Bastien Nocera]

On Mon, 2017-01-02 at 16:02 +0100, Stefan Sauer wrote:
> On 12/30/2016 12:09 PM, jcup...@gmail.com wrote:
> > On 29 December 2016 at 23:55, Emmanuele Bassi 
> > wrote:
> > > As Philip explained earlier in the thread, Valgrind can only
> > > accept a
> > > single suppression file. So, if GTK+ ships a suppression file, it
> > > would need to include suppression rules for all its dependencies,
> > > and
> > > you would still be unable to add your own on top of that. The
> > > only way
> > 
> > I realize you're talking about the default suppressions file, but
> > of
> > course valgrind can load many non-default suppression files at
> > once.
> > Up to 100, according to the man page.
> 
> you were quicker than me :) But yep, up to 100 and I think if an app
> has
> more that 100 dependencies they've got worse problems that exceeding
> this count.

Would be nice to be able to pass a directory of suppression files, so
that we don't need to do this manually.

> > 
> > $ valgrind --suppressions=/first/file.supp --
> > suppressions=/second/file.supp ...
> > 
> > So I think there would be some value in shipping separate, official
> > .supps for glib, gobject, gio, gtk etc etc.
> > 
> > We'd need one for each .pc file, so Stefan's suggestion of a
> > pkg-config var sounds very reasonable to me.
> > 
> > John
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Stefan Sauer]

On 12/30/2016 12:09 PM, jcup...@gmail.com wrote:
> On 29 December 2016 at 23:55, Emmanuele Bassi  wrote:
>> As Philip explained earlier in the thread, Valgrind can only accept a
>> single suppression file. So, if GTK+ ships a suppression file, it
>> would need to include suppression rules for all its dependencies, and
>> you would still be unable to add your own on top of that. The only way
> I realize you're talking about the default suppressions file, but of
> course valgrind can load many non-default suppression files at once.
> Up to 100, according to the man page.

you were quicker than me :) But yep, up to 100 and I think if an app has
more that 100 dependencies they've got worse problems that exceeding
this count.

Stefan
>
> $ valgrind --suppressions=/first/file.supp --suppressions=/second/file.supp 
> ...
>
> So I think there would be some value in shipping separate, official
> .supps for glib, gobject, gio, gtk etc etc.
>
> We'd need one for each .pc file, so Stefan's suggestion of a
> pkg-config var sounds very reasonable to me.
>
> John
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Sébastien Wilmet]

On Thu, Dec 29, 2016 at 11:55:35PM +0100, Stefan Sauer wrote:
> Sorry for reviving the thread. What if upstream lib ship a suppression
> file and add a pkg-config variable pointing to it? Then apps can use
> $PKG_CONFIG --variable=valgrind_suppressions gtk+-3.0
> to collect those and e.g. export them into a valgrind wrapper or use
> them in the test runners.

Things are moving, see this recent glib commit:
https://git.gnome.org/browse/glib/commit/?id=a24f57b071758b01500e2b4b9c05d2a60f8280bf

"glib: Add installed Valgrind suppressions file for GLib and GIO"

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[jcupitt]

On 29 December 2016 at 23:55, Emmanuele Bassi  wrote:
> As Philip explained earlier in the thread, Valgrind can only accept a
> single suppression file. So, if GTK+ ships a suppression file, it
> would need to include suppression rules for all its dependencies, and
> you would still be unable to add your own on top of that. The only way

I realize you're talking about the default suppressions file, but of
course valgrind can load many non-default suppression files at once.
Up to 100, according to the man page.

$ valgrind --suppressions=/first/file.supp --suppressions=/second/file.supp ...

So I think there would be some value in shipping separate, official
.supps for glib, gobject, gio, gtk etc etc.

We'd need one for each .pc file, so Stefan's suggestion of a
pkg-config var sounds very reasonable to me.

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

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Emmanuele Bassi]

Hi Stefan;

On 29 December 2016 at 22:55, Stefan Sauer  wrote:


> Sorry for reviving the thread. What if upstream lib ship a suppression
> file and add a pkg-config variable pointing to it? Then apps can use
> $PKG_CONFIG --variable=valgrind_suppressions gtk+-3.0
> to collect those and e.g. export them into a valgrind wrapper or use
> them in the test runners.

As Philip explained earlier in the thread, Valgrind can only accept a
single suppression file. So, if GTK+ ships a suppression file, it
would need to include suppression rules for all its dependencies, and
you would still be unable to add your own on top of that. The only way
around would be for every dependency you have to ship a suppression
file for their own symbols only, without duplicates, concatenate them
all to your own, and then feed it to your test suite. Every time
there's an update, you'd have to redo the concatenation and possibly
weed out duplicates manually.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Stefan Sauer]

On 08/02/2016 05:13 PM, Sébastien Wilmet wrote:
> On Tue, Aug 02, 2016 at 01:47:41PM +0100, Philip Withnall wrote:
>> On Mon, 2016-08-01 at 20:10 +0200, Sébastien Wilmet wrote:
>>> So, is there an up-to-date Valgrind suppression file somewhere? Or is
>>> GNOME.supp the most up-to-date?
>> The one I’ve been using is here:
>>
>> https://github.com/pwithnall/walbottle/blob/master/libwalbottle/tests/w
>> albottle.supp
>>
>> It covers most of the GLib and GIO functionality which I’ve been using
>> recently. Enough to get the Walbottle tests Valgrind-clean, at least.
>>
>> I do not claim it’s anything like perfect though.
> I already get much better results with walbottle.supp, at least for the
> tests depending only on GLib/GObject. Thanks a lot!
>
>> This has been discussed before, and I failed to do anything about it:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=666114#c28
>>
>> Installing a suppression file with GLib won’t fix everything, because
>> Valgrind only has one default suppression file, which we can’t modify
>> or add to. So even if GLib installed a suppression file, you’d have to
>> pass it as a --suppressions argument to Valgrind manually. However,
>> that is better than having to write your own suppressions file //and//
>> pass it in.
>>
>> See here for information about default.supp:
>>
>> https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto#Valgrind_and
>> _suppression_files
>>
>> Valgrind has a couple of bugs open about improving its support for
>> default suppressions. None of them have seen activity recently:
>>
>> https://bugs.kde.org/show_bug.cgi?id=93376
>> https://bugs.kde.org/show_bug.cgi?id=160905 (basically a duplicate)
> And thanks for the links. I also think that it would be useful to have a
> suppression file upstream, even if it is incomplete.

Sorry for reviving the thread. What if upstream lib ship a suppression
file and add a pkg-config variable pointing to it? Then apps can use
$PKG_CONFIG --variable=valgrind_suppressions gtk+-3.0
to collect those and e.g. export them into a valgrind wrapper or use
them in the test runners.

Stefan

>
> --
> Sébastien
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Sébastien Wilmet]

On Tue, Aug 02, 2016 at 01:47:41PM +0100, Philip Withnall wrote:
> On Mon, 2016-08-01 at 20:10 +0200, Sébastien Wilmet wrote:
> > So, is there an up-to-date Valgrind suppression file somewhere? Or is
> > GNOME.supp the most up-to-date?
> 
> The one I’ve been using is here:
> 
> https://github.com/pwithnall/walbottle/blob/master/libwalbottle/tests/w
> albottle.supp
> 
> It covers most of the GLib and GIO functionality which I’ve been using
> recently. Enough to get the Walbottle tests Valgrind-clean, at least.
> 
> I do not claim it’s anything like perfect though.

I already get much better results with walbottle.supp, at least for the
tests depending only on GLib/GObject. Thanks a lot!

> This has been discussed before, and I failed to do anything about it:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=666114#c28
> 
> Installing a suppression file with GLib won’t fix everything, because
> Valgrind only has one default suppression file, which we can’t modify
> or add to. So even if GLib installed a suppression file, you’d have to
> pass it as a --suppressions argument to Valgrind manually. However,
> that is better than having to write your own suppressions file //and//
> pass it in.
> 
> See here for information about default.supp:
> 
> https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto#Valgrind_and
> _suppression_files
> 
> Valgrind has a couple of bugs open about improving its support for
> default suppressions. None of them have seen activity recently:
> 
> https://bugs.kde.org/show_bug.cgi?id=93376
> https://bugs.kde.org/show_bug.cgi?id=160905 (basically a duplicate)

And thanks for the links. I also think that it would be useful to have a
suppression file upstream, even if it is incomplete.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Philip Withnall]

Hey,

On Mon, 2016-08-01 at 20:10 +0200, Sébastien Wilmet wrote:
> GLib/GTK+ don't seem to provide a Valgrind suppression file upstream.
> At
> the following wiki page:
> https://wiki.gnome.org/Valgrind

That page is fairly outdated. I’ll give it a bit of a spruce up.

> So, is there an up-to-date Valgrind suppression file somewhere? Or is
> GNOME.supp the most up-to-date?

The one I’ve been using is here:

https://github.com/pwithnall/walbottle/blob/master/libwalbottle/tests/w
albottle.supp

It covers most of the GLib and GIO functionality which I’ve been using
recently. Enough to get the Walbottle tests Valgrind-clean, at least.

I do not claim it’s anything like perfect though.

> I'm aware of:
>   "Make GLib valgrind friendly"
>   https://bugzilla.gnome.org/show_bug.cgi?id=627423
> But in that bug, there is no significant activity since 2013, so if
> there is an up-to-date suppression file, it might make sense to
> include
> it upstream, and install it.

This has been discussed before, and I failed to do anything about it:

https://bugzilla.gnome.org/show_bug.cgi?id=666114#c28

Installing a suppression file with GLib won’t fix everything, because
Valgrind only has one default suppression file, which we can’t modify
or add to. So even if GLib installed a suppression file, you’d have to
pass it as a --suppressions argument to Valgrind manually. However,
that is better than having to write your own suppressions file //and//
pass it in.

See here for information about default.supp:

https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto#Valgrind_and
_suppression_files

Valgrind has a couple of bugs open about improving its support for
default suppressions. None of them have seen activity recently:

https://bugs.kde.org/show_bug.cgi?id=93376
https://bugs.kde.org/show_bug.cgi?id=160905 (basically a duplicate)

Philip

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

Up-to-date Valgrind suppression file for GLib/GTK+ ?

[Sébastien Wilmet]

Hello,

GLib/GTK+ don't seem to provide a Valgrind suppression file upstream. At
the following wiki page:
https://wiki.gnome.org/Valgrind

I see that there is:
1) https://people.gnome.org/~johan/gtk.suppression
2) https://github.com/dtrebbien/GNOME.supp

1) is for Gtk+ 2.12, according to the comment at the top.
2) is more recent, but not up-to-date, for example I see:

==6677== 16 bytes in 1 blocks are possibly lost in loss record 1,488 of 6,253
==6677==at 0x4C2DA60: calloc (vg_replace_malloc.c:711)
==6677==by 0x74648FF: g_malloc0 (gmem.c:124)
==6677==by 0x7464BC7: g_malloc0_n (gmem.c:355)
==6677==by 0x6DD922B: type_set_qdata_W (gtype.c:3718)
==6677==by 0x6DD9528: type_add_flags_W (gtype.c:3783)
==6677==by 0x6DD79C6: g_type_register_fundamental (gtype.c:2659)
==6677==by 0x6DB59F3: _g_enum_types_init (genums.c:124)
==6677==by 0x6DDA683: gobject_init (gtype.c:4426)
==6677==by 0x6DDA6AD: gobject_init_ctor (gtype.c:4487)
==6677==by 0x400FDA9: call_init.part.0 (in /usr/lib64/ld-2.23.so)
==6677==by 0x400FEBA: _dl_init (in /usr/lib64/ld-2.23.so)
==6677==by 0x4000CB9: ??? (in /usr/lib64/ld-2.23.so)

I think all things initialized in gobject_init_ctor() can be suppressed,
the same for other "ctor" functions.

So, is there an up-to-date Valgrind suppression file somewhere? Or is
GNOME.supp the most up-to-date?

I'm aware of:
  "Make GLib valgrind friendly"
  https://bugzilla.gnome.org/show_bug.cgi?id=627423
But in that bug, there is no significant activity since 2013, so if
there is an up-to-date suppression file, it might make sense to include
it upstream, and install it.

Thanks in advance,
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list