World: r3wp

I claim ignorance :)

I claim to never have seen two REBOL filenames that were the same 
- and I'm not talking about version numbers

lol

With every release I have to turn my formal build recipes upside 
down

I was pleasantly (but extremely) surprised that the a107 release 
was stable enough to build a new core with. The a1xx series has been 
really experimental, almost as unstable as other people's alpha software.

R3 host-kits are still very alpha.

Other people's betas are released, like, say a year after their alphas 
- but let's not dwell on that

And I mean formal build recipes for R2 as well

The host-kit has probably changed more architecturally in 3 alpha 
versions than the whole python life cycle.

Is the r3 core lib provided by RT? e.g. r3lib.dll

yes

And less and less of R3 is in it with each release. We are externalizing 
a lot of it into the host portion, where you can see and modify the 
source.

Is there a unit test framework for R3 (e.g. I use CppUnit for C++)?

Ssolie, no.

It is so easy to make unit test frameworks in REBOL that there are 
several. But no official one yet.

well yes there is... RUnit... but its very easy to make your own 
in two pages or rebol.

I'm new to rebol obviously :)

Nevertheless, currently there's no official, published test suite 
for R3.

Not published at least. There is apparently a massive test suite 
for R2 (and possibly R3) that RT uses internally.

And yes, it is in unit test format. We have found that unit test 
vectors are best formatted in the "block of code that returns true 
on success" model.

Remnants of an early attempt at getting something structured going 
for R3 can still be found on R3 chat.

And as far as I understand their are third parties doing internal 
regression testing. Nothing published that i know of, though.

I thought Carl generated a test suite for R3 a few years ago? And 
Ladislav seemed to be executing them

Right now there are so many changes between host kit alphas that 
there tend to be regression bugs with every release. They get fixed.

Ladislav may still be executing them - he's in the development group.

Are there any RT employees that hang around in chat?

Unfortunately (or not, depending on your opinion) the module system 
doesn't have many unit tests. The reason for this is because it is 
written using design-by-contract rather than test-driven-development. 
Once the design is final we will write tests to try to break it.

dbc is orthogonal to tdd

DBC makes most of the tests in TDD unnecessary.

There are people involved with the development of R3 that come here, 
like Henrik and me. Some of the others come by more rarely, to catch 
up or answer questions.

For the to-be-made amiga host-kit, would it be possible to include 
both dynamic (libr3.so) and static (libr3.a) linked r3 core libs?

libr3.a is unrealistic.

For the module system the only bugs that get through are native bugs 
and design flaws. The native bugs are found through testing, the 
design flaws through thought. Actual bugs in the module code are 
caught through tracing, but usually prevented in the first place 
through type tests and explicit error checking.

I think we have a remote chance at eventually getting a partially 
linked libr3.o (which can then of course be wrapped in an .a on it's 
own).

I don't know about Amiga or Win32, but at least with Linux linkers 
it's possible to achieve this in a way that should satisfy Carl.

Why those restrictions, Andreas? Core is a statically linked host 
kit.

Which restrictions?

Yes, but we can't reproduce Core from the hostkit.

I worked on the amiga python port and we provide a libpython.so which 
is what apps like Blender then utilize for embedding python

I imagine rebol will be similar

Yeah, but Python is open source :) Carl is _very_ picky about libr3.

that is what is to be expected.

(reply was for ssolie)

thanks Maxim

just thinking out loud a bit while browsing the host-kit here..

The primary reason there's no OSX hostkit is that Carl has not yet 
managed to generate a libr3 to his satisfaction :)

he says he can't generate a .so on OSX that doesn't export all symbols

strange.. I would think you just disable the option in the linker... 
--export-all-symbols or something?

Yeah, which is precisely what an .a does as well ("exporting all 
symbols", that is) :)

gcc doesn't export all symbols by default but maybe apple made some 
changes