RSS/Atom feed Twitter
Site is read-only, email is disabled

Major brokerage on PDB introspection

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

Major brokerage on PDB introspection Joao S. O. Bueno 13 May 21:58
  Major brokerage on PDB introspection Michael Natterer 14 May 23:50
Joao S. O. Bueno
2011-05-13 21:58:22 UTC (over 13 years ago)

Major brokerage on PDB introspection

Hi,

If we run this tiny fu expression on gimp 2.6 (gimp-procedural-db-proc-arg "gimp-layer-get-name" 0), we get: (16 "drawable" "The drawable")

on gimp master, we are getting (0 "item" "The item") - actually, we are getting "0" back for any parameter derived of gimp-item. This completly breaks PDB parameter introspection. Languuage bindings - including the python bindings depend on this to correctly return the correct GIMP_PDB_* constant to work.
(scheme works because it treats all GIMP objects as an integer (by their IDs) and has no type checking)

Can someone find-out what broke this? Maybe it is a use case for the famous "git bisect" thing - but I don't have a setup to try that.

Regards,

js ->

Michael Natterer
2011-05-14 23:50:10 UTC (over 13 years ago)

Major brokerage on PDB introspection

On Fri, 2011-05-13 at 17:58 -0400, Joao S. O. Bueno wrote:

Hi,

If we run this tiny fu expression on gimp 2.6 (gimp-procedural-db-proc-arg "gimp-layer-get-name" 0), we get: (16 "drawable" "The drawable")

on gimp master, we are getting (0 "item" "The item") - actually, we are getting "0" back for any parameter derived of gimp-item. This completly breaks PDB parameter introspection. Languuage bindings - including the python bindings depend on this to correctly return the correct GIMP_PDB_* constant to work.
(scheme works because it treats all GIMP objects as an integer (by their IDs) and has no type checking)

Can someone find-out what broke this? Maybe it is a use case for the famous "git bisect" thing - but I don't have a setup to try that.

Maybe it's a use case for simply looking at the code that returns the wrong value :)

Fixed in master.

--mitch