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
> / \ \ / ) wobsta@..., 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-devel@...
> 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)
|