AltME groups: search

maybe a tree in front of the person's icon, indicating that the view 
is not clear because there are messages stacked in front of the person 
for you to read...or an envelope icon?

It has been a couple of years but I think I just tarred the whole 
directory tree moved it to a new machine

Gabriele, That is great !

I hadn't noticed the extra info poping up. Just that simple extra 
info is very helpful when inspecting/reading code (well for me anyway). 
Thank you.

The fact I hadn't noticed it might be a counter argument to Sunanda's 
fear of being annoyed by it. You really have to leave your pointer 
on it.


Any new language (natural or artificial) feels like "Scriptio continua" 
( http://en.wikipedia.org/wiki/Scriptio_continua) 

at first and all these visual cues are very helpfull in building 
the program's tree in your mind.


Imagine yourself a beginner at german reading a text that would have 
been colorized to accentuate its different elements. Hovering over 
a colored word would give you a translation or even maybe just a 
picture to prevent you from thinking in your first language.

agree, very flexible dynamic code generator. increasing the gadgets 
like list, tree  tab (e.g. as macro) will be very nice too :-)) thx 
for heading me to this.

Paul, 


For what you have described, you may want to use navigation like 
that provided 

by a java script outline tree. One example is http://www.treemenu.net/
  


My plan is to soon make a make-doc revision that takes as input the 
NoteREB data from the
script by Alain Goye.   http://alain.goye.free.fr/rebol/NoteReb.r

Then generate an html site using the same tree structure as the NoteREB 
source file. 

Each page from the NoteREB data file is to be make-doc'ed into a 
separate HTML page.


NoteREB uses a very simple REBOL block structure to hold the content 
and sub-blocks.


If you want to change a page, change the source page, save the file, 
and click the new

reGEN button.  Alain's tree makes the management of the source much 
easier than methods
I had been using before.


I have used this approach for taking easy vid format and making an 
easy vid presentation 

format.  That means that it makes VID faces for each page and allows 
the execution of sample

code by clicking on it. Seems to work well and I plan to put it on 
the script library 
after View 1.3 is released and I can verify it works OK there.

Hi Robert, That is a VERY nice site.  I am continuing this look at 
NoteREB because it manages the source and the tree structure for 
me. For what I want, a tree structure is important.  This approach 
can use makedoc2 or any other variation to make-doc the page.  The 
recursive tree approach combined with any already written make-doc 
function makes it work well so I'll  be done soon  then will have 
a longer look at your site and approach. Thanks.

The make-site approach is based on a directory tree on your disk. 
All path's you see are actually directories, and each dir has only 
one file, an index.html That's why you don't have to hack in any 
document name.

hi,  yesterday I realized I have a 1400 line single parse ruleset 
 which amounts to ~40kb of code !   :-)  I was wondering what are 
your largest Parse rulesets,  I'm just curious at how people here 
are pushing REBOL into extremes.


I might also say that parse is wildly efficient in this case, allowing 
my server to decipher 600 bytes of binary data through all of this 
huge parse rule within 0.01 - 0.02 seconds (spitting out a nested 
rebol block tree of  rebxml2xml ready data).

I need to work with tree, category, subcategory, etc.. does anybody 
have something ready willing to share?) thx!

I have a mysql wrapper that I use in production but haven't released 
because it need cleaning and docs, but if there is interest I could 
release for testing as is. id does things like:

print .db/get/all/sort/debug [mailing/m mailingLog/ml] [ml.dc m.email 
ml.url] [{ml._mailing=m.id}] [m.email asc ml.dc desc]

SELECT `ml`.`dc`,`m`.`email`,`ml`.`url` FROM `mailing` `m`,`mailingLog` 
`ml` WHERE ml._mailing=m.id ORDER BY `m`.`email`,`ml`.`dc` DESC
print .db/set/debug 'mailing 12 reduce['active false] 
UPDATE `mailing` SET `active`=0 WHERE id=12.0

print .db/get/all/flat/debug '_node_tree [_node _media] [{_tree=? 
AND _issue=?} 5443 22]

