adesutherland
Compiler version C11 or C99
Some errors of https://github.com/adesutherland/CREXX/issues/417 are related to using an older compiler version that does not support defining loop variables directly within the loop. By looking at the related CMAKE files, I find always:
cmake_minimum_required(VERSION 3.24)
project(system_plugin C)
set(CMAKE_C_STANDARD 90)
I’m a bit confused because the error messages suggest the need for C11 or C99 support. However, it seems that the CMake files were not updated in your latest commit. Am I misunderstanding something?
"Got it! It’s clear now that the CMake standard can be set differently in each CMake file. Could it be that there’s a platform-specific difference between Windows and Linux? The original Git version seems to consistently use C90, whereas Windows appears to require C99. I made the necessary changes where the errors occurred. I also changed u_int64.. to uint64 and u_int32 to uint32. Please let me know if I should commit the files with a #ifdef _WIN32 switch.
I made changes in the following files:
Index: interpreter/rxvmplugin/rxvmplugins/db_decimal/CMakeLists.txt:
- set(CMAKE_C_STANDARD 99) Index: interpreter/rxvmplugin/rxvmplugins/mc_decimal/CMakeLists.txt
- set(CMAKE_C_STANDARD 99)
Index: interpreter/rxvmplugin/CMakeLists.txt
- set(CMAKE_C_STANDARD 99)
Index: interpreter/rxvmplugin/rxvmplugins/db_decimal/db_decimal.c
- u_int64_t uvalue = 0;
- uint64_t uvalue = 0;
Index: interpreter/rxvmplugin/rxvmplugins/mc_decimal/decnumber_test.c
old: static int do_decNumberFromUInt64_test(char* test, u_int64_t value) { new static int do_decNumberFromUInt64_test(char* test, uint64_t value) {
old: static int do_decNumberToUInt64_test(char* test, u_int64_t value) { new: static int do_decNumberToUInt64_test(char* test, uint64_t value) {
old: u_int64_t result = decNumberToUInt64(dn, context); new: uint64_t result = decNumberToUInt64(dn, context);
old: u_int64_t result = decNumberToUInt64(dn, context); new uint64_t result = decNumberToUInt64(dn, context);
old: static int do_decNumberToUInt32_test(char* test, u_int32_t value) { new: static int do_decNumberToUInt32_test(char* test, uint32_t value) {
old: u_int32_t result = decNumberToUInt32(dn, context); new: uint32_t result = decNumberToUInt32(dn, context);
old: u_int32_t result = decNumberToUInt32(dn, context); new: uint32_t result = decNumberToUInt32(dn, context);
Apologies - my last push has broken the build. I am not sure how to do it but I suggest you try and go back to the previous commit. I will fix across platforms tonight (I hope!)
The person who makes no mistakes is the person who does nothing—Theodore Roosevelt
Everything is up and running, and I’ve learned something new—what more could you ask for? And that, of course, means there was absolutely no need to return to the previous commit after all.
Somehow I am missing my /bin/crexx.rexx compiler driver. I see the /bin directory now is a receptacle for the binaries (which is good) so I will add the crexx executable to it, but build the source from another directory in the source tree, like is done for rxdb.
Update: those are not binaries in /bin, but scripts. crexx compile traps. I'll check it in as it does not seem to hinder the rest of the build.
Whoa - it seems that this merge set back f0049 to a point into the past. we.rexx is an older version and the rxfnsb and rxfnsc split is gone.
Not good :-( However I see levelc and c in the libs - it may just be some cmakefiles I had to manually merge?
Somehow I am missing my /bin/crexx.rexx compiler driver. I see the /bin directory now is a receptacle for the binaries (which is good) so I will add the crexx executable to it, but build the source from another directory in the source tree, like is done for rxdb.
I am seeing /bin/crexx.rexx on my machine and on the github browser for f0049 - so I am hoping it is something that has gone wrong on your machine somehow? What do yo think?
No, there were source directories for rxfnsb and c, and changes from Peter and me. Also, there was a crexx.rexx in the bin directory - for a long time already.
best regards,
René.
On 7 Jan 2025, at 14:50, Adrian Sutherland @.***> wrote:
Not good :-( However I see levelc and c in the libs - it may just be some cmakefiles I had to manually merge?
— Reply to this email directly, view it on GitHub https://github.com/adesutherland/CREXX/issues/418#issuecomment-2575341565, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3WJQIBAHIVLTXBMLELNAD2JPLQ5AVCNFSM6AAAAABUXDBJPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZVGM2DCNJWGU. You are receiving this because you commented.
no, that is crxc.rexx - its granddaddy.
best regards,
René
On 7 Jan 2025, at 16:25, Adrian Sutherland @.***> wrote:
Somehow I am missing my /bin/crexx.rexx compiler driver. I see the /bin directory now is a receptacle for the binaries (which is good) so I will add the crexx executable to it, but build the source from another directory in the source tree, like is done for rxdb.
I am seeing /bin/crexx.rexx on my machine and on the github browser for f0049 - so I am hoping it is something that has gone wrong on your machine somehow? What do yo think?
— Reply to this email directly, view it on GitHub https://github.com/adesutherland/CREXX/issues/418#issuecomment-2575569966, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3WJQJ6TMDSO7XL6MU46IL2JPWWFAVCNFSM6AAAAABUXDBJPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZVGU3DSOJWGY. You are receiving this because you commented.
In both the latest commit and the one before, in have (in bin/crexx) - CmakeLists.txt, boot.sh, ccomp, crexx.rexx, crxc.rexx
I will have a look. Error might be on my side.René.On 7 Jan 2025, at 18:11, Adrian Sutherland @.***> wrote: rxfnsb and c are there
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
Mea maxima culpa. Apologies for the panic.
I know what happened. I pulled f0049, and it did not build. Then - I cloned the repo anew, to a crexx-f0049 directory - and got a phonecall.
At that point I intended to do a git checkout feature/f0049 - but I did not. Then, this stopped working one after the other and I should have looked better.
Again, my sincere apologies for any inconvenience caused.
best regards,
René.
On 7 Jan 2025, at 18:11, Adrian Sutherland @.***> wrote:
rxfnsb and c are there
— Reply to this email directly, view it on GitHub https://github.com/adesutherland/CREXX/issues/418#issuecomment-2575823800, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3WJQNVV4J7VBXHJC6LO2D2JQDD5AVCNFSM6AAAAABUXDBJPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZVHAZDGOBQGA. You are receiving this because you commented.
Hey - no drama! Panic over, and as you keep telling me, we would have been able to recover anything anyway :-)
Meantime, I am fixing the build - the first commit will be an ubuntu fix, the second windows.
After applying today's commit, none of my plugins are working anymore. The errors are strange:
/* Matrix Plugin Test */
options levelb
import rxfnsb
import matrix
exit
...
Error in matrix_test.rexx @ 5:1 - #FUNCTION_NOT_FOUND Error in matrix_test.rexx @ 5:1 - #UNEXPECTED_ARGUMENT, 1
if also refuses to recognise standard functions as:
say copies('-',72)
say 'Factor Analysis'
say copies('-',72)
Error in matrix_test.rexx @ 67:12 - #UNEXPECTED_ARGUMENT, 1, "'-'" Error in matrix_test.rexx @ 67:5 - #FUNCTION_NOT_FOUND, "copies('-',72)"
Lately, import rxfnsb has been sufficient to address them.
It is so weird! I pulled a completely new version from GIT, and all the errors disappeared (except u_int64 stuff)! I've decided to change careers and become a gardener!
There is something not quite right with the cmake build - well this is my hypothesis - I intend to go through all the dependencies carefully
Hi Peter,
well, don't do that yet!
I did a new yesterday and you know what happened.
I have two new explanations: (true, honestly!)
- I had the wrong glasses on (there was something happening outside) and this morning I found a web tab on feature/f0046 open (and not 49!), which made for further surprise
- I tested in my "test" directory (in itself not surprising) but then I was hit by a new occurence of https://github.com/adesutherland/CREXX/issues/329 and the compiler segfaulted a lot. So I was quite unhappy for some time.
The last thing is an error we must fix or explain to users, or maybe fix by having the compiler explain to users when a stale rxbin or other junk hampers it.
best regards,
René.
On 8 Jan 2025, at 10:23, Peter-Jacob @.***> wrote:
It is so weird! I pulled a completely new version from GIT, and all the errors disappeared (except u_int64 stuff)! I've decided to change careers and become a gardener!
— Reply to this email directly, view it on GitHub https://github.com/adesutherland/CREXX/issues/418#issuecomment-2577186422, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3WJQINQPEUCNXREHRS6UD2JTVCLAVCNFSM6AAAAABUXDBJPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZXGE4DMNBSGI. You are receiving this because you commented.
I have a sneaking suspicion: if that turns out to be true, Crexx isn’t the problem—it’s the genius typing this right now. After applying Adrian's updates, I noticed a CMake file for my matrix plugin was missing. Being as lazy as I am, I copied an older version from yesterday's corrupted project, checked for any hardcoded references, and loaded it. So for now: bushes and flowers, you’re safe from me!
I think F0046 and F0049 look the same - in the dark and for tired eyes, I always complain in restaurants - small fonts in romantic lighting :-)
On the stale rxbin problem - I think we could at least make the compiler complain if it finds two rxbin files exposing the same functions.
A
On Wed, 8 Jan 2025 at 12:42, René Vincent Jansen @.***> wrote:
Hi Peter,
well, don't do that yet!
I did a new yesterday and you know what happened.
I have two new explanations: (true, honestly!)
- I had the wrong glasses on (there was something happening outside) and this morning I found a web tab on feature/f0046 open (and not 49!), which made for further surprise
- I tested in my "test" directory (in itself not surprising) but then I was hit by a new occurence of https://github.com/adesutherland/CREXX/issues/329 and the compiler segfaulted a lot. So I was quite unhappy for some time.
The last thing is an error we must fix or explain to users, or maybe fix by having the compiler explain to users when a stale rxbin or other junk hampers it.
best regards,
René.
On 8 Jan 2025, at 10:23, Peter-Jacob @.***> wrote:
It is so weird! I pulled a completely new version from GIT, and all the errors disappeared (except u_int64 stuff)! I've decided to change careers and become a gardener!
— Reply to this email directly, view it on GitHub < https://github.com/adesutherland/CREXX/issues/418#issuecomment-2577186422>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AC3WJQINQPEUCNXREHRS6UD2JTVCLAVCNFSM6AAAAABUXDBJPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZXGE4DMNBSGI>.
You are receiving this because you commented.
— Reply to this email directly, view it on GitHub https://github.com/adesutherland/CREXX/issues/418#issuecomment-2577582577, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBKI6WB4TCGBYNWRGU3PNT2JUMMBAVCNFSM6AAAAABUXDBJPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZXGU4DENJXG4 . You are receiving this because you were assigned.Message ID: @.***>