pyx-devel — PyX development

[PyX-devel] [ pyx-Bugs-1180691 ] incomplete example in ref manual

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Utermann (ralfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: incomplete example in ref manual 

Initial Comment:
Reference manual 0.7.1, chapter  2.1:

The definition of 'rect2' is missing the
final 'path.lineto(0, 0)'


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

>Comment By: André Wobst (wobsta)
Date: 2005-04-11 17:12

Message:
Logged In: YES 
user_id=405853

Right! Fixed in CVS. Thanks for the report!

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

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

[PyX-devel] [ pyx-Bugs-1180691 ] incomplete example in ref manual

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

Bugs item #1180691, was opened at 2005-04-11 14:54
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=1180691&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Utermann (ralfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: incomplete example in ref manual 

Initial Comment:
Reference manual 0.7.1, chapter  2.1:

The definition of 'rect2' is missing the
final 'path.lineto(0, 0)'


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

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

Re: [PyX-devel] Re: Bug in Windows installer

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

Hi,

On 05.01.05, Fernando Perez wrote:
> Let me suggest that you guys have a look at IPython's installer 
> (http://ipython.scipy.org).  I had to deal with many similar issues, and I 
> also develop 'in the blind', since I did everything from a Linux box with 
> only about one day of work on a borrowed windows laptop.  It's primitive 
> under windows, but it works.  Feel free to grab any code from there you may 
> want.

I took at look at it for several times now. But it didn't really match
what we wanted to have. And you need to store install path information
on Windows and Unix as well, and the way to go is to store the
information in a python file created during install. I learned this by
you. But once you do that on a Unix, you can use it on Windows as
well. We do *not* need the registry for that. We do not need to look
into the registry to find some information ... and we do not need to
write something into it, since we keep it in a siteconfig.py file.

Anyway, we do had troubles with the solution I proposed before. Right.
I created a dependancy of the build_lib on install_data. That was a
bad idea for sure. But I solved it (see below).

> You will HAVE to read registry keys if you want to make something portable, 
> since the various windows directories can be called different things under 
> different windows versions.  I also used the win32 extensions from David 
> Ascher so I could give windows users 'Start Menu' shortcuts for  ipython 
> and the manuals, but if you give that up, you can run all the code with 
> only the tools in the stdlib.

We do not care about menu entries, since PyX is a library, not an
application. You nice ipython is different in that respect, of course.

In the mean I kind of "unbroken" the CVS. Although there are some
other things planed for 0.8 and those need to be addressed, if
somebody wants to grab the current CVS, he should be able to test for
the setup. I would be interested in somebody checking for the Windows
installer and building rpm's. I can't check myself ... I don't have
either of these environments.

If nobody checks we have to see at the next release (which will not
hurt me, but it would be nice to get it tested before) ... ;-)


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-Support Requests-1112406 ] add the .dat files to the examples pages

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

Support Requests item #1112406, was opened at 2005-01-30 06:31
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442887&aid=1112406&group_id=45430

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Shane Geiger (shanerg)
Assigned to: Nobody/Anonymous (nobody)
Summary: add the .dat files to the examples pages

Initial Comment:
It would be most helpful to have the .dat files that
were used to generate the examples on the Web site
pyx.sf.net  

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

>Comment By: André Wobst (wobsta)
Date: 2005-03-24 14:39

Message:
Logged In: YES 
user_id=405853

I've updated the webpage generation script to include the .dat files some 
times ago. The extended pages will go online with the next release.

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

Comment By: André Wobst (wobsta)
Date: 2005-02-14 14:11

Message:
Logged In: YES 
user_id=405853

I'm sorry for the late response. Due to a config error (misspelling of the 
email address) your request wasn't forwarded to the developer mailing 
list. Should be fixed now ...

Regarding your issue: To implement that, we could use a policy, that 
those additional files (like data files) should have the same basename. 
Than we could automate the inclusion of the dat-files easily. We do all 
the example pages automatically and that's an absolute requirement to 
keep.

But you may have noticed, that PyX comes with the full set of examples. 
Once you want to check out the examples yourself, you can just grab 
them from the tar-ball you already downloaded. So my answer is more 
like a question to the dev-list on whether to really implement that.

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

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

[PyX-devel] [ pyx-Bugs-1161892 ] EPS size too big?

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jörg Lehmann (joergl)
Summary: EPS size too big?

Initial Comment:
Pyx eps:330k, gnuplot eps:50k ?!?
Is there something wrong here?

Also v7.0.1 seems to typeset "\beta" wrongly; "\beta" produces 
what I would get had I typed "\lambda eta". Most other Greek 
LaTex symbols work ok. (did not try all of them...)

On Mac OSX v10.3.7, with python v2.3

Thank you,
the...@4e...

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

>Comment By: André Wobst (wobsta)
Date: 2005-03-24 14:36

Message:
Logged In: YES 
user_id=405853

The issue seems to be invalid. You're welcome to reopen the report to 
come up with further information or related questions.

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

Comment By: André Wobst (wobsta)
Date: 2005-03-14 08:07

