World: r4wp

Ok, I am leaving, I have to go away.

Henrik speaks wise words. For the past decade, we've been occupied 
with maintaining the GNU C/C++ toolchain in Syllable. If it hadn't 
been so problematic, we could have spent that time developing the 
operating system itself, and the project might have been in a much 
better position now

To everyone: my questions are not meant to create problems. I work 
every day with customers and they always ask me "which is the difference 
between you and this other product/service".

So the difference between Red and R3 is between a car that takes 
you there, and a car that breaks down before reaching your destination

It's a fair question, but the answer depends on insight

I find myself less and less interested in REBOL, even open sourced

Well Guiseppe, you may have to think of a second hand car ;) 

You can drive with it, it can be the car you wanted but some details 
as its color and chairheating can differ from what you had in mind. 
It is up to you to buy it anyway. By buying second hand you can have 
a more powerful engine than buying a new car.

Remember that the REBOLution was proclaimed to create the next generation 
operating system. However, REBOL falls seriously short there, not 
having delivered an operating system and not running well on top 
of any other operating system

Red does solve the problems that need to be solved there

For what I have seen, Kaj, I can second that. I use REBOL to learn 
Red ;)

And the liberation from the C tool CHAIN Viva la Liberation!

:-)

It may be time to consider REBOL an idea, a good one and one that 
now needs to have its true wings in the form of Red.

it would be also possible to rewrite R3 in Red/System, but then R3 
would be similar to Red itself?

Doc tells me an interpreter would be simple to write in Red, so even 
there no need for R3

Does R3 need a console? It would be the interpreter made using Red.

you beat me Kaj!

Kaj - not sure it will be a console, but something like that, just 
not an interpreter, but more a JIT compiler?

Red will be a JIT compiler, but you could still write an interpreter 
on top of it. Might even be useful, for example for platforms that 
block JIT compilation

When the "Red Memory Manager" Doc will be released?

I posted in Sublime Text's forum in regard to the lexing needs that 
we might need for good Red support. The author hasn't answered yet, 
but maybe if others add to the thread, it'll keep it near the top 
and show there's interest in the idea. I suppose even if ST doesn't 
make its lexer pluggable, we could just make the built-in lexer do 
as little as possible by including no tmLanguage file for Red and 
delegating any syntax coloring/scope processing to a native library 
that's part of a Sublime Text package for the Red language. 

http://www.sublimetext.com/forum/viewtopic.php?f=2&t=9870

I think Red's USP is, "the performance of C with the elegance of 
REBOL" ... which is attractive to many folks like myself who woundln't 
otherwise venture near a "compiled" language (given the usual ease 
of use trade-off).

Nenad, could you describe a little the structure that's built up 
by the lexer? Are you intending to (at some point) allow for some 
sort of AST-like (if this is not what's generated already) structure 
to be passed back in along with some way of describing the start/end 
of a modified region in order to reduce the parsing that would need 
to be done if the lexer was being called relatively frequently when 
editing a large source string?

Jerry: when I find time to write it. :-) Probably when I get back 
to memory manager code to add the few missing parts, like GC and 
allocation of big memory chunks, that should happen in the next weeks.

AdrianS: the output of the lexer is nested blocks of Red values, 
same as REBOL with its own lexer (LOAD). The AST is not stored anywhere, 
AST nodes are created and consumed on the fly during the compilation. 
So the closest thing to an AST you can get currently is the output 
of the lexer.


For the needs of a code editor, maybe you could just invoke it on 
the currently edited line (though you would need to deal with unmatched 
opening/closing delimiters). I haven't yet though how I will achieve 
it in Red IDE.

This is all far out of my league. Though I had the same feeling when 
I started working with computers many years ago :-) Keep up the good 
work!

It's not as complex as it sounds. Feel free to ask any question about 
it in Rebol School or in ~ChitChat if it's purely Red-oriented. Open 
source projects are an excellent way to share knowledge and I would 
be glad if Red project can help people (including myself) learn something 
new.

