Failure in Linux and Windows build in GitHub Actions

[trenta3]

I'm trying to build Ren-C on GitHub actions to have automated builds always available. The MacOS build is succeeding, while Linux and Windows builds are failing for unknown reasons (to me). I've tried issuing the same commands locally (I have a Linux machine) and Ren-C builds successfully.

The link to the logs of the various builds with relative errors is: https://github.com/trenta3/ren-c-nightly/actions/runs/1236971482

Windows error:

** Syntax Error: invalid "lit" -- ""
** Where: transcode if load if catch import do catch either else _ do
** Near: (line 152) exe-suffix: '
** File: tmp-boot.r
** Line: 5280

Linux error:

Running: rm -fr objs/
** Error: No such file or directory
** Where: call for-each either switch run-target switch run for-each switch run switch for-each do catch either else _ do
** Near: [... ["Running:" cmd]
    call/shell cmd ~~]
** Line: 367

Maybe someone with more experience in the codebase can help diagnose the issues and propose solutions.

[giuliolunati]

[OT] Ciao Dario, sei italiano?

In tal caso mi fa piacere sapere che c'è qualcun'altro della mia lingua interessato a Rebol/Ren-C. Mi permetto di lasciarti il mio indirizzo:

giuliolunati AT gmail DOT com

Giulio Lunati

Il mer 15 set 2021, 13:12 Dario Balboni @.***> ha scritto:

I'm trying to build Ren-C on GitHub actions to have automated builds always available. The MacOS build is succeeding, while Linux and Windows builds are failing for unknown reasons (to me). I've tried issuing the same commands locally (I have a Linux machine) and Ren-C builds successfully.

The link to the logs of the various builds with relative errors is: https://github.com/trenta3/ren-c-nightly/actions/runs/1236971482

Windows error:

Syntax Error: invalid "lit" -- "" Where: transcode if load if catch import do catch either else _ do Near: (line 152) exe-suffix: ' File: tmp-boot.r ** Line: 5280

Linux error:

Running: rm -fr objs/ Error: No such file or directory Where: call for-each either switch run-target switch run for-each switch run switch for-each do catch either else _ do Near: [... ["Running:" cmd] call/shell cmd ~~] Line: 367

Maybe someone with more experience in the codebase can help diagnose the issues and propose solutions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/metaeducation/ren-c/issues/1133, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLC4M4FRQUZYLBYCXNLML3UCB5R5ANCNFSM5ECGFJZA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[hostilefork]

Good to see you are industrious and handy with a shell, @trenta3 ! Though please keep any binaries you make somewhat secret...

The Linux error is because GitHub Actions does not set SHELL in the environment of invoked processes (for some reason). So when you do CALL/SHELL it doesn't know what to call. You can set it:

  - name: Set Shell
    if: ${{ runner.os == 'Linux' }}
    run: |
      echo "SHELL=/bin/bash" >> $GITHUB_ENV  # pass to next step

That (first) Windows error is because of CR / LF auto translation in Git. The bootstrap executable doesn't give good errors regarding this, newer ones do. You need to turn that off before the checkout step:

  - name: Disable LF to CRLF Auto Translation In Git
    run: |
      git config --global core.autocrlf false
      git config --global core.eol lf

There's another error after that, let me know if you get stuck on it.

[hostilefork]

I'll point out that GitHub Actions defines SHELL if you just ECHO it in the run steps. It just doesn't pass it on to invoked processes.

Newer Ren-C has a workaround:

https://github.com/metaeducation/ren-c/blob/ad5ef95b5f4f76c093000873df7fb7fcc4dfb595/extensions/process/call-posix.c#L238-L248

This also shows a couple of Ren-C-isms at once. One is the COMMA! value, which I'm fond of... it evaluates to nothing, and has no effect unless it's put in a place it shouldn't be:

>> second [a, b]
== ,

>> x: 1 + 2,
== 3

>> x: 1, + 2
** Script Error: + is missing its value1 argument

