plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Core width patch

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

OK.  Since nobody felt strongly about this I have just gone ahead and
committed the ability to set width =0 in plcore, plargs.  I have also
commited the change in the API documentation source.

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
__________________________

On Fri, 22 Feb 2002, Alan W. Irwin wrote:

> On Fri, 22 Feb 2002, Olof Svensson wrote:
>
> >   (Alexandre [Gobbo] writes) The line in plcore:
> >
> >     if (width != plsc->width && width > 0) {
> >
> >   avoids you from setting width =0. But a width =0 has
> >   meaning in windows and unix, so I changed into
> >
> >         if (width != plsc->width && width >= 0) {
> >
> >   width=0 is a thin line, more efficiently drawn than width =1
>
> This is a (minor) API change so I thought this should be discussed on the
> list before I make the change (and also change the documentation
> appropriately).  I checked the code and apparently the setting width = 0
> should cause no problems because that is what it is by default.  (The
> PLStream memory area is malloced, then memset to zero.  BTW, couldn't this
> be done with calloc?)
>
> I didn't check in detail for every driver, but it looks like drivers that
> worry about width set the minimum possible appropriate width for that driver
> when they encounter width=0 which is how I will document this change if we
> all agree to it.
>
> Alan
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

On Sat, 23 Feb 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Maurice, although I don't have a deep understanding of the way dynamic
>  > drivers are done, I think I could probably handle most of this fix myself if
>  > you don't have time to deal with it at the moment.  Let me know what you
>  > decide.
>
> I would be thrilled if you could work on it. :)

OK, I will give it a shot. If I run into any trouble, I will be quick to
call for help....Alan

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

Alan W. Irwin writes:
 > Maurice, although I don't have a deep understanding of the way dynamic
 > drivers are done, I think I could probably handle most of this fix myself if
 > you don't have time to deal with it at the moment.  Let me know what you
 > decide.

I would be thrilled if you could work on it. :)

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

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

On Sat, 23 Feb 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > How about just using the library suffix (e.g., psd.drv for the
>  > double-precision version and ps.drv for the single precision version)
>  > instead on all dynamically loadable *.drv files?  Such a division of library
>  > names seems to work well for our libraries so it shouldn't be that difficult
>  > to extend it to the *.drv files.  I believe such a solution should be a lot
>  > simpler to maintain than rules about library function arguments.
>
> My further investigation of this problem shows this to be in fact the only way
> to solve it.  The ultimate sticky point is the offset into the PLStream
> structure by the pls pointer -- if the PLFLT defn's don't match up, it's
> wrong.  I don't see any way to solve this except dual precision drivers.

I have looked further into the dual-precision driver solution.  From the
README.drivers commentary in drivers it should be fairly straightforward,
but to keep a clean separation between single/double you will need
drivers.db (filled with the single-precision names) and driversd.db (filled
with the double-precision names).  Currently, the only C-code references I
can find to drivers.db is in plcore.c. Those will have to be replaced by a
configured name of either drivers.db or driversd.db. Perhaps the easiest way
to handle this is with a configured symbolic constant much like the way
PLFLT itself is handled.

Maurice, although I don't have a deep understanding of the way dynamic
drivers are done, I think I could probably handle most of this fix myself if
you don't have time to deal with it at the moment.  Let me know what you
decide.

Alan

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

Alan W. Irwin writes:
 > How about just using the library suffix (e.g., psd.drv for the
 > double-precision version and ps.drv for the single precision version)
 > instead on all dynamically loadable *.drv files?  Such a division of library
 > names seems to work well for our libraries so it shouldn't be that difficult
 > to extend it to the *.drv files.  I believe such a solution should be a lot
 > simpler to maintain than rules about library function arguments.

My further investigation of this problem shows this to be in fact the only way
to solve it.  The ultimate sticky point is the offset into the PLStream
structure by the pls pointer -- if the PLFLT defn's don't match up, it's
wrong.  I don't see any way to solve this except dual precision drivers.

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

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

