World: r3wp

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.

So, I am still curious, how Core and Host parts are being abstracted/separated. 
And even then such separation does not mean, that View can be easily 
extracted outside as a module. Extracting only VID is imo nonsense.

to me REBOL the language and REBOL the platform are two different 
things.   forcing view as a requisite to rebol does not allow the 
language to live on its own.


if RT release the equivalent of core and makes that stable, we can 
already build a lot of apps, Back-ends, services, clients, etc.  
I'd rather have networking protocols, a stable set of mezz, continued 
improvements on extensions, than a lot of time waisted on view, delaying 
yet again all we can do with core already.

the OpenGL GUI will not need view, and if someone wants to make a 
cocoa extension or a windows native gui extension... they should 
not be forced to include view in their binaries.

a platform like view is a good thing, not saying it isn't, but its 
a different thing... to me, R3 is about the maturing of the language 
and of its interpreter.

Then good luck to RT, as they should find another mechanism, of how 
to physically isolate various components. With View, there si event 
queue involved, so I wonder, how the eventual split so that you "import 
View can be done. While I like REBOL.dll idea and its isolation, 
I don't like one homogenic Host portion code. It will lead to tonnes 
of various releases. Any ideas here? Could extension isolation interface 
be used for Host code and its componentes? Or are there different 
requirements? I will probably post to R3 Chat, to provoke some ideas 
from Carl. So just stop me, if you think that what I am asking is 
eventually very obvious :-)

At least we need 2 releases: Core and View