Rules on modifying/updating the standard library (interface index)

[NormHarrison]

Hi, I came across this project sometime last year, but only began to actually use it over the past few months. I find the state that Critical Mass/Elegosoft left it in upon open sourcing to be quite impressive and complete, though I had a few questions regarding the rules employed on the modules that the project "ships" with.

For example, I was looking over the interface of Uerror, trying to find if the UNIX strerror() function already had a binding. At the bottom of the interface definition, you can see that there is indication of it's presence:

<*EXTERNAL*>
VAR
  errno: int;

Extension by mjordan

CONST
  Max = ELAST; (* should be exported from Uerror *)

<*EXTERNAL*> VAR
  sys_nerr: int;
  sys_errlist: ARRAY [0..Max] OF char_star;

PROCEDURE GetFrom_sys_errlist(n: INTEGER): char_star RAISES {};

   returns entry n of the 'sys_errlist' array; a checked runtime error unless 0 <= n <= sys_nerr. Its safer and more portable to use this procedure than to access the array directly.

Though upon looking through the repository and the resulting packages installed with the distribution, it doesn't actually seem to appear (at least) on Linux in the resulting common Uerror interface under pkg/m3core/src/unix/Common/Uerror.i3. Assuming I haven't missed or misunderstood anything, would it be permitted by the main "overseers" of this repository to update/fix things like this that are part of the core libraries of the project? I assume it likely depends on whether the changes will break existing code etc. I know I can easily bind to this function myself for what I'm trying to do, but since I do care about this project, I wanted to ask how these situations were handled for possible future encounters.

Thank you

[demoitem]

I can see it in the Cstring interface. Which seems to contain a bunch of functions with the str prefix. Apart from those starting with mem of course. :)

[RodneyBates]

This kind of change is welcome.  There has not been a compelling need for strong  gatekeeping here. You probably need someone to give you push access, but I don't know who controls that.    There is now automatic running of a lot of testing, triggered by a push.  I don't know if it extends to newly created branches.  It  compiles the compiler twice by itself and runs several hundred  tests, so breakage is likely to be found quickly.  Some of the more peripheral code is not tests automatically, especially gui things, but the compiler, main libraries, etc. are.

On 6/8/22 23:47, NormHarrison wrote:

Hi, I came across this project sometime last year, but only began to actually use it over the past few months. I find the state that Critical Mass/Elegosoft left it in upon open sourcing to be quite impressive and complete, though I had a few questions regarding the rules employed on the modules that the project "ships" with.

For example, I was looking over the interface of Uerror https://modula3.github.io/cm3/help/gen_html/m3core/src/unix/freebsd-3/Uerror.i3.html, trying to find if the UNIX |strerror()| function already had a binding. At the bottom of the interface definition, you can see that there is indication of it's presence:

|<EXTERNAL> VAR errno: int; Extension by mjordan CONST Max = ELAST; ( should be exported from Uerror ) <EXTERNAL> VAR sys_nerr: int; sys_errlist: ARRAY [0..Max] OF char_star; PROCEDURE GetFrom_sys_errlist(n: INTEGER): char_star RAISES {}; returns entry n of the 'sys_errlist' array; a checked runtime error unless 0 <= n <= sys_nerr. Its safer and more portable to use this procedure than to access the array directly. |

Though upon looking through the repository and the resulting packages installed with the distribution, it doesn't actually seem to appear (at least) on Linux in the resulting common |Uerror| interface under |pkg/m3core/src/unix/Common/Uerror.i3|. Assuming I haven't missed or misunderstood anything, would it be permitted by the main "overseers" of this repository to update/fix things like this that are part of the core libraries of the project? I assume it likely depends on whether the changes will break existing code etc. I know I can easily bind to this function myself for what I'm trying to do, but since I do care about this project, I wanted to ask how these situations were handled for possible future encounters.

Thank you

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1030, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSVZNEXD26DOFBHBIKWRP3VOFZNFANCNFSM5YIV4UUQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[RodneyBates]

}  it extends to newly created branchesYes, it extends.} It  compiles the compiler twice by itself About twice - I am not sure.But: We can replace 5.11.4 to 5.11.9( I have *.9)} push accessWho known: I have push access? Or have not?09.06.2022, 20:46, "Rodney Bates" @.***>: This kind of change is welcome.  There has not been a compelling need for strong  gatekeeping here. You probably need someone to give you push access, but I don't know who controls that.    There is now automatic running of a lot of testing, triggered by a push.  I don't know if it extends to newly created branches.  It  compiles the compiler twice by itself and runs several hundred  tests, so breakage is likely to be found quickly.  Some of the more peripheral code is not tests automatically, especially gui things, but the compiler, main libraries, etc. are.

On 6/8/22 23:47, NormHarrison wrote:

  Hi, I came across this project sometime last year,
    but only began to actually use it over the past few months. I
    find the state that Critical Mass/Elegosoft left it in upon open
    sourcing to be quite impressive and complete, though I had a few
    questions regarding the rules employed on the modules that the
    project "ships" with.
  For example, I was looking over the interface of Uerror, trying to
    find if the UNIX strerror()
    function already had a binding. At the bottom of the interface
    definition, you can see that there is indication of it's
    presence:
  <*EXTERNAL*>