Doc and the others:

I hav had some considerations about the RED = REBOL issue and I will 
continue the discussion in the REBOL3 area.

I noticed doc-strings are not available yet for #import?

It's late to talk about merging. It's been 2 years, Red is getting 
mature very soon aspecially after the Red/System part is almost done. 
Don't make any distraction to slow it down. ... Besides, R3 is not 
open yet (where is the code?), Red and Doc are all we got now. Doc's 
got the whole plan for Red, which is a good plan. We donate for that 
plan, not for a merge plan. The latest blog article in Red-lang.org 
made me realize that we might have a complete and mature Red in one 
year.

Jerry: that sounds like a realistic deadline to reach 1.0 release, 
as long as I can keep working full time on Red in 2013. Though, Red 
should be fully usable in a couple of months, all features would 
not be there, it won't run at full speed, but it will be enough to 
be able to build almost any app.

Kaj: the compiler should accept them from #import too...looking into 
it....

Nope, no support has been added for doc-strings in #import, but it 
obviously should be supported. I will add it tomorrow.

Thanks. Will have to wait in my bindings for the next release, though

Doc, how about Red becoming the Rebcode part of R3? IMO that would 
be a nice addition.

So, we get both worlds. If we manage to call R3 code from the Red 
section and vice versa, that would be great. We could use the compiled 
speed for inner loops and let the interpreter do all the non-speed 
relevant things.

Robert, I guess you mean Red/System and not Red? Well, the license 
are compatibles, so if someone wants to include Red/System into R3, 
he doesn't need to ask anyone for permission.

Or the other way around, no? With Kaj's system, you can write R3 
extensions in Red/System, no?

Yep, RedCode for R3 is already here

It could be integrated better, but that would require Red to run 
on R3

Kaj - but it is not like Cyphre creted JIT for R2, which looked like 
REBOL and was just faster. Red/System code surely can't run that 
way - it is for offline stuff, where you first have to compile the 
app, no runtime stuff ...

Cyphre's code also needed to be JITed first. I don't see a fundamental 
difference

Pekr: the difference between AOT and JIT compilation is much thiner 
than you think. Just load Red/System compiler code to your R2 app, 
pass it any source code at runtime, use the link?: no option and 
you get compiled code and related data in form of binary! values...and 
voilà! :-) The rest is same as for Cyphre's JIT, you need a way to 
call native code in memory, something that is hardly possible in 
R2, but maybe Cyphre found a hole to achieve it anyway.

something that is hardly possible in R2
 - not a problem

Ladislav: I was thinking about an internal only solution, I know 
it's possible to do it by using a tiny C code in a shared lib.   
        If you've figured out a way to do it without any external 
dependency, I would be glad to learn how you did it.

I know it's possible to do it by using a tiny C code in a shared 
lib.
 - does that look like a problem?

It breaks the "fit all in one binary" REBOL philosophy, requires 
to compile it for each platform and maintain OS-specific code...Not 
a problem per se, but IMHO a sub-optimal solution, that's why I was 
interested in a possibly purely "internal" solution, in case I would 
have missed it.

The link?: no option doesn't seem to be available yet. Is it in the 
unreleased AVR backend?

It's available but not documented as it is only used by the compiler 
internally for now. You can add it to any of the target definition 
block in %config.r for testing (or create a %custom-targets.r file 
instead). It will put the compiler in an "incremental" mode (it can 
compile incrementally as many source file as you want). Once compilation 
has finished, no file will be generated and compiler state will not 
be reset. You can then inspect the result of the compilation from 
console using:

>> probe system-dialect/compiler/job
>> probe emitter/symbols
>> probe emitter/code-buf
>> probe emitter/data-buf
>> probe system-dialect/compiler/imports


You can basically get most of these data in logs when compiling using 
-v 9 option.

Cool, thanks