pyx-devel — PyX development

[PyX-devel] Installing PyX to a non-standard location.

[Andrea R. <ari...@pi...>]

Hi,
I was working to a new Fink package for the new PyX 0.7, when realized 
that the *.lfs files are not found by PyX because are searched in the 
wrong place. After digging a little bit I've found a solution that I 
think is far less than optimal. It consists of a little patch to 
setup.py:

--- PyX-0.7/setup.py.orig       Mon Nov 15 16:30:04 2004
+++ PyX-0.7/setup.py    Tue Nov 16 13:24:08 2004
@@ -41,7 +41,7 @@
  #

  data_files = [# share/pyx is taken relative to "setup.py install 
--home=..."
-              ("share/pyx", ["pyx/lfs/10pt.lfs",
+              ("share/pyx-py@PYTHON_FLAVOR@", ["pyx/lfs/10pt.lfs",
                               "pyx/lfs/11pt.lfs",
                               "pyx/lfs/12pt.lfs",
                               "pyx/lfs/10ptex.lfs",
@@ -53,7 +53,7 @@
                               "pyx/lfs/foils30pt.lfs",
                               "contrib/pyx.def"]),
                # /etc is taken relative to "setup.py install --root=..."
-              ("/etc", ["pyxrc"])]
+              ("@PREFIX@/etc", ["pyxrc"])]

  #
  # pyx_build_py
@@ -95,8 +98,11 @@

      def run(self):
          install_data.run(self)
-        self.pyx_lfsdir = self.pyx_sharedir = 
os.path.join(self.install_dir, "share", "pyx")
-        self.pyx_pyxrc = os.path.join(self.root or "/", "etc", "pyxrc")
+        self.pyx_lfsdir = self.pyx_sharedir = os.path.join("@PREFIX@", 
"share", "pyx-py@PYTHON_FLAVOR@")
+        self.pyx_pyxrc = os.path.join("@PREFIX@", "etc", "pyxrc")

where @PREFIX@ is replaced before install phase by the Fink prefix 
directory (usually /sw).

As far as I can remember Andre uses Fink as well, so I'm wondering if 
he know a better way of getting PyX installed with the right paths 
written in siteconfig.py

I've also read an old thread on PyX-devel (that I missed back on 
April), among Andre, Joerg and Fernando Perez about this topic, but it 
wasn't of much help, perhaps I've missed the point...

Thanks in advance,
   Andrea.

[PyX-devel] [ pyx-Bugs-1065099 ] EPSF 3.0 header is wrong

[SourceForge.net <no...@so...>]

Bugs item #1065099, was opened at 2004-11-12 12:33
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1065099&group_id=45430

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Russell Lang (ghostgum)
Assigned to: Nobody/Anonymous (nobody)
Summary: EPSF 3.0 header is wrong

Initial Comment:
The correct header is
%!PS-Adobe-3.0 EPSF-3.0

The PyX 0.7 hello.eps example
  http://pyx.sourceforge.net/examples/hello.eps
has "EPSF 3.0" not "EPSF-3.0", consequently other 
programs do not recognise it as being EPS.



----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-11-12 15:42

Message:
Logged In: YES 
user_id=405853

Thanks for this report. I've corrected it in the CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1065099&group_id=45430

[PyX-devel] [ pyx-Bugs-1065099 ] EPSF 3.0 header is wrong

[SourceForge.net <no...@so...>]

Bugs item #1065099, was opened at 2004-11-12 22:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1065099&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Lang (ghostgum)
Assigned to: Nobody/Anonymous (nobody)
Summary: EPSF 3.0 header is wrong

Initial Comment:
The correct header is
%!PS-Adobe-3.0 EPSF-3.0

The PyX 0.7 hello.eps example
  http://pyx.sourceforge.net/examples/hello.eps
has "EPSF 3.0" not "EPSF-3.0", consequently other 
programs do not recognise it as being EPS.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1065099&group_id=45430

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx text.py,1.179,1.180

[Andre W. <wo...@us...>]

Hi,

On 26.10.04, Joerg Lehmann wrote:
> AFAIR, every PyX poster has to be run with texmessage.ignoreall, which
> is certainly suboptimal.

Probably that's not true, but don't mind.

> One reason for this is that PyX's parsing
> system for TeX messages is rather opaque, and does not really enable one
> to write specialized message parsers.

I talked to Michael some time ago. He had the very same objections. He
told me, what we should do "instead", but it turned out, that the
current solution already implemented a handling scheme like that. So
the problem might be, that its difficult to read/understand. That's
right.

