plplot-devel — Technical discussion about PLplot development

RE: [Plplot-devel] Remove the deprecated sections in drivers.h and plcore.h?

[Geoffrey F. <fu...@ga...>]

This is the only message I can promise to generate before Monday.

The issue to which you refer, has a recent origin in the sense that
the "authoritative source in cf/configure.in" only appeared recently,
in the timeframe of the dyndrv work.  Before that, plcore.h and
drivers.h is where the stuff was authoritatively stored.

I don't myself view this as a particularly significant issue for a
release, since /users/ of the library can be oblivious to such
things.  Functionality matters for a release, style is of secondary
importance. 

Clearly we want this cleaned up.  I left it in (the header files) as a
record, since we have to keep refering back to it from time to time.
Maybe the transition is mostly complete by now, I don't know.  But for
sure, there needs to be a clear, and documented procedure for adding a
driver, which covers all the points.  If such exists, then I'm for
eliminating all the junk code.  But if not, then lets don't prune the
code before the production of suitable documentation.

I haven't reviewed the documentation lately, so do not actually know
where we stand on that.

I'll /try/ to read email this weekend in case anyone follows up to this,
but can't promise to respond before Monday.

Alan W. Irwin writes:
 > This is mostly directed to Geoffrey.
 > 
 > When I was trying to understand the cgm driver a while back, I noticed the
 > huge
 > 
 > #if 0
 > 
 > #endif
 > 
 > blocks in include/drivers.h and include/plcore.h.
 > 
 > Any objection to me just completely removing these code blocks?  In the latter
 > case (at least) some of the drivers are missing so I got the device number
 > wrong for cgm the first time I tried it.  The definitive source of device
 > numbers is actually cf/configure.in so to have it also (sorta) in plcore.h
 > is not good.
 > 
 > Geoffrey, if this is a no-brainer, I would appreciate an immediate response
 > so I can get on with things.  If you need more time to think about this, I
 > will try to remember not to take any action on this until late tomorrow.
 > 
 > Alan
 > 
 > email: ir...@be...
 > phone: 250-727-2902	FAX: 250-721-7715
 > snail-mail:
 > Dr. Alan W. Irwin
 > Department of Physics and Astronomy,
 > University of Victoria, P.O. Box 3055,
 > Victoria, British Columbia, Canada, V8W 3P6
 > __________________________
 > 
 > Linux-powered astrophysics
 > __________________________
 > 
 > 
 > _______________________________________________
 > Plplot-devel mailing list
 > Plp...@li...
 > https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Remove the deprecated sections in drivers.h and plcore.h?

[Alan W. I. <ir...@be...>]

This is mostly directed to Geoffrey.

When I was trying to understand the cgm driver a while back, I noticed the
huge

#if 0

#endif

blocks in include/drivers.h and include/plcore.h.

Any objection to me just completely removing these code blocks?  In the latter
case (at least) some of the drivers are missing so I got the device number
wrong for cgm the first time I tried it.  The definitive source of device
numbers is actually cf/configure.in so to have it also (sorta) in plcore.h
is not good.

Geoffrey, if this is a no-brainer, I would appreciate an immediate response
so I can get on with things.  If you need more time to think about this, I
will try to remember not to take any action on this until late tomorrow.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Tk colour palettes

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > Maurice, thanks very much for getting this feature to work.  It looks pretty
 > cool, and you are going to turn me into a GUI believer, if I am not
 > careful....;-)

You should try out the cmap1 palette stuff with x16c, e.g. load some of the
other trial palettes and move the positions of the control points around in
cmap1 space.  cool....

-- 
Maurice LeBrun    mj...@ga...

[Plplot-devel] Tk colour palettes

[Alan W. I. <ir...@be...>]

Maurice, thanks very much for getting this feature to work.  It looks pretty
cool, and you are going to turn me into a GUI believer, if I am not
careful....;-)

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] README's

[Alan W. I. <ir...@be...>]

