pyx-devel — PyX development

Re: [PyX-devel] Re: [PyX-user] Some geometry thoughts

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

Hi,

On 27.07.04, Magnus Lie Hetland wrote:
> I know the curves are
> non-linear... I just (naïvely ;) thought that, perhaps, through some
> transformational magic the problem could be solved within the same
> framework of linear equations.

I don't think so. The intersection of two bezier curves is solved
numerically. (Or may be by solving a polynom of grad three.) In case
you want to take a look into MetaPost (I would like to learn more
about that). Is it really possible to say: transform a path by a not
yet completely defined transformation, so that an intersection point
with another path is located at a y coordinate with a certain value?

I just think you can't transform a path with a not yet completely
defined transformation. It becomes too complicated. But, of course,
what you can do for sure is to transform a point by a not yet
completely defined transformation. This is how you can define a
transformation by saying this point goes into this and a second one
into another one etc.

> [snip]
> > Say p and p' are (2d) points, and t is a transformation (i.e. a 2x2
> > matrix + a 2d vector). Then you can write
> > 
> > p' = t(p)
> > 
> > Once you say p' and p are lazy vectors (i.e. they contain 2 variables)
> > as well as t is a lazy transformation (i.e. it contain 6 variables),
> > than the equation above is non-linear. There are non-linear terms in
> > matrix times vector when they both contain variables.
> 
> Right -- you're basically saying that this isn't linear in the
> elements of the transform? But if we freeze the transform it is linear
> in p' and p...?

Ok, lets do some ASCII art (is it art?):

/x'\   /a b\/x\   /e\
|  | = |   || | + | |
\y'/   \c d/\y/   \f/

If you do not define the transformation matrix (i.e. the variables a,
b, c, and d) and you also keep the point p, i.e. x and y, variable,
the left hand side contains terms like a*x, which is non-linear.

You may, at a later point, find out, that you already know the value
of x, for example. Than the term becomes linear ...

And I think, that's what needs to be coded.

> This seems quite muddled. I'm not very tempted to read the MetaPost
> source code to find out how they do it either; I guess maybe I can
> snoop around and see if I find some other pointers on how to do this
> sort of thing.

Or just think what we can code right now after thinking about the
problem. I think its not that complex. Those non-linear terms might be
hidden in some additional "non-linear variable" in a code along the
lines I've started. Should be possible. Just replace a*x by AX and
keep on going. Once a or x becomes available by other means, the
"non-linear variable" can be resolved and a linear equation is
restored. What's also needed are equations for 2d points etc., but
those might be build on top of the term class as well. So I think,
yes, we can really get this working ...

I've worked on my solver code a bit further. You can find an updated
version enclosed. It solves equations "on the fly" and it also tries
to solve equations as soon as possible (it searches for decoupled
systems of equations). I've just checked it into the CVS under
test/experimental/solve.py as well ...


André

PS: I've also seen your comment about isinstance. Right. Currently I'm
    using it in this solver code to differenciate in __add__ etc.
    between the different types. Not yet perfect, right ... ;-)
    (I've the Python Cookbook and read about isstring, yes.)

-- 
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] Another geometry version

[Magnus L. H. <ma...@he...>]

Luckily, I couldn't quite stop playing around with this... My first
thought was to rewrite everything, writing custom stuff to integrate
the linear equation solving stuff and my lazy points. I guess that is
still an option, but I decided to do a very simple version instead.

So, here is a version which uses Andr=E9's linear equation stuff
(although I've switched to numarray -- it's what I use; and numarray
1.0 is out now, so... Hooray for that :).

A point is simply a list of variables. By using ordinary list
notation, such as p[0] one gets at these variables (their values are
available through p[0].value and so forth) but by using the syntactic
sugar p.x (or p.y or p.z) one gets (or sets) their values. For general
dimensions beyond the third, use p.get(dim) or p.set(dim, val) (or,
equivalently, p[dim].value and p[dim].value =3D val).

The lsys class is a simple wrapper that handles left and right hand
sides with more than one element (for multidimensional equations).

There is precious little one can do directly with points at the moment
(such as addition/multiplication) but adding that should be easy. I've
added a single transformation as an example:

"""
def rotated(point, a):
    assert len(point) =3D=3D 2 # To keep it simple :)
    return (point[0]*cos(a)-point[1]*sin(a),
            point[1]*cos(a)+point[0]*sin(a))
"""

Note that this works with the *variables*, not their *values*. Thus,
one can use this transform either way in an equation:

"""
from geom import *
from math import pi

a =3D pt()
b =3D pt()
c =3D pt()

eqs =3D lsys()

a.x =3D 0
a.y =3D 10

eqs.eq(a, rotated(b, pi/2))
eqs.eq(c, rotated(a, pi/2))
eqs.solve()

print b.x, b.y
# Prints out 10.0 0.0
print c.x, c.y
# Prints out -10.0 0.0
"""

So, presto, we've got a bidirectional thingy. Note that the angle in
the transform is still a constant, though. As Andr=E9 pointed out, if
the angle is to be a variable, we'd end up getting equations with
sin() and cos(), and that's not exactly pleasant.

So, this code is still sort of hackish, but it's a starting point that
actually works... And that's always good, isn't it? :)

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

Re: [PyX-devel] A general comment

[Magnus L. H. <ma...@he...>]

Joerg Lehmann <jo...@us...>:
>
[snip]
> You're right, this should not be the case. Sometimes, however, we
> introduced some checks such that the user doesn't get hit by some
> strange error when he calls writeEPSfile.

Checks are good. I guess I'm just saying that more flexible (i.e.
signature-based) checks could be used instead.

