AltME groups: search

I agree. The appearance is too geeky, but by the graphics geek kind. 
I want to build a more user friendly interface on it

@Graham and others: I should have wrote you earlier about what I 
am currently doing instead of leaving you with no info, sorry for 
that, I was very busy these last weeks, with both real life events 
(good ones ;-)) and a new customer from which I accepted a short-term 
job to help pay the bills. The contributions I've received so far 
*are* helpful and I can't thank enough all the people that made donations! 
But their are not enough to cover all my expenses here, if I could 
get 3-4 times more from donations, that would be perfect, but as 
long as the userbase won't be larger I think that it won't be  possible.


So I've accepted a short contract (til end of june) to build a trading 
bot generator with a visual editor (GUI in View) that emits MQ4 language 
source code for feeding the Metatrader4 application. Of course, I'm 
building it in REBOL (Red not ready yet for that). The plan was to 
work part-time on it and part-time on Red, but these last two weeks 
I had to work almost only on that project. I still have a few days 
of intensive work on it, then I'll switch to part-time.


I have quite a lot of code to commit (the Red compiler), but I'll 
wait to finish first the internal modifications in Red/System (to 
ease the integration with Red) before publishing it.

Pekr: right, 400 EUR/month would be enough. 


I believe that the Raspberry pi board has a huge potential, we should 
try our best to support it and build tools for it in Red.

I don't know. Please don't be bogged down by things like gui in Red 
too fast! You first have to make a langauge / a platform that others 
(we) can use and build upon and add libs when we need them. And for 
all the love to VID and like, my oppinion is still that usability 
matters the most and it's hard to beat usability (all the little 
conventions) with non-native GUI-s. Or big delevoloped libraries 
that emaulate them well enough (Qt, GTK, ...)

I have personally entirely different ideas for using Red as a basis 
for a new kind of desktop, but I'm not sure if I'm skilled enough 
to build it. We'll see.

Robert: C++ is a superset of C. Red is not a superset of Red/System, 
they are two different languages that share the same syntax and superficially, 
some semantic rules. Red/System is a low-level dialect of Red than 
enables system & hardware programming with C-level performances. 
Additionally, Red/System is used to build Red runtime (memory manager, 
lexer, natives,...).

So I build my first Red/System DLL, but R2 refuses to load it with: 
** Access Error: Cannot open builds/temp.dll as library.

But that enables already to build a lot of things, like bridges with 
other languages or VMs.

Pekr: thanks for the advice. :-) I haven't followed very closely 
the developpement of R3 nor I have ever wrote R3 code, so I'm not 
aware of all the reasons for some design decisions. That's why I 
ask when I need to. AFAIU, R3 was designed to solve R2 issues. I'm 
building Red from scratch, so I don't have legacy issues (so far) 
to deal with, I have more freedom than Carl with R3 and I intend 
to use it. They are some parts of R2/R3 design that fit well my plan, 
so I use them as inspiration, but there are other parts (especially 
in R3), that I am not fan of. Also, do I need to remind you that 
Red is compiled while R3 is interpreted? These are two different 
models which require different trade-offs.


The difficulties I have to deal with in Red (both design and construction 
process) are inherent part of any non-trivial work to build something 
new and that's my role to solve and overcome them. The best way others 
can help me are by pointing out errors or inconsistencies both in 
the design and implementation.


Wrt Unicode support, I should be able to say in a few days how long 
it will take to support it. I doubt I  need as much as 2-3 months, 
but anyway, nobody but Carl knows what he had put in, and exactly 
how long it took him. ;-)

I've updated the recipe in the Syllable build system to add Red:

Please remember we want to contribute but without a reasonable clue 
this is hard to do. (Besides the closed-source issue this is what 
Carl ran into when expecting others to contribute). Me and Github 
wil never become friends for example, I managed to get some source 
long ago but no clue how to update to the newest sources and github 
has informed me they do not wish to support their macosX tool for 
Leopard that I am running, nor remove the useless (?) check on OS 
number 10.5, and I am NOT updating my system and learning all the 
commandlines to upgrade etc is too much effort, (maybe someone can 
build a REBOL interface).

