AltME groups: search

Two consecutive runs cause following:

>> do %opengl-complex-tree.r3
Script: "Untitled" Version: none Date: none
Script: "Untitled" Version: none Date: none
IMPORTING LIBS
CANNOT SET CGR LIB MORE THAN ONCE (cgr_opengl.dll)
====================================
OpenGL CGR initialization:
registering polygon primitive
register-primitive() [
        valid-prim?() [
        ]
        cgr-name() [
                OpenGL
        ]
]
====================================
Script: "Untitled" Version: none Date: none


then it stops for a while, then it shows window, and outputs other 
stuff to console ....

if you are showing the tree-heavy, its a 170000 vertice model which 
ways 15mb on disk and 50mb in ram !

on my system tree-heavy averages 8fps at any window size. 


the reason its this slow is that I'm not using any kind of smart 
opengl video ram caching atm.  this will obviously be done in time... 
for now I still need to implement things like a real camera primitive, 
lights and materials.

With the heavy tree I have 20fps but I can hear strange sound from 
my notebook.

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

%opengl-test.r3 ran fine.

%opengl-simple-test.r3 crashed after a few seconds:

@** Script error: cannot access window in path event/window/data

** Where: all -apply- wake-up loop -apply- wait forever catch either 
either -apply- do
** Near: all [
    obj: event/window/data
    obj: select obj 'handle...

Same error for complex tree.


Happened on torus too, then I figured it out. The error occurs if 
I move the mouse over the animated area. Other than that, it looks 
very cool Max.

gregg, that looks like an older version of the distro... the new 
files are:
opengl-torus.r3
opengl-simple-tree.r3
opengl-complex-tree.r3


also the error looks like something I patched in r3-gui.r3 not handling 
data-less gobs... did you update/change your r3-gui.r3 in the distro?

Max, I'm expierencing the same flickering as Adrian does, I'm running 
on a 3/4 year old Sony VAIO with Win7. I can't supply any further 
detail, I'm don't have access to the machine right now. I see a flickering 
torus , a flickering  simple tree and no complex tree at all. When 
I'm back at the machine, I'll try with the AA settings which Adrian 
seems to have identfied as the source of the confusion in just this 
moment.

Transfering memory based hash! (map! in R3) datatype into disk based 
shema automatically keeping the hash table computation and lookup 
hidden from user gives you a RIF. Holly grail of all rebollers :) 
long long time promissed, still waiting to be done. Anyway hash tables 
are always usually unsorted, when necessary to search in usually 
some type of additional index is used (B-tree for example), for simple 
information if the key is in the set, bitmap vectors are used with 
advantage, when the set is really big (and bitmap vector doesn fit 
into memory) comressed bitmap may be used and usually bitwise operations 
on those vectors are much quicker than on uncompressed. 

Thisi is why it should be used for bitset! datatype anyway. The number 
of byte aligned (BBC,Packbit,RLE)od word aligned (WAH) schemes exists. 
 It is used in very large datasets when index also resides in disk 
file. Once again bitwise operation may be much quickier even in memory 
on those schemes.

thanks why didn't I think of that

to close to the tree to see the forest   :-/

you mean as in deep searching a tree of blocks ?

It is purely of syntactical nature, a tree of blocks (and parens) 
and scalar values.

G raham a suffix tree may be what tou want for trem compleation

So, all I need is to write a function that takes my data and builds 
the tree ...

Thanks for the link. Seems like I did some kind of tree way...

- MAJOR ANNOUNCEMENT -  Custom Gob Renderers :  prototype released


After weeks of work at various levels, here is the first prototype 
release of my R3 host-kit running OpenGL in HW.

http://www.pointillistic.com/open-REBOL/moa/files/r3-cgr.zip


I updated it to A109 this week-end, I also completely rebuilt the 
file structure so that all of my tools are outside of the host tree.

only the actual host-code patches remain within the host.  the distribution 
includes compiled versions as well as the latest R2 2.7.7 unreleased 
patch.