How about just using the library suffix (e.g., psd.drv for the
double-precision version and ps.drv for the single precision version)
instead on all dynamically loadable *.drv files?  Such a division of library
names seems to work well for our libraries so it shouldn't be that difficult
to extend it to the *.drv files.  I believe such a solution should be a lot
simpler to maintain than rules about library function arguments.

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
__________________________

On Fri, 22 Feb 2002, Maurice LeBrun wrote:

> I recently ran into the following gotcha.  I had an application that ran just
> fine in double precision, but after installing a new version of plplot with
> float precision, it broke.  The reason: only one precision of dynamic drivers
> is built, and they're potentially being used in conjunction with both
> precision libraries.  This is a real recipe for trouble.
>
> My immediate problem looks to occur in plbuf_swin, which I will fix.  I'm also
> worried about any driver call to or from the plplot library that involves
> PLFLT's.  Fortunately, there's not too many.  For example, every driver
> calls plP_setpxl which passes PLFLT's on the stack.  Since ANSI C is not
> supposed to auto promote to double, this could be trouble.
>
> A possible solution is:
>  - drivers may only call internal plplot functions
>  - those functions callable by drivers that use PLFLT's in the argument list
> be changed to use double instead.
>
> --
> Maurice LeBrun    mj...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

I recently ran into the following gotcha.  I had an application that ran just
fine in double precision, but after installing a new version of plplot with
float precision, it broke.  The reason: only one precision of dynamic drivers
is built, and they're potentially being used in conjunction with both
precision libraries.  This is a real recipe for trouble.

My immediate problem looks to occur in plbuf_swin, which I will fix.  I'm also
worried about any driver call to or from the plplot library that involves
PLFLT's.  Fortunately, there's not too many.  For example, every driver
calls plP_setpxl which passes PLFLT's on the stack.  Since ANSI C is not
supposed to auto promote to double, this could be trouble.

A possible solution is:
 - drivers may only call internal plplot functions
 - those functions callable by drivers that use PLFLT's in the argument list
be changed to use double instead.

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

[Plplot-devel] Core width patch

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

On Fri, 22 Feb 2002, Olof Svensson wrote:

>   (Alexandre [Gobbo] writes) The line in plcore:
>
>     if (width != plsc->width && width > 0) {
>
>   avoids you from setting width =0. But a width =0 has
>   meaning in windows and unix, so I changed into
>
>         if (width != plsc->width && width >= 0) {
>
>   width=0 is a thin line, more efficiently drawn than width =1

This is a (minor) API change so I thought this should be discussed on the
list before I make the change (and also change the documentation
appropriately).  I checked the code and apparently the setting width = 0
should cause no problems because that is what it is by default.  (The
PLStream memory area is malloced, then memset to zero.  BTW, couldn't this
be done with calloc?)

I didn't check in detail for every driver, but it looks like drivers that
worry about width set the minimum possible appropriate width for that driver
when they encounter width=0 which is how I will document this change if we
all agree to it.

Alan

RE: [Plplot-devel] Possible bug in matrix initialization

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

On Tue, 19 Feb 2002, Maurice LeBrun wrote:

> Single quotes.. who uses those?  Oh yeah, Fortran...
>
> ;)

;-)

However, in the interests of historical accuracy I gotta say the point was
moot for my first Fortran compiler in 1968.  The only string that sucker had
was the one wrapped around the "PDQ compiler" card deck.  Before each task
that deck was read into the machine, then your fortran source on cards was
read into the machine.  That produced an object code deck which was then
read into the machine and executed. I still remember the great joy we all
had when we upgraded to an IBM 1130 that actually had a disk-resident
fortran compiler which would save your object code to disk and execute it
without fiddling with Fortran compiler object decks or your own object deck.

It was a year later in graduate school that we got access to a fortran
compiler that could deal (to a small extent) with character strings.  I
wonder whether the next 30 years in computing will have so many
revolutionary changes as the last 30 years?  I sure hope so!

Alan

RE: [Plplot-devel] Possible bug in matrix initialization

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