In my Syllable build recipe you can see that you can download the 
current state of a branch the same way:

Daniel: welcome! The best choice so far would be SQLite for such 
usage. We might reuse lower level parts of SQLite to build our own 
storage system specifically designed for Red.

The thing is that they made software so complex, that it has become 
extremely hard to point your finger at where exactly it goes wrong. 
We had to build Syllable to get an idea of some of those things, 
and then nobody wants to believe you

Also, when you try to build an operating system with Red, you'd get 
into GPL 2 territory in kernel space, and you'd have a problem with 
the many GPL 2 drivers. The media codecs and some networking protocols 
mirror that situation in user space

Call it DOS. But the MSDOS target name still annoys me. I don't want 
a legitimate, common target build to bring back such bad memories 
:(

Anti-virus: should I suspect that we have to submit every build of 
every version of every program to all anti-virus vendors to get them 
recognised?

Or rather an earlier alpha, the last private alpha build before we 
switched to public alphas.

So, what is the strategy? I can see various dirs, one named MSDOS, 
but can't see Windows? So what are the targets to distinguish, when 
we build the Windows apps for GUI, or the console?

Pekr: well, if I had billions, I probably would spend them into science 
research rather than that. One of the main science project would 
be to build me a light-saber. ;-)

GiuseppeC: Red/System is a language to build other languages using 
a similar syntax as REBOL, one of which is Red. R3 is based on C. 
There is no way for R3 to tap directly inline into C's performance, 
while Red will be able to. I think this is quite a feat that might 
make Red much more flexible than R3. You also get encapping right 
out of the box with the current compiler. I can't come up with an 
appropriate car analogy.

That means that we have total 100% control over how and where Red 
can build. We don't depend on the quality of the compiler for a platform.

Jerry: that sounds like a realistic deadline to reach 1.0 release, 
as long as I can keep working full time on Red in 2013. Though, Red 
should be fully usable in a couple of months, all features would 
not be there, it won't run at full speed, but it will be enough to 
be able to build almost any app.

From ~Links group: "Could Red eventually become a contender for #6? 
 How strong will support for parallel processing be, eventually, 
in Red?"


#6: yes, that is one of the goals I want to achieve with Red. For 
parallel processing, the model I have in mind is the "parallel collections" 
from Scala. This means that when you are looping over a series, Red 
should be able to parallelize the loop code over n (CPU and/or GPGPU) 
cores at the cost for the user of only a change of the loop function 
name (in Scala, they use a "par." prefix for such functions). This 
requires that the compiler do a deep static analysis of the loop 
body to determine if it can be parallelized (e.g. iterations not 
dependent on results from previous ones). Now, if you also add SIMD 
support in the equation to leverage intra-core parallelism, you get 
a good picture of what I want to achieve. ;-)


So, I think a semi-assisted parallelization/vectorization of loops 
in Red is doable. To what extent and which final efficiency, I'm 
not sure before we build some prototypes.

The "RT-like product" separation wouldn't have much meaning in Red 
where you can build your  executables with whatever modules you need. 


We'll define a common "extension" standard (probably based on module! 
datatype) that all third-party modules will implement, so that your 
app could easily use any modules at a cost of a simple "import" directive. 
Such extensions will be typically coded in Red, but with all the 
low-level options, like Red/System routines and bindings to external 
libs.


Moreover, you'll have also the alternative option to build everything 
in a single binary (including third-party libs if they can be statically 
linked). Such thing is impossible in R2 or closed-source R3. In  
 open-source'd R3, you'll be able to do that too, but you'll have 
to get your hands dirty by implementing the bindings in C and using 
a C compiler to produce the executable binary.

