World: r3wp

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.

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

If the shared library is withdrawn, that' s very bad news

Do you realize that most of R3 will be open source? The static linking 
is just for performance.

I was just hoping that Boron would choose a permissive license instead 
of a divisive one.

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.

It was originally thought that the kernel would be dynamically linked, 
but the performance of that was so bad that static linking was the 
way to go. It will still be refined in any case.

A large portion of the code in R3 will be in the host code, so having 
a dynamic linking break there won't give you as much benefit as simply 
marking pages as sharable or something.

Is that official?

When you consider that all of the platform-specific code is in the 
host, it's obvious.

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

I' ve been trying to do the very same thing defending REBOL in all 
those years, for example in the Syllable project. It's very hard

If it turns out that more broken promises make R3 unusable for me, 
my only saviour will be Boron

I will have been made to wait for half a decade for nothing

We'll see. I didn't know that Syllable was open-source only - I was 
keeping it in mind as a platform to be supported. By hybrid-source 
builds, but still a planned target platform. I'm sure having Boron 
as a R3 kernel replacement would be possible, as long as it is license 
compatible.

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 know that Syllable is itself an open source project, but I thought 
that you would allow close-source applications to run on it. Especially 
freely distributable ones.

Yes, applications. By considering closed system components I am treading 
a very fine line. We can never make the base system dependent on 
closed components, for the very reasons we are discussing now

I always presented REBOL as our cross-platform strategy. As such, 
I have defended part of it being closed