Alan W. Irwin writes:
 > On Tue, 19 Feb 2002, Maurice LeBrun wrote:
 > 
 > > The matrix initializer is expecting a Tcl list for input.  So if you want
 > > variables expanded, use quotes, not braces.
 > 
 > Single quotes failed, but double quotes succeeded so I am a happy camper now.

Single quotes.. who uses those?  Oh yeah, Fortran...

;)

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

RE: [Plplot-devel] Possible bug in matrix initialization

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

On Tue, 19 Feb 2002, Maurice LeBrun wrote:

> The matrix initializer is expecting a Tcl list for input.  So if you want
> variables expanded, use quotes, not braces.

Single quotes failed, but double quotes succeeded so I am a happy camper now.
(Or should I say I am Tcled pink?....;-))

Thanks, Maurice!

(Also thanks to Geoffrey for starting punning....)

Alan

RE: [Plplot-devel] Possible bug in matrix initialization

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

Geoffrey Furnish writes:
 > Alan W. Irwin writes:
 >  > I have been struggling with resetting the cmap1 to default values for tcl.
 >  > Turns out my problems were due to the following construct which I thought
 >  > should work to initialize the matrix.
 >  > 
 >  > matrix l f 6  = {0.5, $midpt, $vertex, $vertex, $midpt, 0.5}
 >  > 
 >  > This silently fails by sticking zeroes everywhere there is a variable
 >  > reference (i.e., all the interior points) even though the variables have
 >  > previously been set.  Isn't this a bug? Shouldn't the variables just be
 >  > replaced by their values?
 >  > 
 >  > I worked around this by using
 >  > 
 >  > l 1 = $midpt
 >  > l 2 = $vertex
 >  > 
 >  > etc., in x08.tcl,
 >  > 
 >  > but I don't think this workaround should be necessary.
 > 
 > :-).  It's called "Tcl" because you're supposed to giggle every time
 > it annoys you.
 > 
 > Braces protect against variable interpolation.
 > 
 > There's probably a way to get what you want using eval or list or
 > something.  

The matrix initializer is expecting a Tcl list for input.  So if you want
variables expanded, use quotes, not braces.

Unfortunately quotes are cumbersome for initializing a multidimensional array
(if even this works; it looks like it might but I haven't tried).  So ideally
the initializer would call Tcl_ExprDouble or Tcl_ExprLong in order to evaluate
the arguments.  I'll put it on my list of things to consider in my Tcl matrix
overhaul planned for later this year, but otherwise try using quotes.

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

RE: [Plplot-devel] Possible bug in matrix initialization

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

Alan W. Irwin writes:
 > I have been struggling with resetting the cmap1 to default values for tcl.
 > Turns out my problems were due to the following construct which I thought
 > should work to initialize the matrix.
 > 
 > matrix l f 6  = {0.5, $midpt, $vertex, $vertex, $midpt, 0.5}
 > 
 > This silently fails by sticking zeroes everywhere there is a variable
 > reference (i.e., all the interior points) even though the variables have
 > previously been set.  Isn't this a bug? Shouldn't the variables just be
 > replaced by their values?
 > 
 > I worked around this by using
 > 
 > l 1 = $midpt
 > l 2 = $vertex
 > 
 > etc., in x08.tcl,
 > 
 > but I don't think this workaround should be necessary.

:-).  It's called "Tcl" because you're supposed to giggle every time
it annoys you.

Braces protect against variable interpolation.

There's probably a way to get what you want using eval or list or
something.  

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

[Plplot-devel] Possible bug in matrix initialization

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

I have been struggling with resetting the cmap1 to default values for tcl.
Turns out my problems were due to the following construct which I thought
should work to initialize the matrix.

matrix l f 6  = {0.5, $midpt, $vertex, $vertex, $midpt, 0.5}

This silently fails by sticking zeroes everywhere there is a variable
reference (i.e., all the interior points) even though the variables have
previously been set.  Isn't this a bug? Shouldn't the variables just be
replaced by their values?

I worked around this by using

l 1 = $midpt
l 2 = $vertex

etc., in x08.tcl,

but I don't think this workaround should be necessary.

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] compile problem

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

