MariaDB/MySQL on x86

[issinoho]

Has there been any talk on this being ported?

[Ian Miller]

On Saturday, April 22, 2023 at 11:38:25 AM UTC+1, issinoho wrote:
> Has there been any talk on this being ported?

See https://forum.vmssoftware.com/viewtopic.php?f=41&t=8627&p=18284&hilit=sql#p18284

and note https://www.mimer.com/mimer-announces-support-for-openvms-v9-2/

[issinoho]

Excellent. Thanks.

[Craig A. Berry]

On 4/22/23 5:38 AM, issinoho wrote:
> Has there been any talk on this being ported?

The C++ compiler that will be necessary to make it even theoretically
possible is still in field test and only became available quite
recently. One can hope, but we won't really know until someone does the
work.

[Arne Vajhøj]

MySQL/MariaDB runs on VMS Alpha and VMS Itanium.

All that is needed to build for VMS x86-64 in the same
version (5.5) as on the other two should be a traditional VMS
compiler. Isn't C++ available as cross compiler?

It has explained stated that getting newer versions of
MySQL/MariaDB (10.x and 11.x) running on VMS require compiler
with support for newer standards - aka need clang.

Arne

[Craig A. Berry]

On 4/24/23 5:18 PM, Arne Vajhøj wrote:
> On 4/24/2023 6:12 PM, Craig A. Berry wrote:
>> On 4/22/23 5:38 AM, issinoho wrote:
>>> Has there been any talk on this being ported?
>>
>> The C++ compiler that will be necessary to make it even theoretically
>> possible is still in field test and only became available quite
>> recently.  One can hope, but we won't really know until someone does the
>> work.
>
> MySQL/MariaDB runs on VMS Alpha and VMS Itanium.

Yeah, but only versions that are near or past EOL.

> All that is needed to build for VMS x86-64 in the same
> version (5.5) as on the other two should be a traditional VMS
> compiler. Isn't C++ available as cross compiler?

Doesn't look like it, according to this:

https://docs.vmssoftware.com/docs/vsi-x86-64-cross-tools-kit-installation-and-startup-guide-v92.pdf

> It has explained stated that getting newer versions of
> MySQL/MariaDB (10.x and 11.x) running on VMS require compiler
> with support for newer standards - aka need clang.

And clang++ is the only C++ there will be for x86.

[Arne Vajhøj]

On 4/24/2023 8:33 PM, Craig A. Berry wrote:
> On 4/24/23 5:18 PM, Arne Vajhøj wrote:
>> On 4/24/2023 6:12 PM, Craig A. Berry wrote:
>>> On 4/22/23 5:38 AM, issinoho wrote:
>>>> Has there been any talk on this being ported?
>>>
>>> The C++ compiler that will be necessary to make it even theoretically
>>> possible is still in field test and only became available quite
>>> recently.  One can hope, but we won't really know until someone does the
>>> work.
>>
>> MySQL/MariaDB runs on VMS Alpha and VMS Itanium.
>
> Yeah, but only versions that are near or past EOL.

MariaDB 5.5 is from 2012 and went EOL in 2020.

Old indeed in general IT. Not quite as old in the VMS world.

And I think it is quite OK functionality wise.

The only think that comes to my mind as missing is the
JSON support in newer versions.

>> All that is needed to build for VMS x86-64 in the same
>> version (5.5) as on the other two should be a traditional VMS
>> compiler. Isn't C++ available as cross compiler?
>
> Doesn't look like it, according to this:
>
> https://docs.vmssoftware.com/docs/vsi-x86-64-cross-tools-kit-installation-and-startup-guide-v92.pdf

That explains why they have not been ported yet.

>> It has explained stated that getting newer versions of
>> MySQL/MariaDB (10.x and 11.x) running on VMS require compiler
>> with support for newer standards - aka need clang.
>
> And clang++ is the only C++ there will be for x86.

I don't think anyone will miss traditional VMS C++.

It is so far behind.

Arne

[Vitaly Pustovetov]

> > https://docs.vmssoftware.com/docs/vsi-x86-64-cross-tools-kit-installation-and-startup-guide-v92.pdf
> That explains why they have not been ported yet.

It is more likely that there was no customer interested in porting MariaDB to x86. So, now I'm using clang to complete the preparation of JDK 8u372 for field testing... it's just a matter of priorities.

Vitaly

[Arne Vajhøj]

