AltME groups: search

I wouldn't build stemmer into search engine .. keep it slim :) .. 
In my case with solr I  process the docs before I index them and 
then I do the same to search queries .. it's all outside of solr..

>> do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=glayout-demo.r
connecting to: www.rebol.org
Script: "GLayout demo" (31-Oct-2006)
Script: "SLiM - STEEL | Library Manager" (14-Jul-2004)
** Script Error: Invalid path value: find-path
** Near: unless slim/find-path %GLayout.r [

    either confirm "GLayout not found. Download it from Rebol.org?" [
        either ...

following discussion from ann-reply :
Pekr: 

>> do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=glayout-demo.r
connecting to: www.rebol.org
Script: "GLayout demo" (31-Oct-2006)
Script: "SLiM - STEEL | Library Manager" (14-Jul-2004)
** Script Error: Invalid path value: find-path
** Near: unless slim/find-path %GLayout.r [

    either confirm "GLayout not found. Download it from Rebol.org?" [
        either ...


hum, looking at the date besides your slim install... its a very 
old version!  I guess you had tried it out a few years back and still 
use the same rebol install or user.


just delete the slim.r file and the demo script will download it 
for you again.

my view is that choice is the right answer.  use what makes sense, 
import, slim, include.  I have an even higher level than include 
with distro-bot.  but still use do directly often.

and since we can build modules dynamically, I guess that we could 
do like slim and embed the dynamic version of the module within the 
source code directly.

not anymore... I'm not setup for this anymore... unfortunately, I 
don't have a lot of time tonight... I have to test cheyenne and start 
putting my web site back online in order to get slim, glayout and 
liquid  "out in the open".

Isn't what slim does ? Holding paths for code library (scripts) and 
allowing to just slim/load %script-name.r where the file is in one 
of the folder in slim path !!

I mean Maxim's Slim !

I have been toying with the idea to add system environment variable 
support in slim for the path resolution  :-)

Max prefers his Slim, I know

BTW, Max: how old is the newest Slim version?

slim is practically the same as module in philosophy, and in many 
areas the same functionaly too.

I use slim and prebol together within the sdk, it works very well. 
 I should use %include.r though, its much better and would solve 
a few little complexities I have with using the prerebol.r

and slim, which has the same dynamic and static linking capabilities.

pow!  all fixed  :-)  just need to let slim  build the new release 
from all the included files and we are set !  I will also be doing 
just a little bit of cleanup within GLayout to reduce the size of 
the final single-file app...

wrt slim, people might say its not documented... well, it was all 
documented on the web for a long time... but that didn't change anything. 
 And I can't be the only one providing all the answers for such a 
community oriented project.  Other people have to jump in.  The list 
of advanced features within slim is too long to list here, but it 
has many things even python coders wish they had.

I am not talking about adopting slim as it is.  it maybe too full-featured. 
 but we need a common reference.  and people underestimate how Carl 
perceives the work done by the community.  If the community tends 
to its own. and creates a precedent... I know Carl will be only too 
happy to work in the same direction.

if you download the glayout demo, it will download the glayout and 
slim, for you..

Rebolek, like many other options, things like save/jpg may not need 
to be included in the default slim installation of REBOL, but I'm 
sure there are many users who would love to have the option of downloading 
a 100k+ library, function, plugin, etc. to easily enable this functionality. 
 I don't care if I have to download and do some code, that's trivial 
- just having the option available would be phenomenal.

Sort of like an appliance...


The perfect setup would be to boot into a slim xwindows environment 
with no or minimal wmanger running my app but have  key combo at 
start up to boot into full linux desktop

>> path-thru http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=slim.r

== %/D/Anton/Dev/Rebol/View/public/www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r%3Fscript-name=slim.r

>> load-thru http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=slim.r
connecting to: www.rebol.org
connecting to: www.rebol.org
== [
    SLiM: make object! [
        id: 1
        slim-path: what-dir
        libs: []
        paths: []
        linked-libs:...

>> exists-thru? http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=slim.r

== %/D/Anton/Dev/Rebol/View/public/www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r%3Fscript-name=slim.r

about JS libs:

I don't use jQuery .. it's oweblown for what I want (I don't need 
it to reinvent javascript). If I need any complex components like 
datepicker (which I don't want to reinvent) I use mootools usually 
(because you can use just needed parts of it). jQuery UI modules 
(which has this) are very very slow and CSS is so complex I don't 
even start to get it how to customize it.


Dojo always seemed this mega lib that I don't want either. If I go 
to their demos (at least last time I looked) everything is slow and 
unresponsive. I want my things to be slim on code and snappy.


Prototype (mootools does this also, but I think a little less) is 
first generation JS lib (that started it all). I think it heavily 
monkey patches the core JS/DOM objects.. thats why I don't like it.


I also neve use css3 selectors in my JS code (that is a major part 
why people use jquery and likes). I always move relative to an element 
with seekFwd, seekIn, seekOut, seekBack fuctions I have or just use 
ID of element (and then seek if needed).

There is finally a script to demonstrate some of GLayout's current 
capabilities.

the demo script will download and save slim and glayout on its own 
(asking first), hands free, no obscure installation needed.


do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=glayout-demo.r

STEEL web site - tools for REBOL is now moved and completely refreshed.


currently has up to date information on liquid, slim  and reTools. 
 Will be uploading some GLayout docs next week.

GLayout demo 0.9.1 Released:
------------------

-auto-updates latest version of GLayout (as per slim requirement).

-new layout using switchpad (btw, switchpad automatically adds a 
right-click popup to select panes)
-takes advantage of new GLayout features.

-improved input field filter example, now properly reacts to caret 
offset (cursor)
-better button and field options examples
-adds center style examples.

do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=glayout-demo.r

is there anything to try already? How does it compare to Maxim Glayout 
or how is that called? Or Slim, or Steel? Never know what Maxim's 
names, terms etc. mean :-)

I'm using SLIM to handle some module loading.

Here is a short example when it fails:
rebol []

;--- Startup
if system/product == 'Link [

 attempt [call reduce ["d:\rebol\view\rebol.exe" system/script/header/file] 
 quit]

 attempt [call reduce ["c:\programme\rebol\view\rebview.exe" system/script/header/file] 
 quit]

 attempt [call reduce ["c:\rebol\view\rebol.exe" system/script/header/file] 
 quit]
	quit
]

;-- use xpeers framework structure
link-root: first split-path system/script/path
link-root: copy/part link-root index? find link-root "/xpeers/"
append link-root %xpeers/
do link-root/framework/anamonitor300.r
do link-root/framework/slim.r

;-- RebGUI stuff

#include %rebgui.r unless value? 'ctx-rebgui [do link-root/framework/libraries/rebgui.r]

;-- SLIM stuff
slim/open 'debug none ; [mark-my-words]
; mark-my-words/init

unit-size: 4
font-size: 12
tab-size: 120x55

display/min-size "CalcIT" compose/deep [
	label "Land"
	drop-list 60 data ["A" "B"] return
] 1024x768
do-events
halt

If I comment the slim/open... line it works.

this is strange...  here is a stupid first  test, try to call rebgui 
after slim... does that change anything?

I just want to share my modifications of the chat widget in b177, 
I needed a slimmer chat. It should also fix the resize issue:
REBOL []
slim-chat: make baseface [
	options: {
		USAGE:

   chat2 120 data ["Bob" blue "My comment." yello 14-Apr-2007/10:58]

		DESCRIPTION:
			Three column chat display as found in IM apps such as AltME.
			Messages are appended, with those exceeding 'limit not shown.

		OPTIONS:

   [limit n] where n specifies number of messages to show (default 100)
			[id n] where n specifies id column width (default 10)
			[user n] where n specifies user column width (default 15)
			[date n] where n specifies date column width (default 25)
	}
	size: 200x100
	pane: []
	data: []
	edge: default-edge
	action: make default-action [
		on-resize: make function! [face] [

   poke face/pane/2/para/tabs 2 face/pane/1/size/x - sizes/slider - 
   (sizes/cell * any [select face/options 'date 25])
			face/redraw/no-show
		]
	]


 height: 0 ; actual pixel height of all messages (-1 ensures first 
 message is offset to hide it's edge
	rows: 0 ; number of messages
	limit: none ; last n messages to display

	append-message: make function! [
		user [string!]
		user-color [tuple! word! none!]
		msg [string!]
		msg-color [tuple! word! none!]
		date [date!]
		/no-show row
		/local p y t1 t2 t3
	] [
		;	cache current tab stops
		p: self
		t1: pick pane/2/para/tabs 1

  t2: pane/1/size/x - sizes/slider - (sizes/cell * any [select p/options 
  'date 25])

		p: self
		;	get height of message
		y: max sizes/line 4 + second size-text make baseface [
			size: as-pair p/size/x - sizes/slider + 1 10000
			text: msg
			font: default-font
			para: para-wrap
		]

		

		insert tail pane/1/pane reduce [
			make baseface [
				offset: as-pair -1 height - 1
				size: as-pair t2 21
				span: all [p/span find p/span #W #W]
				text: user
				edge: make default-edge [size: 0x1]

    font: make font-top [color: either word? user-color [get user-color] 
    [user-color] style: 'bold]
				color: either word? msg-color [get msg-color] [msg-color]
			]
			make baseface [
				offset: as-pair -1 height - 1 + 20
				size: as-pair p/size/x - sizes/slider + 1 y
				text: form msg
				color: either word? msg-color [get msg-color] [msg-color]
				edge: make default-edge [size: 0x1]
				font: default-font
				para: para-wrap
			]
			make baseface [
				offset: as-pair t2 - 1 height - 1

    size: as-pair (sizes/cell * any [select p/options 'date 25]) + sizes/slider 
    + 1 21
				span: all [p/span find p/span #W #X]

    text: form either now/date = date/date [date/time] [date/date]
				edge: make default-edge [size: 0x1]
				font: make font-top [style: 'bold align: 'right]
				color: either word? msg-color [get msg-color] [msg-color]
			]
		]
		height: height + y - 1 + 20
		if ((length? pane/1/pane) / 3) > limit [
			y: pane/1/pane/2/size/y + pane/1/pane/1/size/y - 2
			remove/part pane/1/pane 3
			foreach [u m d] pane/1/pane [
				u/offset/y: u/offset/y - y
				m/offset/y: m/offset/y - y
				d/offset/y: d/offset/y - y
			]
			height: height - y
		]
		unless no-show [
			insert tail data reduce [user user-color msg msg-color date]
			pane/1/size/y: height
			pane/3/ratio: pane/3/size/y / height
			show p
		]

  show pane/1 ; !!! this cleans up artifacts but "eats" other widgets 
  redraw events !!!
	]


 set-user-color: make function! [id [integer!] color [tuple! word! 
 none!] /local idx] [
		if any [zero? id id > rows] [exit]
		poke data id * 5 - 3 color
		if limit > (rows - id) [

   idx: either rows > limit [(id + limit - rows) * 3 - 2] [id * 3 - 
   2]

   pane/1/pane/:idx/font/color: either word? color [get color] [color]
			show pane/1/pane/:idx
		]
	]


 set-message-text: make function! [id [integer!] string [string!] 
 /local idx] [
		if any [zero? id id > rows] [exit]
		poke data id * 5 - 2 string
		if limit > (rows - id) [

   idx: either rows > limit [(id + limit - rows) * 3 - 1] [id * 3 - 
   1]
			insert clear pane/1/pane/:idx/text string
			redraw
		]
	]


 set-message-color: make function! [id [integer!] color [tuple! word! 
 none!] /local idx] [
		if any [zero? id id > rows] [exit]
		poke data id * 5 - 1 color
		if limit > (rows - id) [

   idx: either rows > limit [(id + limit - rows) * 3 - 1] [id * 3 - 
   1]
			pane/1/pane/:idx/color: either word? color [get color] [color]
			show pane/1/pane/:idx
		]
	]

	redraw: make function! [/no-show /local row] [
		clear pane/1/pane
		height: 0
		rows: (length? data) / 5
		row: max 0 rows - limit: any [select options 'limit 100]

  foreach [user user-color msg msg-color date] skip data row * 5 [

   append-message/no-show user user-color msg msg-color date row: row 
   + 1
		]
		pane/1/size/y: height
		pane/3/ratio: either zero? height [1] [pane/3/size/y / height]
		unless no-show [show self]
	]

	init: make function! [/local p] [
		unless options [options: copy []]
		p: self
		limit: any [select options 'limit 100]
		; chat pane (1)
		insert pane make baseface [
			offset: as-pair 0 sizes/line
			size: p/size - as-pair sizes/slider sizes/line
			span: all [p/span find p/span #W #W]
			pane: []
		]
		;	heading (2)
		insert tail pane make gradface [
			offset: -1x-1
			size: as-pair p/size/x sizes/line
			text: "Chat"
			span: all [p/span find p/span #W #W]
			font: make font-button [align: 'left]
			para: make default-para [tabs: [0 0]]
		]
		;	set header tabs

  poke pane/2/para/tabs 1 sizes/cell * (any [select options 'user 15])

  poke pane/2/para/tabs 2 size/x - sizes/slider - (sizes/cell * any 
  [select options 'date 25])
		;	vertical scroller
		insert tail pane make slider [
			offset: as-pair p/size/x - sizes/slider sizes/line - 2
			size: as-pair sizes/slider p/size/y - sizes/line + 2
			span: case [
				none? p/span [none]
				all [find p/span #H find p/span #W] [#XH]
				find p/span #H [#H]
				find p/span #W [#X]
			]
			action: make default-action [
				on-click: make function! [face] [
					if height > face/size/y [

      face/parent-face/pane/1/offset/y: (height - face/size/y * negate 
      face/data) + sizes/line
						show face/parent-face
					]
				]
			]
		]
		pane/3/init
		action/on-resize self
	]
]

To use this, just save it as slim-chat in rebgui/widgets, and then 
do create-distribution.r. It's fully syntax-compatible with the existing 
chat widget.

I forgot, you will need to add #include %widgets/slim-chat.r in rebgui-widgets.r

One major point wasn't said: We need a library system to handle all 
this. I won't use code, where I need to 'do zillions of single files 
in a specific order, handle path and lookup things, need local sub-directories 
to load images etc.


I'm still using Slim on my xpeers system, because that's the only 
thing I know about that handles all this quite well. And I can tell 
you, it pays off. Something like this is required.

kib, it's probably not hard, maybe take a bit of work to make it 
really slim and clever. I just have a ton of projects in the air 
all the time, so I didn't come to it yet.

You want the billion $ idea for digi-cams?


Add a SLIM and BEAUTIFY button that will alter the taken pictures 
in real-time.

There are so many technological fields opening up as more things 
are made possible. I imagine one could apply for a job as an astronaut 
in 50 years, if you are fit enough and remember to eat your daily 
slim-fit foodpill. What about the stabilization and development of 
poor countries in 50 years?  If they are going to be as consuming 
and as productive in 50 years as an industrial country is today, 
then there is going to be millions of new jobs available. Technology 
and progress make far more jobs than they destroy.

It appears that the VIC Pro and VIC Slim are available for purchase 
now. -- http://www.commodoreusa.net/CUSA_Store.aspx

Commodore USA has released a new video showing their office, production 
area and the progress of both the new Commodore 64 and the VIC-Slim. 

Here's the link: http://commodoreusa.net/CUSA_FacilityVideo.aspx

I wish modules existed, hell, that's why I coded slim which handles 
code modules almost 90% exactly like Carl had planned them.

anton, slim doesnt expose ANY words in the global context.  module 
interdependency is assured even if they each need each other's code. 
 and the infrastructure is embeded, where its the code LOADING the 
module which decides what to include.  by declaring words in a module, 
that uses another module, you don't even expose those words.

this is available in R2 for 5 years now.

slim/load 'module-name version 


module-name is searched for in search paths and must match header 
name, or its ignored.

slim/load/expose 'module version [a-function another-function]


you can even rename the funcs as you are exposing them to enforce 
code to cooperate:


slim/load/expose 'module version [[module-name my-own-name] [other-module-name 
my-other-name]]

slim also has an auto-prefix option when you import words.  so as 
to make "collections" easy to differentiate, without having to rename 
each one separately.

Maxim, ok, that's Slim, your software. I was just basically explaining 
to Steeve why I would strongly discourage using SET to export words.

Maxim, I write modular code in R2 as well, though with Gabriele's 
modules, not Slim.

Just curious Maxim...  Would SLIM properly catch the following code?

hax: does [ do load {set 'global-leak! "Mwahahaha!"}]

>:)

(in slim)

cause all I've read of the R3 engine, slim already handles a part 
from actual enforcing of the privacy.

its funny its sooo close to slim ... and slim is over 5 years old 
;-)

but there is definitely one thing that needs to be added, unless 
its just not documented.   the ability for import to RESTRICT what 
is exported by the module. 

this is the most powerfull concept in slim and I'll never want to 
live without it.  


in slim, its the module USER that has control over the module.  when 
you load the module, by default it uses the module's expose list, 
but if you supply your own, then the module doesn't expose anything 
else than what you ask of it.  


this allows me to have a clean current context, and I can prevent 
my module from cluttering the context its loaded in.  especially 
if its loaded AFTER some code has been defined, or using common global 
words.

well, I'm giving you 5 years of daily real-world usage above  ;-) 
  a lot of the slim spec has not been used, by natural selection, 
but the above is in just about 95% of all of my code.

Ladislav, good idea, I'll add a section on slim at the end.

and that is the core reason for the existence of SLIM.

slim also allows you to rename the words AS you are importing them, 
solving the name clashing cleanly and obviously.  This is very usefull 
when you are using frequently updated libs.  and is even more usefull 
when those libs aren't readily editable. (encrypted, compressed, 
etc)

I also vote for the module system to support the ability to restrict 
what you import, and SLiM's ability to rename words on import (and 
prefix them) is very nice.

what you are saying is that for modules, we need to start declaring 
words?  not very rebolish. 


 I have to do so in slim to keep words local to the calling context, 
 but I would have tought that modules would do so automatically since 
 they replace the global context.

 any new word in the root of the spec block of the module should be 
 added to the module's context and set to unset! just like R2's global 
 context does.

just like slim's LOAD is a fancy DO   ;-)

that would be slim's 'OPEN... starting to be late... hehe

well, I've been doing that for years with slim  ;-)

However, it does mean that the trust model of R3's module system 
is different than that of Slim. In particular, you are supposed to 
be able to tell everything you need to know about a module from its 
loaded source, or from its header if there is no source available. 
If you don't trust the module, or if it would trounce the other modules 
you are loading, don't use it.


The R3 module system is designed for competent programmers who need 
to organize their code, but don't want to be bogged down in the beaurocratic 
overhead of maintaining import graphs in a multitasking environment. 
There is enough flexibility to help you structure your application 
as you see fit, and very little management overhead at design, development 
or run time. And it's statically determinable so a preprocessor can 
turn it all into one script with nested modules if need be.

slim allows nested static linking, preserving the import system  
;-)


its the multi-tasking part I don't get... what do you mean by that?

The idea per thread is neat, btw.


but I will be adding the expose refinement to import for sure... 
I just can't use other people's modules and hack them everytime they 
are updated... that is how slim started out... I was using someone 
else's module and everytime he did a release, I had to take 2 hours 
to fix up the module so it would work into my code.


that is the point of importing only the words you want... especially 
renaming them to remove clashes within your code and the module being 
used.  I don't see how that has ANY thing to do with the per-task 
concept  the source which uses a module, just makes it obvious where 
things are coming from and debugging is GREATLY simplified.

All module export in R3 is what you call exposing in slim. Importing 
is a separate issue, and you can choose what to import. The export 
list is just that: a block of unbound words that are used as a guideline 
about what to import - all module context words are actually visible, 
unless they are hidden using the standard hiding facilities. You 
can choose to import just that list, or none, or go by a module reference, 
or import whatever visible words you want. What importing means depends 
on what kind of module or script you are calling from, or for that 
matter whatever you want it to mean.


You need to remember the model if you are doing selective import 
though. You aren't just importing to the current context if you are 
importing named modules. If you come up with a good model for selective 
import, be sure to tell me. I think that I'm one of only a few people 
who really understands the whole model (must write more docs).

slim and R3 modules have a very similar model, as we discussed before, 
since I have the same concept of named/unnamed modules and they basically 
have the same limitations.

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

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?  ;-)

and slim.

in detail, unless you use slim-link to produce a source which INCLUDES 
glayout or slim, your application is not obliged to be open source, 
this applies even when your application is encapped.  just keep the 
slim.r and glayout files external and you are still ok in using it.

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

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

Robert tried slim and in 15 minutes adopted it.

do %slim.r
slim/open liquid 0.6.4

oops  typed a bit too quickly...	

do %slim.r
slim/open 'liquid 0.6.4

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

oops  typed a bit too quickly...	

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

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

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

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

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?

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.

hehe it was really minor, but probably something that's caused me 
some headaches in the past.  wouldn't have been possible without 
slim's verbose printing management  :-)

hehe.  I am just doing so... new version of slim just got uploaded 
(minor changes), liquid is almost ready.

the application will be there within the hour (need to build a friendly 
little rebol.org based slim lib D/L interface using VID)

just thought I'd share this list I built while coaching someone in 
using liquid last night...

SANITY PRESERVING KNOWLEDGE WHEN USING LIQUID:
--------------------------------------------


#1:  liquid isn't a bully  - liquid shares its state, but asks for 
data (pulls, observes, etc) from its subordinates ("parents"), not 
the other way around (it doesn' push or force feed, like a highly 
inneficient signal messaging engine).


#2:  liquid is lazy by default - unless a plug or one of its observers 
 ("children") is stainless, nothing will process automatically (thus, 
faces usually are set to stainless, so that they refresh automatically).

#3:  liquid has several computing modes in a single base class.  
  * linking is for once sided dependencies
  * piping is for inter-dependencies or synchronisation
  * containment is for data storage
  * linked-containment is for processed data storage   


#4:  liquid mutates - plugs automatically change computing modes 
when you call some methods like linking, piping and filling.  depending 
on the order of these operations, a plug may "stick" to its previous 
computing mode.  e.g. a piped node remains piped, even you attempt 
to link it to something.


#5:  liquid is alive - remember that as you are setting up a liquid 
network, your plugs will start receiving messages as you are building 
up the tree, meaning that the process() (and other) functions might 
be triggered before every expected connections are done. always verify 
the integrity of the data before starting the process.  (i just got 
stumped by this one again, 5 minutes ago).


#6:  liquid is a collection of droplets - each plug should do one 
thing or manage one step of a process.  the more you break up the 
network, the better you will be at making it stable, reusable, flexible, 
and fast.


#7:  liquid is highly memory efficient - !plug uses shared classes. 
 so all the liquid operations are in a sub-object called a valve. 
 Thus, when you call internal functions, remember they are within 
the valve, and you must supply the plug as its first argument.  my-plug/valve/stats 
my-plug


#8:  liquid is volubile - its slim-based verbose & indented console 
printing engine (vprint) is YOUR BEST FRIEND.  use it profusely, 
to understand the chain of events and what the hell is going on.

SANITY PRESERVING KNOWLEDGE WHEN USING LIQUID:
--------------------------------------------


#1:  liquid isn't a bully  - liquid shares its state, but asks for 
data (pulls, observes, etc) from its subordinates ("parents"), not 
the other way around (it doesn' push or force feed, like a highly 
inneficient signal messaging engine).


#2:  liquid is lazy by default - unless a plug or one of its observers 
 ("children") is stainless, nothing will process automatically (thus, 
faces usually are set to stainless, so that they refresh automatically).

#3:  liquid has several computing modes in a single base class.  
  * linking is for once sided dependencies
  * piping is for inter-dependencies or synchronisation
  * containment is for data storage
  * linked-containment is for processed data storage   


#4:  liquid mutates - plugs automatically change computing modes 
when you call some methods like linking, piping and filling.  depending 
on the order of these operations, a plug may "stick" to its previous 
computing mode.  e.g. a piped node remains piped, even you attempt 
to link it to something.


#5:  liquid is alive - remember that as you are setting up a liquid 
network, your plugs will start receiving messages as you are building 
up the tree, meaning that the process() (and other) functions might 
be triggered before every expected connections are done. always verify 
the integrity of the data before starting the process.  (i just got 
stumped by this one again, 5 minutes ago).


#6:  liquid is a collection of droplets - each plug should do one 
thing or manage one step of a process.  the more you break up the 
network, the better you will be at making it stable, reusable, flexible, 
and fast.


#7:  liquid is highly memory efficient - !plug uses shared classes. 
 so all the liquid operations are in a sub-object called a valve. 
 Thus, when you call internal functions, remember they are within 
the valve, and you must supply the plug as its first argument.  my-plug/valve/stats 
my-plug


#8:  liquid is volubile - its slim-based verbose & indented console 
printing engine (vprint) is YOUR BEST FRIEND.  use it profusely, 
to understand the chain of events and what the hell is going on.

this is embeded within the slim manager and is added to any slim 
library automatically

if you try out the little blood.r app on rebol.org you'll see how 
extensive liquid's tracing is, thanks to slim's vprint engine.  :-)

Maxim - I have sent you a note on my intent to add to my piece on 
"slim Liquid Rebol" at eclectic-pencil -  I will pen that note in 
blood ...  piping can be so much more feral that ducts ; - )

1. liquid needs no config
2. the naming IS very logical.  

3. impossible, liquid is a kernel, you cannot plug liquid Over, you 
have to build tools with it.  and NO I don't force you to use anything 
cause I don't use it myself.

all of my graphics work, even glayout has always been using VID. 
 Using face/init face/action face/feel of standard vid gadgets... 
the blood example of liquid on rebo.org is such a VID example.


4. liquid has never forced you to use any adapted VID, using slim 
is one line of code, no "config and install required", liquid isn't 
even graphics related.

since processing of requwest seems to take just 1ms I think chances 
per user are slim. What would happen in it collides? would one of 
processes "get file access error" or something worse can happen by 
your exp? (I was asking about the fear of file getting corrup / half 
written before)

Max talking about Steel / SLiM etc

I'd like to know if any of you want to be alpha testers for the up 
and comming version, which is a result of several YEARS of fine tuning, 
 and now combining, a rich set tools.

CURRENT FEATURES (partial list):
General:
-----------------------
-non intrusive, does not force any programing onto you.

    ex:  * no need to have version in header, and can still do version 
    control

           * history format is user specified, massive configurability
-encapped (windows) application, so its easy to use.

-no external dependencies (ex: zip archive is embeded, and coded 
in rebol :-)


Automated:
-----------------------
-script versioning
-file backup (versioned)
-zip archival
-file management

-creation of "packages" (create dirs, copy files, archive, prebol, 
slim-link, encap, etc)

-header manipulation (including history, date, version, and any field 
you want to enforce)
-system calls
-file parsing, replacing info tags.

Flexible setup:
-------------------------
-cascading configuration (global, user, project, + per file)

-config locking, prevents overiding configs in cascaded setups (project 
manager can create rules which no one can break)
-command-line arguments overides for many configs

-user set configs for most if not all features (ex: history format, 
date format).

and much more

Note that encap, prebol, slim-link are also part of the features 
base, but are not yet re-integrated in the first releases.

souce code is 7MB, but probably includes a lot of stuff we can trim 
for our specific purpose. the binaries are big wrt rebol, so it can't 
part of the host code(unless brian can build a very slim version 
of it), but it would make for a very nice extension.

but I've now got slim working in R3  ;-)   am now working on converting 
liquid and other libs.

I'll eventually redesign slim so it uses modules though.

I really like how you've evolved the system and its doing all of 
what I wanted slim to do minus one or two little things, which I 
can easily graft over modules as they are .