note that the current OpenGL CGR is not currently very programmable 
a part from giving it polygons to view, you can't change anything.

the view will rotate by 1 degre everytime you call show or refresh 
on it  (so it can be used for model turntables).

resizing the window resizes the view.   notice that full-screen doesn't 
affect rendering that much.

open the readme file for more information


also note that the current geometry engine auto-calculates surface 
normals using face normals, so you'll have a faceted look.

next release I'll add support for vertex normals which will allow 
smooth shading (at no cost).


please reply in ann-reply, and report any problems you may have... 
I'll fix ASAP.Custom Gob RenderersCustom Gob Renderers

is this a complete Notepad++ source tree that I can build?

----------------------------------------------------------
mod-web-api (v0.5.0)   released !
----------------------------------------------------------
An extensible, programmable webservice module for cheyenne.

http://www.pointillistic.com/open-REBOL/moa/files/mod-web-api-r2.zip

Docs are here, temporarily, until I setup my web server again:

http://www.pointillistic.com/open-REBOL/moa/files/mod-web-api/docs/mod-web-api.html


Installation and setup is all covered in the docs, but in fact, its 
just a question of dropping the file trre right over a cheyenne directory 
tree.
a demo is included as well as a http.cfg file to enable the demo.


it takes 5 minutes to setup and run the demo, as long as you've got 
port 81 free.

trre=tree

I've updated Scite version 3.0.1 with my version of the REBOL lexer 
(which is also available in the menu in this version - it's not in 
the official release)
https://github.com/Oldes/Scite/tree/v301

There is probably nobody here who can find it useful, but I've uploaded 
new XFL related scripts:

https://github.com/Oldes/rs/tree/master/projects-rswf/xfl-clean/latest

https://github.com/Oldes/rs/tree/master/projects-rswf/xfl-combine-bmps/latest

The first one we use to clean XFL sources, the second to merge bitmap 
assets into pow2 textures.

to close to the tree to see the forest       ' :-/

As I said, the main case use is serialising tree structures with 
mixed nesting.

the root problem for all of this lies in the archaic tree structure 
file systems.

as an example, we could just represent a draw structure using primitives 
as objects (which can include several AGG primitives) and call AGG 
native code directly from the object tree.

something like 
draw context [
	prim: 'cross-box
	offset: 10x10
	size: 20x20
	thickness: 1
	border: black
	cross-color: red 
]


would draw a box and two cross lines, without the need to reduce 
this at every refresh when its refreshed and data comes from external 
manipulators:

draw compose [
	pen (prim/border)
	fill-pen none 
	line-width (prim/thickness)
	line-pattern none
	box  (prim/offset) (prim/offset + prim/size - 1x1)
	pen (prim/cross-color)		
	line (prim/offset) (prim/offset + prim/size - 1x1)

 line (prim/offset  + (prim/size * 1x0)) (prim/offset  + (prim/size 
 * 0x1))
]

off the topic, 

Gobs are not specifically related to graphics if they are not rendered 
(showed)

Gobs could be used to implement some efficient data structures, like 
linked list or tree.

As far I tested, dealing with structures of gobs is faster than with 
standard objets.

A really cool feature is that when a gob is append as a child to 
a gob, it's removed from its current parent automaticly.

the current code is a single ~16kb file,  so its not too large right 
now.


obviously as more types are added, this will grow, but since I'm 
using a "rebol-formatted intermediate source tree", its easy to improve.


the parser just generates a version of the C source in this "RFIST" 
format, and the generator only has to convert this into something 
else.


in time, we might even build different emitters for the "RFIST" data.

TAIL - INDEX looks better, thanks... btw.. https://github.com/Oldes/R3A110/tree/master/extensions/zlib

Updated Feb 21 http://github.com/gchiu/Rebol3/tree/master/protocols/

Pavel, I would not be surprised.   I have not looked at this stuff 
for over a year.   Yes, wik.is is now defunct and so my site is gone.
See https://github.com/gchiu/Rebol3/tree/master/protocols

