World: r3wp

It's not Relational, is it?

ADBMS, sorry

Assoiative, relational... 

To my mind, there is no difference, it's just the query language 
which is different

*associative

At the end is always the same problem.
To have fast indexation algorithms

I don't code R3 things yet. Too many moving targets.

Re ALIAS -- it has several security and other issues.

Enabling it via SECURE is a good way of limiting the inadvertent 
damage it can do....And of drawing attention to its dangers for any 
casual dabbler.

The module rework has finally been submitted :)

Now it's time to backport it to R2/Forward, to the extent possible.

The set-block! datatype would make good sense with functions, that 
return more than one value. In Lua, a function returning 3 values 
can be defined as:

function f () return 1, 2, 3 end

and be called like:

a, b, c = f ()


Now a, b and c holds the values 1, 2 and 3. In REBOL we have to write:

set [a b c] f

It would maybe be nice to be able to write:

[a b c]: f

I find it easier to write set [a b c] than to notice the colon on 
the end of [a b c]: - but that may be just me.

Yes, the colon can be hard to notice. It's hard to say, if it will 
be easy to read such code.

The readability of REBOL is one of the deliberate design features 
that makes REBOL quick to program in.

I'm working with a long time REBOL programmer these days. We discuss 
the language now and then. One thing, we discuss, is how the minimalistic 
syntax can make REBOL hard to read. We can use parenthesis for arguments 
to functions, but we rarely do it. We could write:

insert (back (tail (series))) value

but a REBOL programmer would just write:

insert back tail series value


Even if we use parenthesis, REBOL requre different parenthesis notation 
than other languages. The above code in C would look like:

insert (back (tail (series)), value);

And C programmers often don't write the code this way with functions 
within function calls. They use to write:

void *pointer = tail (series);
pointer = back (pointer);
insert (pointer, value);

or something.

That is only because of line-oriented debuggers :)

This, I think, is one of the huge benefit of REBOL. To be able to 
combine words into sentences, that actually makes sense to read and 
understand. I don't know of any other language, that can do it this 
good.

steve, belive me... there is ABSOLUTELY nothing in common between 
relavance and all the db you are used to .  absolutely nothing.

kaj, no its its a system of associated nodes.

its like programming cells directly. no rows, no columns, no tables.

Steve, I'm with you.  I don't see anything special about associative 
model.

I can only say that's cause you haven't used it.

Maxim, I need that relevance think, was impressed by Ron presentation 
at DevCon France! My knowledge is less organized since I stopped 
using vanilla. I need to write a new wiki engine, have tried trees, 
nested set, adjacency, file system based, none satisfy me.

guys, what is Relavance price level? Is it suitable for normal guy 
to play with? Or just for big and specific projects?

Max - re your request towards RXI - I thought that image datatype 
was already accessible via the API?

think -> thing

When I perform get * in R3 Chat, I can see some files are not probably 
updated locally? I can see:


--- Note: work file changes would be lost, skipped: work/r3/mezzanines/mezz-intrinsics.r

--- Note: work file changes would be lost, skipped: work/r3/mezzanines/mezz-load.r


Does it mean those files were not updated on my machine? I did no 
changes locally.

That means that you already had versions of those files in your work 
dir, and that get * didn't overwrite them. If you haven't made local 
changes to any files in that directory, do a purge-dir, then get 
*.

Is this a new error?

REBOL[]
load-gui
stylize [my-button: button [actors: [on-click: [probe face]]]]
view [my-button]

If the button is clicked:
** Script error: cannot access start in path drag/start:

** Where: if do-events do-events do-events either applier wake-up 
loop applier wait do-events if view
** Near: if object? event [
	drag: event
	drag/start: where

Nicolas, please check whether the return value from ON-CLICK can 
be a face. After clicking, it's possible to return a drag object 
and if a face object is returned, it might fail.

Just quickly reading about PHP's "return" function. It's interesting; 
it does not have to be in a function. It can return the evaluation 
of a script to the calling context.
http://us2.php.net/manual/en/function.return.php


Seems like a good idea to me. Maybe Rebol should incorporate this 
idea?

quit/return?

Does quit already do that?

nope it apparently doesn't.

well, it doesn't write anything in the console. maybe I'm doing it 
wrong.

for a return code to the calling program

Not just for the os shell which has launched rebol, but rebol scripts 
that do other rebol scripts - the DO could be considered like a function 
call, and the DO'ed script could RETURN just as if it was a function.

The attractiveness of the idea is that there is just one function 
(return) to learn which handles the same concept (returning) in different 
contexts.

is there any sense of the 'completeness' of R3?

What do you mean by completness? IMO R3 is more advanced than R2 
already, and we are nearing beta stage =  system architecture is 
in-there, all slots in the right place. Now we need to finish few 
things, for user to be usable as R2 is:


- better console (not necessarily needed, but Windows one is total 
crap and makes experience 40% worse for me)
- fixed call
- network protocols (ftp, pop, smtp, proxy )
- ported DB drivers (done by community hopefully)

- improved parse (needed probably if we want to have DB drivers and 
network drivers done new way, but not necessarily)
- missing CGI mode
- GUI far from beta

thanks Petr thats what I was looking for.  I'm in the process of 
putting together a small proposal for my company, and I hadn't seen 
much recently on the release scheduling on the R3 blog.

the progress is great in last 5 months at least - 100 of CureCode 
tickets implemented in one month, sometimes almost daily releases, 
etc. We are "getting there", but not there yet ...

I would wait 6-12 months at least with using R3 in production apps, 
particularly if you are betting on advanced high level things like 
GUI. Development could start now, but R3 is not near feature freeze 
yet. Many moving targets and bugs remain. Cyphre is supposed to give 
the graphics engine another overhaul. We are also missing many docs 
for painless porting of R3 to other OS'es.


BTW: Carl has mentioned before that some things are needed for beta. 
I'm not sure the recent blog post is a good indication that R3 is 
anywhere near beta. I read it more like "this is a necessary 3.0 
feature".

Henrik: Thanks I'll go look at that

re Cyphre - I have trouble reaching him on ICQ, not to mention reaching 
him here. I am really curious, if Cyphre is going to be available 
for "another overhaul", but maybe I am too pessimistic in that regard 
:-(

Henrik - Carl mentions beta in few places ...  one of the being Twitter 
...

Pekr, yes I know. He has used nearly the exact same phrase "needed 
for beta" 1-2 years ago :-)

 We're nearing the time to move R3 into beta.

 sound more concrete imo - it is taken from latest Twitter message 
 :-)

If so, it could be, because he wants to remove the GUI from 3.0. 
I know he is going a bit back and forth on that.

remove GUI from 3.0? Interesting - never heard of it ...