> But maybe there is no easy
> solution for that because the output of TeX/LaTeX is really a mess.
> Still it might be useful to first tokenize the output. Michael, you once
> suggested that making use of the bracket structure of the output may be
> helpful.

Some parsers already use some braket information. But there are other,
typical but not so easy to parse things like indented information
which looks like that:

xxxxxxxxxxx: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
             xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
             xxxxxxxxxxxxxxxxxxxx

Those things are common in NFSS messages for example. It might be
worse the effort to write some code to handle those messages. But it
can be done by defining some methods and use them in different message
parsers by inheritance. (Like the braket handling for including files,
images ... where "()" or "<>" is used etc.)

But it is clear, that we need to work on this topic. I suggest to
first start with a better removal of empty lines at the end of the
parsing to make the final output left by the parsers to become more
readable (i.e. as they are in TeX/LaTeX). And then we should have a
overful/underful h/v-box handler(s), which just creates a warning ...
should be a starting point. I may discuss this with Michael before
starting.

BTW: I did not yet split a 0.7 branch in CVS. It was common sense to
wait for a few days after a release to see, whether we need to release
a fixed version (0.7.x) quickly after the release. Currently we just
have a tag for the release in CVS (which we still could use for
branching AFAIK but we might want to wait a few days to omit the
necessity to port/backport too many things between different
branches).


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx text.py,1.179,1.180

[Andre W. <wo...@us...>]

Hi,

On 26.10.04, Michael Schindler wrote:
> > Anyway I do *not* like your patch, since it disables important checks
> > to be performed.
> 
> Well then, cast it into the doom of fire ;-)

Right. OTOH the point is, that we try to understand TeX's response
instead of just ignoring it. While this is a complicated task, we have
the chance to properly inform the user, whenever enything goes wrong.
Using text.messageparser.ignore disables that. I know, that it might
be a convenient and fast way to get something running ... but at least
in the long term goal we should be able to do better ...

> The problems occurred in complicated examples when people changing the
> default font for LaTeX and doing complicated things. I will write a
> test/functional/test_textparser.py for more demanding checks in the
> case one uses different font sizes, fontencodings ... (Just to see if
> there is more trouble awaiting)

Right. I would suggest that. And there is hope, that we only need the
TeX responses PyX can't deal with (instead of passing around full and
complicated use cases on the lists) to improve the messageparsers. But
if we want to get a good control of TeX, we need to go that hard way
and try to understand what TeX is talking about and do not just throw
it away. Hopefully people will post there TeX error messages instead
(i.e. additionally to) just using text.texmessage.ignore ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx text.py,1.179,1.180

[Joerg L. <jo...@us...>]

On 26.10.04, Michael Schindler wrote:
> The problems occurred in complicated examples when people changing the
> default font for LaTeX and doing complicated things. I will write a
> test/functional/test_textparser.py for more demanding checks in the
> case one uses different font sizes, fontencodings ... (Just to see if
> there is more trouble awaiting)

AFAIR, every PyX poster has to be run with texmessage.ignoreall, which
is certainly suboptimal. One reason for this is that PyX's parsing
system for TeX messages is rather opaque, and does not really enable one
to write specialized message parsers. But maybe there is no easy
solution for that because the output of TeX/LaTeX is really a mess.
Still it might be useful to first tokenize the output. Michael, you once
suggested that making use of the bracket structure of the output may be
helpful.

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx text.py,1.179,1.180

[Michael S. <m-s...@us...>]

On 26.10.04, Andre Wobst wrote:
> 
> Can't confirm this. You're right: Without your patch you get an error
> for your example. Try yourself on a unpatched 0.7 version ... you
> should be able to produce the error as well.
> 
> Anyway I do *not* like your patch, since it disables important checks
> to be performed.

Well then, cast it into the doom of fire ;-)

> In the end a possibility would be to change the order in which the
> messageparsers are applied to the TeX response. My current question
> is, why I did it in reverse order? I'm sure I did it with some use
> cases in mind. But I might have been wrong with this decision. I
> suggest to change this behaviour and apply the messageparsers in the
> order they are given ... and then we'll see how far we can come with
> that. Any objections? We might also go on and switch to attributes and
> merging here to allow for better user control. When nobody complains I
> would suggest to try that ...

The problems occurred in complicated examples when people changing the
default font for LaTeX and doing complicated things. I will write a
test/functional/test_textparser.py for more demanding checks in the
case one uses different font sizes, fontencodings ... (Just to see if
there is more trouble awaiting)

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx text.py,1.179,1.180