I was just curious to see how Gab's systemm worked .. and I tried 
%test.r but 

>> do %test.r
Script: "Test vid" Version: none Date: none
Script: "REBOL View System Functions" Version: none Date: none
Script: "rewrite-tree function" Version: none Date: none

Script: "Simple dialect to create/resize gobs" Version: none Date: 
none

Script: "REBOL VID 3: Definition of FACE prototype object" Version: 
none Date: n
one
Script: "REBOL VID 3: Functions" Version: none Date: none
Script: "REBOL VID 3: Events Handling" Version: none Date: none
Script: "REBOL VID 3: Styles" Version: none Date: none
** Script error: cannot MAKE/TO map! from: none!

** Where: make either make handler parse parse-set-dialect make-styles 
catch eit
her either applier do catch either either applier do
** Near: make map! style-spec/options

Ashley, "just trying to understand why we still need the concept 
of faces under R3." - The role of faces in R3 are just what they 
were in R2, a collection of features and functions inside an object, 
but instead of the underlying View system being closed, they are 
now linked to a fixed set of GOBs, that we eventually can extend 
with all sorts of features. So:

R2:

Layout -> Face tree -> View

R3:

Layout -> Face tree -> GOBs -> View


Faces are what are generated by the layout. So the "face factory" 
is still needed and styles are the "molds" or prototypes. Within 
the face factory, the GOB factory exists. I would assume this separation 
makes HW acceleration or replacing GOBs with a different structure, 
much easier later. GOBs are redrawn using DRAW-FACE and that is handled 
inside the styles.


Styles use resources like fonts, colors, materials and standard draw 
blocks. This eventually helps skinning and abstracts these things 
away from the styles themselves.


The obscure FEEL object is replaced with a set of on-* actors that 
are run at specific times in specific sequences during runtime. They 
are more fine grained, so you can determine what you want to do, 
for example during various stages of face initialization.


The relationship between the layout dialect and faces is a bit different 
than under R2: you can't access the whole face in R3, only facets. 
For example the GOB itself, is not a facet and neither are internal 
states. So in order to change a deeper element of a style, you need 
to create a new style. This seems cumbersome, but is badly needed 
for large layouts, where we are semantically separating appearance 
from purpose. VID allowed this to be an organic mess. We may figure 
out a way to make creating derivative styles a bit easier.

There are a few changes in this, from the VID Extension Kit: All 
error generation is removed and replaced with NONEs. This was due 
to how VID is not pure enough a structure to work in. Consistency 
in the face tree for R3 GUI seems much better, but also because only 
a few styles exist and they all adhere to structure.

Does anyone know where in VID34 the entry to the face-tree is? I 
saw that win-face is set in VIEW but can't find any reference to 
it.

Robert needs this for an application as soon as possible. I can assure 
you that if things like GET-PANEL and SET-PANEL aren't working correctly, 
getting data in and out of the UI will be quite painful, worse than 
digging through an R2 face tree manually. But fortunately I spent 
these few hours yesterday, making sure it's easily done in a single 
line of code.

widgets should be organised in my opinion in 2 categories the first 
one are the "most used ones" not every one will put a tree view or 
a menu in his main windows but everyone will put  labels fields and 
buttons to most of their applications

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

Pekr, you need traversal code to move back and forth relatively in 
the tree.

Apart from the fact that I can't properly answer your question, my 
understanding is, that the team is working on all aspects of GUI, 
in following areas:


- low-level (in C) - new GUI is based mostly on AGG, some fixes and 
enhancements are going to be done. Carl, and Cyphre probably too, 
is also working on HostKit GUI isolation, so that the GUI can be 
fully open-sourced, becomes part of Host environment, and can be 
eventually replaced


- various GUI subsystems are being worked on - layout, resizing, 
keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, 
GUI transition effects, etc.


- GUI styles - new VID is supposed to be released with some advanced 
styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno 
about that one) 


- some other things come to my mind - browser plugins, video codecs 
etc. - good times ahead once we are there, but first things first 
:-)

