World: r3wp

There are three kinds of importing and two kinds of exporting. Multiply 
those and you have six situations. Hence the complexity budget.

ok I see the difference with the needs vs import.  when you specify 
a needs block, are the exports done automatically in the user context?

or must you still add the import command in your script to have access 
to them?

If you have a Needs header (pardon the anthropomorphism), named modules 
in it are put in the module cache and the words in their exports 
list are resolved to the user context (resolve means copying the 
values to corresponding words in the target context, but not overriding 
existing words). Then the words from the system and user contexts 
are imported to yours, with "import" meaning one of three things 
depending on whether you are a script or a regular or isolated module. 
Then any unnamed modules in the list are imported into your context, 
also in one of three ways. The modules in the list are loaded in 
the order specified (transitively). No explicit IMPORT function call 
needed.

Any overrides other than first-come-first-served can be done explicitly 
by setting the value in system/contexts/user, or in self for mixins.

ok, that is exactly how I understood it.

The code to do the importing is no more than 2 or 3 function calls 
for each method, but study them carefully, as even the order of the 
calls matters. It is much easier to understand and use than it was 
to design, believe me.

don't worry, I know how complex module management is ... I think 
you know why  ;-)

I just recently added a few features to slim and I had a lot of fun 
too :-)

If you use the IMPORT function explicitly, there are some things 
you simply can't do to the calling code because it is already bound 
and running. That is the reason that the Needs header is there. However, 
IMPORT/only just loads the module and returns a reference to it, 
and doesn't put it in the module cache at all. Once you have that 
reference you can do whatever you want with it, including selective 
imports. Some wrapper mezzanines should be made to make certain things 
easier but at this point we don't yet know what needs to be made 
easier :)

Selective imports can include words that the module hasn't put in 
its export list at all - anything that isn't hidden.

yep

And by that, I mean in the *current* R3 module system.

You can choose to import just that list, or none, or go by a module 
reference, or import whatever visible words you want

 - eh, really? I thought that one of the ideas of the module is to 
 prevent user to mess with things. There are two point of views:


1) you debug some code, and your imported module function does some 
weird thing, so you want to debug foreign module. You can export 
some intermediate values from module (well, I am not sure it is best 
debugging method, but it is nice that such possibility is here


2) OTOH - you are a module author. Let's say you have some reason 
to protect your code/knowledge. So what you want is - compressed 
and scrambled source, checksum of code section into header field, 
and precisely defined Exports block of exported stuff = API to your 
module. And please don't push me to use Extensions in such a case. 
I am wondering, if security framework can be expanded, so that you 
can protect module/object, so that its words are not visible or gettable 
in any other reflective way :-)


I of course encourage to use open-sourced modules, but sometimes 
hidding the source and having only API exposed might mean a simplicity 
(user does not always need to look into internal, having headaches 
from thousands of line of code)

Well, I didn't say that it wouldn't be tricky. For one thing, you 
can't do any of that from the Needs header, you have to use the IMPORT 
function, and then it is tricky. Not tricky to do, tricky to know 
what to do or to do right. Hence the need for wrappers around IMPORT 
like the one Janko didn't realize he suggested.

For most developers though, you don't need to do any of this stuff. 
The Needs header capabilities are enough. Any more would be too much, 
leading to overcomplexity and bad design. Unmaintainable code - we 
don't want that.

If you want the security framework expanded, push Carl to fix the 
rest of the PROTECT and UNPROTECT tickets in CureCode.

PROTECT/lock and UNPROTECT/lock in particular.

brian, funny, when you say: "leading to overcomplexity and bad design. 
Unmaintainable code" ... lets just say that for me, its going to 
do the opposite.  cause now, we have to manage the redefining of 
words ourselves outside of the module management operation and out 
of context.


I'll stop talking about modules now, cause Carl wants a model where 
the modules control your script, and I want a model which controls 
modules... so we are fundamentally at odds.  I don't want to have 
to work like we in do C where everything ends up being defined in 
the root context, and we end up re-defining things in header file 
 just so they don't collide with other stuff, but that's what will 
happen and what Carl seems to want.  so be it.  to me that is more 
complicated cause its out of context to where its being used.  and 
it adds a shit load of useless files, dependencies and maintenance.

just so its clear... 


