AltME groups: search

hmm ... have you looked at Lingo? I wonder if you can produce dependency 
tree using such dialect? It could be imo done. I mean e.g. - don't 
start clip2 unless clip1 is finished or logo is moved already to 
position XxY etc.

thanks.  Andreas told me he was reaching 70fps using the simple tree 
demo running wine on linux!

the heavy tree is quite hard... the torus should be real-time even 
using software mode.

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

SQL is likely to be overkill for AltME data -- especially as some 
posts are very short (LOL) so the meta data and keys are several 
times the length of the primary content.

We picked a different data structure to all-or-nothing in the REBOL.org 
archive (more of a balanced tree), but then we had a different set 
of priorities and operating conditions:
  http://www.rebol.org/aga-display-posts.r?post=r3wp151x4488

I looked up an old post (2007) talking about how to start Altme Worlds 
on windows start-up. Brock had the answer but I could never get it 
to work. Three years later, I decided to try again. Here are some 
lessons I learned along the way:

Precautions:

You may want to back up the altme folder just in case something goes 
awry. You will also need to know where the files are located.

You may also want to create another temporary worldmaster user and 
note the password. If you're like me, it has been a long time since 
I had to type in the user password.


1. Before you turn off your worlds, go to http://www.altme.com/check.html
and check your world(s). Note the port number and write it down.

2. Create a shortcut icon on your desktop to altme if you don't already 
have one. Do this by right clicking on altme and select "Send to/Desktop."

2. Right mouse click your "Start" menu (I only did this in XP so 
adjust for any changes you might have in your OS) and choose "Explore." 
An "explorer" window will open.

3. Go to the "Start Menu" folder in the the explorer folder tree 
in the left column. In the right column open up "programs" then open 
up "Startup."

4. Drag the altme shortcut icon from the desktop to the startup folder.

5. If you have more than one world, right-click on the just added 
altme shortcut icon and rename it to something like altme-worldname.

6. Show the properties of the just added altme icon by right-clicking 
and choosing properties.

7. There, in the "Target" field, you will add on to what should already 
be there. It should have something like: "C:\Program Files\altme\altme.exe", 
telling the OS where to find altme and the name of the actual program. 
As you may know, the quotes are there because the "Program Files" 
folder has a space in it. Leave it as is and add:

-s "yourworldname" - p the-port-number. E.g., "C:\Program Files\altme\altme.exe" 
-s "myworld" -p 5402. Do not close the properties window but continue 
to the next step.

8. Below the "Target" field you will see the "Start in" field. There, 
enter where altme and its server files exist. The top level folder 
is enough. E.g., "C:\Program Files\altme\" 

9. Apply the changes to the properties and try it out by making sure 
the world is not running and then clicking on the altme icon in the 
Startup folder. This saves you from having to reboot if a mistake 
was made. You should see the familiar altme server window pop up.

10. You need to also check by logging into the world through the 
client. If you can and the data is all there. Great. The only thing 
left is to reboot and make sure it loads by itself.

11. Repeat for all the worlds you have. You'll end up with n altme 
icons each with a different name. 

Things that went wrong:
Before the server could be launched properly via the icon

1. Getting the wrong syntax in the properties/Target. - I thought 
everything had to be enclosed in a single quote string but it doesn't.
After the server was launched

1. Couldn't connect to the altme world - Seem to be related to the 
port #'s I was using. I went back and launched the worlds the manual 
way and checked the ports on the altme website.

2. Could connect but no users. - This had to do with "Start in" info 
or lack thereof. Altme was looking for the data in the Startup folder 
as opposed to my regular altme folder. Your actual data should be 
fine and of course you made a backup, right?

3. Some data (posts) got mixed up - Who knows on that one. I made 
so many attempts, I may have confused something.

4. My user profile was gone or had a different name. - Again, my 
guess is that this was due to the "Start in" info. Worst case, try 
the default "Master" "pass" user. I ended up using another known 
user (hence, my advice to create a temp worldmaster user), then I 
renamed the user I knew was me to me. Weird but it happened in a 
couple of my worlds but only to my profile.