and to traverse the pane of a face, you traverse the FACES block. 
the setup for the face tree is simpler to navigate than in R2, because 
you are for example not allowed to make that block into a face, I 
believe.

Henrik - it still has to be seen ... I require all keyboard navigation 
being OS compatible - can't wait to stress test tabbing, tree-view, 
etc. :-)

As for business apps - that sounds fine, it is just that we did not 
see e.g. list of styles, you might need. Is there e.g. a tree-view? 
Tabs? Table is there IIRC (there is a screenshot on henrik's site)

The reason why I am confused about priorities is, that you surely 
are not going to do business apps by using only buttons, fields and 
check-boxes. Areas, scrollbars, draggers, tabs, grids, tree might 
be usefull too :-)

I need a function to figure out the style tree. Will have to write 
it later. That would be part of the documentation.

Yes, style tree would be useful, but I think it's not top priority 
right now.

I hope soon enough we will be able to see fully working area, navigation 
by keyboard, tabbing system (including the ability to set the order, 
skip certain widgets, etc.), styles like tabs, tree (fully keyboard 
navigation support), table/grid (ditto). With those three styles, 
we can be kings ....

then how can we graphically represents it maybe the tree or node 
based representation isn't the best way that's why i want to speak 
with others and get several point of view on this topic ...

Yeah. The tree view on the left has been a good substitute for multiline 
tabs in recent preference dialogs.

I agree that the tree view has replaced multi-line tabs in recent 
years.

Maybe we need two separate things - style grouping (use gui/widgets 
for that), and style hierarchy - tree or other map of styles, their 
inheritance and dependencies (maybe this is what Rebolek now referst 
to as an object browser?)

ad 1) I can understand that, and that was also one of my worries 
in my initial post. However, as a designer/programmer, wouldn't you 
find usefull to have:


- something like tree-view (or node based visual display) of styles 
and their dependencies?


- wouldn't it help your orientation to have some list like guie/widgets, 
grouping particular styles, just for your info? So that you know 
that e.g. table is being built using xyz styles?

I am just asking - so no offense please :-)

1) It's possible to make the style tree, when the styles are being 
initialized. In fact I already have this as a separate script, but 
it has not been used lately.

Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?

The last one: Gobs with a face have the face assigned to the gob's 
data field, and the gob assigned to the face's gob field. Yes, this 
is circular, but this is because there are two tree roots. FACELESS? 
checks for that circular reference.

Are styles like tabs, grid, tree-view any close to release? Those 
are fundamental to any serious (mainly DB related) GUI developments 
.... I am asking, because I know that you kind of worked on something 
...

I think that talking a graph style, if we don't have tabs, tree, 
grid, is a bit preliminary. We need imo basic styleset, usefull to 
work with general DB apps, then we need more modern skin, and only 
then we need additional styles. We still can't see even concepts 
as accelerator keys being displayed, etc. :-)

it's simple, there's tree-like gob structure. that's all

Henrik - there's no why imo yet :-) From my POV it is very preliminary, 
and I would orientiate myself to:

- adapting existing styles to new R3 GUI engine

- adding styles most commercial guis will need - table, tree, tabs

- be sure all styles behave in a platform compatible way (especially 
area)
- reskinning/respacing the elements

- add support for ctrl-tab at low level to switch between the tabs
- fix all hard R3 crashes

later:

- add support for accelerator keys, but visually, and in the code 
(requires rich-text, most probably autogenerated, to underline the 
letter, but it could be done a different way to - e.g. displaying 
boxes with accelerator keys upon the styles and Alt key press)

- improve the text quality, that is NOT ACCEPTABLE for the 21st century!

even later:

- add some funky styles as Doc to make documentations, wikis, etc. 
:-)
- HW acceleration support where possible.

And now also - back to point 5, away from politics :-)


- New resizing model. Will API change too? Or is is just internal 
change, so I don't need to care about it, apart from knowing, that 
in some cases, resizing model will be more efficient?