VID-like: definitely. Not only because it is a simple and efficient 
way to build GUI, but also because it nicely shows the power of dialecting, 
applied rightly, so it "validates" the whole concept behind REBOL 
and Red. 

I was planning two approaches:


- prototype a VID dialect for cross-platforma native GUI once we 
have the right interfaces between Red and Red/System. (That part 
will include also mobile platforms, if possible, else, they will 
have rely on a mobile-oriented GUI dialect). I will probably start 
to play with it around Christmas, and try to reach an alpha/beta 
in Q2 2013.


- prototype a VID dialect for HTML frontend, having GUI frameworks 
as backend targets (Sensha, jqueryUI,...). The hard part here is 
abstracting the client-side coding, Topaz would be great for that, 
if Gabriele can find time to continue working on it. Else, I will 
need to work on my own Red to JS compilateur.


It would be also nice to have a wrapper over R3/View or a Red/System 
port of it, but it would need contributors to take it in charge. 
There are also more possible GUI options.

And I even don't agree with Henrik. I really can't see, how your 
top-down aproach might work. You need a solig gfx engine (View), 
general enough, to build up. Carl's GUI was OK. And imo Saphirion 
did a bad mistake - we heard, for so long time, that the look is 
the final step. All those years, and the look is really a crap. Much 
worse, than what Carl brought up, even if I can see many improvements 
in engine itself. Look sells, take it, or leave it, and then - please 
don't even try to do your own GUI. No matter how good it is, if it 
looks like 80'ties Solaris, it will never get accepted ...

I want ALSO View/VID, which is being kind of dismissed here both 
by Doc and Kaj :-)

 Absolutly not, I'm just saying that I will build a native GUI solution 
 first, a View-like solution is not my priority but it is welcome. 
 If nobody makes a View-like engine, nor wraps R3/GUI engine, I will 
 consider making one myself when I will have more time.

I did a build run of the examples. It looks OK, but the many casting 
warnings on the GTK bindings are still there. I think that should 
be fixed

Doc, would this Linux server you could provide be able to run VMs 
with OS X and Windows in order to do multi-platform automated builds? 
I'm thinking we could set things up like Unity does (see the link 
below). JetBrains provides TeamCity (the continuous integration server) 
for free to OS projects with an active community.


http://blogs.unity3d.com/2011/10/21/build-engineering-and-infrastructure-how-unity-does-it/

Doc, thanks for the heads-up. I'm also unsure which route to go, 
but I want to have the option to write Red/System only programs, 
so I guess I will usually build a Red binding on a Red/System binding

And some smart person might be able to build a console that could 
be leveraged for both, or at least parts of it.

Can it be that the Windows PE backend compiles in a random number 
or otherwise random uninitialised values? Windows builds seem to 
change on every build run without Red having changed. This is inefficient 
for my incremental builds repository and makes it hard to validate 
build correctness

Red/System is in beta stage. Whether or not it is a good choice for 
a GUI app is matter of personal taste. I personally gave up building 
GUI apps in a C-level language a long time ago. However, if you want 
to give it a try, I recommend you Kaj's GTK+ binding, which now works 
fine on Linux ARM, as shown here: 

http://static.red-lang.org/rpi-gtk-widgets.png

You can see the source code for this GTK+ demo here:

http://red.esperconsultancy.nl/Red-GTK/artifact/3453dd410a1c64ca8f842f75c7431b6f7fc3c4b3


As you can see, Red/System has some limited dialecting capabilities 
that Kaj leveraged to build a very nice GUI dialect (which is quite 
an achievement for a low-level language).

About reflection, will there be a compile option to turn it off, 
for commercial code that should stay closed?


What I planned so far is a compile option to switch between different 
modes of bundling the functions/routines source code into the final 
executable. Main options are: 

- in form of native "build instructions" (the current behavior)
- in form of compressed text