That is also important for us that like everything starting with J.

:-)

Most existing VMS customers are using Rdb (or inddex-sequential files).
But any new or "come back" VMS users will be looking for a RDBMS. And
right now Mimer seems to be the only one available for VMS x86-64.
Good for them to get more on the VMS radar screen I guess.

Arne

[Mark Berryman]

When the field test C++ compiler became available I attempted to build
my MariaDB v5.5 kit. It was a no go for a few reasons.

One,
The field test is still limited in some functionality. For example,
there are some pragmas that are not yet supported or not yet fully
supported. The include_directory pragma does not yet appear to work and
my build procedure depends heavily on this.

Two,
There are a number of places in the port that assume that long and
size_t are 32 bits. For x86_64, they are 64 bits. Addressing this
would almost mean redoing the port. (I think long is a bigger issue than
size_t).

Three,
In order for the headers included with the compiler to compile
correctly, certain values must be defined. For example, in order to use
string.h, either __CORRECT_ISO_CPP_STRING_H_PROTO or
_STRING_H_CPLUSPLUS_98_CONFORMANCE_ must be defined. Otherwise, the
compiler throws errors and aborts. I did not see anything about this in
the documentation and stumbled across it when trying to figure out why
the errors were occurring. Now I wonder if there are others.

I think MariaDB, either V5 for V10, will have to wait until the C++
compiler is more complete.

Mark Berryman

[Arne Vajhøj]

On 4/25/2023 11:33 AM, Mark Berryman wrote:
> On 4/24/23 4:12 PM, Craig A. Berry wrote:
>> On 4/22/23 5:38 AM, issinoho wrote:
>>> Has there been any talk on this being ported?
>>
>> The C++ compiler that will be necessary to make it even theoretically
>> possible is still in field test and only became available quite
>> recently.  One can hope, but we won't really know until someone does the
>> work.
>
> When the field test C++ compiler became available I attempted to build
> my MariaDB v5.5 kit.  It was a no go for a few reasons.
>
> One,
> The field test is still limited in some functionality.  For example,
> there are some pragmas that are not yet supported or not yet fully
> supported.  The include_directory pragma does not yet appear to work and
> my build procedure depends heavily on this.

Is that VMS C++ specific pragma or standard?

If VMS C++ specific then maybe it will not be added as I believe John R
want to keep the C++ compiler as close to clang elsewhere as possible.

> Two,
> There are a number of places in the port that assume that long and
> size_t are 32 bits.  For x86_64, they are 64 bits.  Addressing this
> would almost mean redoing the port. (I think long is a bigger issue than
> size_t).

That seems unlikely to be fixed in the compiler.

Time for int32_t and int64_t?

> Three,
> In order for the headers included with the compiler to compile
> correctly, certain values must be defined.  For example, in order to use
> string.h, either __CORRECT_ISO_CPP_STRING_H_PROTO or
> _STRING_H_CPLUSPLUS_98_CONFORMANCE_ must be defined.  Otherwise, the
> compiler throws errors and aborts.  I did not see anything about this in
> the documentation and stumbled across it when trying to figure out why
> the errors were occurring.  Now I wonder if there are others.

That sound as a bug.

> I think MariaDB, either V5 for V10, will have to wait until the C++
> compiler is more complete.

11.0 is already RC, so maybe go straight to 11 instead of 10.

Arne

[Craig A. Berry]

On 4/25/23 12:04 PM, Arne Vajhøj wrote:
> On 4/25/2023 11:33 AM, Mark Berryman wrote:

>> The field test is still limited in some functionality.  For example,
>> there are some pragmas that are not yet supported or not yet fully
>> supported.  The include_directory pragma does not yet appear to work
>> and my build procedure depends heavily on this.
>
> Is that VMS C++ specific pragma or standard?

Pages 24-25 here:

https://docs.vmssoftware.com/test-docs/vsi-cxx-user-s-guide-for-openvms-systems.pdf

say:

"This pragma is intended to ease DCL command-line length limitations
when porting applications from POSIX-like environments built with
makefiles containing long lists of -I options that specify directories
to search for headers. Just as long lists of macro definitions specified
by the /DEFINE qualifier can be converted to #define directives in a
source file, long lists of places to search specified by the
/INCLUDE_DIRECTORY qualifier can be converted to #pragma
include_directory directives in a source file."

