World: r3wp

the version 0.6 ref document is here: 


http://www.pointillistic.com/open-REBOL/moa/steel/liquid/plug/plug-reference.html

>> do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=liquid.r
connecting to: www.rebol.org
Script: "LIQUID - core dataflow programming engine." (4-Feb-2007)
** Script Error: slim has no value
** Near: slim/register [

this is not a bug... liquid is a slim module.  you must have slim 
loaded first

the quickstart explains how ... its VERY easy.  ;-)

Why can't you just do this:
do %slim.r
do %liquid.r
?

Surely that would be more rebolish ?

But the launching of programs is something to be thought about deeply...........

these are managed modules.

slim is not about loading code.  'do does that.

slim is about managing the internals ... both technically and politically. 
 its about providing a unique and consistent code model to allow 
tools to wrap around this.

we could probably wrap the code in the way you specify. but then, 
slim allows you put your code anywhere...

so the above would not work.

so while people have been waiting 5 years for the promise of modules, 
I have been using them.  and when Carl released his spec... I did 
85% of it in exactly the way he suggests.  even in some details like 
'exposing code.

so I don't wait, yet am very "rebolish" ;-)

obviously its not perfect, obviously I can do code protection, but 
then, Im alone, people want to do their own... so they can always 
do so.

Robert tried slim and in 15 minutes adopted it.

Are you saying you can't do that ?

do what?

do %slim.r
slim/open liquid 0.6.4

oops  typed a bit too quickly...	

do %slim.r
slim/open 'liquid 0.6.4

So that's all that's needed ?

A problem with all these different module managers and include systems 
is that there is ignorance of what they actually do. When you post 
code like the above, I have no idea what it's going to do with the 
files, how they are going to be arranged on my harddisk etc., and 
what global words are going to be defined.

My old INCLUDE system and the new one I've been working on also suffer 
from this "gap of understanding".

I think the answer is a GUI option which shows in clear diagrams 
what is going on.

my library engine is fully documented for 3 years now.  a FULL reference.

No, I mean the diagrams form part of the GUI (when a "show GUI" option 
is selected).

Anton, that is the POINT of slim... you control everything !

the library is not allowed to share any information in global space.

Except you don't know how it works except by going to read the documentation 
first.

the module user exposes on demand, and even the context is unnamed, 
you assign it.... the above again misses code... man  its 2AM here 
I am sleepy.

I am saying it's better for us to integrate a clear image / animation 
of what's about to happen, and what's happening, within the user 
interface.

oops  typed a bit too quickly...	

do %slim.r
liquid: slim/open 'liquid 0.6.4

what user interface?

A GUI, when a hypothetical "GUI" option is chosen.

>> do %slim.r
'slim is defined, no choice about that.

you mean to install libs?

Yes, hwo files are managed should be clear.

slim lets you put files where you want (in many dirs if you want) 
and even allows loaded-lib relative resource dirs.

if I say that a gui manager was needed... every reboler on this list 
would complain that its too complicated and would be scared that 
the lib manager does things behind the scenes.

hehe.

wrt the slim word... you can rename it in the slim.r file if you 
really want to... but its your call.

Would it work, though ? I would have to do some investigation to 
see if it would work. Something I would rather not have to do.

must go, later.

ciao.

ok...i have briefly read the documentation on slim up to 2.5.  I 
have limited experience with rebol, so I'm trying to get clear on 
what problem it solves.

If i understand correctly slim allows you reuse libraries or modules 
in other programs by opening them as opposed to cutting and pasting 
the module into the rebol script?

its more like what value it adds ;-)  but the core featues are:
-loading external code, but in a managed way

-path resolution, allows you to put libs in one or many folders, 
a part from code and reuse.
-version verification.

-enforcing of a standard, where all the code is wrapped in one context 
and the use of 'set is illegal (nothing gets bound to global context)

-allowing the user of a lib the choice of exposing what words he 
wants in his code.

and even automatic renaming of exposed words.

and many more features, like vprint, engine for advanced management 
of verbosity and powerfull indented tracing of your code.

if you only want to use slim for testing out liquid, I suggest to 
follow the quickstart, it should get you started in a few minutes 
without fuss.

ah... just wanted to announce a little milestone of liquid useage 
 :-)   In the current instance of liquidator, event handling and 
window refresh have been successfully decoupled  :-)  this means 
I can refresh based on a timer, instead of based on input events... 
 so I can now properly scale interactively of the view based on its 
weight without even removing one event from the view  :-)


you'd say... but we can already do that... well not exactly... yes 
 you can prevent the call to 'show in your mouse handling... but 
can you prevent the whole processing occurence when you are interactivally 
editing an item?  hehe .


because of liquid's lazy computing, the actual processing is delayed 
until needed, and the show will only occur after this.   so I can 
call update 30 times a second, and it will still only call show when 
things have realy changed, inversly, I can change the data 100 times 
a second, and only the real number of calls to update will actually 
cause a data refresh of all dependent data which changed (like the 
draw block :-)

Do you mean something similar to this ?
	if data <> old-data [
		update-draw-block
		show window
	]

that is the concept, but liquid will know about any atom of data 
which needs to refresh, and will only recompute what HAS changed, 
so in the example you give, not all draw element will actually get 
refreshed, probably only one or two, and then, the draw block is 
relinked... the smarter you are within the processing (as usually) 
the faster will be the refresh rate.