- Is RMA building any commercial app using R3 GUI right now? Because 
I still might miss something, but style-wise I find it difficult 
to imagine, how it could be used. (Tables, lists, tree, area, tabs 
missing or buggy?)

CSS is clearly much more flexible in setups. You use tree of definitions, 
which are then applied in particular cases in document hierarchy. 
 If I am not mistaken, right now we don't have no easy way, of how 
to make e.g. first button in a last row of the panel e.g. red, unless 
you first define red button, and use it in the source of the layout 
:-)

Cyphre - I can simply imagine, how we extend stylize to allow such 
definitions. But - in terms of html, you have IDs, CLASSes, and you 
have also the document tree, so you might know, where to apply which 
part of an CSS. What I can't imagine is - we have layout flow ... 
and no ID, CLASS definitions, we also don't keep tree information 
of the layout (faces), or do we? So how do you instruct, in your 
layout, that first button in the panel should use button-red definition? 
Just curious about what possibilities there are :-)

why ID, when you can call face directly? And of course there's tree 
of gobs, that's how gobs works.

I suggest that classes in the R3 GUI is not useful for the reason 
that it interferes with the "intelligence" layer, where we already 
have:


1. tags to identify state and capability of a face, such as finding 
the default button in the window or whether the button is disabled.
2. name to identify a specific face

3. style name to identify the style and to create a distinct appearance
4. the ability to group faces by panels

5. have information about the ordering of faces stored in the face 
tree

6. use specific policies on how to act on a particular face with 
particular tags

perhaps the correct term is "merged into Carl's source tree".

Is anyone willing to try to develop a tree style?