OK, I have done most of the renaming of README's indicated in my previous
e-mail.  I left bindings/octave/README alone because that was clearly
a general-type README.  I also left bindings/perl5/README alone because
the perl port is still very much a work in the very early stages of its
existence, and I suspect Rafael will be doing lots or reorganization there.

I finally succumbed to Joao's nagging (;-) (which seriously is a well-taken
point for many of our README files), and made some modifications to
README.pythonbuild.  Sometimes it is just easier to do simple stuff like
this immediately rather than prioritizing it.  I also made a README.javaAPI,
which is edited e-mail from Geoffrey about how to add PLplot API to the java
front end.  This should always be relevant even after we catch up to the
present PLplot API, because that API continues to evolve with added
functions, etc. I will make similar files for tcl and python since I have
added API to both of those front ends recently.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] python README (Was: Wish list for the release--various thoughts.)

[Alan W. I. <ir...@be...>]

On Fri, 18 Jan 2002, Joao Cardoso wrote:

> Are the following statements in bindings/python/README still true?

....

They need some revision.  Just like some of the other README files we have
scattered around as you have also rightly pointed out.  This is a
long-standing problem that we are slowly getting right, but since the
same problem occurred for 5.0.4, it is definitely not release critical for
5.1.0.

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Alan W. I. <ir...@be...>]

On Fri, 18 Jan 2002, Maurice LeBrun wrote:

>  >  > I think that 5.1.0 is a fine choice.

OK. I will stick with it.

>  >
>  > One question -- will dyndrivers be turned on by default?  Right now it's not.

My tests indicate that dynamic drivers are fine so I am comfortable with
turning them on by default.  However, I am getting quite pressed for time
so please make the configuration changes yourself.

>
> BTW, would anyone mind if I changed the configure option from:
>
>  --enable-dynamic-drivers
>
> to
>
>  --enable-dyndrivers
>
> ?

Sounds fine to me.

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Joao C. <jc...@fe...>]

On Friday 18 January 2002 2:54 am, Alan W. Irwin wrote:
> On Fri, 18 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> > On Thursday 17 January 2002 17:15, Alan W. Irwin wrote:
=2E..
> > [....] My not yet commited plimage() changes and related
> > functions are yet alpha. At this point I'm afraid of commiting my
> > changes, as perhaps the current cvs plimage() is more stable than
> > mine.
>
> But the point is this does not affect anything other than x20c.  It wou=
ld
> be a much tougher decision if you were fiddling with the very inner cor=
e of
> plplot, but you are not.

I'm not sure about that. Working with plstrm.h, plcore.c, plbuf.c and xwi=
n.c=20
might break others things.

>  I hope to get out the next release within a month
> or two so if you make a mistake with plimage now, it will soon get
> corrected.  So I am inclined to say that if x20c still works on your
> platform with all your uncommitted changes, then go ahead and commit th=
em.
> However, if you are not comfortable with that, that is fine as well.
> Ultimately, of course, it is your decision.

I have checked out a clean cvs and test x20c; it's more stable than my=20
current cvs, so I will not commit my changes for now.
=2E..

> > What I mean is that 5.1 is too definitive for the current status.
> > As you say, we are not many, and can't afford the pressure of a
> > faulty major release.
>
> My understanding of release traditions is quite different.  Patch versi=
on 0
> of anything is never expected to be reliable.  Compare kernel 2.4.0 wit=
h
> 2.4.17 or KDE 2.2.0 with 2.2.2, for example.

But it is not "intencional". We *know* that, given the nature of things,=20
version 0 is unstable, no matter the efforts developpers made. But if you=
=20
look at KDE, e.g., the 0 release is quite usable and is followed shortly =
by a=20
bug correcting release. Gnome has even a shorter history release.

But as Geoffrey said, you are the boss in this matter, and I'm glad you a=
re=20
:-)

Joao

Re: [Plplot-devel] python README (Was: Wish list for the release--various thoughts.)

[Joao C. <jc...@fe...>]