[Andre W. <wo...@us...>]

Hi Michael,

On 25.10.04, Michael Schindler wrote:
> There was a bug in PyX-0.6.3 concerning the texmessageparser, and some
> time ago, I used to help users here in Augsburg with a patched
> version. This bug is documented in the attaches minimal example.
> 
> Today, I was told that the same error had again ocurred, and I
> remembered that I had not checked in my patch. Now, in PyX-0.7 it must
> have been a different problem, that I had no time yet to track down.
> The minimal example does not produce the same error.

Can't confirm this. You're right: Without your patch you get an error
for your example. Try yourself on a unpatched 0.7 version ... you
should be able to produce the error as well.

Anyway I do *not* like your patch, since it disables important checks
to be performed. (And that's why I was against it when I saw your
checkin.) The problem is, that you remove all information by
text.texmessage.ignore and after that the end-of-tex message parser
complains "TeX dvifile messages expected". But that's true ... it
wants to check whether TeX reports about writing the dvifile. It also
checks the number of pages written to the dvifile ... all that becomes
unavailable when you use text.texmessage.ignore, because this will
remove *all* TeX responses. (Note that the texmessage handlers are
applied in reverse order ... so the default parsers are applied last.)

In the end a possibility would be to change the order in which the
messageparsers are applied to the TeX response. My current question
is, why I did it in reverse order? I'm sure I did it with some use
cases in mind. But I might have been wrong with this decision. I
suggest to change this behaviour and apply the messageparsers in the
order they are given ... and then we'll see how far we can come with
that. Any objections? We might also go on and switch to attributes and
merging here to allow for better user control. When nobody complains I
would suggest to try that ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx text.py,1.179,1.180

[Michael S. <m-s...@us...>]

Hi André,

On 25.10.04, Andre Wobst wrote:
> On 25.10.04, Michael Schindler wrote:
> > Update of /cvsroot/pyx/pyx/pyx
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31341
> > 
> > Modified Files:
> > 	text.py 
> > Log Message:
> > texmessage parser has to skip an empty message from LaTeX
> > 
 
> I don't think you need this. Why? I want a use case.

There was a bug in PyX-0.6.3 concerning the texmessageparser, and some
time ago, I used to help users here in Augsburg with a patched
version. This bug is documented in the attaches minimal example.

Today, I was told that the same error had again ocurred, and I
remembered that I had not checked in my patch. Now, in PyX-0.7 it must
have been a different problem, that I had no time yet to track down.
The minimal example does not produce the same error.

sorry for the confusion ...
I will un-do the checkin -- or is it better to use the functionality
of cvs for this?

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

[PyX-devel] Re: [PyX-checkins] pyx/pyx text.py,1.179,1.180

[Andre W. <wo...@us...>]

Hi Michael,

On 25.10.04, Michael Schindler wrote:
> Update of /cvsroot/pyx/pyx/pyx
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31341
> 
> Modified Files:
> 	text.py 
> Log Message:
> texmessage parser has to skip an empty message from LaTeX
> 
> Index: text.py
> ===================================================================
> RCS file: /cvsroot/pyx/pyx/pyx/text.py,v
> retrieving revision 1.179
> retrieving revision 1.180
> diff -C2 -d -r1.179 -r1.180
> *** text.py	19 Oct 2004 14:32:05 -0000	1.179
> --- text.py	25 Oct 2004 14:24:08 -0000	1.180
> ***************
> *** 203,206 ****
> --- 203,210 ----
>   
>       def check(self, texrunner):
> +         # skip when the message is empty (this occurs after LaTeX's message about Font Substitutions)
> +         if not texrunner.texmessageparsed:
> +             return
> + 
>           try:
>               s1, s2 = texrunner.texmessageparsed.split("(%s.aux)" % texrunner.texfilename, 1)

I don't think you need this. Why? I want a use case.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] [ pyx-Bugs-1042458 ] Error with graph.data.list

[SourceForge.net <no...@so...>]

Bugs item #1042458, was opened at 2004-10-07 21:03
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with graph.data.list

Initial Comment:
In graph.data.list(), there are two places where PyX attempts to 
access the builtin list() function as __builtins__.list under certain 
conditions.  This is not correct, since __builtins__ appears as a 
dictionary and has no list attribute, and throws an exception.  

If your _really must_ create a class with the name graph.data.list 
(which, because of the possible conflict with python's built-in list() 
function, especially if someone does 
from graph.data import *
may be a bad idea), it is probably best to, at the top of graph.data, 
do something like

builtin_list=list

