$opmacros_h is something from the new_template.c file from an older
version of MathMap. You probably have an old new_template.c lying
around either in /usr/share/gimp/2.0/mathmap or ~/.gimp/2.?/mathmap,
probably the latter. MathMap will try both directories, first the one
in your home, then the global one, and will take whichever file it
finds first, so if you have, for example, the old files in your home
and the new ones in the global directory, MathMap will still take the
old ones. I should probably just remove looking up in the home
directory and insist that everything is installed globally instead.
Mark
--
Mark Probst
http://www.complang.tuwien.ac.at/schani/
http://www.flickr.com/photos/schani/
http://schani.wordpress.com/
Great, now it works.
I'm a bit disappointed that only the user values from the first filter
show up in the "User values" tab. Or did I miss something?
Thanks !
Seb
That shouldn't happen. Three things that might be the reason: First,
the Composer will generate code for the filter that's focussed (light
blue, as opposed to dark blue). You can focus a filter just by
clicking on it (well, on its blue part). Second, you should probably
hit "Preview" before going to the User Values tab if you've changed
the filter. Third, only the filters that are actually connected to
the focussed filter make it into the code. You can have a hundred
different filters floating around in the composer, but if the focussed
filter is not connected to any of them, you're not going to see their
user values. And why should you - they couldn't make any difference
anyway.
Did that help?
With your advice, it worked. I may now need to "unroll" all the
filters I have to benefit from this approach, but I can see that it
makes sense.
Thanks !
Seb
Thanks for all your work on MathMap, it's quite fantastic!!
On Sat, Jan 12, 2008 at 06:08:09PM -0800, mark....@gmail.com wrote:
> I'm happy to announce the release of MathMap 1.3.1, which offers the
> following new features:
>
> * The MathMap Composer, which allows combining filters in a
> graphical user interface similar to Yahoo Pipes and Quartz
> Composer.
> * New and improved filters.
> * Bugfixes.
Also a memory leak! For example, if I render an animation to a 1024^2
image, mathmap is using 3.1g by frame 7 ... even with something that's
all virtual pixels:
http://loki.aceldama.com/stuff/mathmap-leak.png
I have been going crazy (uh, still crazy) with the fractals, and once
this memory leak is gone I hope to see the end of this animation:
http://loki.aceldama.com/stuff/hm.gif
I left it calculating overnight and woke up to find I had been visited
by the oom_killer!
I have attached an 'hg diff' in case you would like to consider some
minor changes, like allowing up to 360 frames (e.g. so rotations can
be done in 1 degree increments) and using SMP for the final render,
not just the preview! (Yes mathmap leaks even without the compiler
optimizations in my patch)
Cheers,
Tom
--
-- Tom Rathborne to...@aceldama.com http://www.aceldama.com/~tomr/
Thinking you know something is a sure way to blind yourself.
-- Frank Herbert, "Chapterhouse: Dune"
> Also a memory leak! For example, if I render an animation to a 1024^2
> image, mathmap is using 3.1g by frame 7 ... even with something that's
> all virtual pixels:
> http://loki.aceldama.com/stuff/mathmap-leak.png
Thanks for the report!
Does this happen with any filter or only with a specific one? If it's
the latter, could you please post the filter code?
> I have been going crazy (uh, still crazy) with the fractals, and once
> this memory leak is gone I hope to see the end of this animation:
> http://loki.aceldama.com/stuff/hm.gif
Crazy stuff!
> I have attached an 'hg diff' in case you would like to consider some
> minor changes, like allowing up to 360 frames (e.g. so rotations can
> be done in 1 degree increments) and using SMP for the final render,
> not just the preview! (Yes mathmap leaks even without the compiler
> optimizations in my patch)
I'm not sure SMP can safely be turned on for the final render. The
reason is that the GIMP API functions for getting pixels out of the
GIMP drawable might not be thread safe, and several helper functions
in the plug-in that are the interface between the compiled filter and
those functions most certainly aren't. I'll have to look into that.
Have you done timing measurements between using just "-O2" and the
flags you've turned on?
Mark
On Wed, Jan 23, 2008 at 09:43:21PM +0100, Mark Probst wrote:
> > Also a memory leak! For example, if I render an animation to a
> > 1024^2 image, mathmap is using 3.1g by frame 7 ... even with
> > something that's all virtual pixels:
> > http://loki.aceldama.com/stuff/mathmap-leak.png
>
> Thanks for the report!
>
> Does this happen with any filter or only with a specific one? If
> it's the latter, could you please post the filter code?
Yes, even with simple renderers, like Darts Board. (Not even sure why
that was animated, but it was!) With optimizations down to:
-O2 -m64 -march=core2
and no SMP on the final render, I still have this problem.
I'm using GIMP-2.4-SVN.
What I would really like to see is MathMap expressions as a GEGL
filter, so that GIMP can have MathMap "Filter Layers". :)
> > I have been going crazy (uh, still crazy) with the fractals, and once
> > this memory leak is gone I hope to see the end of this animation:
> > http://loki.aceldama.com/stuff/hm.gif
>
> Crazy stuff!
If the usual Mandelbrot set is M(circle-radius-2), this is
M(M(M(M(M(circle-radius-2)*8)*8)*8)*8)
with the rotation and zoom animated.
Some more recent stuff is at:
http://loki.aceldama.com/stuff/mf/
(AVI and PNG are from UltraFractal, actually)
The MathMap language is way more useful than the FRACTINT derivatives
that things like UltraFractal use ... I like being able to colour each
pixel based on any variable in the final state of the fractal machine.
zp9 is an interesting case - given an input image with 10 frames of
horse animation in the top 1/3 and a background, it makes a Zoetrope
loop which animates the horse running in front of the moving flags as
the fractal animates. Since nobody has a zoetrope, I made an animated
GIF version. I seem to have misplaced that exact expression, but I've
attached a similar one. Interpretation is an exercise left to the
reader, I can barely read it now ... guess I should comment my
expressions a little better :)
> > I have attached an 'hg diff' in case you would like to consider
> > some minor changes, like allowing up to 360 frames (e.g. so
> > rotations can be done in 1 degree increments) and using SMP for
> > the final render, not just the preview! (Yes mathmap leaks even
> > without the compiler optimizations in my patch)
>
> I'm not sure SMP can safely be turned on for the final render. The
> reason is that the GIMP API functions for getting pixels out of the
> GIMP drawable might not be thread safe, and several helper functions
> in the plug-in that are the interface between the compiled filter
> and those functions most certainly aren't. I'll have to look into
> that.
Ok, that makes sense! Since my fractals don't use the input image,
they're ok ... but anything that samples the image is automatically
full of race conditions, so GIMP kills mathmap when it gets a TILE_ACK
at the wrong time.
Now it all makes sense!
> Have you done timing measurements between using just "-O2" and the
> flags you've turned on?
No, but I will do that soon ... I think '-m64 -march=core2' is
appropriate for my Intel E6850, and the rest was just things that
sounded helpful from the GCC manpage. :)
Tom
--
-- Tom Rathborne to...@aceldama.com http://www.aceldama.com/~tomr/
Pereant, inquit, qui ante nos nostra dixerunt. -- Aelius Donatus
On Wed, Jan 23, 2008 at 09:43:21PM +0100, Mark Probst wrote:
> I'm not sure SMP can safely be turned on for the final render. The
> reason is that the GIMP API functions for getting pixels out of the
> GIMP drawable might not be thread safe, and several helper functions
> in the plug-in that are the interface between the compiled filter
> and those functions most certainly aren't. I'll have to look into
> that.
Come to irc.gimp.org #gimp sometime :)
pippin is the main gegl developer.
pippin> mathmap should probably be ported to be a gegl node
pippin> as a gegl node, the multithreaded ness or whatever would be
the gegl cores responsibility, that isn't solved yet, but that
is mainly because no time has been spent on it at all
pippin> writing simple C based plug-ins as well is designed to be quite
easy for those that know basic C
I'd like to see the GIMP layer stack replaced by something like the
Composer, but more treelike, so MathMap and other pixel or
computational images can be mixed.
Cheers,
Tom
--
-- Tom Rathborne to...@aceldama.com http://www.aceldama.com/~tomr/
Try to find the real tense of the report you are reading: Was it done, is
it being done, or is something to be done? Reports are now written in four
tenses: past tense, present tense, future tense, and pretense. Watch for
novel uses of CONGRAM (CONtractor GRAMmar), defined by the imperfect past,
the insufficient present, and the absolutely perfect future. -- Amrom Katz
Sure ... I have reverted my changes, done 'hg pull' and 'hg update'
and now 'hg status' says nothing ... and symbols are missing:
gcc -o mathmap mathmap_common.o builtins.o exprtree.o parser.o scanner.o vars.o tags.o tuples.o internals.o macros.o userval.o overload.o jump.o noise.o spec_func.o compiler.o bitvector.o expression_db.o drawable.o designer/designer.o designer/cycles.o designer/widget.o designer/loadsave.o designer_filter.o mathmap_cmdline.o getopt.o getopt1.o generators/blender/blender.o mathmap.o rwimg/librwimg.a lispreader/liblispreader.a `gimptool-2.0 --libs` `pkg-config --libs gmodule-2.0 gthread-2.0 gtksourceview-1.0 libgnomecanvas-2.0` -lm -lgsl -lgslcblas -ljpeg -lpng -lgif
designer/widget.o: In function `designer_widget_node_aux_load_callback':
/home/tomr/play/math/mathmap/designer/widget.c:1030: undefined reference to `lisp_proplist_lookup_symbol'
... lots of other missing lisp_.*
Where is that lisp stuff supposed to come from??
Tom
--
-- Tom Rathborne to...@aceldama.com http://www.aceldama.com/~tomr/
Oh right. I forgot that this is actually multiple hg checkouts.
Back after lunch!
Thanks,
Tom
--
-- Tom Rathborne to...@aceldama.com http://www.aceldama.com/~tomr/
I've always felt that a person's intelligence is directly reflected by
the number of conflicting points of view he can entertain
simultaneously on the same topic. -- Abigail Adams
I just did a couple of animations, with the normal compile settings
and with my '-O3 -march=core2' optimizations. Also turned on
multithreading and did a mandelbrot+enhanced_pond, no problem.
So ... don't worry about that bug, if I see it again I promise to
track it down myself! :)
Tom
--
-- Tom Rathborne to...@aceldama.com http://www.aceldama.com/~tomr/
The best way to have a good idea
is to have a lot of ideas
and throw the bad ones away. -- Linus Pauling