On Monday 18 February 2002 21:24, Geoffrey Furnish wrote:
| We've picked up a compile problem recently.  This is from a fresh
| checkout today, building on Linux:
|
| gcc   plrender.o -L. -lplplot -ltclmatrix -o plrender \
|         -ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -lgd -lpng -ljpeg
| -lz -ldl -lm -lg2c -Wl,-rpath -Wl,/x/furnish/devel/x/plplot/tmp
| ./libplplot.so: undefined reference to `plD_dispatch_init_pstex'
| collect2: ld returned 1 exit status
| make: *** [plrender] Error 1
| [furnish@xiphi tmp]$

My fault. I will correct it soon.

Thanks,
Joao

| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] compile problem

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

We've picked up a compile problem recently.  This is from a fresh
checkout today, building on Linux:

gcc   plrender.o -L. -lplplot -ltclmatrix -o plrender \
        -ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -lgd -lpng -ljpeg -lz
-ldl -lm -lg2c -Wl,-rpath -Wl,/x/furnish/devel/x/plplot/tmp
./libplplot.so: undefined reference to `plD_dispatch_init_pstex'
collect2: ld returned 1 exit status
make: *** [plrender] Error 1
[furnish@xiphi tmp]$ 

Re: [Plplot-devel] PLplot statistics

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

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

> | Didn't we just go through this exercise to prove the libraries had
> | to be there (i.e., mentioned specifically for the link command) for
> | the dynamic driver builds?
>
> I don't quite understand your phrasing. libplplot only depends on the
> libs the xwin and tk drivers depend on, if they are build. Building
> dynamic drivers does not put dependencies in libplplot and in none of
> the executables, so I can build all dyn-drivers I can and package
> them.

It's that last phrase I disagree with (or perhaps misunderstand).  Here is
the current actual build results on my system (taken from make >&!
make.out).

gcc -shared -fPIC -o drivers/dg300.drv shared/dg300.o -L. -lplplotd

That's okay, it is consistent with what you have said.  But...

gcc -shared -fPIC -o drivers/gd.drv shared/gd.o  -lgd -lpng -ljpeg -lz -L. =
-lplplotd

