[GRASS5] Re: GRASS CVS snap-shot bugs
Markus Neteler
neteler at geog.uni-hannover.de
Wed Jan 24 04:15:14 EST 2001
Hi Steve,
[cc to grass5 developers list]
On Tue, Jan 23, 2001 at 04:47:09PM -0600, Stevet at redriver.water.ca.gov wrote:
> 22 Jan. 2001
>
> GRASS 5 Develipment Team;
> via - Marcus Neteler <neteler at geog.uni-hannover.de>
>
> Your web page asks for comments, bugs and such.
> SO.....
> I downloaded last week's snap-shot. The "stable" tar-ball
> was not present due to a stated found-error. The web page indicated
> that the snap-shot had the error fixed.
>
> I compiled the snap-shot on both Slackware 4.0 and Slackware
> 7.1. The first is a "libc-5" type and the second is a "glibc2" type.
> It compiled on both. The 7.1 compile had numerous pointer conversion
> errors. The 4.0 had relitivly none. Experience dictates bad coding
> practices to be the cause. Simply isolate the warnings, add the usual
> force to type in the call and the warnings go away. If they don't then
> the compiler has a problem that needs to be addressed.
GRASS 5 is still on it's way to compile without *any* warning.
Comparing to 1999 we are quite close now. Please send over the
warnings for analysis, maybe we can fix them.
> After compilation I tried to run a small project through the
> GRASS5.0-beta11 I had just compiled. (I tried this on both compiles
> and got the same results, which speaks well for consistancy.)
>
> First problem: The fix-2 in the v.out.ascii has never been
> addressed. I have, at least twice, posted the
> problem, it reasion and the fix to the GRASS
> users group.
In fact this is not o.k. We apologize if this happened the last twelve
month and kindly request you to send your patch again. If it fixes
a problem, we should immediately update v.out.ascii.
> Second problem:The vector-to-raster converter is broken. Not
> only does ver.5 run considerably slower than
> ver.4.21, it fails to handle files of size.
> One file it was to convert was to have 104
> passes. It hung on the 8th and after 45 minutes
> of effort required me to pull the power to regain
> control of my machine.
> The same input, on the same machine but running
> GRASS 4.21 took 12 minutes and 11 seconds to run
> all 104 passes to normal completion.
This was reported recently to me. On my machine (Linux, Suse7) I don't
face such problem. Please report the bug here:
http://www.geog.uni-hannover.de/grass/bugtracking/bugreport.html
> Third problem: The r.stats program has been modified. The
> doccumentation has been modified. But they do not
> agree.
That's to be corrected.
> There are programmers in this world that
> can certify that I fire people for doing that.
As GRASS is open source and the development team open to new members
and contributions I invite you to update the html-page of r.stats.
If you send the update to me, I will update it in CVS.
Generally GRASS is GPL-licensed (http://www.gnu.org/copyleft/gpl.html).
See "11":
"NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR
THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO
THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM
PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.
"
Luckily we cannot get fired... The general idea of GRASS is to collect
contributions of users and programmers. GRASS is always is transition,
however, we work hard to get it as stable and consistent as possible.
Please keep in mind that GRASS is huge:
As of Jan 24 2001 the .c and .h files count nearly 1.5 Million lines
of source code.
> I don't expect programmers to be English Professors, but I do
> make them responsible for the accuracy of the doccumentation of their
> own efforts. If you modify a subroutine, I expect you to rewiew/correct
> it's doccumentation. I leave it to the English Lit types to correct the
> spelling, grammar and make it presentable. But - the programmer is still
> responsible for the correctness of the content.
I agree. Perhaps you could volunteer to assist us in correcting the
documentation?
> Change of subject. In one section I saw a request for someone
> to add a "block adjustment" module. Talk about a brain going a zillion
> different directions at the same time! I finally got it under control
> enough to hold it to just a few points. Why? Where is the rest of it?
> Who has the skill to trouble shoot it? What is the bases of the data to
> be used (table-top scanner, near quarter million dollar roll feed auto-
> adjusting computer driven scanners, micron accuracy multi-read mechanical
> plattens) ????? What about the image itself? Is it with fids, or reseau,
> or none of the above?????? "Block Adjust" is more like a sledge hammer,
> and it comes at the end, (usually) after a great deal of effort in the
> refinement of the base and the image data via the strip adjustments.
> (The fancy roll feed scanner (LH-Systems) is in the other room.)
1. It's on the wish list
2. It's not stated that it should be integrated into the core package
3. see below
> This brings me to a point I feel I need to air. It can be fun
> to take someone else's efforts and 'improve' it. It can be quite
> gratifying to take something 'make-shift' and turn it into something
> 'solid'. BUT - there are some 'lines in the sand' that cannot be
> crossed. A programmer is a tool maker. Very akin to a tool-n-die shopman.
> A programmer is NOT the craftsman who will use the tool. Just as the
> hammer maker, the screwdriver maker and other tool makers know they
> must never, never dictate to the craftsman how to hold or use the tool
> or which tool to use for what, so it must be with programmers.
Here I don't agree. Most of the GRASS developers *are* using there modules.
That's the basic reason to develop them.
> A tool
> that is built from less than 'solid' materials will always be less in
> quality. Just as a program 'thrown together' from various changeable
> aids will never be de-bug-able. No quality mechanic would ever willingly
> buy a wrench which had a softwood handle, a plastic jaw and was bound
> together by string. The same goes for application programs. Pick a
> language for the application and stick to it.
>
> Our first acquisition of GRASS was on a Spark Station, then
> on a DecStation and now on PC's. Maybe you can port your code to
> the next platform correctly.
I still don't see the problem except the three bugs denoted above.
> But will the other aids make the effort?
> Can the other aids even be ported? Will their makers do a craftsman
> like job of their ports? I am of course talking about TK, TCL, JAVA,
> and all the other "shortcuts" I see in GRASS5. The tool-n-die
> shopman is a craftsman. One that has much skill. One that knows his
> first job is to fully understand the design he is asked to create.
> Else how can he choose his materials? Or his fabrication methods?
> So it must be for the programmer.
>
> To agree or to disagree with what you have read comes under
> the wonderfull concept of Freedom of Choice. As it should! But here
> is a truth:
> When one takes on oneself the job of maintainer of product,
> particularly a product upon which others base their livelyhood, one
> leaves the realm of children. "Hacking code" isn't "Crafting code."
I have no problems if you go back to older GRASS releases. We don't
force you to use the current version.
ftp://grass.baylor.edu/pub/grass/grass4.0/
ftp://grass.baylor.edu/pub/grass/grass4.2/
Old GRASS FP version:
ftp://129.229.103.1/pub/grass/outgoing/Floating_pt/
(enjoy compiling this version)
> If you just have to have a block adjust program, I believe
> BLUH was written at the University of Hannover, Germany; in fortran.
> It ran on the PDP-11 and VAX-VMS. State of California got a lot of
> use out of it. It was discontinued when they converted to soft-copy
> a couple of years ago.
>
> V6.30 - July 1985
> Autnor - Dr.-Ing. Karsten Jacobsen
> Institut fur Photogrammetrie und Ingenieurvermessungen
> Universitat Hannover
> Nienburger Strasse 1
> D 3000 Hannover
>
> Location close enough? :)
I know Dr. Jacobsen, met him recently. But BLUH is proprietary.
http://www.ipi.uni-hannover.de/html/service/bluh/BLUH.HTM
So we cannot use it under terms of GPL.
> Steven L. Turner LLS stevet at water.ca.gov
> GIS Tech. Support (916) 653-4041 V/M
> Unit - Land & Water Use (916) 657-4796 F
> Section - Statewide Planning
> Division of Planning and Local Assistance
> Department of Water Resources
> State of California
> 1416 9th Street, Rm 150
> Sacramento, CA 95814
>
Regards
Markus Neteler
--
Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev
mailing list