Robert - I think that it is not accurate, that noone is interested 
in the R3 GUI. IMO we all are, it is just that each of us is busy 
elsewhere. If you look into the past of this group, or in the old 
GUI (Carl's one) old days, it was mostly me and 1-2 users to do some 
comments, studying code, etc. It is about the general lack of man-power. 
E.g. shadwolf claimed, he can do tree view in few hours, but is refusing 
to, and you better don't read the long blog chat. It is also about 
lost confidence of many rebollers into R3 in general. Or just maybe 
- ppl being in wait mode, untill Carl reappears?

As for me - "I would like to help", and I will at some point, at 
least with testing. But got my own project 2Zone moving, awaiting 
LED Screen arrival and needing to do many arrangements. I can't surely 
code tree-view,but I can test, even privately, for anyone who asks 
me. Not much next 3-5 weeks though ....

Robert: you are wrong.  As Pekr said many of us are waiting and busy 
with something else. I downloaded all the RMA R3 stuff, tested all 
GUI examples (found some crash problems btw) I really would like 
to help/write a tree style, but I'm not a good Rebol coder I'm afraid.
So please keep up the work.

having played with customizing the extension kit by merging some 
of the extension code into (on my own)... and building a generic 
call-back system for R3, I can see how it was a bit of a pain when 
Carl extracted View out of the core and put into an extension.  its 
not a trivial task and there are one or two things missing which 
where probably added to the last host kit and extension package to 
fill the gaps.


for one thing, Carl must have had to unify the source files and possibly 
re-organise a bit of the includes.  this is the kind of work that 
is tricky, painfull and extremely bug prone... with ZERO gratification. 
 it just craps out over and over, until you resolve all the dependencies, 
bugs, missing links and figure out how to re-organize code until 
the make tree "works".  


if it where just one OS/compiler it wouldn't be that bad for such 
a fluent C coder like Carl, but having to support ALL of them in 
a consistent way is very painfull and usually laborious.

So, is there a documented dependency tree somewhere ....?

but at same time what happend in R3 project is somewhat some of the 
coolest thing I ever seen a true complicity is rising between carl 
and rebolers. unfortunatly that's not the kind of things easy to 
communicate around. but yes 3 years of alpha stage because the reboler 
community really involved in the creation bringing at every steps 
their comments  etc ... so it's arsh to say that's a fruitless tree 
of efforts

Optimizing file deletes means first avoiding the standard DELETE 
func. It reads the dir each time which can kill you if you have a 
large dir or, heaven forbid, point it at an FTP location. You can 
build on CLEAR easily though.

    delete-all-files-in-dir: func [dir /local port] [
        port: open dir
        clear port
        close port
    ]


I think my tree deleters all rely on some of my other stuff, like 
FILE-LIST and DO-IN-DIR (now standard as IN-DIR). They generally 
have a callback option as well, so you can track progress.

Here's a possible example of use.  Carl could be assigned an oid, 
and then he could sub assign an oid from his root to Andreas.  Andreas 
can now uniquely identify each of his builds with an oid as can Carl 
with no overlap.  We can tell from the tree where they lie.

Sorry for cross posting this in different channels over the last 
year https://github.com/gchiu/Rebol3/tree/master/protocols

It would be possible to make hardware that interprets REBOL values 
directly (it would be VLIW in the sense, that REBOL values are usually 
large, ie. 16 bytes in R2), however the hard part is striking a balance 
between complexity and utility.


The simple fact that code would not be "flat" but more like a tree 
would pose a lot of issues compared to the mainstream hardware architectures.

>> import %mezz/trees.r
>> print mold-tree result

[root [] [html [] [head [] [title []]] [body [] [p [] [text [value 
"This is a paragraph"]]] [p [] [text [value "This is another one"]]]]]]

if you use MOLD-TREE, you won't see those [...]. they are back-references 
that are necessary internally. MOLD won't print them or it would 
be an infinite cycle.

you can navigate with GET-NODE, I haven't needed something like XSLT 
Paths yet (I had something closer to that in Temple).

root: load-html ...
p: get-node root/childs/html/childs/body/childs/p ; for eg.


most of the logic to do what you want is already in trees.r actually, 
because of the rewrite-tree function (that I don't use anymore). 
Anyway, a simple way would be:

get-node-with-id: func [root id] [
    if id = get-node root/prop/id [return root]
    foreach child get-node root/childs [
        if get-node-with-id child id [return child]
    ]
    none
]

Use "5.10 Parse HTML text into a tree" instead

Then, the latter two modules were replaced by a different approach 
that builds a tree of blocks from the HTML and rewrites it as it 
is being built (to avoid doing too many passes). This is done by 
LOAD-HTML, that allows passing a set of rules used for filtering 
(so the actual filter is now a bunch of rules for LOAD-HTML). LOAD-HTML 
handles a lot of HTML weird cases, it's probably not at the level 
of a web browser, but it comes close.

The tree is being built with the Niwashi module, which was separated 
as a generic way to build trees incrementally following rules etc. 
(Niwashi means gardener in Japanese)

7.4 parses a string into a sequence of tags and text (etc.). (it 
also has a load-markup function that is similar to load/markup but 
also parses tag attributes and so on). 5.10 uses 7.4 and builds a 
tree from that sequence of tags and text.

Second: your problem is that you are trying to mold the result, which 
is a tree where each node has a reference to the parent node. (much 
like faces in R2). That's why you see the "loop".

there is a mold-tree function in %mezz/trees.r if you want to mold 
the tree. Or, you could simply use form-html to pretty print the 
tree for you.

Eg. for your first example:

t: load-html p
print mold-tree t


[root [] [html [] [head [] [title [] [text [value "t"]]]] [body [] 
[h2 [] [text [value "HEADING"]]] [p [] [text [value "first para"]]] 
[p [] [text [value "second para"]]]]]]

print form-html/with t [pretty?: yes]

<html>
    <head>
        <title>t</title>
        </head>
    <body>
        <h2>HEADING</h2>
        <p>first para</p>
        <p>second para</p>
        </body>
    </html>

You can also do things like:

>> mold-tree get-node t/childs/html/childs/head/childs/title
== {[title [] [text [value "t"]]]}

doing a bit of stress-testing... I've just loaded a 15MB polygonal 
model of a tree in my 3d system ... it has ~350000 polygons and ~180000 
vertices.

a bit slow using the current unoptimized Old-school OpenGL commands, 
but I'm still averaging about 10 frames a sec on my 4 year old mobile 
nvidia GPU (which is like 16 times slower than an average desktop 
card of today ).

Andreas: the code base is a mix of both single source and multi-source 
tree.


I will not allow source files to become unreadable with every other 
line being #ifdef for a different OS. Those are not maintainable.

I think that when Carl is back, we should merge. CC contains already 
some A111 fixes. What was the reason Carl posted the source tree 
in the different than usual place?

But first, I'd use a native rebol ANSI C90 source tree format (tokenized, 
pre-processed, un-wound error-free source tree data).   

The /library extension would then only manage declarations (funcs 
and structs, for now), assuming funcs to be external library declarations.

the source tree format could also be used by Cyphre's jit, an LLVM 
extension, Rebcode, or things like that, as a common target.  so 
we can all share efforts.

replies in order:


@ pekr,   I am well aware that extensions and /library are different. 
 R2 is not such a very easy way... I've cursed so many times trying 
to use it in "real life".

sea would make your life importing a comple API much easier but its 
not required... the source tree format is the basic interface.  which 
you can submit directly, just like in R2.

I wish compose/deep didn't copy/deep the whole block when it did 
its composing.  


I don't know how it is in R3, but in R2, to simply replace one value 
in tree, you have to copy the whole tree, which isn't very useful.

Our datasets are huge and we optimise for performance by unfolding 
and indexing a lot of stuff into rules... for example instead of 
parsing by a list of words, I parse by a hierarchical tree of characters. 
 its much faster since the speed is linear to the length of the word 
instead of to the number of items in the table. i.e.  the typical 
 O*n   vs.   O*O*n  type of scenario .  just switching to parse already 
was 10 times faster than using  hash! tables and using find on them.... 


In the end, we had a 100 time speed improvement from before parse 
to compiled parse datasets.  this means going from 30 minutes to 
less than 20 seconds....but this comes at a huge cost in RAM... a 
400MB Overhead to be precise.

O*O*n
  == a typo  :-)