So for this last line to work, libgd must be on the build system (our
configure system enforces this in any case). Furthermore, this (rightfully)
puts a dependency in the corresponding rpm package on libgd (and libpng and
libjpeg and libz and finally libplplotd).  So if you lumped all the *.drv
files in one binary rpm, that rpm would necessarily depend on libgd (and th=
e
other extra libraries).  If you split the *.drv results into one rpm per
*.drv file, then only the rpm containing the gd.drv file would have the
dependency on libgd (and other extra libraries), but you probably don't wan=
t
to generate quite so many different rpm packages.  So what goes on now for
my plplot binary rpm is virtually every dynamic driver is in there (as well
as libplplotd, etc.) and the whole rpm depends on libgd, libpng, libjpeg,
and libz (and also the many extra libraries required by gnome.drv which I
haven't mentioned until now).  IIRC, the only two drivers missing from my
plplot rpm are the svga one, and the cgm driver (since there is no viable
libcd rpm).  Anyhow, splitting off the dynamic drivers into their own rpm
package gains you little unless you micro-split them.  Only in that case
(drivers requiring special libraries in their own individual packages) do
you remove some dependencies of the main package on the special libraries.

I am sure Rafael is going through similar calculations.  In his case, thoug=
h,
I assume he will use the micro-split solution since apt-get makes life simp=
le
in that case.

> If "rpm" creates dependencies on the package, then one has to
> find the way to manually remove them (at rpm creation time).

I may be taking that remark out of context, but I think you will run
into trouble with such an approach.

> I know all that, I just wanted to stress the fact that one can
> distribute drivers even knowing that the user system might not have
> imediate support for some of them.

Only if you use the micro-split solution.
>
> I don't agree with Rafael idea of creating a separate rpm for each
> driver!

Actually, he made clear he was talking about deb's.  But I agree with you,
without apt-get a micro-split solution for rpm's is not too practical
so that is why I lumped everything together in the plplot rpm (with
the downside that it has a lot of dependencies that must be satisfied).


> What a mess to install all those perl modules! That's good only for
> debian, and for guys who know what they are doing. When I installed
> those perl modules I was tempted to (and just did)  install them all,
> because their names tell me nothing.

I believe you are referring to the perl modules required for building
the documentation?  I skipped all that for my rpm.  Too lazy....

Alan

Re: [Plplot-devel] State of the Union

[Rafael L. <lab...@mp...>]

* Maurice LeBrun <mj...@ga...> [2002-02-08 04:38]:

> Speaking of long term projects, did anyone catch the recent LJ article =
on
> "Subversion"?  It's a CVS-replacement project, aimed at fixing all the
> irritating deficiencies of CVS as well as desuckifying the code base, w=
hile
> basically preserving the existing API.  I got seriously pumped reading =
about
> it.
>=20
> Here's the LJ article:
> http://www.linuxjournal.com/article.php?sid=3D4768
>=20
> Well worth a read.  The Subversion home page is at:
> http://subversion.tigris.org/

Yes, subversion looks quite promising.

I have been using since three years now another version control system
called PRCS (http://prcs.sf.net).  I am also the Debian package maintaine=
r
for PRCS.  I use it for all my personal projects.  PRCS is considered the
most =EFntellectual"version control system around.  Its simplicity,
elegance, and power are simply unbelievable.

Unfortunately, that clumsy piece of software called CVS dominated the wor=
ld,
just because PRCS did not get the momentum it deserved.  PRCS has been
essentially a one-man effort, namely Josh MacDonald (also from GTK and
XDelta fame), who never got to release the long-awaited PRCS2, which has
client/server support.  Without handling remote repositories, PRCS is no
viable alternative to CVS in a distributed development environment.

At any rate, I think that Subversion is making its path into world
domination.  Although I have a penchant for PRCS, I think that anything t=
hat
makes CVS disappear from Earth is a Good Thing.

--
Rafael


P.S.: Did I tell you that I *hate* CVS?  Preventing files from being
      properly renamed and deleted, among other stupidities, is simply
      unacceptable for a version control system.

P.S.(2): For the lucky Debian users:
         $ apt-get install prcs
         And then look at /usr/share/doc/prcs/prcs-tutorial.html

[Plplot-devel] Package dependencies [was: Re: PLplot statistics]

[Rafael L. <lab...@mp...>]

* Alan W. Irwin <ir...@be...> [2002-02-08 10:23]:

> At some point I intend to get involved in (unofficial) Debian packaging
> myself for the yplot project.  Out of curiosity, do you have to remember all
> the dependencies yourself or do you have an automatic system (as in rpm)
> that usually gets the dependices right for whatever package you have
> assembled?

For tracking shared library dependencies, the Debian packaging tool
(debuild, or dpkg-buildpackage) has a simple mechanism that is triggered by
the following line in debian/control:

    Depends: ${shlibs:Depends}

The "${shlibs:Depends}" string is automatically substituted.  For instance,
in the case of plplot-tcl, it becomes:

    libc6 (>= 2.1.2), tcl8.2 (>= 8.2.2), tk8.2 (>= 8.2.2), xlib6g (>= 3.3.6-4)

Of course, other kind of dependencies (not shared libs) have to be included
by hand.  For instance, plplot-tcl depends on itk3.1, iwidgets3.1, and
itcl3.1.  Currently, this cannot be detected automatically.  However, it
could be, since there is already a mechanism for Perl, using the token
"${perl:Depends}" in debian/control, that checks all module dependencies.
This could easily be extended to Tcl, by parsing the "package require"
instances in Tcl source files.  However, I think that there is few interest
on this mechanism among Debian developers and it is not going to be
implemented.

> BTW, this has been an enjoyable thread which I have helped others to move
> far off topic, 

Right, but I changed the Subject now.

-- 
Rafael

Re: [Plplot-devel] PLplot statistics

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

On Friday 08 February 2002 06:38, Alan W. Irwin wrote:
| On Fri, 8 Feb 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
| > On Thursday 07 February 2002 22:30, Alan W. Irwin wrote:
=2E..
| > But I don't see the point in installing rpms under /usr -- there
| > must exist some reasoning behind that?
|
| It's traditional. Maybe its even in the LSB by now, but violate
| that tradition at your peril.

OK, but tradition is not the same as it was to be :)

| > I have yet another rpm question. With dyndrivers, we can make rpm
| > with all available drivers, without having to worry if the user
| > system has the necessary libs or not! Of course the user will not
| > be able to use those drivers, but it will not hurt, and if the
| > user latter install the extra packages the drivers will be there.
| > Correct?
|
| Didn't we just go through this exercise to prove the libraries had
| to be there (i.e., mentioned specifically for the link command) for
| the dynamic driver builds?

I don't quite understand your phrasing. libplplot only depends on the=20
libs the xwin and tk drivers depend on, if they are build. Building=20
dynamic drivers does not put dependencies in libplplot and in none of=20
the executables, so I can build all dyn-drivers I can and package=20
them. If "rpm" creates dependencies on the package, then one has to=20
find the way to manually remove them (at rpm creation time).

| Anyhow, when building from a src rpm we use the ordinary configure
| script just like when building from a tarball or cvs. (And I am
| sure Rafael would answer the same for the deb package build.) Our
| current configuration checks for certain libraries and headers on
| the build machine.  If libcd is not there it doesn't build the cgm
| driver.  If libgd isn't there, it doesn't build the gd driver with
| png and jpeg devices.  This is uniform across src rpm, (presumably)

I know all that, I just wanted to stress the fact that one can=20
distribute drivers even knowing that the user system might not have=20
imediate support for some of them.

I don't agree with Rafael idea of creating a separate rpm for each=20
driver!
What a mess to install all those perl modules! That's good only for=20
debian, and for guys who know what they are doing. When I installed =20
those perl modules I was tempted to (and just did)  install them all,=20
because their names tell me nothing.

| If you run into any specific problems with a src rpm build of say
| PLplot, don't hesitate to ask me for help.  But my help will only
| be effective if the system has been cleanly installed strictly from
| rpm's without any forcing.

As you might have understand, I start creating a rpm for suse, but my=20
system is far from clean. I do know however what I have installed by=20
hand, from suse packages, or from other disto packages.

Joao

Re: [Plplot-devel] PLplot statistics

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

On Fri, 8 Feb 2002, Rafael Laboissiere wrote:

> I do not know the details of dependency handling in the rpm packaging
> system....

It's mostly automatic.  I check the dependency list that comes as part
of a particular package build (and which of course is also available for
the binary version of the package), and it is almost always right without
any intervention from me.

> ... but for Debian I am planning to make individual packages for each
> specific driver needing exteranl libraries.  The dependencies will be set
> like:
>
>     plplot-tcl -> tcl8.3, tk8.3
>     plplot-xwin -> xlib6g
>     plplot-gd -> libgd2
>     ...
>

Splitting plplot up this way is probably the right thing to do for a system
with apt-get, but many people still (despite Conectiva making an apt-get
that works with rpm packages) handle their rpm dependencies by hand so it is
probably better to lump everything together into one plplot package in that
situation.  Anyhow, that is good justification for my lazy rpm packaging
approach where I only make one plplot package....;-)