The other is that the C API rebSpell() is permitting the extraction of UTF-8 data from the result of the ANY.

[hostilefork]

Since you have a successful Linux build, I'll definitely advise you to engage for some bit of conversation about what it is you've built, and how to use such a thing that has no manual.

It would help to know how much Rebol you already know. Giulio has offered to correspond in Italian, but if you can understand spoken English, I can give a bit of a tour on a web screen-sharing session or such...to try and point things out that would be relevant to your interests.

[trenta3]

Good to see you are industrious and handy with a shell, @trenta3 ! Though please keep any binaries you make somewhat secret...

@hostilefork Why should I keep binaries secret? I think having binaries readily available can help the community grow and can also help current developers to develop their program to all platforms. Also what do you mean by "somewhat secret"? Is not advertising the repo enough or should I make it private?

There's another error after that, let me know if you get stuck on it.

Indeed I got stuck on some header files not being found. I would be grateful if you could provide me how to also completely build a Windows executable, since I'm interested in REBOL and derivatives also because they promise to be easily deployable on a multitude of platforms.

Since you have a successful Linux build, I'll definitely advise you to engage for some bit of conversation about what it is you've built, and how to use such a thing that has no manual.

I already read a couple of book/manuals on REBOL and I think I have a fairly good understanding of r2 in terms of function application and how bindings work, that allows me to read code written in it. I have written only small example programs just to challenge my understanding, but I've not come farther because I realized that all implementations of a REBOL-like language (r2, Red, Ren-C, Arturo, etc.) are missing certain features that are fundamental for me such as: good stack traces, concurrency and/or parallelism features, a GUI, a file unambiguously explaining evaluation semantic, a fairly understandable code base. Good extras are the ability to JIT compile a certain portion of load-heavy code, the ability for the user to extend defined types, as well as overloaded functions and operators.

It would be good to know what is the take of Ren-C in these areas, and how mature they are.

Giulio has offered to correspond in Italian, but if you can understand spoken English, I can give a bit of a tour on a web screen-sharing session or such...to try and point things out that would be relevant to your interests.