class list():...

and then use a=builtin_list(...)

where you currently use __builtins__.list(...)

In general, though, I think it would be even better to rename this 
class to avoid some really mysterious behavior if anyone does do 
an import * from it.

Marcus Mendenhall



----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-10-25 16:55

Message:
Logged In: YES 
user_id=405853

I'm closing this issue, since it has been resolved. The name clash topic 
has also been discussed before. There seems to be no strong arguments 
against reusing some common names.

Just to add some small talk about the name clashes (which are not name 
clashes due to Pythons name spaces): We actually have at least some 
other name clashes in PyX as well. The oldest one I can remember of is 
path.line against graph.style.line (graph.line in former times). When I 
started to work on the graph module, in my first versions I used 
graph.chain for a line connecting style. Jörg strongly argued against that 
naming and so it was changed to line in the early days already. And I'm 
aware of another clash in using the term "style" for stroke and fill styles 
vs. graph styles. Well ... we've decided that people have to learn about it 
beyond the naming ... ;-)

----------------------------------------------------------------------

Comment By: Marcus Mendenhall (mendenhall)
Date: 2004-10-08 14:17

Message:
Logged In: YES 
user_id=470295

I will only twist your arm gently over the data.list naming issue.  I 
almost never import *, since I like using namespaces, so I will probably 
never see the namespace collision.  However, unwary users could get in 
trouble with this.  

Thanks for fixing the problem.  PyX is really a nice package, especially 
as it begins to settle down.

Marcus


----------------------------------------------------------------------

Comment By: André Wobst (wobsta)
Date: 2004-10-08 14:01

Message:
Logged In: YES 
user_id=405853

I've just corrected the bug in the 0.6.x trunk. In CVS head this problem 
does not occur anymore, since the conversion of a sequence into a list is 
not necessary anymore. (Instead the new data handling allows for direct 
mixing of several data sources, which also removes some strange side 
effects.)

Beside that I'm totally aware of the problem of the name "list". The 
name comes out of the following consitency consideration: Creating 
graph data from a file is done by data.file, creating data from out of a 
function is done by data.function, creating data from a different data is 
done by data.data ... so what's the name for creating data from a list of 
points? I thought data.list would be best here ... but feel free to suggest 
a different naming. We could do data.points, but I do not really like it. 
Feel free to convince me or suggest other possibilities. I do not stop at 
those changes currently since I classify PyX to still be in the design 
phase ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

Re: [PyX-devel] Please remove absolute /etc path in PyX setup.py

[Andre W. <wo...@us...>]

Hi Olaf,

On 22.10.04, Ola...@es... wrote:
> I just tried to make an rpm package from PyX 0.7
> under Solaris using
> 
> python setup.py bdist --format rpm
> 
> However, this fails as long as there is an absolute
> /etc in setup.py. It works fine if I make it just "etc".

I think I've done that deliberately. As indicated in setup.py you can
adjust installation directories of the shared data and the global
configuration file independendly by that. And I thought this is quite
usefull and it is a documented behaviour of distutils. However, I do
not understand all the side effects caused by that. So I'm open to any
advice from a distutils expert how to handle this issue. Still, I do
not have troubles in running "python setup.py bdist --format rpm" on
my maschine here up to the point, where it involves the rpm command,
which is not available on my maschine. So what's exactly the problem
with the absolute path and the rpm creation? I just want to understand
whether I'm really doing something wrong in the usage of distutils by
that.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Please remove absolute /etc path in PyX setup.py

[<Ola...@es...>]

Good morning,

I just tried to make an rpm package from PyX 0.7
under Solaris using

python setup.py bdist --format rpm

However, this fails as long as there is an absolute
/etc in setup.py. It works fine if I make it just "etc".

I am using OpenPKG to have rpms under Solaris 2.8.

Otherwise: nice work !!

Regards,

Olaf.

- - -
Olaf Wasmuth,
EDS Deutschland GmbH
Flight Dynamics Support, TOS-GF
European Space Operations Centre
Darmstadt, Germany
Phone: +49 6151 90 (6)2391
Fax: +49 6151 90 (6)3010

[PyX-devel] Announcement: PyX 0.7 released

[Andre W. <wo...@us...>]

Hi,

we are proud to announce the release of PyX 0.7. This release adds
support for inclusion of bitmaps to PyX. Furthermore the path system
has undergone major revision and cleanup. The handling of short path
elements got enhanced considerably to prevent numerical instabilities.
In addition the data and style handling in the graph system was
completely reorganized. In the result is now possible to combine
several graph styles within a single plot instruction.

