|
From: Andrea R. <ari...@pi...> - 2004-01-29 18:13:50
|
Thanks for your answer Andre. I've already written a new .info file for 0.5.1 version, I'll try to=20 get extension modules on this evening and I'll submit the new package=20 as soon as possible. Nevertheless I'm not a Fink's core developer and=20 I'm not allowed to update the Fink's tree itself, so we have to wait=20 for someone to accept the new package; sometime it take quite a long=20 time. Regarding PyX project I was very pleased reading your answer. I=20 completely agree with you, there is place for PyX and people using=20 Python for scientific purpose will enjoy a complete and coherent=20 framework to produce both figures and plots. I'm working with=20 Python+Gnuplot during these days to produce some high-quality plots and=20= I absolutely miss a tool like PyX will become. My main interest, at the moment, is focused toward 2-dim plots=20 (contours and density plots), and I'll be happy to contribute to PyX in=20= this topic. Could it be useful? Unfortunately I'm not a skilled programmer (actually I'm only a "number=20= cruncher" ;-P), and I'll need to study hard before being able to=20 contribute to PyX code. I hope to be ready soon. Cheers, Andrea. On 28 Jan 2004, at 01:45, Andre Wobst wrote: > Hi Andrea, > > On 27.01.04, Andrea Riciputi wrote: >> 1) I don't understand well what "C extension module" exactly are. Are >> they C version of some cpu intensive task? > > In general it depends on the purpose of the extension module. They > might be needed to speed up certain tasks. Another possibility is to > make use of some existing C code or providing python bindings to an > existing library. > > In PyX there are two extension modules. The first is a python binding > to the libkpathsea library for fast directory structure searching > issues. Once this library is initialized, the TeX/LaTeX/Font related > searches becomes extremly fast compared to the fallback solution of > running the kpathsea programm for each lookup (depending on the > TeX/LaTeX path configuration in texmf.cnf the latter can be quite > expensive). The second extension module t1strip reuses some code from > pdftex for reducing font sizes by skipping unneeded glyphs. Since it > reduces the output file size, it is quite nice to have. > >> 2) How can I decide whether I want to activate them or not? > > I strongly encourgage you to turn them on. In order to get the > libkpathsea extension module compiled, you have to uncomment the > build_ext lines. You should fill in > include_dirs=3D/sw/include > library_dirs=3D/sw/lib > You should then be able to compile the extension modules. I'm a happy > fink user nowadays (thanks to you and all the other maintainers for > the great work!) and I hadn't had any problems in doing so. Please > drop a note, if you get into troubles. > >> Last questions are much more related to my personal use of PyX. I've >> looked at PyX source code and (even if I'm not a skilled programmer)=20= >> it >> seems very promising. AFAICU PyX is at the moment a tool very similar >> to METAPOST, with the big difference that it has a high level=20 >> interface >> (Python) and a much more modern design. > > ... and it is written in the same language as used by the users. I > mean, for METAFONT/METAPOST you might need to deal with WEB in order > to implement some new basic (builtin) functionality. > >> In the (I hope) near future you >> have the intention to add many plotting capabilities to PyX (actually >> some of them are already there) resulting in something like Biggles >> (http://biggles.sourceforge.net/), but much more evoluted. So, at the >> very last, PyX will be a very powerful tool with which we can do=20 >> figure >> __and__ data plots, I mean METAPOST + (something like) Biggles >> together. > > It was our intention from the very beginning to build a drawing *and* > plotting library directly usable within an existing language with low > overhead (instead of building an own language). It is quite important > to have *one* tool for both tasks, drawing and plotting, since you can > then always mix those tasks if you are in need of. We (e.g. J=F6rg, > Gert, I myself) were users of gle (glx.sf.net) quite some time ago, > which was able to do both tasks as well. Unfortunately gle was really > buggy and bad designed (it doesn't make much sense to try to improve > it, I think). It didn't use TeX for text processing (it tried to > emulate TeX in some limited fashion ;-); once I wrote a extension for > gle doing some hidden external real TeX processing, which was usable, > but still totally ugly). At some point (after looking for alternatives > including METAPOST) we decided to start with the PyX project. Although > this was back in 2000 (our original discussions about a tool like PyX > might be even a bit older), I think there is still a place for PyX. > Other available software seems to not have filled this place we want > PyX to be. > >> 3) Am I wrong? If I'm right, do you have any project plan? I mean, do >> you have any idea about how long the entire path will take? > > In terms of some major design issues the 0.5 was a very important > step. While the basic infra structure for the attribute handling is > now in place and seems to work well, we still have to go thru all the > code and make use of it. (For example the graph module is currently > not using the new merging technique.) And I want to clean up the boxes > (box module) and make them the basic clipping technique. These tasks > are my major gool for 0.6. I will try hard to make a release of 0.6 > end of February already. > > I'm not sure how much the graph styles can be cleaned up in this > release already. It is quite important, because after that cleanup > further style implementations etc. should be possible from outside. > Before this cleanup it is difficult to work on the graph except for > the axes (which I consider ok compared to the rest). The timeaxis > (probably using the great dateutil modules by Gustavo Niemeyer) are a > long standing goal for me ... and could in principle be done right > away ... > > Other things are pdf and svg support. Both should be possible and I > would like to see them happen within the next year or so. I would like > to see if the PyX design can be applied to other output formats. It > should be (we kept it in mind for a long time already). For example > one could start in making the fonts available for svg. Search for > tubt1svg in google ... and start right away and implement something in > python ... ;-) > >> 4) Can we (I mean we =3D users) contribute to the project? And how? > > One possiblility (the usual way) is to implement something you need > yourself. You can than try to implemtent it "the PyX way". Decorators > which wriggle a given path for example. I would really like to see > those things. In case you have just no idea what to implement, ask and > tell us some preferences. I'm sure we can give some hints where you > could start ... > > > Andr=E9 > > --=20 > by _ _ _ Dr. Andr=E9 Wobst > / \ \ / ) wo...@us..., http://www.wobsta.de/ > / _ \ \/\/ / PyX - High quality PostScript figures with Python &=20= > TeX > (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Pyx-devel mailing list > Pyx...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel > > --- Andrea Riciputi "Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it" -- (Richard Feynman) --- Andrea Riciputi "Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it" -- (Richard Feynman) |