World: r3wp

I also registered my Packager tool for Syllable, written in ORCA:

http://www.ohloh.net/projects/Packager

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.

Found here: http://shootout.alioth.debian.org/

Many years ago that I looked at it, but wasn't REBOL in there with 
a few tests?

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.

It used to be.  Most of the math-intensive ones had been done in 
Rebol, but few of the others.  It skewed the language comparison 
to the "slow" side farther than it should have, since the summaries 
didn't take into account whether all the benchmarks were implemented 
or not.  Don't know if it's changed that part now, though..

Is this ORCA stuff still under active development?

I think not, not for a long time ...

There was a message on the ORCA mailing list yesterday bu Karl Robillard 
annoucing a new incarnation called Boron.


The Boron wiki page is at 
http://sourceforge.net/apps/trac/urlan/wiki/BoronProject

Oh, cool! Enhancements to ORCA have been trickling in over the past 
few years

Boron looks like a complete ORCA reimplementation, so I changed the 
name of this group to reflect that

Wouldn't it be good, if Boron would be eventually designed to plug-in 
to R3 host code?

My lips are sealed :-)

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

It's not as complete as ORCA yet, but the project quality is higher

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

interesting thing this Boron .. what are the main coceptual differences 
to rebol? Does it have a QT binding (it looked so)?

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

I hope Boron is returning to the loose goal of REBOL compatibility, 
but as of yet some things are missing

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

http://urlan.sourceforge.net/boron/doc/func_ref.html

Hmm, 'term-dir instead of 'dirize

because its a specific version of  'terminate

'infuse sounds suspect too

I actually like that function's idea.

'ifn instead of 'unless

funny, those are the two thing I thought where noteworthy.. hehehe

ifn ... very bad style.

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

Need an example of 'infuse...

the way I understand it is:

reduce bind block context

What is the license of Boron? I've been having trouble figuring that 
out from the posted site. Is it BSD-compatible, to allow binary linking?

LGPL

That's compatible with BSD, GPL and many others

Incompatible with R3 though - the host isn't dynamically linked.

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.

No GPL derivitive except Classpath or (L)GPL3 can be encapped, for 
instance.

Legally, I mean. You can't encap (L)GPL 2 code.

Extensions are compatible with LGPL, but not statically linked or 
bundled code.

Too bad - Boron sounded promising.

their argument will be that its rebol that is evil, cause its partially 
closed.   but right now I don't really care.. there are a lot of 
nice things comming for R3.

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

There' s no problem with encapping LGPL code. You just have to deliver 
the object files that allow the receiver to reproduce the encapping

The host is currently statically linked to the kernel (afaik). Most 
host builds will be statically linked in any case.

That would be very bad, not just license wise, but also in terms 
of system performance

Why? Dynamic-linked function calls are slower.