Message:
Logged In: YES 
user_id=405853

Just an idea about your greek letters problem:

"\rho" != "\rho" == r"\rho"

(The first string contains a carrage return. This is probably not what you 
want. ;-))

About the EPS size: Fonts are likely to make a huge difference (whether 
they are embedded or not). Stripping fonts to remove unused glyphs will 
likely help a lot. But still its not the same like sticking on built-in 
PostScript fonts (i.e. those, which do not needed to be embedded into the 
EPS file at all). Note that you can do can use built-in PostScript fonts with 
LaTeX and PyX as well. Use \usepackage{mathptmx} or the like.

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

Comment By: Jörg Lehmann (joergl)
Date: 2005-03-12 16:08

Message:
Logged In: YES 
user_id=390410

Concerning the size of the eps files, a few questions: What
fonts did you use in gnuplot and in PyX? Did you enable
partial font downloading by compiling
the t1strip module?

With respect to your problem with the \beta. I cannot
reproduce this
here. Can you please send a minimal PyX example file.

Thanks,

    Jörg

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

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

[PyX-devel] [ pyx-Feature Requests-1118152 ] default args for data.(list|file)(x=1,y=2)

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

Feature Requests item #1118152, was opened at 2005-02-07 22:00
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1118152&group_id=45430

Category: Interface Improvements (example)
Group: Next Release (example)
>Status: Closed
Priority: 5
Submitted By: Francisco Dellatorre Borges (fdborges)
Assigned to: Nobody/Anonymous (nobody)
Summary: default args for data.(list|file)(x=1,y=2)

Initial Comment:

All graph data entries must have a x and y coordinates. 

It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.

Just as users (e.g.  me) of a cmd line plotting routine
expect to call

$ bozoplot results.dat 

with two columns entries:

0 1
1 3 etc

and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.

Francisco.

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

>Comment By: André Wobst (wobsta)
Date: 2005-03-24 14:24

Message:
Logged In: YES 
user_id=405853

Still, data.data is the proposed solution here. Anyway, I've modified its 
behaviour to (by default) keep the original columns with their names. This 
adds additional flexibility and you now can give the axis names in the data 
files without repeating them in PyX. I think its about all we should do.

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

Comment By: André Wobst (wobsta)
Date: 2005-02-10 13:43

Message:
Logged In: YES 
user_id=405853

Sure, many things could be done. But we do not use __call__ too much. 
(There is a use case in the attribute modification and thats fine but I 
don't know whether its appropriate at an data instance. May be ... could 
be. It would be kind of a convenience method.)

But back to your problem: You could just "decorate" an arbitrary callable 
thing by some additional keyword argument (when they are not 
overwritten). This could look like that:

def decorate(callable, **addkwargs):
    def decorator(*args, **kwargs):
        fullkwargs = addkwargs.copy()
        fullkwargs.update(kwargs)
        callable(*args, **fullkwargs)
    return decorator

def test(*args, **kwargs):
    print args, kwargs

test(1, 2, a=1, b=2)
testdeco = decorate(test, b=-2, c=-3)
testdeco(1, 2, a=1, b=2)

A way to go for you?

Beside that, Jörg, what's your opinion about making a data instance 
callable to create a new data instance out of an existing one. Thats what 
graph.data.data is for right now. But using graph.data.data we do not 
keep the old columns ...

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

Comment By: Francisco Dellatorre Borges (fdborges)
Date: 2005-02-10 12:32

Message:
Logged In: YES 
user_id=576554

1. I think a wrapper would be nice and I thought about
making one myself.
 
I have some code that already works as a wrapper but it's
scathered and as I need to deliver a thesis chapter by the
end of this month, I haven't actually started putting the
code pieces together.

