AltME groups: search

Faster floats branch released: https://github.com/dockimbel/Red/tree/faster-floats

For people wondering what I was working on these last couple of month, 
here's a screenshot of the customer app I'm finishing now: http://sidl.fr/tmp/generator01.png


It's a visual editor for trading strategies that emits MQL4 code 
for Metatrader-based solutions (FOREX trading). The tree is editable 
and redraws itself automatically (no need to drag all the nodes around 
manually). This app also relies on an intermediary DSL for serializing 
the strategy on disk or before compiling it to MQL4. Here's an extract 
from the corresponding dialect representation of the tree from screenshot: 

start on 1 
if 1 buy 5 take 10 stop 10 on-profit [
    buy 6 take 10 stop 10 on-profit [
        buy 10 take 10 stop 10 loop
    ]
] on-loss [
    sell 7 take 10 stop 10 on-profit [
        buy 4 take 10 stop 10 loop
    ]
] 


All is done in REBOL/View 2.7.6 (to avoid CALL bug in 2.7.8) and 
all the source code is 47KB (25KB for the custom styles and VID events 
callbacks).


I'm at 99% completion of that app, so I've resume the work on Red 
since a couple of days.

Actually, I wrote a small lib to perform the 64-bit arithmetic ... 
but I only needed subtract and divide.

it's at:

https://github.com/PeterWAWood/Red-System-Libs/tree/master/Int64

Kaj: I've tried compiling from different folders (out of Red/ tree), 
with both absolute and relative paths to %rsc.r, the compilation 
goes well. The only issue I see is that the final binary is in Red's 
%builds/ instead of local folder. I guess I should change that to, 
by default, output the binary to same folder as program source code.

That also means you don't want to change into the Red tree to start 
the compiler

Ok, I've reproduced the issue with a Red/System program not located 
in Red's tree.

Here we go: https://github.com/dockimbel/Red/tree/v0.3.0/red

REBOL code profiler released: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r


Should work with any REBOL app. Documentation, comments and example 
included in file header.


Hope someone will pick it up and improve it (like adding functions 
sub-tree stats and a GUI). This is github, so feel free to fork then 
fix/improve.

it would be nice to formalise, e.g. to have /bindings subdir, where 
partricular systems would be represented by subdirs, etc.


We already have some place for that since many months (it's the /library 
folder): https://github.com/dockimbel/Red/tree/master/red-system/library

Hi Kaj on my macbook:

Last login: Fri Oct 19 07:21:16 on 
ttys001

 MacBook-van-Arnold-160:~ Arnold$ 
 /Users/Arnold/Downloads/Red\(/System\)\ 
 Testing-dc1b702068063b65/Darwin/Red/hello 
 ; exit;