On Friday 18 January 2002 5:13 am, Geoffrey Furnish wrote:
> Jo=E3o Cardoso writes:
>  > Again CVS logs don't lie: the files in that subdir (Setup and
>  > _tkinter.c) are a "Complete sample of files edited according to the
>  > prescription in bindings/python/README". They must be leftovers from
>  > the static python building, I guess.
>  >
>  > My concern with unknow source or configuration files in cvs is...
>  > concern. New people may lose time looking what they are for, there
>  > might be configuartion support for them, turning configuration issue=
s
>  > more complicated, there might be side-effects, etc.
>
> Mmm, well, I wouldn't call them "leftovers", in thee sense of having
> become obsolete or something.  I personally don't use the PLplot
> python binding any other way than by using the static binding, because
> that gives me access to the plframe widget, which is not yet available
> any other way.  So I do not want to see stuff pertaining to the static
> plplot python binding removed, until we recover plframe via TEA inside
> python/Tk.  I figure that's still a ways out.

OK, I understand it now.

Are the following statements in bindings/python/README still true?

"How to build yourself a python with PLplot support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are two possibilities.  You can try to build a dynamically
loadable python module, or you can modify the python build to include
the plplot module.  The former is what configure will try to do if you
use --enable-python (which is the default).  Currently this does not
work very well.  I have had some success with this plan on Linux, but
not on other Unices yet.  So, I suggest, and this document describes,
to modify the python and rebuild it."=09

Joao

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Joao C. <jc...@fe...>]

On Friday 18 January 2002 1:28 am, I wrote wrote:
=2E..
> (And sgml was "made" because xml was too complicated for everyday
> usage.)

This is wrong, it is exactly the reverse. I just mixed it in my mind, aft=
er=20
reading "The Latex Web Companion".

Joao

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > Maurice LeBrun writes:
 >  > Alan W. Irwin writes:
 >  >  > I don't care that much about version numbers except that I don't want to go
 >  >  > through them too rapidly.  My understanding is the major number should be
 >  >  > incremented for huge changes, the minor number should be incremented for
 >  >  > fairly large changes, and the patch number incremented for smaller changes.
 >  >  > I absolutely agree with you there have been some fairly large changes made
 >  >  > since 5.0.4.  Thus, I assumed it was appropriate to increment the minor
 >  >  > number and move on to 5.1.0.  But if the developers here feel that 5.0.5 is
 >  >  > more appropriate, that is certainly fine with me!
 >  > 
 >  > I think that 5.1.0 is a fine choice.
 > 
 > One question -- will dyndrivers be turned on by default?  Right now it's not.

BTW, would anyone mind if I changed the configure option from:

 --enable-dynamic-drivers

to

 --enable-dyndrivers

?

The extra hyphen make it confusing IMO when trying to figure out what the
corresponding configure variable is (in this case, it's enable_dynamic_drivers
rather than enable_dynamic-drivers).

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > I don't care that much about version numbers except that I don't want to go
 >  > through them too rapidly.  My understanding is the major number should be
 >  > incremented for huge changes, the minor number should be incremented for
 >  > fairly large changes, and the patch number incremented for smaller changes.
 >  > I absolutely agree with you there have been some fairly large changes made
 >  > since 5.0.4.  Thus, I assumed it was appropriate to increment the minor
 >  > number and move on to 5.1.0.  But if the developers here feel that 5.0.5 is
 >  > more appropriate, that is certainly fine with me!
 > 
 > I think that 5.1.0 is a fine choice.

One question -- will dyndrivers be turned on by default?  Right now it's not.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > I don't care that much about version numbers except that I don't want to go
 > through them too rapidly.  My understanding is the major number should be
 > incremented for huge changes, the minor number should be incremented for
 > fairly large changes, and the patch number incremented for smaller changes.
 > I absolutely agree with you there have been some fairly large changes made
 > since 5.0.4.  Thus, I assumed it was appropriate to increment the minor
 > number and move on to 5.1.0.  But if the developers here feel that 5.0.5 is
 > more appropriate, that is certainly fine with me!

I think that 5.1.0 is a fine choice.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > Branches are useful for the really big changes
 > such as dynamic drivers, but I personally lost weeks of work on the tea
 > branch because there wasn't a critical mass of interested developers at the
 > time.  