> If VMS C++ specific then maybe it will not be added as I believe John R
> want to keep the C++ compiler as close to clang elsewhere as possible.

A worthy goal, but if there are workarounds in the compiler for
limitations in the VMS build environment, they may very well still be
needed. Unless alternate solutions are found. In this case, it *might*
be possible, depending on current command line length limitations and
where and how the MariaDB build exceeds them, to use clang++ rather than
CXX from the command line. That based on the fact that -Ifoo takes up
less space than /INCLUDE=[foo]. But even if that works, it's just one
reason it might be a new port as Mark suggested might be necessary
rather than just carrying forward the existing port.

[Arne Vajhøj]

Maybe I should have RTFM ...

:-)

But I got it now.

I am sort of in favor of logicals here if possible (but it is not
necessarily possible).

:-)

Demo:

$ type [.liba.include]a.h
char *a = "This is A";
$ type [.libb.include]b.h
char *b = "This is B";
$ type w1.c
#include <stdio.h>

#include "a.h"
#include "b.h"

int main(int argc, char *argv[])
{
printf("%s\n", a);
printf("%s\n", b);
return 0;
}
$ cc /include=([.liba.include],[.libb.include]) w1
$ link w1
$ run w1
This is A
This is B
$ type w2.c
#pragma include_directory "[.liba.include]"
#pragma include_directory "[.libb.include]"

#include <stdio.h>

#include "a.h"
#include "b.h"

int main(int argc, char *argv[])
{
printf("%s\n", a);
printf("%s\n", b);
return 0;
}
$ cc w2
$ link w2
$ run w2
This is A
This is B
$ type w3.c
#include <stdio.h>

#include "liba/include/a.h"
#include "libb/include/b.h"

int main(int argc, char *argv[])
{
printf("%s\n", a);
printf("%s\n", b);
return 0;
}
$ define/nolog liba [.liba]
$ define/nolog libb [.libb]
$ cc w3
$ link w3
$ run w3
This is A
This is B

Arne

[Arne Vajhøj]

On 4/25/2023 5:18 PM, Arne Vajhøj wrote:
> #include "liba/include/a.h"
> #include "libb/include/b.h"

> $ define/nolog liba [.liba]
> $ define/nolog libb [.libb]

Make that:

#include "libadir/include/a.h"
#include "libbdir/include/b.h"

$ define/nolog libadir [.liba]
$ define/nolog libbdir [.libb]

because otherwise it would work without logicals.

Arne

[John Reagan]

I've been away on vacation for a few weeks. I'll get a status and post in a few days.

[Neil Rieck]

On Saturday, April 22, 2023 at 6:38:25 AM UTC-4, issinoho wrote:
> Has there been any talk on this being ported?

As others have already mentioned, both MySQL-5.5 and MariaDB-5.5 are no longer supported.

And when they were, I was experiencing database corruptions problems at shutdown that forced me to move to MariaDB-10 on Linux
(our shop has been employing heterogeneous computing since 2016; our primary businesses systems run OpenVMS but our relational databases were being served up on CentOS-7; now Rocky-8)

One of the annoyances with MariaDB-10 (and MySQL-6) is that they can only be built with C11 which is still not available on OpenVMS/Alpha or OpenVMS/Itanium
(that blame goes to all the companies before VSI who did not take C/C++ seriously enough to keep the C/C++ ecosystem up to date on OpenVMS).
(not sure why the authors of MySQL and MariaDB did not follow the example set by Apache where HTTPd would always be tied to a simpler version of C)

Everyone reading this knows how difficult it is to play catchup whenever a company has allowed something to slide for more than a decade (IIRC, C99 was the last standard supported by Compaq and I do not recall any progress being made when HP was at the helm).

Kudos to VSI for making as much progress as they have. I only hope that they get around to also supporting C17 (stable) and C23 (pre-release)

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
http://neilrieck.net/OpenVMS.html

[Craig A. Berry]

On 4/26/23 5:33 AM, Neil Rieck wrote:

> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
> only be built with C11 which is still not available on OpenVMS/Alpha
> or OpenVMS/Itanium

Not sure that will ever happen. It's hard to see how VSI can afford to
continue to make major changes to the traditional front end on all
platforms while also keeping up with clang on x86.

> Kudos to VSI for making as much progress as they have. I only hope
> that they get around to also supporting C17 (stable) and C23 (pre-release)

