[GRASS5] Digitizer drivers in v.digit

Hello all

We are trying to create a Tcl/tk interface for v.digit and we found some
strange things in the code. I already mailed Markus on this but he suggested I
mail the list as well.

The first thing we found was that the main.c file was NOT the main program. It
was not even compiled. The main program is in the file bin_digit.c. Markus,
regarding your comment to me "I have renamed bin_digit.c to main.c and changed
the Gmakefile" I did a cvs update, and although other changes have been made
(the files I listed to you are no longer there) this particular change was not
there. Do you want me to do this as part of our project?

Sorry to the rest of you, but I had to clear that up with Markus. Another
strange finding was that we found two files with similar functions, but neither
of the files were compiled. The strange part was in the comments at the top of
the file. Each file contained the following comment

/*
* This code is compiled by each digitizer driver and stored in its directory.
* Even though there is no curses.o it is used.
*/

The problem is that both files seem to define the same function names, but if
we believe the comments, how can both of them be used by the digitizer drivers?

After this we went looking into digitizer drivers and we found that the FAQ's
on the web site give directions for hooking up a digitizer to your computer but
there is nothing concerning using v.digit. Then we checked the GRASS
programming guide for 4.2 and found something completely different from the
current v.digit. For example, the guide (Ch 22) says that the file dig_curses.c
only contains #include statements and should be about 6 lines long. However,
the current dig_curses.c file contains several functions and is over 900 lines
long. Clearly the v.digit code has drastically changed since 4.2 and we are
confused by this talk of Digitizer Device Drivers in the old documentation. We
also found references to code in the src/libes/digitizers directory, but that
code is under construction and is not compiled.

There were "unused" files in the v.digit directory as well, and we wanted to
delete these (after all, I like to clean up code when I can :). Markus has
moved them to an unused directory in CVS and I recompiled v.digit without them
and all went well (Markus, the new directory "unused" did not show up when I
did the cvs update, is this a problem?). So in summary, we are confused about
how this apparently extra code is used by digitizers and are they even
necessary anymore. We would appreciate any ideas you may have concerning
digitizers and v.digit code. Unfortunately, we do not have a digitizer so we
cannot even run our own tests.

Concerning the CVS branch discussion; we plan to separate the interface code
from v.digit. This is going to produce many changes to the core code of
v.digit, so should I use a separate branch? By the way, I know next to nothing
about CVS and haven't had time to read up on it yet. Just curious, since a
previous post indicated users should create their own branch.

Thank you for your time and consideration.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 4425
max: 0

On Thu, 11 May 2000, Justin Hickey wrote:

There were "unused" files in the v.digit directory as well, and we wanted to
delete these (after all, I like to clean up code when I can :). Markus has
moved them to an unused directory in CVS and I recompiled v.digit without them
and all went well (Markus, the new directory "unused" did not show up when I
did the cvs update, is this a problem?). So in summary, we are confused about
how this apparently extra code is used by digitizers and are they even
necessary anymore. We would appreciate any ideas you may have concerning
digitizers and v.digit code. Unfortunately, we do not have a digitizer so we
cannot even run our own tests.

Jazzman,

  Uh, oh! Not good. I have a Hitachi HDG-2436 table which is reputed (in the
source code) to be supported). I am willing to test your code for you. I
bought the digitizer (used, of course) specifically for use with GRASS. When
you think you have a working version, send it to me (off-list) and I'll hook
up the digitizer and run some tests.

  This will also force me to learn how to initialize the board and use it
within GRASS. Ergo, mutual benefit.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2519
max: 0

Hi Justin,

You can get information on how to use CVS from the online
help 'cvs --help-options', from the 'man cvs', and from reading
the postscript file that comes with the CVS installation.
See Chapter 5 on branching and merging.

It is true that one person can create a branch, but once
created, a team of people can work on the branch.

For example, with your working copy, execute the command
'cvs tag -b drivers-rel-1-0-v-digit'

Others, including yourself, can then access that branch
'cvs co -r drivers-rel-1-0-v-digit v.digit
assuming that the v.digit module name exists in the modules
file under CVSROOT. If users already have a local
copy and do not want two copies on their local machine,
they can switch to the tagged version by
'cvs update -r drivers-rel-1-0-v-digit' v.digit