Just BTW, I'm still benefitting from it, so it wasn't lost work from my
perspective.  I'm just getting to it piecemeal.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Maurice L. <mj...@ga...>]

Joao Cardoso writes:
 > The ToDo and PROBLEMS file also needs an update, as some users can have the 
 > expertise and mood to do/solve it. WE *should* use it, also!

The problem with todo files is that if associated with a project they never
reflect your personal priorities so I end up keeping a personal todo file.
Always.  Now, if we shared our todo files, then maybe we'd have something.
That way if I did something that was on everyone's todo, I'd be a hero; if
I saw that two of us had the same item, we could work something out, etc..

Even then I tend to separate it into short term, medium term, and gee it'd be
nice categories.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] next release

[Maurice L. <mj...@ga...>]

Geoffrey Furnish writes:
 > My really truly final viewpoint on this, is that I don't think we
 > should have a release with a broken tk driver.  I would call that a
 > showstopper.  I just hope I'm not the guilty party on that one...

Well, a combo of things happened there.  One, a bad assumption on the max
number of max file devices (my bad), two, increase in the number of file
devices, three, the default configure doesn't exclude any devices (which
I don't particularly like) and in fact is broken in this regard (which I
plan to fix).  In any case, it will be fixed, as I'm on flat-out plplot
mode right now, up to my ears in the palette tools which are coming soon..

-- 
Maurice LeBrun    mj...@ga...

[Plplot-devel] next release

[Geoffrey F. <fu...@ga...>]

Interesting discussion.

I am okay with 5.1.0, also okay with 5.0.5.  I think enough has
happened to justify calling it 5.1.0.  

One variance I have from what Alan said, is that I don't view major
version numbers as being strictly a way to denote major change.  Major
feature stabilization is itself noteworthy.  When we get TEA in,
dynamic drivers made the default, and java support enabled by default,
I would be happy to call it 6.0.0.  But I'd also want to see a doc
shakedown run before that too.  This is effectively what was hinted at
by the 4.99* series.  The idea was we felt it was nearly time to call
it 5.0, but just wanted to fix the last few bugs.  But we just never
got it all straight.

Well, things are different now, with all this activity, for which I am
very thankful to see such energy being poured into PLplot from so many
developers.  We are now able to have much more frequent, and more
substantive rleeases.  And the mere thought of bantering about release
numbers is almost enough to induce giggles all by itself.  My how far
PLplot has come!

My final (well, err, next to final, see below) viewpoint is that Alan
is playing the release-meister role, and has final say on numbering,
dates, etc.  Certainly, if it were up to me, as in the (now thankfully
distant) past, there would be no release in January... :-).

My really truly final viewpoint on this, is that I don't think we
should have a release with a broken tk driver.  I would call that a
showstopper.  I just hope I'm not the guilty party on that one...

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Geoffrey F. <fu...@ga...>]

Jo=E3o Cardoso writes:
 > Again CVS logs don't lie: the files in that subdir (Setup and=20
 > _tkinter.c) are a "Complete sample of files edited according to the=20=

 > prescription in bindings/python/README". They must be leftovers from=
=20
 > the static python building, I guess.
 >=20
 > My concern with unknow source or configuration files in cvs is...=20=

 > concern. New people may lose time looking what they are for, there=20=

 > might be configuartion support for them, turning configuration issue=
s=20
 > more complicated, there might be side-effects, etc.

Mmm, well, I wouldn't call them "leftovers", in thee sense of having
become obsolete or something.  I personally don't use the PLplot
python binding any other way than by using the static binding, because
that gives me access to the plframe widget, which is not yet available
any other way.  So I do not want to see stuff pertaining to the static
plplot python binding removed, until we recover plframe via TEA inside
python/Tk.  I figure that's still a ways out.

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Alan W. I. <ir...@be...>]

On Fri, 18 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Thursday 17 January 2002 17:15, Alan W. Irwin wrote:
> | > When will be 5.1 released?
> |
> | 24 January.
>
> !?!
>
> I thought that this release would be 5.0.5! But if I were the boss we
> would continue until reaching release 5.0.31415926