SELECT `_node`,`_media` FROM `_node_tree` WHERE _tree='5443' AND 
_issue='22'
..

ok I'll have a look. Is there a tree command of some sort that can 
do the looking for me ?

No tree command in the standard distribution

Hi Phil,


*nix doesn't use drive-letters, so _all_ drives show up somewhere 
under the root as directories. _Where_ they show up is up to you 
;-)

Drives are "named" /dev/hda1 (first paritiion on first disk), /dev/hdb3 
(third partitiion on second drive), etc ...

There's a file, which describes the mapping, where your drives are 
put, in Rebol

print read %/etc/fstab


the first two columns show where ich drive is put in the directory 
tree (and then some more info)

or you can do 

call "mount"

which displays the currently mounted drives.

You can use a file tree on disk or through FTP. Not sure how to copy 
the mulyiple CDs into one tree

To help do the transition, I wrote a rebol script that converts a 
native The Bat! mail database to a directory tree structure mirroring 
the contents in the open Berkeley format,  mbox, as found in the 
Unix world.

I'd like to let my cgi script to be easy portable. I already moved 
them twice on tree different unix-like OS successfully, but I had 
always the problem of the first row. If in the first row I wrote 
#!/usr/local/rebol/rebol -c I need, in the new hosting OS, to have 
Rebol installed in thet dir. But this is not always true (or simple 
to set up). So I'd like to use a "portable syntax". Now, I did various 
tests but I couldn't find a solution. I already tryed:

I have been writing Rebmu programs in actual Rebmu, as opposed to 
writing them in Rebol and then translating, as a test of how "bad" 
it is: http://github.com/hostilefork/rebmu/tree/master/examples/

I found that appendChild(elem) should do the move.

But still difficulty navigating the DOM tree to get to the right 
place where it can be inserted.
eg.  top.frame2.appendChild(elem)  is not working.

load the jquery library into your site and make your life much easier, 
it makes manipulating DOM a kid game 8) http://jquery.commaybe look 
also for the accordion or tree plugin for your menu

Get a parse tree result from Parse


http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=load-parse-tree.r


For fans of REBOL's Parse function, it could be particularly useful 
used with Gabriele's Rewrite function.

WHy? isnt the sdk-christmas-tree here? :)

how funny - wasn't looking high enough in the tree.  I've been using 
that tree structure for so long that it became transparent over the 
past couple of years.

As long as there is a glossary that let's you translate from familiar 
terms, I think you're OK using REBOL's native terms, though they 
were foreign to me when I started.

Window or dialog?

 Or Screen or Form or Layout. A Dialog is usually something other 
 than the main screen in an app. You sometimes need to use all those 
 terms if you're speaking in the domain of an application, so use 
 wha'ts appropriate in each context. 

Face or graphical object?

 Or Control or Widget. Tough call on this one. I was used to Control 
 from VB, and Face confused me as it could be a layout as well. I 
 like distringuishing between layouts and controls. Hmmm Maybe a hierarchical 
 tree.

Facet, attribute, property or descriptor?

 I like either Attribute or Property. I can live with Facet in REBOL, 
 it's shorter, and it makes sennse if you think in terms like "let's 
 discuss this facet of the business". 

Style, widget or template?
	Style, definitely.

Is there a tree widget for RebGUI being developed already?

Maarten, Yesterday I started using Alain Goyé's NoteREB outline tree 
now - written 04/05/2004.  Very nice.   I am blending it with Carl's 
Easy VID to update VID Usage to have a navigatable tree approach.

Tree code must include the capablity of seting node and leaf icons 
 ;)

SVG format is so blury that you can't match it to a predeterminate 
struture you have to do a structure analyst for each leaf of the 
the object tree then get the needed information from leaf and nodes 
then convert them to rebol then apply the draw

I think that's because technologie issue (graphics libs that would 
be used to normally render SVG files to screen are different from 
AGG ) then you have plenty of possibilities SVG can be seen as a 
VID  widget tree where youonly get relevent informations but the 
structure have some recusing consept

