World: r3wp

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

It's just my speculation. The GUI can be removed if desired. It's 
going to be a module.

I doubt it ... do you think that module can have easily binary code? 
:-) You can remove VID, but what about View kernel? I doubt it. But 
we still have to see Core and Host isolation interface. Extensions 
are something different. We are still waiting for Host code release 
...

Henrik - a bit OT here, but maybe not. Have you looked into UIs of 
iPhone, HTC Sense (TouchFlo 3D)? I wonder if those glossy nice icons 
and other UI elements can be done using AGG and gradients, or are 
those things precisely rendered using 3D tools? Or are they just 
non-scallable bitmaps?

http://www.htc.com/www/product/touchdiamond/touchflo-3d.html
http://www.htc.com/www/press.aspx?id=103534&lang=1033

Well, to my mind, the GUI is written with Rebol code (it can be exported 
in a module). The graphic engine (GOBs, draw dialect) will stay in 
the core.
It depends of what you call the GUI.

Pekr, OSX traditionally uses 512x512 32 bit bitmaps for icons. I 
assume it's the same for the iPhone.

they are usually made with 3D tools and Photoshop and the like.

releasing a REBOL beta without GUI is a VERY good idea.

with extensions all of the View internals can be outside... its basically 
AGG with a set of predefined hooks.  The only detail would be custom 
datatype... which should eventually reach extensions... maybe Carl 
could just build a special (undocumented) extension hook so that 
cyphre has access to more stuff, without the hassle of supporting 
it as a feature for the public.

on my part, once Carl adds either one or both of my requirements 
for the next evolution of extensions, then I can proceed with a fully 
independent version of a GUI written in OpenGL... no need for any 
internal view stuff a part from the image! datatype... not even window 
manager.

not sure it is good idea at all. But product packaging strategy was 
never explained for R3. Will there be Core, Command, View, Base like 
products? I am not sure, that technologically, R3 is done in such 
a way, so that such separation is possible (= all View internals 
can be placed outside R3 as a module). Also - having it optional 
as a module can lead to split of efforts once again.