Problem with r3-54fbf54.exe, r3-54fbf54-debug.exe

[no-e-in]

On win7, from replpad-js:

Then problem with 0.3.40:

and 0.3.1:

[hostilefork]

Well, this looks like three different problems.

(1) Looks like it's using cloudfront links, and cloudfront is not enabled at this time due to the fact that it caches links and breaks our greenlighting strategy (e.g. a single file that has a consistent name but changes to tell us which hash for the build has passed enough smoke testing to be valid). A greenlight would need to be able to expire caches, and until then we are using s3. So it looks like the download script was experimentally changed and not changed back when the s3 finished.

This falls under my general belief that anything people expect to keep working needs to be tested. We now have headless automated smoke testing through marionette which can use a headless firefox and poke keys into it and test for answers. The code is not terribly difficult to grok, so if we'd like to add a similar-looking script to live alongside the downloads script and get pulled and run, that is fine by me. Any interest in helping with that, @no-e-in ? Just a bit of Python and figuring out what the downloads script should say.

(2) This is an artifact of committing to C99 or higher for smart console features. The C89 implementation path was low priority. I didn't realize the MinGW builds on Windows x86 was actually using C89 when you just say "C". :-/ Anyway, this addresses that:

https://github.com/metaeducation/ren-c/commit/017e385d9c15d45768fc693f24d26cdb94c56d57

(3) Looks to be some kind of memory thing. I don't get the problem.

So for what it's worth, these two run for me now:

http://s3.amazonaws.com/metaeducation/travis-builds/0.3.1/r3-017e385.exe http://s3.amazonaws.com/metaeducation/travis-builds/0.3.40/r3-017e385-debug.exe

[no-e-in]

Both r3-017e385.exe (and last r3-a29b32c.exe) and r3-017e385-debug.exe show the same result as (3). If you have no problem on Win10, you can close the issue.

[hostilefork]

f you have no problem on Win10, you can close the issue.

I tried ReactOS and it worked, with minor modification to unlink "vnsprinf" (a recent dependency due to mbedTLS which could be removed).

What is the specific OS version and specs (processor, memory, etc.) you are using that are having the problem?

[no-e-in]

I don't want to waste your time on an old system (above all if it's just my problem).

The working version of ren-c that I own is:

Version: 2.102.0.3.40 Platform: Windows win32-x64 Build: 11-Oct-2019/23:10:48+0:00 Commit: 4e67e9e46b1e97c2dc7624174e39149e149c710c

[hostilefork]

I'll mark it low-priority, but I'd like to know what the problem is and keep an eye out for it, especially if it used to work. We might be able to locate a commit which caused the problem.

Maybe we'll come across another Windows 7 with a similar configuration and try it there. (I made the ReactOS system act pretty old with 1GB memory and it still worked.) I can try a Vista on an old laptop, and I have an XP virtual machine somewhere too.

[no-e-in]

