VMS support

VMS support

[Chong Yidong]

What is the situation with the VMS support?  AFAICT, ttn was working on
getting it to work again, but I haven't heard anything about this
project since.  Dan Nicolaescu has suggested removing VMS support for
the purpose of code cleanup.  WDYT?

Re: VMS support

[Thien-Thi Nguyen]

() Chong Yidong <cyd@stupidchicken.com>
() Mon, 21 Jul 2008 15:52:38 -0400

   What is the situation with the VMS support?  AFAICT, ttn was working
   on getting it to work again, but I haven't heard anything about this
   project since.

Emacs 21.2 was the last known-good port, but that requires out-of-tree
code due to legal issues (specifically: the author of a big chunk of
VMS-specific code filed in 1992 a "copyright disclaimer" only, which is
not equal in force to a "copyright assignment" IIUC, and repeated
attempts to get the (standard) past/future copyright assignment from him
(by me and perhaps others) have failed, even though he has indicated in
200[45]-ish email that he is willing to do so).  These legal issues
might still be resolvable (i can try engaging him again), but i cannot
say for sure.

More details, including (lack-of-)progress/technical info, are at:
http://www.gnuvola.org/software/emacs-for-vms/

   Dan Nicolaescu has suggested removing VMS support for the purpose of
   code cleanup.  WDYT?

I think removing VMS support is fine, but not for the purpose of code
cleanup.  That reason implies that clean VMS support should be kept.
A better reason is that VMS is proprietary and Emacs users on VMS have
not shown sufficient interest in it.

If VMS support is to be removed, please do a complete job and remove it
from the Lisp and config/build/doc/admin parts of Emacs, as well.

thi

Re: VMS support

[Stefan Monnier]

>    What is the situation with the VMS support?  AFAICT, ttn was working
>    on getting it to work again, but I haven't heard anything about this
>    project since.

> Emacs 21.2 was the last known-good port, but that requires out-of-tree
> code due to legal issues (specifically: the author of a big chunk of
> VMS-specific code filed in 1992 a "copyright disclaimer" only, which is
> not equal in force to a "copyright assignment" IIUC, and repeated
> attempts to get the (standard) past/future copyright assignment from him
> (by me and perhaps others) have failed, even though he has indicated in
> 200[45]-ish email that he is willing to do so).  These legal issues
> might still be resolvable (i can try engaging him again), but i cannot
> say for sure.

The only question that I think is really relevant is: is there some hope
that someone will pursue this work (both the copyright assignment issue
and the update of the code to the Emacs-CVS-trunk codebase) in some
foreseeable future.


        Stefan

Re: VMS support