5. I made a copy of the actual altme.exe and named it altme2.exe 
thinking that perhaps this was the problem. The target was then changed 
to reflect it. Don't do this, it  is not necessary and may freak 
you out.


Now I have 4 worlds up and automatically running when I need to reboot 
the server. Yea.

So not linear, but a tree. And you use blocks as lisp-pairs.

In this case i would not cons a new tree, but change the old (or 
a copy of it).

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.

As I said - we need tree-view, grid (or little better list), tabs, 
group-box, and maybe even menu. Those missing styles will make it 
difficult to newbies to start using View as full-fledged dev-tool 
replacement ....

that controls can also access the sorrounding text. so they can influence 
the formatting of the following text, or fold it. Based on that they 
have even tree-views.

SteveT, using faces directly with MAKE is a lower level approach 
than LAYOUT. What LAYOUT does, is produce a face object that consists 
of many subfaces from your layout description written in the VID 
dialect. Each one of these face objects have settings for size, offset, 
appearance, text content, etc, which are set as the layout description 
is parsed. Using MAKE FACE directly provides greater control, but 
is more cumbersome to use, because you have to set all these values 
manually and arrange the face tree manually. You can see the content 
of the base FACE object in the console with:

>> ? face


The FACE object is the only object ever used, so it's a good idea 
to get to know it. You can extend it with more values and VID does 
this, to create variants, modes and extra operations on a face, like 
SET-FACE, GET-FACE, etc.


The reason why many choose to skip VID for this, is that VID doesn't 
provide the level of control needed as some things can't be determined 
properly at layout time, such as interdependency of sizes or offsets 
between faces, which is why VID doesn't support easy resizing out 
of the box.


Oh and when you get to try VID3 in REBOL3, forget everything I said, 
because it's a whole different system. :-)

LAYOUT produces a tree of objects. Each object is a face. VIEW displays 
that tree of objects.

LAYOUT is the VID dialect, which is REBOL's layout engine. When giving 
it a block of words, it produces a tree of objects, that each are 
a face. Each face contains sizes, offsets, colors, texts, event handlers 
and actions to perform when clicking on the face.

The tree of objects is then passed to VIEW, which displays the tree 
of objects as a graphical user interface.

mhinson, you've stumbled onto the first limitation. If we take the 
line of code apart, it does the following:

view								; view the created layout

 layout							; create the layout (object tree of FACES) from the 
 VID dialect block
		[						; start of VID dialect block
			button					; the first element, a BUTTON
				"ok"				; the text for BUTTON

    [				; start of the action block for the button. it's evaluated when 
    the button is clicked.

     name: get-face face	; get the value of the button through the buttons 
     GET-FACE accessor
					print name		; print the value (likely none)
				]				; end of action block
		]						; end of layout block


Now when I say limitation, it's because you can't easily check for 
mouse button up, release, mouse movement, etc. The VID dialect directly 
uses a block right after the button description to describe what 
should happen after clicking the button. That's part of the syntax 
and above I wrote it as:

	<face style> <face text> [<action>]


You can specify size, color, edge size, background image and a few 
grahpical effects.


And with it being a dialect, you can leave things out or swap the 
ordering of some parameters.


If you want more advanced control, you need to use the FEEL object, 
but you are definitely not ready for that. :-) Settle for working 
with VID and some layouts like above. VID was designed to be easy 
and very fast to use. If you go beyond VID, you will need a whole 
lot more knowledge on how to do things.

oh, that was simpler than expected. Thanks very much.  I must say 
I dont think Rebol is very easy to learn, but once all these tricks 
are known it must be very easy to write things quickly.  Perl is 
like a tool shop & a tree for wood, while Rebol is like a high street 
full of all sorts of shops as well as tools.

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

doh... when you're too close to the tree... you can't see the forest... 


I was using TO parse command on a rule ... this obviously won't work....

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

That's right, Syllable is not Unix. Indeed there is no /mnt directory. 
There could be, and like Unix, volumes can be mounted anywhere in 
the file tree, but the convention is to mount volumes in the root: 
/

Searching for instructions to build sources tree.

I need to build my own hacked source tree

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.

On the twiki site http://twiki.org/cgi-bin/view/Plugins/GenPDFLatexAddOn

I found this