> For instance, we check whether the arguments passed to some canvas
> methods are of a certain type. I don't think this is necessarily
> bad. See for instance the insert and set method of the
> canvas._canvas class for two examples.

The best solution here, IMO, (in an ideal world ;) would be to use
either (1) interfaces or (2) protocol adaptation. There are PEPs for
both, but I'm not sure whether either will ever become standard
Python. (I guess interfaces have the best chance, even though
adaptation is much cooler ;)

If the API is simple one could check manually (as with the helper
functions for strings etc.; you could write similar ones to check
whether something seems to be a good canvas).

I guess in these cases a simple isinstance might be easier. After all,
we *do* have multiple inheritance, so one could always just subclass
the needed class as if it were an interface.

> > Such type-based discrimination <wink> is in most cases necessary; if
> > an object can do the job, just let it.
> >
> > (Often, using polymorphism directly, i.e. simply calling a method on
> > the given object, would be better than using an if statement checking
> > properties on the object. That's not feasible in special cases such a=
s
> > this, where you have to deal with numbers and strings and the like, o=
f
> > course.)
>=20
> Again, you're right - which unfortunately does not mean that the code i=
s
> perfect in this sense - it developped over quite some time... So if
> there are some points where you think the present code can be improved
> in this regard, feel free to point them out (or just send a patch).

The reason I noticed this was that I saw plenty of isinstance() calls
in the linear equation code -- might be inconvenient if one wanted to
mix in multidimensional points between the variables and numbers it
already knows about, because, basically, the "aren't allowed" in
there.

No big deal, though. If it turns out to be problematic, I can always
fiddle a bit with the code, I guess :)

>         J=F6rg

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

Re: [PyX-devel] A general comment

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

On 27.07.04, Magnus Lie Hetland wrote:
[snip]
> OK, let's take a look at that as an example...

Ok, but as I said, the code in CVS is completely different. Maybe
I should have picked another example...

> First of all, it uses helper.isstring and helper.isnumber, both of
> which use the Leap Before You Look idiom -- I have no quarrels with
> them. That is not type checking/type based polymorphism. This is how
> it *should* be done <wink>
> 
> The only use of isintance here is:
> 
>   if isinstance(l, length):
>       self.length = l.length
>   elif helper.isstring(l):
>       # ...
> 
> Why is this check necessary? Why not use something like this (possibly
> wrapped in helper.islength or something, if desired):
> 
>   try:
>       self.length = l.length
>   except AttributeError:
>       if helper.isstring(l):
>           # ...
> 
> Then, if I decided to implement my own length-like class which
> supplied the required length attribute (which is, after all, all
> that's required) it would work nicely.
> 
> The only thing you achieve by using isintance instead is to close the
> door in my face -- "no wannabe lengths permitted".

You're right, this should not be the case. Sometimes, however, we
introduced some checks such that the user doesn't get hit by some
strange error when he calls writeEPSfile. For instance, we check whether
the arguments passed to some canvas methods are of a certain type. I
don't think this is necessarily bad. See for instance the insert and set
method of the canvas._canvas class for two examples.

> Such type-based discrimination <wink> is in most cases necessary; if
> an object can do the job, just let it.
>
> (Often, using polymorphism directly, i.e. simply calling a method on
> the given object, would be better than using an if statement checking
> properties on the object. That's not feasible in special cases such as
> this, where you have to deal with numbers and strings and the like, of
> course.)

Again, you're right - which unfortunately does not mean that the code is
perfect in this sense - it developped over quite some time... So if
there are some points where you think the present code can be improved
in this regard, feel free to point them out (or just send a patch).

        Jörg

Re: [PyX-devel] A general comment

[Magnus L. H. <ma...@he...>]

Joerg Lehmann <jo...@us...>:
>
[snip]
> Another typical use of isinstance is to implement some type based
> polymorphism. For instance, if you pass some object to a function and
> this function checks in which way he can deal with this object.

Sure -- but in Python the Right Thing(tm) in most cases isn't
type-base polymorphism, but signature-based polymorphism. If something
quacks like a duck, you treat it like a duck. It doesn't really have
to *be* a duck. (Someone might have implemented a duck-robot, for
example, and it would be impolite not to let them use that instead :)

> Here, I have to admit, I'm not always sure about the Python way of
> doing things like that... A typical example was the constructor of
> the unit.length class (only in the released PyX versions), which was
> able to convert nearly anything to a length. In CVS we already got
> rid of that...

OK, let's take a look at that as an example...

First of all, it uses helper.isstring and helper.isnumber, both of
which use the Leap Before You Look idiom -- I have no quarrels with
them. That is not type checking/type based polymorphism. This is how
it *should* be done <wink>

The only use of isintance here is:

  if isinstance(l, length):
      self.length =3D l.length
  elif helper.isstring(l):
      # ...

Why is this check necessary? Why not use something like this (possibly
wrapped in helper.islength or something, if desired):

  try:
      self.length =3D l.length
  except AttributeError:
      if helper.isstring(l):
          # ...

Then, if I decided to implement my own length-like class which
supplied the required length attribute (which is, after all, all
that's required) it would work nicely.

The only thing you achieve by using isintance instead is to close the
door in my face -- "no wannabe lengths permitted".

Such type-based discrimination <wink> is in most cases necessary; if
an object can do the job, just let it.

(Often, using polymorphism directly, i.e. simply calling a method on
the given object, would be better than using an if statement checking
properties on the object. That's not feasible in special cases such as
this, where you have to deal with numbers and strings and the like, of
course.)

>         J=F6rg

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

Re: [PyX-devel] A general comment

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

Hi Magnus,

On 27.07.04, Magnus Lie Hetland wrote:
> Just a general comment on the use of isinstance -- I think it's best
> avoided when possible. Type checking breaks polymorphism... Signature
> checking or the "leap before you look" paradigm are, IMO, more
> Pythonic. Just noticed a few isintance calls in the code here and
> there -- just thought I'd pipe in. Feel free to ignore :)

In general, you're right - and there are probably some places where
avoiding isinstance would be better. However, there are some
places where this is not so easy, and a simple isinstance is clearer
than code which tries to generalize even the special case. 
Sometimes we also check for instances of a specific class to throw
an exception already quite early. In principle this is not necessary,
but believe me, it helps when you now early on that you did something
wrong...

Another typical use of isinstance is to implement some type based
polymorphism. For instance, if you pass some object to a function and
this function checks in which way he can deal with this object. Here, I
have to admit, I'm not always sure about the Python way of doing things
like that... A typical example was the constructor of the unit.length
class (only in the released PyX versions), which was able to convert
nearly anything to a length. In CVS we already got rid of that...

        Jörg

[PyX-devel] A general comment

[Magnus L. H. <ma...@he...>]

Just a general comment on the use of isinstance -- I think it's best
avoided when possible. Type checking breaks polymorphism... Signature
checking or the "leap before you look" paradigm are, IMO, more
Pythonic. Just noticed a few isintance calls in the code here and
there -- just thought I'd pipe in. Feel free to ignore :)

-- 
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

[PyX-devel] Constraint-based stuff (geometry)

[Magnus L. H. <ma...@he...>]

Just somewhat related -- the constraint package of logilab:

  http://www.logilab.org/projects/constraint/documentation

It only works with finite domains and isn't very fast, I believe.
Might still be a source of inspiration; I don't know :}

-- 
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

Re: [PyX-devel] Re: [PyX-user] Some geometry thoughts

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
[snip]
> BTW: I didn't wrote a linear equation solver, but what I did was
> exactly a "variable class" and the "linear equations behind the
> scenes", i.e. building up linear terms. To actually solve the linear
> equations I used Numeric in my sample code already.

I noticed that when I looked at the code :)

I've actually seens some similar code somewhere else before (the code
I mentioned earlier) -- and I've written similar things too (also
related to logic programming and the like). Seems like (possibly) a
reasonable approach.

