Crash in test suite

[jacereda]

n-do-patch.txt The following test crashes the interpreter when built with -DNDEBUG

../build/r3 ./run-tests.r parse/examples/red-replace.parse.test.reb

I'm pretty sure this isn't the right thing to do, but the attached patch fixed it for me, it might give some hint.

[hostilefork]

You've picked a complicated thing to look at!! If you have thoughts to share about it, there's a forum thread here:

https://forum.rebol.info/t/skinning-replace-with-reds-string-parse-hack/2043

This bug actually came from the fact that the "trash" state was used to signal when the parameter enumeration was exhausted. Trash is a special "write-only" concept that only exists in debugging. But the test IS_TRASH() was misleadingly defined to just return false in the release build. Hence it accidentally got used when the /RELAX refinement was added to APPLY, when that need-to-read meant that trash was not the appropriate tool to use.

To keep this from happening again, IS_TRASH() is #undef'd now in release situations:

https://github.com/metaeducation/ren-c/blob/master/src/include/sys-trash.h

https://github.com/metaeducation/ren-c/commit/5ab7367f52376bb76aed696a9e1d0491da821c6b

As there being lots of not passing tests shows... right now everything is in quite a lot of chaos... a collection of experiments. I'm not sure what to do with it. I might just consider the product of all this to be a research paper, and throw out the code. :-/

[jacereda]

Works fine now, thanks.

[hostilefork]

Though I've been neglecting the project for much of the last year, I'm glad to have participation... especially those who can get through the building process and look at the code!

But as you're probably noticing... the state of things has come to err on the side of experimentally exploring fundamental language questions. The creation of "generalized isotopes" (including the idea of "unstable isotopes") felt right enough that haphazardly retrofitting things to try the concepts outweighed more conservative changes for the near-zero userbase:

https://forum.rebol.info/t/a-justification-of-generalized-isotopes/1918

Re-thinking PARSE as something which is built in usermode via "parser combinators" means it's tremendously slow. But it is meant to be a showcase of what you could do effectively as a user (vs. needing to use C for any "solid" code):

https://forum.rebol.info/t/introducing-the-hackable-usermode-parse-uparse/1529

Optimization has been tinkered with, and does show promise, but it is not a priority:

https://forum.rebol.info/t/progress-on-nativizing-parser-combinators/1636

The whole of the situation comes from the idea that I found historical Rebol to have poor invariants, and a pursuit of making it act rationally for non-trivial compositions:

https://forum.rebol.info/t/the-canonical-list-of-non-negotiables/1244

All these apologies for the mess aside...I'd be interested in what triggers your interest, a good place to write thoughts is in the introductions section on the forum:

https://forum.rebol.info/c/introductions/46

[jacereda]

Sorry for the delay, been quite busy these days.

I simply started exploring Haiku some weeks ago and was quite surprised there wasn't a packaged Rebol interpreter in HaikuDepot.

I have good memories of Rebol on my Amiga, so I thought I needed to port this. Too bad there isn't a VIEW dialect :( I might consider it at some point.

For now I can contribute a prebuilt binary for Haiku-x64 and the patches I used if you're interested. I'll PR those when I find the time to polish the whole thing.

[hostilefork]

Ah, cool. I've tried to keep it possible to run on Haiku, though last time I built it myself was September 2021. There were some issues about no support for either C99 or C++11 in the version I tried, so I wound up having to revive C++98 support as a compromise:

https://forum.rebol.info/t/ren-c-builds-with-20-year-old-compiler-on-haiku/1710

At that time networking hadn't been rewritten to use libUV, but now it has been. Maybe that means network reads will work on Haiku?

https://forum.rebol.info/t/libuv-integration-has-started-an-i-o-renaissance/1694/5

If it doesn't but is close to working...maybe you want to look into it. :-)

For now I can contribute a prebuilt binary for Haiku-x64 and the patches I used if you're interested.

I'd certainly take a look at patches. What would be even better would be if there were some way to get a HaikuOS build on the GitHub continuous integration... could QEMU be used there?

Main thing I want people to be aware of is that this is a huge barely-under-control experiment that is not ready to have users. Ren-C is deliberately not advertised anywhere while it has a chance to evolve. So definitely don't let any prebuilt binaries escape somewhere like HaikuDepot, and certainly don't brand anything as an official "Rebol"!

[hostilefork]

Too bad there isn't a VIEW dialect :( I might consider it at some point.

P.S. on this point... I was never particularly impressed with Rebol2's view dialect myself. I guess I'm skeptical that something as open-ended as arbitrary GUI development can be captured well in one design. Particular domains (like input forms) perhaps.

You may be interested to know that the Red language implements not just "VID", but a competing variant called "VID/S (Spaces)":

https://forum.rebol.info/t/vid-s-or-spaces-from-reds-hiiamboris/1886

I'm skeptical of the value of investing in GUI on native platforms, vs. furthering the WebAssembly integration with browsers:

https://forum.rebol.info/t/visual-parse-on-the-web-has-arrived/1837

It seems to me that any development of a GUI dialect is best experimented with in the browser. If what arises were truly amazing in terms of what it could accomplish without forcing you at source level to express any CSS/JavaScript/HTML, then perhaps that would be the time to consider a native implementation that could run without a browser. The benefit of prototyping as a web app is then the prototype is likely actually running on the most realistically useful platform to the most people.

[jacereda]

I'd certainly take a look at patches. What would be even better would be if there were some way to get a HaikuOS build on the GitHub continuous integration... could QEMU be used there?

I'm not very familiar with GitHub CI, but looks like this is it?

https://github.com/hectorm/docker-qemu-haiku