Re: Fixes for GNU Sather 1.2.2

[Sather User]

On Thu, 18 Jun 2009, Michael R. Taylor wrote:

> Thanks for your patch, however the reason 1.2.3 went with 32bit
> INTs was to retain backwards-compatibility with legacy programs.
> INT should, and definitely will, become 64bit.  However it makes no
> sense to do that in a patch-level release.  The INT change will

My laptop is 64-bit today.  Why does it make no sense?

No code changes are required in Sather programs.  Existing binaries,
unless they have static linking, won't run on Linux x86_64.
Recompiled with a compiler that has my patches, they will.  They may
have greater arithmetic precision, but that will rarely be a problem.
Shouldn't be at all.  I can't see that your "backwards-compatibility"
argument makes sense.

The reason 1.2.3 went with 32bit INTs was because, when you compiled
1.2.2 on x86_64, make test reported an integer overflow, and you found
a one or three line work-around that replaced longs with ints.

> happen in GNU Sather 2.0 when code breakage is more expected.  It

Oh.  I didn't know any GNU Sather 2.0 was planned.  You didn't mention
in when referring to your plans in response to my first post.  You
said, "I would be interested in helping to modernize GNU Sather if
there is some interest."  When did you last discuss and take feedback
on your GNU Sather 2.0 plans in a GNU Sather mailing list?  How does
it relate to the 1.3 betas?

My second, replacement, set of diffs leave 32-bit Sather code totally
unchanged.  Nil changes.  Apart from fixes to existing broken code.
Still, you'd better leave them alone.  "Code breakage", you know.

> looks like it will be one of the first changes towards 2.0 (along
> with removing the ALL_CAPITAL class requirement).  One decision that

Have you considered the discussion in comp.lang.sather concerning the
decision to make class names all-capital?  Do you reject the reasons
stated by Stephen Omohundro, the inventor of the Sather programming
language?  What are your credentials to do that?

Is there any actual reason to do it?

Are you being guided by the whinges of mere spectators, C programmers
with no commitment to Sather, who don't like change, haven't made the
change, from the C-language aesthetics they are familiar with?  You
need to be careful of people who shout criticisms from 100 paces.

Typing convenience?  When there is only one class name per entire
class, and when reading convenience, perspicuity, easy readability,
easily keeping your bearings when reading the code (not Omohundro's
reason, just a point that occurs to me now) is hugely more important?

And this trifle, a gratuitous change to something that works well, is
the epoch-making change which will define 2.0?  The only one that you
can think of to mention?

> needs to be made is whether GNU Sather 2.x releases should have
> 64bit INTs or C long INTs.  There are pros/cons to either.

Okay, what are the pros and cons?  There is no such issue.  How has it
arisen in your mind?  Again, the decision was made by the language
designer, and I've already, in a recent message, mentioned an obvious
reason why they have to be the size of C longs.  "64bit INTs"?  What
are you talking about?

The decision has been made.  You are the maintainer.  Maintain it!

> If you don't use GNU Sather, you might be on the wrong mailing

I don't use GNU Sather because it has been degraded by gratuitous,
showy but useless, changes made by GNU maintainers.  The most
disgusting to me, though I can understand that others would think it
unimportant, was the change of the name of the executable, from "cs"
to "sacomp".

Yes, I'm on the wrong mailing list.  Will unsubscribe very soon, and
leave you in peace.

> list, but your input is still appreciated.  About the licensing: GNU
> Sather is a part of the GNU system, and as such follows the GNU
> software standards as much as possible.  The ICSI code was donated
> to GNU and with it ICSI allowed the license change.  Since then, it
> has always been GPL-ed.  The original GNU Sather license is
> compatible with converting to GPL v3.

You are absolutely correct.  However my own development is based on
the Sather-1.2b release, not on the later Sather-1.2b-gpl release.
Sather-1.2b was released before it was donated.  When I make changes,
the changes are not automatically GPL'd, and I specifically adhere to
the original Sather license.  You can say that all the code of
Sather-1.2b was subsequently donated, but you can't say that about
development based on Sather-1.2b.

If I post fixes to this mailing list, I place them under the GPL.  I
don't mean that that is automatic, I mean I specifically give that
authority.

I was only saying that marks of my adherence to the Sather license
might have remained in my diffs, specifically, comments with my
initials, and that you are authorized to remove them.

Michael, I hope I didn't set out to attack you, but IMHO your message
does not bear serious scrutiny.  All I could find in it was excuses to
do nothing.  There is a huge amount of work to be done on GNU Sather.
Something as simple and easy as an install target is missing.  pSather
platforms are in disrepair and the 1.2.3 Makefile has:

> #PLATFORMS=linux,linux/lwp,linux_at,linux_at/smp
>
> PLATFORMS=linux

Why is the pSather PLATFORMS line commented out, when most personal
computers on the market today are dual core?

The total concentration on Linux indicated by those lines is
unfortunate and unnecessary, when you have access to a GNU compile
farm.  But, okay, given that, why won't linux/lwp and linux/smp
compile in 1.2.3?

There is much in connection with pSather that needs documentation.
Get it working on Solaris, Solaris 5 if possible, read the headers,
and document them and the programs, how it all works.  Write with a
view to assisting your successors with the information they will need
to do fresh ports to Linux and BSD, to keep them working when other
things change.

There is so much real work to be done that you should be hard at it.
You should be able to say something intelligent about what you are
doing or plan to do, rather than fancifully waffling about Sather 2.0
in the never-never, using the prospect of it as an excuse to do
nothing; and about how you are going to over-rule Berkeley academics
on int versus long, and class name capitalization, things that are
working today as they designed and implemented them.

Regards,
Mike

-- 
Michael Talbot-Wilson