[metapost] Trying to figure out MPLib

Taco Hoekwater taco at elvenkind.com
Sun Aug 5 14:51:59 CEST 2012


Hi all,

Yesterday, I wrote:
>
> PS I've just spend most of  today writing a function called
> mp_solve_path() and the stuff around it. It seems to work OK, but I
> now need to write documentation and I have done enough for today. ;)

And here it is. I've tried to do the minimal amount of work on my side
for now, which means there is some work needed to get the attached
source to run.

First, and most importantly, the archive has a patch file for mp.w
in metapost 1.212 that needs to be applied before building libmplib.a.
If you have the 'patch' program, then

	<top>/metapost-1.212$ patch -p0 < ~/mppath-demo/mp.w.patch

should do the trick. Otherwise, you'll have to apply the fixes by hand.
There is nothing interesting in the patch, it just removes some 'static'
classifiers from a few needed functions.

Then build libmplib.a, and copy libmplib.a, mplib.h, mpmp.h, and
mplibps.h to the mppath-demo folder.

 From there, 'make' builds the simple test application 'test'.

Other files in the archive:

   mppath-demo/Makefile
	-- a simple makefile
   mppath-demo/fixkpse.c
	-- corrects libmplib.a linkage, as posted earlier
   mppath-demo/mppath.h
	-- header for the functions in mppath.c, including documentation
   mppath-demo/mppath.c
	-- internals, containing quite a bit of black magic you should
	not look at too closely
   mppath-demo/test.c
	-- the demo app	

The sources test.c and mppath.h together should make clear how it all
works, but just in case, here are some pitfalls and remarks:

* current MPlib does not like values >= abs(4096.0).

* tensions should no be less than abs(0.75)

* mp_knot lists have to be circular, so if you forget to close the
   path with either mp_final_knotpair or mp_cycle_knotpair, the solve
   function will fail.

* the mp_set_knot*_* functions should be called only after two knots
   are already connected via mp_final_knotpair or mp_cycle_knotpair,
   otherwise the internal connections become messy.
   This is the main reason for mp_append_knot(), which is just a chain
   of mp_creat_knot, mp_set_knot, mp_final_knotpair.

* mp_solve_path changes the path in-situ. Right now, this involves
   some copying and black magic, but once the code moves to the core
   mplib, that part becomes simpler (and therefore faster).

* struct mp_knot is currently defined in mplibps.h. This (and its
   internals) will change in mplib 2, but I did not want to write
   accessor functions right now, because even that API is not
   finalized yet.

* error discovery is a boolean value right now, but eventually in
   mplib 2 there will be a way to query the exact error.

In principe, all the functions in mppath.h (except possibly for
mp_dump_path) will become part of the official API starting with mplib
2, but the maximum value limits may change.

OTOH, none of the implementation stuff in mppath.c will become part of 
the API.

Have fun,
Taco




-------------- next part --------------
A non-text attachment was scrubbed...
Name: mppath-demo.tar.gz
Type: application/x-gzip
Size: 5027 bytes
Desc: not available
URL: <http://tug.org/pipermail/metapost/attachments/20120805/cac7c5f1/attachment.gz>


More information about the metapost mailing list