#  Setup the Latex rendering software


    * Ensure that a latex document preparation system is available to 
    the user name (uid) running the twiki web server.

    * Install any custom latex style files needed. The best suggestion 
    is to create a local texmf tree accessible by the server. For example, 
    for an apache server running as 'nobody' on a linux system:

          o create the directory /home/nobody/texmf/tex/latex, with reasonable 
          permissions.

          o Place the custom .cls and .sty latex files in this directory

          o as user root or nobody, run texhash /home/nobody/texmf to create 
          the ls-R latex database file for the /home/nobody/texmf/ tree.

sudo apt-get install xfonts-100dpi xfonts-75dpi
[sudo] password for gouslar: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
xfonts-100dpi is already the newest version.
xfonts-75dpi is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Ok

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.

Hi all,


After learning a lot from you all I feel like I should contribute 
a bit.

On http://alain.goye.free.fr/rebol/or on Rebol Desktop's "AGReb" 
Reb site,
you can find:


- an updated version of %NoteReb.r, a REBOL tree-like notes organizer,
similar to and compatible with http://www.treepad.com/.

This new version of NoteReb.r has quite more functionalities; I use 
it to

work. A major bug seems to remain when intensively using the "undo" 
function
of Romano's edit-text-undo.r , which is quite nice despite that.


- a simple todo list, %todo-ag.r, which orders tasks by priority 
based on
their importance, workload and deadline...


If anyone likes these please drop me a line, and if you improve them, 
all
the better!

Alain.

Some core Twitter API functions: http://www.ross-gill.com/r/twitter.html

	? twitter
	tw: twitter/find #REBOL
	twitter/as "rgrebol" "****"
	fr: twitter/friends
	new: twitter/update "Now"


Results are XML objects - see http://bit.ly/xml_rebol(probe result/tree 
for structure).  Will add more at some point.

http://twitter.com/rgrebol

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

Shadwolf/Tree-Widget: I used Cyphre's one. The main trouble I found 
out is changing the tree. A path access structure would be nice. 
Things like: add-entry tree/1/2/3 "New Entry" or with a named path: 
my-tree/material/copper/price or so.

I'm looking forward to see a tree-widget in RebGUI. This will make 
it mostly complete for a good bunch of applications.

To menu or not to menu. Menu widget, as well as tree one, is a case 
for subdialect. Just go and look at Cyphre's one. You just use sub-language 
to define it - item, action, icon, accelerator key, position in structure 
(block of blocks) etc.

Ok, those were icons vs. menu. As for tree-view, menu, grid data 
blocks. It is still the same problem, of how to efficiently use rebol 
structure (block of blocks) to represent tree (=in the meaning of 
hierarchy here). If we think twice, we can see that similar discussion 
is being held in XML group. We parse XML, and want to store it somehow 
efficiently, being able to navigate to some path(node), to read some 
item, but also to change it etc ...

just my 2cents regarding menus: what I really would like as well 
is what Robert told about, circle menus. They're far better than 
rectangular menus (in most cases anyway used for  context menus). 
The big advantage is, if done correctly that one can use them blind 
via forming a habit. This means of course that the content must not 
change (anyway a principle a good UI should obey). So one can simply 
right click (or whatever action to activate the menu) and go with 
the mouse in a certain direction and release, all in a fraction of 
a second and be sure to have selected the right item. For beginners 
the menu can appear and be visible, but for somebody who formed a 
habit it doesn't even have to be long enough visible to actually 
see it - because the whole item selection was faster than that it 
could appear.

One of the drawbacks is, that one can't put as many items as in a 
rectangular menu, best is 4, but maxium probably 8 items if there 
are 8 sectors for the circle. But I like to think about it in that 
way that one can form the mouse menus more levels (probably only 
two make sense), in that way that after selecting one item a second 
circle appears which can offer more choices. And because this can 
get habitual again it's very userfriendly for both experts and beginners 
without forceing either to something. For instance I think the useability 
of Operas mouse gestures is an example for tree menus which don't 
even appear. But in principle one could think that upon pressing 
the right mouse button a circle appears and moving to the item downward 
opens another menu so that moving again to the right selects the 
close window item. The only problem with submenus might be that it's 
kind of hard to find a good middle way for the distances the mouse 
cursor has to travel and error tolerance.