Find a more detailed list of changes below. Enjoy!


Jörg, André, Michael and Gert


---------

0.7 (2004/10/21):
  - bitmap module:
    - new module for inclusion of bitmap images
  - path module:
    - names of local and member variables now follow the naming convention of
      having a _pt suffix when containing lengths in points
  - bbox module:
    - names of local and member variables now follow the naming convention of
      having a _pt suffix when containing lengths in points
    - enlarge was misspelled as enlarged
    - renamed _bbox -> bbox_pt
    - new bbox method center, which returns the coordinates of the center
      of the bbox
    - enlarge and enlarged do no longer interprete unqualified lengths as
      being of type visual
  - unit module:
    - unit.cm, unit.t_cm, etc. are no longer sub classes but instances
      of length
    - never convert implicitly into visual/width, etc. lengths (this is more
      about usage of the unit module in various other modules) (TODO: update
      documentation)
    - support for string initialization removed
    - support for initialisation with other length removed
    - lengths can now be divided by other lengths (as suggested by Michael Gruber
      and Magnus Lie HHetland)
  - text module:
    - postpone reading of fontmap files until TeX/LaTeX is started
    - sign of font number in dvifile (reported by Michael Gruber)
    - phantom attribute
  - canvas module:
    - added new classes page and document for multipage PostScript output
    - apply deformers (instead of trafos) in draw method
  - style module:
    - decrease interval for dotted and dash-dotted lines for better visual
      appearance
  - setup.py and distribution:
    - create siteconfig on install to store positions of the shared data
      and the global pyxrc
  - graph modules:
    - graph style + data reorganization
      - modularization of the graph styles by separating data handling and drawing tasks
      - several graph styles can now be combined together
      - graph data can internally now combine different data sources
        (by that, some nasty side effects could have been removed)
    - enum -> num renaming
    - allow for horizontally and vertically centered graph key alignment and a key background
    - fix bug that graph was not finished automatically when a bbox was specified
      manually (reported by David Barton)
  - path module:
    - pathel -> pathitem, etc. renaming
    - methods accepting a parameter value / arc length now also allow the user to 
      pass a tuple (subpath, param) / (subpath, arclen)
    - normpath constructor no longer accepts a path or normpath as argument but only a list
      of normsubpaths. Use the new normpath method of the path instead to construct a normpath
      from a path.
    - normsubpath can now deal with short (i.e. shorter than epsilon) segments correctly
    - the intersect and split methods of normpath and normsubpath have been completely rewritten and
      now take the accuracy epsilon correctly into account. Note that for a closed subpath the
      split function now returns the segment containing the closing point as first element
      in the result list (before, it was returned as last element).
    - normsubpathitems and normsubpath now implement much more methods also provided by
      path and normpath instances
    - normpath.append no longer accepts pathitems but only normsubpaths
  - deformer module: new
    - moved cycloid and smoothed from deco into deformer
  - bbox module:
    - handle "BoundingBox: (atend)" (cf. bug #945621 reported by Jim Boyle)
    - kpsearch option to search for file using the kpathsea library (contributed by Michael Gruber)
  - base module:
    - PSCmd and PSOp are now joined in a new class canvasitem
  - deco module: 
    - decorated path no longer allows modification of its path
    - new method excluderange which allows to remove certain parameter ranges from the stroked path
    - additional canvas provided by decorated path is now called ornaments
    - constriction=None now indicates an arrowhead without constriction
  - trafo module:
    - trafos are now deformers
  - examples:
    - a bunch of bargraph examples have been added

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] A problem with axis manual ticks.

[Andre W. <wo...@us...>]

Hi Andrea,

On 19.10.04, Andrea Riciputi wrote:
> The 
> problem arose because the manual says that manual ticks list overtake 
> automatic ticks, maybe a little further explanation (in the manual) 
> should be useful.

Right. But instead of *fixing* the manual I just fixed it in the
source, since I think we should really do it like the manual told it
all the time. The reason is, that the manual way to do it allows you
to remove a tick at a certain position without disableing the
partitioner. That might be useful ...

So thanks for your report, it got fixed for the future.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] A problem with axis manual ticks.

[Andrea R. <ari...@pi...>]

Thanks for your explanation, adding parter=None works as expected. The 
problem arose because the manual says that manual ticks list overtake 
automatic ticks, maybe a little further explanation (in the manual) 
should be useful. However I agree with you that beeing able to mix 
automatic and manual ticks is a nice feature.

Cheers,
   Andrea.

