World: r3wp

Unlike JVM bytecodes, which were designed to be implemented in hardware, 
or CLR bytecodes, which were designed for JIT compilation, REBOL's 
semantic model was designed for efficient interpretation from the 
start, and then made more efficiently interpreted over time. A machine 
interpreter for the REBOL semantics would not really resemble the 
machine architectures with which you are familiar (maybe the Lisp 
machine?).

If you were going to be doing this in hardware, it would be likely 
that there would be some changes to the details of the data model 
to make that more efficient. However, to keep the real advantages 
to REBOL's semantic model, the core principles would still need to 
stand.

who cares the developpement is on hold Carl have better more profitable 
things to do than loose his time with rebol 3

brianH none of the non compilable programming languages was a success. 
Face it Softwares companies want to steal idea from public domain 
but don't want anyone to steal from them that's how it is. And as 
compilation hum brianH SDK is a half assed intent to hide source 
codes of rebol scripts to people common view no ? So the statement 
I'm making Carl made it like 9 years ago when he create the sdk branch...

what are the things not compilable ? list them and then we will see 
if there are of any interrest in fact, if you want to discuss  things 
come with arguments for the discussion and not

come with hum it's not possible cause the guru said so.

Carl is killing rebol for many years now you don't believe it but 
that's how it is...

Now close is R3 to first beta?  Now that Carl has a job ... it looks 
live the core development is going to be stalled for a while yet.

So close and yet so far away. It could easily be called a beta right 
now, and a release with some more bugs fixed and just a bit more 
implementation, for example in SORT

But obviously, if no progress is made towards that anymore, it can 
still take a long time

Can't sorts be done as an extension?

Yes, but that's not really relevant to beta status

I'm using a REBOL implementation

I think someone else did a binding to a sort library

Ok, I guess the question is then , how blocking is Carl's absence 
going to be ?

R3 has a real chicken and egg problem. Much work could be done without 
Carl's direct involvement but for many people Carl's work is not 
yet sufficiently complete for them to do it. (A good example being 
the work you've put into R3 schemes, Graham).


The RM-Asset team are doing a great job of making progress with R3/GUI. 
Lets hope that they can continue and don't hit some issues which 
will need a lot of Carl's time to fix.

Peter, as far as I recall, the schemes I worked on 2 years ago did 
work .. but I was waiting for Carl's promised review so everyone 
would know whether this was the way he wanted things done or not. 
 Nobody wants to have the same issue that Gabriele had of writing 
code ( VID, http ) which is then deemed to complex or hard to maintain.

In this respect ... I did not want history to repeat

In Carl's absence .. we need a project lead who is going to take 
over .. or we just do the Milton thing

If your schemes had been used for the last two years wouldnt they 
be the de-facto schemes by now?

I never completed the user interface to them ... just tested that 
the basic functionality was present.

No point in polishing them if Carl had something else in mind

The big question is where to publish them as there isn't a single 
repository for REBOL as there is for other languages CPAN, PEAR, 
GEMS etc.

Pretty much most things are now on github are they not?

I disagree with there being no point in polishing things if Carl 
has something else in mind. Code only needs Carl's approval if it 
is to be included inside the executables that he publishes.

github is popular for source code but not for distributable modules. 
Many Ruby/Gems source code can be found on github but they are still 
distributed via GEMS.

Peter, I think schemes come into that class

Nobody can take over from Carl as he has complete control over the 
source of the "core" of REBOL. Different people could take the lead 
for different "non-core" projects. Robert is taking the lead with 
R3/GUI. (Perhaps because he has a need for R3/GUI). You had taken 
the lead with R3/Network schemes.

Why do you think schemes need to be included in the executables published 
by Carl?

because people would expect to have things like ftp, smtp, pop3 in 
the distributed exe

Why? Because they were included with R2?

because http is included with r3

I have a question for Kaj .. does the curl binding mean we can use 
https as a scheme now?

Pretty much everything I do requires SSL these days

A partial implementation of http is inlcuded in R3, most likely because 
it is needed by R3 itself.

It is going to be a long. long time before there is a version of 
R3 published which inlcudes ftp, smtp and pop3.

I do know how to spell include just now hoe to type it !!

I thought there was a way that one could include one's own schemes 
in a binary .. but I never got it to work

You can use SSL in the cURL binding, but I haven't written scheme 
wrappers yet. Due to incomplete documentation, that's going to be 
a lot of work

Basically the same issues you had

Would Curl-to-R3 be able to solve the NTLM challenge that I have 
... similar to Graham's HTTPS for everything these days?

this doesn't work ? http://softinnov.org/rebol/ntlm.shtml

Graham I was never able to get connection using Doc's NTLM to IIS 
6.0.   Do did you have success with a Windows domain where you can 
display the login with a REBOL UI and then request information from 
IIS?

I've never tried NTLM .. suggest you contact doc

Thanks. Doc and I have had a series of discussions on it where he 
has helped me out. In particular was Cheyenne being able to pull 
IIS information authenticated to a Windows domain for presentation 
from Cheyenne. We got to ... some more detailed / dedicated Doc work 
needed because NTLM is tricky.   That's not an option now because 
Red is a priority for everyone including me.  But if Curl enables 
it ...

NTLM is a hard to support, even using OS API. Making my NTLM implementation 
work in all cases would probably take days (or even weeks) of research, 
tests and debugging.

A shorter road might be to port Python NTLM libs to REBOL.

cURL supports NTLM

There are two sides to R3 adoption for me. First is the available 
features. I greatly prefer to have basic schemes (HTTP and FTP in 
particular) built in. A basic GUI system is also important to me, 
but I can use R3 for non-GUI things without that. The second, and 
more important, aspect is stability and robustness. Is the module 
model stable, is it robust? Will tasks ever work? Are there outstanding 
core bugs that will prove problematic if they are never fixed. That 
is, if RT never did any more work on R3, could I use it for production 
work?

That's a matter of how much risk you are willing to take. R3 works 
quite well, but if you do hit a problem, it will be impossible to 
fix