World: r3wp

I am not just talking about you but about maby people in many places 
ROARING about the unrespected release date. Complaining does not 
help.

Collaborating in every plase does.

They have alredy the "pedal on the metal". No more  power can be 
taken from this engine. More we stress it more will the project have 
design and implementation problems.

Rebol 3 will come sometime the next year. This is (probably) the 
only fact we have.

the next year using an earth metric ?   ;-)

Please read back in this thread. The problem is not that R3 takes 
time. The problem is that promises keep being made and broken

Kaj, I have already read it and I agree with you: it is a Rebol Tech 
problem. It is better for us knowing no release date at all. I'll 
never ask it as I have learn to work on what we already have and 
not on what will there be in the future.

The first public alpha is supposed to be quite soon, but is not yet 
ready. The official plan will be released soon, after some refinement. 
All of the developers are busy developing or in other ways, or both. 
The first public release of DevBase should come with the alpha. Dates 
are approximate, as not all of the factors are yet known, but Carl 
now knows better than to provide unrealistic release dates (we hope).

Giuseppe, the collaborative approach you're talking about is impossible 
if we have nothing to work with. That's one of my gripes

Exactly this was promised for early this month

Kaj: Personally I prefer having access to some programmer documentation 
about implemantations, commands, structure and so on. So I would 
undestand how to setup my future projects.

Then, In my little world I live in, I would start writing: "I don't 
like this for that reason" , "I like it for this other".

Next year

 for me could be even 2009 to go out of alpha/beta but then I am sure 
 it will be a good implementation and not one produced under pressure. 
 However we must have an adult approach to the release date problem: 
 now we know that Carl has the defect of giving release date the team 
 can't respect...

Kaj, outside circumstances changed the plans. Two of the lead developers 
had to work on another task for a bit, and it took longer than expected. 
This happens. Others have stepped up to pick up some of the slack 
so development proceeds, but the particular parts those two developers 
were working on got put on hold. Those two developers are back now 
so developement on their sections is continuing.

... the next time Carl will write "this is the release date" we will 
answer him that the release date is not important but having a good 
language is.

With all due respect, this can't all happen within the last month 
that the promises were made

Estimates.

I'm not interested in having this whole argument all over again. 
I asked a simple question and eventually I got my answer: since a 
few weeks, Core is delayed for another month and View for several 
more months

It happened ! Now it is already history.

It is past. It has been surely a mistake but it happened and it is 
past. Now we must move from the incidend and have a positive approach. 
A stalled discussion does not help anyone.

Actually, /Core wasn't going to exist at all, but now something like 
/Core will be released as a public alpha.

GOOD ! More months means we will have a better product !

(Kaj, please remember my words: "Positive approach is the way" !

Please tell me how I can be more positive than building two operating 
systems and convincing everyone to integrate REBOL in them?

Kaj, I agree with you: you did your part on promoting Rebol and I 
respect you for your position.

I would really like to have some support back

Check your private chat then.

I know. I want to say this to you: I have even written to Rebol Tech 
asking for a pricing on both SDK/Command and having no answer.

I could have 2 approach: start screaming everywere stating that they 
don't even care to give the users a price or understandig that there 
is something wrong behind the scenes that does need our patience 
waiting to be solved.

I am sure, you did your best but the positive approach is waiting 
to cooperate. Now it is their turn to make something. Not our.

A last word as I have flooded this groups of message. Think about 
this situation there are 2 ships, both are sinking; on the first 
ship the passengers start fighting the crew of the sinking , on the 
second the passengers cooperates with the crew to save more lifes 
as possible. Which approach will give the best results ?

Now it is time for me to sleep. Here in Italy it is 5 to 1 am. Good 
night !

Syllable is not sinking ;-)

What you mean ?

Kaj, ths is not the proper group to ask questions about Syllable 
but I do not see a Syllable group here...

And the web site left me with a few questions

I'm downloadng the live version to give it a wirl.

New people here do not get into the Syllable group, as some people 
wanted it to be private

Ok, I have found Syllable on the internet. No more questions here. 
Good night dear collegues.

Giuseppe asked about my projects, though

I'm an old Amiga guy and Syllable reminds me a bit of Amiga (from 
the site). I would be interested in joining that group if possible.

I just added both of you. You can remove yourself if you want

And, it oncestarted out as an Amiga clone :-)

Louis: From what I can tell from DocBase; initially the unicode support 
will be that the Rebol source will be UTF-8 encoded. The next step 
seems to be changing string! to UTF-8 encoding.


It looks as though work hasn't yet started on the unicode! datatype.

as for UTF8 - is it compatible to current +128 char extension? I 
mean e.g. czech alphabet uses special characters above 128 ASCII 
value ....

Peter, thanks. The progress of unicode support is vefy important 
to me.

really? well, then you should know that first alpha with unicode 
support was released for testing :-)

That is great! :>)  Thanks for that news, Pekr.

UTF-8 is a strict extention of ASCII, but ASCII is only defined between 
0 and 127. Characters 128+ are not ASCII, they are extensions, and 
their meaning depends on the codepage. The codepage of an 8-bit string 
is unknown, unless you specify it externally (or do a lot of statistical 
calculations). Strings or scripts with characters extended by a codepage 
will have to be translated by a codepage-to-utf-8 function or process 
specific to the particular codepage, ahead of time. Fortunately, 
such a process can be fast and even implemented in a byte-oriented 
language easily.

Other than UNICODE, will there be an UNISEX version of the interpreter 
? :-)