The latter option will generate smaller executables, but will be 
slow down boot time a little, as it will require the interpreter 
to process it. The former option provides a high level of obfuscation, 
that requires a lot of work to decompile (cracking REBOL's SDK protection 
is probably an easier job).

My own website is done with Cheyenne and the HTML dialect and is 
very easy for me to maintain: Makedoc files are rendered on the fly 
to each webpage. I can SSH to the server and edit files as I please 
and there is nearly zero HTML involved.


Granted, there is no blog or comments section, but is another example 
of how a small toolchain (one Cheyenne executable and a few script 
files) can be used to build a good website.

I've done a complete build run and I see no regressions in the examples

I've done a full build run with the path fixes, without regressions

No build regressions in a full build run

Oddly, there's a build regression in a GTK program just for Syllable, 
which is not even a valid combination

Yep, it's starting to look good. I'll build the examples once more

No build problems

NickA - I share your point of view. Ppl mostly nowadays think, that 
the web rules it all. However - it is still complex. I don't care, 
if we generate HTML5 (whatever it is) in the end, as far as we can 
very easily build apps using VID like dialect. I remember those initial 
days, where we had really a small script (1.6KB) to show image from 
4 webcams ...

For Red, it will rather work as R2 SDK where you just import the 
modules you need to build your binary. We would also provide a console 
binary with all or most of modules included by default (like the 
fat binaries from the SDK).

There are still various bugs in R3, though. You seem to need the 
latest build from Andreas, and R3 corrupts tuples passed across the 
bridge

Nobody has proposed me so far to build a R2-level cross-platform 
console for Red, so I will implement one in the next weeks. Before 
that, I will probably work on PIC support for Mach-O and ELF and 
implement object! support.

Sorry, I meant to say what language is Red/System developed in, but 
now I remember that I build my Red/System programs in R2 currently. 
 For some reason, I thought Red/System's low-level code was in C, 
but I guess that's just because Red/System code kind of looks like 
C.

Git was not designed for humans, AFAICT. It was designed to let loose, 
informal teams manage huge open source projects. Now it has become 
the default hammer, and every software project a nail. I don't mean 
git is bad in any way, and it is successful for a reason. It has 
become friendly enough that a lot of people can use it, but I still 
see notes about how most people don't know how to use it effectively. 


I imagine you could build a great, human-friendly wrapper over git, 
providing 90% of the power with 10% of the effort. It would take 
a git expert and a good designer, but maybe not too much time.

I just never got very far with Boron.  I donated to it when I thought 
it could be a viable open source alternative to R2, but it's feature 
set never evolved enough to be useful for work, like R2.  That's 
been the problem with ALL REBOL related language tools for the past 
6 years or so.  That's what made/makes R2 attractive.  A full stack 
of usable tools for creating applications.  If the Saphirion guys 
and Doc build usable tool sets with mature GUI, sound, database, 
3D, etc. APIs, then people will begin to use those languages.  Boron 
never had any of those features implemented in a user friendly way.

Livecode cross-compiles to any platform.  I can build Windows, Mac, 
Linux, Android, and Web apps, and X-code projects, with the click 
of a button *all on my Windows machine (or on a Mac or Linux box, 
if I want).

NickA: I fully agree with you. A bare Red core has low value and 
not much potential to attract a large crowd. Actually building all 
those user-level features will be the fun part of Red project, I'm 
looking forward with great appetit to the moment I'll be able to 
work on them. Also with a solid Red core, we could provide an even 
better user experience than Livecode, which, e.g. still struggles 
to handle Unicode fully:

http://www.runrev.com/products/livecode/text-and-data-processing/


We should mention that currently it’s perfectly possible to build 
applications that use Unicode in LiveCode, but there are some limitations. 
[...] We’re hard at work adding beautiful, seamless and complete 
Unicode support for a future version so please check back if you’re 
interested in that.

I tried several times with the latest build. I open a fresh console 
window.
print x * y
** script error ... window closes..