Have you tried the clang-based C++ compiler currently in field test,
which, as a side effect of being clang, works as either a C compiler or
a C++ compiler? I suspect that will be the path forward for newer
standards.

[Simon Clubley]

On 2023-04-25, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 4/25/2023 12:14 AM, Vitaly Pustovetov wrote:
>>
>> It is more likely that there was no customer interested in porting
>> MariaDB to x86. So, now I'm using clang to complete the preparation
>> of JDK 8u372 for field testing... it's just a matter of priorities.
> That is also important for us that like everything starting with J.
>
>:-)
>

So what did you think about _J_OVIAL ? :-)

Or _J_avascript for that matter ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[bill]

On 4/26/2023 8:14 AM, Simon Clubley wrote:
>
> So what did you think about _J_OVIAL ? :-)
>

Laugh all you want. The last I heard the USAF is still using
Jovial. Especially after the fiasco their pet project Ada
turned out to be. :-)

bill

[Simon Clubley]

On 2023-04-26, Craig A. Berry <craig...@nospam.mac.com> wrote:
>
> On 4/26/23 5:33 AM, Neil Rieck wrote:
>
>> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
>> only be built with C11 which is still not available on OpenVMS/Alpha
>> or OpenVMS/Itanium
> Not sure that will ever happen. It's hard to see how VSI can afford to
> continue to make major changes to the traditional front end on all
> platforms while also keeping up with clang on x86.
>

They don't need to change those front ends.

If you have existing DEC-specific code, use the DEC front ends that John
is writing.

If you have industry-standard C or C++ code that needs modern compiler
standards, then just call clang directly, instead of via one of the
DEC front ends.

[Craig A. Berry]

On 4/26/23 7:19 AM, Simon Clubley wrote:
> On 2023-04-26, Craig A. Berry <craig...@nospam.mac.com> wrote:
>>
>> On 4/26/23 5:33 AM, Neil Rieck wrote:
>>
>>> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
>>> only be built with C11 which is still not available on OpenVMS/Alpha
>>> or OpenVMS/Itanium
>> Not sure that will ever happen. It's hard to see how VSI can afford to
>> continue to make major changes to the traditional front end on all
>> platforms while also keeping up with clang on x86.
>>
>
> They don't need to change those front ends.
>
> If you have existing DEC-specific code, use the DEC front ends that John
> is writing.
>
> If you have industry-standard C or C++ code that needs modern compiler
> standards, then just call clang directly, instead of via one of the
> DEC front ends.

Which is no help at all for someone who just said, "C11 which is still
not available on OpenVMS/Alpha or OpenVMS/Itanium." Unless someone with
a very large pile of cash wants to revive llvm-alpha and llvm-ia64.

[Simon Clubley]

Yeah, you are right Craig. I missed what you were saying. Sorry.

[Craig A. Berry]

On 4/26/23 12:42 PM, Simon Clubley wrote:
> On 2023-04-26, Craig A. Berry <craig...@nospam.mac.com> wrote:
>>
>> Which is no help at all for someone who just said, "C11 which is still
>> not available on OpenVMS/Alpha or OpenVMS/Itanium." Unless someone with
>> a very large pile of cash wants to revive llvm-alpha and llvm-ia64.
>>
>
> Yeah, you are right Craig. I missed what you were saying. Sorry.

For credit where credit is due, I was quoting Neil Rieck, not myself.

[Arne Vajhøj]

I don't know if VSI has officially stated it, but when I saw
that Alpha and Itanium would not get 9.x, then my conclusion
was that:
- VSI will support Alpha and Itanium to run what is running
on them today - whatever was created 20-30 years ago will
continue to run for many years to come
- anyone wanting major new VMS or VMS LP functionality for
new stuff will need to migrate to x86-64

Arne

[Arne Vajhøj]

On 4/26/2023 6:33 AM, Neil Rieck wrote:
> On Saturday, April 22, 2023 at 6:38:25 AM UTC-4, issinoho wrote:
>> Has there been any talk on this being ported?
>
> As others have already mentioned, both MySQL-5.5 and MariaDB-5.5 are
> no longer supported.

Yep.

> And when they were, I was experiencing database corruptions problems
> at shutdown

On VMS?