2. Yet, I still would like to be able to code some things
faster and a wrapper won't help much at it. When drawing
some illustrative didactic graphs for my thesis, I end up
calling data.list 4 or 5 times in a file, (and that's using
attr.changelist([a,b,c]) to avoid extra calls as in:

g.plot([ data.list(i, x=1, y=2, text=3) for i in [pts, pts1,
pts2] ],
       [st.line([attr.changelist( 
[linewidth.thick, linewidth.normal,linewidth.normal] ),
                 attr.changelist( 
[linestyle.solid, linestyle.dashdotted, linestyle.dashdotted
] )]),
        st.text(textdx=0.5, textdy=0)])

Perhaps allow setting default values at a data.list instance
initialization and then allow more instances to be created
from this one?

dlst = data.list(None, x=1, y=2, dy=3) # setting default values.
g.plot(dlst(d1, text=4), style1)
g.plot(dlst(d2, stacked=4), style2)

I don't know exactly how this should be implemented, as you
seem to need different data.list objects to process, the
class object would have to became a object factory
separating the current data.list.__init__ method into 
__init__ and __call__. Hackish solutions in this direction
would be easy to implement and a more clean version
shouldn't be too much of a problem.

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

Comment By: Jörg Lehmann (joergl)
Date: 2005-02-08 09:55

Message:
Logged In: YES 
user_id=390410

I agree with André. Such a policy should not be part
of the data component. In order to support quick&easy
plotting, a wrapper providing some standard plot types as
suggested recently by Michael Hagemann on the pyx-user is
the way to go. 

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

Comment By: André Wobst (wobsta)
Date: 2005-02-08 09:06

Message:
Logged In: YES 
user_id=405853

Couldn't you do this within your bozoplot command? The point is that 
graph.data.file and the like do not know anything about the column 
names they need to fill with data. It's designed the other way around. 
You provide some data and the graph styles (by the help of the axis 
names available in the graph) will tell you, whether this is a valid 
request. I do not want to stress that too much, especially since we 
currently have an xy graph only, but the axis names could be completely 
different in an polar plot, a 3-d plot etc. And other graph styles like text, 
arrow, errorbars etc. want other data as well. I would not like to see a 
semi-guessing solution in PyX. Comments?

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

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

[PyX-devel] [ pyx-Bugs-1161892 ] EPS size too big?

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jörg Lehmann (joergl)
Summary: EPS size too big?

Initial Comment:
Pyx eps:330k, gnuplot eps:50k ?!?
Is there something wrong here?

Also v7.0.1 seems to typeset "\beta" wrongly; "\beta" produces 
what I would get had I typed "\lambda eta". Most other Greek 
LaTex symbols work ok. (did not try all of them...)

On Mac OSX v10.3.7, with python v2.3

Thank you,
the...@4e...

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

>Comment By: André Wobst (wobsta)
Date: 2005-03-14 08:07

Message:
Logged In: YES 
user_id=405853

Just an idea about your greek letters problem:

"\rho" != "\rho" == r"\rho"

(The first string contains a carrage return. This is probably not what you 
want. ;-))

About the EPS size: Fonts are likely to make a huge difference (whether 
they are embedded or not). Stripping fonts to remove unused glyphs will 
likely help a lot. But still its not the same like sticking on built-in 
PostScript fonts (i.e. those, which do not needed to be embedded into the 
EPS file at all). Note that you can do can use built-in PostScript fonts with 
LaTeX and PyX as well. Use \usepackage{mathptmx} or the like.

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

Comment By: Jörg Lehmann (joergl)
Date: 2005-03-12 16:08

Message:
Logged In: YES 
user_id=390410

Concerning the size of the eps files, a few questions: What
fonts did you use in gnuplot and in PyX? Did you enable
partial font downloading by compiling
the t1strip module?

With respect to your problem with the \beta. I cannot
reproduce this
here. Can you please send a minimal PyX example file.

Thanks,

    Jörg

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

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

[PyX-devel] [ pyx-Bugs-1161892 ] EPS size too big?

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jörg Lehmann (joergl)
Summary: EPS size too big?

Initial Comment:
Pyx eps:330k, gnuplot eps:50k ?!?
Is there something wrong here?

Also v7.0.1 seems to typeset "\beta" wrongly; "\beta" produces 
what I would get had I typed "\lambda eta". Most other Greek 
LaTex symbols work ok. (did not try all of them...)

On Mac OSX v10.3.7, with python v2.3

Thank you,
the...@4e...

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

>Comment By: Jörg Lehmann (joergl)
Date: 2005-03-12 16:08

Message:
Logged In: YES 
user_id=390410

Concerning the size of the eps files, a few questions: What
fonts did you use in gnuplot and in PyX? Did you enable
partial font downloading by compiling
the t1strip module?

With respect to your problem with the \beta. I cannot
reproduce this
here. Can you please send a minimal PyX example file.

Thanks,

    Jörg

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

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

[PyX-devel] [ pyx-Support Requests-1161892 ] EPS size too big?

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

Support Requests item #1161892, was opened at 2005-03-12 01:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442887&aid=1161892&group_id=45430

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: EPS size too big?

Initial Comment:
Pyx eps:330k, gnuplot eps:50k ?!?
Is there something wrong here?

Also v7.0.1 seems to typeset "\beta" wrongly; "\beta" produces 
what I would get had I typed "\lambda eta". Most other Greek 
LaTex symbols work ok. (did not try all of them...)

On Mac OSX v10.3.7, with python v2.3

Thank you,
the...@4e...

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

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

[PyX-devel] [ pyx-Bugs-1161374 ] incorrect example misc/julia.py

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gert Ingold (gertingold)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect example misc/julia.py

Initial Comment:
It seems that in this example the arguments xiterations and
yiterations in the call to bitmap.image should be
interchanged.
This will become clear when making xiterations
different from
yiterations.

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

>Comment By: André Wobst (wobsta)
Date: 2005-03-11 16:23

Message:
Logged In: YES 
user_id=405853

Right. The data needs to be ordered left to right line by line *and* from top 
to bottom as its most common for bitmap data. Other order schemes could 
be implemented, but as long as nobody complains. Anyway, thanks for the 
report. Fixed in CVS.

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

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

[PyX-devel] [ pyx-Bugs-1161374 ] incorrect example misc/julia.py

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

Bugs item #1161374, was opened at 2005-03-11 14:07
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=1161374&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gert Ingold (gertingold)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect example misc/julia.py