On 19 Oct 2004, at 07:37, Andre Wobst wrote:

> Sure it can. The idea is, that you can just add a few ticks to an
> automatically created ticks. If you want to disable automatically
> created ticks, you just need to set parter=None in the axis
> constructor. Unfortunately, as I've found out now by your example,
> that the manual set ticks do not win against ticks created by the
> parter as it is stated in the manual. The problem is, that merging of
> the ticks is the wrong operation here. I'll just try to correct that
> for the future. But beside that its the intended behavior. Might still
> be worth a discussion, but I think its a nice feature to be able to
> mix ticks which are set manually and which are created automatically.

Re: [PyX-devel] A problem with axis manual ticks.

[Andre W. <wo...@us...>]

Hi,

On 18.10.04, Andrea Riciputi wrote:
> c.insert(pyx.graph.axis.pathaxis(p, pyx.graph.axis.lin(min = 0, max = 
> 1.4, manualticks = myTicks)))
> 
> Very simple example indeed, but look at the resulting eps file (I 
> attach to the email what I get) and especially to the 0.5 tick. It 
> should be a minor tick (as I defined it), but it's major one!
> 
> I've no idea about where the bug could be, nevertheless I hope this can 
> be of any help.

Sure it can. The idea is, that you can just add a few ticks to an
automatically created ticks. If you want to disable automatically
created ticks, you just need to set parter=None in the axis
constructor. Unfortunately, as I've found out now by your example,
that the manual set ticks do not win against ticks created by the
parter as it is stated in the manual. The problem is, that merging of
the ticks is the wrong operation here. I'll just try to correct that
for the future. But beside that its the intended behavior. Might still
be worth a discussion, but I think its a nice feature to be able to
mix ticks which are set manually and which are created automatically.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] A problem with axis manual ticks.

[Andrea R. <ari...@pi...>]

Hi,
I was playing with manual ticks when I've discovered what I think is a 
bug (PyX v0.6.3). Here is a minimal script that exhibits this 
misbehaviour:

import pyx

p = pyx.path.line(0, 0, 4, 0) # I prepare a straight line

# I start to define my own ticks list so that major ticks are
# interleaved with minor ones.

myTicks = [pyx.graph.axis.tick.tick(0., label = "0", labelattrs = 
[pyx.text.mathmode]),
            pyx.graph.axis.tick.tick(0.1, label = "", ticklevel = 1),
            pyx.graph.axis.tick.tick(0.2, label = "0.2", labelattrs = 
[pyx.text.mathmode]),
            pyx.graph.axis.tick.tick(0.3, label = "", ticklevel = 1),
            pyx.graph.axis.tick.tick(0.4, label = "0.4", labelattrs = 
[pyx.text.mathmode]),
            pyx.graph.axis.tick.tick(0.5, label = "", ticklevel = 1),
            pyx.graph.axis.tick.tick(0.6, label = "0.6", labelattrs = 
[pyx.text.mathmode]),
            pyx.graph.axis.tick.tick(0.7, label = "", ticklevel = 1),
            pyx.graph.axis.tick.tick(0.8, label = "0.8", labelattrs = 
[pyx.text.mathmode]),
            pyx.graph.axis.tick.tick(0.9, label = "", ticklevel = 1),
            pyx.graph.axis.tick.tick(1.0, label = "1", labelattrs = 
[pyx.text.mathmode]),
            pyx.graph.axis.tick.tick(1.1, label = "", ticklevel = 1),
            pyx.graph.axis.tick.tick(1.2, label = "1.2", labelattrs = 
[pyx.text.mathmode]),
            pyx.graph.axis.tick.tick(1.3, label = "", ticklevel = 1),
            pyx.graph.axis.tick.tick(1.4, label = "1.4", labelattrs = 
[pyx.text.mathmode]),]

# And now I plot the axis.

c = pyx.canvas.canvas()
c.insert(pyx.graph.axis.pathaxis(p, pyx.graph.axis.lin(min = 0, max = 
1.4, manualticks = myTicks)))
c.writeEPSfile("amelia.eps")

Very simple example indeed, but look at the resulting eps file (I 
attach to the email what I get) and especially to the 0.5 tick. It 
should be a minor tick (as I defined it), but it's major one!

I've no idea about where the bug could be, nevertheless I hope this can 
be of any help.

Cheers,
   Andrea.

Re: [PyX-devel] graph.data.list bug - cause

[Andre W. <wo...@us...>]

Hi,

On 14.10.04, Francisco Borges wrote:
> # everything goes ok, but then if I use a tuple:

Right, this is a poor mans workaround for the moment.

> I googled c.l.py and found Tim Peters explaining that user code should
> never use __builtins__ but the module __builtin__ (no 's' at the end)
> instead.
> 
> http://groups.google.com/groups?hl=en&lr=&threadm=304d20df.0205110931.4ccd39%40posting.google.com&rnum=2&prev=/groups%3Fq%3D__builtins__%26hl%3Den%26lr%3D%26group%3Dcomp.lang.python.*%26selm%3D304d20df.0205110931.4ccd39%2540posting.google.com%26rnum%3D2

That's interesting!

I also patched the 0.6 CVS trunk some times ago, but its unlikely that
we'll have a 0.6.4 release, since I'll try to get 0.7 out this week.
The whole problem of needing a conversion to a list got removed in
this upcoming version and thus a builtins access is not needed
anymore.

Anyway, thanks for your report.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] graph.data.list bug - cause

[Joerg L. <jo...@us...>]

Hello Francisco,

On 14.10.04, Francisco Borges wrote:
[ snip ]
> Well, *NOW* I looked at the devel archives I saw Wobst talking about how
> the CVS has not the problem anymore but perhaps still unaware of what
> actually caused the problem, which is the use of __builtins__ and not
> "import __builtin__", so I'm sending it anyway.

The CVS version of graph.data.list does not longer need to access
the "builtin" list, so this problem does not occur anymore.

Anyway, thanks for the hint,

        Jörg

[PyX-devel] graph.data.list bug - cause

[Francisco B. <bo...@le...>]

Hello,

Look at this (pyx 0.6.3)

from pyx import *

a=graph.data.list([ [i,i**2] for i in range(10)])

# everything goes ok, but then if I use a tuple:

a=graph.data.list([ (i,i**2) for i in range(10)])

I get an AttributeError, more specifically, it happens that 

Traceback (most recent call last):
  File "../src/figs/bug.py", line 17, in ?
    a=graph.data.list([ (i,i**2) for i in range(10)])
  File "/usr/lib/python2.3/site-packages/pyx/graph/data.py", line 137,
  in __init__
    points[i] = [i+1] + __builtins__.list(points[i])
AttributeError: 'dict' object has no attribute 'list'

I googled c.l.py and found Tim Peters explaining that user code should
never use __builtins__ but the module __builtin__ (no 's' at the end)
instead.

http://groups.google.com/groups?hl=en&lr=&threadm=304d20df.0205110931.4ccd39%40posting.google.com&rnum=2&prev=/groups%3Fq%3D__builtins__%26hl%3Den%26lr%3D%26group%3Dcomp.lang.python.*%26selm%3D304d20df.0205110931.4ccd39%2540posting.google.com%26rnum%3D2

and doing the obvious code change does make the problem go away.

Well, *NOW* I looked at the devel archives I saw Wobst talking about how
the CVS has not the problem anymore but perhaps still unaware of what
actually caused the problem, which is the use of __builtins__ and not
"import __builtin__", so I'm sending it anyway.

Cheers,
Francisco.

[PyX-devel] [ pyx-Bugs-1042458 ] Error with graph.data.list

[SourceForge.net <no...@so...>]

Bugs item #1042458, was opened at 2004-10-07 14:03
Message generated for change (Comment added) made by mendenhall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with graph.data.list

Initial Comment:
In graph.data.list(), there are two places where PyX attempts to 
access the builtin list() function as __builtins__.list under certain 
conditions.  This is not correct, since __builtins__ appears as a 
dictionary and has no list attribute, and throws an exception.  

If your _really must_ create a class with the name graph.data.list 
(which, because of the possible conflict with python's built-in list() 
function, especially if someone does 
from graph.data import *
may be a bad idea), it is probably best to, at the top of graph.data, 
do something like

builtin_list=list

class list():...

and then use a=builtin_list(...)

where you currently use __builtins__.list(...)

In general, though, I think it would be even better to rename this 
class to avoid some really mysterious behavior if anyone does do 
an import * from it.

Marcus Mendenhall



----------------------------------------------------------------------

>Comment By: Marcus Mendenhall (mendenhall)
Date: 2004-10-08 07:17

Message:
Logged In: YES 
user_id=470295

I will only twist your arm gently over the data.list naming issue.  I 
almost never import *, since I like using namespaces, so I will probably 
never see the namespace collision.  However, unwary users could get in 
trouble with this.  

Thanks for fixing the problem.  PyX is really a nice package, especially 
as it begins to settle down.

Marcus