Once you have a local copy tied to a branch, it remains
there until you tell it do otherwise. For instance, the
'cvs update -A v.digit'
command will bring it back to the HEAD of the repository
branch. If you have modified files under the branch tag
though, you will; have to commit your work first or rename
the changed file before updating back to the HEAD.

Hope that gets you going.

John Huddleston

----- Original Message -----
From: Justin Hickey <jhickey@impact1.hpcc.nectec.or.th>
To: <grass5@geog.uni-hannover.de>
Cc: <stongsim@hpcc.nectec.or.th>
Sent: Thursday, May 11, 2000 11:09 AM
Subject: [GRASS5] Digitizer drivers in v.digit

[snip]

Concerning the CVS branch discussion; we plan to separate the interface

code

from v.digit. This is going to produce many changes to the core code of
v.digit, so should I use a separate branch? By the way, I know next to

nothing

about CVS and haven't had time to read up on it yet. Just curious, since a
previous post indicated users should create their own branch.

Thank you for your time and consideration.

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 3331
max: 0

On Thu, May 11, 2000 at 05:09:46PM +0000, Justin Hickey wrote:

Hello all

We are trying to create a Tcl/tk interface for v.digit and we found some
strange things in the code. I already mailed Markus on this but he suggested I
mail the list as well.

The first thing we found was that the main.c file was NOT the main program. It
was not even compiled. The main program is in the file bin_digit.c. Markus,
regarding your comment to me "I have renamed bin_digit.c to main.c and changed
the Gmakefile" I did a cvs update, and although other changes have been made
(the files I listed to you are no longer there) this particular change was not
there. Do you want me to do this as part of our project?

Justin,

sorry for the delay. I have updated the CVS now (delayed due to
hardware breakdown, new mainboard now).

Notice for all:
Several files not used in v.digit are in v.digit/unused/ now.
The file bin_digit.c is renamed to main.c, the Gmakefile changed
for this. So the file structure should be (rather) clean now.

There were "unused" files in the v.digit directory as well, and we wanted to
delete these (after all, I like to clean up code when I can :). Markus has
moved them to an unused directory in CVS and I recompiled v.digit without them
and all went well (Markus, the new directory "unused" did not show up when I
did the cvs update, is this a problem?). So in summary, we are confused about

Mhh, it should. I would like to pass the question on our CVS
specialists :slight_smile:

Kind regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2298
max: 0

John,
it is good to have someone with som much experience on the project.

Do you thing we should create a grass tree cvs stable branch?

This way developers could crank away with heavy modifications but
minor onces need to be worked upon the stable branch?

I assume that this might be more feasable then having everybody just
creating branches for local use.

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

Markus (et al)

Manually moving directories and files on the CVS server from the
repository to outside the repository is not usually recommended.

Let the CVS users execute the command
'cvs remove file-to-be-removed'
then the file-to-be-removed stays in the CVS repository
but is not longer accessible to main (HEAD) branch
developers. However, it is still available for those
who have tagged whole sections of code that need
that file. On the CVS server, an Attic directory is
created and the file goes there. Thus the file is
still available for older builds (compliance with older
systems or standards, etc.) but no longer is "seen"
by developers working at the HEAD. The l option
on cvs remove command is local directory only. The
R or recursive option is default if no argument is given.

John Huddleston

----- Original Message -----
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: <grass5@geog.uni-hannover.de>
Sent: Thursday, May 11, 2000 8:51 AM
Subject: Re: [GRASS5] Digitizer drivers in v.digit

[snip]

> There were "unused" files in the v.digit directory as well, and we

wanted to

> delete these (after all, I like to clean up code when I can :). Markus

has

> moved them to an unused directory in CVS and I recompiled v.digit

without them

> and all went well (Markus, the new directory "unused" did not show up

when I

> did the cvs update, is this a problem?). So in summary, we are confused

about

Mhh, it should. I would like to pass the question on our CVS
specialists :slight_smile:

Kind regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 3059
max: 0