;-)

>
> Seriously, there are too many new functionalities for this to be 5.1.
> Java is all new, python has suffered significative modifications,

I don't care that much about version numbers except that I don't want to go
through them too rapidly.  My understanding is the major number should be
incremented for huge changes, the minor number should be incremented for
fairly large changes, and the patch number incremented for smaller changes.
I absolutely agree with you there have been some fairly large changes made
since 5.0.4.  Thus, I assumed it was appropriate to increment the minor
number and move on to 5.1.0.  But if the developers here feel that 5.0.5 is
more appropriate, that is certainly fine with me!

For the others here, please let me know your feelings on this.

> [...] what else?... I can't use "plrender"
> with device tk,..

Neither can I, but this is the first I have heard of it!  (I tend to
do strictly non-interactive tests, and leave the interactive stuff to
the rest of you.)  I must have missed your bug report to the list....;-)

Here is mine....

Maurice, here are the symptoms (with dynamic drivers configured if that
makes a difference)

There is no problem if I executed

=2E/x01c -dev tk

However,

=2E/x01c -dev plmeta -o x01c.meta
=2E/plrender -i x01c.meta -dev tk
TCL command "
         invalid command name "

Can this bug be fixed before the release?

>
> [....] My not yet commited plimage() changes and related
> functions are yet alpha. At this point I'm afraid of commiting my
> changes, as perhaps the current cvs plimage() is more stable than
> mine.

But the point is this does not affect anything other than x20c.  It would b=
e
a much tougher decision if you were fiddling with the very inner core of
plplot, but you are not.  I hope to get out the next release within a month
or two so if you make a mistake with plimage now, it will soon get
corrected.  So I am inclined to say that if x20c still works on your
platform with all your uncommitted changes, then go ahead and commit them.
However, if you are not comfortable with that, that is fine as well.
Ultimately, of course, it is your decision.

> I have just added an option to x01c to show how one can
> programatically save a file (that is stable, I will commit it).
>
> What I mean is that 5.1 is too definitive for the current status.
> As you say, we are not many, and can't afford the pressure of a
> faulty major release.

My understanding of release traditions is quite different.  Patch version 0
of anything is never expected to be reliable.  Compare kernel 2.4.0 with
2.4.17 or KDE 2.2.0 with 2.2.2, for example.

That said, I do want the functionality that worked in 5.0.4 to continue to
work in 5.0.5 (or 5.1.0., whichever the developers here prefer).  I believe
that is the case.  It is only a small subset of the new things that have
been added that are not completely stabilized yet.  For example, dynamic
drivers seem to work perfectly for all but xwin and tk, and our
configuration scheme works around that problem so no user will be affected
by it (assuming that plrender bug gets fixed.) Java is of course considered
to be experimental since it is still incomplete, but for the defined API, i=
t
is rock solid.  Python no longer segfaults.  Thus, I will have no
compunction about telling all our users we no longer support 5.0.4, and it
is time to move to this next release (whatever version number we decide).

Alan

Re: [Plplot-devel] README naming conventions

[<jca...@in...>]

