C-language API permits weaker backward compatibility requirements. #1798

jhwoodyatt · 2018-05-24T19:03:05Z

Change to the C-language API extracted from #1003 for introducing the CAML_API_VERSION mechanism to improve control of the backward compatibility requirement.

Add CAML_API_VERSION parameter in the "caml/compatibility.h" header.
Default value is 100.
Explicitly define CAML_NAME_SPACE if CAML_API_VERSION >= 400.
If CAML_API_VERSION < 403, then also #define caml_stat_heap_xxx_size.
If CAML_API_VERSION < 400, then also #define Modify, Begin_roots, End_roots.
Always include "caml/compatibility.h" from "caml/memory.h" header.
Never include "caml/compatibility.h" from other headers.

dra27 · 2018-06-30T12:01:53Z

Sorry, changing the base did not do what I'd hoped - please could you rebase this commit on to trunk?

damiendoligez

There is a problem in compatibility.h. The rest looks OK.

You also need to rebase to trunk. (and also change the base? I'm not sure)

byterun/caml/compatibility.h

xavierleroy · 2018-07-03T16:12:35Z

byterun/caml/memory.h

@@ -465,6 +464,8 @@ CAMLextern struct caml__roots_block *caml_local_roots;  /* defined in roots.c */
  caml_modify (&Field ((block), caml__temp_offset), caml__temp_val); \
 }while(0)

