[Caml-list] removal of C compiler variables in in 4.06

[Caml-list] removal of C compiler variables in in 4.06

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

While wresting with labltk and 4.05 I noticed an backwards incompatible
change in labltk.git (986e116 "Fix for ocaml 4.06") and in ocaml.git
(cc7ad5650a "Get rid of BYTECC and NATIVECC"). What is the rationale to
break external users of BYTECC/NATIVECC? Perhaps labltk shouldnt have
used these variables in the first place. But if their usage is legitime,
why the needless breakage?

Olaf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Caml-list] removal of C compiler variables in in 4.06

[Adrien Nader]

Hi,

On Tue, Jul 18, 2017, Olaf Hering wrote:
> While wresting with labltk and 4.05 I noticed an backwards incompatible
> change in labltk.git (986e116 "Fix for ocaml 4.06") and in ocaml.git
> (cc7ad5650a "Get rid of BYTECC and NATIVECC"). What is the rationale to
> break external users of BYTECC/NATIVECC? Perhaps labltk shouldnt have
> used these variables in the first place. But if their usage is legitime,
> why the needless breakage?

First of all, I absolutely definitely completely would not call these
"needless" and even less say that breakage was voluntary. I understand
your frustration but the way you communicate about the issue doesn't
come out as nice.

This change was part of a huge set of changes to fix 20 years of
duplication between the Makefile and Makefile.nt files in the build
system.
The commit that did the changes is the following:
https://github.com/ocaml/ocaml/commit/cc7ad5650aac641053178ec1d08789b8e793e87b

I don't think it makes sense to try to give you straight away another
variable to use. Chances are that, in the first place, this variable
wasn't the one that made sense to use. Moreover its content could change
at any time (and did change). If you explain the needs, then it should
be possible to give you better hints to adapt to this change.

Best,

-- 
Adrien Nader

Re: [Caml-list] removal of C compiler variables in in 4.06

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On Tue, Jul 18, Adrien Nader wrote:

> First of all, I absolutely definitely completely would not call these
> "needless" and even less say that breakage was voluntary. I understand
> your frustration but the way you communicate about the issue doesn't
> come out as nice.

It was not meant to be rude or demanding. Sorry for that.

> I don't think it makes sense to try to give you straight away another
> variable to use. Chances are that, in the first place, this variable
> wasn't the one that made sense to use. Moreover its content could change
> at any time (and did change). If you explain the needs, then it should
> be possible to give you better hints to adapt to this change.

It seems labltk is the only package which makes use of BYTECC/NATIVECC.
So in this context cc7ad5650a is correct.

I was hoping labltk.git#master would just work with "every" ocaml
version. But now #master works with none.

As noted in other replies, there is an issue open at github. Hopefully
it gets sorted out at some point.


Olaf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Caml-list] removal of C compiler variables in in 4.06

[Stéphane Glondu]

On 18/07/2017 11:02, Olaf Hering wrote:
> While wresting with labltk and 4.05 [...]

FYI, I've fixed labltk with 4.05 in the Debian package (not yet uploaded):

 
https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/labltk.git/tree/debian/patches

Maybe you can double-check and submit upstream?


Cheers,

-- 
Stéphane

Re: [Caml-list] removal of C compiler variables in in 4.06

[Gabriel Scherer]

The BYTECC and NATIVECC variables are still present in 4.05 (the last
release), they are gone in 4.06 (the in-development version). Olaf
mentions that this requires a change to the labltk build system, but
the change should not affect 4.05.

Stéphane, in your patches, it looks to me like you apply the
4.06-required change in 0001-Fix-for-ocaml-4.06.patch, and then you
cancel them in 0003-CC-variable-does-not-exist-in-4.05.0-s-Makefile.conf.patch
to go back to the unchanged state. Could you apply none of them
instead? (It does not help that there is an unrelated change in
0001-..-4.06.patch, it would be nicer to have two separate patches.)

Note that your patch 0002-Fix-calls-to-caml_-functions.patch is very
nice (use of the caml_ prefix for C runtime functions, the unprefixed
functions being deprecated and disabled by default), you should
definitely submit it upstream.

On Tue, Jul 18, 2017 at 7:37 AM, Stéphane Glondu <steph@glondu.net> wrote:
> On 18/07/2017 11:02, Olaf Hering wrote:
>>
>> While wresting with labltk and 4.05 [...]
>
>
> FYI, I've fixed labltk with 4.05 in the Debian package (not yet uploaded):
>
>
> https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/labltk.git/tree/debian/patches
>
> Maybe you can double-check and submit upstream?
>
>
> Cheers,
>
> --
> Stéphane
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] removal of C compiler variables in in 4.06

[Stéphane Glondu]

On 18/07/2017 14:24, Gabriel Scherer wrote:
> Stéphane, in your patches, it looks to me like you apply the
> 4.06-required change in 0001-Fix-for-ocaml-4.06.patch,

That patch is not mine. It is taken from upstream git repository. My 
patches are 0002- to 0004- and (should) apply to the master branch of 
upstream repository.