Initial Comment:
It seems that in this example the arguments xiterations and
yiterations in the call to bitmap.image should be
interchanged.
This will become clear when making xiterations
different from
yiterations.

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

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

[PyX-devel] [ pyx-Support Requests-1112406 ] add the .dat files to the examples pages

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

Support Requests item #1112406, was opened at 2005-01-30 06:31
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442887&aid=1112406&group_id=45430

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Shane Geiger (shanerg)
Assigned to: Nobody/Anonymous (nobody)
Summary: add the .dat files to the examples pages

Initial Comment:
It would be most helpful to have the .dat files that
were used to generate the examples on the Web site
pyx.sf.net  

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

>Comment By: André Wobst (wobsta)
Date: 2005-02-14 14:11

Message:
Logged In: YES 
user_id=405853

I'm sorry for the late response. Due to a config error (misspelling of the 
email address) your request wasn't forwarded to the developer mailing 
list. Should be fixed now ...

Regarding your issue: To implement that, we could use a policy, that 
those additional files (like data files) should have the same basename. 
Than we could automate the inclusion of the dat-files easily. We do all 
the example pages automatically and that's an absolute requirement to 
keep.

But you may have noticed, that PyX comes with the full set of examples. 
Once you want to check out the examples yourself, you can just grab 
them from the tar-ball you already downloaded. So my answer is more 
like a question to the dev-list on whether to really implement that.

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

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

