World: r4wp

That is precisely what Kaj has done with his console-pro binary, 
including several of his own bindings.

Don't ask me details on the module/component yet, I haven't decided 
on the best approach. I just know that I want it to be as simple 
as possible.

Doc, will we have anything like R3 environment stuff - e.g. delayed 
loading/bootstraping, some debug stuff, being able to trace memory, 
time of running app, etc?

You'll have much more sophisticate debugging tools in the Red IDE. 
;-)

I agree - R3 modules have to prove themselves first - we live way 
too long without them, most users are used to contexts ....

Well - IDE is IDE, I mean - the runtime stuff. Simply put (and most 
probably worrying unnecessarily and sounding like a broken machine), 
let's make R3/Red another Amiga like OS :)

You'll have some of the debugging features accessible from the console.

Having an outline for implementing types will be great. I have looked 
at the current code, and they are laid out very clearly, but notes 
on how the slots work, so implementers don't assume something that's 
incorrect would help. And also how best to leverage work in similar 
types.

Doc, will you implement this, too?

red>> b: %x
== %x
red>> b/y
== none

No flooding or trying to prove anyone wrong. I'm happy to see improvements 
and progress in Red's development. There is no Red-vs-R3, we're all 
in this together.

There are some things in R3, particularly some of the things that 
the module system can do, that probably won't make sense to do in 
Red because it's compiled. Delay-loading modules won't be as important 
for Red because most of the overhead of creating a module can be 
done ahead of time when it's compiled. It would make sense to support 
the delaying feature because you might want to have a module's side 
effects happen at a particular time, but the delay can happen a lot 
later in the process than it would in R3. Red might benefit from 
the options specification method and some other aspects of its surface 
API and behavioral model, but the implementation would be completely 
different. The restrictions we made to make the module system statically 
resolvable (in R3's case by a preprocessor like prebol or Ladislav's 
include) would be a lot more important for Red than they have been 
so far for R3, because compilation makes static resolution more important.

In many ways, R3's module system design is even more beneficial for 
a language like Red than it is for R3 itself. Actually, that was 
one of the things I was taking into account when we were thinking 
it through. Back before Red was announced I was thinking about putting 
a JIT compiler into R3, and R3's extensions are similar in some ways 
to what modules would be in a Red-like language. So R3's module system 
was basically designed with Red in mind.

In order for R3 to get the full benefit of its module system, Ladislav's 
include and Saphiron's encapper would have to be enhanced to use 
and process them. Red can get the benefit from day one just because 
it's compiled.

red>> {}
*** Load Error: string ending delimiter } not found!
== {}}

Error fixed.

About the path composition for files, I might give it a try tomorrow.

red>> ""
*** Load Error: string ending delimiter not found!
== """

Sounds like we really need LOAD regression tests if we want to finish 
this...

Yep. Another one:

red>> view [{}]
Box: skipping unknown dialect word "{".
Box: skipping unknown dialect word "}".

It's on my todo list to do more LOAD tests for R3. You can use those 
then, at least as a start.

Unfortunately they won't happen today.

I need to port them to Quick-Test anyway.

BTW, I have no clue where the R3 tests are located online?

https://github.com/rebolsource/rebol-test

Thanks.

file! is suddenly broken:

red>> print %x
unset

Those tests manage to be unified between R2 and R3 by tagging the 
ones that aren't. A #red tag could be added...

Works here.

Where do I find LOAD tests? There are only these ones: https://github.com/rebolsource/rebol-test/blob/master/load-tests.txt

Fresh build, on Linux

Let me stash my changes to see if there's a side-effect.

There aren't that many yet, which is why I need to add some.

All tests are here: https://github.com/rebolsource/rebol-test/blob/master/core-tests.r

Wait, my console-pro isn't rebuilt

Fresh console build with latest pushed commit (on Win7):

red>> print %x
x

I'm getting #411 again on two programs

With the exact same error message?

Yes. I've checked in my current state of GTK so you can test it

If you update everything, it happens on console-pro and GTK-IDE

{} is OK now that I've forced a build

On Linux only?

Dunno, probably not

I'm running View 2.7.8.4.3

Can you try it with /Core 2.7.6? (just in case...)

Sigh. rebol.com only lists 2.5

Found it in the maze. It works

Great!