> > Certainly. It would also be neat to be able to use parametrized curve=
s
> > in the same system, as in MetaPost; but I guess it's not quite that
> > critical, as you already have support for finding intersections
> > in PyX.
>=20
> Finding intersections etc. is usually a nonlinear operation. But you
> can define points by that ... sure. I guess it will be similar to
> MetaPost in that respect (though I'm not quite sure right now).

I don't know how MetaPost does it either. I know the curves are
non-linear... I just (na=EFvely ;) thought that, perhaps, through some
transformational magic the problem could be solved within the same
framework of linear equations. I guess finding out how MetaPost
actually does this might be quite useful.

[snip]
> Say p and p' are (2d) points, and t is a transformation (i.e. a 2x2
> matrix + a 2d vector). Then you can write
>=20
> p' =3D t(p)
>=20
> Once you say p' and p are lazy vectors (i.e. they contain 2 variables)
> as well as t is a lazy transformation (i.e. it contain 6 variables),
> than the equation above is non-linear. There are non-linear terms in
> matrix times vector when they both contain variables.

Right -- you're basically saying that this isn't linear in the
elements of the transform? But if we freeze the transform it is linear
in p' and p...?

> So I think what one has to do is to postpone this non-linear equation
> until the non-linear terms are solved by other constraints. I guess,
> thats what MetaPost does as well ... as soon as p or t gets defined
> somewhere else, the equation above becomes linear.

Well, you certainly can't solve an underdetermined set of equations
anyway, whether they're linear or not :)

I guess the problem will be writing it up as a set of linear equations
(i.e. in matrix form). What you're saying is that we can't really do
this before either p, p' of t has been determined by other means?

This seems quite muddled. I'm not very tempted to read the MetaPost
source code to find out how they do it either; I guess maybe I can
snoop around and see if I find some other pointers on how to do this
sort of thing.

Does anyone know of any other systems/sources of information than
MetaPost?

> > Anyway, writing a system like this based on linear equations is a
> > bit more work than a one-way function-based one. I'll have a look
> > but I can't promise anything.
>=20
> Sure, nobody does. But we might have a starting point now ... and
> maybe somebody is really interested in this.

Well, I'd be very interested in having it available :]

> Its not top priority for me, but well, on the other hand, I already
> like it ... we can get something really funny quite quickly I guess.