[PyX-devel] [ pyx-Bugs-1120100 ] Fails to build under non-root

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michal Čihař (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to build under non-root

Initial Comment:
setup.py build should not require root, however it
attempts to write to /usr/share/pyx:

+ python setup.py build
running build
running build_py
running install_data
creating /usr/share/pyx
error: could not create '/usr/share/pyx': Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.18551 (%build)

Attached patch changes way when siteconfig.py is written.

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

>Comment By: André Wobst (wobsta)
Date: 2005-02-10 19:02

Message:
Logged In: YES 
user_id=405853

setup.py rev. 1.29 should solve the problem. It keeps PyX running in the 
build directory by adjusting the relative paths. The absolute paths are 
inserted in install_lib as suggested by the original patch. It hopefully will 
solve the whole issue.

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

Comment By: André Wobst (wobsta)
Date: 2005-02-10 18:06

Message:
Logged In: YES 
user_id=405853

I see. I think, this is partially due to the fact, that its not totally trivial to 
create a siteconfig.py on the fly. You need to do something like what we 
already have. (In that sense its fine ... we already have it.)

OTOH I would not like to hard-code the position of the config file. Take 
fink where global config files are located at /sw/etc there. And what's /
etc on Windows? (Beside the problem, that "/" is not available and 
distutils fails although its not documented, but I'll work around that for 
the future.)

I think it would be best to also write some adjusted version of 
siteconfig.py in the build-directory. I'll just code that and then we'll see 
whether it fits everybodies needs ... (or at least almost everybodies)

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

Comment By: Michal Čihař (nijel)
Date: 2005-02-10 17:50

Message:
Logged In: YES 
user_id=192186

Well I prefer not to have such "configuration" files, so I
try to write some kind of autodetection (and hardcode config
file in /etc). You can find this in my application Wammu and
I saw simmilar thing in imgSeek.

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

Comment By: André Wobst (wobsta)
Date: 2005-02-10 17:36

Message:
Logged In: YES 
user_id=405853

Ok. My idea was to already create the final version of siteconfig.py in the 
build directory. But you're right that this is too much burden to cover for 
a build command. build_py should better not depend on install_data.

Anyway I like your suggestion in modifying install_lib instead of build_py 
and replace siteconfig.py right after the copy_tree performed by 
install_lib's install method. But why not keep the dependance on a 
modified version of install_data? I think its better to keep the path 
calculation for siteconfig.py in install_data. Any objections?

BTW there is another problem with this new version (your and mine as 
well): PyX does not run from the build directory anymore, since there is 
no build_data to copy the data into the build directory and the 
siteconfig.py from PyX referes to some relative paths. Should we fix 
that? I'm not sure whether its needed to have a running version in the 
build directory, but that's something I do not yet like too much. We could 
*additionally* fix the siteconfig.py by our own build_py command but 
keep it to be relative paths. Or implement a build_data ... ?!

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

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

[PyX-devel] [ pyx-Bugs-1120100 ] Fails to build under non-root

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Čihař (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to build under non-root

Initial Comment:
setup.py build should not require root, however it
attempts to write to /usr/share/pyx:

+ python setup.py build
running build
running build_py
running install_data
creating /usr/share/pyx
error: could not create '/usr/share/pyx': Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.18551 (%build)

Attached patch changes way when siteconfig.py is written.

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

>Comment By: André Wobst (wobsta)
Date: 2005-02-10 18:06

Message:
Logged In: YES 
user_id=405853

I see. I think, this is partially due to the fact, that its not totally trivial to 
create a siteconfig.py on the fly. You need to do something like what we 
already have. (In that sense its fine ... we already have it.)

OTOH I would not like to hard-code the position of the config file. Take 
fink where global config files are located at /sw/etc there. And what's /
etc on Windows? (Beside the problem, that "/" is not available and 
distutils fails although its not documented, but I'll work around that for 
the future.)

I think it would be best to also write some adjusted version of 
siteconfig.py in the build-directory. I'll just code that and then we'll see 
whether it fits everybodies needs ... (or at least almost everybodies)

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

Comment By: Michal Čihař (nijel)
Date: 2005-02-10 17:50

Message:
Logged In: YES 
user_id=192186

Well I prefer not to have such "configuration" files, so I
try to write some kind of autodetection (and hardcode config
file in /etc). You can find this in my application Wammu and
I saw simmilar thing in imgSeek.

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

Comment By: André Wobst (wobsta)
Date: 2005-02-10 17:36

Message:
Logged In: YES 
user_id=405853

Ok. My idea was to already create the final version of siteconfig.py in the 
build directory. But you're right that this is too much burden to cover for 
a build command. build_py should better not depend on install_data.

Anyway I like your suggestion in modifying install_lib instead of build_py 
and replace siteconfig.py right after the copy_tree performed by 
install_lib's install method. But why not keep the dependance on a 
modified version of install_data? I think its better to keep the path 
calculation for siteconfig.py in install_data. Any objections?

BTW there is another problem with this new version (your and mine as 
well): PyX does not run from the build directory anymore, since there is 
no build_data to copy the data into the build directory and the 
siteconfig.py from PyX referes to some relative paths. Should we fix 
that? I'm not sure whether its needed to have a running version in the 
build directory, but that's something I do not yet like too much. We could 
*additionally* fix the siteconfig.py by our own build_py command but 
keep it to be relative paths. Or implement a build_data ... ?!

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

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

[PyX-devel] [ pyx-Bugs-1120100 ] Fails to build under non-root

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

Bugs item #1120100, was opened at 2005-02-10 16:31
Message generated for change (Comment added) made by nijel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442886&aid=1120100&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Čihař (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to build under non-root

Initial Comment:
setup.py build should not require root, however it
attempts to write to /usr/share/pyx:

+ python setup.py build
running build
running build_py
running install_data
creating /usr/share/pyx
error: could not create '/usr/share/pyx': Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.18551 (%build)

Attached patch changes way when siteconfig.py is written.

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

>Comment By: Michal Čihař (nijel)
Date: 2005-02-10 17:50

Message:
Logged In: YES 
user_id=192186

Well I prefer not to have such "configuration" files, so I
try to write some kind of autodetection (and hardcode config
file in /etc). You can find this in my application Wammu and
I saw simmilar thing in imgSeek.

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

Comment By: André Wobst (wobsta)
Date: 2005-02-10 17:36

Message:
Logged In: YES 
user_id=405853

Ok. My idea was to already create the final version of siteconfig.py in the 
build directory. But you're right that this is too much burden to cover for 
a build command. build_py should better not depend on install_data.

Anyway I like your suggestion in modifying install_lib instead of build_py 
and replace siteconfig.py right after the copy_tree performed by 
install_lib's install method. But why not keep the dependance on a 
modified version of install_data? I think its better to keep the path 
calculation for siteconfig.py in install_data. Any objections?

BTW there is another problem with this new version (your and mine as 
well): PyX does not run from the build directory anymore, since there is 
no build_data to copy the data into the build directory and the 
siteconfig.py from PyX referes to some relative paths. Should we fix 
that? I'm not sure whether its needed to have a running version in the 
build directory, but that's something I do not yet like too much. We could 
*additionally* fix the siteconfig.py by our own build_py command but 
keep it to be relative paths. Or implement a build_data ... ?!

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

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

[PyX-devel] [ pyx-Bugs-1120100 ] Fails to build under non-root

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Čihař (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to build under non-root

Initial Comment:
setup.py build should not require root, however it
attempts to write to /usr/share/pyx:

+ python setup.py build
running build
running build_py
running install_data
creating /usr/share/pyx
error: could not create '/usr/share/pyx': Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.18551 (%build)

Attached patch changes way when siteconfig.py is written.

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

>Comment By: André Wobst (wobsta)
Date: 2005-02-10 17:36

Message:
Logged In: YES 
user_id=405853

Ok. My idea was to already create the final version of siteconfig.py in the 
build directory. But you're right that this is too much burden to cover for 
a build command. build_py should better not depend on install_data.

Anyway I like your suggestion in modifying install_lib instead of build_py 
and replace siteconfig.py right after the copy_tree performed by 
install_lib's install method. But why not keep the dependance on a 
modified version of install_data? I think its better to keep the path 
calculation for siteconfig.py in install_data. Any objections?

BTW there is another problem with this new version (your and mine as 
well): PyX does not run from the build directory anymore, since there is 
no build_data to copy the data into the build directory and the 
siteconfig.py from PyX referes to some relative paths. Should we fix 
that? I'm not sure whether its needed to have a running version in the 
build directory, but that's something I do not yet like too much. We could 
*additionally* fix the siteconfig.py by our own build_py command but 
keep it to be relative paths. Or implement a build_data ... ?!

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

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

[PyX-devel] [ pyx-Bugs-1120100 ] Fails to build under non-root

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

Bugs item #1120100, was opened at 2005-02-10 16:31
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=1120100&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Čihař (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to build under non-root

Initial Comment:
setup.py build should not require root, however it
attempts to write to /usr/share/pyx:

+ python setup.py build
running build
running build_py
running install_data
creating /usr/share/pyx
error: could not create '/usr/share/pyx': Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.18551 (%build)

Attached patch changes way when siteconfig.py is written.

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

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

Re: [PyX-devel] Re: [PyX-user] bar chart x-axis custom labels

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

Hi Pieter,

On 10.02.05, pieter claassen wrote:
> Last few questions regarding clean-up and axis:
> 
> 1. Is getting the path cleaned-up as simple as adding the appropriate
> start and finishing points to not start in thin air?

In practice yes. I think the suggested style will work for you at the
moment quite well. But its not a solution to be added to the PyX core.
I'll give you some hints, why I think so.

> 2. I haven't check the axis, but will the parter do the right thing with
> labels if I add large numbers of data points? (I am at work otherwise I
> would have checked this myself;-)

Sure, the parter will do (mostly), what you want. If it doesn't, you
could use the handy "density" parameter of the axis, or, when you want
more control, put your own parter in (for example a manual parter). Or
place some manual marks yourself. Since you have a standard linear (or
logarithmic) axis now, you can do all these "standard" things ...

> 3. Anything else that you think needs to be cleaned up?

Just some ideas, which to my mind need to be addressed:

- Make the graph dimensions interchangeable.
- Add the baseline of the histogram (like fromvalue in barpos).
- Add some kind of variable width handling. In the first this will
  lead to some more verbose data need to be passed into the style. I
  would start in using the pos and range style. Just like an errorbar.
  Starting from that we could add some histogram data creation, which
  could (a) calculate the width or (b) make some educated guess for
  the widths out of the data it gets.
- Proper handling of "out of graph" parts (i.e. skip them). Do not use
  clipping for that.
- Some graphical enhancements: A switch to make the histogram
  step-like (as in gnuplot) or barlike (with lines down to the
  baseline as we have it now). And the output path should be improved
  (be sophisticated and use as less path items as possible).

That would be cool.


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] bar chart x-axis custom labels

[pieter c. <pi...@cl...>]

Last few questions regarding clean-up and axis:

1. Is getting the path cleaned-up as simple as adding the appropriate
start and finishing points to not start in thin air?
2. I haven't check the axis, but will the parter do the right thing with
labels if I add large numbers of data points? (I am at work otherwise I
would have checked this myself;-)
3. Anything else that you think needs to be cleaned up?

Pieter



> Hi,
>
> On 07.02.05, pieter claassen wrote:
>> I did run your example code and attached is the result. Something looks
>> like it is not working. Any suggestions?
>
> Just to get the list informed: We've solved this by private mail. It
> was an indentation problem (a statement was inside an else branch by
> accident). Happy PyXing ...
>
>
> André
>
> --
> by  _ _      _    Dr. André Wobst
>    / \ \    / )   wo...@us..., http://www.wobsta.de/
>   / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
>  (_/ \_)_/\_/           visit http://pyx.sourceforge.net/
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> PyX-devel mailing list
> PyX...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
>

Re: [PyX-devel] Re: [PyX-user] bar chart x-axis custom labels

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

Hi,

On 07.02.05, pieter claassen wrote:
> I did run your example code and attached is the result. Something looks
> like it is not working. Any suggestions?

Just to get the list informed: We've solved this by private mail. It
was an indentation problem (a statement was inside an else branch by
accident). Happy PyXing ...


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-Feature Requests-1118152 ] default args for data.(list|file)(x=1,y=2)

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

Feature Requests item #1118152, was opened at 2005-02-07 22:00
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1118152&group_id=45430

Category: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Francisco Dellatorre Borges (fdborges)
Assigned to: Nobody/Anonymous (nobody)
Summary: default args for data.(list|file)(x=1,y=2)

Initial Comment:

All graph data entries must have a x and y coordinates. 

It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.

Just as users (e.g.  me) of a cmd line plotting routine
expect to call

$ bozoplot results.dat 

with two columns entries:

0 1
1 3 etc

and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.

Francisco.

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

>Comment By: André Wobst (wobsta)
Date: 2005-02-10 13:43

Message:
Logged In: YES 
user_id=405853

Sure, many things could be done. But we do not use __call__ too much. 
(There is a use case in the attribute modification and thats fine but I 
don't know whether its appropriate at an data instance. May be ... could 
be. It would be kind of a convenience method.)

But back to your problem: You could just "decorate" an arbitrary callable 
thing by some additional keyword argument (when they are not 
overwritten). This could look like that:

def decorate(callable, **addkwargs):
    def decorator(*args, **kwargs):
        fullkwargs = addkwargs.copy()
        fullkwargs.update(kwargs)
        callable(*args, **fullkwargs)
    return decorator

def test(*args, **kwargs):
    print args, kwargs

test(1, 2, a=1, b=2)
testdeco = decorate(test, b=-2, c=-3)
testdeco(1, 2, a=1, b=2)

A way to go for you?

Beside that, Jörg, what's your opinion about making a data instance 
callable to create a new data instance out of an existing one. Thats what 
graph.data.data is for right now. But using graph.data.data we do not 
keep the old columns ...

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

Comment By: Francisco Dellatorre Borges (fdborges)
Date: 2005-02-10 12:32

Message:
Logged In: YES 
user_id=576554

1. I think a wrapper would be nice and I thought about
making one myself.
 
I have some code that already works as a wrapper but it's
scathered and as I need to deliver a thesis chapter by the
end of this month, I haven't actually started putting the
code pieces together.

2. Yet, I still would like to be able to code some things
faster and a wrapper won't help much at it. When drawing
some illustrative didactic graphs for my thesis, I end up
calling data.list 4 or 5 times in a file, (and that's using
attr.changelist([a,b,c]) to avoid extra calls as in:

g.plot([ data.list(i, x=1, y=2, text=3) for i in [pts, pts1,
pts2] ],
       [st.line([attr.changelist( 
[linewidth.thick, linewidth.normal,linewidth.normal] ),
                 attr.changelist( 
[linestyle.solid, linestyle.dashdotted, linestyle.dashdotted
] )]),
        st.text(textdx=0.5, textdy=0)])

Perhaps allow setting default values at a data.list instance
initialization and then allow more instances to be created
from this one?

dlst = data.list(None, x=1, y=2, dy=3) # setting default values.
g.plot(dlst(d1, text=4), style1)
g.plot(dlst(d2, stacked=4), style2)

I don't know exactly how this should be implemented, as you
seem to need different data.list objects to process, the
class object would have to became a object factory
separating the current data.list.__init__ method into 
__init__ and __call__. Hackish solutions in this direction
would be easy to implement and a more clean version
shouldn't be too much of a problem.

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

Comment By: Jörg Lehmann (joergl)
Date: 2005-02-08 09:55

Message:
Logged In: YES 
user_id=390410

I agree with André. Such a policy should not be part
of the data component. In order to support quick&easy
plotting, a wrapper providing some standard plot types as
suggested recently by Michael Hagemann on the pyx-user is
the way to go. 

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

Comment By: André Wobst (wobsta)
Date: 2005-02-08 09:06

Message:
Logged In: YES 
user_id=405853

Couldn't you do this within your bozoplot command? The point is that 
graph.data.file and the like do not know anything about the column 
names they need to fill with data. It's designed the other way around. 
You provide some data and the graph styles (by the help of the axis 
names available in the graph) will tell you, whether this is a valid 
request. I do not want to stress that too much, especially since we 
currently have an xy graph only, but the axis names could be completely 
different in an polar plot, a 3-d plot etc. And other graph styles like text, 
arrow, errorbars etc. want other data as well. I would not like to see a 
semi-guessing solution in PyX. Comments?

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

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

[PyX-devel] [ pyx-Feature Requests-1118152 ] default args for data.(list|file)(x=1,y=2)

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

Feature Requests item #1118152, was opened at 2005-02-07 22:00
Message generated for change (Comment added) made by fdborges
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1118152&group_id=45430

Category: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Francisco Dellatorre Borges (fdborges)
Assigned to: Nobody/Anonymous (nobody)
Summary: default args for data.(list|file)(x=1,y=2)

Initial Comment:

All graph data entries must have a x and y coordinates. 

It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.

Just as users (e.g.  me) of a cmd line plotting routine
expect to call

$ bozoplot results.dat 

with two columns entries:

0 1
1 3 etc

and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.

Francisco.

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

>Comment By: Francisco Dellatorre Borges (fdborges)
Date: 2005-02-10 12:32

Message:
Logged In: YES 
user_id=576554

1. I think a wrapper would be nice and I thought about
making one myself.
 
I have some code that already works as a wrapper but it's
scathered and as I need to deliver a thesis chapter by the
end of this month, I haven't actually started putting the
code pieces together.

2. Yet, I still would like to be able to code some things
faster and a wrapper won't help much at it. When drawing
some illustrative didactic graphs for my thesis, I end up
calling data.list 4 or 5 times in a file, (and that's using
attr.changelist([a,b,c]) to avoid extra calls as in:

g.plot([ data.list(i, x=1, y=2, text=3) for i in [pts, pts1,
pts2] ],
       [st.line([attr.changelist( 
[linewidth.thick, linewidth.normal,linewidth.normal] ),
                 attr.changelist( 
[linestyle.solid, linestyle.dashdotted, linestyle.dashdotted
] )]),
        st.text(textdx=0.5, textdy=0)])

Perhaps allow setting default values at a data.list instance
initialization and then allow more instances to be created
from this one?

dlst = data.list(None, x=1, y=2, dy=3) # setting default values.
g.plot(dlst(d1, text=4), style1)
g.plot(dlst(d2, stacked=4), style2)

I don't know exactly how this should be implemented, as you
seem to need different data.list objects to process, the
class object would have to became a object factory
separating the current data.list.__init__ method into 
__init__ and __call__. Hackish solutions in this direction
would be easy to implement and a more clean version
shouldn't be too much of a problem.

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

Comment By: Jörg Lehmann (joergl)
Date: 2005-02-08 09:55

Message:
Logged In: YES 
user_id=390410

I agree with André. Such a policy should not be part
of the data component. In order to support quick&easy
plotting, a wrapper providing some standard plot types as
suggested recently by Michael Hagemann on the pyx-user is
the way to go. 

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

Comment By: André Wobst (wobsta)
Date: 2005-02-08 09:06

Message:
Logged In: YES 
user_id=405853

Couldn't you do this within your bozoplot command? The point is that 
graph.data.file and the like do not know anything about the column 
names they need to fill with data. It's designed the other way around. 
You provide some data and the graph styles (by the help of the axis 
names available in the graph) will tell you, whether this is a valid 
request. I do not want to stress that too much, especially since we 
currently have an xy graph only, but the axis names could be completely 
different in an polar plot, a 3-d plot etc. And other graph styles like text, 
arrow, errorbars etc. want other data as well. I would not like to see a 
semi-guessing solution in PyX. Comments?

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

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

[PyX-devel] [ pyx-Feature Requests-1118152 ] default args for data.(list|file)(x=1,y=2)

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

Feature Requests item #1118152, was opened at 2005-02-07 22:00
Message generated for change (Comment added) made by joergl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1118152&group_id=45430

Category: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Francisco Dellatorre Borges (fdborges)
Assigned to: Nobody/Anonymous (nobody)
Summary: default args for data.(list|file)(x=1,y=2)

Initial Comment:

All graph data entries must have a x and y coordinates. 

It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.

Just as users (e.g.  me) of a cmd line plotting routine
expect to call

$ bozoplot results.dat 

with two columns entries:

0 1
1 3 etc

and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.

Francisco.

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

>Comment By: Jörg Lehmann (joergl)
Date: 2005-02-08 09:55

Message:
Logged In: YES 
user_id=390410

I agree with André. Such a policy should not be part
of the data component. In order to support quick&easy
plotting, a wrapper providing some standard plot types as
suggested recently by Michael Hagemann on the pyx-user is
the way to go. 

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

Comment By: André Wobst (wobsta)
Date: 2005-02-08 09:06

Message:
Logged In: YES 
user_id=405853

Couldn't you do this within your bozoplot command? The point is that 
graph.data.file and the like do not know anything about the column 
names they need to fill with data. It's designed the other way around. 
You provide some data and the graph styles (by the help of the axis 
names available in the graph) will tell you, whether this is a valid 
request. I do not want to stress that too much, especially since we 
currently have an xy graph only, but the axis names could be completely 
different in an polar plot, a 3-d plot etc. And other graph styles like text, 
arrow, errorbars etc. want other data as well. I would not like to see a 
semi-guessing solution in PyX. Comments?

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

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

[PyX-devel] [ pyx-Feature Requests-1118152 ] default args for data.(list|file)(x=1,y=2)

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

Feature Requests item #1118152, was opened at 2005-02-07 22:00
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1118152&group_id=45430

Category: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Francisco Dellatorre Borges (fdborges)
Assigned to: Nobody/Anonymous (nobody)
Summary: default args for data.(list|file)(x=1,y=2)

Initial Comment:

All graph data entries must have a x and y coordinates. 

It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.

Just as users (e.g.  me) of a cmd line plotting routine
expect to call

$ bozoplot results.dat 

with two columns entries:

0 1
1 3 etc

and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.

Francisco.

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

>Comment By: André Wobst (wobsta)
Date: 2005-02-08 09:06

Message:
Logged In: YES 
user_id=405853

Couldn't you do this within your bozoplot command? The point is that 
graph.data.file and the like do not know anything about the column 
names they need to fill with data. It's designed the other way around. 
You provide some data and the graph styles (by the help of the axis 
names available in the graph) will tell you, whether this is a valid 
request. I do not want to stress that too much, especially since we 
currently have an xy graph only, but the axis names could be completely 
different in an polar plot, a 3-d plot etc. And other graph styles like text, 
arrow, errorbars etc. want other data as well. I would not like to see a 
semi-guessing solution in PyX. Comments?

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

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

[PyX-devel] [ pyx-Feature Requests-1118152 ] default args for data.(list|file)(x=1,y=2)

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

Feature Requests item #1118152, was opened at 2005-02-07 22:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442889&aid=1118152&group_id=45430

Category: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Francisco Dellatorre Borges (fdborges)
Assigned to: Nobody/Anonymous (nobody)
Summary: default args for data.(list|file)(x=1,y=2)

Initial Comment:

All graph data entries must have a x and y coordinates. 

It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.

Just as users (e.g.  me) of a cmd line plotting routine
expect to call

$ bozoplot results.dat 

with two columns entries:

0 1
1 3 etc

and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.

Francisco.

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

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