ANNOUNCEMENT: MathMap 1.3.1

39 views
Skip to first unread message

mark....@gmail.com

unread,
Jan 12, 2008, 9:08:09 PM1/12/08
to MathMap
Dear MathMap users,

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.

You can download it from the MathMap homepage or from one of the links
below.

The MathMap homepage can be found at

http://www.complang.tuwien.ac.at/schani/mathmap/

Binaries for several Linux distributions are available here:

http://download.opensuse.org/repositories/home:/mark_probst/

The source package can be downloaded here:

http://www.complang.tuwien.ac.at/schani/mathmap/files/mathmap-1.3.1.tar.gz

For instructions on how to get the absolutely latest MathMap sources
via Mercurial, read this:

http://www.complang.tuwien.ac.at/schani/mathmap/README.mercurial

Mark

Seb Perez-D

unread,
Jan 13, 2008, 2:54:57 PM1/13/08
to MathMap
On Jan 13, 3:08 am, mark.pro...@gmail.com wrote:

> I'm happy to announce the release of MathMap 1.3.1

I compiled 1.3.1 for Ubuntu 7.04, x86_64. When executing Mathmap, it
opens fine, but trying to preview gives a compiles error:

gcc -O2 -c -fPIC -o /tmp/mathfunc11952_1.o /tmp/mathfunc11952_1.c
/tmp/mathfunc11952_1.c:48:23: error: $opmacros_h: No such file or
directory
/tmp/mathfunc11952_1.c:150: error: expected specifier-qualifier-list
before 'image_t'
/tmp/mathfunc11952_1.c: In function 'calc_lines':
/tmp/mathfunc11952_1.c:376: error: 'xy_const_vars_t' has no member
named 'tmp_2_1'
/tmp/mathfunc11952_1.c:376: error: 'xy_const_vars_t' has no member
named 'tmp_7_1'
/tmp/mathfunc11952_1.c:376: warning: assignment makes pointer from
integer without a cast
/tmp/mathfunc11952_1.c: In function 'init_frame':
/tmp/mathfunc11952_1.c:427: error: 'xy_const_vars_t' has no member
named 'tmp_2_1'
/tmp/mathfunc11952_1.c:428: error: 'xy_const_vars_t' has no member
named 'tmp_7_1'

Also, the dialog box in Gimp says that there is an interpreter
available... which isn't the case in the 1.3 branch.

Cheers,

Seb

Mark Probst

unread,
Jan 13, 2008, 3:02:47 PM1/13/08
to mat...@googlegroups.com
On Jan 13, 2008 8:54 PM, Seb Perez-D <sbp...@gmail.com> wrote:
> gcc -O2 -c -fPIC -o /tmp/mathfunc11952_1.o /tmp/mathfunc11952_1.c
> /tmp/mathfunc11952_1.c:48:23: error: $opmacros_h: No such file or
> directory

$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/

Sebastien Perez-Duarte

unread,
Jan 13, 2008, 3:26:42 PM1/13/08
to mat...@googlegroups.com
On Jan 13, 2008 9:02 PM, Mark Probst <mark....@gmail.com> wrote:
>
> 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.

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

Mark Probst

unread,
Jan 13, 2008, 3:32:55 PM1/13/08
to mat...@googlegroups.com
On Jan 13, 2008 9:26 PM, Sebastien Perez-Duarte <sbp...@gmail.com> wrote:
> 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?

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?

Sebastien Perez-Duarte

unread,
Jan 13, 2008, 3:43:07 PM1/13/08
to mat...@googlegroups.com
On Jan 13, 2008 9:32 PM, Mark Probst <mark....@gmail.com> wrote:
> That shouldn't happen.

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

Tom Rathborne

unread,
Jan 23, 2008, 12:49:42 PM1/23/08
to mat...@googlegroups.com
Hi Mark,

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"

mathmap.patch

Mark Probst

unread,
Jan 23, 2008, 3:43:21 PM1/23/08
to mat...@googlegroups.com
Hey Tom,

> 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

Tom Rathborne

unread,
Jan 23, 2008, 4:36:06 PM1/23/08
to mat...@googlegroups.com
Hi 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

Pereant, inquit, qui ante nos nostra dixerunt. -- Aelius Donatus

zoetrope-20-slice-double-animation.mm

Tom Rathborne

unread,
Jan 23, 2008, 4:56:58 PM1/23/08
to mat...@googlegroups.com
Mark,

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 :)

http://www.gegl.org/

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

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

mark....@gmail.com

unread,
Feb 13, 2008, 11:21:03 AM2/13/08
to MathMap
Hi Tom!

> 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 haven't been able to reproduce this bug. Could you please provide
me with every detail (input image, filter you're using, exact
settings) to reproduce this? Or could you please confirm that the bug
is not in Mercurial MathMap anymore (though I have no idea what should
have fixed it)?

Thanks!

Mark

Tom Rathborne

unread,
Feb 13, 2008, 12:02:29 PM2/13/08
to mat...@googlegroups.com
Hi Mark!

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

mark....@gmail.com

unread,
Feb 13, 2008, 12:04:58 PM2/13/08
to MathMap
On Feb 13, 6:02 pm, Tom Rathborne <tom.rathbo...@gmail.com> wrote:
> /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??

You'll need to update lispreader (in the "lispreader" dir) as well.

Mark

Tom Rathborne

unread,
Feb 13, 2008, 12:15:30 PM2/13/08
to mat...@googlegroups.com

Oh right. I forgot that this is actually multiple hg checkouts.
Back after lunch!

Thanks,

Tom

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

Tom Rathborne

unread,
Feb 13, 2008, 3:22:29 PM2/13/08
to mat...@googlegroups.com
Hi Mark,

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

The best way to have a good idea
is to have a lot of ideas
and throw the bad ones away. -- Linus Pauling

Reply all
Reply to author
Forward
0 new messages