> and then you
> cancel them in 0003-CC-variable-does-not-exist-in-4.05.0-s-Makefile.conf.patch
> to go back to the unchanged state. Could you apply none of them
> instead? (It does not help that there is an unrelated change in
> 0001-..-4.06.patch, it would be nicer to have two separate patches.)

I agree. I kept 0001- as is because the unrelated change is also needed 
to compile with 4.05.0

> Note that your patch 0002-Fix-calls-to-caml_-functions.patch is very
> nice (use of the caml_ prefix for C runtime functions, the unprefixed
> functions being deprecated and disabled by default), you should
> definitely submit it upstream.

https://github.com/garrigue/labltk/issues/4


Cheers,

-- 
Stéphane

Re: [Caml-list] removal of C compiler variables in in 4.06

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

On Tue, Jul 18, Stéphane Glondu wrote:

> FYI, I've fixed labltk with 4.05 in the Debian package (not yet uploaded):
> https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/labltk.git/tree/debian/patches

Thanks, I came up with the same changes, execpt the one for
"Texp_function".

Olaf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Caml-list] removal of C compiler variables in in 4.06

[Gabriel Scherer]

I think that it should not be too hard to use a bash sleight-of-hand
to define a variable as BYTECC if it is defined and CC otherwise (or
the other way around), to get a labltk makefile that works with both.
(The Texp_function change is harder and you may need
version-conditional preprocessing, typically using cppo, to handle
them; this is the price to pay for accessing unstable
compiler-internal definitions.)

Note that labltk is currently hosted on the OCaml Forge, which is due
to be closed soon, so moving to a different place would be required. If
you are interested in labltk and helping its maintenance, you should
contact the current maintainers, who may welcome help for the migration
and the kind of maintenance work this thread is about.

On Tue, Jul 18, 2017 at 9:41 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Jul 18, Stéphane Glondu wrote:
>
>> FYI, I've fixed labltk with 4.05 in the Debian package (not yet uploaded):
>> https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/labltk.git/tree/debian/patches
>
> Thanks, I came up with the same changes, execpt the one for
> "Texp_function".
>
> Olaf

Re: [Caml-list] removal of C compiler variables in in 4.06

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

On Tue, Jul 18, Gabriel Scherer wrote:

> (The Texp_function change is harder and you may need
> version-conditional preprocessing, typically using cppo, to handle
> them; this is the price to pay for accessing unstable
> compiler-internal definitions.)

Right now it requires at least 4.04 due to usage of Ppat_open.

> Note that labltk is currently hosted on the OCaml Forge, which is due
> to be closed soon, so moving to a different place would be required. If
> you are interested in labltk and helping its maintenance, you should
> contact the current maintainers, who may welcome help for the migration
> and the kind of maintenance work this thread is about.

Well, I can certainly help if needed.


Olaf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [Caml-list] removal of C compiler variables in in 4.06

[Jesper Louis Andersen]

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

On Tue, Jul 18, 2017 at 11:04 AM Olaf Hering <olaf@aepfle.de> wrote:

>

But if their usage is legitime,
> why the needless breakage?
>

I like to think of software as sometimes hitting a local optima. That is,
to move forward you have to stop the hill-climbing algorithm and  start
going in the "wrong direction" in order to hit a better spot later on.

Every feature in a system is also a liability later on. Hence, any change
is a balancing act of keeping backwards compatibility and moving forward.
I'd expect some breakage between software releases. Some of these are
potential incompatibilities, and in the unlucky case, an incompatibility
which noone foresaw sneaks in[0]. The goal is to manage the amount of work
it takes to upgrade systems, and possibly provide automated tools to help
doing so[1].

Removing features is a great way to move forward. I've often salvaged old
code by removing a lot of support for desirable features, revamped the
systems core, and then added those features which were truly needed later
on. We also learn in hindsight, so many changes eventually have to be
reverted. The larger your interface, the more brittle it tends to be.

That said, it certainly sounds like a too eager change since 4.06 is not
slated for release for a while. But I wanted to ramble a bit about
controlled change in a software system.

[0] 4 years ago, the Erlang serialization "external term format" was
changed to allow for certain symbols to be UTF-8 encoded. Releases would be
able to handle the decoding, but would not produce such terms. The recent
20.0-rc1 release enabled the feature since it was believed that backwards
compatibility was in place. Yet, it broke systems because they rely on
things like the lexicographic ordering of the marshalled serialization,
among other things. The final release had to avoid producing the new UTF-8
encoded form if the symbol (atom) was representable in the old (ASCII)
form. Erlang highly values its backwards compatibility because upgrades to
clusters tend to happen one machine at a time.

[1] The Go language used a tool 'go fix' to upgrade breaking changes to the
syntax before release 1.0 of the language. This enabled change, yet
provided an upgrade path for existing code. 'go fix' is simpler in Go
because all code has a default formatting through 'go fmt' so you can just
read the AST, change it, render it, and run 'go fmt' on it. The fixes are
also rather crude and syntactical. This was no Cocinelle.

[-- Attachment #2: Type: text/html, Size: 3048 bytes --]