so you have an XML  struture we transforme it to a REBOL Object! 
tree then this tree must be glanced and translated to have the AGG 
draw block ;)

actually my main problem i how to build path to reach information 
into the SVG rebolien converted object tree

how can i insert an XML tree inside another ?

As text? Is the XML a DOM tree, parse-xml generated blocks, what?

as a dom tree but it may be generated blocks as well

How is your DOM tree implemented? REBOL doesn't currently have very 
good XML support by default as such. People tend to use text, blocks, 
objects or a combination of them.

How to get started with xml? I know the simple things, kind of object-tree, 
similar to what parse-xml does. What extras would be needed?

Volker, I'm not even sure that node objects need to be stored as 
a tree.

As programmer not AFAIK. with a dom you can use path-notation. with 
SAX you build that tree yourself. I guess SAX makes sense when you 
convert data, like xml-make-doc. one tag, output something, another 
tag, output something other.

There are two major types of XML (or SGML) APIs:

Tree-based APIs

    These map an XML document into an internal tree structure, then allow 
    an application to navigate that tree. The Document Object Model (DOM) 
    working group at the World-Wide Web Consortium (W3C) maintains a 
    recommended tree-based API for XML and HTML documents, and there 
    are many such APIs from other sources. 
Event-based APIs

    An event-based API, on the other hand, reports parsing events (such 
    as the start and end of elements) directly to the application through 
    callbacks, and does not usually build an internal tree. The application 
    implements handlers to deal with the different events, much like 
    handling events in a graphical user interface. SAX is the best known 
    example of such an API.

If the internal representation is an object-base tree, what are the 
barriers to the 'get-elements-by-tag-name function?

Yes, load is our tree, parse our events. Think of parse as "Here 
comes the word 'file. Yuppa, and a real 'file! . Good, and a 'binary!. 
(fine, now i store that data in that file)"

Chris - following is true imo which favors SAX with me:


Tree-based APIs are useful for a wide range of applications, but 
they normally put a great strain on system resources, especially 
if the document is large. Furthermore, many applications need to 
build their own strongly typed data structures rather than using 
a generic tree corresponding to an XML document. It is inefficient 
to build a tree of parse nodes, only to map it onto a new data structure 
and then discard the original.

The thing is - result of DOM parsing is tree representation of document 
- in Rebol .... the question is, what if you need data organised 
otherwise? You will have to search that tree and build such structure 
which fits you anyway ....

But we should not think that having DOM will allow us to manipulate 
website elements, as having document loaded into rebol DOM will not 
allow us to manipulate DOM tree loaded into browser :-)

>> source parse-xml+
parse-xml+: func [[{
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the built-in
    REBOL parse-xml function.
}
        code [string!] "XML code to parse"
    ]][
    xml-parse/parser/parse-xml code
]

hash! is ok when staying at the level of an unary tree, not deeper. 
don't ask me why, it's just an observation. obviously it was wanted 
by the implementation... perhaps aiming to RIF ?

Doing my first steps with REBOL I tried to do something with XML

(reading/eventually modifing/writing). I looked for some scripts 
helping
me to do this and found:

1. xml2rebxml/rebxml2xml:
    I got the following problems:
    - missing/loosing comments
    - missing/loosing elements - that's realy serious
    my steps were:
      my-doc: xml2rebxml read %simple.xml
      write %simple2.xml rebxml2xml my-doc


    The second documents finishes outputting elements after some comment
    block in
     the source xml doc.

 2. xml-parse/xml-object:

     The versions I found on the reb library didn't work, I used some

     older versions from rebXR-1.3.0, I've got my objects, but it would 
     be

     nice to have a third module like xml-write to get the object tree
     back to xml. Is somebody developing something like this?

 3. mt.r:

     I tried to figure out how it works. Basically I can write some XML

     based on a REBOL block but I couldn't figure out how to define the

     rules about elements and attributes. Where can I find an example

     about writing for instance svg with mt.r, how looks the coresponding
     REBOL block and the rules for svg?