I guess. The problem is laying the foundation in such a way as not to
proclude the kind of future development we might want (e.g. full
linear equation solver linked to parametric curves and transforms)
without falling into the paralyzing trap of hypergeneralization (which
I know all to well -- and I've got the scars to prove it ;)

I'll think a bit about whether it's possible to a very simple thing
here (a "Smallest Thing That Could Possibly Work" kind of thing) --
beyond what we already have, of course.

> Andr=E9

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

Re: [PyX-devel] Re: [PyX-user] Some geometry thoughts

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

Hi,

On 27.07.04, Magnus Lie Hetland wrote:
> > >     Equal(b, a + Point(10, 0))
> > 
> > I just couldn't resist: A linear equation solver can be easily build
> > like this.
> 
> I know -- I've thought about this myself in the past, and I've even
> found code that does this sort of thing. I don't remember exactly
> where, but it had a variable class and did all the linear equations
> behind the scenes.
> 
> Also, numarray (and Numeric) has support for the equation solving
> part; I guess they could be optional mechanisms for speed, if this is
> indeed the way to go.

BTW: I didn't wrote a linear equation solver, but what I did was
exactly a "variable class" and the "linear equations behind the
scenes", i.e. building up linear terms. To actually solve the linear
equations I used Numeric in my sample code already.

> Certainly. It would also be neat to be able to use parametrized curves
> in the same system, as in MetaPost; but I guess it's not quite that
> critical, as you already have support for finding intersections
> in PyX.

Finding intersections etc. is usually a nonlinear operation. But you
can define points by that ... sure. I guess it will be similar to
MetaPost in that respect (though I'm not quite sure right now).

> > My grasp tells me, that a transformation contains another set of
> > variables (6 for a 2d->2d affine transformation). When multiplying
> > with a (lazy) point (two variables) the system becomes non-linear.
> > I'm kind of confused at the moment ... ;-)
> 
> Hm. No, I don't think so... If you say that one point, transformed by
> an affine transform, equals another point, all you have is a linear
> set of two equations in two variables -- no?

Say p and p' are (2d) points, and t is a transformation (i.e. a 2x2
matrix + a 2d vector). Then you can write

p' = t(p)

Once you say p' and p are lazy vectors (i.e. they contain 2 variables)
as well as t is a lazy transformation (i.e. it contain 6 variables),
than the equation above is non-linear. There are non-linear terms in
matrix times vector when they both contain variables.

So I think what one has to do is to postpone this non-linear equation
until the non-linear terms are solved by other constraints. I guess,
thats what MetaPost does as well ... as soon as p or t gets defined
somewhere else, the equation above becomes linear.

> Anyway, writing a system like this based on linear equations is a bit
> more work than a one-way function-based one. I'll have a look but I
> can't promise anything.

Sure, nobody does. But we might have a starting point now ... and
maybe somebody is really interested in this. Its not top priority for
me, but well, on the other hand, I already like it ... we can get
something really funny quite quickly I guess.


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-user] Some geometry thoughts

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi,
>=20
> I'm moving my posting to pyx-devel ... I think its a much better place
> to post the following code. (Magnus, you're listing here, don't you? I
> think I remember your name from when I looked at the subscriber list
> quite some time ago.)

Sure. I didn't quite remember myself, which is why I used pyx-user...
But, yes, I'm on pyx-devel as well.

> On 27.07.04, Andre Wobst wrote:
> > Beside that my main concern is, whether its enough to stick on this
> > strict assignments. This is quite a limitation. We can't compete to
> > MetaPost by that (but we want, don't we?). I'm not sure whether its
> > possible to cook it all down to an Equality-function:
> >=20
> >     Equal(b, a + Point(10, 0))
>=20
> I just couldn't resist: A linear equation solver can be easily build
> like this.

I know -- I've thought about this myself in the past, and I've even
found code that does this sort of thing. I don't remember exactly
where, but it had a variable class and did all the linear equations
behind the scenes.

Also, numarray (and Numeric) has support for the equation solving
part; I guess they could be optional mechanisms for speed, if this is
indeed the way to go.

> Find some code enclosed. You may consider to go along that line
> (just in case you want to spend some time on this issue).

I might. This is sort of an issue that crops up every now and then for
me (i.e. every time I want to create a figure, basically ;)

> I think, a 2d-point can be build on top of this already by combining
> two variables.

Certainly. It would also be neat to be able to use parametrized curves
in the same system, as in MetaPost; but I guess it's not quite that
critical, as you already have support for finding intersections
in PyX.

> The same for higher dimension points. I'm not totally sure whether a
> transformation can be easily integrated in that concept.

Well, if we use a general matrix-based version, it's all good.
(Haven't looked at your code -- it might work just as well.) That is,
an affine transform are basically just added terms to the linear
equations. And it would be *very* useful to allow them... E.g. "this
point rotated around that point by 60 degrees equals this point
rotated around that point by 30 degrees" and the like.

> My grasp tells me, that a transformation contains another set of
> variables (6 for a 2d->2d affine transformation). When multiplying
> with a (lazy) point (two variables) the system becomes non-linear.
> I'm kind of confused at the moment ... ;-)

Hm. No, I don't think so... If you say that one point, transformed by
an affine transform, equals another point, all you have is a linear
set of two equations in two variables -- no?

Not sure what you mean by "multiplying with a [...] point" here,
though. I may be missing something :]

Anyway, writing a system like this based on linear equations is a bit
more work than a one-way function-based one. I'll have a look but I
can't promise anything.

> Andr=E9

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]

[PyX-devel] Re: [PyX-user] Some geometry thoughts

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

Hi,

I'm moving my posting to pyx-devel ... I think its a much better place
to post the following code. (Magnus, you're listing here, don't you? I
think I remember your name from when I looked at the subscriber list
quite some time ago.)

On 27.07.04, Andre Wobst wrote:
> Beside that my main concern is, whether its enough to stick on this
> strict assignments. This is quite a limitation. We can't compete to
> MetaPost by that (but we want, don't we?). I'm not sure whether its
> possible to cook it all down to an Equality-function:
> 
>     Equal(b, a + Point(10, 0))

I just couldn't resist: A linear equation solver can be easily build
like this. Find some code enclosed. You may consider to go along that
line (just in case you want to spend some time on this issue). I
think, a 2d-point can be build on top of this already by combining two
variables. The same for higher dimension points. I'm not totally sure
whether a transformation can be easily integrated in that concept. My
grasp tells me, that a transformation contains another set of
variables (6 for a 2d->2d affine transformation). When multiplying
with a (lazy) point (two variables) the system becomes non-linear. I'm
kind of confused at the moment ... ;-)


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/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi Jörg,

