World: r3wp

I will fix some of the bugs though.

The closer we make it, the less documentation we have to write ! 
:)

For example,  the Ops in Orca have are more comprehensive and correct 
that the ones in R2.

Indeed.

do we clone the stupid parts as well? :-)

now now ;)

Lets swicth the conversation to IRC.

I'm looking for an IRC client now... what are you guys using ?

I use Colloquy in OSX

I'm going to try Bersirc.

What's the freenode server address I need ?

Ok I'm in.

Anton -if you are on Windows, then mirc is probably the best one 
...

Too late, I'm using Bersirc, which is open source.

ah, ok, I just wanted to suggest what is simply the best for all 
those years ... :-)

I went to wikipedia and it has an IRC comparison chart :)

Jamie, Henrik, if there are bad ops or stupid parts in R2, be sure 
to mention them to those creating R3. Either RT will fix the problems 
or explain why they aren't problems. In the long run, it would be 
a good thing if Orca and REBOL were to be more compatible.

Yes, actually, I'm more in favour of staying close to rebol, even 
with its bugs and deficiencies, to maintain as much compatibility 
as possible.

Agreed.

I just don't see the use of being compatible. I actually see it like 
a wast of time. 100% compatibility means importing the gotchas, the 
bugs, and the problems in certain designs. Like the port system.

Yet my goal is to abandon Rebol, not have a backup tool. If I build 
a tool I want to use it for my own benefit. Not become tied to following 
an external spec.

(at least we know those bugs.)

My approach about cloning "Copy what you like"  http://www.paulgraham.com/copy.html

Again. I taking this as a hobby. I will still pitch in if others 
want to make Orca into a real clone. Any how I still learn something 
which is my goal.

Perhaps switches?

Maybe. But thats a lot of work. When one could just doing something 
new and cool.

It depends of what is the objective. If the objective is to support 
an older code base then compatibility is a must.

If the objective is move forward and have the tool you want then 
that is not so important. Because the fwd port will only need to 
be do once.

All good points, and I respected your points from the start.  The 
other side is true as well, and not actually in conflict with your 
goals, just your time, which is what is most valuable.

Campfire chatroom closed to public access. Please use theOrca  IRC 
channel on freenode instead.

The Campfire room will remain open for private interactions with 
Karl Robillard if you need an account please requested here.

Why don't you use synapse chat?  You have the server and client ...

Can you build that for all platforms ? Is the source open ?

Jaime, this is a deep difference and we need to settle it.  I agree 
it's more exciting being able to experiment and choose new behaviours 
for a language, but I think it's more responsible to support the 
language that we have. We can't just keep jumping from language to 
language. The real hard work is to perfect an existing language.

Will you agree to a real clone ? Then we can move forward without 
forking.

At least the same syntax. not intended breaks like using $ for hex 
because orca will not need money! anyway.

Why are you pushing ahead anyway since you say you have abandoned 
Rebol for plt-scheme and ror?

Jaime said hobby and learning. Maybe we should implement an rebol-interpreter 
in scheme?

What i am curious about, how does scheme handle binding? can i bind 
symbols in data to contexts, and how? I like that for dialects.

I would value Jaime's contributions highly, however, it's important 
that we don't fight each other by pushing different directions.

Sometimes you have to take a big step back to consider the issues.

Rebol exists, and works for most people given what they are trying 
to do.

The cool thing about an open source version is that when someone 
comes across a problem they can fix just that problem (thus offering 
it back to the community).  In theory this could be done in such 
a way that that section of Rebol runs on Orca (for example), while 
the rest runs on standard Rebol.


O Rebol can "choose" to fix these issues (since they would be self 
documenting).
O Orca can branch from the Rebol sheme.
O New features can come into existence by committee.
O Open source die-hards will step up to Rebol

O Some companies are anti-open-source.  Rebol then becomes their 
savior, and thus becomes closed version of itself.

This actually seems like a win/win to me.

yes, but maybe it would be vital, if FINALLY RT would explain a bit 
a plan. We saw documents about more of community involvement, also 
about how some parts will be opened. But what we never saw were details 
to such a plan. R3 is coming. My understanding is, that is should 
make situation much better, as what does not belong to kernel, should 
be kicked off from Rebol, into module/plug-in, call it whatever ...

If we get extensible R3, who needs open source just for the sake 
of open source? The only part closed will be the language itself 
...

but it HAS to work, otherwise I understand the concern of Jaime - 
waiting for fixes months is frustrating ...

Just don't expect me to join Google groups or anything. There are 
far too many disparate communication systems around. I have happily 
standardized on AltME

That's alright, we moved to IRC.

IRC is standard, but when altme is available, I wonder why that choice 
... but hey, whatever works :-)

Reichart, yes, the development of open source rebol clones may just 
allow Rebol to become comfortable with its closed position.

Pekr, AltME doesn't cover all linux platforms yet, so that would 
limit the audience a little bit.

but R2 is already dead anyway. R3 introduces lots of new concepts, 
I wonder if Orca will try to adapt ...