World: r3wp

For instance, in the AGG wrapper the commands that are used to implement 
the Draw dialect are exported in their own context rathar than globally, 
because they aren't meant to be called directly as functions. Other 
APIs may need to do the same thing for similar reasons.

In a lot of cases you want to make commands at the marshaling boundary, 
and make REBOL wrapper code that you export. REBOL code can encapsuate 
a lot of functionality, whether you are doing so in an object type, 
a scheme or a dialect.

Back to the name..  what if I export System extension context into 
main context, where is already System defined? Now it looks it just 
silently do not overwrites the existing one.. shouldn't it throw 
an error?

If you are just exporting the native API then make the extension's 
module private rather than public, and just import the extension 
into the module that provides a simple REBOL-like public API for 
others to use.

The current build doesn't have most of the security protections implemented. 
We want to fix the *many* protection bugs first.

So do you want me to add CC ticket?

There already is one.

For that matter there is a message warning about this problem at 
startup of 109 and 110.

ok.. fine... so do you think I can safely use 'system' like exported 
names and believe, that if someone want's to use the extension, he 
will imported like:
	fmod: import %ext-fmod.dll
to avoid conflicts and not:
	import %ext-fmod.dll
?

fmod: import/no-user/no-lib %ext-fmod.dll

That combination was Carl's suggested replacement for the /only option. 
More fine-grained control.

Keep in mind that exported words that are predefined are not overriden 
by the export process. Your export of the word 'system will not change 
the setting of the word 'system in the user context. In order to 
change that you need to assign it manually. Word precedence is first-come-first-serve, 
so even if the 'system word in the user or lib contexts is protected, 
there will still be no error triggered because the export was going 
to just silently not work anyways.

The protection of the system words (that isn't working at the moment) 
only affects explicit assignment.

Yes, but we should be warned when you are trying to import word into 
context where the word already exists.. it looks that now it just 
silently does nothing, which could lead to suprices later.

It's only a surprise because the module system is not particularly 
well documented at the moment. The override policy is very consistent.

Documentation will not help in cases where you have unexpected name 
conflict.

There will always be a name conflict somewhere. That is why we have 
an override policy. Of course anything unexpected will be surprising, 
but in this case the unexpected thing is that there was a name conflict 
in the first place, not the behavior of the system in reaction to 
the conflict. That is of course assuming that the developer has read 
the docs, and that we have written them, neither of which I am really 
assuming at this point.

But the module system has had a first-come-first-served policy for 
a couple years now, with manual overrides if need be.

I tried all of the possibilities, and that is the policy that grants 
the greatest flexibility and control to the end-developer with the 
least code, and the least surprise. We even tested this with third-party 
developers and code bases. Given the REBOL language, it's the best 
policy.

Strangely enough, the whole point of the lib runtime library is to 
manage overrides. That is why we don't have explicit import by default 
too.

this is my pet peeve of an automatic export system (in any language). 
 the "user" of a lib isn't the one managing the possible clashes 
and he has no control over it, because the design makes exporting 
things the default behaviour. 


to protect from this, people then have to start prefixing their tools, 
and the readability of source code then is reduced.


currently when I use R3 modules, It feels very much like I'm doing 
#includes in C but I get no warning that I'm potentially introducing 
a nameclash.

Well, in R3 exporting things is not the default behavior: The module 
maker has to explicitly mark something to be exported, and even then 
if there is a name clash the export doesn't happen. Plus, all exported 
words are right there in the module header (even the keyword-exported 
ones) so you can check for conflicts if you like.

So it's more like #include with every define wrapped in an #ifndef 
(is that the word for "if not defined"?).

REBOL doesn't have a "warning" mechanism at all, it just has an error 
mechanism. Warning mechanisms are really awkward at runtime - that 
is why you only see them in compilers or applications with runtime 
logging. And only the latter would apply to us. We have been talking 
about making a binding lint tool for R3 though, and that could easily 
generate such warnings.

(#ifndef, yes)

Is it safe to have a command without arguments return a value? Is 
there a return slot reserved anyway in the arguments frame?

the return slot is the first argument in the frame.  AFAIK the argument 
frame is always the same size no matter how many arguments to actually 
supply (0 to 8)

Ah, OK, safe then. That makes that combination a lot easier

Is there any example how to deal with objects? Especially how to 
create objects on C side.

I've found it.. I must use RL_SET_FIELD macro... but it requires 
to define all posible words.

After importing an extension, I consistently get a REBOL error if 
I allocate any non-trivial amount of memory afterwards:

>> import %./sample.so
>> array 100'000 
== REBOL System Error:
REBOL System Error #1207: assertion failed

Happens for my own extensions on both Win32 A110 and Linux A110. 
Also just tried it with Kaj's cURL extension, same problem.

Anyone else seeing this?

== REBOL System Error:
REBOL System Error #1207: assertion failed

Program terminated abnormally.
This should never happen.
Please contact www.REBOL.com with details.

Linux A110?

Yes

Thanks, I'll report it as bug.

Looks noteworthy :-)

When I go beyond 14 commands, importing segfaults. I thought people 
had made extensions with far more commands?

I don't see none of these these problems with my FMOD extension.

I'm on XP only.

Maybe you do something wrong in your extension.

Just tested your extension attached to CC (sample.c) and I cannot 
repro the assertion as well.

Thanks for testing, Oldes.

Would you mind mailing me your resulting .dll?

And what compiler did you use? GCC or MSVC?

gcc (GCC) 3.4.5 (mingw-vista special r3)

Would you mind trying the following:
http://bolka.at/2010/rebol3/tmp/sample.dll

works

Ok, so works on XP, fails on Linux and Wine. Will try Win7 later 
on.