Markus (et al)

----- Original Message -----
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: <grass5@geog.uni-hannover.de>
Sent: Thursday, May 11, 2000 10:41 AM
Subject: Re: [GRASS5] Digitizer drivers in v.digit

[snip]

> Let the CVS users execute the command
> 'cvs remove file-to-be-removed'
> then the file-to-be-removed stays in the CVS repository
> but is not longer accessible to main (HEAD) branch
> developers.
Mhhh, I did following:

cd v.digit/
rm main.c # the old unused one
cvs rm main.c
mv bin_digit.c main.c
cvs add main.c
cvs ci -m"renamed bin_digit.c to main.c" bin_digit.c main.c

Almost, here's a full sequence with explanation. After a 'cvs rm'
the local CVS/Entries file is changed but not the repository. Then
after a 'cvs commit', the repository file bin_digit.c,v is moved
to a newly created (if it did not exist) directory and the local
CVS/Entries file no longer has the bin_digit.c entry. After the
cvs add, only the CVS/Entries files has the entry. After a
'cvs commit' or 'cvs ci', the CVS repository moves the Attic
file back (only if it is the same name) and increments the
revision number, then updates your CVS/Entries file to
reflect the new revision number.

Looking into ATTIC shows:
http://freegis.org/cgi-bin/cvsweb.cgi/grass/src/mapdev/v.digit/Attic/
-> bin_digit.c

Isn't that correct?

In the repository, the files are RCS files and end with a ',v' The Attic
file only existed in that time frame after the remove and before
adding the new one of the same name.

For my convenience I wrote two scripts:

- cvs.r.add # add a full directory with comments to CVS
- cvs.remove # remove a directory

These scripts consist of many cvs add, cvs rm and cvs ci
calls.

Perhaps my below message from yesterday was a bit confusing
(at least for Justin). Generally I am always using the cvs
commands (hopefully properly, otherwise please complain).
The missing commit from yesterday was due to a hardware
problem over here. Of course I should never announce before
committing! My apologies...

Sometimes announcing before commiting is good in a team
environment. If anyone is heavily pounding on the code then
they can also let you know.

For those users who prefer a GUI interface the jCVS Java
interface runs on all platforms with JDK1 and JDK2. The
WinCVS runs on Windows and uses Tcl/TK for macros.

John Huddleston

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 4073
max: 0

On Thu, May 11, 2000 at 09:18:59AM -0600, John Huddleston wrote:

Markus (et al)

Manually moving directories and files on the CVS server from the
repository to outside the repository is not usually recommended.

John,

thanks for you comment (I am still learning CVS).

Let the CVS users execute the command
'cvs remove file-to-be-removed'
then the file-to-be-removed stays in the CVS repository
but is not longer accessible to main (HEAD) branch
developers.

Mhhh, I did following:

cd v.digit/
rm main.c # the old unused one
cvs rm main.c
mv bin_digit.c main.c
cvs add main.c
cvs ci -m"renamed bin_digit.c to main.c" bin_digit.c main.c

Looking into ATTIC shows:
http://freegis.org/cgi-bin/cvsweb.cgi/grass/src/mapdev/v.digit/Attic/
-> bin_digit.c

Isn't that correct?

However, it is still available for those
who have tagged whole sections of code that need
that file. On the CVS server, an Attic directory is
created and the file goes there. Thus the file is
still available for older builds (compliance with older
systems or standards, etc.) but no longer is "seen"
by developers working at the HEAD. The l option
on cvs remove command is local directory only. The
R or recursive option is default if no argument is given.

For my convenience I wrote two scripts:

- cvs.r.add # add a full directory with comments to CVS
- cvs.remove # remove a directory

These scripts consist of many cvs add, cvs rm and cvs ci
calls.

Perhaps my below message from yesterday was a bit confusing
(at least for Justin). Generally I am always using the cvs
commands (hopefully properly, otherwise please complain).
The missing commit from yesterday was due to a hardware
problem over here. Of course I should never announce before
committing! My apologies...

Excuse me and thank you for your valuable comments!
As Bernhard stated: It is good to have you here!

