AltME groups: search

I think so. I think Reichart set up a custom script just for Rebol3 
world, and hasn't generalised it into a release version of AltME 
yet.

But back to the question: Is Win32, MacOSX and Debian Linux enough 
for now ? Are all current orca developers covered by those supported 
platforms ?

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

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.

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.

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

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.

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

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.

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.

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.

I expected exactly such a reaction, just waited for it to pop up 
:-) I am talking about focus/orientation .... all the potential of 
RT goes to R3. Judge for yourself, if Orca should, and for how long, 
to focus on R2, respectively to add new features, before we know, 
what RT gives us ...

Anton, I don't see contradiction between your goals and my goal.

Sounds good, but how about this case: 
	foreach v [1 2 3] [ ]
in rebol currently returns unset!
in orca returns 'v

It can be argued that this is a small useful improvement that doesn't 
interfere with rebol code. I would prefer, however, to change it 
back to the rebol way because there may be times (possibly very rare) 
when some code relies on this behaviour and is broken by the change. 
How do you see this case ?

Kaj, and anyone else new to the discussion, I'm trying to get a consensus 
on the future direction of Orca. It is a divergence from Rebol, as 
stated on these pages:
http://trac.geekisp.com/orca/wiki/OrcaProject
http://trac.geekisp.com/orca/wiki/OrcaBehavior

But I would like to steer it back to Rebol. Actually, since Orca 
needs a name change, it's probably better to fork and do a big name 
change, probably to something like OpenRebol or ORebol. What do people 
think about that ?

I think it's wise to fork Orca, to be clear about the name and the 
direction it's going.

And the easiest way for that is add the missing natives and mezz.

Once the all the natives and mezz are completed then we can talk 
about enhancements.

Ok, so we can pool our resources and leave the arguments til a later 
stage.

Life is funny for months, I encourage people to work on Orca, when 
KarlR and myself decide to quit, we get new fuel. Funny.

It doesn't matter now, Orca works, it is just missing completeness 
in natives and that I the port system.

Pekr, another reason is shyness and desire of learning only. So they 
avoid any legal problems. However I don't see how a clone can have 
legal implications. It is not like we are copying the src code, and 
re-engineering is allowed.

He hangs on and engages the community

On the interest in Orca. As I mentioned before, Orca is included 
in Syllable 0.6.1. In that form, many thousands of copies have been 
distributed already all over the world. We're currently up to about 
4500 downloads of the install CD, so those would presumably be people 
really running the system, 2300 live CDs and an unknown number of 
VMware images, which have been very popular in the past. It's also 
in the shops on the DVD version of Linux Format magazine. I don't 
know how big the DVD part of its circulation is, but it must be many 
thousands

Now not many of those Syllable users would currently be using Orca, 
but starting with the next Syllable release I am writing and rewriting 
system tools in Orca, so basically all future Syllable users would 
be using Orca. The next step of course is to make the developers 
among them aware of it

Seeing that the Orca Campfire chat is now closed, some people here 
would like an Orca world and I'm running a number of AltME worlds 
anyway, I started one. If you would like an account, ask me here, 
or log in as guest. The world name is Orca and the guest password 
is guest

And that suggests that we are a competitor

The other issue is that Karl is continuing with Thune. That's going 
to be the first place to get code from to integrate with Orca, and 
that would make it LGPL again

Karl's other language, still similar rebol to but more divergent 
(and newer) than orca.

The only way would be to maintain an LGPL-free core and a version 
with LGPL-libraries. But that doesn't solve the issues with the BSD 
core and it starts looking a lot like a fork

You could ask Karl and I expect this issue will be settled quickly...

I don't support GPL in any way, that is a bitch license. LGPL I don't 
know about. But if RT releases some parts, I hope those are BSD. 
And if Orca can serve for REBOL back, that is a strange situation 
to have ....

business should be allowed ... and to allow business, you should 
not push anyone to unwanted/unrelated actions ....