At some point I intend to get involved in (unofficial) Debian packaging
myself for the yplot project.  Out of curiosity, do you have to remember all
the dependencies yourself or do you have an automatic system (as in rpm)
that usually gets the dependices right for whatever package you have
assembled?

BTW, this has been an enjoyable thread which I have helped others to move
far off topic, but I also hope people have paid attention to the original
topic which was to have a look at
http://sourceforge.net/project/stats/index.php?report=last_30&group_id=2915
and http://sourceforge.net/project/stats/index.php?report=months&group_id=2915
to get an idea of how many people are taking an interest in our work.

Alan

Re: [Plplot-devel] State of the Union

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

Maurice LeBrun writes:
 > According to the LJ article, they're about to release version 1.0 ("oh
 > no.. run away!" :), so it's somewhat premature to plan our changeover.
 > But maybe sometime later this year after it's proven itself.

Well.. after some more research it looks to me like it may take longer than
that.  Basically I am very impressed, although I did notice one thing I didn't
like about it (tagging/branching).  This may be a good time to get involved
with the design process.

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

Re: [Plplot-devel] State of the Union

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

Speaking of long term projects, did anyone catch the recent LJ article on
"Subversion"?  It's a CVS-replacement project, aimed at fixing all the
irritating deficiencies of CVS as well as desuckifying the code base, while
basically preserving the existing API.  I got seriously pumped reading about
it.