On 22.07.04, Joerg Lehmann wrote:
> You misunderstood me. I did not mean that the user should call this
> function, but I was just suggesting that the style handles the return
> value separately, i.e., not in the function donedrawpoints. But this
> is not so important at all.

Ok. I might spend a separate function. But as you said, this is an
implementation detail and not so important.

> > First I thought it would be a bad idea to return something else than
> > the data instance at the plot command (because its like what we do in
> > canvas.insert etc.). On the other hand, the data is not -- *never* --
> > bound tightly to the graph. It contains no information about what's
> > plotted. (Currently, it does, because sharedata and privatedatalist is
> > storred in the data instance, but thats a misfeature we will resolve
> > in the future. Once we did, there seems to be no reason at all, why a
> > data instance does not contain any information about the output
read: data instance does contain any information about the output
> > created. In the future I don't see any reason, why the data would need
> > a container like privatedata/sharedata/styledata. It does not have to
> > store anything related to the graph.)
> 
> I'm getting confused...

The point is, that it does not make any sense, that the plot method
returns the data instance(s) in the future since those will not store
any information related to the current graph (as it currently does,
since privatedatalist and sharedata are instance variables of data
right now).

> > Hence I think it would be good to allow the styles to return something
> > related to the stuff actually drawn. The only remaining question is,
> > whether this fancy_return is the right thing to do. I'm still not
> > satisfied. In some sense it makes sense to make the finish process
> > visible. Back to #2: Explicit is better than implicit. What about
> > something along the lines:
> > 
> >     pd = graph.plot(data(...), [graph.style.line()])
> > 
> >     p = pd.finish()
> 
> I do not like this idea. Why should one finish the plot data? This
> sounds very strange to me. However, I could imagine a
> 
>     p = pd.getX()
> 
> with X={styleinfo,styledata,...} whathever you like.
> 
> > where pd are the "plot data" and p is the path. Its more or less back
> > to what we had in the sense, that we have this plot data construct,
> > which takes care about the graph instance needed, the data and styles
> > in use, the return values, the finishing process etc. Still, the
> > styles should be responsible to create the return value(s). In the
> > first we only need to return the path when creating a line. The plot
> > data instances will have a finish method only, which will take care of
> > the internals and return the draw results from the styles. And that's
> > it. I think that's probably ok. Its not that complicated and its quite
> > explicit.
> 
> As I said above, I do not like the name at all. And I also don't see
> a problem in returning something from the plot command which will
> only be populated with data later, namely when the graph has been 
> finished.

The point is, that it can't be just a list. Otherwise the user would
immediately split up the list content and we can't populate the items
later on:

    p1, p2 = g.plot(...)

(Still, we could some fancy_return construct for the return values p1
and p2).

So another possibility would be to return a container, i.e. an
instance of an empty class, where instance variables can be set as
needed:

    pd = g.plot(...)

We can than access those instance variables, once they are created
(after the graph was finished):

    c.stroke(pd.path)

But here's a problem. Suppose the styles create several paths (this
becomes possible in stacked bars once the new bars are finished):

    pd = g.plot(d, [graph.style.bar(), graph.style.line(),
                    graph.style.barpos(stack="ystack1"),
                    graph.style.bar(), graph.style.line()])

pd shall contain two paths now. Thats what styles get privatedata for.
But how to access that by the user. Back to my suggestion, it would
look like:

    p1, p2 = pd.finish()

Still, finish is the wrong name. We might come up with a single name
used in both cases: as a style method name (instead of introducing a
return value of donedrawpoints) and here as well. Something like
styledata (or stylesdata) ... this name has vanished internally in
favor of sharedata and privatedata. So we could use that ...

Still, not sure whether we're getting it right at all ... but I think
this solution would work well.


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/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi André,

On 22.07.04, Andre Wobst wrote:
> On 22.07.04, Joerg Lehmann wrote:
[...snip...]
> > Btw, we could also introduce a new style method which is responsible for
> > returning the return value, when called with the corresponding sharedata
> > and privatedata objects.
> 
> This is too complicated for the user. You need the
> sharedata/privatedatalist from a given plot command and put it into
> the styles to recieve some information. Hmmm. I don't see any
> advantage of this quite complicated way to extract information.

You misunderstood me. I did not mean that the user should call this
function, but I was just suggesting that the style handles the return
value separately, i.e., not in the function donedrawpoints. But this
is not so important at all.

> First I thought it would be a bad idea to return something else than
> the data instance at the plot command (because its like what we do in
> canvas.insert etc.). On the other hand, the data is not -- *never* --
> bound tightly to the graph. It contains no information about what's
> plotted. (Currently, it does, because sharedata and privatedatalist is
> storred in the data instance, but thats a misfeature we will resolve
> in the future. Once we did, there seems to be no reason at all, why a
> data instance does not contain any information about the output
> created. In the future I don't see any reason, why the data would need
> a container like privatedata/sharedata/styledata. It does not have to
> store anything related to the graph.)

I'm getting confused...

> Hence I think it would be good to allow the styles to return something
> related to the stuff actually drawn. The only remaining question is,
> whether this fancy_return is the right thing to do. I'm still not
> satisfied. In some sense it makes sense to make the finish process
> visible. Back to #2: Explicit is better than implicit. What about
> something along the lines:
> 
>     pd = graph.plot(data(...), [graph.style.line()])
> 
>     p = pd.finish()