Markus

----- Original Message -----
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: <grass5@geog.uni-hannover.de>
Sent: Thursday, May 11, 2000 8:51 AM
Subject: Re: [GRASS5] Digitizer drivers in v.digit

[snip]

> > There were "unused" files in the v.digit directory as well, and we
wanted to
> > delete these (after all, I like to clean up code when I can :). Markus
has
> > moved them to an unused directory in CVS and I recompiled v.digit
without them
> > and all went well (Markus, the new directory "unused" did not show up
when I
> > did the cvs update, is this a problem?). So in summary, we are confused
about
> Mhh, it should. I would like to pass the question on our CVS
> specialists :slight_smile:
>
> Kind regards
>
> Markus
>

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 3547
max: 0

On Thu, May 11, 2000 at 10:41:14AM -0600, John Huddleston wrote:

Sometimes announcing before commiting is good in a team
environment. If anyone is heavily pounding on the code then
they can also let you know.

True.
One of the playground rules here is, that Markus should know
about what people are doing and where they are hacking in the CVS
tree.

To phrase it in the other direction:
  Do not start anything major unless you have Markus permission
  to work on that part of the tree.

Asking here certainly is a good idea.
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

On Thu, May 11, 2000 at 10:41:14AM -0600, John Huddleston wrote:

Markus (et al)

[...]

Almost, here's a full sequence with explanation. After a 'cvs rm'
the local CVS/Entries file is changed but not the repository. Then
after a 'cvs commit', the repository file bin_digit.c,v is moved
to a newly created (if it did not exist) directory and the local
CVS/Entries file no longer has the bin_digit.c entry. After the
cvs add, only the CVS/Entries files has the entry. After a
'cvs commit' or 'cvs ci', the CVS repository moves the Attic
file back (only if it is the same name) and increments the
revision number, then updates your CVS/Entries file to
reflect the new revision number.

Ok. So I should not perform two steps at the same time...

On the v.digit stuff:
Do I have to apply further changes or is it o.k.?
This isn't clear for me yet (excuse me, sometimes I am pretty
slow). -> Perhaps personal mail not to bother the others...

Sometimes announcing before commiting is good in a team
environment. If anyone is heavily pounding on the code then
they can also let you know.

Of course. Until now I was rather the only writing to the
CVS. So I have to learn how to work in a developers
environment! But this is what I was dreaming of. :slight_smile:

I'll try to learn harder.

Thanks, John, for your patience,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2309
max: 0

On Thu, May 11, 2000 at 07:02:26PM +0200, Bernhard Reiter wrote:

On Thu, May 11, 2000 at 10:41:14AM -0600, John Huddleston wrote:
> Sometimes announcing before commiting is good in a team
> environment. If anyone is heavily pounding on the code then
> they can also let you know.

True.
One of the playground rules here is, that Markus should know
about what people are doing and where they are hacking in the CVS
tree.

.. what I can do is to connect people not knowing each
other. Means: I already connected people who wanted to
work on the same problem to "synchronize" them. Of course
this list is a good forum!

To phrase it in the other direction:
  Do not start anything major unless you have Markus permission
  to work on that part of the tree.

Mhh, I suggest: Don't *commit* until the team allows. Of course
you are free to work where/what you want. It should be too
centralized, but under control. Confusions like my v.digit
problem should be avoided and will be avoided by communication.
Small updates should be generally o.k. if not platform
dependent. Otherwise we loose time.

Maybe it is a good idea if we know from each other about current
projects (if bigger projects like the XDRIVER or tcl_v.digit).
I already made a sort of list:
http://www.geog.uni-hannover.de/grass/coop.html
(incomplete).

Best wishes

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2372
max: 0

Markus,

Well, I suspect that since most of the GRASS folks are new to
CVS these messages are helpful. This should close this
subject line.

----- Original Message -----
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: <grass5@geog.uni-hannover.de>
Sent: Thursday, May 11, 2000 11:55 AM
Subject: Re: [GRASS5] Digitizer drivers in v.digit
[snip]

Ok. So I should not perform two steps at the same time...

