An interesting way of keeping track of versions
anal...@hotmail.com
Suppose you are tinkering with code and parameters of a program that
is trying to do something open-ended (say, forecasting). The
parameters can be kept in an external file and printed out with the
output so that you have a permanent track of what parameter values
give rise to what results.
But let us say that you are also tinkering with code - it is a pure
pain in the neck to throw in version numbers etc. in the code But
nothing stops the fortran executable from reading its own the source
code and voila! - you have a pain-free way of listing code changes
with the output. If you are using a modern IDE such as Visual Studio,
you can isolate sub-programs you are currently tinkering with into a
separate source code file. All you would have to do is to keep a base
version and do the tinkering in the current version, read them both
from your program, write a diffing routine specialized for fortran and
there you have it - the specific lines of code causing the output
along with your current parameter settings permanently included in the
output.
robin
|I am surprised that no one seems to have thought of before.
|
| Suppose you are tinkering with code and parameters of a program that
| is trying to do something open-ended (say, forecasting). The
| parameters can be kept in an external file and printed out with the
| output so that you have a permanent track of what parameter values
| give rise to what results.
|
| But let us say that you are also tinkering with code - it is a pure
| pain in the neck to throw in version numbers etc. in the code But
| nothing stops the fortran executable from reading its own the source
| code and voila! - you have a pain-free way of listing code changes
| with the output.
You can instead obtain a compilation listing,
with or without any INCLUDE files.
Just as easy to save that.
glen herrmannsfeldt
> I am surprised that no one seems to have thought of before.
> Suppose you are tinkering with code and parameters of a program that
> is trying to do something open-ended (say, forecasting). The
> parameters can be kept in an external file and printed out with the
> output so that you have a permanent track of what parameter values
> give rise to what results.
> But let us say that you are also tinkering with code - it is a pure
> pain in the neck to throw in version numbers etc. in the code
If you use a version system like CVS or SVN, then you can arrange
for the version numbers to be included in the code. You can then
print them out when the program runs. Such systems also allow you
to retrieve the source of any previous version easily, or to
look at the differences between them (like the unix diff command).
Note that reading the source while the program runs isn't quite
right, as it will get changes to the source, even if that version
hasn't been compiled yet.
CVS and SVN are especially useful in group programming projects,
but are also useful for one person. For the reason mentioned,
and also because it is sometimes necessary to retrieve a previous
version, such as when a change doesn't work as expected.
(CVS and SVN keep track of version numbers in different ways,
and you do have to be a little careful to get the right number
compiled in to the appropriate place, but once it works it should
keep working.
-- glen
Terence
> <analys...@hotmail.com> wrote in messagenews:228458bf-2576-4ba6...@n3g2000yqb.googlegroups.com...
Back in the "old" days, the variaous IBM Fortran compilers always
started main unsigned COMMON at the same reletive memory position
(different for different mainframes types, but you get the idea). So a
version number placed in position 1 of common could be seen in a
partial dump, and a self-query subroutine would, on demand, display
this version number. And as an extension you could put the date and
author next...
This position was very early in the memory dump, about 103 if I
remember correctly.
Terence
I just replied after Robin. Had to take out the four character "dodo"
to get posting accepted.
Richard Maine
> anal...@hotmail.com <anal...@hotmail.com> wrote:
> > I am surprised that no one seems to have thought of before.
...
> > But let us say that you are also tinkering with code - it is a pure
> > pain in the neck to throw in version numbers etc. in the code
>
> If you use a version system like CVS or SVN, then you can arrange
> for the version numbers to be included in the code.
Which is to say that, yes, quite a lot of people have thought about it
for quite a long time before.
Or there are simpler ways even without version control systems. I
usually have a version parameter in my programs. No, it really isn't
much of a pain at all. I know because that's what I do. A simple
one-line edit. I suppose it would be a fuss if I wanted to update it
with every single edit to the program code, but I just do it when I make
a "release." It would not be particularly hard to script an auto-edit
into a Makefile, even without using CVS and friends. I'm pretty sure
some people do that, but I don't tend to bother.
It is reasonably common to have program output explicitly say what
version of the program it is from. Many of my programs do that. So do
many other programs that I see.
For a very direct example, if you look at the User-Agent header of this
posting, I think you'll find that it says MacSOUP/2.8.3 (and some other
data). That header is generated by MacSOUP, which puts its version
number in its own output in very typical fashion. *LOTS* of programs do
things like that; as you see, I didn't have to go very far to find an
example. MacSOUP isn't written in Fortran, but that bit isn't horribly
language specific other than in trivial syntax differences.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> anal...@hotmail.com <anal...@hotmail.com> wrote:
>> > I am surprised that no one seems to have thought of before.
>> > But let us say that you are also tinkering with code - it is a pure
>> > pain in the neck to throw in version numbers etc. in the code
>> If you use a version system like CVS or SVN, then you can arrange
>> for the version numbers to be included in the code.
> Which is to say that, yes, quite a lot of people have thought about it
> for quite a long time before.
> Or there are simpler ways even without version control systems. I
> usually have a version parameter in my programs. No, it really isn't
> much of a pain at all. I know because that's what I do. A simple
> one-line edit. I suppose it would be a fuss if I wanted to update it
> with every single edit to the program code, but I just do it when I make
> a "release." It would not be particularly hard to script an auto-edit
> into a Makefile, even without using CVS and friends. I'm pretty sure
> some people do that, but I don't tend to bother.
When I wrote that one, I was thinking about the problem of having
subroutines in separate files, changing some of the subroutines,
and not updating the main program with any version number that it
may contain.
One difference between CVS and SVN has to do with the way version
numbers are tracked in multiple file projects. With CVS, each file
has a version number. That number is updated only when a new
version of that file is created. With SVN the whole tree
(set of files) has a version number, which is updated when any
file changes (and then change is checked in).
For the problem the OP seemed to be discussing, you would want
to keep track of the version number for each file with CVS, or
of the whole project with SVN. I believe you can arrange the
version number, as printed out when the program runs, to update
with SVN and make. For CVS, you might need to collect the version
numbers from each file (subroutine) together, and somehow print
out all those numbers.
In any case, if you are going through an active modify/compile/test
phase it is easy to forget to update the version number.
> It is reasonably common to have program output explicitly say what
> version of the program it is from. Many of my programs do that. So do
> many other programs that I see.
> For a very direct example, if you look at the User-Agent header of this
> posting, I think you'll find that it says MacSOUP/2.8.3 (and some other
> data). That header is generated by MacSOUP, which puts its version
> number in its own output in very typical fashion. *LOTS* of programs do
> things like that; as you see, I didn't have to go very far to find an
> example. MacSOUP isn't written in Fortran, but that bit isn't horribly
> language specific other than in trivial syntax differences.
-- glen
anal...@hotmail.com
I should have mentioned, I was talking about one person tinkering, not
a formal setting where the programmer has to sign in blood for code
changes and countless higher ups would have to sign off and the
executable/script changes actually being made by other minions, with
pre-set fallback procedures (and of course the 3 a.m. phone call to
the programmer).
Th only discipline needed is not to leave changes in the source code
without compilation. Otherwise once the diffing code for the current
version and a base version is written, the "tinker, run, observe
output" cycle can proceed totally naturally with fallback to any
version being possible with very little effort.
glen herrmannsfeldt
(snip, I wrote)
>> If you use a version system like CVS or SVN, then you can arrange
>> for the version numbers to be included in the code. You can then
>> print them out when the program runs. Such systems also allow you
>> to retrieve the source of any previous version easily, or to
>> look at the differences between them (like the unix diff command).
> I should have mentioned, I was talking about one person tinkering, not
> a formal setting where the programmer has to sign in blood for code
> changes and countless higher ups would have to sign off and the
> executable/script changes actually being made by other minions, with
> pre-set fallback procedures (and of course the 3 a.m. phone call to
> the programmer).
While such version systems are pretty much necessary for large
programming projects, they are still useful for one person.
> Th only discipline needed is not to leave changes in the source code
> without compilation. Otherwise once the diffing code for the current
> version and a base version is written, the "tinker, run, observe
> output" cycle can proceed totally naturally with fallback to any
> version being possible with very little effort.
How do you keep track of all the changes, such that you can
get back to a previous one? Comment out the old lines?
Preprocessor #ifder? A stack of listings of old versions?
Yes it is possible, and pretty often I do it that way, but
it is still something that computers are better at doing
than people are.
-- glen
Richard Maine
> anal...@hotmail.com <anal...@hotmail.com> wrote:
> > I should have mentioned, I was talking about one person tinkering, not
> > a formal setting where the programmer has to sign in blood for code
> > changes ...
> While such version systems are pretty much necessary for large
> programming projects, they are still useful for one person.
Indeed, many of my programs were done by "one person (me) tinkering."
Just because I didn't have to sign in blood, etc., doesn't mean that
some degree of version control wasn't very useful and almost required.
If other people use your programs (as they did mine), you need to be
able to readily identify versions. You don't necessarily need a real
fancy system, but you need to decide when you have something that you
will release to your users and call a version. I've been known to do
things as simple as make a copy of my working tree and archive that; in
fact, I've used that method quite a bit.
If one doesn't pay at least some attention to defining when one has the
code in a releasable state, then one obviously doesn't have any other
users (and wouldn't keep any very long).
anal...@hotmail.com
I am doing it by computer - the executable itself diffs its source
code agaist a base version and prints the diff output with each run.
You would select what you finally you want based on the output and
right in the output is a few lines of what you need to do to the base
version to generate the version of your program that would generate
the output you have selected.
The greatest problem of tinkering, (a brilliancy turns out not to be
one and you need to go back to where you were) is solved for good.
You don't need version numbers in the source code, you don't need
conditional logic based on version number, you don't need copies of
subprograms named sub, subold, subold1 etc. You mess with the source
every which way and as long as the output and source (as a diff
against a base version) are printed out permanently together, you have
a track of what you did effortlessly.
dpb
...
> ... and as long as the output and source (as a diff
> against a base version) are printed out permanently together, you have
> a track of what you did effortlessly.
But if you do want to go back some number of steps, will it reconstruct
the previous source automagically, as well?
VCS will do that if you simply make a build point...
Most programming editors have the hooks to make the retrieval/save
function transparent...my favorite editor dates from DOS days of the
early 80s and already had it then...I've used the combination for so
long I don't recall what it was like before.
--
anal...@hotmail.com
everybody seems determined to miss the point.
Yes there are source code control systems.
yes you can write a version number into images of your source.
But version of program output are separate objects from versions of
the source code - the room for human error comes in when you somehow
forget how you produced one version of the output. The proposed
method ties program output to source-code automatically and briefly -
in many case, the source-code diff output would only be a few lines
which would be difficult to recover otherise if you have been
tinkering a lot.
The only human effort comes in to use the diff output to convert the
base source-version into the one you want - but you have the program
output to help make sure that the job is done correctly.
dpb
...
> everybody seems determined to miss the point.
>
> Yes there are source code control systems.
>
> yes you can write a version number into images of your source.
>
> But version of program output are separate objects from versions of
> the source code - the room for human error comes in when you somehow
> forget how you produced one version of the output. The proposed
> method ties program output to source-code automatically and briefly -
> in many case, the source-code diff output would only be a few lines
> which would be difficult to recover otherise if you have been
> tinkering a lot.
...
The use of the VCS automates the whole thing is the point...as someone
else said, if you also want the listing, the compiler does that
automagically, too.
It seems to me everything you're doing is already available in a cleanly
wrapped solution already...
I don't see what's new/different that isn't more easily accomplished
otherwise.
--
glen herrmannsfeldt
> On Oct 4, 8:41 pm, dpb <n...@non.net> wrote:
>> analys...@hotmail.com wrote:
>> > ... and as long as the output and source (as a diff
>> > against a base version) are printed out permanently together, you have
>> > a track of what you did effortlessly.
(snip)
> everybody seems determined to miss the point.
> Yes there are source code control systems.
> yes you can write a version number into images of your source.
> But version of program output are separate objects from versions of
> the source code - the room for human error comes in when you somehow
> forget how you produced one version of the output. The proposed
> method ties program output to source-code automatically and briefly -
> in many case, the source-code diff output would only be a few lines
> which would be difficult to recover otherise if you have been
> tinkering a lot.
If your changes work such that differences to a base version are
all you need, and small enough, then yes. Though you can do better
than that. With make you could automate the diff, then generate
Fortran source containing the program text as literal constants.
Then the diff lines would be compiled in, and stay right even if
you changed the source, or copied the executable to another computer.
> The only human effort comes in to use the diff output to convert the
> base source-version into the one you want - but you have the program
> output to help make sure that the job is done correctly.
If you have N different versions, then there are N*(N-1)/2
possible diff outputs. CVS and SVN will generate those for you
with a very simple command, given the version numbers.
Also, with one command they will give you the source files as
they existed for any version, but still not forget all the other
versions.
-- glen
Klaus Wacker
> Richard Maine <nos...@see.signature> wrote:
[...]
>
> When I wrote that one, I was thinking about the problem of having
> subroutines in separate files, changing some of the subroutines,
> and not updating the main program with any version number that it
> may contain.
>
> One difference between CVS and SVN has to do with the way version
> numbers are tracked in multiple file projects. With CVS, each file
> has a version number. That number is updated only when a new
> version of that file is created. With SVN the whole tree
> (set of files) has a version number, which is updated when any
> file changes (and then change is checked in).
>
> For the problem the OP seemed to be discussing, you would want
> to keep track of the version number for each file with CVS, or
> of the whole project with SVN. I believe you can arrange the
> version number, as printed out when the program runs, to update
> with SVN and make. For CVS, you might need to collect the version
> numbers from each file (subroutine) together, and somehow print
> out all those numbers.
This is not how CVS is used. CVS has tags, which can be seen as a
short name for "all those numbers". Every release to users should be
tagged, but intermediate states can also be tagged. The version
numbers of the individual files are normaly never seen by users and
hardly ever by the developers.
--
Klaus Wacker klaus....@udo.edu
Experimentelle Physik V http://www.physik.uni-dortmund.de/~wacker
TU Dortmund Tel.: +49 231 755 3587
D-44221 Dortmund Fax: +49 231 755 4547
glen herrmannsfeldt
(snip, I wrote)
>> For the problem the OP seemed to be discussing, you would want
>> to keep track of the version number for each file with CVS, or
>> of the whole project with SVN. I believe you can arrange the
>> version number, as printed out when the program runs, to update
>> with SVN and make. For CVS, you might need to collect the version
>> numbers from each file (subroutine) together, and somehow print
>> out all those numbers.
> This is not how CVS is used. CVS has tags, which can be seen as a
> short name for "all those numbers". Every release to users should be
> tagged, but intermediate states can also be tagged. The version
> numbers of the individual files are normaly never seen by users and
> hardly ever by the developers.
Not normally, but the OP seems to want to know about it.
Though do note the unix 'what' command.
Printing out the version number seems more reasonable than
printing out the source code itself.
-- glen
JB
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> numbers are tracked in multiple file projects. With CVS, each file
>> has a version number. That number is updated only when a new
>> version of that file is created. With SVN the whole tree
>> (set of files) has a version number, which is updated when any
>> file changes (and then change is checked in).
>>
>> For the problem the OP seemed to be discussing, you would want
>> to keep track of the version number for each file with CVS, or
>> of the whole project with SVN. I believe you can arrange the
>> version number, as printed out when the program runs, to update
>> with SVN and make. For CVS, you might need to collect the version
>> numbers from each file (subroutine) together, and somehow print
>> out all those numbers.
>
> This is not how CVS is used. CVS has tags, which can be seen as a
> short name for "all those numbers". Every release to users should be
> tagged, but intermediate states can also be tagged. The version
> numbers of the individual files are normaly never seen by users and
> hardly ever by the developers.
I've always thought that CVS having version numbers for each file is
an artifact of the design based on RCS rather than any deep thought.
And of course, once you start having things like branches, or for that
matter multiple repositories in the more modern version control
systems, the concept of a global version number doesn't make that much
sense. git, for instance, uses SHA hashes to identify commits (of
course, git also supports tags).
--
JB
nm...@cam.ac.uk
>
>And of course, once you start having things like branches, or for that
>matter multiple repositories in the more modern version control
>systems, the concept of a global version number doesn't make that much
>sense. git, for instance, uses SHA hashes to identify commits (of
>course, git also supports tags).
Oh, yes, they do! Use 0 and 1 for the two halves of every branch,
and write them out in order as the binary expansion of a fixed
point number :-)
Regards,
Nick Maclaren.
Paul van Delst
> I should have mentioned, I was talking about one person tinkering,
Really, that's what version control systems are for. Be it one person, or many. Embedding version numbering keywords in
source code has been a functionality that version control systems have had for, crikey, decades.
FWIW, this is what I do now (I use subversion):
module blah
implicit none
private
public :: ...
public :: ...etc
character(*), parameter :: module_version_id = &
id = '$Id:$'
...other stuff....
contains
...important routines....
SUBROUTINE blah_version( Id )
CHARACTER(*), INTENT(OUT) :: Id
Id = MODULE_VERSION_ID
END SUBROUTINE blah_version
end module blah
I then call "blah_version", and similar for other modules, to get a complete listing of the verison numbers of all the
modules I've used. That has turned out to be *very* handy when the the concatenated version strings are added into a
netCDF file's history attribute.
As with your suggestion, the programmer has to be disciplined enough to commit the code to the repository before
compiling (to update the $Id:$ keyword).
All the rest of the stuff is handled (very well) by the version control system.
anyway....
cheers,
paulv
anal...@hotmail.com
One more time.
(1) There is source code.
(2) It can be changed over and over to produce an executable.
(3) Each executable produces (perhaps) different output.
(4) As you make one executable after another, the results are
sometimes better, sometimes worse. You might have produced 20
executables, stored all their output and evetually decide you want
executable number 13, by examining its output.
(5) You now need to be able to go back to source code version 13, make
executable no. 13 from it and make it the "production" version.
The executables are a red herring here - although it is the executable
that produces the output what you need to be able to do is to link
output version to source code version permanently and mechanically,
without depending on human discipline.
The method suggested achieves this, without involving a third entity -
some kind of version repository and other acts of discipline such as
marking version numbers in the code.
dpb
...
> (5) You now need to be able to go back to source code version 13, make
> executable no. 13 from it and make it the "production" version.
>
> The executables are a red herring here - although it is the executable
> that produces the output what you need to be able to do is to link
> output version to source code version permanently and mechanically,
> without depending on human discipline.
>
> The method suggested achieves this, without involving a third entity -
> some kind of version repository and other acts of discipline such as
> marking version numbers in the code.
The point the others are making is again...
The VCS can do the same automagically...the version can be incremented
automatically, the listing is part of the output of the compiler, the
desired version can be recalled/rebuilt simply by asking.
All it takes is using an already existing toolset and tying it to the
editor used as you've tied a different set of tools together.
--
anal...@hotmail.com
Everybody seems to be confusing complier output and the output from
the executable. There isn't any way shape or form a VCS can know that
the output the user is interested in is written to unit number 47 and
write a version number on that file when teh executable runs.
John
wrote:
An alternative that has served me well is to not depend on any code
history mechanism at all
in the long term, but to depend on the code itself
(and I've used everything from UPDATE/Historian to sccs(1) to CVS(1)
to subversion(1)
to git(1)) and to not worry about embedding version numbers into
executables and object
files (although I still think what(1) is a significant GNU/Unix tool
and find it very useful
when compilers embed compiler information and compile time information
into object files and
executables).
The vast majority of my Fortran code goes into a library (dozens of
them, actually). As each library is built, an ar(1)
library is built of the same routines using the (expanded) source.
Even if I make a shared object
library I always make an archive library as well. Then, the source
archive file (built with ar(1)
and the static object library are merged.
By the way ...
I consider it a valuable habit to make everything you can be as
generic as possible and go into a
library. Reuse of code is natural that way.
Then, if I need to compare the source used between two different
library versions I expand each one
into it's own directory using the "ar x" command and then compare the
routines in question (usually
it is just a few at a time that I am interested in the differences
between) with the handiest "diff"
utility (often just vimdiff(1) or diff(1) or dircmp(1) lately,
sometimes I use something much more elaborate to compare the files).
Keeping the code in the *.a object library file can make the libraries
considerably larger in size; but practice has shown this to be an
insignificant issue.
This is all done very simply with a single main make(1) file. The code
itself is actually kept as HTML with the
code contained in a (deprecated, I'm afraid) <xmp></xmp> region. The
make(1) file extracts the code from the HTML
and runs it thru cpp(1) (yes, I know the limits of cpp(1)) into a
scratch directory, compiles it and places the expanded
code and the object file into the libraries (source and object). No
messy *.o files laying around, no question about
what conditional code branches were taken when the preprocessing (if
any) occurred; If I am on a machine I installed the
library on I don't have to get access to the repository files to see
the source or worry about converting from one history-maintenance tool
to another (it is
hard to be enthusiastic about the advantages of git(1) over CVS(1)
when you've been through that a few dozen times).
If you make many copies of your libraries instead of having them in
some shared area (like an NFS-mounted file system)
the increased size of the merged source/object library file
might be an issue; or the fact that anyone with a copy of your library
also has a copy of your code might be disturbing.
If so, it is trivial to make a copy of your library sans the source
files (expand the archive file; make a new archive
file with just the *.o files).
If you have code that is used for many years it can easily outlive
many of the tools used to keep code version history.
So, just keeping the code in the library itself is a useful KISS-based
method.
With FORTRAN (77-) this approach has worked extremely well. Fortran
modules and a few other things have added complications to what I
outlined
here, and you have to remember to "checkpoint" a copy of your
libraries on a regular basis; but this simple method is quite
robust if your goal is to make sure you have the code around that you
used to make a specific code release.
PS: all the main program files go into a "source library" file as
well.
Richard Maine
> Everybody seems to be confusing complier output and the output from
> the executable. There isn't any way shape or form a VCS can know that
> the output the user is interested in is written to unit number 47 and
> write a version number on that file when teh executable runs.
Sure it can - trivially. And people have been doing things like that for
decades. I have, as have many others. I'd say it is worth considering
the possibility that just maybe other people have thought about these
kinds of things before and that you could take advantage of their work
instead of reinventing the world from scratch. If not, well, do what you
will.
Yes, it does also take a line of simple Fortran code. That shouldn't be
too daunting. You have the Fortran code write the value of a parameter
to the file in whatever form seems appropriate. The version control
system updates the parameter value in the source code by any of the
means that have been discussed.
Heck, this is the easy stuff - perhaps so easy that some people assumed
it. It is a bit harder to get a version number in the executable in a
strictly guaranteed way. One can get bitten by things like the compiler
optimizing away things that don't actually get used and thus don;t mak
etheir way into the executable image.
Nasser M. Abbasi
> anal...@hotmail.com<anal...@hotmail.com> wrote:
>
>> Everybody seems to be confusing complier output and the output from
>> the executable. There isn't any way shape or form a VCS can know that
>> the output the user is interested in is written to unit number 47 and
>> write a version number on that file when teh executable runs.
>
> Sure it can - trivially. And people have been doing things like that for
> decades.
Yup.
Example from http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_16.html
-------
It is common to embed $Id$ string in the C source code. This example
shows the first few lines of a typical file, after keyword substitution
has been performed:
static char *rcsid="$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";
/* The following lines will prevent gcc version 2.x
from issuing an "unused variable" warning. */
#if __GNUC__ == 2
#define USE(var) static void * use_##var = (&use_##var, (void *) &var)
USE (rcsid);
#endif
Even though a clever optimizing compiler could remove the unused
variable rcsid, most compilers tend to include the string in the binary.
Some compilers have a #pragma directive to include literal text in the
binary.
-------------
One can search binary file for such string using a command such as
$ strings /usr/bin/gfortran | grep -i rcsid
(assuming that is the vesion control string used in this example).
--Nasser
glen herrmannsfeldt
(snip)
> Even though a clever optimizing compiler could remove the unused
> variable rcsid, most compilers tend to include the string in the binary.
> Some compilers have a #pragma directive to include literal text in the
> binary.
If the program prints out the variable, then the optimizer better
not remove it.
-- glen
Uno
Well, yeah, and I have to wonder how #pragma would work from a fortran
point of view. In perl, they're what you use. In fortran, it's a
syntax error. In C, it's implementation-defined from the get-go, so I
doubt it would be something that could make sense through the iso c binding.
--
Uno
glen herrmannsfeldt
(snip on #pragma and C compilers)
> Well, yeah, and I have to wonder how #pragma would work from a fortran
> point of view. In perl, they're what you use. In fortran, it's a
> syntax error. In C, it's implementation-defined from the get-go, so I
> doubt it would be something that could make sense through the iso c binding.
Well, since gfortran is gcc based, it is certainly possible that
it implements #pragma. That would seem more likely in C
preprocessor mode, though.
-- glen
robin
If you don't have a source listing (on paper or disc),
you don't know what the version number is..
e p chandler
Open Watcom has its own form of pragma, but it is more like
!dec$attributes....
Uno
I see, and it has the advantage of being syntactical fortran.
--
Uno
anal...@hotmail.com
> analys...@hotmail.com <analys...@hotmail.com> wrote:
> > Everybody seems to be confusing complier output and the output from
> > the executable. There isn't any way shape or form a VCS can know that
> > the output the user is interested in is written to unit number 47 and
> > write a version number on that file when teh executable runs.
>
> Sure it can - trivially. And people have been doing things like that for
> decades. I have, as have many others. I'd say it is worth considering
> the possibility that just maybe other people have thought about these
> kinds of things before and that you could take advantage of their work
> instead of reinventing the world from scratch. If not, well, do what you
> will.
>
> Yes, it does also take a line of simple Fortran code. That shouldn't be
> too daunting. You have the Fortran code write the value of a parameter
> to the file in whatever form seems appropriate. The version control
> system updates the parameter value in the source code by any of the
> means that have been discussed.
>
There are three reasons for VCS:
(1) Controlled innovation - you want to keep changing things, but
retain the ability to recreate the source version that would produce
any of the observed outputs
(2) Multiple versions active
(3) Chain-of-custody - basically policing of what is running at a
given point in time (think of Sarbanes Oxley)
The solution proposed is an immaculate solution for (1) and (1) alone.
Using VCS's for this task is overkill and at any rate still introduces
friction into the innovation process (remembering to check in and
check out every version, only version numbers can be written to output
- if you want to eyeball two outputs along with their source - you'll
have to pull the two source versions and attach them to the output
manually etc.