[MetaTeX] libmpost status update

Taco Hoekwater taco at elvenkind.com
Wed Jul 14 13:20:59 CEST 2004


Below follows a repost of a message that I originally sent to the ntg-context list.

Improvements since 28 juni are:

> - C strings instead of a string pool ( and no pool file).

Everything that coud be done easily is now done. Internally, there still is
a 'string pool', but  that is used exclusively to shuffle user-supplied strings
around, to be precise:

	(1) The storage for value(X) where token X is of type 'string'
	(2) The value of cur_exp while manipulating string-valued expressions.

> - A "struct METAPOST" instance that gets moved around, instead of global variables

This is more or less finished. All functions that needed global variables in the original,
 now have a header line like
	
	void mp_print_initialize (MP mp);

Where an MP is of type:

	typedef struct METAPOST *MP;

and the structure has fields for all of the previously global variables (as well as some
new ones). What remains to be done is changing zillions of locations where the code
now uses #define's to access these varables. 

	#define buffer mp->buffer_field

but this is low priority since the current code works OK.

> - A namespace for all externally visible procedures and enums (prefix 'mp')

Done

> - mp_initialize() and mp_finish() calls to allow clean restarts.

Almost done. 

There is initalization via	  MP mp_mpost_new (void)
or                                      MP mp_mpost_load (FILE *memfile)
And the main function is             mp_mpost_main (MP instance)

but mp_finish() still needs splitting off.

> - All file I/O will be configurable (through callbacks)

on a very very low level, this is now complete, but the
situation is still far from ideal (if interested, read mp-03-io.c).
More on this subject later.

> - PostScript output will be isolated from the other output. (to allow other
>   output backends in the future).

All printing to the PostScript file(s) is now unified in one routine:
	mp_ps_printf()
but the opening and closing of files still needs cleanup, and the
main shipout procedure still has to be parameterised to allow
switching to another output style.

Other progress / remarks:
---------------------------------

- The C source is now in CVS on http://www.sarovar.org.
   It desperately needs debugging at the GDB level. lots of it.

- All non-ps printing uses a unified mp_printf() frontend 
  except in a few code locations where this is impossible
  (there it uses stdlib i/o)

- overflow() is only called for the "hash size" and "main memory" arrays,
   and a few locations in the tfm writer. 
   * The tfm section needs careful cleanup because I suspect some of the 
     overflows are in fact bound by TFM file format instead of MP array sizes.
   * hash size is on the todo list (I need to find a way to enlarge the hash
     without trashing old values, and some static allocs need to be moved out
     of the way)
   * memory size is hard to fix because mem[] grows from the two sides inwards.
   
  all other buffers and arrays are (should be) reallocated dynamically.

Greetings, Taco

-------------
Subject: Extending metapost
Date: Mon, 28 Jun 2004 10:40:35 +0200

I saw this passing by in another thread, and since I am myself currently working
on a C port of metapost:

> (and ... i also want to look into extending tex and metapost)

What kind of extensions to metapost do you (or anyone else) have in mind?

Progress update: 

Work on the C port of MP is coming along nicely. Work progress is fairly slow 
because I have to make change quite a lot of small changes to the code.
I expect to have a 'working' test executable in about 3 or 4 weeks.

libMP will have (at least) the following changes wrt. the Web source code:

- C strings instead of a string pool ( and no pool file).
- A "struct METAPOST" instance that gets moved around, instead of global variables
  (libMP will be thread-safe)
- A namespace for all externally visible procedures and enums (prefix 'mp')
- mp_initialize() and mp_finish() calls to allow clean restarts.
- All file I/O will be configurable (through callbacks)
- PostScript output will be isolated from the other output. (to allow other
  output backends in the future).



-- 
groeten,

Taco


More information about the Metatex mailing list