World: r3wp

We need more information on what Carl is cooking ...

hum so lets imagine due to the few information how a VID "page" will 
be page [ <button text="my text on the button" action: [  some-callback] 
 bgcolor: red fgcolor: pink size:100x50  position: 0x0 >

A few questions I have about R3:


Will R3 be open source in some fashion?  For example if Carl were 
to retire or expire, would the language remain viable or would the 
evolution of operating systems make it obsolete.


Will R3 be capable to access low level hardware?  For example, will 
I be able to read sections of a hard drive directly?

Will R3 enable me to send ICMP packets over the network?


What is the primary revenue source for RT expected to be from the 
production of R3?  Is is the software alone or some other licensing 
models?


I'm sure I'll have other questions but curious of these for now as 
I contemplate the future of my programming skills.

1. There is a clause that makes sure the code will be opened or transfered 
to a different instance in case of RT's demise, but I'm not exactly 
sure on which circumstances it counts.


2. You should be able to access drivers directly, anything that fits 
with R3's device model. See http://www.rebol.net/r3blogs/0087.html

3. See 2.


4. Products built on top of R3. R3 itself will be free as in beer.

Then how is RT to make any money $$$?

See 4. :-)

So Carl doesn't need to make money from R3?

I don't think he can make money from R3. R2 has specific barriers 
that prevent you from implementing specific things in the free version. 
Those barriers are gone in R3.

I'll guess I'll hang on for a bit longer.

My take on it is that REBOL/IOS made more money than R2 did. It's 
just well-known that a lot of people didn't like paying for essential 
features like better security algorithms, ODBC or DLL access (DLL 
is now free in R2 though). When that is the case, it's easier to 
just flip over to an open source language like Python which do these 
things for free. I also know that RT is wanting to build apps based 
on REBOL, and not just sell REBOL itself.

forgot the SDK... that must have made a few $ as well. I don't think 
that will be free for R3.

What would be included in the R3 SDK?

I don't know yet. Other than encappers, hopefully an IDE or advanced 
debugger. It's stated on the rebol.com site that an IDE would have 
to be done in cooperation with a third party (us!). :-)

I see.  I know I currently have the R2 SDK.

I have it too.

Will R3 be open source in some fashion?  For example if Carl were 
to retire or expire, would the language remain viable or would the 
evolution of operating systems make it obsolete.

Paul tjat's  an ask I do to myself often rebol have to stay for the 
futur generations ...

paul all the other asks you do i'm doing them since 4 years now ^^ 
...

I don't think he can make money from R3. R2 has specific barriers 
that prevent you from implementing specific things in the free version. 
Those barriers are gone in R3. ---> Was true on the earlier version 
but as more ppl using it more way to bypass the limitations on free 
version have been found (using a C server to implements callback 
to a library overide all those limitations 4 years ago I told Carl 
those limitations where just futile they can slowing down the developpement 
nothing more...)  examples: calling a .Exe file was  bypassed first 
by the browse/ set-browser command wich lead me to co write the first 
free rebol WM packager a clone to a SDK (not as sharp) but  witch 
was able to package in a .exe file a VM script and related datas 
(dependencies (iimages etc...). That project was grebox. and then 
It was obvious to allow free version to use call function.

sql:// have been opened by  mysql-protocol so the limitation to access 
odbc:// was not working neither

for DLL we openned it by  doing C  servers and make rebol scripts 
sending commands to those servers wich is what rebol is all about 
 (messaging system)

so as all limitations can be bypassed why keeping them ?  I prefere 
franckly the way blender claim mommey they have a preoject they do 
the bill then they publish on their web sites "OK guys we want to 
intruce this new feature it will cost us that monney we open donation 
if you donate alot you will get prizes (t-shirtt, cd with advanced 
tutorials, mugs  etc...) and that system works well plus contributors 
feel they really are guest and participating activly on the blender 
project advancement that's in my opinion lot more dynami

c

for IDE that's too an old dream of us pending to the lack of often 
release ....

I don't want to start programming an IDE if at the end of the year 
I have to redo all the work because rebol3 is realeased and I have 
to change the whole IDE

but the IDE is an IDE in rebol to do rebol software.... But why an 
IDE  in rebol ??? Well for a  lot of reason 1) promotion purpose 
.... Rebol don't need anything else than rebol to do his dev tools 
... and if we can do dev tools as sharp as you can see it with rebol 
that means rebol can do alot for your company too. 2) cause rebol 
 is what we are doing here  ^^... Other language are other languages 