Maybe someone else will come along with a BSD rebol clone one day, 
but Rebol and Orca being at opposite ends of an axis is not a bad 
situation. Nicely balanced.

They work for and against each other in different ways. If it is 
changed from LGPL to BSD then there will be other restrictions, but 
also other advantages.

Anyone with any experience with Jabber clients ? I just tried using 
Psi to create an account on jabber.org without much luck. (a possible 
problem with certificate and unresolved host error.)

I collected some links for Orca's scattered resources in the Orca 
world and wrote a how-to for compiling it

No, and I'm not at all sure SWIG bindings would be the best solution 
to interfacing with external libraries, for Orca

SWIG bindings are one-to-one bindings, mapping a C library call to 
a function in the high-level language. This disregards the richer 
ways of expression that are possible in the high-level language. 
As we know, REBOL is especially powerful, and I think it would be 
better to write bindings in a more suitable way

I think the best way in REBOL is, as usual, to design dialects on 
the abstraction level of the user, and implement them in terms of 
the available C libraries. This is what Orca does so far with Qt 
and OpenGL

Yes, I suppose there would be a big difference between compiled and 
interpreted languages

I am continuing with Orca in Syllable, and I will make improvements 
to Orca where I can and need them. A few other people have expressed 
interest in development as well

Kaj send me you diffs and I will post the changes.

Diffs. I mean load the current base from the repository and generata 
a universal patch using the diff cmd on the two copies. Then we can 
check changes one by one.

I'm reading Ubuntu 6.06RC release notes and here's this:

ORCA

Replacing the venerable Gnopernicus is the new Orca, a scriptable 
screenreader for the GNOME desktop. Expect some great things from 
this in the coming months and years. Best of all, it is written in 
Ubuntu's favourite language, Python.

Hm, that's not OUR orca :( BTW, what is its current status?

I'm working with Orca on Syllable. I've identified a number of bugs 
and missing features that I will work on first when I start developing 
Orca itself

There were a few unreleased bug fixes for Orca and QUIT/RETURN was 
implemented recently, so I made a new release and put it on FreshMeat:

I released new source and binary packages for ORCA:

There's a binary for Linux, and this new version is also included 
in Syllable, starting with Syllable Server 0.2 that I just released

Several small fixes and enhancements were made to ORCA over the past 
year, which these packages roll up

Are there any performance comparison tests between ORCA and REBOL?

I once did a few simple tests and found ORCA to be generally somewhat 
faster than REBOL 2 in basic processing. Both of them were at least 
twice as fast as Ruby

I found the Computer Language Benchmark Game a few weeks ago. Could 
be interesting to make REBOL and ORCA versions of those benchmarks.

I don't see REBOL in there. I've only known about that benchmark 
a few weeks, so REBOL could have been there earlier and later removed 
from some reason.

I ported Boron to Syllable, both Syllable Desktop and Syllable Server

It has a shared library instead of a static one, and PThreads integration

ORCA has the bindings and Boron was started specificaly to update 
them, so they should work already

There's a new word reference that shows status and compatibility:

And a few that've been truncated. Doesn't seem like a good road to 
go down.

That's compatible with BSD, GPL and many others

This is why I said that I would be OK with Boron if it wasn't divisive, 
like Orca. It can't use Orca's license and succeed.

If Boron changed to Classpath or BSD/MIT then there would be no division 
of labor between the Boron and REBOL communities.

The R3 host isn' t dynamically linked? In the original plan, we were 
promised both static and dynamic libraries

A little, but you get to load the entire environment over and over 
again for each, possibly short-lived, REBOL process you start

This eats memory and startup and teardown time

I am well aware of the situation, except for the parts that we have 
been unable to know in all those years, such as the eventual license 
and software configuration

I will not get into the anti-divisive properties of the LGPL and 
GPL here

I was just trying to figure out a way to endorse Boron and say that 
it is good for the REBOL community. Sorry.

