Re: [Gimp-developer] Why doesn't --enable-debug turn off optimization?
On Thursday 15 April 2010 18:56:53 Omari Stephens wrote: > It seems like running configure with --enable-debug should also disable > optimization; otherwise you end up with a bunch of magically inlined or > optimized-out function calls, optimized-out variables, and confusing > execution order. Shouldn't whoever says --enable-debug be able to say -O0 as well? Otherwise it might be harder to pin down erratic behaviour to the compiler. Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why doesn't --enable-debug turn off optimization?
Zitat von "Omari Stephens" : > It seems like running configure with --enable-debug should also disable > optimization; otherwise you end up with a bunch of magically inlined or > optimized-out function calls, optimized-out variables, and confusing > execution order. > > Thoughts? [...] AFAIK gcc inlines starting with -O3 and higher. I'm not sure what happens with optimizations with less than -O3, but maybe the result is not that extremely chaotic. Completely disabling optimizations would make sure that debugging might be possible easily. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Why doesn't --enable-debug turn off optimization?
It seems like running configure with --enable-debug should also disable optimization; otherwise you end up with a bunch of magically inlined or optimized-out function calls, optimized-out variables, and confusing execution order. Thoughts? --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser (Sven Neumann): Python plugin defaults accessible
On Mon, 2010-04-12 at 23:20 +0200, Avgoustinos Kadis wrote: > Thanks Sven, very important to know that! > How feasible are these options? > > 1. Randomly pick a value for each parameter. From what you said (that > it depends a lot on the parameters) this wont give us the best results > but at least we will have a preview. > > 2. Modify PDB so it can store default parameters and enter their > values in the plug-ins (maintained in one place only)? Sven wrote: The latter is the only reasonable solution and it has been on the TODO for quite a while already. But IMO it goes way beyond the scope of a GSoC project. Lloyd responds: If the GSoC project was just to be a proof of concept, then you could get the defaults for a subset of plugins, namely some Python plugins, as follows: 1) make the patch to pygimp that allows Gimp to reimport plugins (small patch proposed earlier on this list, search under "gimp_env_init".) 2) Python pseudo code snippet: for each python plugin filename in the standard directories: __import__( filename ) for procname in gimpfu._registered_plugins_.keys() params = gimpfu._registered_plugins_[procname][8] for param in params: default = param[3] In other words, reimporting a plugin sometimes calls its register() which creates a "private" structure in gimpfu that gives the registration parameters, including the defaults (and a range of reasonable values for some types of parameters.) Sometimes means: unless the call to register() is guarded by if __name__ = "__main__" !!! The call to register() is a declaration: the convention should be that it NOT be guarded. The call to register() doesn't interact with Gimp. (This is more discussion about the proposed patch.) Not the way you would ultimately want to have defaults accessible, but it might help enable a transition to a more general solution. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New on this list... how to start juming into Gimp-dvelopment?
Oliver Bandel (oli...@first.in-berlin.de) wrote: > I'm new on the developer list. Welcome. > I would like to help in pushing into the direction of overcoming the > 8-Bit limitation. Also interesting would be for me to have more > knowledge on the plugin-stuff; I had already written some little > Python-plugins, but to know more about that would be fine I also > think about implementing a foreign language interface for OCaml. For the 8-bit limitation the important keyword is GEGL, which is the project we want to base on for higher bit depths. Pippin is the person in the know there. > At the moment I'm using Ubuntu and used the "apt-get source gimp" to > download the sources of the current Gimp on my distribution. I looked > for the necessary tools, which were not all installed. So then I > installed them. I suspect this is not the current gimp source you're getting there. For development you really need to look at the stuff in the git repository. Of importance are the three git repositories babl / gegl / gimp, which need to be built and installed (in your own prefix, not (!) parallel to the system installed babl/gegl/gimp versions). For gtk+ and glib development code the system stuff *might* be too old, we have debian testing as a rule-of-thumb of the versions we depend on. A lot of other information is available at http://developer.gimp.org/faq.html and the surrounding pages. Probably does not answer *all* questions but hopefully enables a start. > It looks like a lot of code... It is. But it is IMHO really good code... :) If you drop by in #gimp on irc.gimp.org (aka gimpnet) ask questions (and wait patiently, it is not really a real-time-response channel) a lot of questions could be answered "live" if you manage to catch the right persons (which is not too hard if you ask specific questions). Hope this helps, Simon (aka nomis in IRC) -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Python
Am Donnerstag, 15. April 2010 11:33:42 schrieb Tor Lillqvist: > > It seems that you're talking Windows in this case. ;-) > > > > Frankly, it is a very bad thing when applications include a script > > language engine in their distribution that then is installed somewhere in > > a non- standard place on the platform. > > But what is the "standard" place for Python on Windows? And are you > sure that some version of OpenOffice.org for instance even would work > with whatever Python version the python.org people currently consider > "standard"? All Python distributions I know of handle the place where they are installed via the Windows registry, i.e. any application can test whether python is installed or not (and where) by simply querying the registry. Now, if Python comes bundled with an applicaton, this registration is not made (which is good in the first place, since it is not Python that gets installed but another application). For the time being I haven't had any problems with Gimp and Blender using a system-wide installation of Python and even upgrading Python without touching the applications worked flawlessly - but then it maybe just working for me... > On systems with package management and svendor package repositories > that *do* offer standard packages of everything imagineable in the > FLOSS worls, the situation is quite different of course. Windows has its dreaded registry which should be used for these purposes since the "standard" place for installing stuff can be chosen freely by the user. I admit that with some underlying libraries like Gtk+ there *can* be a problem when installing system-wide versions. However, when using the registry, it should be possible to even have several (and incompatible) versions of said libraries installed (since both, version information and path to the library can be registered). Anyway, if people decide to include Python in Gimp for Windows it is fine with me, but I would still think of it as an extremely suboptimal solution - not for the usability of Gimp, but more in view of securing and maintaining the system itself which already is a pain in places where it hurts most. Torsten signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Python
On Thursday, April 15, 2010, 2:26:42, Michael Hansen wrote: > And my second question: If this is really the case, will > establishing Python support be simplified in future (by embedding > native support for Python scripts)? GIMP 2.8 will optionally include Python and PyGTK+ on Windows. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > Spend sufficient time in confirming the need and the need will disappear. -- Peter's Prognosis ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Python
> It seems that you're talking Windows in this case. ;-) > Frankly, it is a very bad thing when applications include a script language > engine in their distribution that then is installed somewhere in a non- > standard place on the platform. But what is the "standard" place for Python on Windows? And are you sure that some version of OpenOffice.org for instance even would work with whatever Python version the python.org people currently consider "standard"? On systems with package management and svendor package repositories that *do* offer standard packages of everything imagineable in the FLOSS worls, the situation is quite different of course. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] New on this list... how to start juming into Gimp-dvelopment?
Hello, I'm new on the developer list. I like to look for possibilities where I can help in the Gimp-development. I'm using Gimp since about 1 1/2 years, starting with Rolf Steinort's nice video tutorials. Gimp has helped me solving some picture enhancements in the emantime, but it also has some limitations. Here I want to help. I would like to help in pushing into the direction of overcoming the 8-Bit limitation. Also interesting would be for me to have more knowledge on the plugin-stuff; I had already written some little Python-plugins, but to know more about that would be fine I also think about implementing a foreign language interface for OCaml. But I should start with some small steps I think. I have just looked into some *.c files, but rather unsystematically. At the moment I'm using Ubuntu and used the "apt-get source gimp" to download the sources of the current Gimp on my distribution. I looked for the necessary tools, which were not all installed. So then I installed them. And at the GEGL-part I encountered other problems: there is a library babl, which is already installed, but seems to be out of date. I got the sources, but the mentioned confiugure-script was not there. I tried other ways, but did not get it compiled, and so I did not got something Gimpy to play with. So no easy start jumping into Gimp was possible. What would you recommend as a setup for the develeopment? Are there already scripts for the Gimp-developers that just can be used? For example: maybe there is a bunch of scripts that invoke svn update's and maybe also installation of the stuff that is used to develop the software (automatically compiling all the libraries in local directuries)? Any ideas on what stuff can be done at the begin, without influencing other parts of the current development? Starting with svn conflicts would be not that good, IMHO. Also I'm looking for an overview on the whole source and the way the software is organized. It looks like a lot of code... Also maybe it would make sense to go to developer meetings? I'm located in Berlin. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Python
On Thu, Apr 15, 2010 at 11:28 AM, Torsten Neuer wrote: > Am Donnerstag, 15. April 2010 02:26:42 schrieb Michael Hansen: >> And my second question: If this is really the case, will establishing >> Python support be simplified in future (by embedding native support for >> Python scripts)? OpenOffice or the newest version of Blender already come >> with all necessary files to use Python scripts for example, without the >> need to install all that stuff. > > It seems that you're talking Windows in this case. ;-) > > Frankly, it is a very bad thing when applications include a script language > engine in their distribution that then is installed somewhere in a non- > standard place on the platform. This is windows we are talking about here. Nothing that isn't provided by MS$ has a standard place in the OS. Its nature deems that for your things to work you need to provide all your own dependencies. And yes, that means potentially 6 copies of python, GTK or any other dependency. It is regrettable, but treating windows like a Unix system is just as wrong. Windows is not a version fixed and built as one environment. What works for one app does not have to work for another because they can have totally incompatible versions. There was a time when applications did not package their own GTK. It was a pain in the ass to figure out why gimp install broke pidgin. Yes, it bloats windows, but it ensures that apps run OK for those that lack the skills to resolve conflicts. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Python
Am Donnerstag, 15. April 2010 02:26:42 schrieb Michael Hansen: > I read this tutorial: > http://www.gimpusers.com/tutorials/install-python-for-gimp-2-6-windows.html > > "Today, most GIMP scripts/helpers/extensions are written using Python > instead of the outdated SCHEME (known as Script-Fu). This allows a lot of > great possibilities, but at the moment the installation of GIMP-Python for > Windows requires a few steps." > My first question is: Is it true, that Python scripts are the future, while > Script-Fu is outdated? Python has got several advantages over Script-Fu, but saying that Script-Fu is outdated does not mean that support for Script-Fu will vanish from one day to another. > And my second question: If this is really the case, will establishing > Python support be simplified in future (by embedding native support for > Python scripts)? OpenOffice or the newest version of Blender already come > with all necessary files to use Python scripts for example, without the > need to install all that stuff. It seems that you're talking Windows in this case. ;-) Frankly, it is a very bad thing when applications include a script language engine in their distribution that then is installed somewhere in a non- standard place on the platform. Why ? For several reasons: * there might be security issues with this engine - and you would then have to update several packages instead of just one * you fill up your hard drive with the same programs over and over * you cannot use the language as a general purpose script engine on the platform (or it is at least very hard to do so) when it is included in another programs distribution * ... (there is more, but these are the most important reasons not to include a language in a program distribution) So, if someone was to ask me, I would stringly discourage including python in the Gimp distribution for Windows. A better approach would be to check the dependency on that engine, see if it is installed and then (download and) install it automatically in a standard place if necessary. just my 2cc Torsten signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [PATCH] fix build when objdir and source dir are different
Attached. Seems pretty straightforward.
--xsdg
>From 75abc6e31331137c643d09ac4db7b508a4406327 Mon Sep 17 00:00:00 2001
From: Omari Stephens
Date: Thu, 15 Apr 2010 06:56:23 +
Subject: [PATCH] Fix build in case where objdir and srcdir differ
The build currently doesn't work when the build dir is distinct from
the source dir. This small change fixes that and the build completes
successfully.
Example case where this is true:
$ cd gimpsrc/
$ mkdir builddir
$ cd builddir/
$ ../autogen.sh
$ make
In this case, the (cd) on line 168 of the Makefile will do:
cd ../../../plug-ins/pygimp/
At which point calling ${PYGTK_CODEGEN} will fail because of the
argument:
--register ../../../plug-ins/pygimp/gimpcolor-types.def
Because we already cd into that directory, we can get rid of the
extra path specification and we're golden.
---
plug-ins/pygimp/Makefile.am |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/plug-ins/pygimp/Makefile.am b/plug-ins/pygimp/Makefile.am
index 59194bc..f6625e6 100644
--- a/plug-ins/pygimp/Makefile.am
+++ b/plug-ins/pygimp/Makefile.am
@@ -170,8 +170,8 @@ CLEANFILES = gimpui.c gimpthumb.c
--override $*.override \
--register $(PYGTK_DEFSDIR)/gdk-types.defs \
--register $(PYGTK_DEFSDIR)/gtk-types.defs \
- --register $(srcdir)/gimpcolor-types.defs \
- --register $(srcdir)/gimpenums-types.defs \
+ --register ./gimpcolor-types.defs \
+ --register ./gimpenums-types.defs \
--prefix $* $*.defs) > gen-$*.c \
&& cp gen-$*.c $*.c \
&& rm -f gen-$*.c
--
1.7.0.4
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