VAR errno: int;

Extension by mjordan

CONST Max = ELAST; ( should be exported from Uerror )

<EXTERNAL> VAR sys_nerr: int; sys_errlist: ARRAY [0..Max] OF char_star;

PROCEDURE GetFrom_sys_errlist(n: INTEGER): char_star RAISES {};

returns entry n of the 'sys_errlist' array; a checked runtime error unless 0 <= n <= sys_nerr. Its safer and more portable to use this procedure than to access the array directly.

  Though upon looking through the repository and the
    resulting packages installed with the distribution, it doesn't
    actually seem to appear (at least) on Linux in the resulting
    common Uerror interface under
    pkg/m3core/src/unix/Common/Uerror.i3.
    Assuming I haven't missed or misunderstood anything, would it be
    permitted by the main "overseers" of this repository to
    update/fix things like this that are part of the core libraries
    of the project? I assume it likely depends on whether the
    changes will break existing code etc. I know I can easily bind
    to this function myself for what I'm trying to do, but since I
    do care about this project, I wanted to ask how these situations
    were handled for possible future encounters.
  Thank you
  —
    Reply to this email directly, view it on GitHub, or unsubscribe.
    You are receiving this because you are subscribed to this
    thread.Message
      ID: ***@***.***>

,___M3devel mailing @.***://m3lists.elegosoft.com/mailman/listinfo/m3devel

[VictorMiasnikov]

^^^^ There is my message that sent 10.06.2022, 08:45, "vvm@ZZZZZZZZZZZ" But I even can not edit it...

[VictorMiasnikov]

On 6/8/22 23:47, NormHarrison wrote: …

09.06.2022, 20:46, "Rodney Bates" @.***>: This kind of change is welcome.  There has not been a compelling need for strong  gatekeeping here. You probably need someone to give you push access, but I don't know who controls that.    There is now automatic running of a lot of testing, triggered by a push.  I don't know if it extends to newly created branches.  It  compiles the compiler twice by itself and runs several hundred  tests, so breakage is likely to be found quickly.  Some of the more peripheral code is not tests automatically, especially gui things, but the compiler, main libraries, etc. are.

}  it ( VVM: i.e. "automatic running of a lot of testing" ) extends to newly created branches

Yes, it extends.

} It  compiles the compiler twice by itself 

About twice - I am not sure.

But: We can replace 5.11.4 to 5.11.9 ( I have *.9)

} push access

Who known: I have push access? Or have not?

[VictorMiasnikov]

Folder /m3core/src/unix/freebsd-3/ and whole /m3core/src/unix/ even doen't exits inside source tree.

Best choice is regenerating all documentaion inside . . . /help/gen_html/

( IMHO, as minimum)

[NormHarrison]

I can see it in the Cstring interface. Which seems to contain a bunch of functions with the str prefix. Apart from those starting with mem of course. :)

Aha, thank you. I'm not sure why I kept searching for the alternate name that was depicted in the Uerror.i3 interface documentation, and didn't try the original C function name instead... Though I did come across another situation like this for the socketpair() binding listed at the bottom of Usocket.i3, as it doesn't appear inside the resulting file pkg/m3core/src/unix/Common/Usocket.i3 and only the documentation. Again no a big deal of course, just some inconsistencies here and there that I assume were created long ago.

This kind of change is welcome. There has not been a compelling need for strong gatekeeping here. You probably need someone to give you push access, but I don't know who controls that. There is now automatic running of a lot of testing, triggered by a push. I don't know if it extends to newly created branches. It compiles the compiler twice by itself and runs several hundred tests, so breakage is likely to be found quickly. Some of the more peripheral code is not tests automatically, especially gui things, but the compiler, main libraries, etc. are.

Thank you for the quick response sir, I am very glad to hear that this is the opinion. I would indeed like to assist, and while I am not experienced as anyone here, I can experiment locally and possibly just make pull requests until we can figure out what to do regarding direct access. I did see that someone with the username "Eric Sessoms" appeared and completely revamped the build process, but then seemingly disappeared. I have no clue if this account is related to that person, but a new account under the same name appeared 4 days ago. Regarding some possibly more serious issues with the project overall, while working on something last night, it seems I managed to write something that makes the compiler itself consistently produce a runtime error while compiling a module implementation file (it is an array subscript error specifically). I haven't looked into it more yet, but will do so tomorrow, it may have been something rather silly I did on accident.

Thank you

[VictorMiasnikov]

} makes the compiler

Are You see

https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20220208_13-48

?

[VictorMiasnikov]

I did see that someone with the username "Eric Sessoms" appeared and completely revamped the build process, but then seemingly disappeared. I have no clue if this account is related to that person, but a new account under the same name appeared 4 days ago.

I sent e-mail message to "our Eric Sessoms" ;-)

In any key d5.11.9-ZZYYXX-20220208_13-48 contain both "old style cm3-all-*" with worked Calc[.exe] and modern cm3-allby.concierge.pyfull-upgradeall.-AMD64_LINUX-d5.11.9- ( . . .) .deb