No, I have always planned on the basis of a shared library, which 
is standard practice and was promised

Syllable is an open source project and was always clearly presented 
as such. We do that for one overriding reason only: to never get 
in the Atari/Amiga/RiscOS/BeOS situation again, where commercial 
entities destroy your platform

Kaj, do you realize that the entire host and kernel combination could 
be a shared library? That would solve your startup problems without 
the performance hit. Or you could split your host into platform-abstraction 
and platform-integration portions and then dynamically link between 
those parts. It's just putting the split between the host code and 
the kernel that doesn't make sense.

I say that there will be no dynamic split between the host and kernel, 
for practical reasons (performance drops like a stone). I don't say 
that you can't make a statically linked host and kernel into a dynamic 
library that other things can link to.

so once we have the host and Carl realized that he'd waste less time 
giving us a bit more control, there is a chance for a bit more core->host 
migration still.

anyhow.... Boron is interesting, I hope there will be a way to bridge 
it and R3 at some point.

Concerning the license, there' s no need to be alarmist. If contributors 
work under BSD, both R3 and Boron can use it

Nick, I think R# and ORCA also had Windows binaries many years ago

Just wondering what you can do with a clone that has no ports ... 
can it read and write files?  Do cgi ?

Of course, ORCA has been able to read and write files for years, 
and that's what I use in Syllable. And when it can do that, or just 
print to standard output, you can also do CGI with it

ORCA was quite REBOL compatible. There was an intermediate project 
Thune that was much more Forth like and not compatible. Boron has 
prefix syntax again but is less compatible than ORCA

Yes, it's Karl, and he has a mail address and mailing list at SourceForge

There has been a continuous line of development over about half a 
decade from ORCA via Thune (and Rune) to Boron. Boron is the newest 
and the only current project

Not much is needed for CGI, so I'd guess it's possible. ORCA had 
a getenv function to get the environment variables and so does Boron, 
I guess

As it stands, Boron seems reasonably capable of processing strings 
and lists - I could certainly have a go at writing some useful stuff 
if CGI were possible.  I'll send Karl an email...

Right  now I'm very excited to be playing with a working open source 
REBOL implementation in Windows :) I wonder what dependencies it 
has, and if it can be compiled to run on Windows Phone or any other 
potentially useful operating systems.  Even just for simple file 
managment and text processing, it would be really cool to see this 
running somewhere where real REBOL isn't currently available.  And 
since it's open source, there's potential to expand it's capabilities.

Porting it to other platforms shouldn't be hard. I just compiled 
it on Syllable and that was it

I want to try to compile ORCA for Windows too - I tried briefly once 
in the past, but ran into problems and didn't have time to play with 
it.

Yep (and there's a devpak for the BZip2 library :)

I had a quick look at Boron and at second look I got the impression 
that it can be a real alternative, if  R3 does not move faster.

Has anyone a project file for Codeblocks and Boron under Windows 
or some hints how to do it?

i think all you should need to do for that on windows is fire up 
cmake gui and select the boron directory

Kaj, thanks for noting that standard input example - it is new.  
In June, Boron's user manual version was 0.1.2 and the windows release 
was 0.1.4.  It's really encouraging to see work accomplished :)  
I donated a small amount back in June to Karl using the paypal link 
- if he's motivated by money to do more work, I'd support that without 
reservation.  I don't have much time right now to explore much, but 
I'd love to see a continuing active open source alternative.

It only starts, if I go into the bundle and start the boron-gl executable 
manually.

I don't know how that works on OS X. I only know that it just works 
on other Unixy systems such as Linux and Syllable

A bundle is simply a directory, which contains specific directories 
and has a specific icon. OSX recognizes such directories as applications. 
Inside are libraries, icons, images and executables of various CPU 
platforms. The user then sees the directory as an application, which, 
when double clicked, automatically runs the correct executable inside 
according to CPU platform. You're not supposed to go inside a bundle 
to start the program.