In my older benchmarks with Carl's R3 build, R3 was a quarter faster 
than R2 (3 : 4). But I was computing Fibonacci 35 then, and now Fibonacci 
40 to have a better comparison with fast languages on fast machines

Andreas' R3 build is a bit slower even than mine, so nothing wrong 
with mine it seems. Apparently R3 is 10% slower than R2 on Fibonacci 
40

Yes, you'll be able to just build your fat binary/interpreter yourself 
including whatever module you want.

Fresh build, on Linux

We just released our first R3 based tool. See: http://www.saphirion.com/development/heat-map/


The tool gives you an editor to build hierarchical structures / layouts 
where you than can map given information criterias (Skills, Performance, 
...) into visual recognizable values (color, line width, ...).


We use this tool to visualize complex situations on one page. The 
values could be feed from a database or other source in real-time 
and the visualization will update immediatly.

Saphirion's Host-kit has been updated:
-added PNG encoder
-added Core extension module for generic additional commands
-reworked compile/build process
-fixed security flaw in Encap
-fixed bug caused non-functional networking
-improved console output handling logic
-patched ENCODE to not crash on png
-updated LOAD-GUI with currentspahirion link
-recompiled r3.exe, r3core.exe, r3encap.exe and r3ogl.exe

Update on the web-page will be available on the weekend.

I thought about that too, label font color can be set, but I was 
afraid it would slow down the app. That is why I chose to build the 
extra mirrors as a seperate layer to show on top of the grid-layer 
and the unchangeble mirror-layer.

I've added a build script to the above testing repository, to build 
all my Red examples in one go

This is the benefit of speaking another language than English that 
is the base for so many computerlanguages. You can say things like 
rij: array [100] where array: array [100] would be a sure syntax 
error, and rij means array in Dutch off course. If you are in need 
of additional translations, just say so. Next I will build a multi-lang 
support lbl-something/text: lbl-something-tekst and a preferences 
panel with file (mirror.ini or mirror-pref.ini) for language (En 
De Nl Fr Es Pt additional wishes?), mirror line-width normal(1)/bold(3 
wide) for placed or both kinds and/or the grid, color of added mirrors, 
color for ok color for not ok.

The main issue I have with this script is this. My script did not 
compile. I used 'now in my script to time a kind of loop foreach 
versus forall and this failed. The control was not passed back to 
my script, I just compiled hello.reds script and this was successful 
and my script got the focus again. So that is nice but with unsuccessfull 
build it woul be nice to gather results and maybe restart compiling 
with different setting (for verbose for example). I have no idea 
how to do this.

OK, I will let it to experts. You can find some BrianH comments in 
the prior blog article, where Carl asked for the opinion. Please 
read it as well. But imo really - why to complicate the situation? 
Why not MIT or BSD? Is Carl fearing some big company will behave 
badly, build commercial stuff upon REBOL, and make some money, without 
donating changes back?

IIRC he actually use the Android NDK compiler to do that build. But 
don't take my word for it.

Graham, it should work on anything that has at least Android 2.2 
and an arm cpu. Moreover the APK contains additional build  of the 
R3 interpreter for arm cpus that have hardware floating point operations. 
I haven't made any benchamrks so I don't know if this is really performance 
advantage (in case of Rebol code) for Devices with such better and 
newer hardware.

Nice work Kaj. I'm working on Unicode support for the tokenizer, 
so the console should get at least Unicode support for the DevCon. 
I plan to write a real cross-platform console engine as nobody has 
stepped out to build one so far, I guess it should be ready for the 
DevCon.

Yes, Andreas, very nice looking site. And thanks too to Saphirion 
for the build farm.

Build farm is 2/3 mine, 1/3 Saphirion :)

so typically a build is just three steps:
- fetching an r3-make
- make make
- make clean prep

well, some build details might be nice - for example under Windows 
which toolchain was used - these details might be important if/when 
people start comparing performance among builds gotten here and elsewhere