I do not like this idea. Why should one finish the plot data? This
sounds very strange to me. However, I could imagine a

    p = pd.getX()

with X={styleinfo,styledata,...} whathever you like.

> where pd are the "plot data" and p is the path. Its more or less back
> to what we had in the sense, that we have this plot data construct,
> which takes care about the graph instance needed, the data and styles
> in use, the return values, the finishing process etc. Still, the
> styles should be responsible to create the return value(s). In the
> first we only need to return the path when creating a line. The plot
> data instances will have a finish method only, which will take care of
> the internals and return the draw results from the styles. And that's
> it. I think that's probably ok. Its not that complicated and its quite
> explicit.

As I said above, I do not like the name at all. And I also don't see
a problem in returning something from the plot command which will
only be populated with data later, namely when the graph has been 
finished.

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi,

On 22.07.04, Andre Wobst wrote:
> data instance does not contain any information about the output

In case you're confused: Right, just cancel the "not" in the line
above. Sorry.


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/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi Jörg,

On 22.07.04, Joerg Lehmann wrote:
> On 22.07.04, Andre Wobst wrote:
> > Right. You can even make this a style option (if you like):
> > 
> > p = g.plot(graph.data(...), [graph.style.line(returnpath=1)])
> 
> Yes, but probably that's not necessary.

Sure. But we're able to allow for it. There might be usecases in the
future.

> That's exactly the reason why I don't like this idea. I really think we
> shouln't expose the sharedata and privatedata lists, which really are
> internal implementation details, to the user.
> 
> Btw, we could also introduce a new style method which is responsible for
> returning the return value, when called with the corresponding sharedata
> and privatedata objects.

This is too complicated for the user. You need the
sharedata/privatedatalist from a given plot command and put it into
the styles to recieve some information. Hmmm. I don't see any
advantage of this quite complicated way to extract information.

First I thought it would be a bad idea to return something else than
the data instance at the plot command (because its like what we do in
canvas.insert etc.). On the other hand, the data is not -- *never* --
bound tightly to the graph. It contains no information about what's
plotted. (Currently, it does, because sharedata and privatedatalist is
storred in the data instance, but thats a misfeature we will resolve
in the future. Once we did, there seems to be no reason at all, why a
data instance does not contain any information about the output
created. In the future I don't see any reason, why the data would need
a container like privatedata/sharedata/styledata. It does not have to
store anything related to the graph.)

Hence I think it would be good to allow the styles to return something
related to the stuff actually drawn. The only remaining question is,
whether this fancy_return is the right thing to do. I'm still not
satisfied. In some sense it makes sense to make the finish process
visible. Back to #2: Explicit is better than implicit. What about
something along the lines:

    pd = graph.plot(data(...), [graph.style.line()])

    p = pd.finish()

where pd are the "plot data" and p is the path. Its more or less back
to what we had in the sense, that we have this plot data construct,
which takes care about the graph instance needed, the data and styles
in use, the return values, the finishing process etc. Still, the
styles should be responsible to create the return value(s). In the
first we only need to return the path when creating a line. The plot
data instances will have a finish method only, which will take care of
the internals and return the draw results from the styles. And that's
it. I think that's probably ok. Its not that complicated and its quite
explicit.


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/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi André,

On 22.07.04, Andre Wobst wrote:
> On 22.07.04, Joerg Lehmann wrote:
> > So each
> > style can choose the data it wants to pass back to the user, which might
> > not only be the path but also colours, etc.
> 
> Right. You can even make this a style option (if you like):
> 
> p = g.plot(graph.data(...), [graph.style.line(returnpath=1)])

Yes, but probably that's not necessary.

> There's not limitation by design.
> 
> > > But there is, of course, a problem: We can't return something from the
> > > donedrawpoint method at the plot command, because donedrawpoint will
> > > be called much later. But we could return a wrapper along the lines
> > > you can find enclosed. fancy_return acts like the returnvalue of data,
> > > but it deferes referencing to the returnvalue until something is
> > > accessed. We can even automate the neccessary finishing of the graph
> > > that way.
> > 
> > This would be one solution. Btw, in principle, this could also be 
> > done by returning a list.
> 
> Hmmm ... isn't that even worse (i.e. the late evaluation becomes even
> more implicit)? Suppose the offen used idiom:

Sorry, the list thing was not really meant serious... Too hot, here.

> > Alternatively, if we want to act according to "The Zen of Python" #2,
> > namely "Explicit is better than implicit", we could also raise an
> > exception when trying to access the return value and the graph has not
> > yet been finished.
> 
> Ok, fine to me.

I'm not sure which solution is better, probably both are ok.

> Right, the name is just a "working name". We can certainly find
> something suitable. The basic question is, whether this return value
> wrapper is a good way to go. I think, we gain a really cool syntax and
> user interface by that. You can just access drawing results without
> fiddling in the internals. But we're wrapping the return value in
> something, where we can inject the real return value later on. The
> basic question is, whether this is a good idea. May be it isn't.

I don't think it's a bad idea. At least it is better than returning
the privedata of all styles, for the reason given below.

> Suppose we do the following: we just return the privatedata of all the
> styles originally given:
> 
> sd, = g.plot(data(...), [graph.style.line()])
> 
> We can than access sd.path once the graph is finished. While this is
> much less fancy, it might be just the best way to go. OTOH the
> question is, whether we'll never need to access variables of the data
> instance. At similar places in PyX we return the data instance itself
> as we do it right now. I don't yet have a strong fealing what's the
> best thing to do. (And we should also keep in mind, that sharedata and
> privatedatalist might be moved to the graph in the future.)

