RE: [Vxl-maintainers] vxl releases etc

[Brendan McCane <mccane@cs...>]

Joe Mundy said:
> I don't like solution 2).  Maybe we could more broadly share the work
of
> a release according to solution 1) in some way.  I don't have a good
> understanding of what is involved.  How did the process go last time?
> Joe

Well, the process is basically a pain in the proverbial IMO. I made a
few mistakes along the way (hence the reason we have a 1.1.0.1, and not
just a 1.1). But basically I just followed the instruction list passed
on by Ian Scott - I'm not a cvs expert so most of it was voodoo to me,
but it seemed to do the trick. The most effort if I remember correctly
is the downloading and compiling which needs to be done a few times on
at least two platforms - the scariest bit is getting the tags right, I
think I had to undo what I'd done once or twice ...

I presume you don't like 2) because of the apparent difficulty of entry
for newcomers? But I think at the moment the difficulty of entry is even
greater because newcomers download an old version of the library, spend
some effort trying to compile it, then ask one of the lists how to fix
it only to be told that they should get the CVS version...

My suggestions were (in increasing order of personal preference):
1) maintain the status quo, but making some effort to make releases on a
semi-regular basis (perhaps every 12 mths)

2) remove the releases from public view, and tell everyone to get the
latest CVS version as that is stable

3) automatically tar up a new release on a regular time frame (say once
a month, once a week, every day - if it's automatic, who cares?), and
just make that the current release (possibly changing only a minor
version number, eg 1.1.1, 1.1.2, ...).

Instructions (From Ian):
--------------
1. Download everything first onto at least two platforms and test the
current CVS HEAD. THe dashboards can be wrong (They never noticed that
the root configure filres had been removed!) This includes updating
CHANGES.txt.
* Need to commit changes here before making branch point etc.

2. The following is a description of how to make a branch point and
branch (Thanks to Brad for the info)(This only applies to making a new
minor version release, not a patch release)
          
        cd vxl
        cvs up -PdA
      cvs tag vxl-1-0-bp
        cvs tag -b vxl-1-0

3. Move to the branch
        cvs up -r vxl-1-0

4. Do some release specific work
      Make sure that core/vxl_version.h is correct.
      Update CHANGES.txt to mention the new release.
        Copy in an INSTALL.html (e.g. from the website)

5. Tag the 1.0.0 release:
        cvs tag vxl-1-0-0

5A. If you end up in a mess (e.g. because SF will not recognise that
configure really shouldn't be in the CVS attic) you can abandon the
branches and tags you have made so far. You can fix everything in the
main CVS branch, and commit it there. Then simply retag everything with
the -F option, which will make it forget about the previous locations of
the tags. It is not recommended to do this if these tags have had any
other users but yourself.

        cd vxl
        cvs up -PdA
      cvs tag -F vxl-1-0-bp
        cvs tag -bF vxl-1-0

6. Create a vxl download into directory.
        Do this on a Unix box so that the execute permissions are
        preserved. use cvs export to strip the CVS directories.
        cd /tmp
        cvs export -r vxl-1-0-0 -d vxl-1.0.0 vxl

7. Tar it up, and test the tar file from scratch on at
        least two platforms.

8. Submit it to the Sourceforge File Release system.

9. Get a copy of the documentation build, tar it up, and submit it to
the File Release System.

10. Did I mention that testing is good. Try downloading the files from
SourceForge. It can go wrong even now.

11. Submit a email describing the release to vxl-users, vxl-announce,
and submit a news item at VXL's SourceForge project page.

Ian.
-------------
-- 
Cheers,

Brendan.
----------------------------------------------------------------------------
Brendan McCane                          Email:  mccane@...
Department of Computer Science          Phone:  +64 3 479 8588/8578.
University of Otago                     Fax:    +64 3 479 8529
Box 56, Dunedin, New Zealand.

[Vxl-maintainers] VIL and large files

[Rob Radtke <rob@st...>]

Hi everyone,
I've been using VIL for a while now and had a question/comment for you all.

 
Unless I'm missing something, it appears as if VIL is unable to handle image
files larger than 2^31-1 bytes (i.e.. the largest number that can be
represented by vil_streampos which is typedef'd to be a long int). The
reason I noticed this in the first place was because I ran across a NITF
file that exceeded these bounds.  The NITF spec allows for files as big as
10^12-1 (999,999,999,999) bytes.  
 
So, it seems as if this limitation is caused by the combination of two
things:
 
1) vil_streampos is defined to be long int -- long int is 32 bits on my
platform (Windows).
and
2) vil_stream has no API for iterative seeking (i.e.. seeking from the
current position as opposed to the start of the stream).
 
It seems like we could overcome this limitation by remedying either #1 or
#2.  I took a crack at #1 in my working directory by changing the typedef
(of vil_streampos) to this:
 
#if VXL_HAS_INT_64
typedef vxl_int_64 vil_streampos;
#else //VXL_HAS_INT_64
typedef long int vil_streampos;
#endif //VXL_HAS_INT_64
 
That caused lots of compiler warnings elsewhere in VIL code base where int,
long int and vil_streampos are occasionally used interchangeably.  Some of
these issues were easy to resolve and other would (I believe) require API
changes.  Also, vil_stream_fstream::seek() (which uses std::fstream under
the hood) would have to be modified.  My plan for that was to have it do
multiple seeks (from current position) for cases where the desired seek
offset exceeded the size of istream::streampos.  I never got this far.
 
The other option would be to attack #2 by adding a parameter similar to
ios_base::seekdir to vil_stream::seek().  Then client code could get a
larger seek, by iteratively seeking.  This would solve the NITF case
somewhat nicely (files up to 10^12 bytes) but would be infeasible for REALLY
large files where you may have to seek a ridiculous number of times (worst
case: 2^32) to get to the end of the file.  Of course, who cares about files
that are that big if they even exist.  This solution requires a (small)
change to the core API.
 
I suppose a third option would be to add a virtual seek64() function that
did the right thing for all subclasses.  I haven't really thought this idea
through too thoroughly.
 
At any rate, does anyone have any opinions on this?  Is there another
(easier) option I'm missing.  If I were to pursue a solution, would you want
it incorporated into VIL?  Thank you all for your consideration.
 
Rob Radtke