Where can I find more about xml and REBOL, I think it would be very 
nice
to have some REBOL scripts, doing things like 
   some-elem: xml-create [ elem "foo" namespace "myns" attribs [
                                     bar "something"
                                     xyz "123"]
                                     ]
   xml-modify [ elem another-elem append some-elem ]
and finally
   xml-write %mynewxml.xml my-doc


Is somebody developing something like this with REBOL? Some scripts 
giving

me the same comfort in REBOL like maybe XOM (http://www.xom.nu) is 
giving
for XML in Java. Of course done with some nice REBOL dialects?

What is the above mentioned "EasyXML" - is it available for use/testing?

Thank you for any tips, carsten

I thought SAx was about finding the most suitable data structure 
- not a tree representation, which is DOM.

I don't know if the event handling part is mandatory (BTW, to whom 
?).
isn't all about accessing XML data the best way a PL can ?

No, parse-xml generates a (broken, incomplete) DOM tree. Gavin McKenzie's 
xml-parse is more like a SAX parser.

I've also had a look inside xml-parse, it seems to be really like 
SAX - ready to use. But nobody is maintaining it, I think. As far 
as I understand, somebody could create a Handler to get the desired 
block structure (for instance a Handler for RebXML or any other model). 
I have to learn about this in REBOL.


A question: how can I measure memory for a block or an object tree 
in REBOL?

With length? i need some recursion, otherwise I get only the first 
level of the block if it is nested? How to serialize an object tree 
in REBOL - is there some function available?

we already have data as trees

 - if you use that, then tree rewriting would be very useful for you, 
 wouldn't it?

can you further define "tree rewriting"

max: tree rewriting is the technique that compilers use to get from 
the source AST to the final machine code; you can also imagine purely 
functional languages as special tree rewriting engines.

basically, you have a tree, and you have a set of rules for rewriting; 
a rule is a pattern and a replacement for the matched node

Tree rewriting is a model of computation which is used in a variety 
of contexts within computer science, for example in semantic specification 
and compiler implementation

ok, so you pre-specify how path /aaa/bbb/ccc/ specifies data in another 
tree  /xxx/yyy/zzz ?

xslt does something very similar; it matches a number of nodes (via 
xpath), then creates a new tree based on those nodes. rules are applied 
recursively so that you end up with a new tree starting from the 
initial tree.

there are only two votes so far, howeverr both voted for 3. maybe, 
we could introduce a new concept to CS, "dialect rewriting". :) it's 
the same as tree rewriting but without a tree. ;)

dialect rewriting is basically what my rewriting engine for rebcode 
does; it's rewriting where instead of using a regexp you use a parse 
rule; and instead of compiling a tree to another tree you compile 
a dialect to another dialect.

so it can be considered a superset of tree rewriting (since you can 
think of a dialect to represent trees)

BTW, Gabriele you have my vote on tree rewriting.

Actually I don't care what directly is available (as a user), if 
just some things can be done:

e.g. people need to process XML - thus people already knowing XSLT 
and XPATH would like to leverage their knowledge (I asume) - so if 
we get a dialect for this (2.) this is nice, but even nicer if there 
is some mechanism (a generalization) which allows to import an XSLT 
(ast?) or some XPATH query and return the (more rebolesque) according 
Rebol dialect

3. three has always this kind of attitude of being able to do everything 
better in Rebol itself - even if true (?), that's one of the problems 
with Rebol, that outsiders can't afford the time to do many things 
better (themself) or don't care, because they want use some standards 
nevertheless and Rebol drops out as an option


so I vote for 2. with the ability for 1. maybe by the possibilities 
tree rewriting (or dialect rewriting) offers (I have not much glue 
about this - so some of the experts should know)

it turns out that i can do tree rewriting as a subset of dialect 
rewriting. it's a bit tricky but works well.

on top of this, one could probably implement something similar to 
xslt, to translate a tree (parsed from xml) to another tree (maybe 
xhtml or another xml doc)