More rebol to save the people  ^^.... 3) because who knows better 
what we need and what we want than us  maybe the strongest and the 
first to believe in rebol  4) because IDE in rebol can make us share 
the code and work together on a base project where anyone will apport 
his ideas tries and that's what is a community all about doing there 
own project on their sides sharing informations and experiencies 
and gathering around hudge project or mendatory projects  ( like 
rebgui  ^^)

Thanks for the info Shadwolf.  I see your frustration and noticed 
some of those projects over the years.

I would not start working on an R3 IDE until R3 is feature stable 
(sometime around beta release). R3 contains in its current version 
more debugging and profiling functions than the public alpha and 
there might be more to come. It could be that Carl sees a good direction 
for an IDE at some point.

I have no intention at this time, thats for sure.

Sw: I guess you see an IDE as having some built-in collaboration 
tools (as per #4)?  #3 -- Rebollers, for some reason, have a very 
hard time using someone else's code -- that's part of why it's difficult 
to establish a repository.  Perhaps an IDE would bridge this as it 
would allow developers to bring in 'modules' seemlessly?  #1 -- look 
at Ruby and Rails for a language/framework that is successful in 
spite of IDE availability.  They use that language as a strength 
and rely on the quality of 3rd party editors (TextMate?) to make 
it accessible.  Not to mention immediate availability within all 
but Windows OS (sigh)

My goal with QM is to deliver a high-level entry point for developing 
web applications (and a fledgling sister project in app development) 
that gets you started quickly, reduces the quirk quotient, structures 
the environment, and is above all expressive.  I see this as the 
hook.  Depth comes with initial success...

Chris, I think the thing we lack in REBOL is that we don't have any 
collaborations really.  What I mean is the partnering of each others 
products and putting them out as a solution.  Think of QM and TRETBASE 
or some other product and then maybe that powering Henriks forum 
just to give you an idea.

Collaboration and community development is a goal of DevBase.

What is the status of REBOL3 right now?

usable but not complete

Louis:

http://www.hmkdesign.dk/rebol/files/90e3407319954c2fb00e1665fdbd0e22-128.html

http://www.hmkdesign.dk/rebol/files/2d1fc42665bf4b0db081b79d236a3b38-129.html

Henrik, many thanks for the blog links. Very interesting.

Is unicode support finished?

it's implemented, although there are still compatibility bugs left 
some places.

unicode has changed many things on a basic level. this affects some 
mezzanines which need to be fixed.

I figured unicode support would be very complex, but I think now 
that it was even more complex than I thought. It will be very helpful 
to me. Thanks for the info, Henrik!

I am not aware of any bugs in the mezzanines relative to Unicode, 
but there are a few in the natives. Overall the code could use a 
conceptual audit for Unicode compatibility, though a great deal of 
this has been done already.

If anyone else knows of specific bugs in the mezzanines that relate 
to Unicode, please bring them up here or in the applicable forums.

BrianH, well I guess I counted indirect changes in. If you look at 
the latest bugs, some mezzanines still expect non-binary input for 
WRITE and non-binary output for READ.

I'll check. Thanks for the heads-up.

That bug can't be fixed without the string-to-binary encoding and 
decoding infrastructure being there. Those native functions don't 
exist yet because their design is not finalized.

For that matter, I recall that there was some talk of changing the 
SAVE and LOAD functions completely. It is an unresolved design issue, 
unless Carl's current work includes string encoding and decoding 
as well.

So to answer Louis' question: Not yet, as far as we know. The data 
structures for Unicode strings are there, as are UTF-8 word! values, 
but binary encoding and decoding is not yet there, and there are 
some limts to Unicode input and output (mostly due to the Windows 
console). The encoding/decoding work seems likely to get done as 
a part of Carl's GUI work, as that will probably include text display. 
The console IO limits are likely to remain until the written-in-REBOL 
GUI console is adopted.

This is all an informed guess though :(

Thanks, Brian.