Hello, world!
§±ÖÁµ, ºÌüµ!
`O}Y, NLu
Dobrý den sv
te
logout

[Proces voltooid]

 /Users/Arnold/Downloads/Red\(/System\)\ Testing-dc1b702068063b65/Darwin/Red/Fibonacci 
 ; exit;

MacBook-van-Arnold-160:~ Arnold$ /Users/Arnold/Downloads/Red\(/System\)\ 
Testing-dc1b702068063b65/Darwin/Red/Fibonacci ; exit;
Fibonacci 35: 9227465
logout

[Proces voltooid]


MacBook-van-Arnold-160:~ Arnold$ /Users/Arnold/Downloads/Red\(/System\)\ 
Testing-dc1b702068063b65/Darwin/Red/empty ; exit;
logout

[Proces voltooid]
I took the programs from the Red tree under Darwin

Completely agreed 0 does not exist, even not for computers. A computer 
with 0 memory does not have memory at address 0 either :)

Counting starting at 0 is nonsense. No matter who and how many times 
it is explained. In human/fysic world we only put letter 1 in envelope 
1, letter 2 in envelope 2 etcetera, there is no letter 0 to put into 
envelope 0. It is only a confusing trick to start at 0. (I know you 
can look at memory like a binary tree) In these days of plenty of 
memory, I say let location 0 unused. Besides for who was REBOL meant 
initially? People. Scientists not computerscientists. Let those struggle 
with C and the likes. 1-base is one of the big plusses REBOL has 
over the majority of other languages. (enough bikeshedding from me 
today)

I always had mixed feelings about it, on one side it allows to extend 
objects in-place, which is very useful when they are referenced (in 
a tree structure for example), but it also encourages a, IMHO bad 
coding pattern, which is using objects to store data when you should 
use (the much cheaper) blocks instead.

the following are currently invalid REBOL notations (the first three 
load in R2 but get scrambled)

I prefer the first tree, since they are pretty obvious without any 
knowledge of the language.

16#FFFF000F
8#7124554764
2#0110110101

H#FFFF000F
O#7124554764
B#0110110101

No, it strips any ../ prefixes from relative include paths and then 
looks for them in the compiler tree, instead of just using them relative 
to the location of the source file

The Red directory in my example has nothing to do with the compiler 
tree. It's just the parent directory in which I keep my projects. 
I want include paths to be relative to the source file, not the compiler, 
be it Red or Red/System

It would be very useful to have a search path for includes that could 
include directories elsewhere, possibly in the compiler tree, but 
it should start by checking relative to the source file

Curses binding for Red/System released: https://github.com/dockimbel/Red/tree/master/red-system/library/curses


Big thanks to Bruno (a new french contributor) for this nice work!

So, how does it work? When you need to interrupt the flow of code 
in a function in Red/System, currently you can just use EXIT/RETURN 
to make an early exit. But, sometimes, you need to go up through 
several nested calls, that's where the new THROW function comes handy. 
It will interrupt the execution and go up the call tree to find the 
first function that has the CATCH attribut set. It will then just 
resume execution after the last function call (from which the exception 
has been generated).


If no CATCH attribut is found, it will go up to global code and resume 
from there.

ZLib binding for Red/System released by Bruno:

https://github.com/dockimbel/Red/tree/master/red-system/library/zlib

First release of prototype low-level bridge with Java world:

https://github.com/dockimbel/Red/tree/dyn-lib-emitter/red-system/bridges/java

Pushed it in new rsrc-support branch: https://github.com/dockimbel/Red/tree/rsrc-support

That base should be enough for a start, the hard part now is to generate 
the resources tree with all the right entries ...far from easy.

Red/Java bridge prototype released: 

https://github.com/dockimbel/Red/tree/dyn-lib-emitter/red/bridges/java

Hmm, new commits are in different tree, not merged into dyn-lib branch 
yet?

How is that I can't see e.g. bridge.java in here? https://github.com/dockimbel/Red/tree/dyn-lib-emitter/red-system/bridges/java

I can get to it only via your second posted link, which instead of 
dyn-lib, shows "tree: 5d43ad443a" ....

So from that page, I get to https://github.com/mxcl/homebrew/tree/master/Library/Formula

a long list of stuff. Down there, I see gtk+.rb, click it, and I 
get to a page, which seems to be some description (or recipe, as 
you mentioned). Then what?

I created an account on the red.esperconsultancy site hoping it would 
bring a little more possibilities in browsing up the tree. This was 
not the case. I am sure that it must be there somewhere but you have 
to know or have a link or own the server ;)

(@Peter, your last question is to Bo about his print-line statements 
I presume.)

https://github.com/dockimbel/Red/tree/dyn-lib-emitter/red/bridges/android/samples/eval

I've found the trailer better than the movie, I was quite disappointed 
(I'm a huge DC comics fan)...the "epic" moments weren't that much 
epic to me, so the whole movie (2h30) was a bit borring...The Krypton 
civilisation and display technology were the most interesting parts 
to me. ;-) Actually, the movie reminded me a lot the "Tree of Life", 
like a mosaic of sequences, and with almost the same soporific audio 
track... No real breathtaking moments...Even the mandatory "love 
story" sounds fake... The fx +  3D was too much to me, you're quickly 
lost in the fight sequences. But that's just my opinion, others might 
like it very much. ;-)

www.tree-mapper.com 	First releas of the web-page for our new product. 
Done with R3. We will add more and more over time.

www.tree-mapper.com	Email notification option added. More screenshots. 
Demo version can be downloaded.

head-map: Yes, common term. The tool actually does tree-maps.

I have seen that, but what I was asking about is the actual source 
tree that Saphirion is using. I got the impression from Robert, some 
time ago, that it was somehow being 'cleaned up' and would be made 
public in some way.

Perhaps it helps to learn about the mechanisms: There are several 
ways to generate a dynamic UI:


The LAYOUT function works by creating an object tree, a tree of faces 
that are simply ordinary objects. When passing this to the VIEW function, 
a layout is displayed. The layout function is part of VID and is 
as such a high level function. VIEW is a low level function to interpret 
the face tree.


The face tree consists of objects that contain other objects through 
the FACE/PANE word. If the FACE/PANE contains an object, that object 
is a single face, that is displayed inside the parent face. If the 
PANE contains a block, that block may contain multiple objects that 
are simply multiple faces. As such, a typical window is a face with 
a FACE/PANE that is a block that contains other objects.


Graphically, the face is represented by a region on the screen that 
has the size and offset, possibly an effect, such as coloring, blur 
or mirroring or a text attached to it, and image or other faces that 
are only visible inside that region.

A window is also a face.


To navigate to the parent face from a face, use the FACE&/PARENT-FACE 
word. Note that FACE/PARENT-FACE is many times not set by VID, which 
is sometimes problematic.


You can manipulate the face tree by adding removing objects dynamically 
and calling the SHOW function. You can also change values in existing 
face objects in the tree, such as for resizing or moving the faces 
and then calling SHOW again. You can also build a face tree entirely 
by hand, and this is usually the starting point for different layout 
engines, such as RebGUI, that simply build face trees in their own 
way.


The prototype face is FACE, which is a minimum requirement face for 
the View engine. The prototype face for a VID face, which contains 
a few more words, is SYSTEM/VIEW/VID/VID-FACE, which is the minimum 
requirement face for VID.


One condition for the face tree is to not use the same object in 
multiple locations. The VIEW or SHOW function will return an error 
if that is the case.


A simpler way is also to generate a new face tree every time you 
want to change the layout. Although this is slightly more computationally 
heavy, it allows you to manipulate the block that was passed to the 
LAYOUT function instead of manipulating the face tree directly. This 
technique is best used, when the face tree changes dramatically by 
each manipulation.


Another important concept is the DRAW engine which is a separate 
entity in REBOL2. It can be called to draw on an image bitmap, using 
the DRAW function or as in effect for a face object, by adding a 
parameter in the VID dialect block or by changing the FACE/EFFECT 
word. DRAW is used by calling a dialect. if you just want to use 
fields, buttons and simple user interface designs, you may not need 
to use DRAW.

I got an idea from a friend. So I got ready to start my two scripts 
(maybe someone wrote smth similar???) - one window; left pane has 
file system folders tree with top at the script's dir, right pane 
has some content. I want two scripts, every of them is a standalone 
app for its own like-minded audience: 1) plaintext.r, and 2) activetext.r. 
The plaintext.r will have right pane editor for plain text, saving 
it on the fly while editing (when the window is navigated away or 
closed, the text is saved); and activetext.r which has a plaintext-with-rebol-applets 
or .r content at the right pane.

Unknown word or style: tree
Unknown word or style: textarea

REBOL [Title: "rtext.r"]

view layout [treepane: tree contentpane: textarea] 400x400

hmm. How to display a tree of folders and files in REBOL???

There are some scripts that do that in the script library:
   www.rebol.org/search.r?find=tree

...bloated platforms include tree components by default...

For a complete package that has a tree view (rather than a separate 
component), try rebGUI:
   http://www.dobeash.com/RebGUI/widgets.html

But remember that the panel block as described with [across space 
0x0 label "_" ... etc. is only a description. Adding something to 
that block will not affect your current layout. The LAYOUT function 
parses the block into a tree of objects (faces), which then can be 
displayed with VIEW.

So, you either re-build that layout, or you manipulate the face object 
tree directly.

you can make it a bit smoother than that by wrapping the whole thing 
in a panel and assigning a new face tree to that panel every time. 
Then you won't need to close and reopen the window.

Thanks for getting back to me on this Doc...
So if i have this correct, I should:
1. Use the latest version from Cheyenne (have made a copy)

2. Remove all services and protocols from the %services/ and %protocols/ 
folders, except for task-master.r (which i need!)

3. Now hopelessly confused - the UniServe directory tree of the latest 
Cheyenne version I have is as follows:
     Uniserve
     ---clients
     ---libs
     ---protocols
     ---services
         ---task-master.r
         ---task-master
             ---task-handler.r
     I don't see a %UniServe/handlers folder...

note from the python code that there are styles and javascript specified 
inside the <p> element!
i was wondering about Gabrielle's HTML niwashi tree

#! /usr/bin/env r2
REBOL []

here: what-dir

program: dirize clean-path here/../../../cms/files/program/PowerMezz

do program/mezz/module.r

load-module/from program

module [
	imports: [
		%mezz/trees.r
		%mezz/load-html.r
		%mezz/html-to-text.r
	]
][
;	print mold-tree load-html read http://osslo.nl/leveranciers

	make-dir %data

	for id 1 169 1 [
		print id

  page: load-html read join http://osslo.nl/leveranciers?mod=organization&id=
  id


  content: get-node page/childs/html/childs/body/childs/div/childs/3/childs/2

		body: get-node content/childs/table/childs/tbody
;		print form-html/with body [pretty?: yes]
;		print mold-tree body

;		item: get-node body/childs/10/childs/2
;		print form-html/with item [pretty?: yes]
;		print mold-tree item
;		print mold item

		record: copy ""
		short-name: name: none

		unless get-node body/childs/tr/childs/th [  ; Missing record
			foreach item get-node body/childs [

    switch/default type: trim get-node item/childs/td/childs/text/prop/value 
    [
					"Logo:" [

;						if all [get-node item/childs/2/childs/1  get-node item/childs/2/childs/1/childs/1] 
[
;							repend record

;								['icon tab tab tab tab		get-node item/childs/2/childs/a/childs/img/prop/src 
 newline]
;						]
					]
					"Naam:" [
						if get-node item/childs/2/childs/1 [
							repend record

        ['name tab tab tab tab		name: trim/lines html-to-text get-node item/childs/2/childs/text/prop/value 
         newline]
						]
					]
...					"Adres:" [

      unless empty? trim/lines html-to-text form-html/with get-node item/childs/2 
      [pretty?: yes] [
							street: get-node item/childs/2/childs/1/prop/value
							place: get-node item/childs/2/childs/3/prop/value

							number: next find/last street #" "
							street: trim/lines html-to-text copy/part street number

							unless empty? street [
								repend record ['street tab tab tab tab	street newline]
							]
							unless empty? number [
								repend record ['number tab tab tab tab	number newline]
							]
							unless place/1 = #" " [
								where: find  skip place 5  #" "

        repend record ['postal-code tab tab tab	copy/part place where  newline]

								place: where
							]
							unless empty? place: trim/lines html-to-text place [
								repend record ['place tab tab tab tab 	place newline]
							]
						]
					]
					"Telefoon:" [

      unless #{C2} = to-binary trim/lines html-to-text form-html/with get-node 
      item/childs/2 [pretty?: yes] [
							repend record

        ['phones tab tab tab tab	trim get-node item/childs/2/childs/text/prop/value 
         newline]
						]
					]
					"Website:" [

      if all [get-node item/childs/2/childs/1  get-node item/childs/2/childs/1/childs/1] 
      [
							repend record

        ['websites tab tab tab		trim get-node item/childs/2/childs/a/childs/text/prop/value 
         newline]
						]
					]
					"E-mail:" [

      if all [get-node item/childs/2/childs/1  get-node item/childs/2/childs/1/childs/1] 
      [
							repend record

        ['mail-addresses tab tab	trim/all get-node item/childs/2/childs/a/childs/text/prop/value 
         newline]
						]
					]
					"Profiel:" [

      unless #{C2} = to-binary trim/lines html-to-text form-html/with get-node 
      item/childs/2 [pretty?: yes] [
							repend record [
								'description newline
									tab replace/all

          trim html-to-text form-html/with get-node item/childs/2 [pretty?: 
          yes]
										"^/" "^/^-"
									newline
							]
						]
					]
				][
					print ["Onbekend veld: " type]
				]
			]
			write rejoin [%data/
				replace/all replace/all replace/all any [short-name name]
					#" " #"-"
					#"/" #"-"
					#"." ""
				%.txt
			] record
		]
	]
]

SQLite version 4 announced/proposed. The default built-in storage 
engine is a log-structured merge database instead of B-tree in SQlite3. 
As far as I understand the docs This store could be usable standalone 
or use SQL frontend. Google to SQLite4.

Scot, Saphirion's R3GUI is used in our Treemapper application: http://www.tree-mapper.com/


It's a bit ugly right now, because I haven't had time to work on 
the skin yet.

Could you all please test the https://github.com/BrianHawley/r3-bh/tree/length-embedded-script
fix? Carl wants more testers before he accepts the https://github.com/rebol/r3/pull/40
pull.

The source for w_readline is found here:
https://github.com/Geomol/World/tree/master/src/host

R3 extension will open the door to many usefull extensions now. We 
should collect the current status of existing extensions and of course
new ones we like to see. 
Quick check on current extensions (lib based) :
cURL, ZMQ, ODBC, FMOD, IMagick...


Another area is what is the best practice to create and maintain 
embedded extensions, how to integrate a dynamic built for this how 
to organize the source tree.

Currently I am working on a embedded cgi extension as a testcase, 
this will lead also into questions like: mezz or native, embedded 
or lib?

Extensions on my list:
CGI, JSON, POSIX, PCRE and some math libs.

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?

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.

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

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:

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)

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 think it would be very cool to have a DOM tree browser written 
in REBOL)

Yes, a DOM tree browser would be very cool.

and a partridge in a pear tree ;)