debug builds: maybe. i'd like to get this added to the mainline sources 
first. once that's done, i'm still not so sure if they really are 
that useful at the moment, as I think they won't help much without 
a build environment set up.

well, with the basic build farm in place and the website launched, 
i'll maybe get to some more build process revisions (including debug 
builds) soon.

In my humble opinion there is an immense wall between users and developers, 
that is not the open source way. Altme is inaccessible to most user, 
nobody know it and the procedure to register is hidden somewhere 
and too complicated; here we have no more than 50 readers. Rebol.com 
site seems a dead site. Curecode seems a secret society (it's impossible 
to reach if don't know the correct link, who is  working on it?). 
 Stack overflow is the only way at the moment users have to discover 
somenthing about Rebol, but it's not the appropriate site. We cold 
multiply 1000 times users with a good support.  Rebol must be more 
partecipative, but I don't see around anything about it.  Everytime 
I write a post about Rebol, I feel like an archaeologist with a dead 
language. Searching information about Rebol is a huge quest.
What did you do for Rebol? What can you do now for Rebol?

Do you want to build an open working infrastructure or you want remain 
sat on your chair looking Rebol going in ruin?

We have finally Rebol and Rebol VID source working, now we have to 
attract developers from all around the world.

I''m not starting a new Rebol, just making attractive for normal 
people, the bones and muscles of every good open source project.

While I'm against blind copying, I think MaxV is simply trying to 
build some momentum. He's been very active, and I appreciate all 
his past efforts. If we open a dialog, we'll either come together 
or disagree in a friendly manner. :-) As much as I believe in talking 
first, sometimes that stalls efforts as well. Now at least we have 
something  to look at and use for further discussion.


And while I don't like having too many channels, and use only a few 
consistently, his new portal looks nice and incorporates a lot of 
functionality already.

I believe that R3 Chat would be the PERFECT solution for REBOL communications, 
if we could build a more mature HTML front end.  Will Carl release 
the source?

This is fantastic Doc. I know it's still very early days, but you 
are making great progress and it's very exciting to see it come to 
life. When I copied the commands from the new blog entry, to build 
the console, and it worked the first time, perfectly, it made my 
day. Then, even doing just simple things in the console was fun.

But if you define a routine in a Red script, and then DO it, it will 
work. You can also build a custom console by writing a Red script 
and adding at the end an %include %<path-to>/console.red.

Yeah, but I don't want to complicate my build script further. I already 
have to track many branches of REBOL

I try to keep my build procedures as minumal as possible

If Andreas updates the makefile in one of the next commits, my build 
recipe just downloads that. Ah, thanks

However, the reliable way to do a full & clean build is `make make` 
followed by `make clean prep r3`.

All fine now. I've switched the Syllable build system to the community 
source:

Is your build identical with the 0.4.4?

What I'm doing now is just a Linux build. A build on Syllable Desktop 
yields a different host executable: that is not compatible. The library 
would also be internatlly different when compiled on Syllable Desktop, 
but Desktop can still load a library compiled on Linux

I see I penciled in a TO_SYLLABLE parameter here in the Syllable 
overlay of the build recipe:

nope. i corrected that and still the same error.


i have data stored in json. i use json.r to convert to rebol objects. 
i want to create a query layer on top of this - which is why the 
expression builder...
the fact1 is an attr of the data object. these can be nested.
how best can i build the expression to retrieve the value i want?

