World: r3wp

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 ...

Robert - you know what was missing in R2 SQLite driver? Collation 
support. We (me, Ashley) tried to find out, how to use it, but were 
not able to wrap collation routine in R2 DLL interface.

I use the static lib and compile everything into one DLL.

Update for new SQLite verison is simple.

Collation: Not looked at it yet. I have never needed it.

so you don't need to correctly sort in German language?

Well... ;-) Yes, I do.

Will take a look.

I think the instructions for the Visual studio host kit instructions 
needs to be modified a bit more.  I'm a newb to Visual Studio but 
found the instructions confusing for the adding of the additional 
files and for finding the "additional include directories"