I have often missed structural pattern matching in REBOL, something 
like the match statement in Nemerle (I'm sure it's in other functional 
languages but that's the first that came to mind). You could combine 
a structural pattern specification dialect (like XPath) with a structure 
building dialect (like XSLT), and then make the dialect compilable 
to REBOL code that can be used over and over again. It would be like 
a regex compiler for structures - I would use this every day.


All you would have to do to implement actual XPath syntax would be 
to specify a standard mapping of XML semantics in REBOL data structures 
(see my block model in this group from last October) and then have 
compile the XPath syntax (in a string) to the structure matching 
dialect. Then you could work from there.


(Gabriele, sorry if this seems redundant - I'm trying to explain 
tree rewriting in more REBOL-like terms).

when i think about representing data conceptually, i tend to always 
come up with a graph or a tree (then i map the conceptual graph to 
a relational model, or maybe to a dialect). so for selecting data 
a "navigation" approach (which is basically what xpath does) seems 
rather natural for me; then you can map the navigation to SELECT 
statements etc if needed.

so maybe my question is: is graph navigation (or, if you think it 
is general enough, tree navigation) a general enough selection model, 
or do you think that it would be missing something?

>> do %xml-parse.r

Script: "A more XML 1.0 compliant set of XML parsing tools." (2-Mar-2005)
** Script Error: Invalid argument:
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the...
** Where: throw-on-error
** Near: func [[{
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the built-in
...
>>

; You can still parse the tree too:
parse doc/tree [<some> into [<xml> "to try"]]

Ok, another revision.  This has a few more methods, I may strip them 
down to read-only, as I don't need to manipulate the object though 
I left them in for completeness.

>> do http://www.ross-gill.com/r/qdom.r
connecting to: www.ross-gill.com
Script: "QuickDOM" (none)
>> doc: load-dom {<some><xml id="foo">to try</xml></some>}
>> foo: doc/get-by-id "foo"
>> foo/name
== <xml>
>> foo/value
== [
    /id "foo" 
    # "to try"
]
>> kids: foo/children
== [make object! [
        name: #
        value: "to try"
        tree: [
            # "to try"
        ]
        position: [
   ...
>> kids/1/value
== "to try"
>> doc/tree/<some>/<xml>/(#)           
== "to try"

you can just do a mold/all load, that will in effect copy the whole 
tree along with all the series too.

ex:

load mold/all make object! [
    a: make object! [
        b: make object! [
            c: "tadam!"
        ]
    ]
]


will effectively create a complete duplicate of the whole object 
tree.

I just created this function to convert the data tree returned from 
REBOL's default parse-xml function back to the same string:
context [
	out: copy ""
	emitxml: func[dom][
		foreach node dom [
			either string? node [
				out: insert out node
			][
				foreach [ name atts content ] node [
					out: insert out join {<} [name #" "]
					if atts [
						foreach [att val] atts [ 
							out: insert out ajoin [att {="} any [val ""] {" }]
						]
					]
					out: remove back out
					
					either all [content not empty? content] [
						out: insert out #">"
						emitxml content
						out: insert out ajoin ["</" name #">"]
					][
						out: insert out "/>"
					]
				]
			]
		]
	]
	set 'xmltree-to-str func[dom][
		clear head out
		emitxml dom
		head out
	]
]

Just note, that if the source xml is using CDATA, the parsed tree 
does not contain this info, so the result would be different.

>> print xmltree-to-str probe third parse-xml+ {<foo>abc <![CDATA[Jack 
& Jill]]> xyz</foo> }
[["foo" none ["abc Jack & Jill xyz"]]]
<foo>abc Jack & Jill xyz</foo>

yes DideC you are right the most problem will be to create tht tree 
structure to store all the LinearGradient définition and there childs 
then retrieve the approprieted informations

opkay so we are planning on the opportinity to use a REBOL tree object! 
structure to represente SVG datas :)

I make a base code but now I have to find a good code to exploit 
the relevent datas from the object tree

so in Rebol tree object the g block can be a bloc of sub object or 
an object  ;)

Okay so here is the first version of my work on SVG to rebol objects 
tree structure

I like the XML  primitive draw explorer like a tree view of the compoun 
of your draw this is particularly good to write SVG renderer

Handling SVG as REBOL object! tree makes it really really easier 
to set recursivity and code writing ( as all can be exploded into 
small fonctions I hope the resulting code once terminated won't be 
so deficult to read

It would be cool to build a sort of proto-tree.  So you can see where 
in the tree a word is related.

I created a graphic language that effectively had two commands:

Draw: at an xy point and
Circle: which had center coordinates, radius, angle and divisor.

The angle and devisor allowed you to pull an interesting trick.  


So to make a square, you simply called it with a divisor of 4.  this 
would build a string (block) with 4 pairs.  If you wanted a diamond, 
set the angle to 45.
 
You then passed the string to draw.


This may seem like a weird way to do this, but it was perfect for 
a real time rending system that was interactive.  We use this in 
a draw program like Flash.

And the idea of a graph giving the family tree of the language is 
terrific.

Then a genus tree, since many words are just subtle variations.

Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?

Q: What does the world on Nov-15-2005 look like?


A: Our main goal is to get REBOL into the hands of more users, not 
just programmers and techies.... by the millions over time.  By doing 
that, we create a market for not only handy free REBOL apps, but 
also for commercial apps and entire businesses that are related to 
REBOL.



Q: Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?


A: Our plan is to make that a window option that is part of the face/options 
for a window.  If an OS does not support this mode, then the option 
will be ignored, but the application will still be fully functional.



Q: I hope it is still valid that cooperation with RT is possible. 
I mean - last few weeks I play with some Win32 functions (thanks 
to Gregg) and I would like we would have proper app behavior in multi-monitor/multi-desktop 
environments .... so I wonder if any SIGs will be created, some ppl 
will be invited to participate, comment etc., or if RT is gonna cook 
it all themselves?


A: Yes, there are many such special interest projects currently going 
on. (Most of them are occurring via private projects in AltME and 
IOS.)  These days 90% of REBOL changes are done in cooperation with 
the REBOL community.



Q: Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?


A: Regarding 2.7 and 1.4 question: we change the revision numbers 
(the second number) whenever there is a major change in REBOL that 
may be unstable.  The /core 2.7 kernel (that is in /view 1.4 as well) 
adds new datatypes to REBOL, and they are the first datatypes added 
in several years, so we consider this to be a major change, and marked 
it that way.
Yes, we do plan to be making a few AGG fixes very soon.

Oh, and regarding VID: we plan to be making very big changes there. 
More to come soon.


Q: Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.


A: On structs: yes, we will enable this feature on core, but it should 
only be used for lower level code.  Objects are more powerful.


Q: Could you add an APPLY opcode to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).


A: I'm not sure what is meant by the path for it. You mean for refinements?
That may actually slow down the apply interface.

I guess one problem with a multicast tree is that if you're disseminating 
your RSS feed this way, you may not know how many subscribers there 
are.

So you will make executing slower, because now the interpreter needs 
to keep track of the whole tree to see which values changed and which 
are a violation of contract.

and why they have dynamic images? src="/zkdemo/zkau/web/zul/img/tree/root-open.gif;jsessionid=51580CB61B89633DED498444EB959AED"

hmm, just got myself to http://rubyforge.org- there is really many 
community projects ongoin with Ruby ..., just go to project tree 
...

The strategy is to en/decrypt every block that gets written to disk. 
Even all B*-tree stuff etc. with this it's fully transparent to the 
database engine.

its more like interfaces/multiple inheritance than inheritance IMHO. 
means you are not forced to a tree, and you dont share code.

(I think it would be very cool to have a DOM tree browser written 
in REBOL)

Yes, a DOM tree browser would be very cool.

sometimes you'll need to call refresh on the window itself, cause 
the new/old faces will change how the whole tree of groups measure 
up against each other

ended up with scroll panes, menues, tree views, all matter of buttons 
and fiels.

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.

it sounds very much like my RE, except my RE does not have that ability 
to move around freely in the structure, and you have to cross relate 
manually. no "traversing" back and forth. you can't start in the 
"middle" of the tree.

and a partridge in a pear tree ;)