Re: gobject-introspection Version 1 || GNOME

[philip . chimento]

Hi,

As is the standard in open-source software, you can find the license
information in the COPYING file in the root directory of the source
distribution or Git repository:
https://gitlab.gnome.org/GNOME/gobject-introspection/blob/master/COPYING

We do not have an ECCN number. Although I don't believe that
gobject-introspection uses encryption directly, it can be used to load
encryption libraries in client code, and there are no restrictions on the
purpose it could be used for.

I make no guarantees as to the accuracy of this information. We
unfortunately cannot provide any legally binding details, other than what
you can find yourself by inspecting the source code. Since many of our
contributors are individuals, not connected with any company, we cannot do
anything that might expose them to legal liability.

Best regards,
Philip C

On Wed, Mar 7, 2018 at 2:27 AM Chhabra, Komal /CS <
komal.chha...@exxonmobil.com> wrote:

> Hi Team,
>
>
>
> This is Komal Chhabra, a Team Lead from centralized license management
> team of ExxonMobil known as Software Asset Management[previously known as
> ITAM. The Software Asset Management group at ExxonMobil exists in large
> part to steward software license compliance
>
>
>
> We are contacting you to get *ECCN *details for product *gobject-introspection
> Version 1 *:
>
>
>
> Could you please provide us the ECCN number for this software
>
>
>
> *  If you do not have your software classified with an ECCN,
> please kindly answer the following questions* so that we may self-assess
> if there may be any prohibition or restriction for export or re-export of
> this product.
>
>
>
>  1, Does the Software perform any encryption or utilize any
> encryption processes?  Y/N
>
>  2. If the answer is YES to question 1, please indicate if the
> encryption is coded into the application or separately called (such as
> using SSL)
>
>  3. If the answer is YES to question 1, please indicate what
> function(s) the cryptography/encryption serves
>
>
>
> A, Copyright protection purposes (Includes using a license
> key/code)
>
> B, User authentication purposes
>
>C, A core part of the functionality such as to encrypt databases
>
>D, To encrypt communications between the software and a host
> system.
>
>
>
>  Background information:
>
>  An Export Control Classification Number (ECCN) is a specific
> alpha-numeric code that identifies the level of export control for items
> e.g. software that are exported from member states of the Wassenaar
> Arrangement, including the United States. After obtaining the ECCN, the
> exporter must determine  whether an export license is required
>
>
>
> Waiting for your kind acknowledgment.
>
>
>
> Regards,
>
>
>
> *Komal Chhabra*
>
> *New Products & Complex Team*
>
> *EMIT | IT OPS | Customer Infrastructure | WDS | SAM*
>
>
>
> *HCL Technologies Ltd. *
>
> *(CIN: L74140DL1991PLC046369)*
>
> *10th Floor, ODC-IV, Software Tower 6, Sector 126*
>
> *Noida SEZ, Uttar Pradesh – 201301, India*
>
> *Email : komal.chha...@em-msph.com <komal.chha...@em-msph.com>*
>
>
>
> *for*
>
>
>
> *ExxonMobil Global Services Company*
>
> *22777 Springwoods Village Parkway*
>
> *Spring, TX 77389*
>
> *United States of America*
>
>
>
>
>
> *From:* Chhabra, Komal /CS
> *Sent:* Friday, February 23, 2018 2:46 PM
> *To:* 'gtk-devel-list@gnome.org' <gtk-devel-list@gnome.org>
> *Subject:* RE: gobject-introspection Version 1 || GNOME
> *Importance:* High
>
>
>
> Hi Team,
>
>
>
> This is Komal Chhabra, a Team Lead from centralized license management
> team of ExxonMobil known as Software Asset Management[previously known as
> ITAM. The Software Asset Management group at ExxonMobil exists in large
> part to steward software license compliance
>
>
>
> We are contacting you to get *few* details for product *
> gobject-introspection Version 1 *:
>
>
>
> 1.   Under which agreement it falls under: MIT , GPL or LPGL ?
>
> 2.   Could you please provide us the ECCN number for this software
>
>
>
> *  If you do not have your software classified with an ECCN,
> please kindly answer the following questions* so that we may self-assess
> if there may be any prohibition or restriction for export or re-export of
> this product.
>
>
>
>  1, Does the Software perform any encryption or utilize any
> encryption processes?  Y/N
>
>  2. If the answer is YES to question 1, please indicate if the
> encryptio

RE: gobject-introspection Version 1 || GNOME

[Chhabra, Komal /CS]

Hi Team,

This is Komal Chhabra, a Team Lead from centralized license management team of 
ExxonMobil known as Software Asset Management[previously known as ITAM. The 
Software Asset Management group at ExxonMobil exists in large part to steward 
software license compliance

We are contacting you to get ECCN details for product gobject-introspection 
Version 1 :


Could you please provide us the ECCN number for this software

  If you do not have your software classified with an ECCN, please 
kindly answer the following questions so that we may self-assess if there may 
be any prohibition or restriction for export or re-export of this product.

 1, Does the Software perform any encryption or utilize any 
encryption processes?  Y/N
 2. If the answer is YES to question 1, please indicate if the 
encryption is coded into the application or separately called (such as using 
SSL)
 3. If the answer is YES to question 1, please indicate what 
function(s) the cryptography/encryption serves

A, Copyright protection purposes (Includes using a license key/code)
B, User authentication purposes
   C, A core part of the functionality such as to encrypt databases
   D, To encrypt communications between the software and a host system.

 Background information:
 An Export Control Classification Number (ECCN) is a specific 
alpha-numeric code that identifies the level of export control for items e.g. 
software that are exported from member states of the Wassenaar Arrangement, 
including the United States. After obtaining the ECCN, the exporter must 
determine  whether an export license is required

Waiting for your kind acknowledgment.

Regards,

Komal Chhabra
New Products & Complex Team
EMIT | IT OPS | Customer Infrastructure | WDS | SAM

HCL Technologies Ltd.
(CIN: L74140DL1991PLC046369)
10th Floor, ODC-IV, Software Tower 6, Sector 126
Noida SEZ, Uttar Pradesh - 201301, India
Email : komal.chha...@em-msph.com<mailto:komal.chha...@em-msph.com>

for

ExxonMobil Global Services Company
22777 Springwoods Village Parkway
Spring, TX 77389
United States of America


From: Chhabra, Komal /CS
Sent: Friday, February 23, 2018 2:46 PM
To: 'gtk-devel-list@gnome.org' <gtk-devel-list@gnome.org>
Subject: RE: gobject-introspection Version 1 || GNOME
Importance: High

Hi Team,

This is Komal Chhabra, a Team Lead from centralized license management team of 
ExxonMobil known as Software Asset Management[previously known as ITAM. The 
Software Asset Management group at ExxonMobil exists in large part to steward 
software license compliance

We are contacting you to get few details for product gobject-introspection 
Version 1 :


1.   Under which agreement it falls under: MIT , GPL or LPGL ?

2.   Could you please provide us the ECCN number for this software

  If you do not have your software classified with an ECCN, please 
kindly answer the following questions so that we may self-assess if there may 
be any prohibition or restriction for export or re-export of this product.

 1, Does the Software perform any encryption or utilize any 
encryption processes?  Y/N
 2. If the answer is YES to question 1, please indicate if the 
encryption is coded into the application or separately called (such as using 
SSL)
 3. If the answer is YES to question 1, please indicate what 
function(s) the cryptography/encryption serves

A, Copyright protection purposes (Includes using a license key/code)
B, User authentication purposes
   C, A core part of the functionality such as to encrypt databases
   D, To encrypt communications between the software and a host system.

 Background information:
 An Export Control Classification Number (ECCN) is a specific 
alpha-numeric code that identifies the level of export control for items e.g. 
software that are exported from member states of the Wassenaar Arrangement, 
including the United States. After obtaining the ECCN, the exporter must 
determine  whether an export license is required

Waiting for your kind acknowledgment.

Regards,

Komal Chhabra
New Products & Complex Team
EMIT | IT OPS | Customer Infrastructure | WDS | SAM

HCL Technologies Ltd.
(CIN: L74140DL1991PLC046369)
10th Floor, ODC-IV, Software Tower 6, Sector 126
Noida SEZ, Uttar Pradesh - 201301, India
Email : komal.chha...@em-msph.com<mailto:komal.chha...@em-msph.com>

for

ExxonMobil Global Services Company
22777 Springwoods Village Parkway
Spring, TX 77389
United States of America


From: Chhabra, Komal /CS
Sent: Wednesday, February 21, 2018 4:44 PM
To: 'gtk-devel-list@gnome.org' 
<gtk-devel-list@gnome.org<mailto:gtk-devel-list@gnome.org>>
Subject: gobject-introspection Version 1 || GNOME

Hi Team,

This is Komal Chhabra, a Team Lead from centralized license management team of 
ExxonMobil known a

RE: gobject-introspection Version 1 || GNOME

[Chhabra, Komal /CS]

Hi Team,

This is Komal Chhabra, a Team Lead from centralized license management team of 
ExxonMobil known as Software Asset Management[previously known as ITAM. The 
Software Asset Management group at ExxonMobil exists in large part to steward 
software license compliance

We are contacting you to get few details for product gobject-introspection 
Version 1 :


1.   Under which agreement it falls under: MIT , GPL or LPGL ?

2.   Could you please provide us the ECCN number for this software

  If you do not have your software classified with an ECCN, please 
kindly answer the following questions so that we may self-assess if there may 
be any prohibition or restriction for export or re-export of this product.

 1, Does the Software perform any encryption or utilize any 
encryption processes?  Y/N
 2. If the answer is YES to question 1, please indicate if the 
encryption is coded into the application or separately called (such as using 
SSL)
 3. If the answer is YES to question 1, please indicate what 
function(s) the cryptography/encryption serves

A, Copyright protection purposes (Includes using a license key/code)
B, User authentication purposes
   C, A core part of the functionality such as to encrypt databases
   D, To encrypt communications between the software and a host system.

 Background information:
 An Export Control Classification Number (ECCN) is a specific 
alpha-numeric code that identifies the level of export control for items e.g. 
software that are exported from member states of the Wassenaar Arrangement, 
including the United States. After obtaining the ECCN, the exporter must 
determine  whether an export license is required

Waiting for your kind acknowledgment.

Regards,

Komal Chhabra
New Products & Complex Team
EMIT | IT OPS | Customer Infrastructure | WDS | SAM

HCL Technologies Ltd.
(CIN: L74140DL1991PLC046369)
10th Floor, ODC-IV, Software Tower 6, Sector 126
Noida SEZ, Uttar Pradesh - 201301, India
Email : komal.chha...@em-msph.com

for

ExxonMobil Global Services Company
22777 Springwoods Village Parkway
Spring, TX 77389
United States of America


From: Chhabra, Komal /CS
Sent: Wednesday, February 21, 2018 4:44 PM
To: 'gtk-devel-list@gnome.org' 
Subject: gobject-introspection Version 1 || GNOME

Hi Team,

This is Komal Chhabra, a Team Lead from centralized license management team of 
ExxonMobil known as Software Asset Management[previously known as ITAM. The 
Software Asset Management group at ExxonMobil exists in large part to steward 
software license compliance

We are contacting you to get few details for product gobject-introspection 
Version 1 :


1.   Under which agreement it falls under: MIT , GPL or LPGL ?

2.   Could you please provide us the ECCN number for this software

  If you do not have your software classified with an ECCN, please 
kindly answer the following questions so that we may self-assess if there may 
be any prohibition or restriction for export or re-export of this product.

 1, Does the Software perform any encryption or utilize any 
encryption processes?  Y/N
 2. If the answer is YES to question 1, please indicate if the 
encryption is coded into the application or separately called (such as using 
SSL)
 3. If the answer is YES to question 1, please indicate what 
function(s) the cryptography/encryption serves

A, Copyright protection purposes (Includes using a license key/code)
B, User authentication purposes
   C, A core part of the functionality such as to encrypt databases
   D, To encrypt communications between the software and a host system.

 Background information:
 An Export Control Classification Number (ECCN) is a specific 
alpha-numeric code that identifies the level of export control for items e.g. 
software that are exported from member states of the Wassenaar Arrangement, 
including the United States. After obtaining the ECCN, the exporter must 
determine  whether an export license is required

Waiting for your kind acknowledgment.

Regards,

Komal Chhabra
New Products & Complex Team
EMIT | IT OPS | Customer Infrastructure | WDS | SAM

HCL Technologies Ltd.
(CIN: L74140DL1991PLC046369)
10th Floor, ODC-IV, Software Tower 6, Sector 126
Noida SEZ, Uttar Pradesh - 201301, India
Email : komal.chha...@em-msph.com

for

ExxonMobil Global Services Company
22777 Springwoods Village Parkway
Spring, TX 77389
United States of America

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

Re: GObject introspection for cairo

[Nicola Fontana]

Il Thu, 22 Jan 2015 09:50:00 -0800 Jasper St. Pierre jstpie...@mecheye.net 
scrisse:

 Cairo-GObject provides access to enums, but it won't automatically get you
 great cairo bindings. It might actually get you 90% of the way there,
 though, and I'd be interested seeing how far you can run with just that,
 and be happy to merge patches that make it easier.

Hi Jasper,

I'm not arguing against developing glue code for cairo. In fact my
specific problem is exactly a missing access to an enum type.

My knowledge on bindings internals is limited, but I think exposing
the GBoxed wrappers can also help the lifetime management of the
underlying types, and I bet memory leaks are the n.1 problems in
language bindings.

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

Re: GObject introspection for cairo

[Emmanuele Bassi]

hi;

On 22 January 2015 at 16:13, Nicola Fontana n...@entidi.it wrote:

 I need introspection access to a type actually not exported in
 cairo-1.0.gir, and in fact that gir file exports only a fraction of the
 types available.

Cairo is not a GObject library, so introspection is fairly useless.
the only reason why Cairo has introspection data is for GObject
properties and signal marshallers, as well as Cairo types in exposed
in public API in other libraries; the Cairo type system is not mapped
to the GObject type system, so introspection cannot do much to
differentiate calls on, say, an image surface and an xlib surface.

for Cairo, you should always prefer native bindings — like pycairo, or
the cairo GJS module.

 The patches [1] and [2] addresses this issue: any chance to get them
 merged before the next release?

 [1] https://bugzilla.gnome.org/show_bug.cgi?id=686107
 [2] https://github.com/GNOME/gobject-introspection/pull/1

please, do not use pull requests on the Github mirror: nobody looks at
them, and cannot be merged from there anyway (it's a read-only
mirror).

if you have patches, please attach them on Bugzilla.

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: GObject introspection for cairo

[Nicola Fontana]

Il Thu, 22 Jan 2015 16:28:19 + Emmanuele Bassi eba...@gmail.com scrisse:

 if you have patches, please attach them on Bugzilla.

Patches attached to bug #743364:
https://bugzilla.gnome.org/show_bug.cgi?id=743364

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

Re: GObject introspection for cairo

[Nicola Fontana]

Il Thu, 22 Jan 2015 16:28:19 + Emmanuele Bassi eba...@gmail.com scrisse:

 Cairo is not a GObject library, so introspection is fairly useless.

Hi Emmanuele,

the cairo source tree includes cairo-gobject [1] that already wraps
enums and structs in GObject style. I just browsed the code and added
the missing types to the gir file.

 for Cairo, you should always prefer native bindings — like pycairo, or
 the cairo GJS module.

I'm using LGI [2] which provides automatic bindings based on GObject
introspection. This gives me the ability to access all the libraries I
need (cairo is only one of them) through the same interface.

One of my API needs the cairo_surface_type_t enum, so adding a new
dependency only for that is not an option. If the patches are rejected
I'll wrap the enum on my side instead (or drop that particular feature).

 if you have patches, please attach them on Bugzilla.

Sorry, my bad. I had really hard time trying to figure out how to submit
bugs to gobject-introspection. I just discovered (10 mins ago) I need to
select GLib as product first.

Ciao.
-- 
Nicola

[1] http://cgit.freedesktop.org/cairo/tree/util/cairo-gobject
[2] https://github.com/pavouk/lgi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject introspection for cairo

[Jasper St. Pierre]

Cairo-GObject provides access to enums, but it won't automatically get you
great cairo bindings. It might actually get you 90% of the way there,
though, and I'd be interested seeing how far you can run with just that,
and be happy to merge patches that make it easier.

Why? cairo has a subtype system where you have subtypes of cairo_surface_t
(e.g. cairo_image_surface_t) or cairo_pattern_t (e.g.
cairo_gradient_pattern_t) where some objects have special methods. You
determine which type this is by calling cairo_surface_get_type(); and
matching it against a closed enum (cairo_surface_type_t).

It might be enough to do 90% of the work with GObject-Introspection and
write some small by-hand functions when you need to cast to a specific
type in your binding, but you do always need some small native glue code
that calls cairo_surface_get_type();

On Thu, Jan 22, 2015 at 9:39 AM, Nicola Fontana n...@entidi.it wrote:

 Il Thu, 22 Jan 2015 16:28:19 + Emmanuele Bassi eba...@gmail.com
 scrisse:

  Cairo is not a GObject library, so introspection is fairly useless.

 Hi Emmanuele,

 the cairo source tree includes cairo-gobject [1] that already wraps
 enums and structs in GObject style. I just browsed the code and added
 the missing types to the gir file.

  for Cairo, you should always prefer native bindings — like pycairo, or
  the cairo GJS module.

 I'm using LGI [2] which provides automatic bindings based on GObject
 introspection. This gives me the ability to access all the libraries I
 need (cairo is only one of them) through the same interface.

 One of my API needs the cairo_surface_type_t enum, so adding a new
 dependency only for that is not an option. If the patches are rejected
 I'll wrap the enum on my side instead (or drop that particular feature).

  if you have patches, please attach them on Bugzilla.

 Sorry, my bad. I had really hard time trying to figure out how to submit
 bugs to gobject-introspection. I just discovered (10 mins ago) I need to
 select GLib as product first.

 Ciao.
 --
 Nicola

 [1] http://cgit.freedesktop.org/cairo/tree/util/cairo-gobject
 [2] https://github.com/pavouk/lgi
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list




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

Re: gobject-introspection: Cryptic error in g-ir-scanner

[Martin Schlemmer]

 On 2014/02/04 at 12:04 PM, Ankit Vani a...@nevitus.org wrote:
 On Tue, Feb 4, 2014 at 3:27 PM, Bastien Nocera had...@hadess.net wrote:
 Try getting a backtrace of the crash. It's likely a bug in the library
 itself.
 
 Can you tell me how exactly to go about getting a backtrace?
 
 I've tried using gdb on python (to run g-ir-scanner) without any special
 setting, but I'm unable to break on g_log.

Setup PATH, LD_LIBRARY_PATH, etc. needed as per you environment.

Do the following:

# cd /home/ankit/devel/pidgin-dev/finch/libgnt/
# export GI_SCANNER_DEBUG=save-temps
# make

Note the lines (will have different temporary directory prefix) like:
-
(process:13172): GLib-CRITICAL **: g_key_file_has_group: assertion 'key_file != 
NULL' failed
Command 
'['/home/ankit/devel/pidgin-dev/finch/libgnt/tmp-introspectZP9FjN/Gnt-2.8', 
'--introspect-dump=/home/ankit/devel/pidgin-dev/finch/libgnt/tmp-introspectZP9FjN/functions.txt,/home/ankit/devel/pidgin-dev/finch/libgnt/tmp-introspectZP9FjN/dump.xml']'
 returned non-zero exit status -11
-

then run (as mentioned, ZP9FjN will differ):

# gdb tmp-introspectZP9FjN/Gnt-2.8
(gdb) r 
--introspect-dump=tmp-introspectZP9FjN/functions.txt,tmp-introspectZP9FjN/dump.xml

You might have to use: 

# gdb tmp-introspectZP9FjN/.libs/Gnt-2.8

if libtool's wrappers are enabled.

Set breakpoints and debug as needed.

Hope this helps.


Regards,
Martin



Vrywaringsklousule / Disclaimer:  
http://www.nwu.ac.za/it/gov-man/disclaimer.html 

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

Re: gobject-introspection: Cryptic error in g-ir-scanner

[Bastien Nocera]

On Tue, 2014-02-04 at 15:20 +0530, Ankit Vani wrote:
 Hi
 
 I have set up gobject-introspection in Pidgin -- and it works well for
 libpurple, pidgin and finch. However, g-ir-scanner dies with a very
 cryptic error when g-ir-scanner scans libgnt.
 
 
 The error looks like:
   GISCAN   Gnt-2.8.gir
 
 (process:13172): GLib-CRITICAL **: g_key_file_has_group: assertion
 'key_file != NULL' failed

Try getting a backtrace of the crash. It's likely a bug in the library
itself.


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

Re: gobject-introspection: Cryptic error in g-ir-scanner

[Ankit Vani]

On Tue, Feb 4, 2014 at 3:27 PM, Bastien Nocera had...@hadess.net wrote:
 Try getting a backtrace of the crash. It's likely a bug in the library
 itself.

Can you tell me how exactly to go about getting a backtrace?

I've tried using gdb on python (to run g-ir-scanner) without any special
setting, but I'm unable to break on g_log.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection: Cryptic error in g-ir-scanner

[Bastien Nocera]

On Tue, 2014-02-04 at 15:34 +0530, Ankit Vani wrote:
 On Tue, Feb 4, 2014 at 3:27 PM, Bastien Nocera had...@hadess.net wrote:
  Try getting a backtrace of the crash. It's likely a bug in the library
  itself.
 
 Can you tell me how exactly to go about getting a backtrace?
 
 I've tried using gdb on python (to run g-ir-scanner) without any special
 setting, but I'm unable to break on g_log.

ulimit -c unlimited
G_DEBUG=fatal_criticals make

And examine the coredump with gdb.

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

Re: GObject Introspection Enum details

[Jasper St. Pierre]

You can try g_registered_type_info_get_type_name(), but mind asking why you
want to know?


On Sun, Nov 17, 2013 at 11:33 AM, Aleksey prolog.her...@gmail.com wrote:

  Hi guys



 I am trying to use GIRepository (version 1.38) to retrieve Enumeration
 details and I'm wondering how to retrieve C-name of Enum. For example, I
 have GIEnumInfo instance for GBookmarkFileError (
 https://developer.gnome.org/glib/2.38/glib-Bookmark-file-parser.html#GBookmarkFileError
 ).

 Calling g_base_info_get_name gives me BookmarkFileError, not
 GBookmarkFileError.

 After looking at *.gir file contents for GLib, I've found that required
 value is stored in c:type attribute:



 enumeration name=BookmarkFileError

 c:type=GBookmarkFileError

 glib:error-quark=g_bookmark_file_error_quark

 ...

 /enumeration



 so I expected to be able to get the name using g_base_info_get_attribute,
 however, checking available attributes with 
 g_base_info_iterate_attributesproduced no results. Code used to check 
 attributes (no attribute
 names/values are printed):



 // print available attributes, taken from GIRepository manual page

 void print_attributes(GIBaseInfo *info)

 {

 GIAttributeIter iter = { 0, };

 char * name;

 char * value;

 while (g_base_info_iterate_attributes (info, iter, name, value)) {

 g_print (attribute name: %s value: %s, name, value);

 }

 }



 int main(int argc, char ** argv)

 {

 GIRepository *repo = g_irepository_get_default();

 g_irepository_require(repo, GLib, NULL, 0, NULL);

  gint count = g_irepository_get_n_infos(repo, GLib);

  // find first enum

 int i;

 GIBaseInfo * info = NULL;

 for (i = 0; i  count; i++) {

 info = g_irepository_get_info(repo, GLib, i);

 GIInfoType type = g_base_info_get_type(info);

 if (type == GI_INFO_TYPE_ENUM) break;

 }



 const gchar * name = g_base_info_get_name(info);

  printf(Enum: %s\n, name);

 print_attributes(info);



 return 0;

 }

 Could you please advise on how is it possible to get C-type name for enum
 (e.g. GBookmarkFileError).

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




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

Re: GObject Introspection Enum details

[Aleksey]

Thanks Jasper

I've somehow overlooked that GIEnumInfo is inherited GIRegisteredTypeInfo, not 
directly from GIBaseInfo.
Unfortunately, g_registered_type_info_get_type_name() returns NULL. I've also 
tried g_registered_type_info_get_g_type  g_type_name:

GType type = g_registered_type_info_get_g_type(info);
const gchar * name = g_type_name(type);

but it returns void.

  mind asking why you want to know?

I am trying to automate binding generation for Swi-Prolog 
(http://www.swi-prolog.org/). Currently I am working on datatype conversion, 
for example, following (generated) function takes Prolog data structure (term) 
and converts it to C enum-integer:

BookmarkFileError convert_term_to_BookmarkFileError(term_t var)
{
const char * value = convert_term_to_cstring(var);

if (strcmp(value, invalid_uri) == 0) {
return invalid_uri;
} else if (strcmp(value, invalid_value) == 0) {
return invalid_value;
} else if (strcmp(value, app_not_registered) == 0) {
return app_not_registered;
} else if (strcmp(value, uri_not_found) == 0) {
return uri_not_found;
} else if (strcmp(value, read) == 0) {
return read;
} else if (strcmp(value, unknown_encoding) == 0) {
return unknown_encoding;
} else if (strcmp(value, write) == 0) {
return write;
} else if (strcmp(value, file_not_found) == 0) {
return file_not_found;
}

printf(Error in convert_term_to_BookmarkFileError while converting 
value\n);
return (BookmarkFileError)0;
}

But I need to get exact names for enum (and enum values, but this is another 
problem I hadn't investigated yet).

On Sunday 17 November 2013 11:51:24 Jasper St. Pierre wrote:
 You can try g_registered_type_info_get_type_name(), but mind asking why you
 want to know?
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection bindings: how to get gtype for enum type?

[Thibaut Paumard]

Hi again,

Answering to self:

Le 13/05/2013 18:08, Thibaut Paumard a écrit :
 I want to implement setting GObject properties during initialization
 with g_object_newv().

 When the property is of an Enum type, I need to find the gtype
 corresponding to the exact Enum type. What I have in my hands is the
 GIPropertyInfo for the property, which yields the GITypeInfo for the
 Enum type. How do I get from here to there?

g_registered_type_info_get_g_type()

Regards, Thibaut.




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

Re: [GObject-Introspection] Doubt about GIR files generation

[Alejandro T. Colombini]

Thanks for your answer. Unfortunately, I already do that and it still fails.

Doing tests looking for a solution I've omitted the GIR files
generation and it fails while linking the library to the main program,
so I'm doing something wrong with the Autotools (although everything
works if the library is not installed) and therefore I think this
question doesn't belong here.

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

Re: [GObject-Introspection] Doubt about GIR files generation

[Simon McVittie]

On 07/03/13 13:04, Alejandro T. Colombini wrote:
 if any symbol name has been added or modified in the version
 being build, libtool complains about undefined references to these
 symbols while linking. It happens only during the g-ir-scanner
 execution and doesn't in the regular linking of the library. May it be
 something about g-ir-scanner looking for the libraries in the system
 first and then in the build tree?

Sounds as though the program compiled by the scanner is being linked
against the system copy rather than the just-installed copy. Have you
set YourLibrary_1_0_gir_LIBS = libyour-library.la in the Makefile.am
that controls scanning? That's what telepathy-glib does, and it seems to
result in picking up the local library correctly.

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

Re: [gobject-introspection] How to use caller-allocates and allow-none annotations in Clutter

[Kouhei Sutou]

Hi,

In 50ead835.5070...@collabora.co.uk
  Re: [gobject-introspection] How to use caller-allocates and allow-none 
annotations in Clutter on Mon, 07 Jan 2013 14:14:13 +,
  Simon McVittie simon.mcvit...@collabora.co.uk wrote:

 [I am not a g-i developer, please do not take this as authoritative.]

Thanks for your reply.
I am still waiting for a g-i developer but your reply is
very helpful for me.

I may misunderstand (out caller-allocates).
My understanding about (out) (allow-none) will be right.

Thanks!
--
kou

 On 07/01/13 13:22, Kouhei Sutou wrote:
   ClutterActorIter iter;
   ClutterActor *child;
 
   clutter_actor_iter_init (iter, container);
   while (clutter_actor_iter_next (iter, child))
 {
   /* do something with child */
 }
 [...]

 The child parameter is a return location and the return
 location is allocated by caller. (The returned object isn't
 allocated by caller.)
 
 What annotation should be used for the case?  I thought
 out caller-allocates. Is it right usage for the
 annotation? Or out is the right annotation?
 
 To me this looks like an ordinary (out), the same case as each of the
 two outputs of g_hash_table_iter_next(). (out caller-allocates) is
 rare: as I understand it, you'd use it in this situation:
 
 GValue value = { 0 };
 
 this_value_argument_is_out_caller_allocates (value);
 ...
 g_value_unset (value);
 
 and not many others.
 
 The child parameter can be NULL. What annotation should be
 used for the case? I thought allow-none. Is it right usage
 for the annotation? Can I use allow-none for an out
 parameter?
 
 I believe (out) (allow-none) means it is safe to pass NULL instead of
 child, if you just want to look at the boolean return, rather than if
 you pass child, that might result in child == NULL afterwards.
 
   match_start:
 return location for start of match, or
 NULL. [out caller-allocates][allow-none]
 
 I believe this means you call it like this:
 
 GtkTextIter start;
 
 if (gtk_text_iter_forward_search (..., start, ...))
   {
 printf (match starts at %d\n,
 gtk_text_iter_get_offset (start));
   }
 
 or perhaps like this if you need to use the heap for start for whatever
 reason (I'm not sure about this usage, some details might be wrong):
 
 GtkTextIter *start = g_new0 (GtkTextIter);
 
 if (gtk_text_iter_forward_search (..., start, ...))
   {
 printf (match starts at %d\n,
 gtk_text_iter_get_offset (start));
   }
 
 g_free (start);
 
 Is clutter_actor_iter_next() case the same case as
 gtk_text_iter_forward_search()?
 
 No, I think it's the same case as g_hash_table_iter_next().
 
 S
 ___
 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: [gobject-introspection] How to use caller-allocates and allow-none annotations in Clutter

[Simon McVittie]

[I am not a g-i developer, please do not take this as authoritative.]

On 07/01/13 13:22, Kouhei Sutou wrote:
   ClutterActorIter iter;
   ClutterActor *child;
 
   clutter_actor_iter_init (iter, container);
   while (clutter_actor_iter_next (iter, child))
 {
   /* do something with child */
 }
[...]

 The child parameter is a return location and the return
 location is allocated by caller. (The returned object isn't
 allocated by caller.)
 
 What annotation should be used for the case?  I thought
 out caller-allocates. Is it right usage for the
 annotation? Or out is the right annotation?

To me this looks like an ordinary (out), the same case as each of the
two outputs of g_hash_table_iter_next(). (out caller-allocates) is
rare: as I understand it, you'd use it in this situation:

GValue value = { 0 };

this_value_argument_is_out_caller_allocates (value);
...
g_value_unset (value);

and not many others.

 The child parameter can be NULL. What annotation should be
 used for the case? I thought allow-none. Is it right usage
 for the annotation? Can I use allow-none for an out
 parameter?

I believe (out) (allow-none) means it is safe to pass NULL instead of
child, if you just want to look at the boolean return, rather than if
you pass child, that might result in child == NULL afterwards.

   match_start:
 return location for start of match, or
 NULL. [out caller-allocates][allow-none]

I believe this means you call it like this:

GtkTextIter start;

if (gtk_text_iter_forward_search (..., start, ...))
  {
printf (match starts at %d\n,
gtk_text_iter_get_offset (start));
  }

or perhaps like this if you need to use the heap for start for whatever
reason (I'm not sure about this usage, some details might be wrong):

GtkTextIter *start = g_new0 (GtkTextIter);

if (gtk_text_iter_forward_search (..., start, ...))
  {
printf (match starts at %d\n,
gtk_text_iter_get_offset (start));
  }

g_free (start);

 Is clutter_actor_iter_next() case the same case as
 gtk_text_iter_forward_search()?

No, I think it's the same case as g_hash_table_iter_next().

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

Re: [Solved] Re: [gobject-introspection] callback without GDestroyNotify

[Mohan R]

On Tue, 2012-10-23 at 19:43 +0100, Emmanuele Bassi wrote:
 hi;
 
 don't use the G namespace for you code unless you plan on submitting
 it for inclusion in GLib. 
 
 If you're writing a gtweet library, then the namespace ought to be
 Gtweet. 
 
 ciao, 
 Emmanuele. 

Of course I'm going to submit to gnome. But I'm trying to get it
introspection ready and create a small application before submitting.
Without introspection writing a webapi library is useless.

Introspection solves one of the biggest pain which is converting json to
a c struct. Now I can directly export json responses from twitter to
gjs/seed.

Reason for another twitter library? (1) for my learning purpose (2)
twitter-glib is not compatible with current twitter-api, (3) I didn't
dig more about libsocialweb, but in my point of view, one-thing-fit-all
is not the right way for twitter because twitter-api is not stable, they
change things whenever they like.

Code is in github (https://github.com/mohan43u/tweetpts/tree/gtweet) but
its not ready. I don't know gnome will accept this one when I submit.
But, I'm doing this for my personal learning. Introspection is very
exciting.

Thanks,
Mohan R

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

Re: [Solved] Re: [gobject-introspection] callback without GDestroyNotify

[Alexander Larsson]

On ons, 2012-10-24 at 11:34 +0530, Mohan R wrote:
 On Tue, 2012-10-23 at 19:43 +0100, Emmanuele Bassi wrote:
  hi;
  
  don't use the G namespace for you code unless you plan on submitting
  it for inclusion in GLib. 
  
  If you're writing a gtweet library, then the namespace ought to be
  Gtweet. 
  
  ciao, 
  Emmanuele. 
 
 Of course I'm going to submit to gnome. But I'm trying to get it
 introspection ready and create a small application before submitting.
 Without introspection writing a webapi library is useless.

Writing a library is one thing, but using a prefix like g_ in
g_tweet_object_samplestream implies that this is part of glib. You need
to use a different prefix, like gtweet_ or you risk conflicts with
later symbols added to glib.



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

Re: [Solved] Re: [gobject-introspection] callback without GDestroyNotify

[Emmanuele Bassi]

hi;

On 24 October 2012 07:04, Mohan R mohan...@gmail.com wrote:
 On Tue, 2012-10-23 at 19:43 +0100, Emmanuele Bassi wrote:
 hi;

 don't use the G namespace for you code unless you plan on submitting
 it for inclusion in GLib.

 If you're writing a gtweet library, then the namespace ought to be
 Gtweet.

 ciao,
 Emmanuele.

 Of course I'm going to submit to gnome.

that's not what I wrote, but I apologize if I came across as a bit too terse.

you should not be using the g_*/G* namespace unless you're
contributing code to GLib (glib, gobject, gio) — not GNOME.

using the g_* namespace from other components may very well lead to
symbol collision.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Solved] Re: [gobject-introspection] callback without GDestroyNotify

[Mohan R]

On Wed, 2012-10-24 at 10:42 +0100, Emmanuele Bassi wrote:

 you should not be using the g_*/G* namespace unless you're
 contributing code to GLib (glib, gobject, gio) — not GNOME.
 
 using the g_* namespace from other components may very well lead to
 symbol collision.

Sorry, I was confused. So, I have to change g_tweet_ to gtweet_ and use
'gtweet' as my namespace instead of 'g'.

Actually, while creating GTweetObject class, I did just what you said
(using gtweet_object_get_type() instead of g_tweet_object_get_type()).
but somehow ended-up doing g_tweet while fixing issues thrown by
g-ir-scanner. It started working after I changed by namespace to 'g'
instead of 'gtweet'. May be because I was wrong in annotations and
unfamiliarity with g-ir-scanner. I'll fix it.

Thanks you for pointing out.

Thanks,
Mohan R

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

[Solved] Re: [gobject-introspection] callback without GDestroyNotify

[Mohan R]

Fixed it,

My mistake, annotations are wrong, because the name of the function is
'g_tweet_object_samplestream', but the anotation says
'tweet_object_samplestream'. Sorry to distrub you all.

On Tue, 2012-10-23 at 21:11 +0530, Mohan R wrote:

 /**
  * tweet_object_samplestream:
  * @tweetObject: a #TweetObject
  * @func: (closure userdata) (scope async): a callback function to
 invoke for every tweet
  * @userdata: (closure) (allow-none): data to be sent to the callback.
  */
 void g_tweet_object_samplestream(GTweetObject *tweetObject,
  GTweetObjectStreamFunc func,
  gpointer userdata);
 

Here is the fixed one,

/**
 * g_tweet_object_samplestream:
 * @tweetObject: a #TweetObject
 * @func: (closure user_data) (scope async): a callback function to
invoke for every tweet
 * @user_data: (closure): data to be sent to the callback.
 */
void g_tweet_object_samplestream(GTweetObject *tweetObject,
 GTweetObjectStreamFunc func,
 gpointer user_data);

g-ir-scanner writes this function like this,

  method name=samplestream
c:identifier=g_tweet_object_samplestream
return-value transfer-ownership=none
  type name=none c:type=void/
/return-value
parameters
  parameter name=func
 transfer-ownership=none
 scope=async
 closure=1
doc xml:whitespace=preservea callback function to invoke
for every tweet/doc
type name=TweetObjectStreamFunc
  c:type=GTweetObjectStreamFunc/
  /parameter
  parameter name=user_data transfer-ownership=none
doc xml:whitespace=preservedata to be sent to the
callback./doc
type name=gpointer c:type=gpointer/
  /parameter
/parameters
  /method

Thanks,
Mohan R

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

Re: [Solved] Re: [gobject-introspection] callback without GDestroyNotify

[Emmanuele Bassi]

hi;

don't use the G namespace for you code unless you plan on submitting it for
inclusion in GLib.

If you're writing a gtweet library, then the namespace ought to be Gtweet.

ciao,
Emmanuele.
On Oct 23, 2012 7:15 PM, Mohan R mohan...@gmail.com wrote:

 Fixed it,

 My mistake, annotations are wrong, because the name of the function is
 'g_tweet_object_samplestream', but the anotation says
 'tweet_object_samplestream'. Sorry to distrub you all.

 On Tue, 2012-10-23 at 21:11 +0530, Mohan R wrote:

  /**
   * tweet_object_samplestream:
   * @tweetObject: a #TweetObject
   * @func: (closure userdata) (scope async): a callback function to
  invoke for every tweet
   * @userdata: (closure) (allow-none): data to be sent to the callback.
   */
  void g_tweet_object_samplestream(GTweetObject *tweetObject,
   GTweetObjectStreamFunc func,
   gpointer userdata);
 

 Here is the fixed one,

 /**
  * g_tweet_object_samplestream:
  * @tweetObject: a #TweetObject
  * @func: (closure user_data) (scope async): a callback function to
 invoke for every tweet
  * @user_data: (closure): data to be sent to the callback.
  */
 void g_tweet_object_samplestream(GTweetObject *tweetObject,
  GTweetObjectStreamFunc func,
  gpointer user_data);

 g-ir-scanner writes this function like this,

   method name=samplestream
 c:identifier=g_tweet_object_samplestream
 return-value transfer-ownership=none
   type name=none c:type=void/
 /return-value
 parameters
   parameter name=func
  transfer-ownership=none
  scope=async
  closure=1
 doc xml:whitespace=preservea callback function to invoke
 for every tweet/doc
 type name=TweetObjectStreamFunc
   c:type=GTweetObjectStreamFunc/
   /parameter
   parameter name=user_data transfer-ownership=none
 doc xml:whitespace=preservedata to be sent to the
 callback./doc
 type name=gpointer c:type=gpointer/
   /parameter
 /parameters
   /method

 Thanks,
 Mohan R

 ___
 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: gobject-introspection and GBoxed

[jcupitt]

Hi Tomeu,

On 12 January 2012 11:02, Tomeu Vizoso to...@sugarlabs.org wrote:
 Looks like a bug in pygobject, could you file a bug with a backtrace?

 It may be worth trying out with the latest release to scope better the 
 problem.

I've tried with git master gobject-introspection and 3.0.3 pygobject
and the crash has gone but it still doesn't work. Should I file a bug
or am I making a stupid error?

I have this in the header:


/* A very simple boxed type for testing. Just holds an int.
 */
typedef struct _VipsThing {
int i;
} VipsThing;

/**
 * VIPS_TYPE_THING:
 *
 * The #GType for a #VipsThing.
 */
#define VIPS_TYPE_THING (vips_thing_get_type())
GType vips_thing_get_type( void );
VipsThing *vips_thing_new( int i );
int vips_thing_get_i( VipsThing *thing );
-

this in the .c file:

---
/* A very simple boxed type for testing. Just an int.
 */

/**
 * vips_thing_new:
 * @n:
 *
 * Returns: (transfer full): a new #VipsThing.
 */
VipsThing *
vips_thing_new( int i )
{
VipsThing *thing;

thing = g_new( VipsThing, 1 );
thing-i = i;

printf( vips_thing_new: %d %p\n, i, thing );

return( thing );
}

static VipsThing *
vips_thing_copy( VipsThing *thing )
{
VipsThing *thing2;

thing2 = vips_thing_new( thing-i );

printf( vips_thing_copy: %d %p = %p\n, thing-i, thing2, thing );

return( thing2 );
}

static void
vips_thing_free( VipsThing *thing )
{
printf( vips_thing_free: %d %p\n, thing-i, thing );

g_free( thing );
}

int
vips_thing_get_i( VipsThing *thing )
{
printf( vips_thing_get_i: %d %p\n, thing-i, thing );

return( thing-i );
}

G_DEFINE_BOXED_TYPE( VipsThing, vips_thing,
(GBoxedCopyFunc) vips_thing_copy,
(GBoxedFreeFunc) vips_thing_free );
---

But this happens in Python:

 from gi.repository import Vips
 dir(Vips)
... long list, all the GObject based types I use are there and work,
so I think the introspection stuff is OK
... Vips.thing* is not there, but Vips.Thing is
 Vips.Thing
Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/john/vips/lib/python2.7/site-packages/gi/module.py,
line 243, in __getattr__
return getattr(self._introspection_module, name)
NotImplementedError: gi.BoxedInfo object (Thing) at 0x0x7f9e7ac674d0
 Vips.Thing(12)
NotImplementedError: gi.BoxedInfo object (Thing) at 0x0x7f9e7ac676c8
 Vips.Thing.new(12)
NotImplementedError: gi.BoxedInfo object (Thing) at 0x0x7f9e7ac675f0
 dir(Vips.Thing)
NotImplementedError: gi.BoxedInfo object (Thing) at 0x0x7f9e7ac67a70
 Vips.thing_new
AttributeError: 'gi.repository.Vips' object has no attribute 'thing_new'


The /home/john/vips/lib/python2.7/site-packages/gi/module.py in the
backtrace proves that I'm using my own build of gi master and not the
host one, I hope.

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

Re: gobject-introspection and GBoxed

[Tomeu Vizoso]

On Wed, Jan 11, 2012 at 14:47,  jcup...@gmail.com wrote:
 Hi all,

 I'm adding gobject-introspection support to my library. It's working
 well for the GObject classes, but I just can't get it to work for
 GBoxed objects. I'm sure I'm missing something obvious. Do I need to
 write an override to make a class for the type myself?

 I've spent some time googling and grepping around and not found a
 simple example. Again, I'm probably being stupid.

 I'm doing something like this in a header:

 /**
  * VIPS_TYPE_BLOB:
  *
  * The %GType for a #VipsBlob.
  */
 #define VIPS_TYPE_BLOB (vips_blob_get_type())
 GType vips_blob_get_type( void );
 typedef ... VipsBlob;
 VipsBlob *vips_blob_new( int n );

 and this in the .c file:

 GType
 vips_blob_get_type( void )
 {
        static GType type = 0;

        if( !type )
                type = g_boxed_type_register_static( VipsBlob,
                        (GBoxedCopyFunc) ...,
                        (GBoxedFreeFunc) ... );

        return( type );
 }

 /**
  * vips_blob_new:
  * @n:
  *
  * Returns: (transfer full): the new #VipsBlob.
  */
 VipsBlob *
 vips_blob_new( int n )
 {
        return (...a new VipsBlob);
 }

 Now when I start up Python I get this:

 from gi.repository import Vips
 Vips.blob_new
 function blob_new at 0x77e31de8
 Vips.blob_new(12)

 Program received signal SIGSEGV, Segmentation fault.
 _args_cache_generate (callable_cache=0x9b04c0, callable_info=0xa6d280)
    at /build/buildd/pygobject-3.0.0/gi/pygi-cache.c:1282

 This is on current Ubuntu, so:

 $ pkg-config gobject-introspection-1.0 --modversion
 1.30.0

Looks like a bug in pygobject, could you file a bug with a backtrace?

It may be worth trying out with the latest release to scope better the problem.

Thanks,

Tomeu

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

Re: gobject-introspection broken (?) on quartz ?

[Kristian Rietveld]

Which machine is this on?  If this is on Tiger, you need to build yourself a 
newer make (3.71, it's in MacPorts) because things break with the (old) make 
3.70 that's shipped with latest XCode for Tiger.

regards,

-kris.

On Nov 18, 2011, at 6:32 AM, Paul Davis wrote:

 make
 Makefile:2712: *** Need to define GLib_2_0_gir_LIBS or
 GLib_2_0_gir_PROGRAM.  Stop.
 *** Error during phase build of gobject-introspection: ##
 Error running make   *** [8/14]
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

Re: gobject-introspection broken (?) on quartz ?

[Paul Davis]

On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org wrote:
 Which machine is this on?  If this is on Tiger, you need to build yourself a 
 newer make (3.71, it's in MacPorts) because things break with the (old) make 
 3.70 that's shipped with latest XCode for Tiger.

yes, this is Tiger. Is there any particular reason why this has not
been added to the bootstrap process? and is there a particular reason
why this breakage has crept in for a particular, less than critical
component of the stack when the old make has worked just fine for
years?

(i'll get on the make front right away, though. thanks for the info).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection broken (?) on quartz ?

[Paul Davis]

On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org wrote:
 Which machine is this on?  If this is on Tiger, you need to build yourself a 
 newer make (3.71, it's in MacPorts) because things break with the (old) make 
 3.70 that's shipped with latest XCode for Tiger.

did you mean GNU Make? which is at version 3.82 now?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection broken (?) on quartz ?

[Paul Davis]

On Fri, Nov 18, 2011 at 8:03 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com 
 wrote:
 On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org wrote:
 Which machine is this on?  If this is on Tiger, you need to build yourself 
 a newer make (3.71, it's in MacPorts) because things break with the (old) 
 make 3.70 that's shipped with latest XCode for Tiger.

 did you mean GNU Make? which is at version 3.82 now?

i ask because on the machine question:


macarena:~ paul$ make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection broken (?) on quartz ?

[Kristian Rietveld]

On Nov 18, 2011, at 2:03 PM, Paul Davis wrote:

 On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com 
 wrote:
 On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org wrote:
 Which machine is this on?  If this is on Tiger, you need to build yourself 
 a newer make (3.71, it's in MacPorts) because things break with the (old) 
 make 3.70 that's shipped with latest XCode for Tiger.
 
 did you mean GNU Make? which is at version 3.82 now?

My apologies (I didn't have my Tiger machine handy), I meant that Tiger ships 
with GNU make 3.80 and you need at least GNU make 3.81.  This is due to usage 
of $(or ...) and/or $(and ...) which are only available in 3.81 onwards.


-kris.

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

Re: gobject-introspection broken (?) on quartz ?

[Kristian Rietveld]

On Nov 18, 2011, at 1:56 PM, Paul Davis wrote:
 
 yes, this is Tiger. Is there any particular reason why this has not
 been added to the bootstrap process?

I think because not that many people are building on Tiger anymore.  I stumbled 
across it this Summer and I just ended up installing GNU make from MacPorts to 
fix the issue.  Snow Leopard ships with 3.81 and thus is not affected.

 and is there a particular reason
 why this breakage has crept in for a particular, less than critical
 component of the stack when the old make has worked just fine for
 years?

The issue is caused by the GObject-introspection makefiles using $(or ...) and 
$(and ...).  These makefiles are included by projects that support 
GObject-introspection and generate GIRs at compile-time.  I would guess relying 
on GNU Make 3.81 is fair since it has been out for a while and obtaining it on 
Tiger is easy ...


regards,

-kris.

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

Re: gobject-introspection broken (?) on quartz ?

[Paul Davis]

On Fri, Nov 18, 2011 at 9:53 AM, Kristian Rietveld k...@loopnest.org wrote:
 My apologies (I didn't have my Tiger machine handy), I meant that Tiger ships 
 with GNU make 3.80 and you need at least GNU make 3.81.  This is due to usage 
 of $(or ...) and/or $(and ...) which are only available in 3.81 onwards.

a feature that was so vital that legends of makefiles for decades
always wondered how to live without it ... sorry, i should not be so
sarcastic, its just been a long morning already :)

thanks very much for the info.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection broken (?) on quartz ?

[John Ralls]

On Nov 18, 2011, at 6:53 AM, Kristian Rietveld wrote:

 
 On Nov 18, 2011, at 2:03 PM, Paul Davis wrote:
 
 On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com 
 wrote:
 On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org 
 wrote:
 Which machine is this on?  If this is on Tiger, you need to build yourself 
 a newer make (3.71, it's in MacPorts) because things break with the (old) 
 make 3.70 that's shipped with latest XCode for Tiger.
 
 did you mean GNU Make? which is at version 3.82 now?
 
 My apologies (I didn't have my Tiger machine handy), I meant that Tiger ships 
 with GNU make 3.80 and you need at least GNU make 3.81.  This is due to usage 
 of $(or ...) and/or $(and ...) which are only available in 3.81 onwards.
 

Interesting. I hadn't encountered that problem before. I'll add a newer make to 
the bootstrap module and skip it for later OSX versions.

For future reference, please use gtk-osx-users-l...@gnome.org for gtk-osx build 
problems.

Regards,
John Ralls

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

Re: gobject-introspection broken (?) on quartz ?

[John Ralls]

On Nov 18, 2011, at 7:02 AM, John Ralls wrote:

 
 On Nov 18, 2011, at 6:53 AM, Kristian Rietveld wrote:
 
 
 On Nov 18, 2011, at 2:03 PM, Paul Davis wrote:
 
 On Fri, Nov 18, 2011 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com 
 wrote:
 On Fri, Nov 18, 2011 at 3:18 AM, Kristian Rietveld k...@loopnest.org 
 wrote:
 Which machine is this on?  If this is on Tiger, you need to build 
 yourself a newer make (3.71, it's in MacPorts) because things break with 
 the (old) make 3.70 that's shipped with latest XCode for Tiger.
 
 did you mean GNU Make? which is at version 3.82 now?
 
 My apologies (I didn't have my Tiger machine handy), I meant that Tiger 
 ships with GNU make 3.80 and you need at least GNU make 3.81.  This is due 
 to usage of $(or ...) and/or $(and ...) which are only available in 3.81 
 onwards.
 
 
 Interesting. I hadn't encountered that problem before. I'll add a newer make 
 to the bootstrap module and skip it for later OSX versions.
 
 For future reference, please use gtk-osx-users-l...@gnome.org for gtk-osx 
 build problems.
 

I should also have mentioned that in general MacPorts isn't compatible with 
gtk-osx. Their set up pollutes the global environment, so the linker will often 
find their libraries instead of the ones built with gtk-osx. I know that you 
two (Kris and Paul) are expert enough to fix that, but there are lots of folks 
out there who aren't -- hence the warning on the Building page Paul referenced.

Regards,
John Ralls


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

Re: gobject-introspection-0.10.8 warnings on AIX

[Simon McVittie]

On Tue, 15 Nov 2011 at 12:48:35 -0600, Albert Chin wrote:
 We've built gobject-introspection-0.10.8 on AIX, HP-UX, Solaris, IRIX, Tru64
 UNIX, and RHEL. We have it compiling everywhere except AIX.
 
 We're seeing the following error. Any ideas?
 
 /opt/build/gobject-introspection-0.10.8/tests/gimarshallingtests.h:41: syntax 
 error, unexpected typedef-name, expecting ')' or ',' in 'void 
 gi_marshalling_tests_int8_out_max (gint8 *int8);' at 'int8'

AIX's system headers probably typedef or #define int8, uint16 etc.
to be the same thing as the standard int8_t, u_int16_t etc. The g-i tests
are using these names as parameters.

g-i could work around this by renaming the argument to i8 or int8_ or
something.

   File ../giscanner/maintransformer.py, line 117, in 
 _pass_fixup_hidden_fields
 if (field.name.startswith('_')
 AttributeError: 'NoneType' object has no attribute 'startswith'

This is probably just fallout from the parse errors above.

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

Re: gobject-introspection-0.10.8 warnings on AIX

[Albert Chin]

On Tue, Nov 15, 2011 at 07:12:06PM +, Simon McVittie wrote:
 On Tue, 15 Nov 2011 at 12:48:35 -0600, Albert Chin wrote:
  We've built gobject-introspection-0.10.8 on AIX, HP-UX, Solaris, IRIX, Tru64
  UNIX, and RHEL. We have it compiling everywhere except AIX.
  
  We're seeing the following error. Any ideas?
  
  /opt/build/gobject-introspection-0.10.8/tests/gimarshallingtests.h:41: 
  syntax error, unexpected typedef-name, expecting ')' or ',' in 'void 
  gi_marshalling_tests_int8_out_max (gint8 *int8);' at 'int8'
 
 AIX's system headers probably typedef or #define int8, uint16 etc.
 to be the same thing as the standard int8_t, u_int16_t etc. The g-i tests
 are using these names as parameters.
 
 g-i could work around this by renaming the argument to i8 or int8_ or
 something.

38: void gi_marshalling_tests_int8_in_max (gint8 int8);
39: void gi_marshalling_tests_int8_in_min (gint8 int8);

41: void gi_marshalling_tests_int8_out_max (gint8 *int8);
42: void gi_marshalling_tests_int8_out_min (gint8 *int8);

44: void gi_marshalling_tests_int8_inout_max_min (gint8 *int8);
45: void gi_marshalling_tests_int8_inout_min_max (gint8 *int8);

If that was the case, why aren't there complaints about lines 38 and
39?

And, how do I find out what command is invoked to generate these
syntax errors?

-- 
albert chin (ch...@thewrittenword.com)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection-0.10.8 warnings on AIX

[Albert Chin]

On Tue, Nov 15, 2011 at 01:46:59PM -0600, Albert Chin wrote:
 On Tue, Nov 15, 2011 at 07:12:06PM +, Simon McVittie wrote:
  On Tue, 15 Nov 2011 at 12:48:35 -0600, Albert Chin wrote:
   We've built gobject-introspection-0.10.8 on AIX, HP-UX, Solaris, IRIX, 
   Tru64
   UNIX, and RHEL. We have it compiling everywhere except AIX.
   
   We're seeing the following error. Any ideas?
   
   /opt/build/gobject-introspection-0.10.8/tests/gimarshallingtests.h:41: 
   syntax error, unexpected typedef-name, expecting ')' or ',' in 'void 
   gi_marshalling_tests_int8_out_max (gint8 *int8);' at 'int8'
  
  AIX's system headers probably typedef or #define int8, uint16 etc.
  to be the same thing as the standard int8_t, u_int16_t etc. The g-i tests
  are using these names as parameters.
  
  g-i could work around this by renaming the argument to i8 or int8_ or
  something.
  
 File ../giscanner/maintransformer.py, line 117, in 
   _pass_fixup_hidden_fields
   if (field.name.startswith('_')
   AttributeError: 'NoneType' object has no attribute 'startswith'
  
  This is probably just fallout from the parse errors above.
 
 I fixed the parse errors but the AttributeError remains.

My patch to fix the parse errors was wrong. Looking into it further.

-- 
albert chin (ch...@thewrittenword.com)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection-0.10.8 warnings on AIX

[Albert Chin]

On Tue, Nov 15, 2011 at 04:28:45PM -0600, Albert Chin wrote:
 On Tue, Nov 15, 2011 at 01:46:59PM -0600, Albert Chin wrote:
  On Tue, Nov 15, 2011 at 07:12:06PM +, Simon McVittie wrote:
   On Tue, 15 Nov 2011 at 12:48:35 -0600, Albert Chin wrote:
We've built gobject-introspection-0.10.8 on AIX, HP-UX, Solaris, IRIX, 
Tru64
UNIX, and RHEL. We have it compiling everywhere except AIX.

We're seeing the following error. Any ideas?

/opt/build/gobject-introspection-0.10.8/tests/gimarshallingtests.h:41: 
syntax error, unexpected typedef-name, expecting ')' or ',' in 'void 
gi_marshalling_tests_int8_out_max (gint8 *int8);' at 'int8'
   
   AIX's system headers probably typedef or #define int8, uint16 etc.
   to be the same thing as the standard int8_t, u_int16_t etc. The g-i tests
   are using these names as parameters.
   
   g-i could work around this by renaming the argument to i8 or int8_ or
   something.
   
  File ../giscanner/maintransformer.py, line 117, in 
_pass_fixup_hidden_fields
if (field.name.startswith('_')
AttributeError: 'NoneType' object has no attribute 'startswith'
   
   This is probably just fallout from the parse errors above.
  
  I fixed the parse errors but the AttributeError remains.
 
 My patch to fix the parse errors was wrong. Looking into it further.

I think the code in question is:
#ifndef __GI_SCANNER__
# define __GI_SCANNER__
#endif
#include /opt/build/gobject-introspection-0.10.8/tests/gimarshallingtests.h

But, gcc-4.4.6 accepts this on AIX:
  /opt/TWWfsw/gcc44/bin/gcc -E -C -I. - -I.. 
-I/opt/TWWfsw/libglib226/include/gcc44/gio-unix 
-I/opt/TWWfsw/libglib226/include/gcc44 
-I/opt/TWWfsw/libglib226/lib/gcc44/include -I/opt/TWWfsw/gettext018/include

Is g-ir-scanner doing some parsing on the result of the above on the
input above? Still looking at the code.

-- 
albert chin (ch...@thewrittenword.com)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection-0.10.8 warnings on AIX

[Albert Chin]

On Tue, Nov 15, 2011 at 07:12:06PM +, Simon McVittie wrote:
 On Tue, 15 Nov 2011 at 12:48:35 -0600, Albert Chin wrote:
  We've built gobject-introspection-0.10.8 on AIX, HP-UX, Solaris, IRIX, Tru64
  UNIX, and RHEL. We have it compiling everywhere except AIX.
  
  We're seeing the following error. Any ideas?
  
  /opt/build/gobject-introspection-0.10.8/tests/gimarshallingtests.h:41: 
  syntax error, unexpected typedef-name, expecting ')' or ',' in 'void 
  gi_marshalling_tests_int8_out_max (gint8 *int8);' at 'int8'
 
 AIX's system headers probably typedef or #define int8, uint16 etc.
 to be the same thing as the standard int8_t, u_int16_t etc. The g-i tests
 are using these names as parameters.

Ok, this turned out to be the problem. In inttypes.h, AIX has:
  /*
   * BSD fixed-size integer type additions to the above ISO-C types.
   *
   */
  typedef signed char int8;
  typedef signed shortint16;
  typedef signed int  int32;
  #ifdef  __64BIT__
  typedef longint64;
  #else   /* _ILP32 */
  #if defined(_LONG_LONG)
  typedef signed long longint64;
  #endif
  #endif

 g-i could work around this by renaming the argument to i8 or int8_ or
 something.

Will work up a patch with this in mind.

File ../giscanner/maintransformer.py, line 117, in 
  _pass_fixup_hidden_fields
  if (field.name.startswith('_')
  AttributeError: 'NoneType' object has no attribute 'startswith'
 
 This is probably just fallout from the parse errors above.

Yep.

-- 
albert chin (ch...@thewrittenword.com)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject Introspection: array type too unspecific?

[Michael Kappert]

On 07/07/2011 01:07 AM, Florian Müllner wrote:

2011/7/6 Michael Kappert

g_type_info_get_array_type returns a GIArrayType which only
distinguishes C, ptr, byte and nested arrays. This does not seem
to be enough to generate wrappers automatically. The exact array
element type needs to be known.  (Or doesn't it? I'm using CLISP's
FFI that does the wrapping for me, I'm not too familiar with C.)



I think you are misunderstanding GIArrayType.
To determine the actual element type, you can use something along the
lines of



GITypeInfo *element_info = g_type_info_get_param_type (type_info, 0);
GITypeTag element_type = g_type_info_get_tag (element_info);


Thanks!
I didn't think of parameterized types and so I couldn't make any sense 
of g_info_type_get_param_type(info, n) ...


But now I wonder, how do you determine the number of parameters?


Michael

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

Re: GObject Introspection: array type too unspecific?

[Florian Müllner]

Hey,

2011/7/6 Michael Kappert michael.kapp...@gmx.net

 g_type_info_get_array_type returns a GIArrayType which only distinguishes
 C, ptr, byte and nested arrays. This does not seem to be enough to
 generate wrappers automatically. The exact array element type needs to be
 known.  (Or doesn't it? I'm using CLISP's FFI that does the wrapping for me,
 I'm not too familiar with C.)


 I think you are misunderstanding GIArrayType. It doesn't tell anything
about the content (read: element type) of the array, but describes the
data type itself. As native C arrays often suck, Glib provides higher-level
array types which are more convenient - unfortunately that means that
array is ambiguous, it may be either a native C array (e.g. char[]) or one
of the Glib array types (GArray, GPtrArray, GByteArray).

To determine the actual element type, you can use something along the lines
of

GITypeInfo *element_info = g_type_info_get_param_type (type_info, 0);
GITypeTag element_type = g_type_info_get_tag (element_info);

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

Re: gobject introspection in runtime possible?

[Alexander Larsson]

On Thu, 2011-04-07 at 12:22 +0200, Andrea wrote:
 Hello list,
  Just a flash question about introspection (I'm a newbye).
 
 
 Is it possible to get introspection data from a GObject in runtime?
 I was wondering if it would be convenient to create a special
 introspectable parent object to declare d-bus interfaces of derived,
 simply listing properties and class initialized methods.
 
 
 As I see gobject-introspection do it offline reading .c file

Generation of the introspectiondata is offline during the build, but
accessing the existing introspection data can be done at runtime.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a deeply religious crooked cowboy moving from town to town, helping folk 
in trouble. She's a pregnant gypsy pearl diver from the wrong side of the 
tracks. They fight crime! 

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

Re: gobject introspection in runtime possible?

[Alexandre Mazari]

Le jeudi 07 avril 2011 à 12:22 +0200, Andrea a écrit :
 Hello list,
  Just a flash question about introspection (I'm a newbye).
 
 
 Is it possible to get introspection data from a GObject in runtime?
 I was wondering if it would be convenient to create a special
 introspectable parent object to declare d-bus interfaces of derived,
 simply listing properties and class initialized methods.
 
 
 As I see gobject-introspection do it offline reading .c file

Indeed gobject-introspection generates metadata at build-time. Though
GType/GObject have facilities to do simple introspection at runtime.
Those facilities precluded gir and only provide informations about
signals and properties of a living instance.

Have a look at:
* g_signal_list_ids
http://developer.gnome.org/gobject/unstable/gobject-Signals.html#g-signal-list-ids
lists all signals for a specified GType

* g_signal_query
http://developer.gnome.org/gobject/unstable/gobject-Signals.html#g-signal-query
gives info about a specified signal

* g_object_class_list_properties
http://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-class-list-properties
 returns a list of GParamSpec* describing properties (type, name,
usage...)


Also, you might want to do that introspection for all the type hierachy
for a specific instance. To climb up the tree, use

g_type_class_peek_parent
http://developer.gnome.org/gobject/unstable/gobject-Type-Information.html#g-type-class-peek-parent

and g_type_interface_peek/g_type_interface_peek_parent
http://developer.gnome.org/gobject/unstable/gobject-Type-Information.html#g-type-class-peek-parent

Hope this helps, Happy Coding !


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

Re: [gobject-introspection] How should name collisions be resolved

[Colin Walters]

On Thu, Feb 10, 2011 at 12:14 PM, Alan alan.mcgov...@gmail.com wrote:
 In .NET it is invalid to generate a property or a method which is the
 same name as an event as it is ambiguous as to whether you're invoking
 the event or calling the method.

Yeah, this fits into a general class of corner case restrictions from
a language mapping.  Similar to adding methods to a GObject interface
is OK in C, but an API break in the obvious Java and .NET mapping.

I think it'd be reasonable to add warnings for this to the
introspection scanner, but that doesn't help all the existing code out
there like GTK3 that just got released.

Related to this is the issue of language keywords; for example you
could call a method gtk_widget_switch () or something fine in C, but
then you end up with mywidget.switch() which is a problem since it's a
keyword.

 What are peoples opinions on taking care of this in the gir format and
 using the renameto feature to avoid the collision in all languages?
 Is this feasible? Are there any better ways of handling this kind of
 case?

We can do this for GTK3; but I'm loathe to use Rename-to except as a
binding band aid on top of a library that's already shipped.  It has
the compound problem that all of a sudden the *old* name isn't
accessible, and there was a possibility something was using it.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gobject-introspection] How should name collisions be resolved

[Luca Bruno]

On Thu, Feb 10, 2011 at 05:14:39PM +, Alan wrote:
 In .NET it is invalid to generate a property or a method which is the
 same name as an event as it is ambiguous as to whether you're invoking
 the event or calling the method.

This also affects Vala. Other problems happen wrt properties and
constructors.

-- 
http://www.debian.org - The Universal Operating System


signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[Colin Walters]

On Wed, Dec 15, 2010 at 8:54 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote:

 But since you bring it up, what is the official policy? Is it C89? Is it 
 published somewhere?

 For GTK+, we're generally avoiding C++ comments, since they cause
 problems for the compilers that are used on win32. What other non-C89
 features do you have in mind ?

But they *are* used in gtk3 right now...

 Nested functions are not really worth discussing, thats just a
 historical accident on the part of the gcc team...

I totally agree with this.

But the point is, if something's not tested, it's basically guaranteed
to break (like srcdir != builddir, etc).  gcc defaults to enabling GNU
features, and the buildbots don't specify -std=c89, so there is
absolutely zero testing coverage.

If we want this to work, we need to add stuff to configure.ac in
modules to, if gcc is detected, add -std=c89.  Or we tell people to
use gnu89, and other compilers have to implement the GNU C subset we
make up (which is apparently C++ comments OK, nested functions not OK,
etc).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[Javier Jardón]

On 16 December 2010 17:07, Colin Walters walt...@verbum.org wrote:
 On Wed, Dec 15, 2010 at 8:54 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:
 On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote:

 But since you bring it up, what is the official policy? Is it C89? Is it 
 published somewhere?

 For GTK+, we're generally avoiding C++ comments, since they cause
 problems for the compilers that are used on win32. What other non-C89
 features do you have in mind ?

 But they *are* used in gtk3 right now...


I dont think so. Where are they used?

Regards
-- 
Javier Jardón Cabezas
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[Emmanuele Bassi]

On Thu, 2010-12-16 at 12:07 -0500, Colin Walters wrote:
 On Wed, Dec 15, 2010 at 8:54 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:
  On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote:
 
  But since you bring it up, what is the official policy? Is it C89? Is it 
  published somewhere?
 
  For GTK+, we're generally avoiding C++ comments, since they cause
  problems for the compilers that are used on win32. What other non-C89
  features do you have in mind ?
 
 But they *are* used in gtk3 right now...

then they should be removed. we don't use c99 in glib and gtk -- it's
been pointed out many times in many threads on this very mailing list.

 But the point is, if something's not tested, it's basically guaranteed
 to break (like srcdir != builddir, etc).  gcc defaults to enabling GNU
 features, and the buildbots don't specify -std=c89, so there is
 absolutely zero testing coverage.

it's trivial to add a new compiler flag; in Clutter we even use the
AS_COMPILER_FLAGS m4 macro[1] written by David Schleef to guarantee
portability.

ciao,
 Emmanuele.

[1]
http://git.clutter-project.org/clutter/tree/build/autotools/as-compiler-flag.m4


-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

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

Re: Gobject-Introspection and CMPH

[Colin Walters]

On Thu, Dec 16, 2010 at 12:44 PM, Emmanuele Bassi eba...@gmail.com wrote:

 then they should be removed. we don't use c99 in glib and gtk -- it's
 been pointed out many times in many threads on this very mailing list.

Actually gtk3 currently fails with -std=c99 even due to some anonymous
unions in gtkcssprovider.c.  So we actually *in reality right now*
require gnu89 or gnu99, and we will likely continue to do so unless
configure is patched to force the issue.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[John Ralls]

On Dec 16, 2010, at 9:47 AM, Colin Walters wrote:

 On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote:
 
 Okay well, I *think* you answered my question, which is that you want
 the stack to build with c99.

No, but Emmanuele did: It should be c89. Gobject-introsopection has been 
failing that for some time, but before you added cmph, it built with c99.

Regards,
John Ralls
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[Colin Walters]

On Thu, Dec 16, 2010 at 2:30 PM, John Ralls jra...@ceridwen.us wrote:

 On Dec 16, 2010, at 9:47 AM, Colin Walters wrote:

 On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote:

 Okay well, I *think* you answered my question, which is that you want
 the stack to build with c99.

 No, but Emmanuele did: It should be c89. Gobject-introsopection has been 
 failing that for some time, but before you added cmph, it built with c99.

Okay, someone tell me how exactly you're building glib with c89, on
what operating system.  It fails for me here on RHEL6 (gcc (GCC) 4.4.4
20100726 (Red Hat 4.4.4-13)), if I specify -std=c89 in CFLAGS:

http://people.gnome.org/~walters/build-glib-c89.log

It looks to me like we also need to specify at least _POSIX_SOURCE
defined, but even that's not good enough because we need va_copy,
which requires -D_GNU_SOURCE.   Hmm, actually doing this breaks half
the configure checks if we just specify it on make invocation,
because we find va_copy during detection since we're using the
default gnu89.

If I manually run configure like:
./configure --prefix=/src/build/jhbuild
--libdir=/src/build/jhbuild/lib64 CFLAGS='-Wall -std=c89'

then it errors out later trying to find arpa/nameser_compat.h.

So...if people are claiming this really works, let me know how you're
doing it...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[Colin Walters]

On Mon, Dec 13, 2010 at 1:35 PM, John Ralls jra...@ceridwen.us wrote:
 One of the files in the new (to introspection) cmph directory, chd_ph.c, 
 includes an anonymous union which requires -std=gnu99 to compile. Is that OK?

This would have been better as a bug.  However, if what you're
*really* asking here is:

* What's the gtk+/GNOME policy on compilers that we should build with?

That would be a good subject for a list discussion =)

What's the actual problem you ran into that caused you to make this
post (hypothetical example: You are trying to build the stack with
LLVM, and it doesn't support anonymous unions (it may actually, i'm
just making this up)).

Now, if we're trying to say that GTK+/GNOME only requires C89,
strictly speaking, we have work to do:

$ metabuild CFLAGS='-Wall -std=c89'
metabuild: logging to '/tmp/build-gtk3.log'
metabuild: Detected Makefile, using it
metabuild: Running: ['chrt', '--idle', '0', 'nice', 'ionice', '-c',
'3', '-t', 'make', 'CFLAGS=-Wall -std=c89', '-j', '24']
make  all-recursive
make[1]: Entering directory `/src/checkout/gtk3'
...
make[2]: Entering directory `/src/checkout/gtk3/gdk'
make[3]: Entering directory `/src/checkout/gtk3/gdk'
make[4]: Entering directory `/src/checkout/gtk3/gdk/win32'
make[4]: `.gitignore' is up to date.
make[4]: Leaving directory `/src/checkout/gtk3/gdk/win32'
make[4]: Entering directory `/src/checkout/gtk3/gdk/quartz'
make[4]: `.gitignore' is up to date.
make[4]: Leaving directory `/src/checkout/gtk3/gdk/quartz'
make[3]: Leaving directory `/src/checkout/gtk3/gdk'
make  all-recursive
make[3]: Entering directory `/src/checkout/gtk3/gdk'
Making all in x11
make[4]: Entering directory `/src/checkout/gtk3/gdk/x11'
  CC gdkapplaunchcontext-x11.lo
  CC gdkasync.lo
  CC gdkcursor-x11.lo
  CC gdkdevice-core.lo
  CC gdkdevicemanager-core.lo
  CC gdkdevicemanager-x11.lo
  CC gdkdisplay-x11.lo
  CC gdkdnd-x11.lo
  CC gdkeventsource.lo
  CC gdkgeometry-x11.lo
  CC gdkeventtranslator.lo
  CC gdkglobals-x11.lo
  CC gdkim-x11.lo
  CC gdkinput.lo
  CC gdkkeys-x11.lo
  CC gdkmain-x11.lo
  CC gdkproperty-x11.lo
  CC gdkscreen-x11.lo
  CC gdkselection-x11.lo
  CC gdkspawn-x11.lo
  CC gdktestutils-x11.lo
  CC gdkvisual-x11.lo
  CC gdkwindow-x11.lo
  CC gdkxftdefaults.lo
  CC gdkxid.lo
  CC checksettings.o
checksettings.c: In function ‘main’:
checksettings.c:43:7: error: expected expression before ‘/’ token

make[4]: *** [checksettings.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory `/src/checkout/gtk3/gdk/x11'

Now, obviously C++ comments in C files are pretty easy for other
compilers to implement.  But it's hard to know what other GNU C
extensions the GTK+ stack uses with without fixing those.  Are there
any nested functions for example in GTK+?  I'd be surprised, but you
never know...

The CMPH situation for g-i is special in a few ways because it's an
import of sort-of-maintained code, and I really don't want to be in
the business of diverging too far.  I should probably invest in axing
out a lot of the code that isn't used, but it's nontrivial.

Bottom line here - if there's a use case you think should be
supported, *explain what it is*, and let's discuss getting a buildbot
set up.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gobject-introspection] Multiple libraries in the 'shared-library' parameter

[Colin Walters]

On Wed, Dec 8, 2010 at 7:20 PM, Alan alan.mcgov...@gmail.com wrote:
 Hey,

 I'm just looking at generating bindings for .NET and I've hit an
 issue. For the .NET bindings you need to supply the native library
 name along with the function to invoke. I've noticed that the gir
 format likes to specify multiple library names in the shared-library
 parameter, for example in Gtk-3.0.gir I have:
 shared-library=libgtk-x11-3.0.so.0,libgdk-x11-3.0.so.0

Leaving aside the discussions ongoing now about folding gdk into gtk,
this is basically a workaround for a Debian libtool patch; some
discussion here:

https://bugzilla.gnome.org/show_bug.cgi?id=633405

We could undo this by running sed on the resulting XML I guess.  For
now, I suggest using just the first library name.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[John Ralls]

On Dec 15, 2010, at 9:21 AM, Colin Walters wrote:

 On Mon, Dec 13, 2010 at 1:35 PM, John Ralls jra...@ceridwen.us wrote:
 One of the files in the new (to introspection) cmph directory, chd_ph.c, 
 includes an anonymous union which requires -std=gnu99 to compile. Is that OK?
 
 This would have been better as a bug.  However, if what you're
 *really* asking here is:
 
 * What's the gtk+/GNOME policy on compilers that we should build with?
 
 That would be a good subject for a list discussion =)
 
 What's the actual problem you ran into that caused you to make this
 post (hypothetical example: You are trying to build the stack with
 LLVM, and it doesn't support anonymous unions (it may actually, i'm
 just making this up)).
 
 Now, if we're trying to say that GTK+/GNOME only requires C89,
 strictly speaking, we have work to do:
 
 $ metabuild CFLAGS='-Wall -std=c89'
 metabuild: logging to '/tmp/build-gtk3.log'
 metabuild: Detected Makefile, using it
 metabuild: Running: ['chrt', '--idle', '0', 'nice', 'ionice', '-c',
 '3', '-t', 'make', 'CFLAGS=-Wall -std=c89', '-j', '24']
 make  all-recursive
 make[1]: Entering directory `/src/checkout/gtk3'
 ...
 make[2]: Entering directory `/src/checkout/gtk3/gdk'
 make[3]: Entering directory `/src/checkout/gtk3/gdk'
 make[4]: Entering directory `/src/checkout/gtk3/gdk/win32'
 make[4]: `.gitignore' is up to date.
 make[4]: Leaving directory `/src/checkout/gtk3/gdk/win32'
 make[4]: Entering directory `/src/checkout/gtk3/gdk/quartz'
 make[4]: `.gitignore' is up to date.
 make[4]: Leaving directory `/src/checkout/gtk3/gdk/quartz'
 make[3]: Leaving directory `/src/checkout/gtk3/gdk'
 make  all-recursive
 make[3]: Entering directory `/src/checkout/gtk3/gdk'
 Making all in x11
 make[4]: Entering directory `/src/checkout/gtk3/gdk/x11'
  CC gdkapplaunchcontext-x11.lo
  CC gdkasync.lo
  CC gdkcursor-x11.lo
  CC gdkdevice-core.lo
  CC gdkdevicemanager-core.lo
  CC gdkdevicemanager-x11.lo
  CC gdkdisplay-x11.lo
  CC gdkdnd-x11.lo
  CC gdkeventsource.lo
  CC gdkgeometry-x11.lo
  CC gdkeventtranslator.lo
  CC gdkglobals-x11.lo
  CC gdkim-x11.lo
  CC gdkinput.lo
  CC gdkkeys-x11.lo
  CC gdkmain-x11.lo
  CC gdkproperty-x11.lo
  CC gdkscreen-x11.lo
  CC gdkselection-x11.lo
  CC gdkspawn-x11.lo
  CC gdktestutils-x11.lo
  CC gdkvisual-x11.lo
  CC gdkwindow-x11.lo
  CC gdkxftdefaults.lo
  CC gdkxid.lo
  CC checksettings.o
 checksettings.c: In function ‘main’:
 checksettings.c:43:7: error: expected expression before ‘/’ token
 
 make[4]: *** [checksettings.o] Error 1
 make[4]: *** Waiting for unfinished jobs
 make[4]: Leaving directory `/src/checkout/gtk3/gdk/x11'
 
 Now, obviously C++ comments in C files are pretty easy for other
 compilers to implement.  But it's hard to know what other GNU C
 extensions the GTK+ stack uses with without fixing those.  Are there
 any nested functions for example in GTK+?  I'd be surprised, but you
 never know...
 
 The CMPH situation for g-i is special in a few ways because it's an
 import of sort-of-maintained code, and I really don't want to be in
 the business of diverging too far.  I should probably invest in axing
 out a lot of the code that isn't used, but it's nontrivial.
 
 Bottom line here - if there's a use case you think should be
 supported, *explain what it is*, and let's discuss getting a buildbot
 set up.

I wanted to know whether I should file a bug on cmph not compiling when I feed 
it -std=c99 (almost everything else,
including gtk+, builds happily with c89, so no, it doesn't have nested 
functions) or just change the gtk-osx jhbuild module to use gnu99. 

I guess you answered the question, so I'll write a patch and file a bug... but 
probably not till early next week, as we're releasing Gnucash 2.4.0 this 
weekend and I've some work to do there first.

But since you bring it up, what is the official policy? Is it C89? Is it 
published somewhere?

Regards,
John Ralls


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

Re: Gobject-Introspection and CMPH

[Matthias Clasen]

On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote:

 But since you bring it up, what is the official policy? Is it C89? Is it 
 published somewhere?

For GTK+, we're generally avoiding C++ comments, since they cause
problems for the compilers that are used on win32. What other non-C89
features do you have in mind ?
Nested functions are not really worth discussing, thats just a
historical accident on the part of the gcc team...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gobject-Introspection and CMPH

[John Ralls]

On Dec 15, 2010, at 5:54 PM, Matthias Clasen wrote:

 On Wed, Dec 15, 2010 at 8:43 PM, John Ralls jra...@ceridwen.us wrote:
 
 But since you bring it up, what is the official policy? Is it C89? Is it 
 published somewhere?
 
 For GTK+, we're generally avoiding C++ comments, since they cause
 problems for the compilers that are used on win32. What other non-C89
 features do you have in mind ?
 Nested functions are not really worth discussing, thats just a
 historical accident on the part of the gcc team...

Actually, I don't have anything in mind. Although I like C++ comments (and C++ 
in general) I have no issues writing C89 (or KR  for that matter) code.

I just want to know what constitutes breaking the build so that I do the 
right thing when it happens. 

(I don't know why Colin went off on C++ comments. My original post was about an 
anonymous union.)

Regards,
John Ralls

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

Re: [GObject Introspection] Getting style colors using GTK and Python

[John Palmieri]

I talked to Colin.  Current plans are that PyGI will only be fully supported on 
Gtk3 where Gdk style functionality is going away.  See 
http://blogs.gnome.org/carlosg/2010/08/23/css-like-styling-for-gtk/ for an idea 
of where the styling code is headed.  Supporting arbitrary C structs won't be 
fixed and there are plans to prevent access to these potential segfault prone 
constructs.
 
- John Palmieri jo...@redhat.com wrote:

 This is broken - see bug
 https://bugzilla.gnome.org/show_bug.cgi?id=621258
 
 I have some workarounds in demos directory of pygobject but there is
 still no ways to get certain attributes.  I'll ping Colin again on
 Monday as he has landed his scanner changes.
 
 - Krzysztof Klinikowski kkszy...@gmail.com wrote:
 
  Hello. I need to get colors from used GTK style. Later, using PyGTK
 I
  do things like:
 
  def get_theme_colors(w = gtk.Window()):
w.realize()
style = w.get_style()
output = {}
 
for i in [base, text, fg, bg]:
  c = getattr(style, i)[gtk.STATE_NORMAL]
  output[i] = Color.from_gtk_color(c)
  c = getattr(style, i)[gtk.STATE_SELECTED]
  output[%s_selected % i] = Color.from_gtk_color(c)
 
return output
 
  Now im trying to do using PyGI:
 
  def get_theme_colors(w = gtk.Window()):
  w.realize()
  style = w.get_style()
  output = {}
 
  for i in [base, text, fg, bg]:
  print style.bg
  c = getattr(style, i)[gtk.StateType.NORMAL]
  output[i] = Color.from_gtk_color(c).hex
  c = getattr(style, i)[gtk.StateType.SELECTED]
  output[%s_selected % i] = Color.from_gtk_color(c).hex
 
  return output
 
  But something like style.bg always prits me:
 
  Segmentation fault (core dumped)
 
  Question is why? Should I do that in different way? I have no idea.
  Could anyone help me?
  ___
  gtk-devel-list mailing list
  gtk-devel-list@gnome.org
  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
 
 --
 --
 John (J5) Palmieri
 Software Engineer
 Red Hat, Inc.

-- 
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Gobject Introspection] GIRepository.gir seems incorrect

[Colin Walters]

On Thu, Aug 19, 2010 at 3:35 AM, Mildred Ki'Lya mildred...@gmail.com wrote:

 So I suppose that's a bug in vala then.

 Until the problem is fixed, I created a copy of the gir file and removed
 the offending function.

Well, it's more that the respective type systems are not fully in sync
- yet.  But convergence here would be good, and I'd like to see that
happen.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [GObject Introspection] Getting style colors using GTK and Python

[John Palmieri]

This is broken - see bug https://bugzilla.gnome.org/show_bug.cgi?id=621258

I have some workarounds in demos directory of pygobject but there is still no 
ways to get certain attributes.  I'll ping Colin again on Monday as he has 
landed his scanner changes.

- Krzysztof Klinikowski kkszy...@gmail.com wrote:

 Hello. I need to get colors from used GTK style. Later, using PyGTK I
 do things like:
 
 def get_theme_colors(w = gtk.Window()):
   w.realize()
   style = w.get_style()
   output = {}
 
   for i in [base, text, fg, bg]:
 c = getattr(style, i)[gtk.STATE_NORMAL]
 output[i] = Color.from_gtk_color(c)
 c = getattr(style, i)[gtk.STATE_SELECTED]
 output[%s_selected % i] = Color.from_gtk_color(c)
 
   return output
 
 Now im trying to do using PyGI:
 
 def get_theme_colors(w = gtk.Window()):
 w.realize()
 style = w.get_style()
 output = {}
 
 for i in [base, text, fg, bg]:
 print style.bg
 c = getattr(style, i)[gtk.StateType.NORMAL]
 output[i] = Color.from_gtk_color(c).hex
 c = getattr(style, i)[gtk.StateType.SELECTED]
 output[%s_selected % i] = Color.from_gtk_color(c).hex
 
 return output
 
 But something like style.bg   always prits me:
 
 Segmentation fault (core dumped)
 
 Question is why? Should I do that in different way? I have no idea.
 Could anyone help me?
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-devel-list

-- 
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Gobject Introspection] GIRepository.gir seems incorrect

[Steve Frécinaux]

On 08/18/2010 07:32 PM, Mildred Ki'Lya wrote:

Hi,

I'm trying to use the GIRepository library in order to access GI
information and create a compile time binding for the Lisaac language.

I don't like C very much, and I'm going to use Vala. But the vala
compiler complains that it can't find the type filename.


GObject introspection use a filename string type to mark strings that 
represent file names, because those are not utf8 strings, rather 
bytestrings with exceptions.

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

Re: GObject Introspection support for GSList or other types without a GLib type

[Daniel Espinosa]

That's true, but is there any data type check when g_object_set/get function
is called?

If GLib plans to use G_TYPE_POINTER for GSList, GError, gshort, and any
other data type without G_TYPE* macro defined, then just tell it on the
documentation: if you (programer) want to use a not defined type use
G_TYPE_POINTER on properties declaration.

If documented or the better practice is stablished, some projects like
Anjuta doesn't need to define a G_TYPE_ERROR from him self.

2009/6/17 Owen Taylor otay...@redhat.com

 On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:
  How to handle data types without a GLib GType defined.
 
  On libgda, it define a GType for GError and a GSList becouse these
  doesn't exist on GLib and it uses them as parameters when creating
  properties and events.
 
  For now may be the library (as Anjuta does) must create its own GType
  definition but with the following rule: the name of the type must be
  defined as GError and GSList, in order to allow g-ri-scanner to
  detects the currect types GError and GSList as the example.
 
  In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with GdaError and
  GdaSList, then the scanner tries to find a definition to GdaError
  and GdaSList but they don't exist, when changed this types' names as
  avobe the correct type is detected.

 To point out what may be obvious - there is zero advantage of a
 X_TYPE_SLIST over G_TYPE_POINTER.

 This is true in general, and true for gobject-introspection - if
 gobject-introspection finds a property by introspection and deduces a
 type of GSList for it, it still doesn't have the element-type.

 - Owen





-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (en trámite, pero para los cuates:
LIBRE)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject Introspection support for GSList or other types without a GLib type

[Owen Taylor]

On Sun, 2009-06-21 at 19:33 -0500, Daniel Espinosa wrote:
 That's true, but is there any data type check when g_object_set/get
 function is called?
 
 If GLib plans to use G_TYPE_POINTER for GSList, GError, gshort, and
 any other data type without G_TYPE* macro defined, then just tell it
 on the documentation: if you (programer) want to use a not defined
 type use G_TYPE_POINTER on properties declaration.
 
 If documented or the better practice is stablished, some projects like
 Anjuta doesn't need to define a G_TYPE_ERROR from him self.

You are misunderstanding my comment.

I'm talking in *particular* about GSList. Well and GList, GHashTable and
other container types.

Without parameterized types (a list of what?) G_TYPE_SLIST is useless.

- Owen

 2009/6/17 Owen Taylor otay...@redhat.com
 On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:
  How to handle data types without a GLib GType defined.
 
  On libgda, it define a GType for GError and a GSList becouse
 these
  doesn't exist on GLib and it uses them as parameters when
 creating
  properties and events.
 
  For now may be the library (as Anjuta does) must create its
 own GType
  definition but with the following rule: the name of the type
 must be
  defined as GError and GSList, in order to allow
 g-ri-scanner to
  detects the currect types GError and GSList as the example.
 
  In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with
 GdaError and
  GdaSList, then the scanner tries to find a definition to
 GdaError
  and GdaSList but they don't exist, when changed this types'
 names as
  avobe the correct type is detected.
 
 
 To point out what may be obvious - there is zero advantage of
 a
 X_TYPE_SLIST over G_TYPE_POINTER.
 
 This is true in general, and true for gobject-introspection -
 if
 gobject-introspection finds a property by introspection and
 deduces a
 type of GSList for it, it still doesn't have the element-type.
 
 - Owen
 
 
 
 
 
 -- 
 Trabajar, la mejor arma para tu superación
 de grano en grano, se hace la arena (R) (en trámite, pero para los
 cuates: LIBRE)

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

Re: GObject Introspection problems

[Colin Walters]

On Fri, Jun 19, 2009 at 7:56 AM, Daniel Espinosaeso...@gmail.com wrote:
 I'm introducing GObject Introspection y two libraries GDA and my own project
 libcash[http://sourceforge.net/projects/libcash/], but when compiling to
 generate gir and typedef files I get this errors messages.

My guess here is that the parser has gotten confused by an error
earlier.  In csh-account.c, I bet this is the problem:

static gchar *sql_debit = SELECT sum (amount) FROM transactions \
WHERE debit in \
 (SELECT id 
FROM accounts \
  WHERE parent 
in \
  (SELECT id 
FROM accounts WHERE id = ##account::int or parent
= ##account::int) \
  UNION SELECT 
id FROM accounts WHERE id = ##account::int);

Multiline strings with this syntax are a GCC extension I believe, and
it's possible our current parser handles them.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject Introspection support for GSList or other types without a GLib type

[Owen Taylor]

On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:
 How to handle data types without a GLib GType defined.
 
 On libgda, it define a GType for GError and a GSList becouse these
 doesn't exist on GLib and it uses them as parameters when creating
 properties and events.
 
 For now may be the library (as Anjuta does) must create its own GType
 definition but with the following rule: the name of the type must be
 defined as GError and GSList, in order to allow g-ri-scanner to
 detects the currect types GError and GSList as the example.
 
 In GDA it has GDA_TYPE_ERROR and GDA_TYPE_SLIST with GdaError and
 GdaSList, then the scanner tries to find a definition to GdaError
 and GdaSList but they don't exist, when changed this types' names as
 avobe the correct type is detected.

To point out what may be obvious - there is zero advantage of a
X_TYPE_SLIST over G_TYPE_POINTER. 

This is true in general, and true for gobject-introspection - if
gobject-introspection finds a property by introspection and deduces a
type of GSList for it, it still doesn't have the element-type. 

- Owen


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

Re: GObject Introspection support for GSList or other types without a GLib type

[Tim-Philipp Müller]

On Sun, 2009-06-14 at 02:30 -0500, Daniel Espinosa wrote:

 On libgda, it define a GType for GError and a GSList becouse these
 doesn't exist on GLib and it uses them as parameters when creating
 properties and events.

Great, another library that registers its own GError boxed type. I think
I've lost count now. Any chance we could get a boxed type for GError in
GLib after all? (see bugs #300610 and #337092)

 Cheers
  -Tim


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

Re: GObject Introspection as part of the GNOME platform

[Stefan Kost]

Emmanuele Bassi schrieb:
 On Tue, 2009-03-10 at 15:18 -0300, Johan Dahlin wrote:
 Hi,

 We think GObject Introspection adds a lot to the GNOME platform and
 would like to
 discuss how it can be integrated.
 
 yey!
 
 absolutely agree about finally having G-I integrated in the platform.
 
 * Source comment (gtk-doc) annotations we expect C authors to
   use and maintain in libraries
 
 it would be good to have a gtk-doc release (and people depending on it,
 so that distro will finally start shipping a decent version of gtk-doc)
 that understands those annotations, stripping them when needed or adding
 human readable descriptions (this would also help increase the
 consistency in the API references on library.gnome.org). I know that
 ensonic is working on this.

I'll try to make one by the end of april at least (hopefully earlier). There is
some ongoing changes, but I can turn those things off, if I can finish them. The
syntax highlighed code listing changes could get more testing though. I prefer
to get the bug reports before releasing :)

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

Re: GObject Introspection as part of the GNOME platform

[Emmanuele Bassi]

On Tue, 2009-03-10 at 15:18 -0300, Johan Dahlin wrote:
 Hi,
 
 We think GObject Introspection adds a lot to the GNOME platform and
 would like to
 discuss how it can be integrated.

yey!

absolutely agree about finally having G-I integrated in the platform.

 * Source comment (gtk-doc) annotations we expect C authors to
   use and maintain in libraries

it would be good to have a gtk-doc release (and people depending on it,
so that distro will finally start shipping a decent version of gtk-doc)
that understands those annotations, stripping them when needed or adding
human readable descriptions (this would also help increase the
consistency in the API references on library.gnome.org). I know that
ensonic is working on this.

 == Option 1: Included in glib.tar.gz, included in libgobject-2.0.so ==

 == Option 2: Included in glib.tar.gz, as a separate libgirepository-1.0.so ==

I'd obviously favour either option 1) or 2), with a slight preference
for 1). being able to refactor parts of the GType system using
introspection would be a killer feature.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net

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

Re: GObject Introspection as part of the GNOME platform

[Rob Taylor]

Emmanuele Bassi wrote:
 On Tue, 2009-03-10 at 15:18 -0300, Johan Dahlin wrote:
 Hi,

 We think GObject Introspection adds a lot to the GNOME platform and
 would like to
 discuss how it can be integrated.
 
 yey!
 
 absolutely agree about finally having G-I integrated in the platform.
 
 * Source comment (gtk-doc) annotations we expect C authors to
   use and maintain in libraries
 
 it would be good to have a gtk-doc release (and people depending on it,
 so that distro will finally start shipping a decent version of gtk-doc)
 that understands those annotations, stripping them when needed or adding
 human readable descriptions (this would also help increase the
 consistency in the API references on library.gnome.org). I know that
 ensonic is working on this.
 
 == Option 1: Included in glib.tar.gz, included in libgobject-2.0.so ==
 
 == Option 2: Included in glib.tar.gz, as a separate libgirepository-1.0.so ==
 
 I'd obviously favour either option 1) or 2), with a slight preference
 for 1). being able to refactor parts of the GType system using
 introspection would be a killer feature.


This sounds great to me, though I do hope we can make sure there's an
obvious approach to cross-compiling it before including in glib proper.
 - and that includes good support for building the typelibs when
cross-compiling. I recall early on we had a pretty good story here, but
I'm not sure what the current state is.

Thanks,
Rob


 ciao,
  Emmanuele.
 


-- 
Rob Taylor, Codethink Ltd. - http://codethink.co.uk
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject Introspection as part of the GNOME platform

[Johan Dahlin]

On Wed, Mar 11, 2009 at 9:55 AM, Rob Taylor rob.tay...@codethink.co.uk wrote:
 Emmanuele Bassi wrote:

 This sounds great to me, though I do hope we can make sure there's an
 obvious approach to cross-compiling it before including in glib proper.
  - and that includes good support for building the typelibs when
 cross-compiling. I recall early on we had a pretty good story here, but
 I'm not sure what the current state is.

As far as I can see there aren't any easy solutions.
We're depending on libffi to calculate struct sizes for the typelib
which is very
much host and compiler dependent.  g-ir-compile really needs to run on the
target system the way things are setup right now. The same applies
for the small generated program which introspects signals  properties, but
that's probably easier to solve.

In my opinion, supporting cross-compilation shouldn't be a blocker for
integration into glib proper. It's more of a 'nice feature' to support.

-- 
Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject Introspection as part of the GNOME platform

[muppet]

Johan Dahlin wrote:
 As far as I can see there aren't any easy solutions.
 We're depending on libffi to calculate struct sizes for the typelib
 which is very
 much host and compiler dependent.  g-ir-compile really needs to run on the
 target system the way things are setup right now. The same applies
 for the small generated program which introspects signals  properties, but
 that's probably easier to solve.

 In my opinion, supporting cross-compilation shouldn't be a blocker for
 integration into glib proper. It's more of a 'nice feature' to support.

I'm sure people putting gnome on phones will disagree.

You could do tricks like using the cross compiler to generate assembly instead
of machine code from specially-crafted, generated C code, and then parse the
resulting assembly to extract the structure sizes and offsets.


-- 
muppet scott at asofyet dot org

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

Re: GObject Introspection as part of the GNOME platform

[Rob Taylor]

muppet wrote:
 Johan Dahlin wrote:
 As far as I can see there aren't any easy solutions.
 We're depending on libffi to calculate struct sizes for the typelib
 which is very
 much host and compiler dependent.  g-ir-compile really needs to run on the
 target system the way things are setup right now. The same applies
 for the small generated program which introspects signals  properties, but
 that's probably easier to solve.

 In my opinion, supporting cross-compilation shouldn't be a blocker for
 integration into glib proper. It's more of a 'nice feature' to support.
 
 I'm sure people putting gnome on phones will disagree.

That was kinda my thought.

 You could do tricks like using the cross compiler to generate assembly instead
 of machine code from specially-crafted, generated C code, and then parse the
 resulting assembly to extract the structure sizes and offsets.

Ick. Maybe a better option is to use
AC_CHECK_SIZEOF and AC_CHECK_ALIGNOF, though I'm far from sure how
useful that is in this case or even if it'll work in general.

Thanks,
Rob


-- 
Rob Taylor, Codethink Ltd. - http://codethink.co.uk
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject Introspection as part of the GNOME platform

[Mathieu Lacage]

On Wed, 2009-03-11 at 11:08 -0400, muppet wrote:
 Johan Dahlin wrote:
  As far as I can see there aren't any easy solutions.
  We're depending on libffi to calculate struct sizes for the typelib
  which is very
  much host and compiler dependent.  g-ir-compile really needs to run on the
  target system the way things are setup right now. The same applies
  for the small generated program which introspects signals  properties, but
  that's probably easier to solve.
 
  In my opinion, supporting cross-compilation shouldn't be a blocker for
  integration into glib proper. It's more of a 'nice feature' to support.
 
 I'm sure people putting gnome on phones will disagree.
 
 You could do tricks like using the cross compiler to generate assembly instead
 of machine code from specially-crafted, generated C code, and then parse the
 resulting assembly to extract the structure sizes and offsets.

Maybe it is really obvious but, why are you not using the output of
readelf -wi ? It's fairly trivial to parse and all of this could be done
on the host without any working target provided you have a
cross-compiler.

A sample output parser is attached to this email. Feel free to consider
it in the public domain and rip it out if you wish to. (at some point, I
had a working C-based dwarf2/3 debuginfo parser which did not rely on
readelf, and I could share that if there was really interest but,
really, I don't think it would be of much use).

regards,
Mathieu
#!/usr/bin/env python

import sys
import re
import getopt
import os


class Data:
def __init__(self, data):
self.data = data

class DebugData:
class Item:
def __init__(self):
self.type = ''
self.ref = 0
self.level = 0
self.attributes = {}
def __init__(self, debug_filename):
file = os.popen ('readelf -wi ' + debug_filename, 'r')
self.__lines = file.readlines ()
self.__current = 0
self.__re1 = re.compile ('([^]+)([^]+):[^A]*Abbrev Number:.*\d+.*\((\w+)\)')
self.__re2 = re.compile ('[^]+[^D]*(DW_AT_\w+)([^:]*:)+ ?0?x?([^ \t\)]+)[ \t\)]*$')
return
def rewind (self):
self.__current = 0
return
def read_line (self):
if self.__current == len (self.__lines):
return ''
line = self.__lines[self.__current]
self.__current = self.__current + 1
return line
def write_back_line (self):
self.__current = self.__current - 1
return
def write_back_one (self, item):
self.__current = self.__current - 1 - len (item.attributes.keys ())
return
def read_one (self):
item = DebugData.Item ()
while 1:
line = self.read_line ()
if line == '':
if item.type == '':
return None
else:
return item
result = self.__re1.search (line)
if result is None:
continue
item.level = result.group (1)
item.ref = result.group (2)
item.type = result.group (3)
while 1:
line = self.read_line ()
result = self.__re1.search (line)
if result is not None:
self.write_back_line ()
return item
result = self.__re2.search (line)
if result is None:
self.write_back_line ()
return item
item.attributes[result.group (1)] = result.group (3)
return item
def find_struct (self, struct_type_name):
return self.find_by_name ('DW_TAG_structure_type', struct_type_name)
def find_by_name (self, type, name):
item = self.read_one ()
while item is not None:
if item.type == type and \
item.attributes.has_key ('DW_AT_name') and \
item.attributes['DW_AT_name'] == name:
return item
item = self.read_one ()
return item
def find_by_ref (self, ref):
item = self.read_one ()
while item is not None:
if item.ref == ref:
return item
item = self.read_one ()
return item
def find_member (self, member_name, parent):
sub_item = self.read_one ()
while sub_item is not None:
if sub_item.level == parent.level:
self.write_back_one ()
return None
if sub_item.type == 'DW_TAG_member' and \
sub_item.attributes.has_key ('DW_AT_name') and \
sub_item.attributes['DW_AT_name'] == member_name:
return Data (sub_item.attributes['DW_AT_data_member_location'])
sub_item = self.read_one ()
return None
# public methods below
def get_struct_member_offset (self, struct_type_name, member_name):
self.rewind ()
item = 

Re: GObject Introspection as part of the GNOME platform

[Brian J. Tarricone]

Johan Dahlin wrote:


In my opinion, supporting cross-compilation shouldn't be a blocker for
integration into glib proper. It's more of a 'nice feature' to support.


As long as that means glib will still cross-compile, just the 
introspection stuff gets disabled, I'm ok with that.  Otherwise... 
yuck, that's awful.


-brian

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

Re: gobject-introspection boilerplate

[Johan Dahlin]

On Mon, Feb 2, 2009 at 1:57 PM, Behdad Esfahbod beh...@behdad.org wrote:
 Hi,

 I'm trying to make a pango devel release but I can't get the
 gobject-introspection stuff happy.  Main reason is that it requires 0.6.2 but
 rawhide only has 0.6.1, but there's also a bunch of autotools-related
 improvements that can be made.  Since this stuff is copied in more than one
 module I'm writing here.  I can make the changes to pango tonight if that 
 helps.

Yeah, I should have done that. My autofoo is not strong enough to do macros yet.

 Moreover, it would be a good idea to add --enable-introspection with a default
 value of auto, to give people (distros, etc) full control on whether to
 (re)build the introspection stuff.

Right, it probably makes sense to be able to disable it.

 Finally, when I try to make dist or make distcheck, I should get an error
 if introspection is not enabled.  Otherwise I may make a release with stale
 .git files.  To do that check how gtk-doc does it:

 if ENABLE_GTK_DOC
 dist-check-gtkdoc:
 else
 dist-check-gtkdoc:
@echo *** gtk-doc must be installed and enabled in order to make dist
@false
 endif

 dist-hook: dist-check-gtkdoc

We should try putting this in a macro or included through a Makefile which
is distributed by introspection.

 And, one last point, we should advise automake that distcheck should enable
 introspection.  This is done in the toplevel Makefile.am:

 DISTCHECK_CONFIGURE_FLAGS = --enable-gtk-doc

Oh, I wasn't aware of that piece of magic.

I'm not sure that I can find time to write a proper .m4 and test it this week.
I guess someone else has to volunteer or we have to revert the patch until
I can find time to do it properly.

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

Re: GObject-Introspection 0.6.2

[Alberto Ruiz]

2009/1/22 Johan Dahlin jo...@gnome.org:
 I'm proud to announce yet another release of GObject-Introspection.

You guys rock!

 Tarballs can be found at:
http://download.gnome.org/sources/gobject-introspection/0.6/

 What's new in this release?

 * Gtk-doc comments (including version and deprecated) are
  now included in girs.
 * Callback annotations (scope)
 * Rewritten annotation parser
 * Struct methods
 * Bugs fixed:
- Bug 562622 – Errordomains missing
- Bug 562615 – Struct methods missing
- Bug 567813 – Everything should be versioned
- Bug 555036 – put gtk-doc in GIR
- Bug 562467 – Property annotation
- Bug 546739 – Introspection should know precise signal parameter types
- Bug 563591 – Flags not recognized when there is no introspection data
- Bug 563386 – scanner ignores const on boxed return values
- Bug 566404 – Annotations for GLib
- Bug 566419 – Element type of arrays not properly handled in all cases
- Bug 566560 – giscanner.transformer.SkipError
- Bug 563794 - Redo annotation parsing  applying
- Bug 563469 – Arrays not treated correctly in struct offset calculation
- Bug 556489 – callback annotations
- Bug 563998 – Cache the GIBaseInfo for GTypes
- Bug 562545 – Add function taking / returning GValue
- Bug 563742 – introspection should record the introduced version of
- Bug 562971 – g-ir-scanner failure on libgpod headers
- Bug 562289 – Race when removing invalid cache
- Bug 559705 – Missing association between static methods and classes
- Bug 562022 – gobject-introspection needs python headers
- Bug 561617 – Return value array annotations
- Bug 561296 - Add storage type to the typelib data for enums
- Bug 559706 - Interface prerequisites
- Bug 561087 - Respect is_pointer in serialize_type()
- Bug 560825 – Add size and alignment to typelib

 I've also started the process of moving GIR generation to the upstream
 libraries.
 Pango is already supporting that and Atk and Gtk+ will do so in the near 
 future.
 This is necessary to be able to get documentation inside the gir, an example
 of a GIR of Gtk+ trunk from a couple of days agao can be found here:

 http://www.gnome.org/~johan/Gtk-2.0.gir.gz (300kb)

 The goal of the project is to describe the APIs and collect them in
 a uniform, machine readable format. The initial target is language bindings,
 which are heavy users of this kind of data.

 Interesting parts of this release includes:

 * GIR - An XML format used to describe APIs
 * Typelib - a way to serialize GIR to disk
 * libgirepository - C API to access typelib

 GIR format is fairly stable, but expect small parts to change.
 The typelib format is not complete and will be extended upon in future 
 releases.

 There are Perl, Python and Java bindings publicly available using
 GObject-Introspection. The gir-repository provides GIRs for common
 GObject based libraries (such as pango,gtk,gstreamer,clutter,webkit) until
 the libraries themselves ship them.

 I'd like to specially thank the following people, who made this release
 possible: Matthias Clasen for the initial prototype and general design,
 Jürg Biletter for writing a header scanner, Colin Walters for helping out
 everywhere and making sure the release got done. Richard Hult  Tor
 Lillqvist for testing and making sure it works on MacOS X  Win32.

 See http://live.gnome.org/GObjectIntrospection and the README included
 in the tarball for more information.

 Thanks to all contributors to this release:
  Johan Bilien, Jürg Billeter, Christophe Fergeau, Havoc Pennington,
  Andreas Rottmann, Owen Taylor, Tristan Van Berkom, Colin Walters
  Dan Winship

 GObject-Introspection requires flex, bison, python (2.5 or higher) and
 glib. ffi 3.0.1 or higher can optionally be used.

 Reports bugs to
 http://bugzilla.gnome.org/enter_bug.cgi?product=glibcomponent=introspection
 Contract us at: gtk-devel-list@gnome.org or #introspection at irc.gnome.org
 Homepage: http://live.gnome.org/GObjectIntrospection

 Johan Dahlin
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-devel-list




-- 
Un saludo,
Alberto Ruiz
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gobject-introspection and gtkmmproc (Re: [Vala] Auto mm(C++) binding for libraries written in Vala?)

[Murray Cumming]

On Tue, 2008-10-14 at 14:31 -0400, Yu Feng wrote:
 Hi,
 
 there is a link at http://live.gnome.org/GObjectIntrospection/
 saying that gtkmm 'can' use gobject-introspection.
 
 Is anyone working on this

No.

  / when will it likely to be done?

Not soon unless someone decides that they would enjoy doing it.

gobject-introspection doesn't offer much for gtkmm, though it could give
us better .def files (or some other file format at that stage in
gmmproc).

A general gmmproc rewrite would also be nice, probably using all python,
keeping the existing behaviour, but again, it would not actually be
immediately useful.


-- 
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com


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

Re: GObject-Introspection 0.5.0

[Mathieu Lacage]

[trimming the mad CC list]

On Mon, 2008-09-08 at 07:42 +0200, Mikkel Kamstrup Erlandsen wrote:

  typedef enum {
 GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after 
  use */
 GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it 
  is */
  } GITypeOwnership;
 
  Just as a nitpick, these two names look very similar and quite confusing
  for non-native English speakers.  Maybe you could come up with something
  different, especially in place of 'callee'?
 
  It's actually commonly-used terminology, e.g. caller-save registers
  vs. callee-save registers in compilers.
 
 With all due respect I am not sure compiler-writers are the main
 audience of GObject Introspection. I for one find the terminology a
 bit confusing too.

I am neither a native english speaker nor a compiler writer but callee
vs caller is pretty standard terminology. None of the proposed
alternatives look any better and they all fail the standard
terminology test. When I started programming, my english language
vocabulary quickly expanded to include such terms. It seems pretty
reasonable to expect new programmers/non native english speakers go
through the same kind of learning. Such is life for those not blessed
with being born in the right country...

Mathieu

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

Re: GObject-Introspection 0.5.0

[Mikkel Kamstrup Erlandsen]

2008/9/9 David Zeuthen [EMAIL PROTECTED]:
 On Tue, 2008-09-09 at 10:12 -0700, Mathieu Lacage wrote:
 I am neither a native english speaker nor a compiler writer but callee
 vs caller is pretty standard terminology.

 Completely agree.

David (not a native English speaker either)

Ok. I admit that I am bike shedding here. I can assure you that I'll
have a good life no matter the final wording :-)

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

Re: GObject-Introspection 0.5.0

[Paolo Bonzini]

Mikkel Kamstrup Erlandsen wrote:
 2008/9/7 Paolo Bonzini [EMAIL PROTECTED]:
 I'm leaning towards using the ownership terminology instead of 
 transfer.
 typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use 
 */
GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it is 
 */
 } GITypeOwnership;
 Just as a nitpick, these two names look very similar and quite confusing
 for non-native English speakers.  Maybe you could come up with something
 different, especially in place of 'callee'?
 It's actually commonly-used terminology, e.g. caller-save registers
 vs. callee-save registers in compilers.
 
 With all due respect I am not sure compiler-writers are the main
 audience of GObject Introspection. I for one find the terminology a
 bit confusing too.

What about employer and employee instead? :-)

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

Re: GObject-Introspection 0.5.0

[Havoc Pennington]

Hi,

On Mon, Sep 8, 2008 at 12:07 PM, Mike Kestner [EMAIL PROTECTED] wrote:

 If either attribute is unspecified, it's assumed to be false.


Kind of a detail, but with the scanner setup in g-i, I think it would
be good to require manual specification of ownership for all allocated
types. Otherwise we can't tell what has been looked at.

If you're adding introspection to a new library (or a new part of an
old library), bottom line is somebody has to go through and specify
all the ownerships by hand, so at least in some mode we should be able
to tell whether that's been done. If a new function appears in a
library, g-i should somehow notify us that ownership has to be
specified.

If we don't automate detecting the case where ownership hasn't been
looked at by hand, surely it's going to constantly break ...

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

Re: GObject-Introspection 0.5.0

[Johan Dahlin]

Murray Cumming wrote:

On Mon, 2008-09-08 at 10:09 -0500, Mike Kestner wrote:

On Sun, 2008-09-07 at 17:39 +0200, Johan Dahlin wrote:

Paul Pogonyshev wrote:

Johan Dahlin wrote:

[...]

  I'm leaning towards using the ownership terminology instead of transfer. 

typedef enum {
   GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
   GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it is */
} GITypeOwnership;

Just as a nitpick, these two names look very similar and quite confusing
for non-native English speakers.  Maybe you could come up with something
different, especially in place of 'callee'?

Agreed, I'm open to suggestions.
caller/subroutine ?

In GAPI, we have two ownership attributes on list elements: owned and
elements_owned.


or nothing is owned. Yes, we have these 3 in gtkmm too. Johan's system
offers a fourth combination, list-not-owned, element-owned, so-far not
seen in the wild), but it seems fine.


True, but most importantly: it supports lists of lists.

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

Re: GObject-Introspection 0.5.0

[Johan Dahlin]

Alexander Larsson wrote:

On Mon, 2008-09-01 at 09:35 +0200, Johan Dahlin wrote:

I'm proud to announce the initial release of GObject-Introspection.
Colin Walters and I have been hacking madly on it for the past couple of 
weeks and we have finally reached a point to where we're ready for more

more users.

Tarball can be found at:
http://download.gnome.org/sources/gobject-introspection/0.5/

The goal of the project is to describe the APIs and collect them in
a uniform, machine readable format. The initial target is language bindings, 
which are heavy users of this kind of data.


I have a question about the details of GITransfer.


GITransfer is still a bit in a flux as none of the existing (open) users
use it yet.

GITransfer is part of the typelib which hasn't yet been updated to the 
revised XML format. One of the main changes was to allow nested types 
definitions, and thus being able to specify things such as:

- type of the list
- type of the element

I'm leaning towards using the ownership terminology instead of transfer.

typedef enum {
  GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
  GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it is */
} GITypeOwnership;


Ownership examples of existing APIs:
  gtk_container_get_children: list = caller, element = callee
  gtk_icon_view_get_selected_items: list = caller, element = caller
  gtk_rc_get_default_files: list = callee, element = callee

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

Re: GObject-Introspection 0.5.0

[Paul Pogonyshev]

Johan Dahlin wrote:
 [...]

  I'm leaning towards using the ownership terminology instead of transfer. 
 
 typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it is */
 } GITypeOwnership;

Just as a nitpick, these two names look very similar and quite confusing
for non-native English speakers.  Maybe you could come up with something
different, especially in place of 'callee'?

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

Re: GObject-Introspection 0.5.0

[Paolo Bonzini]

 I'm leaning towards using the ownership terminology instead of transfer. 
 typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it is */
 } GITypeOwnership;
 
 Just as a nitpick, these two names look very similar and quite confusing
 for non-native English speakers.  Maybe you could come up with something
 different, especially in place of 'callee'?

It's actually commonly-used terminology, e.g. caller-save registers
vs. callee-save registers in compilers.

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

Re: GObject-Introspection 0.5.0

[Alexander Larsson]

On Sun, 2008-09-07 at 17:01 +0200, Johan Dahlin wrote:
 Alexander Larsson wrote:
  On Mon, 2008-09-01 at 09:35 +0200, Johan Dahlin wrote:
  I'm proud to announce the initial release of GObject-Introspection.
  Colin Walters and I have been hacking madly on it for the past couple of 
  weeks and we have finally reached a point to where we're ready for more
  more users.
 
  Tarball can be found at:
  http://download.gnome.org/sources/gobject-introspection/0.5/
 
  The goal of the project is to describe the APIs and collect them in
  a uniform, machine readable format. The initial target is language 
  bindings, 
  which are heavy users of this kind of data.
  
  I have a question about the details of GITransfer.
 
 GITransfer is still a bit in a flux as none of the existing (open) users
 use it yet.
 
 GITransfer is part of the typelib which hasn't yet been updated to the 
 revised XML format. One of the main changes was to allow nested types 
 definitions, and thus being able to specify things such as:
 - type of the list
 - type of the element
 
 I'm leaning towards using the ownership terminology instead of transfer.
 
 typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it is */
 } GITypeOwnership;
 
 
 Ownership examples of existing APIs:
gtk_container_get_children: list = caller, element = callee
gtk_icon_view_get_selected_items: list = caller, element = caller
gtk_rc_get_default_files: list = callee, element = callee

So, your specify ownership twice, once for container and once for
contents? Makes sense to me. 

The problem with the transfer terminology is that it takes a different
meaning for in args than for out/return args, and this way we can avoid
that.


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

Re: GObject-Introspection 0.5.0

[Mikkel Kamstrup Erlandsen]

2008/9/7 Paolo Bonzini [EMAIL PROTECTED]:

 I'm leaning towards using the ownership terminology instead of transfer.
 typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use 
 */
GI_OWNERSHIP_CALLEE  /* callee owns it, caller should leave it as it is 
 */
 } GITypeOwnership;

 Just as a nitpick, these two names look very similar and quite confusing
 for non-native English speakers.  Maybe you could come up with something
 different, especially in place of 'callee'?

 It's actually commonly-used terminology, e.g. caller-save registers
 vs. callee-save registers in compilers.

With all due respect I am not sure compiler-writers are the main
audience of GObject Introspection. I for one find the terminology a
bit confusing too.


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

Re: GObject-Introspection

[BJörn Lindqvist]

2008/6/2 Johan Dahlin [EMAIL PROTECTED]:
 An alternative here is make a clean break, eg only use this in new
 language bindings and make the typelib/GIR define the API.

 For Python I plan to;
 * Convert PyGTK .defs to .xml, still keep them locally
 * Find out the changes between the .gir in gir-repository/upstream and
   apply fixes/patches on top of them
 * Write a new module, eg pybank which interacts with the typelibs only

 That means that the old cruft we collected in PyGTK will only
 be cruft there and not upstream. For future modules we'll use the
 more 'dynamic' bindings as available in pybank.

About the xml format... What is the advantage of having the c library
meta data stored in xml format instead of s-expressions? The .defs
files used for Python bindings are very succinct in comparison to the
ugly .xml files GIR brings to the table. Writing and updating
s-expressions is much easier than xml.

Why is a new XML syntax needed altogether when .defs already exist?
Couldn't that syntax just be extended?

I looked at the gir-repository, I couldn't find anything that makes
writing bindings easier. E.g:

function name=init c:identifier=FcInit
  return-value
type name=none c:type=void/
  /return-value
  parameters
  /parameters
/function

seem to be roughly the same as:

(define-function init
  (c-name FcInit)
  (return-type none)
  (parameters
'()
  )
)

And presumably, you would still have to hand-write large parts of the
bindings using something analogous to PyGTK's overrides. I can't think
of any automagic that would turn this C function:

  void gtk_label_get (GtkLabel *label, char **text);

to this Python method:

  gtk.Label.get() - str()

Please tell me if I'm wrong.


-- 
mvh Björn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject-Introspection

[Johan Dahlin]

BJörn Lindqvist wrote:

2008/6/2 Johan Dahlin [EMAIL PROTECTED]:

An alternative here is make a clean break, eg only use this in new
language bindings and make the typelib/GIR define the API.

For Python I plan to;
* Convert PyGTK .defs to .xml, still keep them locally
* Find out the changes between the .gir in gir-repository/upstream and
  apply fixes/patches on top of them
* Write a new module, eg pybank which interacts with the typelibs only

That means that the old cruft we collected in PyGTK will only
be cruft there and not upstream. For future modules we'll use the
more 'dynamic' bindings as available in pybank.


About the xml format... What is the advantage of having the c library
meta data stored in xml format instead of s-expressions? The .defs
files used for Python bindings are very succinct in comparison to the
ugly .xml files GIR brings to the table. Writing and updating
s-expressions is much easier than xml.


There were a couple of reasons to switching to xml over s-expressions.
The primary one is that XML is more popular, most modern languages
have parsers builtin which will make it easier to write tools upon it.
Other reasons includes that xml is more flexible.

The GIR XML is meant to be processed  modified by tools, not human beings.


And presumably, you would still have to hand-write large parts of the
bindings using something analogous to PyGTK's overrides. I can't think
of any automagic that would turn this C function:

  void gtk_label_get (GtkLabel *label, char **text);


We solve that by adding annotations in the gtk-doc comment.
The specific case you mentioned will have something like this:

/**
 * gtk_label_get
 * @label: the label
 * @text: (out): the text of the label
 */

Which will in turn be create the following XML snippet:
parameter name=text direction=out
  type name=string/
/parameter

The idea is to annotate most of the available API so almost the complete 
bindings can done without manually overriding parts.


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

Re: GObject-Introspection

[Michael Lawrence]

On Mon, Sep 1, 2008 at 7:33 AM, Johan Dahlin [EMAIL PROTECTED] wrote:

 BJörn Lindqvist wrote:

 2008/6/2 Johan Dahlin [EMAIL PROTECTED]:

 An alternative here is make a clean break, eg only use this in new
 language bindings and make the typelib/GIR define the API.

 For Python I plan to;
 * Convert PyGTK .defs to .xml, still keep them locally
 * Find out the changes between the .gir in gir-repository/upstream and
  apply fixes/patches on top of them
 * Write a new module, eg pybank which interacts with the typelibs only

 That means that the old cruft we collected in PyGTK will only
 be cruft there and not upstream. For future modules we'll use the
 more 'dynamic' bindings as available in pybank.


 About the xml format... What is the advantage of having the c library
 meta data stored in xml format instead of s-expressions? The .defs
 files used for Python bindings are very succinct in comparison to the
 ugly .xml files GIR brings to the table. Writing and updating
 s-expressions is much easier than xml.


 There were a couple of reasons to switching to xml over s-expressions.
 The primary one is that XML is more popular, most modern languages
 have parsers builtin which will make it easier to write tools upon it.
 Other reasons includes that xml is more flexible.

 The GIR XML is meant to be processed  modified by tools, not human beings.


The VAPI format from the Vala project is a nice human-writeable format that
should soon be convertable to GIR (currently can be converted to GIDL).

Example:
public class Gtk.Label : Gtk.Misc {
  public void get(out text);
  ...
}



  And presumably, you would still have to hand-write large parts of the
 bindings using something analogous to PyGTK's overrides. I can't think
 of any automagic that would turn this C function:

  void gtk_label_get (GtkLabel *label, char **text);


 We solve that by adding annotations in the gtk-doc comment.
 The specific case you mentioned will have something like this:

 /**
  * gtk_label_get
  * @label: the label
  * @text: (out): the text of the label
  */

 Which will in turn be create the following XML snippet:
 parameter name=text direction=out
  type name=string/
 /parameter

 The idea is to annotate most of the available API so almost the complete
 bindings can done without manually overriding parts.

 Johan

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

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

Re: GObject-Introspection

[Murray Cumming]

On Mon, 2008-09-01 at 16:33 +0200, Johan Dahlin wrote:
 There were a couple of reasons to switching to xml over s-expressions.
 The primary one is that XML is more popular, most modern languages
 have parsers builtin which will make it easier to write tools upon it.
 Other reasons includes that xml is more flexible.

As someone who is struggling with nested quotes and braces in gtkmm's
perl-based .defs parser, I am glad that the future offers XML. Thanks.

 The GIR XML is meant to be processed  modified by tools, not human beings.
 
  And presumably, you would still have to hand-write large parts of the
  bindings using something analogous to PyGTK's overrides. I can't think
  of any automagic that would turn this C function:
  
void gtk_label_get (GtkLabel *label, char **text);
 
 We solve that by adding annotations in the gtk-doc comment.
 The specific case you mentioned will have something like this:
   
 /**
   * gtk_label_get
   * @label: the label
   * @text: (out): the text of the label
   */
 
 Which will in turn be create the following XML snippet:
 parameter name=text direction=out
type name=string/
 /parameter
 
 The idea is to annotate most of the available API so almost the complete 
 bindings can done without manually overriding parts.

As I've told Johan, this won't be possible for significant amounts of
the API, because human thought really is required to make truly usable
APIs. And I worry that the auto-generation will create bad API that will
be declared stable and unbreakable without a maintainer ever even
looking at it.

But we won't have this problem with gtkmm because we hand-define the API
that should exist and only generate the intermediate _implementation_.

-- 
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

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

Re: GObject-Introspection

[Johan Dahlin]

Murray Cumming wrote:

On Mon, 2008-09-01 at 16:33 +0200, Johan Dahlin wrote:

[..]

As I've told Johan, this won't be possible for significant amounts of
the API, because human thought really is required to make truly usable
APIs. And I worry that the auto-generation will create bad API that will
be declared stable and unbreakable without a maintainer ever even
looking at it.


PyGTK has used that concept quite successfully for a long time.

But nevertheless, it's up to the bindings to decide what they are going to 
do with the information. If someone wants to write a completely automated
binding they should be free to do so. However, I expect most bindings to 
have small or large parts of manually written APIs on top of the one 
exported in the GIR/typelib.


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

Re: GObject-Introspection

[Colin Walters]

On Mon, Sep 1, 2008 at 11:18 AM, Murray Cumming [EMAIL PROTECTED] wrote:

 As I've told Johan, this won't be possible for significant amounts of
 the API, because human thought really is required to make truly usable
 APIs. And I worry that the auto-generation will create bad API that will
 be declared stable and unbreakable without a maintainer ever even
 looking at it.

Nothing prevents a binding maintainer from continuing to use a totally
hand-coded approach on top of G-I, or a hybrid.  As Johan said, I
think the most practical approach is going to be to expose the
autogenerated API without modification, but *also* have auxiliary
libraries which fix up some APIs to be nicer, or integrate with other
libraries in one's platform.

Personally though, I fairly strongly believe that the GObject world is
simply too big now for individual language bindings to completely hand
code on top of.  Long ago we thought GObject would just be for GTK+,
and GTK+, while huge, is not unmanageable for a small team of
volunteer contributors.

But that was then; today, we have a full virtual filesystem (Gio),
database APIs (libgda), HTTP (libsoup), GPS location (libgypsy),
next-generation UI frameworks (HippoCanvas, Clutter, GooCanvas...),
multicast DNS (avahi), multimedia (GStreamer), etc.  Maybe gtkmm can
get away with it for C++ since it has C compatibility, but for
everyone else, it's too big.

Even if you disagree though, with G-I we can centralize all the
currently duplicated work that binding maintainers do, and by having
the metadata generation included in the indivdual libraries, we will
encourage C authors to create bindable APIs and write metadata from
the start, which will help everyone.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject-Introspection

[Michael Lawrence]

On Sun, Jun 1, 2008 at 8:00 AM, Johan Dahlin [EMAIL PROTECTED] wrote:

 This mail is long overdue, but I finally got my act together and started to
 prepare for an initial release.


[snip]



 == GIR XML Format ==

 The core of the GObject-introspection is an XML format which is called GIR
 (
 GObject Introspection Repository) which contains the API introspection
 metadata for a library or interface entity.

 GIR currently contains three different XML namespaces:
  - core
contains features available in popular programming languages,
classes, methods, functions, interfaces, properties, strings,
enums etc.
  - c
contains features specific to the C language:
identifiers, symbol names, C types
  - glib
contains features specific to GLib/GObject:
signal, GType, flags, paramspec,

 The separation of different data in different namespaces allow you
 to reuse it allows you to arbitrarily extend the metadata available
 in different languages.


I've noticed that the Typelib is missing an attribute for the API version,
that is, something similar to the since in gtk-doc. My guess is the GIR
format is missing that, as well. I think it would be useful to track the
version at which each symbol was introduced, so that language bindings, for
example, can build against multiple versions of a library.

Also, an indication of whether a function has variadic arguments would be
useful. I can't find that in the typelib, as far as I've looked.

Thanks for picking up this project and doing a great job,
Michael
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject-Introspection

[Johan Dahlin]

Yevgen Muntyan wrote:
 Hi there,
 
 On Jun 1, 2008, at 10:00 , Johan Dahlin wrote:
 
 [gobject introspection stuff]
 
 Too bad gobject-introspection depends on python-2.5. Is
 it going to be a dependency only for gobject-introspection
 itself, or is it going to be a dependency for projects
 which use gobject-introspection, i.e. will a user need
 python-2.5 to build a foobar package which happens to provide
 or use introspection data?

I chosed to depend on python 2.5 because that was available on
my machine and I wanted to focus on writing code instead of writing 
something which runs on all possible setups.

However, it might make sense to make it run on python 2.4, which should
not be too difficult, patches are definitely welcome and if nobody submits 
one I might do the work myself in the future.

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

Re: GObject-Introspection

[Johan Dahlin]

Havoc Pennington wrote:
 Hi,
 
 On Sun, Jun 1, 2008 at 11:53 AM, Yevgen Muntyan [EMAIL PROTECTED] wrote:
 Too bad gobject-introspection depends on python-2.5. Is
 it going to be a dependency only for gobject-introspection
 itself, or is it going to be a dependency for projects
 which use gobject-introspection, i.e. will a user need
 python-2.5 to build a foobar package which happens to provide
 or use introspection data?

This will at most, be a build time dependency.

 Depends on where a project hooks in which is sort of an interesting
 question in itself.
 
 AIUI the pipeline to use say GTK via g-i is:
 
 1) Scan GTK Source, output gir to common gir-repository module

Just to make this clearm, this is mostly short-term. Once we have a couple 
of users and enough stability we will start pushing it upstream.

 2) Merge any custom annotations shared among all language bindings and
 kept in gir-repository (adding accessors, marking memory management
 rules, etc.)

While important, this is also temporary. And should eventually move
upstream as well.

 3) Merge any per-language-binding custom annotations (e.g. hacks to
 keep back compat with old binding versions, or whatever)
 4) Generate binary typelib
 5) At runtime, language binding depends on binary typelib

Most languages will also depend on the C library to access the typelib.
I believe writing bindings for a C based library is far easier than
rewriting the whole library for each language. I would not be surprised 
though if we see at least some LB doing just that.

 What this implies right now, due to 3), is that we have separate
 binary typelibs for each language binding which results in the
 language bindings needing to run a Python merge-thingy themselves, I
 think.
 
 However, that's clearly not ideal... we would really want common
 binary typelibs used by everyone. So I guess step 3) needs fixing.
 Which would leave language bindings depending only on the binary
 typelib and the C lib used to read it, and not depending on Python at
 all during their build. In fact if the typelibs are arch-independent
 they could in theory just be distributed prebuilt with gir-repository.
 Not sure if they are.

An alternative here is make a clean break, eg only use this in new
language bindings and make the typelib/GIR define the API.

For Python I plan to;
* Convert PyGTK .defs to .xml, still keep them locally
* Find out the changes between the .gir in gir-repository/upstream and
   apply fixes/patches on top of them
* Write a new module, eg pybank which interacts with the typelibs only

That means that the old cruft we collected in PyGTK will only
be cruft there and not upstream. For future modules we'll use the
more 'dynamic' bindings as available in pybank.

 The question I can't figure out right now is how to do merging or
 custom stuff on the binary level. The way the binary typelib format
 works, merging is practically impossible. Because if you say iterate
 over all functions in a class, that is just walking through a
 fixed-size mmap'd array. To be able to merge a new function from
 another, separate binary typelib would be a major project it seems
 like, or worse, throw away the efficiency win of the shared mmap()
 approach.

I haven't been paying too much attention to the typelib recently, as my 
bandwidth is just enough for me to keep working on the scanner/GIT format 
for now. I hope someone motivated can jump in here and start updating and 
extending the typelib.

One thing I thought about was using a proper binary tree in the typelib,
where it would be possible to define your new set of nodes you can
add at any level. I'm not sure about the performance implications for that 
though. (Similar to Quicktime/MPEG4 ISO format)

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

Re: GObject-Introspection

[Yevgen Muntyan]

Hi there,

On Jun 1, 2008, at 10:00 , Johan Dahlin wrote:

 [gobject introspection stuff]

Too bad gobject-introspection depends on python-2.5. Is
it going to be a dependency only for gobject-introspection
itself, or is it going to be a dependency for projects
which use gobject-introspection, i.e. will a user need
python-2.5 to build a foobar package which happens to provide
or use introspection data?

Best regards,
Yevgen

P.S. Python-2.5 is not old, it's about a year old and I
don't have it on this machine, where I am running gtk
from trunk. It might be old enough for folks who do python,
but not for everybody ;)

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

Re: GObject-Introspection

[Curtis Hovey]

On Sun, 2008-06-01 at 10:53 -0500, Yevgen Muntyan wrote:
 Hi there,

 On Jun 1, 2008, at 10:00 , Johan Dahlin wrote:

 [gobject introspection stuff]

 Too bad gobject-introspection depends on python-2.5. Is
 it going to be a dependency only for gobject-introspection
 itself, or is it going to be a dependency for projects
 which use gobject-introspection, i.e. will a user need
 python-2.5 to build a foobar package which happens to provide
 or use introspection data?

 Best regards,
 Yevgen

 P.S. Python-2.5 is not old, it's about a year old and I
 don't have it on this machine, where I am running gtk
 from trunk. It might be old enough for folks who do python,
 but not for everybody ;)

Python 2.4 is not supported. 2.5 is the 18 months old and is the stable
version to be developing to. Versions 2.6 and 3.0 will be released in
September of this year.

-- 

__C U R T I S  C.  H O V E Y___
Guilty of stealing everything I am.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject-Introspection

[Yevgen Muntyan]

On Jun 1, 2008, at 11:09 , Curtis Hovey wrote:

 On Sun, 2008-06-01 at 10:53 -0500, Yevgen Muntyan wrote:
 Hi there,

 On Jun 1, 2008, at 10:00 , Johan Dahlin wrote:

 [gobject introspection stuff]

 Too bad gobject-introspection depends on python-2.5. Is
 it going to be a dependency only for gobject-introspection
 itself, or is it going to be a dependency for projects
 which use gobject-introspection, i.e. will a user need
 python-2.5 to build a foobar package which happens to provide
 or use introspection data?

 Best regards,
 Yevgen

 P.S. Python-2.5 is not old, it's about a year old and I
 don't have it on this machine, where I am running gtk
 from trunk. It might be old enough for folks who do python,
 but not for everybody ;)

 Python 2.4 is not supported. 2.5 is the 18 months old and is the  
 stable
 version to be developing to. Versions 2.6 and 3.0 will be released in
 September of this year.

And C99 is the current C standard... I mean, what python
maintainers say is one thing (they still make security
releases for 2.3 and 2.4, no?), and what's installed is
another thing. Question is whether it's okay to ignore
older systems, especially when newest python is needed
only for its new syntax. If the answer is yes, fine,
new python is fun and all that. I just was surprised by
that, because e.g. pygtk, a python package, still supports
python-2.4.

Best regards,
Yevgen

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