That's exactly the reason why I don't like this idea. I really think we
shouln't expose the sharedata and privatedata lists, which really are
internal implementation details, to the user.

Btw, we could also introduce a new style method which is responsible for
returning the return value, when called with the corresponding sharedata
and privatedata objects.

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi Jörg,

On 22.07.04, Joerg Lehmann wrote:
> So each
> style can choose the data it wants to pass back to the user, which might
> not only be the path but also colours, etc.

Right. You can even make this a style option (if you like):

p = g.plot(graph.data(...), [graph.style.line(returnpath=1)])

There's not limitation by design.

> > But there is, of course, a problem: We can't return something from the
> > donedrawpoint method at the plot command, because donedrawpoint will
> > be called much later. But we could return a wrapper along the lines
> > you can find enclosed. fancy_return acts like the returnvalue of data,
> > but it deferes referencing to the returnvalue until something is
> > accessed. We can even automate the neccessary finishing of the graph
> > that way.
> 
> This would be one solution. Btw, in principle, this could also be 
> done by returning a list.

Hmmm ... isn't that even worse (i.e. the late evaluation becomes even
more implicit)? Suppose the offen used idiom:

x, y = g.plot(...)

You will immediately loose the chance to inject the return values
later on, don't you? I think, this is really bad. People will not
understand, what we're doing. (BTW this shows, that we need to create
a fancy_return instance for each style return value separately.)

> Alternatively, if we want to act according to "The Zen of Python" #2,
> namely "Explicit is better than implicit", we could also raise an
> exception when trying to access the return value and the graph has not
> yet been finished.

Ok, fine to me.

> > OTOH, I'm not sure whether fancy_return would be too fancy ...
> 
> The name certainly is, but besides that I begin to like the idea.

Right, the name is just a "working name". We can certainly find
something suitable. The basic question is, whether this return value
wrapper is a good way to go. I think, we gain a really cool syntax and
user interface by that. You can just access drawing results without
fiddling in the internals. But we're wrapping the return value in
something, where we can inject the real return value later on. The
basic question is, whether this is a good idea. May be it isn't.

Suppose we do the following: we just return the privatedata of all the
styles originally given:

sd, = g.plot(data(...), [graph.style.line()])

We can than access sd.path once the graph is finished. While this is
much less fancy, it might be just the best way to go. OTOH the
question is, whether we'll never need to access variables of the data
instance. At similar places in PyX we return the data instance itself
as we do it right now. I don't yet have a strong fealing what's the
best thing to do. (And we should also keep in mind, that sharedata and
privatedatalist might be moved to the graph in 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] Re: [PyX-checkins] pyx/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi André,

On 22.07.04, Andre Wobst wrote:
[...snip...]
> But we could establish something much more intuitive to the user in
> terms of the return value of the plot command. First, each style could
> have a return value in the donedrawpoints method (or it might return
> None, which would be counted as no return value). In case several
> return values will occure in the different styles, we could create a
> list of return values. Otherwise the return value could be taken as it
> is.
>
> (As a side remark: In case, the plot command was used with a list of
> data in the first place, we could always return a list of the result
> values ... it might happen to have a list as items than.)

Sounds good, except for the problem described by you below. So each
style can choose the data it wants to pass back to the user, which might
not only be the path but also colours, etc.

> But there is, of course, a problem: We can't return something from the
> donedrawpoint method at the plot command, because donedrawpoint will
> be called much later. But we could return a wrapper along the lines
> you can find enclosed. fancy_return acts like the returnvalue of data,
> but it deferes referencing to the returnvalue until something is
> accessed. We can even automate the neccessary finishing of the graph
> that way.

This would be one solution. Btw, in principle, this could also be 
done by returning a list.

> In summary the plot command could directly return the path, when a
> line is drawn (it would return a fancy_return instance instead, but
> this might not matter so much). And as soon as properties of the path
> are accessed, the graph could be finished automatically. (BTW: We
> could do an automatic finish in graph.pos() and the like as well ...)

Alternatively, if we want to act according to "The Zen of Python" #2,
namely "Explicit is better than implicit", we could also raise an
exception when trying to access the return value and the graph has not
yet been finished.

> OTOH, I'm not sure whether fancy_return would be too fancy ...

The name certainly is, but besides that I begin to like the idea.

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi Jörg,

On 22.07.04, Joerg Lehmann wrote:
> > line1.styledata.path changes to line1.privatedatalist[-1].path
> 
> This changes makes me wonder how the user can deal with the
> privatedatalist in the future. While in the present case, it is still
> rather clear that the last element in this list contains the style
> orginally specified in (or automagically chosen by, as in the present
> case) the plot command, due to style dependencies this is not totally
> clear in the general situation. Should there be an interface which
> allows access to the nth user specfied style? Or is accessing the
> {private|shared}datalist more a undocumented kludge and should only be
> done by a user who really knows what's going on internally?

I think we currently have a quite undocumented behaviour all the time.
And its much to complicated to be usefull. While there is not so much
wrong with having the path stored in one of the privatedatalist items
(internally, I think its the correct way to deal with it), we might
define an additional interface for passing information from a plot
command back to the user. Currently we just return the data instance.
It's not completely wrong to do that, but the user has to know quite
something about the internal structure to actually access whatever he
wants to access later on. (Remember, in former times where there was
not such a strict separation, that the data instance keeps track of
all the styles, we had a return value of type plotinfo, which
basically was a data instance and its style. We used that for graph
keys and others in earlier versions. None of this stuff was really
documented at any time.)