[Richard M Stallman]

    Emacs 21.2 was the last known-good port, but that requires out-of-tree
    code due to legal issues (specifically: the author of a big chunk of
    VMS-specific code filed in 1992 a "copyright disclaimer" only, 

We can use code with a copyright disclaimer.
So if that was indeed the reason for removing the code,
someone misunderstood the issue.

Perhaps there was some other reason.

Re: VMS support

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Wed, 23 Jul 2008 16:05:01 -0400

   The only question that I think is really relevant is: is there
   some hope that someone will pursue this work (both the
   copyright assignment issue and the update of the code to the
   Emacs-CVS-trunk codebase) in some foreseeable future.

Personally speaking, there is hope, in two parts:

a/ I received a clarification about the nuances between
   "disclaiming interest" and "copyright assignment" from the FSF
   copyright clerk (thanks!), which can be summed up (IIUC) as:
   Richard Levitte's code is ok to use, if i copyright the
   (extensive) changes i've made to it, since i myself have done
   the past/future assignment.

b/ I have a soft spot for VMS, though that spot shrinks w/ time.
   If i can finangle a $ituation to provide a port of Emacs 22 (or
   Emacs 23, once it settles), i will do it, otherwise no.

Having said that, i haven't queried potential funders yet, and the
negotiation process may take a while, and it may ultimately block
indefinitely, so "in some foreseeable future" is not indicated.

I say go ahead and zonk the VMS support.  If someone funds another
port (by me or whoever), previous source can always be re-dredged
and previous "expertise" can always be re-fudged. :-D

If anyone reading this is in a position to expedite b/ (above),
please feel free to contact me privately.

thi

Re: VMS support

[Stefan Monnier]

> a/ I received a clarification about the nuances between
>    "disclaiming interest" and "copyright assignment" from the FSF
>    copyright clerk (thanks!), which can be summed up (IIUC) as:
>    Richard Levitte's code is ok to use, if i copyright the
>    (extensive) changes i've made to it, since i myself have done
>    the past/future assignment.

Good.

> b/ I have a soft spot for VMS, though that spot shrinks w/ time.
>    If i can finangle a $ituation to provide a port of Emacs 22 (or
>    Emacs 23, once it settles), i will do it, otherwise no.

The only meaningful merge in my mind is a merge with CVS trunk, not with
some previous released version of the code, otherwise you'll always have
to play catch up.

> I say go ahead and zonk the VMS support.  If someone funds another
> port (by me or whoever), previous source can always be re-dredged
> and previous "expertise" can always be re-fudged. :-D

OK, so we should get rid of the VMS code in one clean commit with a CVS
tag before and another after.  I think it's important for this commit to
be as clean as possible (i.e. it really removes all the VMS related
code and text), so that there won't be some future changes that remove
a bit more of the VMS support: this way the CVS tags will faithfully
include all the relevant code (and text).

I guess we should do the same for the Carbon port since it also seems
that nobody is interested in updating&maintaining it.


        Stefan

Re: VMS support

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > I say go ahead and zonk the VMS support.  If someone funds another
  > > port (by me or whoever), previous source can always be re-dredged
  > > and previous "expertise" can always be re-fudged. :-D
  > 
  > OK, so we should get rid of the VMS code in one clean commit with a CVS
  > tag before and another after.  I think it's important for this commit to
  > be as clean as possible (i.e. it really removes all the VMS related
  > code and text), so that there won't be some future changes that remove
  > a bit more of the VMS support: this way the CVS tags will faithfully
  > include all the relevant code (and text).

IMO doing it this way is too high of a burden and hence not very
feasible.  It pretty much forces this to be a one person job instead of
allowing it to be distributed.  
There are 397 references just to the VMS string just in the C code +
docs.  And there are probably many things that are only valid for VMS,
but are not explicitly mentioning the VMS string.

  > I guess we should do the same for the Carbon port since it also seems
  > that nobody is interested in updating&maintaining it.

Is this a go ahead?

Re: VMS support

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Thu, 24 Jul 2008 09:59:52 -0400

   The only meaningful merge in my mind is a merge with CVS trunk,
   not with some previous released version of the code, otherwise
   you'll always have to play catch up.

To port is to always play catch up.  E-then-N vs N-then-E, you're
better off letting the taxi driver handle the urban tactics...

thi

Re: VMS support

[Stefan Monnier]

>> OK, so we should get rid of the VMS code in one clean commit with a CVS
>> tag before and another after.  I think it's important for this commit to
>> be as clean as possible (i.e. it really removes all the VMS related
>> code and text), so that there won't be some future changes that remove
>> a bit more of the VMS support: this way the CVS tags will faithfully
>> include all the relevant code (and text).

> IMO doing it this way is too high of a burden and hence not very
> feasible.  It pretty much forces this to be a one person job instead
> of allowing it to be distributed.   There are 397 references just to
> the VMS string just in the C code + docs.  And there are probably many
> things that are only valid for VMS, but are not explicitly mentioning
> the VMS string.

Well, there's doing a perfect jog and then there's doing a thorough job.
A perfect job is probably impossible.  But handling the 397 references
to vms in the C code shouldn't be that hard, and dealing with the rest
of the references in the Lisp code and in the manual shouldn't be that
hard either.  Sure, you're going to miss some implicit references, but
that's OK.

If you don't want to do it, then don't do it.

>> I guess we should do the same for the Carbon port since it also seems
>> that nobody is interested in updating&maintaining it.
> Is this a go ahead?

Yes, but with the same requirement of a clean removal.


        Stefan

Re: VMS support

[Stefan Monnier]

>    The only meaningful merge in my mind is a merge with CVS trunk,
>    not with some previous released version of the code, otherwise
>    you'll always have to play catch up.

> To port is to always play catch up.  E-then-N vs N-then-E, you're
> better off letting the taxi driver handle the urban tactics...

I can assure you that it's not the same if your code is in the trunk vs
if your code is on some other branch: when I edit the the C code and see
an "#ifdef VMS" I'll try to pay attention to that code, even if I can't
test that my change doesn't break it.  If it's not in the trunk, I won't
see the #ifdef and you'll have to deal with the breakage.


        Stefan

Re: VMS support

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Thu, 24 Jul 2008 16:00:03 -0400

   I can assure you that it's not the same if your code is in
   the trunk vs if your code is on some other branch: when I
   edit the the C code and see an "#ifdef VMS" I'll try to pay
   attention to that code, even if I can't test that my change
   doesn't break it.  If it's not in the trunk, I won't see
   the #ifdef and you'll have to deal with the breakage.

Whoever does porting work has to deal w/ the breakage, anyway,
regardless of the intention/care of others.  I appreciate your
saying you would take care, but the care you take is not the
only factor.

But that's enough from me on this topic.

thi

Re: VMS support

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> I guess we should do the same for the Carbon port since it also seems
  > >> that nobody is interested in updating&maintaining it.
  > > Is this a go ahead?
  > 
  > Yes, but with the same requirement of a clean removal.

Carbon is gone now.  There's a before-remove-carbon and a remove-carbon tag.
doc/emacs/macos.texi is still present, it looked like it might have some
text that is useful.  Someone that knows the platform would need to
handle that.  There's a note about it in admin/FOR-RELEASE.

Doing this a one big commit is _extremely_ inconvenient.  A thorough
removal can be done in steps too, and tags can help sort out the changes
easily.  The unnecessary red tape just adds extra work for absolutely
zero gain.

Re: VMS support

[Stefan Monnier]

> Doing this a one big commit is _extremely_ inconvenient.  A thorough
> removal can be done in steps too, and tags can help sort out the changes
> easily.  The unnecessary red tape just adds extra work for absolutely
> zero gain.

Can't imagine why it's so inconvenient.  Care to give some example of
the difficulties it adds?


        Stefan

Re: VMS support

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > Doing this a one big commit is _extremely_ inconvenient.  A thorough
  > > removal can be done in steps too, and tags can help sort out the changes
  > > easily.  The unnecessary red tape just adds extra work for absolutely
  > > zero gain.
  > 
  > Can't imagine why it's so inconvenient.  Care to give some example of
  > the difficulties it adds?

If you only can spend a few minutes at a time when doing this (and I do), you can't
write ChangeLogs when doing the work because they will conflict on
updates.  When updating you get unnecessary conflicts that need to be
resolved.  When working offline you can't cvs remove files.  If you cvs
remove files before tagging, the tag won't apply to that file.  And
probably more.  On the other hand the gain is inexistent.

Re: VMS support

[Stefan Monnier]

> If you only can spend a few minutes at a time when doing this (and
> I do), you can't write ChangeLogs when doing the work because they
> will conflict on updates.

You should place the ChangeLog text somewhere where it won't conflict
(e.g. some temp file, or further down in the ChangeLog file where there
will hopefully not be any changes) and then move it into place when you
do the commit.  Or you simply use C-x ^ r to auto-resolve the conflicts.

> When updating you get unnecessary conflicts that need to be resolved.

Again, since you're removing unused code, conflicting changes should be
relatively infrequent.  Doesn't sound like a big deal.

> When working offline you can't cvs remove files.

Yes, it's an irksome part of CVS.  I even submitted a patch to fix it
(together with a patch to add files offline as well) and used it for
a while.  But nowadays, I just directly edit the CVS/Entries file when
faced with this problem (after all, all it takes is to add a "-" at the
right place).

> If you cvs remove files before tagging, the tag won't apply to that
> file.

Really?  Duh, that's a nasty bug.  I guess it means you should indeed
refrain from "cvs removing" before the commit.  Instead, you should only
"rm" the files, and keep track of them, so that when you commit you do
"cvs tag; cvs rm <markedfiles>; cvs commit".  Kind of ugly indeed.

> On the other hand the gain is inexistent.

If someone ever intends to pick up this code and do something useful
with it, having it cleanly delimited by before/after tags is
very helpful.  If it's not commited as a single commit, you risk having
your change be interleaved with other unrelated changes.  Of course, if
nobody ever picks it up, the gain is indeed inexistent, but the cost
really seems pretty minor compared to the effort needed to figure out
how to remove the code (which parts to remove, etc...).

Thank you for the effort,


        Stefan

Re: VMS support

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > If you only can spend a few minutes at a time when doing this (and
  > > I do), you can't write ChangeLogs when doing the work because they
  > > will conflict on updates.
  > 
  > You should place the ChangeLog text somewhere where it won't conflict

[snip] 
Yes there are solutions to all these, but they mean just more work, and
mean changing the normal work style, which is equivalent to more work.

  > > On the other hand the gain is inexistent.
  > 
  > If someone ever intends to pick up this code and do something useful
  > with it, having it cleanly delimited by before/after tags is
  > very helpful.  If it's not commited as a single commit, you risk having
  > your change be interleaved with other unrelated changes.  Of course, if
  > nobody ever picks it up, the gain is indeed inexistent, but the cost
  > really seems pretty minor compared to the effort needed to figure out
  > how to remove the code (which parts to remove, etc...).

That's what I've been saying, its absolutely _not_ minor.  And trading
requiring to do work now for _maybe_ avoiding work in the future when
_maybe_ someone _might_ pick up the code is a bad tradeoff.

So the question is, will you continue this policy?

Re: VMS support

[Stefan Monnier]

> That's what I've been saying, its absolutely _not_ minor.

Keeping the ChangeLog on the side, as well as the list of files to `cvs
rm' seems like very minor annoyances.  Compared to the cost of finding
the parts of the code that uses Carbon, then finding the places that
refer to those places, ...  Maybe you don't think so because you'd
already done most of the work of finding the relevant places, but then
you just have a *perception* of a high marginal cost.

> And trading requiring to do work now for _maybe_ avoiding work in the
> future when _maybe_ someone _might_ pick up the code is
> a bad tradeoff.

Could be.  If you've ever been at the other end of the stick, you'll
know that the added work of extracting the relevant patches from a set
of interleaved patches can be excruciating.  Especially with CVS and its
lack of atomic commits.  So yes, the gain is only hypothetical, but is
potentially much higher than the cost.

> So the question is, will you continue this policy?

Yes.  As I said, if you don't want to do this job, then just leave the
old code in its place: we've been living with it for years, so it's
not like it's urgent to remove it.


        Stefan

Re: VMS support

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > That's what I've been saying, its absolutely _not_ minor.
  > 
  > Keeping the ChangeLog on the side, as well as the list of files to `cvs
  > rm' seems like very minor annoyances.  Compared to the cost of finding
  > the parts of the code that uses Carbon, then finding the places that
  > refer to those places, ...  Maybe you don't think so because you'd
  > already done most of the work of finding the relevant places, but then
  > you just have a *perception* of a high marginal cost.

Sorry, but repeating the same thing to someone that has the personal
practical experience of the things discussed is not exactly productive,
and obviously pointless.

  > > So the question is, will you continue this policy?
  > 
  > Yes.  As I said, if you don't want to do this job, then just leave the
  > old code in its place: we've been living with it for years, so it's
  > not like it's urgent to remove it.

Fine.  Dealing with silly, pointless red tape is not exactly the best
way to do volunteer work.

Re: VMS support

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Sun, 27 Jul 2008 12:51:12 -0700

   [cvs problems]

Perhaps you can kill two birds w/ one stone and do the work under
another version control system, one that supports using a local
repo to incrementally commit, exercising the new repo-specific vc
code in the process.  Then, when everything is presentable, squash
the local changes into one commit for cvs.

That's more work, but you get some side-benefit as well.

thi