> that forced me to move to MariaDB-10 on Linux (our shop
> has been employing heterogeneous computing since 2016; our primary
> businesses systems run OpenVMS but our relational databases were
> being served up on CentOS-7; now Rocky-8)
>
> One of the annoyances with MariaDB-10 (and MySQL-6) is that they can
> only be built with C11 which is still not available on OpenVMS/Alpha
> or OpenVMS/Itanium (that blame goes to all the companies before VSI
> who did not take C/C++ seriously enough to keep the C/C++ ecosystem
> up to date on OpenVMS). (not sure why the authors of MySQL and
> MariaDB did not follow the example set by Apache where HTTPd would
> always be tied to a simpler version of C)
>
> Everyone reading this knows how difficult it is to play catchup
> whenever a company has allowed something to slide for more than a
> decade (IIRC, C99 was the last standard supported by Compaq and I do
> not recall any progress being made when HP was at the helm).
>
> Kudos to VSI for making as much progress as they have. I only hope
> that they get around to also supporting C17 (stable) and C23
> (pre-release)

VMS C has been struggling a bit to get to C99.

But it is my impression that C99 is sort of livable
as few C applications rely on C11 & C17.

I believe the big problem is C++. C++98 is totally
obsolete. A lot of actively maintained C++ applications
require C++11/14 or C++17.

So VMS C++ with its C++98 support is a problem.

And I believe the MySQL/MariaDB issue is in the C++
part not the C part.

Arne

[Arne Vajhøj]

On 4/26/2023 8:19 AM, bill wrote:
> On 4/26/2023 8:14 AM, Simon Clubley wrote:
>> So what did you think about _J_OVIAL ? :-)
>
> Laugh all you want.  The last I heard the USAF is still using
> Jovial.

But still a bit old.

As example:

http://www.seadeo.com/Vax_Compilers.htm

VMS support, but on VAX not that "new" Alpha thing.

:-)

Arne

[Dave Froble]

I do believe that the purpose of starting up VSI was to port VMS to x86 and
beyond. I've got to think that it would not have happened for just Alpha and
itanic. Those are dead, no new chips, no growth potential. Perhaps the Alpha
and itanic support was mainly to keep the customers on VMS until x86 VMS was ready.

The original announced plan did not include Alpha. But enough paying customers
convinced VSI to have an Alpha VMS release. I remember Clair Grant writing
something like "now to see if we can make any money from Alpha", or something
like that.

So, since they planned on a single source for Alpha, itanic, and x86, at least
as much as possible, the support for the dead CPUs also helped x86.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Neil Rieck]

No, but I will.

As I have mentioned before, 99% of all software (applications as well as software development tools) is written in C/C++ so not supporting C/C++ is one way to kill any platform.

p.s. back in the day, the people at the Apache foundation had the foresight to see this problem on the horizon so their first big project, HTTPd, would only be supported on a very early implementation of C. This is one reason why Apache HTTPd can be found in every computer ecosystem. Anyway, developers at Oracle (MySQL-6) and MariaDB Corp (MariaDB-10) were wearing different hats when they decided to use C11. If other open software developers follow this trend then current operating systems not supporting C11, C17 and C23 (and their C++ equivalents) will quickly find their OS classified as museumware.

Neil Rieck
Waterloo, Ontario, Canada.

http://neilrieck.net/OpenVMS.html

[Arne Vajhøj]

On 4/27/2023 6:36 AM, Neil Rieck wrote:
> On Wednesday, April 26, 2023 at 8:04:28 AM UTC-4, Craig A. Berry
> wrote:
>> On 4/26/23 5:33 AM, Neil Rieck wrote:
>>
>>> One of the annoyances with MariaDB-10 (and MySQL-6) is that they
>>> can only be built with C11 which is still not available on
>>> OpenVMS/Alpha or OpenVMS/Itanium
>> Not sure that will ever happen. It's hard to see how VSI can afford
>> to continue to make major changes to the traditional front end on
>> all platforms while also keeping up with clang on x86.
>>> Kudos to VSI for making as much progress as they have. I only
>>> hope that they get around to also supporting C17 (stable) and C23
>>> (pre-release)
>> Have you tried the clang-based C++ compiler currently in field
>> test, which, as a side effect of being clang, works as either a C
>> compiler or a C++ compiler? I suspect that will be the path forward
>> for newer standards.
>
> No, but I will.
>
> As I have mentioned before, 99% of all software (applications as well
> as software development tools) is written in C/C++ so not supporting
> C/C++ is one way to kill any platform.

I don't believe those 99%.

Most surveys of programming languages show:

tier 1 - JavaScript, Python, Java
tier 2 - C/C++, C#, PHP
tier 3 & 4 - all the rest

The only domain I can think of where C/C++ is totally dominant is
OS.

> p.s. back in the day, the people at the Apache foundation had the
> foresight to see this problem on the horizon so their first big
> project, HTTPd, would only be supported on a very early
> implementation of C. This is one reason why Apache HTTPd can be found
> in every computer ecosystem.

I can sympathize with that - I probably code my C in C89.

:-)

> Anyway, developers at Oracle (MySQL-6)
> and MariaDB Corp (MariaDB-10)

MySQL went from 5.7 to 8.0 there is no 6.x.

> were wearing different hats when they
> decided to use C11. If other open software developers follow this
> trend then current operating systems not supporting C11, C17 and C23
> (and their C++ equivalents) will quickly find their OS classified as
> museumware.

I believe the problem is mostly in C++ not C.

C99->C11 is relative small (standard multi-threading, better
unicode support and some other stuff).

C11->C17 is just bugfixes.

A C17 program will very much look like a C99 program.

Obviously a program using some of the new features
in C11 (like the standard threading instead of POSIX
threading) will not build out of the box with C99.

But overall C is C.

Not so with C++.

C++98->C++03 is just bugfixes.

C++03->C++11 is huge: type inference, modern for loop,
different return type declaration, nullptr, enum class,
lambda, attributes, regex support, better unicode support,
standard multi-threading and much more.

C++11->C++14 added a bunch of smaller changes.

C++14->C++17 added a bunch of smaller changes.

C++17->C++20 added more (concepts, modules, coroutines,
spaceship operator, mandate two's complement etc.).

A C++20 program can look totally different from a
C++98 program.

The C++20 program will in some ways look more like a Java
or C# program than a Cnn or C++98 program.

Arne

[Simon Clubley]

On 2023-04-27, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> Most surveys of programming languages show:
>
> tier 1 - JavaScript, Python, Java
> tier 2 - C/C++, C#, PHP
> tier 3 & 4 - all the rest
>

I suspect the splits are different depending on if you are talking
about server-side code or client-side code.

>
> C++17->C++20 added more (concepts, modules, coroutines,
> spaceship operator, mandate two's complement etc.).
>

And in C++20, C++ _finally_ got C's designated initializers:

https://www.cppstories.com/2021/designated-init-cpp20/

They've only been around for decades in the C world... :-)

[Arne Vajhøj]

On 4/28/2023 8:32 AM, Simon Clubley wrote:
> On 2023-04-27, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>
>> Most surveys of programming languages show:
>>
>> tier 1 - JavaScript, Python, Java
>> tier 2 - C/C++, C#, PHP
>> tier 3 & 4 - all the rest
>>
>
> I suspect the splits are different depending on if you are talking
> about server-side code or client-side code.

It is overall.

Server side is not that different. JavaScript would drop a lot
(node.js is becoming "a thing" but is not "the thing"). Java
would be reduced a tiny bit due to Android app code not being
counted. C# and C++ would be reduced a tiny bit too due to Windows
desktop apps and various *nix GUI apps not being counted. But not
a big change.

Client side (as in browser + Android & iOS apps + desktop apps)
would be different. I would say: tier 1 = JavaScript, tier 2 =
Java, Kotlin and Swift, tier 3 = C# and C/C++.

Arne

[Neil Rieck]

Sir, I think you misunderstood my post. All those languages (including Javascript, Python, Java along with COBOL, FORTRAN and BASIC and anything else you can think of) are now implemented in either C or C++ ( https://www.stroustrup.com/applications.html )

Back in the day, all software (both tools and applications) would have been implemented in macro assembler but now everything is implemented in C or C++ then a code generator takes care of the final step; portable software would be virtually impossible if this wasn't the case. This is what Bell Labs had in mind when they were thinking about porting UNIX from an 18-bit PDP-7 to a 16-bit PDP-11 in the early 1970s. This magic trick was quickly repeated on an Interdata Model 70 then VAX-11.

Anyone who has ever worked with Python knows it can be implemented with other languages (including Python) but the CPYTHON virtual machine is the most popular and it is implemented in C.

But it looks like Python has followed the example set by the developers of MySQL-6 and MariaDB-10 in that Python-3.11 can only be built using a C11 compiler. Python-3.6 became unsupported at the end of 2021 ( https://devguide.python.org/versions/ ) so the clock is ticking toward another future choke point.

Now many people do not use Python-3 or MariaDB-10, but I use both everyday. And although I'm a fan of OpenVMS (while my employer remains agnostic), a decision by VSI to not support C11 would force a negative decision many like me.

comment: I am currently attending a Udemy course on "machine learning". It appears that Python-3 is the only game in town for work in this area (TensorFlow, scikit-learn, and PyTorch are just three of many python add-on libraries).

[Arne Vajhøj]

On 4/29/2023 7:47 AM, Neil Rieck wrote:
> On Thursday, April 27, 2023 at 7:48:03 PM UTC-4, Arne Vajhøj wrote:
>> On 4/27/2023 6:36 AM, Neil Rieck wrote:
>>> As I have mentioned before, 99% of all software (applications as
>>> well as software development tools) is written in C/C++ so not
>>> supporting C/C++ is one way to kill any platform.
>> I don't believe those 99%.
>>
>> Most surveys of programming languages show:
>>
>> tier 1 - JavaScript, Python, Java tier 2 - C/C++, C#, PHP tier 3 &
>> 4 - all the rest

> Sir, I think you misunderstood my post.

I misunderstand things all the time.

:-)

> All those languages
> (including Javascript, Python, Java along with COBOL, FORTRAN and
> BASIC and anything else you can think of) are now implemented in
> either C or C++ ( https://www.stroustrup.com/applications.html )
>
> Back in the day, all software (both tools and applications) would
> have been implemented in macro assembler but now everything is
> implemented in C or C++ then a code generator takes care of the final
> step; portable software would be virtually impossible if this wasn't
> the case. This is what Bell Labs had in mind when they were thinking
> about porting UNIX from an 18-bit PDP-7 to a 16-bit PDP-11 in the
> early 1970s. This magic trick was quickly repeated on an Interdata
> Model 70 then VAX-11.

C and C++ are widely used on in the infrastructure of other languages.

The compilers themselves can easily be written in another language
and sometimes do so.

But the RTL is different. If one need to write a RTL that interfaces
the OS and want to support many OS'es, then the list of possible
languages becomes pretty short. And C and C++ are at the top of the
list.

> Anyone who has ever worked with Python knows it can be implemented
> with other languages (including Python) but the CPYTHON virtual
> machine is the most popular and it is implemented in C.

I don't think there are any implementation without a C dependency at
the lower level.

Jython & GraalPython run in JVM, IronPython run in CLR and PyPy
is written in (Restricted) Python, but both JVM and CLR has
an interface to the OS written in C or C++ somewhere at the
lowest level. And I am pretty sure that it is the same for PyPy.

> But it looks like Python has followed the example set by the
> developers of MySQL-6 and MariaDB-10 in that Python-3.11 can only be
> built using a C11 compiler.

I did not know, but not so surprising. At some point projects
move on. Python had to choose between C99 that is now 24 years
old and C11 that is 12 years old and decided and now they
made the jump. It is not exactly chasing latest and greatest.

> Now many people do not use Python-3 or MariaDB-10, but I use both
> everyday. And although I'm a fan of OpenVMS (while my employer
> remains agnostic), a decision by VSI to not support C11 would force a
> negative decision many like me.

C11 on VMS x86-64 should not be a problem with clang.

But it seems unlikely that VSI will invest in going to C11
on Alpha and Itanium.

> comment: I am currently attending a Udemy course on "machine
> learning". It appears that Python-3 is the only game in town for work
> in this area (TensorFlow, scikit-learn, and PyTorch are just three of
> many python add-on libraries).

Python is a very important language today.

Arne

[Neil Rieck]

I'm glad you added that clarification.
I think Alpha is totally off the table but I think a case could be made for providing modern compiler support to OpenVMS on Itanium.
This would enable people like Mark Berryman, Brett Cameron and others to more easily port open software products to the OpenVMS ecosystem.
This is a must on x86-64 since open source software appears to be ever more important today than it ever was.

Back to python for a moment. I've got a lot of production stuff running under python-3.6 (which is no longer supported) so we are preparing to move to python-3.9
Not sure about OpenVMS systems but Linux systems allow you to support multiple python environments simultaneously via the shebang mechanism.
Anyway, I've been playing a lot with python-3.9 lately an have noticed that many modern python libraries are installed via something called the whl mechanism. Watching this happen is like watching a professional magician: c or c++ source code is downloaded, then compiled + linked (provided you have installed development tools like gcc).

[Arne Vajhøj]

On 4/30/2023 8:48 AM, Neil Rieck wrote:
> On Saturday, April 29, 2023 at 8:57:50 AM UTC-4, Arne Vajhøj wrote:
>> On 4/29/2023 7:47 AM, Neil Rieck wrote:
>>> Now many people do not use Python-3 or MariaDB-10, but I use
>>> both everyday. And although I'm a fan of OpenVMS (while my
>>> employer remains agnostic), a decision by VSI to not support C11
>>> would force a negative decision many like me.
>> C11 on VMS x86-64 should not be a problem with clang.
>>
>> But it seems unlikely that VSI will invest in going to C11 on Alpha
>> and Itanium.
>>> comment: I am currently attending a Udemy course on "machine
>>> learning". It appears that Python-3 is the only game in town for
>>> work in this area (TensorFlow, scikit-learn, and PyTorch are just
>>> three of many python add-on libraries).
>> Python is a very important language today.
>

> I'm glad you added that clarification. I think Alpha is totally off
> the table but I think a case could be made for providing modern
> compiler support to OpenVMS on Itanium. This would enable people like
> Mark Berryman, Brett Cameron and others to more easily port open
> software products to the OpenVMS ecosystem. This is a must on x86-64
> since open source software appears to be ever more important today
> than it ever was.

VSI decision.

I doubt that it will happen.

> Back to python for a moment. I've got a lot of production stuff
> running under python-3.6 (which is no longer supported) so we are
> preparing to move to python-3.9 Not sure about OpenVMS systems but
> Linux systems allow you to support multiple python environments
> simultaneously via the shebang mechanism. Anyway, I've been playing a
> lot with python-3.9 lately an have noticed that many modern python
> libraries are installed via something called the whl mechanism.
> Watching this happen is like watching a professional magician: c or
> c++ source code is downloaded, then compiled + linked (provided you
> have installed development tools like gcc).

You got 3.10 on Itanium.

https://vmssoftware.com/products/python/

and it also list a wheels kit. I don't know if it
compiles or come pre-built.

Arne

[Jan-Erik Söderholm]

Den 2023-04-30 kl. 14:48, skrev Neil Rieck:

> something called the whl mechanism.

That is "Pyhton Wheels", right?

https://pypi.org/project/wheel/

[Neil Rieck]

To be honest, I am not sure. Sometimes change happens so quickly that when I see something happen I do not always investigate. One can only stand back and say "now that is interesting!"

Neil

[Craig A. Berry]

On 4/25/23 10:33 AM, Mark Berryman wrote:
> On 4/24/23 4:12 PM, Craig A. Berry wrote:

>>
>> On 4/22/23 5:38 AM, issinoho wrote:
>>> Has there been any talk on this being ported?
>>

>> The C++ compiler that will be necessary to make it even theoretically
>> possible is still in field test and only became available quite
>> recently.  One can hope, but we won't really know until someone does the
>> work.
>
> When the field test C++ compiler became available I attempted to build
> my MariaDB v5.5 kit.  It was a no go for a few reasons.
>
> One,
> The field test is still limited in some functionality.  For example,
> there are some pragmas that are not yet supported or not yet fully
> supported.  The include_directory pragma does not yet appear to work and
> my build procedure depends heavily on this.

Version 230512, released today, says support for this pragma has now
been added.

> Two,
> There are a number of places in the port that assume that long and
> size_t are 32 bits.  For x86_64, they are 64 bits.  Addressing this
> would almost mean redoing the port. (I think long is a bigger issue than
> size_t).
>
> Three,
> In order for the headers included with the compiler to compile
> correctly, certain values must be defined.  For example, in order to use
> string.h, either __CORRECT_ISO_CPP_STRING_H_PROTO or
> _STRING_H_CPLUSPLUS_98_CONFORMANCE_ must be defined.  Otherwise, the
> compiler throws errors and aborts.  I did not see anything about this in
> the documentation and stumbled across it when trying to figure out why
> the errors were occurring.  Now I wonder if there are others.
>
> I think MariaDB, either V5 for V10, will have to wait until the C++
> compiler is more complete.

It's hard to say whether it's there yet, but from the number of changes
it's certainly moving along. From the changelog it looks like they've
been doing internal releases every couple of weeks but I think it's been
a couple of months since the last external release.