Here's the LJ article:
http://www.linuxjournal.com/article.php?sid=4768

Well worth a read.  The Subversion home page is at:
http://subversion.tigris.org/

According to the LJ article, they're about to release version 1.0 ("oh
no.. run away!" :), so it's somewhat premature to plan our changeover.
But maybe sometime later this year after it's proven itself.

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

Re: [Plplot-devel] State of the Union

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

There's this plasma physicist at UT (Dr. Wendell Horton) that Geoff & I both
have worked with who had this remarkable gift.. in the course of 5 minutes he
could give you enough work through simple-sounding suggestions to keep you
busy for about the next year or two.  Remind you of anything? :)

Geoffrey Furnish writes:
 > Plframe Bugs:
 > ...
 >     2) First zoom in seems to often be a double display.  Very
 >        noticeable for big plots where it takes several seconds in dead
 >        time to display.  After the first zoom, the screen goes blank,
 >        then the plot flashes up, then immediately disappears, then
 >        more dead time, followed finally by a redisplay of the image.
 >        The second one "sticks".  Next zoom is okay.  (Still slow, but
 >        at least it only redisplays once).  But the first zoom down
 >        from the top, is a double hitter.
 > 
 >     3) C-r does a double redisplay too.  Once to go back to the size
 >        of the plot when there were scroll bars.  But then it notices
 >        the scroll bars are gone, so it resizes again and redisplays
 >        given the full screen real estate of the fully reseted
 >        plframe. 

Properly handling all the events here & filtering out the extraneous ones was
a huge headache when I was developing this originally IIRC.  After a lot of
hard-fought progress I got to a point where I threw up my hands in disgust and
said "good enough!".  Maybe now I could stomach working on it again, to try
for perfection, but I dunno.  When I'm next in the mood for some pain I'll
look at it.

 >     Probably we need a way for a Tcl script to set a "don't update"
 >     flag in plframe, then it can do the stuff with the Tk geometry
 >     manager to resize the plframe sans the scroll bars, then it should
 >     reenable event handling and tell plframe to redraw (just once).

Hmm...

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

Re: [Plplot-devel] PLplot statistics

[Rafael L. <lab...@mp...>]

* Jo=E3o Cardoso <jca...@in...> [2002-02-08 00:48]:

> Like me, when I made an automatic upgrade in my linux box, just to find
> that (of course) the upgrade had upgraded just the distro packages, not=
 the
> manually installed rpm ones? And then searching for all them... it woul=
d be
> much easier if they were in /usr/local -- or if I had a separate rpm
> database just for them.

<AD>
This is an area where Debian excels.  In my systems, I have no locally
installed packages, every package I have comes from Debian mirrors and is
automatically upgraded (thanks to "apt-get update; apt-get upgrade").  I =
am
talking about Debian woody (next stable release), that contains currently
over 8000 packages.
</AD>

> I have yet another rpm question. With dyndrivers, we can make rpm=20
> with all available drivers, without having to worry if the user=20
> system has the necessary libs or not! Of course the user will not be=20
> able to use those drivers, but it will not hurt, and if the user=20
> latter install the extra packages the drivers will be there. Correct?

I do not know the details of dependency handling in the rpm packaging
system, but for Debian I am planning to make individual packages for each
specific driver needing exteranl libraries.  The dependencies will be set
like:
 =20
    plplot-tcl -> tcl8.3, tk8.3
    plplot-xwin -> xlib6g
    plplot-gd -> libgd2
    ...

If the user says "apt-get install plplot-gd", then libgd2 will be
automatically downloaded, installed, and configured.

--=20
Rafael