Last working version of ren-c (from https://s3.amazonaws.com/metaeducation/travis-builds/0.3.1/):

Version: 2.102.0.3.1 Platform: Windows win32-x86 Build: 6-Mar-2020/2:54:52+0:00 Commit: af6ff2fd6306b4d501fe343512e830358080a2b0

First version not working is 5a74c34. It only prints ">>" all the time.

[hostilefork]

I meant, rather, what your Windows specifics were (how much RAM, what service pack, etc. etc.) But as it happens, I borrowed a Windows 7 laptop that reproduces the problem.

Prior to that, I tinkered around and built a version with Visual Studio in order to get it to be XP-compatible, and it runs there, shown here demonstrating multiple return values:

So this appears to be something particular to MinGW-based builds and older Windows. If you'd like to confirm that, here's the build I used on XP:

https://hostilefork.com/media/shared/no-e-in/r3-vstudio-347f5f7.zip

As always...having a repro case is usually the key to resolving things...though I don't really know even if I put a MinGW-based toolchain on this Win 7 machine (which is not mine) if using the non-cross-compiler will have the same issue. Guess I will find out! :-/ Otherwise I'll change the Travis build to keep debug symbols and see if I can step through it locally.

[no-e-in]

Hostilefork, thank you for taking the time to my problem. But: https://hostilefork.com/media/shared/no-e-in/r3-vstudio-347f5f7.zip =>_CONNECTION_REFUSED

[hostilefork]

@no-e-in I'm sorry, it's an http link... not https.

http://hostilefork.com/media/shared/no-e-in/r3-vstudio-347f5f7.zip

[no-e-in]

After downloading Visual C++ Redistributable for Visual Studio 2015 (for VCRUNTIME140.dll), ren-c works. Have you tried compiling ren-c with ren-tcc? I had tried a few weeks ago but I failed.

[hostilefork]

After downloading Visual C++ Redistributable for Visual Studio 2015 (for VCRUNTIME140.dll), ren-c works.

Microsoft does not consider statically linking to the VC runtime to be a supported option and warns not to do it. There are reasons it is technically inadvisable.

Though Rust at one point changed to do it anyway.

Have you tried compiling ren-c with ren-tcc?

I have never done this on Windows. The demo I did in the conference video with a tcc bootstrap was on Ubuntu. Of course, keeping such things working even still requires a running test. So I wouldn't mind a Travis build which uses a TCC compiler to build initially including the TCC extension, and then bootstraps using that Rebol-with-TCC as the C99 compiler as well as make tool.

But I do not have the time to write everything in the universe, so I have to pick my priorities. I'll offer help with someone who is interested in doing it, based on what I know. But most of what I know is in the README.md or code comments.

Speaking of that README.md: if you read it, there are a number of additional complications with TCC on Windows to sort through. One would have to be an individual with sufficient motivation to slog through it all to get a bootstrap.

I lack that motivation: Windows is not a platform I am interested in, other than proof-of-concept of versatility. Though Microsoft is trying to be better about open source lately--it's still the case that proprietary closed source systems that are gigabytes upon gigabytes for minimal installations aren't my cup of tea. Not only is Windows 10 too big to want in VirtualBox to start with, they charge you for each one you want to spin up. Add in all the spyware and shovelware like Xbox apps you can't uninstall...and yeah, no. I can't be building a better future if I drown myself much deeper into their ever-increasingly deranged one...

Just say no, kids!

[no-e-in]

For this reason I am still on win7. Hostilefork, thank you for everything.

[hostilefork]

I installed a MinGW-based compiler (via installing Qt Creator, and choosing MinGW kit) on the Windows 7 machine. It reproduced the error, so I could look into it with a debugger. (It's not really that hard to do, so if you don't have an integrated debugger / IDE you might consider it.)

Two things are going on. One is my mistake...no C builds at all were using the smart console because I got an #ifdef wrong. Then I noticed some other details while testing. Here is a summary of what that was about.

but that probably wound up good though, because it means we're testing the "dumb" console branch even though I was supposedly too lazy to care about it. Which brings us to the second issue, which appears to be a bug of some kind in Windows 7 when using ReadFile() on stdin attached to a console with a large buffer.

The Go language came across the same issue: https://github.com/golang/go/issues/13697

I've lowered the size we ask for, and then if that still gets the error it repeats asking lower amounts until it gets to some minimum. Summary here.

If you've not been following the motivations behind mucking with the console code, it's changes to become more "granular" in the sense of doing the key-by-key processing. The goal is to abstract that so that we can have one history mechanism and tab-completion codebase that is shared across all the targets (much as there is one shared body of REPL logic).

Hostilefork, thank you for everything.

The best way to thank me is to hang out on the forum and share whatever you are working on!!

I think there's a lot of interesting stuff afoot. The emulation of Rebol2/Red is a project that I think has a chance to really show off the acrobatics of the system, and that's something it seems people would enjoy helping build and test.

Anyway, these should hopefully work...note the x86 one is being built as C89 and hence lacks smart terminal functions on purpose:

http://s3.amazonaws.com/metaeducation/travis-builds/0.3.1/r3-67ee4fd.exe http://s3.amazonaws.com/metaeducation/travis-builds/0.3.40/r3-67ee4fd-debug.exe

[no-e-in]

Hostelifork, they both work.

The best way to thank me is to hang out on the forum and share whatever you are working on!!

I have a relationship with the programming of love/hate. It takes me dozens of hours to implement a program of medium/low complexity. I constantly make small mistakes and the end result is often mediocre. It's frustrating. With ren-c you've moved a long way away from rebol and it's hard to find the documentation of the changes. Also many functions that enhance the features of ren-c, like collect then else etc., are written in c. So in ren-c you can find either many simple functions or few rather complex programs. I wanted to bring to ren-c and red the core of this prolog written in rebol. It is a program that stresses the stack, the memory and the processing speed of the interpreter. Unfortunately in the program there is a bug in the unification algorithm, which is noticeable in the more complex processing, which I was unable to detect. However, I often test replpad-js, 0.3.1, 0.3.40 and some functions like help and sometimes I try to compile ren-c. It's not much but also the skills are not many.