World: r3wp

Someone know why we are still using AGG 2.3 from March 2005?    2.4 
still used the BSD license

There are changes in the design, files, and interfaces are made, 
so that, you will have to spend some time for migratintg your applications. 
I tried to maintain is as painless as possible, but still some concepts 
have changed. There some files were removed from the package, but 
not functionality.
 - probably ...

@brian .. what I meant was that many of the C programs I've come 
across use argv, argc in main.  Instead i would pass these parameters 
in the function that is being exported.  Just need to rewrite all 
those c functions that access argc, and argv

Graham: host-args.c -- clean and easy to modify or replace with what 
you need. And special args can still be passed in the arg struct 
if R3 needs it.

Ok, so there's a new R3 sitting here on the shelf drying out waiting 
for some better testing.

Has some useful new ext funcs:

	void *(*make_block)(u32 size);
	void *(*make_string)(u32 size, int unicode);
	int (*get_string)(REBSER *series, u32 index, void **str);
	u32 (*map_word)(REBYTE *string);
	u32 *(*map_words)(REBSER *series);
	REBYTE *(*word_string)(u32 word);
	u32 (*find_word)(u32 *words, u32 word);
	int (*series_info)(REBSER *series, REBCNT what);
	int (*get_char)(REBSER *series, u32 index);
	u32 (*set_char)(REBSER *series, u32 index, u32 chr);
	int (*get_value)(REBSER *series, u32 index, RXIARG *val);

 int (*set_value)(REBSER *series, u32 index, RXIARG val, int type);
	u32 *(*words_of_object)(REBSER *obj);
	int (*get_field)(REBSER *obj, u32 word, RXIARG *val);
	int (*set_field)(REBSER *obj, u32 word, RXIARG val, int type);

Also, the API is now auto-documented -- within the reb-ext-lib.h 
-- including special tips.

So, this will be A101.

To be released once we have a volunteer to write some tests for it.

(And no, we'll not just dump it to the group, because I don't want 
to flood Curecode due to non-tested status. Best to wait on it.)

Carl .. exactly how many posts regarding the hostkit have been made 
to curecode?

I presume curecode has a view filter too

Two ... one in May, and one in April 2010

Call to Community to help us get the next host-kit released:

We need a way to test extensions with each release.


Tests need to be able to handle normal extensions as well as embedded 
extensions (because the difference is only a few #ifdef statements.)

There are a few "dimensions" to test the basic mechanisms:

1. some commands (in a named extension module)
2. commands that use and verify all possible argument datatypes
3. commands that return all different datatypes
4. defining and setting words (variables)
5. accessing values in a block

6. accessing values in an object (new feature, but this is one reason 
why we need the test)

I'm sure there are a few other misc items.


We think that the entire tests can be generated with a REBOL script, 
and save a lot of typing. However, that's not a requirement.

I will release our test-framework, which should be used as base or 
as resulting format.

This is a simple to use test environment that can automatically run 
thousands of tests.

And, of course the host-kit that needs to be tested needs to be released. 
IMO we will release a RC to get feedback on the extension part.

Don't you release and then test?  Isn't this back to front?

What's the reason that the Linux host-kit has not been released yet?

I'm guessing most people are not on windows but other platforms

Really? I think let's first get the Windows version done, than the 
Linux.

Windows is there, so no reason not to use it for testing.

Published the test-framework on www.rm-asset.com

Carl thanks.

Wasn't there one RT's test framework in the past too?

Pekr, yes... RT uses a simple testing framework.

Graham: no, you don't release then test. That's insanity.

The concept of "just upload it" does not work.  Here's why:


1. Parts of the API may not work at all, because of course, they 
are not tested!


2. Parts may work incorrectly... and therefore are just going to 
confuse most developers, and they'll get frustrated.


3. Because the code is not tested, it floods CureCode with tickets, 
most of which should not even be posted there.


4. Without a testing methodology, there will be no consistent test 
suite over time... just a bunch of hacked together code pieces from 
various developers.

btw, I have volunteered with robert, but have not gotten reply yet.


I have client work which deals with extensions and have started some 
extension building automation... 

since this testing goes hand in hand with actual work I'm doing so 
I guess Its logical for me to step up and take the task.

Sold! PS: Robert has another project today.

also posted a private msg to you on R3 re this

Maxim, let me find a direct private channel to you.

ok.

Check R3 Chat. I'll be sending you a few notes.

Check your email.

ok

know what they say....  "carefull what you wish for... you just might 
get it"   :-)

I asked for it  ;-)

@Carl ... I don't think the three or so people testing extensions 
are going to flood anything.

And surely the testing argument applies to R3 ... so where is the 
test suite?

Wasn't testing suite publicly available? http://www.rebol.net/r3blogs/0125.html

I don't recall seeing it ... but in April 2008 I wasn't playing with 
R3

The method seems sound, but I think there could be a problem with 
the quantity of tests generated. Currently, with only five (of 56) 
datatypes tested, there are more than 22'000 test vectors, and they 
build exponentially. We may end up with more than a million test 
vectors for the final suite.

Yup. But that's OK if it's all automated.

yes, let it run for two days... do we really care?

it might even provide other insight on running such a heavy script

Or give Carl the impetus to build a grid/ipc/distribution infrastructure.

Graham, SQLite uses over 2 Billion tests before doing a release.

for i 1 1000'000'000 1 [  insert db {select * from test where id 
= (?)} i ]

The point is that 22'000 test vectors isn't much, and can be generated 
for the most part. We don't have to write them by hand.