----------------------------------------------------------------------

Comment By: André Wobst (wobsta)
Date: 2004-10-08 07:01

Message:
Logged In: YES 
user_id=405853

I've just corrected the bug in the 0.6.x trunk. In CVS head this problem 
does not occur anymore, since the conversion of a sequence into a list is 
not necessary anymore. (Instead the new data handling allows for direct 
mixing of several data sources, which also removes some strange side 
effects.)

Beside that I'm totally aware of the problem of the name "list". The 
name comes out of the following consitency consideration: Creating 
graph data from a file is done by data.file, creating data from out of a 
function is done by data.function, creating data from a different data is 
done by data.data ... so what's the name for creating data from a list of 
points? I thought data.list would be best here ... but feel free to suggest 
a different naming. We could do data.points, but I do not really like it. 
Feel free to convince me or suggest other possibilities. I do not stop at 
those changes currently since I classify PyX to still be in the design 
phase ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

[PyX-devel] [ pyx-Bugs-1042458 ] Error with graph.data.list

[SourceForge.net <no...@so...>]

Bugs item #1042458, was opened at 2004-10-07 21:03
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with graph.data.list

Initial Comment:
In graph.data.list(), there are two places where PyX attempts to 
access the builtin list() function as __builtins__.list under certain 
conditions.  This is not correct, since __builtins__ appears as a 
dictionary and has no list attribute, and throws an exception.  

If your _really must_ create a class with the name graph.data.list 
(which, because of the possible conflict with python's built-in list() 
function, especially if someone does 
from graph.data import *
may be a bad idea), it is probably best to, at the top of graph.data, 
do something like

builtin_list=list

class list():...

and then use a=builtin_list(...)

where you currently use __builtins__.list(...)

In general, though, I think it would be even better to rename this 
class to avoid some really mysterious behavior if anyone does do 
an import * from it.

Marcus Mendenhall



----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-10-08 14:01

Message:
Logged In: YES 
user_id=405853

I've just corrected the bug in the 0.6.x trunk. In CVS head this problem 
does not occur anymore, since the conversion of a sequence into a list is 
not necessary anymore. (Instead the new data handling allows for direct 
mixing of several data sources, which also removes some strange side 
effects.)

Beside that I'm totally aware of the problem of the name "list". The 
name comes out of the following consitency consideration: Creating 
graph data from a file is done by data.file, creating data from out of a 
function is done by data.function, creating data from a different data is 
done by data.data ... so what's the name for creating data from a list of 
points? I thought data.list would be best here ... but feel free to suggest 
a different naming. We could do data.points, but I do not really like it. 
Feel free to convince me or suggest other possibilities. I do not stop at 
those changes currently since I classify PyX to still be in the design 
phase ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

[PyX-devel] [ pyx-Bugs-1042458 ] Error with graph.data.list

[SourceForge.net <no...@so...>]

Bugs item #1042458, was opened at 2004-10-07 14:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with graph.data.list

Initial Comment:
In graph.data.list(), there are two places where PyX attempts to 
access the builtin list() function as __builtins__.list under certain 
conditions.  This is not correct, since __builtins__ appears as a 
dictionary and has no list attribute, and throws an exception.  

If your _really must_ create a class with the name graph.data.list 
(which, because of the possible conflict with python's built-in list() 
function, especially if someone does 
from graph.data import *
may be a bad idea), it is probably best to, at the top of graph.data, 
do something like

builtin_list=list

class list():...

and then use a=builtin_list(...)

where you currently use __builtins__.list(...)

In general, though, I think it would be even better to rename this 
class to avoid some really mysterious behavior if anyone does do 
an import * from it.

Marcus Mendenhall



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1042458&group_id=45430

Re: [PyX-devel] Re: [PyX-checkins] pyx/pyx canvas.py,1.269,1.270

[Michael S. <m-s...@us...>]

Hi, 

On 31.08.04, Joerg Lehmann wrote:
> On 31.08.04, Andre Wobst wrote:
> > On 30.08.04, Jörg Lehmann wrote:
> > > apply deformers when drawing a path. Note that it is not clear
> > > whether we first apply a trafo and then a deformer or vice versa
> > 
> > One could argue, that a transformation is not that different from a
> > deformer ...

> Good point. I actually like this idea. We just have to derive
> trafo.trafo from deformer.deformer and supply trafo.trafo with a 
> deform method.
>
In general, trafos and deformers do not commute.
Therefore, the user should specify the order of appliance. For this,
it would be the best to have trafos act as deformers. Good idea.

Michael.
-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.