I would very much appreciate this, but let me add that I will probably end up developing a base kind of rebol on my own since the sources of this project seem likely unmaintainable and hard to understand (https://trello.com/c/27zkBP58/90-modify-with-confidence). Thus my interests concentrate on the language implementation and peculiar features. I will try to come up with a list of what I would be interested in knowing so that we can talk about it. In exchange for a tour of the language, I can offer to produce useful documentation about the internals of the implementation or the code structure itself that could be helpful for someone else that wants to contribute to the project.

[hostilefork]

What has drawn people to Rebol historically has varied. But a large number who praised it and used it were less interested in the language itself, rather the properties of the executable. It was small, and you could run on any OS without installing anything else...it came with a GUI built in.

But when serious language theorists look at Rebol, they notice it is riddled with design holes. The language itself wasn't composable the way one might like languages to be: mixing constructs in new ways that weren't specifically accounted for never worked. It was more like a "scriptable app" that had a few features that pleased its userbase...and had to be extended by the designer every time a new need came up.

So put briefly: If you don't understand what these holes are, then you won't appreciate the many issues that Ren-C is trying to solve. Starting from scratch inevitably makes the same mistakes.

Once you know that historical Rebol was fundamentally broken, there are basically 3 choices:

1. Inventory and address the holes one at a time and try to fix or mitigate them
2. Ignore the holes and just hope that if you add enough features and integration no one will notice
3. Turn away and run from the crackpots using it, and work with a more solidly designed language

(1) is Ren-C's hard-chosen path. Energy is spent on identifying certain patterns in source that users must be able to write and have work, if the language is to justify its existence at all. While it would be nice if stack traces were beautiful and if building the sources was 100% easy, all of that would be meaningless if the punch line was "oh, and the language this is all supporting doesn't actually work"

(2) is chosen by people like Red and Oldes's branch of R3-Alpha, as well as some clones that have popped up over the years.

(3) is probably the most sensible choice, but if I didn't think there was some promise in the language I wouldn't be pursuing (1).

---

Regardless, given that I've worked on this for many years now, it would be good to hear me out about what the language actually is. (My opinion isn't the only one...but it's the most informed one!) I can bring up Rebol2/R3-Alpha/Red and show you weak points and where Ren-C beats them, and why I think that's important.

Your conclusion may be to avoid this language family entirely. And that would be reasonable. But I also have some demonstration of what I think the "good parts" are, so maybe you'd be inspired by those.

[hostilefork]

Indeed I got stuck on some header files not being found.

Looking at the logs it appears your r3 does not have an .exe extension. Windows won't run things unless they end in .exe:

https://github.com/trenta3/ren-c-nightly/runs/3629793034?check_suite_focus=true#step:9:11

The build process has some glitches of not giving an error code sometime on aggregate operations where the last operation succeeds, so if things are failing you have to look at "successful" steps sometimes.

[hostilefork]

I will try to come up with a list of what I would be interested in knowing so that we can talk about it.

Definitely do post an introduction on the forum. I can give you pointers to what I consider to be important background reading for whatever you are looking at.

I'd certainly advise surveying the state of binding before digging too far into any Rebol.

https://forum.rebol.info/t/binding-re-examined-from-first-principles/1515

You mention multithreading a lot, and Ren-C's plan is to migrate to stackless processing. So "green threading" will likely be the model used. Stackless is important for other reasons:

https://forum.rebol.info/t/switching-to-stackless-why-this-why-now/1247

(Historical Rebol/Red are basically the same as CPython--interpreter recursions recurse the CPU stack--and that's not forward-looking. So switching to stackless is another one of those big things that Ren-C is trying to do. Each big battle like this just takes time.)

---

Quick sidenote about the builds you're doing: They are not -DNDEBUG: ... (D)efine (N)o (DEBUG)ging

NDEBUG is a C-ism:

https://stackoverflow.com/questions/9229978/why-ndebug-instead-of-release

It's good that you're building with asserts - Please always run instrumented executables at this phase of development for experimentation and testing. I'm just pointing out that in addition to including a lot of stuff, these have a bunch of asserts and such built in which makes the executables fatter and slower. FYI.

[gchiu]

@hostilefork https://github.com/hostilefork Why should I keep binaries secret? I think having binaries readily available can help the community grow and can also help current developers to develop their program to all platforms. Also what do you mean by "somewhat secret"? Is not advertising the repo enough or should I make it private?

All our builds are automatically uploaded to Amazon S3 We used to have tools to download those automatically but they have fallen into disrepair.

On Fri, 17 Sept 2021 at 20:39, Dario Balboni @.***> wrote:

Good to see you are industrious and handy with a shell, @trenta3 https://github.com/trenta3 ! Though please keep any binaries you make somewhat secret...

@hostilefork https://github.com/hostilefork Why should I keep binaries secret? I think having binaries readily available can help the community grow and can also help current developers to develop their program to all platforms. Also what do you mean by "somewhat secret"? Is not advertising the repo enough or should I make it private?

There's another error after that, let me know if you get stuck on it.

Indeed I got stuck on some header files not being found. I would be grateful if you could provide me how to also completely build a Windows executable, since I'm interested in REBOL and derivatives also because they promise to be easily deployable on a multitude of platforms.

Since you have a successful Linux build https://github.com/trenta3/ren-c-nightly/runs/3613483011?check_suite_focus=true#step:10:14, I'll definitely advise you to engage for some bit of conversation about what it is you've built, and how to use such a thing that has no manual.

I already read a couple of book/manuals on REBOL and I think I have a fairly good understanding of r2 in terms of function application and how bindings work, that allows me to read code written in it. I have written only small example programs just to challenge my understanding, but I've not come farther because I realized that all implementations of a REBOL-like language (r2, Red, Ren-C, Arturo, etc.) are missing certain features that are fundamental for me such as: good stack traces, concurrency and/or parallelism features, a GUI, a file unambiguously explaining evaluation semantic, a fairly understandable code base. Good extras are the ability to JIT compile a certain portion of load-heavy code, the ability for the user to extend defined types, as well as overloaded functions and operators.

It would be good to know what is the take of Ren-C in these areas, and how mature they are.

Giulio has offered to correspond in Italian, but if you can understand spoken English, I can give a bit of a tour on a web screen-sharing session or such...to try and point things out that would be relevant to your interests.

I would very much appreciate this, but let me add that I will probably end up developing a base kind of rebol on my own since the sources of this project seem likely unmaintainable and hard to understand ( https://trello.com/c/27zkBP58/90-modify-with-confidence). Thus my interests concentrate on the language implementation and peculiar features. I will try to come up with a list of what I would be interested in knowing so that we can talk about it. In exchange for a tour of the language, I can offer to produce useful documentation about the internals of the implementation or the code structure itself that could be helpful for someone else that wants to contribute to the project.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/metaeducation/ren-c/issues/1133#issuecomment-921616838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABR4QQDDTOPB3KXEAC7OJ3UCL5CZANCNFSM5ECGFJZA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Graham Chiu

[trenta3]

All our builds are automatically uploaded to Amazon S3 We used to have tools to download those automatically but they have fallen into disrepair.

@gchiu Where can I find those builds? I've not seen them publicized!

What has drawn people to Rebol historically has varied. But a large number who praised it and used it were less interested in the language itself, rather the properties of the executable. It was small, and you could run on any OS without installing anything else...it came with a GUI built in.

I must say that I too got attracted to it by the small executable and the built-in GUI, but also by the fact that it is easy to create DSL for specific purposes, that actually makes the language able to evolve to cover the need to write terse (and more understandable) code for all the various tasks.

Energy is spent on identifying certain patterns in source that users must be able to write and have work, if the language is to justify its existence at all. While it would be nice if stack traces were beautiful and if building the sources was 100% easy, all of that would be meaningless if the punch line was "oh, and the language this is all supporting doesn't actually work"

@hostilefork Thanks for this explanation, that actually made me curious about what those holes are, and how Ren-C is trying to solve them.

Regardless, given that I've worked on this for many years now, it would be good to hear me out about what the language actually is. (My opinion isn't the only one...but it's the most informed one!) I can bring up Rebol2/R3-Alpha/Red and show you weak points and where Ren-C beats them, and why I think that's important.

Your conclusion may be to avoid this language family entirely. And that would be reasonable. But I also have some demonstration of what I think the "good parts" are, so maybe you'd be inspired by those.

I would definitely like to hear you out about that.

It's good that you're building with asserts - Please always run instrumented executables at this phase of development for experimentation and testing. I'm just pointing out that in addition to including a lot of stuff, these have a bunch of asserts and such built in which makes the executables fatter and slower. FYI.

Thanks!

Definitely do post an introduction on the forum. I can give you pointers to what I consider to be important background reading for whatever you are looking at.

I'd certainly advise surveying the state of binding before digging too far into any Rebol.

I will read those sources and then post on the forum when I know the questions I would like to ask.

[hostilefork]

Against my better judgment I did allow @gchiu to have a LATEST-OF which can be run from the Web REPL:

https://forum.rebol.info/t/the-latest-news-about-latest-of/1758 https://github.com/metaeducation/ren-c/blob/master/scripts/latest-of.reb

So if you go to http://hostilefork.com/media/shared/replpad-js/ and type help latest-of you can see what that's about. Plain latest-of will guess your OS and give you a debug build.

That the LATEST-OF operation works is part of the CI test itself:

https://github.com/metaeducation/ren-c/blob/35c6f6c4723d76a245c5c628e07d3b500a5482ef/.github/workflows/linux-gcc-build.yml#L433-L448

I'd imagine this covers what you were looking for.

If you've generally lost interest, that's fine...but I'd ask you'd delete what you were doing (or make it private). Just for the simple reason that there's enough noise on the Internet already, and dead-ends tend to lead people to wasting time figuring out if they're relevant or not.