On Thursday 17 January 2002 21:36, Alan W. Irwin wrote:
| The name README.java causes some problems (since the .java
| extension means a java file on many systems including Linux) so it
| needs to be changed again.
|
| Any objections here to README.javademos?  That is in accord with
| README.tcldemos and README.tkdemos in their respective examples/tcl
| and examples/tk directories. I would also want to change
| examples/python/README.python to README.pythondemos, if we all
| agree on this convention.
|
| The other README convention question concerns binding/*/README.  I
| don't like a whole lot of different files called README since that
| can get confusing (even if they are all in different directories).=20
| So what do you think of changing the names to README.pythonbuild,
| README.tclbuild, etc. in the bindings directory tree?
|
| I have already discussed these two proposals with Geoffrey.  He had
| no strong feelings either way but suggested I bring it to the list
| so here it is.  I don't have strong feelings either except that I
| want the current README.java name changed to something other than
| README.
|
| So please give me some alternatives if you don't like the above
| proposed naming conventions.

That's fine for me. And looks consistent and self-explanatory.

Joao
|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 250-721-7715
| snail-mail:
| Dr. Alan W. Irwin
| Department of Physics and Astronomy,
| University of Victoria, P.O. Box 3055,
| Victoria, British Columbia, Canada, V8W 3P6
| __________________________
|
| Linux-powered astrophysics
| __________________________
|
|
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Wish list for the release--various thoughts.

[<jca...@in...>]

On Thursday 17 January 2002 17:15, Alan W. Irwin wrote:
| Joao, you have brought up a number of interesting points which I
| will attempt to answer in context below.
|
| Alan
=2E..

| On Thu, 17 Jan 2002, Joao Cardoso wrote:
| > Hi,
| >
| > I think that the main directory README, INSTALL, CHANGES and NEWS
| > files should be updated, as they are the first think that I read
| > on (and I assume others also do it :).
| > The ToDo and PROBLEMS file also needs an update, as some users
| > can have the expertise and mood to do/solve it. WE *should* use
| > it, also!
|
| I agree with both your points here.  I don't have time to start any
| of this myself so I would encourage you (after the release,
| please!) to change these files any way you like. Once you start to
| use them, I (and perhaps the other developers) will most likely
| follow.  Note, if there are any English problems with your changes,
| I would be willing to make corrections after you make your main
| changes.

As you say latter that this will be a major release, I think that=20
they should be changed now. But as nobody has the time now, I suggest=20
a 5.1.1 release to follow shortly after 5.1.0, with bug fixes and=20
improved docs.

You can quickly change the the README or NEWS files by just appending=20
the announcements you made when you release 5.0.1...5.0.4.

| > The examples/java/README file should be in bindings/java, or its
| > name changed to README.java, to follow what is done in the other
| > examples directory.
|
| Done.
|
| > I thinks that each bindings and examples subdirs should have a
| > README file, and the main README file should point to them.
|
| We are gradually getting there on the first point, and on the
| second point I say please go ahead.  I would be happy to see
| changes in the overall README before the release.

I will try it.

|
| > What is the purpose of the "new" directory and its "bogus" file?
| > And the bindings/python/1.4b3 subdir?
|
| Haven't got a clue.
|
| > When will be 5.1 released?
|
| 24 January.

!?!

I thought that this release would be 5.0.5! But if I were the boss we=20
would continue until reaching release 5.0.31415926

Seriously, there are too many new functionalities for this to be 5.1.=20
Java is all new, python has suffered significative modifications,=20
plimage() has still bugs on it, what else?... I can't use "plrender"=20
with device tk,..

| What do we intend to have on it?
|
| Current CVS HEAD plus any changes we do from now until then.  See
| my wishlist.
|
| > Can we add more
| > and more stuff to HEAD
|
| Yes, so long as it is useful.  plimage is an excellent example of
| such an add-on.
|
| and always have an unstable CVS?
|
| No.  For example, we are in a stabilizing phase right now in
| preparation for the release.

I don't agree. My not yet commited plimage() changes and related=20
functions are yet alpha. At this point I'm afraid of commiting my=20
changes, as perhaps the current cvs plimage() is more stable than=20
mine. I have just added an option to x01c to show how one can=20
programatically save a file (that is stable, I will commit it).

What I mean is that 5.1 is too definitive for the current status.
As you say, we are not many, and can't afford the pressure of a=20
faulty major release.

| We have discussed release philosophy many times before so I will
| try to keep this short.  As far as I am concerned, I never plan to
| make an experimental or unstable release.  Instead, periodically we
| work hard to stabilize cvs HEAD and release that.

Yes, but I was not aware of 5.1.0

| My own view is we are too small a project to support a lot of
| different branches.  For example, I never want to see a special
| stable branch (except periodically for CVS HEAD).

I agree.

|  Branches are
| useful for the really big changes such as dynamic drivers, but I
| personally lost weeks of work on the tea branch because there
| wasn't a critical mass of interested developers at the time.  Thus,
| you have to be really careful about splitting development up too
| much.  Taking the plimage example, again, I wouldn't have gotten
| interested in it if you hadn't put it on the HEAD.

So, it was my mistake. I would put it on a branch.

|  So for
| relatively small changes like this that don't impact a lot of other
| stuff, put them right on HEAD, then work to stabilize them in time
| for a release. Obviously, you are not quite satisfied with plimage
| yet ("work in progress"), but I am not personally going to worry if
| you change the API one more time after this release.  Users of new
| features have to expect API changes.  However, I do hope that the
| x20c example at least works for this release, and that you have
| plimage completely stabilized (including API decisions) in time for
| the release after this one.

Isn't the current x20c.c stable enought for you? As I said before, my=20
current changes are not so stable... I think, as I never run a clean=20
cvs HEAD again.

| > I would like to add some things to the documentation, after
| > english-proofing by an English native speaker, but I found the
| > DocBook too complex! I was still not able to create the
| > development environment (and I tried, and I tried, and I tried ,
| > but I couldn't get it :-)).
|
| I will be happy to help you get this sorted out, Joao.  But I need
| specifics from you off list.  (In the next few days I will be going
| through this for my own woody system and perhaps a RedHat 7.2
| system as well so now is an excellent time to get the DocBook
| development environment working on your system as well.)
|
| > Is there a xml2sgml utility?
| > ( My system has a sgml2xml utility). Than I could convert to
| > latex and add the docs.
|
| I have not heard of an xml2sgml facility.  sgml is being phased out
| in favor of xml so I think the sgml/xml language types would view
| xml2sgml as a retrograde step they were unwilling to support.

It is not xml that is complicated, is all the setup needed to run it!=20
DocBook is for book writers, editors and publishers, not for a lonely=20
graphics library. I personaly don't want to spend too much time=20
writing docs, and I want to it using my usual tools. But what is done=20
is done.

(And sgml was "made" because xml was too complicated for everyday=20
usage.)

| I
| think a much better solution is simply to get the DocBook-xml
| environment working on your system.  I will help, but as I said
| above, I need specifics about what doesn't work.  For example, how
| far did you get in README.developers?

Re-read it several times, installed several, possibly confliting=20
packages, looking for the tons of perl modules my system has and has=20
not... Don't worry, I will write the text, trying to use the tags=20
correctly, and I will submit it to you.

Thanks,
Joao

Re: [Plplot-devel] Wish list for the release--various thoughts.

[<jca...@in...>]

On Thursday 17 January 2002 19:25, Geoffrey Furnish wrote:
| Joao Cardoso writes:
|  > What is the purpose of the "new" directory and its "bogus" file?
|
| Mmmm.  Well, cvs log just about says it all.
|
| Or so it would seem.    <wink>

You are right, of course. The 'bogus' file is for "testing",...,"Just=20
a test", "foo". ;)

| :-).
| :
|  > And the bindings/python/1.4b3 subdir?
|
| Stuff that was needed to get PLplot working with python 1.4 beta 3.
|
| I haven't touched the python binding recently, so do not really
| have an up to date and first hand perspective on the current issues
| for the python binding, beyond what is gleaned by reading Alan's
| various emails on the subject.

Again CVS logs don't lie: the files in that subdir (Setup and=20
_tkinter.c) are a "Complete sample of files edited according to the=20
prescription in bindings/python/README". They must be leftovers from=20
the static python building, I guess.

My concern with unknow source or configuration files in cvs is...=20
concern. New people may lose time looking what they are for, there=20
might be configuartion support for them, turning configuration issues=20
more complicated, there might be side-effects, etc.

Joao

Re: [Plplot-devel] java install changes

[<jca...@in...>]

On Thursday 17 January 2002 16:26, Alan W. Irwin wrote:
| On Thu, 17 Jan 2002, Joao Cardoso wrote:
| > On Wednesday 16 January 2002 10:10 pm, Alan W. Irwin wrote:
| > > Joao, I wrote those instructions at your suggestion.  By all
| > > means please give the instructions a try, and let me know if
| > > they need any additions.
| > >
| > > Alan
| >
| > (1) Install a jdk (Java Development Kit).  I used the Blackdown
| > jdk-1.2.2 for Linux, but for that platform there is also an IBM
| > jdk if you prefer.
| >
| > I would say that it was also tested with sun-1.1.8 and IBM-1.3.0.
|
| Please expand a bit. I am not sure what you mean by sun-1.1.8.  Is
| this the Blackdown jdk 1.1.8 port for Linux?  By IBM-1.3.0 are you
| referring to their Linux port? Finally, are you saying you tested
| with both of these Linux jdk ports, and it worked fine for you?  If
| so, that is excellent news.
|
| Alan

I'm not shure if it is SUN java. Java examples worked in both=20
suse-7.0, where the default java is:

jcard@rick:~ > rpm -q java
java-1.1.8v3-1

jcard@rick:~/tmp/plplot-clean/tmp > rpm -qi java
Name        : java                         Relocations: (not=20
relocateable)
Version     : 1.1.8v3                           Vendor: SuSE GmbH,=20
Nuernberg, Germany
Release     : 1                             Build Date: Mon 18 Jun=20
2001 16:09:55 WEST
Install date: Tue 09 Oct 2001 23:47:48 WEST      Build Host:=20
amdsima.suse.de
Group       : Development                   Source RPM:=20
java-1.1.8v3-1.src.rpm
Size        : 39201909                         License: 1994, 1995,=20
1996, 1997 Sun Microsystems, Inc.
Packager    : fee...@su...
Summary     : Java Developers Kit
Description :
With this package you are able to create your own platform-independent
JAVA applications. You can compile your it with the Java compiler and
start it with the Java interpreter or the Appletviewer.
The authors of this package stipulated that the sources should not
cross hands more than two times. For this reason we are unable to
provide a source package for this program.
To get the sources, look at:=20
http://www.blackdown.org/java-linux/Mirrors.cgi
For more information please refer to /usr/share/doc/packages/java.

Authors:
--------
    Steve Byrne <sb...@gn...>

SuSE series: d
-------------------------------------------------------------------------=
-----------------------

and on suse-7.2, installing the (to pay), Suse supplied but not=20
default, IBM jdk:

[jcard@feup] rpm -qa | fgrep IBM
IBMJava2-JRE-1.3-67
IBMJava2-SDK-1.3-61

[jcard@feup] java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010626 (JIT=20
enabled: jitc))


Joao

[Plplot-devel] README naming conventions

[Alan W. I. <ir...@be...>]

The name README.java causes some problems (since the .java extension means a
java file on many systems including Linux) so it needs to be changed again.

Any objections here to README.javademos?  That is in accord with
README.tcldemos and README.tkdemos in their respective examples/tcl and
examples/tk directories. I would also want to change
examples/python/README.python to README.pythondemos, if we all agree on this
convention.

The other README convention question concerns binding/*/README.  I don't like
a whole lot of different files called README since that can get confusing
(even if they are all in different directories).  So what do you think of
changing the names to README.pythonbuild, README.tclbuild, etc. in the
bindings directory tree?

I have already discussed these two proposals with Geoffrey.  He had no
strong feelings either way but suggested I bring it to the list so here it
is.  I don't have strong feelings either except that I want the current
README.java name changed to something other than README.

So please give me some alternatives if you don't like the above proposed
naming conventions.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Wish list for the release--various thoughts.

[Geoffrey F. <fu...@ga...>]

Joao Cardoso writes:
 > What is the purpose of the "new" directory and its "bogus" file? 

Mmmm.  Well, cvs log just about says it all.  

Or so it would seem.    <wink>

:-).

 > And the bindings/python/1.4b3 subdir?

Stuff that was needed to get PLplot working with python 1.4 beta 3.

I haven't touched the python binding recently, so do not really have
an up to date and first hand perspective on the current issues for the
python binding, beyond what is gleaned by reading Alan's various
emails on the subject.

-- 
Geoffrey Furnish         fu...@ga...