World: r3wp

Who said beta will span all platforms?

I am also not sure, GUI will support Unicode from the very beginning, 
altough many expressed it being a priority. There is a difference 
between GUI and VID. Carl worked on VID. Once he is back to it, I 
believe Cyphre is going to be contacted to do some work on View part 
...

My guess is 2-3 weeks for VID itself and 1-2 months for the skin. 
Really lowlevel stuff depends on the availability of Cyphre.

Cyphre is waiting for the C code alignment. He does not have recent 
sources for View. If I understand him correctly, he has to wait for 
the Host code release ...

... or for Carl sending him latest version ...

when it's ready, I hope that Cyphre can at least partially work independently 
from Carl.

A windows only beta will nicely establish R3's cross-platrom credentials.

A non-unicode GUI beta will nicely establish R3's internationalisation 
credentials.

OK, so wait another year for the beta ...

then I prefer Core only beta, all current R3 platforms ...

eek... I can use it to send email!

what else

who wrote this?

it looks very nice

who wrote what?

the online rebol console

ahhh  ...  kaj

who said that ?

After the parse enhancement, I really think the extensions improvements 
(other datatypes and devices/callbacks) should be done first... a 
lot of stuff can then start parallel to what carl works on.  not 
just by me... but many of us can work on improving R3 at the capacity 
level through extensions and have the need and will to do it.

bah...

who said what?

Who said that the online rebol console was written by Kaj?

I think Henrik wrote one, Kaj wrote one ... is this a new one ?

we can do the protocols now, by ourself, since a while, but noone 
do that. We are just a bunch of lamers :-)

ahhhh sorry, that is a new one !

And people could come with VID proposals too, to help Carl

freebol is a domain owned by the guy refered to as "hostile fork" 
afaik

I think the VID design is pretty decided upon, it just needs agile 
hands to implement it... and that IIRC depends upon a few enhancements 
to the engine and for some of the design to be finalized by Carl.

I have to change color... blue is too crowded.

looks like Carl wants to visit the problem of empty rules.

Henrik is referring to this blog entry:
  http://www.rebol.net/cgi-bin/r3blog.r?view=0258

Brian, it's possibly forlorn, but I can forsee a pattern of [and 
map! here: change to-block here/1 :here into []] (sorry, rough approximation) 
in order to serialise in one form or other.  Given there could be 
no other possible use for [into map!] perhaps parse could imply that 
conversion?

The new one was written by user known as Fork, or HostileFork ...

Good guy, and smart too. New to REBOL but not new to programming.

Another Brian :)

Chris, we've been careful to make the interaction model of map! more 
like that of objects than series. You can't parse objects either.

Right, objects present a similar pain.  I know for the most part, 
you don't want to do this.  It's a very specific case - when 'parse 
into encounters a map, instead of returning false, it converts to 
a block and parses.  I don't see this as touching the way map! works 
at all, just parse - for those occasions where it'd be useful over 
an old-style workaround.

As I said, the main case use is serialising tree structures with 
mixed nesting.

Instead of alternating between parse/iteration, you can just use 
parse.

Well, the IF operation of PARSE was added exactly for that reason: 
to make alternating between PARSE and DO code easier :)

BrianH ...  it's like a "i don't kiss girls  cause i'm affraid" your 
comment about open sourcing ... sorry but when the language is open 
source and have apeal  it meet it's public ... And contributions 
rains...


So open the  source at least will have an educational purpose ... 
it's better to be able to refere directly to the content of the source 
code to extract replies to our asks than waiting endlessly answers 
from the main chief guru or ithe selected ones don't you think ?

it's better to be able to refere directly to the content of the source 
code to extract replies to our asks than waiting endlessly answers 
from the main chief guru or ithe selected ones don't you think ?

 - sounds quite childish, who asks you to wait for anything? I never 
 did, even when I was asked to by some like you. Some answers I wrote 
 in my articles actually cannot be found in the source code, how about 
 that?

those like me sounds insulting ... are you looking down to me ?

You are insulting me by saying "waiting endlessly answers from the 
main chief guru or ithe selected ones" - I repeat: never did and 
never felt like, but was asked to by some like you. You are even 
now trying to state I should, as I read, that is why you are like 
those who did before.

Shadwolf, all of my contributions to R3 and R2 have been in the open 
source portions, which is already a significant fraction of REBOL. 
This source has been open for a year at least, effectively. In that 
time, having the source open has brought the code contributions of 
a couple people. This is what I mean when I say that opening the 
source isn't some magic trick that will get you help.


In that same time period, the introduction of CureCode, R3 chat and 
DocBase have led to huge amounts of contributed help, more testers 
finding more bugs than we ever would have found without them. Those 
contributions have been extremely valuable. However, none of them 
were related to opening the source.


Now, I am all in favor of opening the source, but I am in favor of 
it for social, business and convenience reasons. I have no illusions 
that it will get more than a few people to contribute though. And 
read-only licenses are the worst of all, because anybody who wants 
to actually do anything with what they might learn from reading the 
code is usually legally prohibited from reading the code, to prevent 
accidental copyright infringement.

When the host code is opened, I will celebrate with the rest of you, 
particularly since it will allow a level of customization that SDK 
encappers could only dream of. I can only hope that it would bring 
useful contributions though, particularly in platform support.

perhaps it's a binary switch?

[post removed by library team. (sunanda)]

[post removed by library team. (sunanda)]

Dilemma there, because it should still be remembered.