On the v.digit stuff:
Do I have to apply further changes or is it o.k.?
This isn't clear for me yet (excuse me, sometimes I am pretty
slow). -> Perhaps personal mail not to bother the others...

I happened to have the original files here locally so I did:

grep main.c CVS/Entries
grep bin_digit.c CVS/Entries

and both files displayed as version 1.1.1.1
Next, I performed the following update

cvs update -A main.c bin_digit.c

The main.c was updated to version 1.3 and the bin_digit.c
was removed from my local directory. Looks like this
is what you wanted to do based on the emails.

John Huddleston

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2750
max: 0

Hello Rich

On May 11, 6:06am, Rich Shepard wrote:

  Uh, oh! Not good. I have a Hitachi HDG-2436 table which is reputed (in the
source code) to be supported). I am willing to test your code for you. I
bought the digitizer (used, of course) specifically for use with GRASS. When
you think you have a working version, send it to me (off-list) and I'll hook
up the digitizer and run some tests.

Thank you very much for the offer to test the code. We will certainly send you
the working version, but it may not be for a few months. Since we plan to rip
out the interface code from the core v.digit code, it will be a while before we
get anything running.

I'll let you know how it goes.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2253
max: 0

Hello Markus and others

On May 11, 3:51pm, Markus Neteler wrote:

Notice for all:
Several files not used in v.digit are in v.digit/unused/ now.
The file bin_digit.c is renamed to main.c, the Gmakefile changed
for this. So the file structure should be (rather) clean now.

OK, I see these changes now. I had to use the cvs update -d command to get the
"unused" directory, just to let you know.

On May 11, 7:04pm, Markus Neteler wrote:

> To phrase it in the other direction:
> Do not start anything major unless you have Markus permission
> to work on that part of the tree.
Mhh, I suggest: Don't *commit* until the team allows. Of course
you are free to work where/what you want. It should be too
centralized, but under control. Confusions like my v.digit
problem should be avoided and will be avoided by communication.
Small updates should be generally o.k. if not platform
dependent. Otherwise we loose time.

I agree that we should have the team check changes before they are committed.
This implies three things:

1. There is definitely reason to have at least two source tress, one for
"committed" code (stable tree) and one for submitting changes to be evaluated.

2. Someone or some small team must dedicate themselves to evaluating submitted
changes. Otherwise, changes may never be applied to the stable tree.

3. We need a policy for evaluation as well as using CVS in general - standard
arguments to use for the different operations (update, commit, etc) that work
for the GRASS project and its developers - when should we create tags, naming
format for tags, who commits to the stable tree and when, etc.

Unfortunately, I'm new to CVS so I can't make too many suggestions, but I think
we need to address these 3 items and come to some kind of consensus soon.

Just my $0.02 worth.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 3415
max: 0

On Fri, 12 May 2000, Justin Hickey wrote:

Unfortunately, I'm new to CVS so I can't make too many suggestions, but I think
we need to address these 3 items and come to some kind of consensus soon.

  Out of curiosity, I looked at the web site of our local technical book
store (www.powells.com) and discovered that this past March saw the
publication of a CVS book: Open Source Development With CVS by Karl Franz
Fogel. I ended up ordering it from amazon.com to save 10%.

  Thought I'd pass this on for anyone else who's interested.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1894
max: 0

On Fri, May 12, 2000 at 06:07:39AM -0700, Rich Shepard wrote:

On Fri, 12 May 2000, Justin Hickey wrote:

  Out of curiosity, I looked at the web site of our local technical book
store (www.powells.com) and discovered that this past March saw the
publication of a CVS book: Open Source Development With CVS by Karl Franz
Fogel.

The book is quite usable... I can recommend it.
You can almost get everything online from: http://cvsbook.red-bean.com/

http://www.loria.fr/~molli/cvs-index.html is another good entry
point for CVS documentation. (Also linked from the GRASS CVS page
freegis.org/grass/ )

I ended up ordering it from amazon.com to save 10%.

BTW: The Free Software community is boycotting amazon for their
misuse of software patents. There are alternatives:
  http://www.noamazon.com/
  http://www.fsf.org/philosophy/amazon.html

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)