The MetaPost team is happy to announce a new release of MetaPost:
----------------------------------------------------------------------
MetaPost 1.004
----------------------------------------------------------------------
The sources and a win32 package can be downloaded immediately from
http://foundry.supelec.fr/projects/metapost/
This release will also be available from CTAN soon, and it will be
included in the next TeXLive. The source package should compile normally
on all systems that are capable of compiling a modern web2c-based TeX
distribution.
The win32 package is intended for texlive or a similar web2c-based
installation, and has been tested only with TeXLive 2007. These
executables will *not* work for miktex, sorry.
Of course, we welcome any comments (either good or bad) that you may
have. Simply replying to this message is fine, but see the bottom of
the message for a more formal way to report bugs and feature requests.
----------------------------------------------------------------------
What is new in version 1.004:
----------------------------------------------------------------------
* The picture color component commands misbehaved in 1.003:
the current (default) colormodel was not taken into consideration,
so all colors had to be explicit for "redpart" etc. to work.
(this bug is the one broke the graph.mp package)
In 1.004 for "defaulted" colors, the suitable value in the current
(default) colormodel is returned without any errors. This change
also reverts to silently defaulting a 'black' color when asking
for the redpart etc. of an object that cannot be colored at all.
* The picture color component commands misbehaved in 1.003 in
a different manner also: the defaults for uninitialized CMYK
color picture parts were still assuming 'black' was defined as
(1,1,1,1) instead of as (0,0,0,1).
* The macro Gwithpc_ in the graph.mp package did not work properly
with non-rgb colormodel objects.
* plain.mp has a new macro, 'colorpart', that returns the color
parts of a graphical object within a picture in a form suitable
for feeding it back to 'withcolor'.
* The latest kpathsea library from TeXLive is included.
* There is now a separate manual for the boxes package (mpboxes.pdf).
----------------------------------------------------------------------
Legal notice / license / bug reports
----------------------------------------------------------------------
MetaPost is a system for producing graphics developed by John Hobby
at AT&T, based on Donald Knuth's Metafont. The MetaPost home page
is http://tug.org/metapost.
MetaPost and related programs are in the public domain.
The MetaPost development project is currently hosted at Supelec,
https://foundry.supelec.fr/projects/metapost; please report bugs and
request enhancements through there if possible. Alternatively, you
can reach us through the
On May 1, 2008, at 11:24 AM, Taco Hoekwater wrote:
The MetaPost team is happy to announce a new release of MetaPost:
---------------------------------------------------------------------- MetaPost 1.004 ----------------------------------------------------------------------
The sources and a win32 package can be downloaded immediately from
http://foundry.supelec.fr/projects/metapost/
This release will also be available from CTAN soon, and it will be included in the next TeXLive. The source package should compile normally on all systems that are capable of compiling a modern web2c-based TeX distribution.
Hi Taco, I have two questions/problems with the new release: 1. for my linux box, I just grabbed the linux tarball, but the binaries in there still declare they're version 1.003. Is that an oversight, or are those indeed old binaries (and you forgot to pack the new ones? :-) 2. On OS X 10.5 (intel), compilation aborts with this message: creating Makefile creating doc/Makefile creating lib/Makefile creating man/Makefile creating mpware/Makefile creating mpdir/Makefile creating web2c/Makefile creating window/Makefile cat: ../../../src/texk/web2c/window/Makefile.in: No such file or directory creating fmtutil.cnf creating c-auto.h gcc -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/web2c -I../.. - I../../../../src/texk/web2c/.. -I.. -I../../../../src/texk/web2c/ web2c/.. -g -O2 -c ../../../../src/texk/web2c/web2c/kps.c In file included from ../../../../src/texk/web2c/../kpathsea/config.h: 78, from ../../../../src/texk/web2c/web2c/../config.h:44, from ../../../../src/texk/web2c/web2c/web2c.h:3, from ../../../../src/texk/web2c/web2c/kps.c:26: ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: syntax error before '*' token ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: conflicting types for 'calloc' ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: conflicting types for 'malloc' ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: conflicting types for 'realloc' /usr/include/stdlib.h:176: error: previous declaration of 'realloc' was here ../../../../src/texk/web2c/../kpathsea/c-std.h:57: warning: data definition has no type or storage class ../../../../src/texk/web2c/web2c/kps.c: In function 'uppercasify': ../../../../src/texk/web2c/web2c/kps.c:36: warning: initialization from incompatible pointer type make: *** [kps.o] Error 1 Any pointers? Thomas
On Sat, May 3, 2008 at 8:56 PM, Thomas A. Schmitz
On May 1, 2008, at 11:24 AM, Taco Hoekwater wrote:
The MetaPost team is happy to announce a new release of MetaPost:
---------------------------------------------------------------------- MetaPost 1.004 ----------------------------------------------------------------------
The sources and a win32 package can be downloaded immediately from
http://foundry.supelec.fr/projects/metapost/
This release will also be available from CTAN soon, and it will be included in the next TeXLive. The source package should compile normally on all systems that are capable of compiling a modern web2c-based TeX distribution.
Hi Taco,
I have two questions/problems with the new release:
1. for my linux box, I just grabbed the linux tarball, but the binaries in there still declare they're version 1.003. Is that an oversight, or are those indeed old binaries (and you forgot to pack the new ones? :-)
I have build mpost from src (I always prefer to compile from source) # mpost This is MetaPost, Version 1.004 (Web2C 7.5.5) ** ! End of file on the terminal... why? -- luigi it's new . it's powerful . it's luatex . http://www.luatex.org
On Sat, May 03 2008, luigi scarso wrote:
1. for my linux box, I just grabbed the linux tarball, but the binaries in there still declare they're version 1.003. Is that an oversight, or are those indeed old binaries (and you forgot to pack the new ones? :-)
# mpost This is MetaPost, Version 1.004 (Web2C 7.5.5)
That means some redundancy in the code: the version number is maintained at two places ("mpost" and "mpost --version"). Cheers, Peter -- http://pmrb.free.fr/contact/
On Sun, May 4, 2008 at 7:46 AM, Peter Münster
On Sat, May 03 2008, luigi scarso wrote:
1. for my linux box, I just grabbed the linux tarball, but the binaries in there still declare they're version 1.003. Is that an oversight, or are those indeed old binaries (and you forgot to pack the new ones? :-)
# mpost This is MetaPost, Version 1.004 (Web2C 7.5.5)
That means some redundancy in the code: the version number is maintained at two places ("mpost" and "mpost --version").
root@luigicasa-laptop:/opt/luatex/metapost-1.004# grep -r 1.004 src src/texk/web2c/mp.web:@d banner=='This is MetaPost, Version 1.004' {printed when \MP\ starts} src/texk/web2c/mp.web:@d metapost_version=="1.004" root@luigicasa-laptop:/opt/luatex/metapost-1.004# grep -r 1.003 src src/texk/web2c/lib/texmfmp.c:#define BANNER "This is MetaPost, Version 1.003" -- luigi it's new . it's powerful . it's luatex . http://www.luatex.org
Thomas A. Schmitz wrote:
I have two questions/problems with the new release:
1. for my linux box, I just grabbed the linux tarball, but the binaries in there still declare they're version 1.003. Is that an oversight, or are those indeed old binaries (and you forgot to pack the new ones? :-)
Answered by Peter and Luigi. I 've fixed the repository versions of texmfmp.c, and will probably update the tarballs tomorrow (I also have to add that mpboxes.pdf)
2. On OS X 10.5 (intel), compilation aborts with this message:
This is the same problem Hans van der Meer ran into with MPlib a while back. Somehow configure fails to notice that OS X 10.5 has standard C headers just like any other Unix. If you look at the configure output, it will say somewhere in the middle: checking for ANSI C header files... no The build error is a result of that. Hans van der Meer came up with the following answer (but I have *no* idea how to implement):
Eureka! I think I found it (took a lot of experimentation).
Playing with the optimizing options through CFLAGS and setting the architecture to the G4 status of my Mac Powerbook, miraculously Metafont1.002 did compile under MacOSX10.5. Experimentally I then established that the architecture should be specified on the gcc call in order to have the proper ANSI headers found; without these compilation will get stuck.
The options that I think relevant are (both CFLAGS and CXXFLAGS should be set):
1. general architecture specification: CFLAGS -arch ppc (for powerpc) CFLAGS -arch ppc64 (for the new 64bit binaries on powerpc) CFLAGS -arch i386 (for intel) I did not check the ppc64 (not needed) and i386 (not having one) options.
2. more specific architecture specification affecting instruction set and scheduling if one wants to tune the generated code to ones processor: CFLAGS -mcpu=G4 (-mcpu=G5 etc. whichever ones machine has)
It would be most natural, I think, if the -arch switch is added standard through the autoconf scripts. Taco could see to that for metapost and luatex, I trust. Can someone mail this experience to the maintainers of pdftex? (I could not ascertain why pdftex compiles without problems).
Hans van der Meer
Best wishes, Taco
On Sun, May 4, 2008 at 10:38 AM, Taco Hoekwater wrote:
Thomas A. Schmitz wrote:
1. general architecture specification: CFLAGS -arch ppc (for powerpc) CFLAGS -arch ppc64 (for the new 64bit binaries on powerpc) CFLAGS -arch i386 (for intel) I did not check the ppc64 (not needed) and i386 (not having one) options.
2. more specific architecture specification affecting instruction set and scheduling if one wants to tune the generated code to ones processor: CFLAGS -mcpu=G4 (-mcpu=G5 etc. whichever ones machine has)
It would be most natural, I think, if the -arch switch is added standard through the autoconf scripts. Taco could see to that for metapost and luatex, I trust. Can someone mail this experience to the maintainers of pdftex? (I could not ascertain why pdftex compiles without problems).
I might be missing the point, but I would be glad if -arch would not be set automatically if there is some better solution. Now it's really easy to cross-compile metapost, pdfTeX and LuaTeX for ppc on intel. If configure script would set the -arch unconditionally, then I would probably run into problems. But again - I might be misunderstanding the problem. Mojca
On May 4, 2008, at 10:38 AM, Taco Hoekwater wrote:
Thomas A. Schmitz wrote:
I have two questions/problems with the new release:
1. for my linux box, I just grabbed the linux tarball, but the binaries in there still declare they're version 1.003. Is that an oversight, or are those indeed old binaries (and you forgot to pack the new ones? :-)
Answered by Peter and Luigi. I 've fixed the repository versions of texmfmp.c, and will probably update the tarballs tomorrow (I also have to add that mpboxes.pdf)
Thanks, Taco.
2. On OS X 10.5 (intel), compilation aborts with this message:
This is the same problem Hans van der Meer ran into with MPlib a while back. Somehow configure fails to notice that OS X 10.5 has standard C headers just like any other Unix.
If you look at the configure output, it will say somewhere in the middle:
checking for ANSI C header files... no
The build error is a result of that. Hans van der Meer came up with the following answer (but I have *no* idea how to implement):
Eureka! I think I found it (took a lot of experimentation).
Playing with the optimizing options through CFLAGS and setting the architecture to the G4 status of my Mac Powerbook, miraculously Metafont1.002 did compile under MacOSX10.5. Experimentally I then established that the architecture should be specified on the gcc call in order to have the proper ANSI headers found; without these compilation will get stuck.
The options that I think relevant are (both CFLAGS and CXXFLAGS should be set):
1. general architecture specification: CFLAGS -arch ppc (for powerpc) CFLAGS -arch ppc64 (for the new 64bit binaries on powerpc) CFLAGS -arch i386 (for intel) I did not check the ppc64 (not needed) and i386 (not having one) options.
2. more specific architecture specification affecting instruction set and scheduling if one wants to tune the generated code to ones processor: CFLAGS -mcpu=G4 (-mcpu=G5 etc. whichever ones machine has)
It would be most natural, I think, if the -arch switch is added standard through the autoconf scripts. Taco could see to that for metapost and luatex, I trust. Can someone mail this experience to the maintainers of pdftex? (I could not ascertain why pdftex compiles without problems).
Hans van der Meer
Best wishes, Taco
Thanks again. I simply issued export CFLAGS="-arch i386" and could compile without problems. Thanks, and best wishes Thomas
Hi Thomas, Can you please replace the c-std.h in src/texk/kpathsea with the attached one and see if that helps? The one I am distributing with metapost is slightly different from the one in tl, and we need to exclude differences that from the list of causes (either that, or we found the cause) Best wishes, Taco Thomas A. Schmitz wrote:
Hi Taco,
I have two questions/problems with the new release:
1. for my linux box, I just grabbed the linux tarball, but the binaries in there still declare they're version 1.003. Is that an oversight, or are those indeed old binaries (and you forgot to pack the new ones? :-)
2. On OS X 10.5 (intel), compilation aborts with this message:
creating Makefile creating doc/Makefile creating lib/Makefile creating man/Makefile creating mpware/Makefile creating mpdir/Makefile creating web2c/Makefile creating window/Makefile cat: ../../../src/texk/web2c/window/Makefile.in: No such file or directory creating fmtutil.cnf creating c-auto.h gcc -DHAVE_CONFIG_H -I. -I../../../../src/texk/web2c/web2c -I../.. - I../../../../src/texk/web2c/.. -I.. -I../../../../src/texk/web2c/ web2c/.. -g -O2 -c ../../../../src/texk/web2c/web2c/kps.c In file included from ../../../../src/texk/web2c/../kpathsea/config.h: 78, from ../../../../src/texk/web2c/web2c/../config.h:44, from ../../../../src/texk/web2c/web2c/web2c.h:3, from ../../../../src/texk/web2c/web2c/kps.c:26: ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: syntax error before '*' token ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: conflicting types for 'calloc' ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: conflicting types for 'malloc' ../../../../src/texk/web2c/../kpathsea/c-std.h:57: error: conflicting types for 'realloc' /usr/include/stdlib.h:176: error: previous declaration of 'realloc' was here ../../../../src/texk/web2c/../kpathsea/c-std.h:57: warning: data definition has no type or storage class ../../../../src/texk/web2c/web2c/kps.c: In function 'uppercasify': ../../../../src/texk/web2c/web2c/kps.c:36: warning: initialization from incompatible pointer type make: *** [kps.o] Error 1
Any pointers?
Thomas ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
/* c-std.h: the first header files.
Copyright 1992, 1993, 1994, 1995, 1996, 1997, 2008 Karl Berry.
Copyright 1999, 2005 Olaf Weber.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License
along with this library; if not, see http://www.gnu.org/licenses/. */
#ifndef KPATHSEA_C_STD_H
#define KPATHSEA_C_STD_H
/* Header files that essentially all of our sources need, and
that all implementations have. We include these first, to help with
NULL being defined multiple times. */
/* Workaround against a
Hi Taco, thanks, will try that, but I'm away from my OS X box till late this afternoon. I will keep you posted! Best Thomas On May 6, 2008, at 8:50 AM, Taco Hoekwater wrote:
Hi Thomas,
Can you please replace the c-std.h in src/texk/kpathsea with the attached one and see if that helps? The one I am distributing with metapost is slightly different from the one in tl, and we need to exclude differences that from the list of causes (either that, or we found the cause)
Best wishes, Taco
Hi Taco, Hi Karl, looks like you nailed it: with the new c-std.h, compilation works without a hitch on my 10.5 box! Best wishes Thomas On May 6, 2008, at 8:50 AM, Taco Hoekwater wrote:
Hi Thomas,
Can you please replace the c-std.h in src/texk/kpathsea with the attached one and see if that helps? The one I am distributing with metapost is slightly different from the one in tl, and we need to exclude differences that from the list of causes (either that, or we found the cause)
Best wishes, Taco
participants (5)
-
luigi scarso -
Mojca Miklavec -
Peter Münster -
Taco Hoekwater -
Thomas A. Schmitz