Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build binary compatible in R2 and R3 for Elf #421

wants to merge 1 commit into from

Build binary compatible in R2 and R3 for Elf #421

wants to merge 1 commit into from


Copy link

@hostilefork hostilefork commented Mar 4, 2013

This is incomplete work but my original goal was not to get all the regression tests running, but just get a byte-for-byte compatible executable. Now, as per Kaj's suggestion it's not necessary to hold it up when there are people who are in a good (and likely better) position to help. It should not be actually pulled into master until the test regressions are fixed. But pushing it seemed like the right thing to do at this point.

One important thing is that there is an esoteric bug in R3 which I isolated, and which BrianH is working on a "real fix" for. I just poked in a workaround temporarily. Here is the modification I made to c-word.c around line 238... I just wrapped the while loop in an IF:

if (LEN_BYTES(VAL_SYM_NAME(words+h)) == len) {
    while ((n = Compare_UTF8(VAL_SYM_NAME(words+h), str, len)) >= 0) {

You'll need that or the real fix for Compare_UTF8, for binary compatibility of the R2/R3 build of

Performance-wise it suffers because I did not try to tackle a map! rewrite, since defining hash! as block! was easier. That's something that wouldn't be too hard to do, but more prudent to get the test suite passing again.

I threw most of my miscellaneous routines for R2/R3 support into the r2-forward.r file just because it was included already and I didn't want to add new files if I could avoid it. But what we actually want is going to be a mixture of R2/Forward enhancements and the creation of R3/Backward.

These StackOverflow questions pertain to the documentation of issues of R2/R3 compatibility, sorted in rough order of importance:

If possible I'd like to have discussions/feedback about those questions and techniques on StackOverflow, at least as much of the discussion as we can.

Viva la Redolution...! :-)

Copy link

@hostilefork hostilefork commented Sep 7, 2013

I'm going to close this pull request and assume no one is doing derivative work on it. Hence if this is important, then rebasing the changes against a current master would be the best strategy.

In my opinion this was important. It gave me a fairly broad view of Red and how it works, the thinking behind it, and assisted in forming my opinions of the direction of the Rebol and Red projects.

It also formed the basis of what an "R3/Backward" would need to look like, found a couple of mean bugs in Rebol, and was my first "real" Rebol programming project.

However, we basically cannot move forward on this without getting the indexing compromise finished. With that and R3/Backward, Red should "just work" on Rebol3 with only minor changes at most.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

1 participant