parse-int-values: func [

    "Parses and returns integer values, each <n> chars long in a string."
    input [any-string!]

    spec [block!] "Dialected block of commands: <n>, skip <n>, done, 
    char, or string"
    /local
        gen'd-rules ; generated rules
        result      ; what we return to the caller

        emit emit-data-rule emit-skip-rule emit-literal-rule emit-data
        digit= n= literal=
        int-rule= skip-rule= literal-rule= done= build-rule=
        data-rule skip-rule
][

    ; This is where we put the rules we build; our gernated parse rules.
    gen'd-rules: copy []
    ; This is where we put the integer results
    result: copy []

    ; helper functions

    emit: func [rule n] [append gen'd-rules replace copy rule 'n n]
    emit-data-rule: func [n] [emit data-rule n]
    emit-skip-rule: func [n] [emit skip-rule n]
    emit-literal-rule: func [value] [append gen'd-rules value]
    emit-data: does [append result to integer! =chars]

    ; Rule templates; used to generate rules

    ;data-rule: [copy =chars n digit= (append result to integer! =chars)]
    data-rule: [copy =chars n digit= (emit-data)]
    skip-rule: [n skip]

    ; helper parse rules
	digit=: charset [#"0" - #"9"]
    n=: [set n integer!]
    literal=: [set lit-val [char! | any-string!]]

    ; Rule generation helper parse rules
    int-rule=: [n= (emit-data-rule n)]
    skip-rule=: ['skip n= (emit-skip-rule n)]
    literal-rule=: [literal= (emit-literal-rule lit-val)]
    done=: ['done (append gen'd-rules [to end])]

    ; This generates the parse rules used against the input

    build-rule=: [some [skip-rule= | int-rule= | literal-rule=] opt done=]


    ; We parse the spec they give us, and use that to generate the

    ; parse rules used against the actual input. If the spec parse

    ; fails, we return none (maybe we should throw an error though);

    ; if the data parse fails, we return false; otherwise they get
    ; back a block of integers. Have to decide what to do if they
    ; give us negative numbers as well.
    either parse spec build-rule= [
        either parse input gen'd-rules [result] [false]
    ] [none]
]

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.

odbc drivers for windows can only be used with the rebol/view, the 
gui build, unless you paid for a rebol/command sdk

Today I tried combining some tables in Excel, but without (frustrating!) 
no success. So tomorrow I will try and build a quicky REBOL script 
to put the data in one Rebdb databasetable and then do a dump of 
that and import that again in Excel.

So I combine data NAME PROP1 with NAME PROP2 giving a table NAME 
PROP1 PROP2
Any tips suggestions for lookalike scripts? Tia!

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

You can build that singleton when rfunc is called initially, or if 
you only need one then you can use funct/with to make a static local 
var with that value. (Still haven't analyzed the source.)

what would be useful is to build something like a SPARQL dialect 
on top of this

I think this would be the start of something superb. If we can build 
a SPARQL like query interface on top of an associative db in rebol, 
we could simply point it to any of the open data initiatives and 
then go on the ride of a lifetime!

Kaj, not sure if it's of use to you, but I dug out the timings from 
the last time I built Qt (on a Linux host, 4 months ago):


$ ./configure -opensource -nomake examples -nomake demos -nomake 
docs -nomake translations
5 minutes

$ make -j2
34 minutes


That was on a moderate dual-core machine with 2GB ram and spinning 
disks. Not sure how much make could parallelise, but for a single-core 
machine roughly twice the build time will be a reasonable worst case 
estimation. I guess that otherwise the configure-to-build time ratio 
will still be roughly the same.

I'm starting to get the GUI build to work, and it takes a few hours 
here, but Syllable Desktop can't use the second core on this machine, 
and compiling is roughly half the speed as on Linux, anyway, so that's 
roughly consistent with your timing

I'm working on many things, currently Enlightenment, GTK+ and Qt. 
The infrastructure they need in Syllable to build and run is mostly 
shared, and some of the dependencies they use are shared

How big are the Enlightenment libs? Does E have any peculiar build/runtime 
dependencies?

No, we haven't had time to make emulator images for 0.6.7 yet. The 
Enlightenment port isn't published in binary yet, but you could compile 
it with the Syllable build system

I added Fork's preliminary R3 port of Red to the build system, with 
an overlay for Syllable Desktop so it can be experimented with there: