4 added 2 characters in body
source | link

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate instead.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.

The documentation only talks about WSEvaluate (for wstp.h). Three places have three inconsistent things.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate, which is consistent with the documentation.


My personal opinion on this still hasn't changed:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones. J/Link and .NET/Link did not change the MathLink naming in their API, and their C basis still uses ML-prefixed functions. Changing all this would be a pointless waste of time so I assume Wolfram won't do it, even if they say that ML deprecated.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but I look at what they do, not what they say.

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate instead.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.

The documentation only talks about WSEvaluate (for wstp.h). Three places have three inconsistent things.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate, which is consistent with the documentation.


My personal opinion on this still hasn't changed:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones. J/Link and .NET/Link did not change the MathLink naming in their API, and their C basis still uses ML-prefixed functions. Changing all this would be a pointless waste of time so I assume Wolfram won't do it, even if they say that ML deprecated.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but look at what they do, not what they say.

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate instead.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.

The documentation only talks about WSEvaluate (for wstp.h). Three places have three inconsistent things.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate, which is consistent with the documentation.


My personal opinion on this still hasn't changed:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones. J/Link and .NET/Link did not change the MathLink naming in their API, and their C basis still uses ML-prefixed functions. Changing all this would be a pointless waste of time so I assume Wolfram won't do it, even if they say that ML deprecated.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but I look at what they do, not what they say.

3 added 92 characters in body
source | link

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate instead.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.

The documentation only talks about WSEvaluate (for wstp.h). Three places have three inconsistent things.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate, which is consistent with the documentation.


My personal opinion is what it has always beenon this still hasn't changed:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one.If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones. J/Link and .NET/Link did not change the MathLink naming in their API, and their C basis still uses ML-prefixed functions. Changing all this would be a pointless waste of time so I assume Wolfram won't do it, even if they say that ML deprecated.

Why would you choose the WSWS ones then? I understand that Wolfram tells you that the MLML ones are deprecated, but look at what they do, not what they say.

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate.


My personal opinion is what it has always been:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but look at what they do, not what they say.

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate instead.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.

The documentation only talks about WSEvaluate (for wstp.h). Three places have three inconsistent things.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate, which is consistent with the documentation.


My personal opinion on this still hasn't changed:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones. J/Link and .NET/Link did not change the MathLink naming in their API, and their C basis still uses ML-prefixed functions. Changing all this would be a pointless waste of time so I assume Wolfram won't do it, even if they say that ML deprecated.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but look at what they do, not what they say.

2 added 92 characters in body
source | link

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate.


My personal opinion is what it has always been:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but look at what they do, not what they say.

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.


My personal opinion is what it has always been:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but look at what they do, not what they say.

I did not have the time to construct a complete solution for you, but I looked at wstp.h and at the output of wsprep. Here's what I found:

wstp.h has no WSEvaluate declared. It has MLEvaluate.

wsprep is supposed to output the definition of WSEvaluate (while wstp.h is supposed to have the declaration). But wsprep outputs neither WSEvaluate nor MLEvaluate. It outputs PREPEvaluate, which looks like a bug to me. I'd try #define WSEvaluate PREPEvaluate and add a declaration manually, but I'd expect this workaround to break with the next Mathematica release.


In comparison, mathlink.h and mprep are as expected: both have MLEvaluate.


My personal opinion is what it has always been:

MathLink was renamed to WSTP purely for marketing reasons. This move brought exactly zero technical benefits. However, it did create bugs, it did create additional work for developers (= a waste of time), and it did lead to many inconsistencies between the documentation and the actual state of things, as the ML->WS renaming seems to have been done separately in the actual code and in the documentation.

If you want to save yourself trouble, use the ML-prefix API, not the WS-prefix one. This has been in use for more than 25 years and is well tested. There is evidence that this, and not the WS-named equivalent, is being used internally (e.g. see the symbols in the kernel executable). LibraryLink only works with the ML-functions, not the WS ones.

Why would you choose the WS ones then? I understand that Wolfram tells you that the ML ones are deprecated, but look at what they do, not what they say.

1
source | link