Wouldn't that be really something worth implementing in Rebgui ? 
:-)

Does anyone have Tree View Face in REBOL? Thanks.

tree view is one of the some other widgets i plan to make but ( there 
is allways a but)  i would like to make it svg compliant for  symbols 
(but this can be done after wise) what is important for me is the 
ability to set a symbol system (you can use default one or give your 
own symbols for group leaft),  auto show of the slider according 
the level of it , function that handle the selection when you clic 
on a leaf you can or get it's value and post treat it or run a callback 
called on leaft clic event  the last point is the data structure 
common structure used by many many prjects is [ "group_name" [ "subgourp" 
[ "leaf1" "leaf2" "leaf3"]] "goup_name2" ["leaf" "leaf" "leaf" ] 
] if text is followed by a block! this means the text is a gourp 
label other wise it's a leaf label

group-box: Today an other idea striked me for group-box. How about 
a way to collapse the group-box like a sub-tree in a tree control? 
With this a GUI could be make very dense and only those parts expanded 
that are currently worked on.

This approach is good for top-down approaches in applications.

Robert: I'm using hypernotes for this. There's tree-list on left 
and you can define whatever layout you want with VID tag. I also 
patched hypernotes with SCRIPT tag so I can write code in hypernotes 
and script is generated automatically.

Rebolek, is/could the tree-list be made RebGUI compliant? That would 
be really great!! Especially the idea with the VID tag and the SCRIP 
stuff.

graham - do you miss tree-view with your apps? just curious ....

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 could be a good base for a remote Wiki editor. Just add an HTML 
generator to convert to static pages tree.

I'm sure I don't want VID improvements before of rebcode.... I want 
CORE with rebcode first... And I really hope that some release  will 
not be postponed just because there is no  new tree-list GUI or something 
else

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 majority of the code in rebol follows a straight line. But you 
can make that straight line have a twist depending on the order of 
evaluation for some expressions. Which a compiler can predict. Because 
this predictions can be broken with any function call the compiler 
must  pick one branch of the call-tree. Which may not be what the 
programmer intended.

The exponential problem of compiling a call-tree becomes impractical 
as the number of functions increases. There are some techniques to 
mitigate this, but rebol is atypical in the sense that his CFG lacks 
any punctuation. Without punctuation there is no easy way to determine 
where the expression begin or end.

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.

Something to consider for REBOL 3: The current implementation strategy 
for symbols in REBOL has significant limits to the possible number 
of symbols available at one time. It might be a good idea to try 
a red-black tree for symbols instead - newLISP uses that strategy 
and can handle millions of unique symbols efficiently.

The difference between binary search trees and red-black trees is, 
that the latter only have O(h) if the height of the tree is small. 
Red-Black tries are balanced and hence can guarantee O(lg n) times. 
But there exists many other search-tree schemes that hold too.

but look at my last post and the code example  its VERY simple... 
if I had had THAT 5 years ago, I would have been able to build up 
from REBOL to be able to at least support an array of data from the 
start and then try to understand the concept of the grammar tree.

actually not a dialect, it just converts a View object tree to postscript. 
it's used in the same way as to-image is on a layout.

because that is handled at the View level. text wrapping information 
is not available in the layout tree.

perhaps the layout tree is different for rebgui

all to-postscript.r does is go through the layout tree and renders 
each object as a postscript color box with a text box on top of it. 
face values are just mapped into postscript.

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.

so instead of having a kernel using a stack its using a tree.  Am 
I right in saying that  this is a shift from the turing machine? 
 :-)

The engine will use liquid's flexible interpreted messaging overlayed 
on the other graph engine which I will use for scalability in sheer 
volume of connections and nodes I can allocate.  just a portion of 
the tree usually needs to be in RAM at any given time, and in fact, 
parts of processing tree can now reside on different computers since 
the graph engine is refered to... it should be quite fun to use.


this will be tied in to the OpenGL and scream core scene-description 
engine as one cohesive toolset.


in this system, the binary nodes will actually be optional and should 
be invisible when used from the rebol application's point of view.

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.