+#if CAML_API_VERSION < 400
+
 /*


I'm afraid that Begin_roots and End_roots are used in code generated by the venerable CamlIDL tool (https://github.com/xavierleroy/camlidl/). The tool hasn't been updated in a long time but still has users. Forcing them to set CAML_API_VERSION to 312 or something is not nice.

Okay. Now that this is on trunk and not 4.07 I'll get around to this after my vacation.

So, first question about this: if the venerable CamlIDL doesn't set CAML_API_VERSION then it defaults to 100, and Begin_roots/End_roots definitions are available accordingly. Am I mistaken?

- Add CAML_API_VERSION parameter in the "caml/compatibility.h" header. - Default value is 100. - Explicitly define CAML_NAME_SPACE if CAML_API_VERSION >= 400. - If CAML_API_VERSION < 403, then also #define caml_stat_heap_xxx_size. - If CAML_API_VERSION < 400, then also #define Modify, Begin_roots, End_roots. - Always include "caml/compatibility.h" from "caml/memory.h" header. - Never include "caml/compatibility.h" from other headers.

jhwoodyatt · 2018-07-26T16:13:49Z

I have rebased this on trunk and addressed the "fishy" thing that @damiendoligez noticed. I'm ready to make whatever change @xavierleroy thinks is necessary to keep CamlIDL from being damaged, but I'm not sure I know what to do there.

xavierleroy · 2018-07-26T16:49:22Z

My problem is that I'm not sure what CAML_API_VERSION=100 means:

all runtime APIs since version 1.00 can be used, or
only runtime APIs that were in version 1.00 can be used.

CamlIDL is a case where we need both old APIs (for code generated by CamlIDL) and newer APIs (for code hand-written by users to do things that CamlIDL cannot handle).

jhwoodyatt · 2018-07-26T19:51:01Z

My problem is that I'm not sure what CAML_API_VERSION=100 means...

I had this problem too, and I agree it's confusing. Here's a proposal, which I hope perhaps @stedolan or somebody else more central to the multicore effort will review, that would expand the set of configuration variables used for API backward compatibility selection.

Change all the instances of CAML_API_VERSION in this change to CAML_API_COMPATIBILITY.
Introduce another configuration variable CAML_API_VERSION which matches the version in the top level VERSION file. (I might be able to write some logic that automatically generates the definition during the compiler build.)

#define CAML_API_COMPATIBILITY 100
#define CAML_API_VERSION 408

This would allow consumers of the runtime API A) to assert their minimum API compatibility using definitions of the CAML_API_COMPATIBILITY variable before inclusion of <caml/compatibility.h>, and B) to adapt their internal logic to version of the API in the current compiler switch.

jhwoodyatt · 2018-09-10T17:19:15Z

Gentle acknowledgement that I'm still holding the ball on this problem, and I'm not sure what to do with it.

damiendoligez · 2018-11-16T13:01:16Z

If I understand correctly, your CAML_API_COMPATIBILITY variable is defined by the user and is the minimum API version needed by the user's code, while the CAML_API_VERSION is the actual version number and defined by the runtime's headers.

jhwoodyatt · 2018-11-27T19:13:18Z

If I understand correctly, your CAML_API_COMPATIBILITY variable is defined by the user and is the minimum API version needed by the user's code, while the CAML_API_VERSION is the actual version number and defined by the runtime's headers.

That's what I think I was doing, yes. Again, I'm not sure this pull request is really the appropriate way to address the underlying problem, or even if the underlying problem is important enough to address. My interest in it developed when I tried to make some of my personal code with a few C-language foreign functions in it compile under the Multicore OCaml branch, which seems like it will need something in the runtime interface that allows extension implementations to compile according to the version of the runtime available.

jhwoodyatt · 2018-11-27T19:13:55Z

When I get a few spare cycles next, I'll see about resolving those merge conflicts.

XVilka · 2019-09-20T07:41:57Z

@johnwhitington will be this part of the 4.10 by any chance?

johnwhitington · 2019-09-20T07:49:20Z

@XVilka I assume that was autocomplete for @jhwoodyatt :-)

XVilka · 2019-09-20T07:59:48Z

Yes, sorry about that.

gadmm · 2019-12-07T11:30:43Z

This is superseded by #9167 in case it is accepted. Please see the discussion there.

jhwoodyatt · 2019-12-10T22:24:41Z

I'm tracking the progress of #9167 and will withdraw this if that achieves consensus.

gadmm · 2020-01-23T21:57:15Z

For the record, I proposed a clarification of CAML_API_VERSION renamed as CAML_NAME_SPACE at #9167 which can be reused. (The bug #9167 was meant to fix was fixed differently but I still think that the approach there is preferable if some mechanism of the sort is deemed useful.)

jhwoodyatt · 2021-06-10T21:51:35Z

Abandoning this request as the basic concern was more recently considered in #9167 and keeping this open when that has been closed seems unnecessary.

* Figma colors tailwind.config.js, old colors->legacy, tutorial block, hero section * split hero background in background and camel, scale background * remove featured+rating on book, book difficulty variant type, lang manual banner draft, books block draft * add two more book recommendations * exercises block * language manual banner background * better book recommendation text * move industrial user success story card to template * platform tools section learn landing, rename legacy cards class * update border color from Figma, adjust card hover shadow, transform paper cards to new class * refactor footer * refactor learn_sidebar into learn_layout * buttons from design system, substitute legacy primary by new primary, books page * exercises.eml * legacy primary-600 and primary-700 to new primary color

jhwoodyatt force-pushed the x-jhwoodyatt-api-version branch from 4384918 to 6fa8189 Compare May 24, 2018 19:07

damiendoligez self-assigned this May 31, 2018

dra27 changed the base branch from 4.07 to trunk June 30, 2018 12:01

dra27 changed the base branch from trunk to 4.07 June 30, 2018 12:01

damiendoligez requested changes Jul 3, 2018

View reviewed changes

byterun/caml/compatibility.h Outdated Show resolved Hide resolved

xavierleroy reviewed Jul 3, 2018

View reviewed changes

jhwoodyatt force-pushed the x-jhwoodyatt-api-version branch from 6fa8189 to 2f0769e Compare July 26, 2018 16:10

jhwoodyatt changed the base branch from 4.07 to trunk July 26, 2018 16:11

gadmm mentioned this pull request Oct 16, 2019

Coq's vm_compute code is broken on trunk/4.10 #9013

Closed

gadmm mentioned this pull request Dec 7, 2019

Fix compatibility.h inclusion and add CAML_NAME_SPACE versioning #9167

Closed

gasche mentioned this pull request Dec 23, 2019

meta-issue on C runtime API and compatibility stories #9205

Closed

jhwoodyatt closed this Jun 10, 2021

C-language API permits weaker backward compatibility requirements. #1798

C-language API permits weaker backward compatibility requirements. #1798

Uh oh!

Conversation

jhwoodyatt commented May 24, 2018

Uh oh!

dra27 commented Jun 30, 2018

Uh oh!

damiendoligez left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

xavierleroy Jul 3, 2018

Choose a reason for hiding this comment

Uh oh!

jhwoodyatt Jul 5, 2018

Choose a reason for hiding this comment

Uh oh!

jhwoodyatt Jul 26, 2018

Choose a reason for hiding this comment

Uh oh!

jhwoodyatt commented Jul 26, 2018

Uh oh!

xavierleroy commented Jul 26, 2018

Uh oh!

jhwoodyatt commented Jul 26, 2018

Uh oh!

jhwoodyatt commented Sep 10, 2018

Uh oh!

damiendoligez commented Nov 16, 2018

Uh oh!

jhwoodyatt commented Nov 27, 2018

Uh oh!

jhwoodyatt commented Nov 27, 2018

Uh oh!

XVilka commented Sep 20, 2019

Uh oh!

johnwhitington commented Sep 20, 2019

Uh oh!

XVilka commented Sep 20, 2019

Uh oh!

gadmm commented Dec 7, 2019

Uh oh!

jhwoodyatt commented Dec 10, 2019

Uh oh!

gadmm commented Jan 23, 2020

Uh oh!

jhwoodyatt commented Jun 10, 2021

Uh oh!

Uh oh!

damiendoligez left a comment •

edited

Loading