I guess I really meant  something like O(n*n) 


Its the kind of dramatic  linear vs logarithmic scaling difference 
when we unfold our datasets into parse.


but its not exactly that kind of scaling, since the average topology 
of the sort tree will have a lot of impact on the end-result.  for 
example in my system, when I try to index more than the first 5 characters, 
the speed gain is so insignificant that the ratio is quickly skewed, 
when compared to the difference which the first 3 letters give.  


Its 100% related to the actual dataset I use.  in some, going past 
2 is already almost useless, in others I will have to go beyond 5 
for sure.  in some other datasets we unfold them using hand-picked 
algorythms per branch of data, and others its a pure, brute force 
huge RAM gobler.

I don't know how it's on Vista, but on W7 or XP you can place it 
anywhere... I today updated my old zlib script to do late initialisation, 
you can find it here: https://github.com/Oldes/rs/tree/88291b8c720e9026978a080ca40100c3f2fb780f/projects-dll/zlib/latest

this is the easiest way to know if a data element can be traversed 
via pick without having to first know if the datatype can be traversed.


the issue is that many types have indexed content but are not series 
(i.e. no "current" index).  so we can get the value or deny listing 
in one function call.

ex:

print-tree: funct  [data][
	i: 0
	either len: length? :data [
		repeat i len [print-tree pick :data i]
	][
		print mold/all :data
	]
]

If you have looked at Red sources since a long time (like a week 
;-)), you should look at the Quick-Test framework added yesterday 
by PeterWood: https://github.com/dockimbel/Red/tree/master/red-system/tests
(see the readme.txt)

if you want to parse function calls into a call tree, you'd need 
some argument delimitations

New branch started: `libc-init`


First commit contains proper init code for libc on Linux. It works 
ok, but additional testing needs to be done. Also support for other 
platforms needs to be added.

https://github.com/dockimbel/Red/tree/libc-init