wrt MODULES, I'm not at odds with the work you have done brian, which 
is very clean and well done... I'm at odds with the philosophy itself 
of the module model Carl decided to use.  It doesn't change anything 
wrt to R2's scalability problems, a part from removing paths in DO. 
 that's just my PoV and people aren't obliged to agree with it.  
:-)


python's module management is the best I've used, cause users have 
control, not the modules.  And since its a language based on the 
use of modules, I hoped we would follow that path.  but it seems 
not. what can I say.  

slim R3?  ;-)

Max - so just cut your two messages and paste them to the blog article! 
Carl does NOT monitor this channel.

where can I get the code to R3 chat?  I know where is the data, but 
not where is the source to the whole chat app.

>> source chat
chat: make function! [[
    "Open REBOL DevBase forum/BBS."
    /local err
][
    print "Fetching chat..."
    if error? err: try [do http://www.rebol.com/r3/chat.rnone] [

        either err/id = 'protocol [print "Cannot load chat from web."] [do 
        err]
    ]
    exit
]]

ah, ok, I didn't think it got it from the net at each instance... 
I was going to source the chat func in a few minutes... hehehe

no prob, i like when you ask newbies questions ;-)

Message 3564

hehehe  yeah, I'm always a REBOL newbie a few minutes a day  ;-D

unlike me who is a the contrary a rebol guru a few seconds per years 
:P

Can I get my hands on an early HOST code release for windows?

only Carl can answer that, but so far only a few of us have it . 
  to keep support noise low and freedom of alteration high.

you'll have to ask Carl privately on R3 chat.

any word on when do we expect general availability?

I can do that.  Thanks Maxim.

Pekr, honestly... right now, a part from porting to another platform, 
there is too little documentation and oppeness for it to be very 
usefull to people in general.


I expect a few other platforms to get ported by Carl (he did a linux 
one this week), so he can continue to polish the OS independance 
of the code as much as possible.  


Supporting the extension model on other platforms seems to be a big 
priority.

Once that is done... then one or two rounds of adding "host-specific 
features" to the host and some documentation too.  


A lot of the limits and oppenness of the host is being discovered 
by us... Carl just made it compilable... now our job is to try enough 
stuff and report bugs, limitations,  requirements, suggestions, to 
Carl so the host itself can actually have stuff in it which is meant 
at host-specific features.  


things like: Native R3 callbacks.  host to extension interconnections, 
extensions within the host, device extension hooks, etc.


until the extension model is revised and few more things are added 
to the host, I don't expect the release to be tagged as"release", 
but it might go public.

the licensing also doesn't seem to be completely ironed out.


my humble guess... with the holiday season approaching?  end of january 
he should either be releasing a beta host with a lot more of functionality 
or the current stripped down version, with a lot of testing and a 
lot of platforms now at the same level.


I'd bet on the latter, with a feature testing version in alpha with 
the current crew hammering out tests and architecture discussions 
:-)

how can I check the secure settings in R3? I noticed there is a system/options/secure 
path. Is it related to what I am asking?

secure query

With Host kit how do we role our own R3 code into the builds?

there is a function in rebol-lib.h which is called Reb_Do_String(); 

you could use it to run a bit of code in host-main.c BEFORE this 
line:


 n = (Main_Args.options & RO_NO_BOOT) ? TRUE : Reb_Start(0); // TRUE 
 on halt

there are few other funcs there which are intriguing.



but you can't add native stuff yet anywhere in the host.. for that 
we have to wait for Carl to move the extension code to the host first.

ok, so right now only build the core module and that is all right?

yep, once your IDE is setup it should compile as-is.  it did for 
me, the first time tried.

cool

do follow the instructions here: http://www.rebol.net/wiki/Host-Builds#MS_Visual_Studio

( I'm using visual studio express, which is free, and it works without 
hassle)

Yeah, I got those.  I got studio installed already so I will be building 
it shortly.  I may do it tomorrow.

Max - the first REBOL developer productively moving to R3 :-)

The 2nd.

Cool :-) How's your SQLite driver progressing?

Done. Now adding multi database handling &  SQL statement caching 
and than that's it. Don't have an idea what to add else.

Do yo use lib, or do you wrap DLL? = if you are using lib, you need 
to rebuild extensions for each new SQLite release. But I understand 
that statically linking might be easier ...