But we could establish something much more intuitive to the user in
terms of the return value of the plot command. First, each style could
have a return value in the donedrawpoints method (or it might return
None, which would be counted as no return value). In case several
return values will occure in the different styles, we could create a
list of return values. Otherwise the return value could be taken as it
is.

(As a side remark: In case, the plot command was used with a list of
data in the first place, we could always return a list of the result
values ... it might happen to have a list as items than.)

But there is, of course, a problem: We can't return something from the
donedrawpoint method at the plot command, because donedrawpoint will
be called much later. But we could return a wrapper along the lines
you can find enclosed. fancy_return acts like the returnvalue of data,
but it deferes referencing to the returnvalue until something is
accessed. We can even automate the neccessary finishing of the graph
that way.

In summary the plot command could directly return the path, when a
line is drawn (it would return a fancy_return instance instead, but
this might not matter so much). And as soon as properties of the path
are accessed, the graph could be finished automatically. (BTW: We
could do an automatic finish in graph.pos() and the like as well ...)

OTOH, I'm not sure whether fancy_return would be too fancy ...


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] Re: [PyX-checkins] pyx/test/functional test_bargraph.py,1.7,1.8 test_graph.py,1.50,1.51

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

Hi André,

On 22.07.04, André Wobst wrote:
[ ... snip ...]
> *** test_graph.py	2 Jul 2004 13:59:57 -0000	1.50
> --- test_graph.py	22 Jul 2004 08:21:21 -0000	1.51
> ***************
> *** 55,62 ****
>       g.finish()
>   
> !     p1=line1.styledata.path
> !     p2=line2.styledata.path.reversed()
> !     p3=line3.styledata.path.reversed()
> !     p4=line4.styledata.path
>       (seg1a,), (seg2a,) = p1.intersect(p2)
>       (seg2b,), (seg3b,) = p2.intersect(p3)
> --- 55,62 ----
>       g.finish()
>   
> !     p1=line1.privatedatalist[-1].path
> !     p2=line2.privatedatalist[-1].path.reversed()
> !     p3=line3.privatedatalist[-1].path.reversed()
> !     p4=line4.privatedatalist[-1].path
>       (seg1a,), (seg2a,) = p1.intersect(p2)
>       (seg2b,), (seg3b,) = p2.intersect(p3)
[ ... snip ...]

This changes makes me wonder how the user can deal with the
privatedatalist in the future. While in the present case, it is still
rather clear that the last element in this list contains the style
orginally specified in (or automagically chosen by, as in the present
case) the plot command, due to style dependencies this is not totally
clear in the general situation. Should there be an interface which
allows access to the nth user specfied style? Or is accessing the
{private|shared}datalist more a undocumented kludge and should only be
done by a user who really knows what's going on internally?

        Jörg

[PyX-devel] [ pyx-Bugs-966575 ] install problem on mandrake 10

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

Bugs item #966575, was opened at 2004-06-04 16:38
Message generated for change (Settings changed) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=966575&group_id=45430

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: install problem on mandrake 10

Initial Comment:
unable to install last Pyx release. after running
setup.py -install, I get this error message :
/usr/lib/python23/config/Makefile 
"can not read file or does not exist"


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

>Comment By: André Wobst (wobsta)
Date: 2004-07-14 17:18

Message:
Logged In: YES 
user_id=405853

Didn't recieved any further comments after > 1 month. Issue seems to 
be solved. Closing.

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

Comment By: Jörg Lehmann (joergl)
Date: 2004-06-04 16:44

Message:
Logged In: YES 
user_id=390410

Are you sure you have installed the Python 2.3 development
packages (probably named python-dev or python2.3-dev)?


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

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

[PyX-devel] [ pyx-Bugs-990687 ] symbol/line representation in key incorrect

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gert Ingold (gertingold)
Assigned to: Nobody/Anonymous (nobody)
Summary: symbol/line representation in key incorrect

Initial Comment:
As the enclosed example demonstrates, the
representation of line and symbol in a graph key
appears to be incorrect. In the graph, the line is
drawn before the symbol so that filling the symbol with
a different color will make the line disappear under
the symbol. In the key, it seems that the line is drawn
after the symbol so that the line does not disappear.

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

>Comment By: André Wobst (wobsta)
Date: 2004-07-14 17:14

Message:
Logged In: YES 
user_id=405853

Right. The enclosed patch will correct the problem and is also checked 
into the 0.6.x CVS branch. However, the current CVS head (and thus the 
forthcomming 0.7 release) is not affected by the problem, since lines and 
symbols got splitted into two independend styles. You now specify a list 
of styles in the second parameter of the plot method of the graph. By 
that you can even alter the order, in which the styles are drawn. This 
order is the same in the graph and in the graph key (I just checked it and 
even found some bugs while checking ... so thanks anyway ...)

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

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

[PyX-devel] [ pyx-Bugs-990687 ] symbol/line representation in key incorrect

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

Bugs item #990687, was opened at 2004-07-14 06:21
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=990687&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gert Ingold (gertingold)
Assigned to: Nobody/Anonymous (nobody)
Summary: symbol/line representation in key incorrect

Initial Comment:
As the enclosed example demonstrates, the
representation of line and symbol in a graph key
appears to be incorrect. In the graph, the line is
drawn before the symbol so that filling the symbol with
a different color will make the line disappear under
the symbol. In the key, it seems that the line is drawn
after the symbol so that the line does not disappear.

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

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

[PyX-devel] New list: pyx-checkins@lists.sourceforge.net

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

Hi,

FYI: I've setup a new list pyx...@li... to which
PyX source code checkin messages are sent automagically. Feel free to
subscribe, if you're interested. Replies should go to the pyx-devel
list.

        Jörg