AltME groups: search

btw notice that I included your last release of the r3_gui.r3 in 
the cgr-apps to make sure I stay forward complient... though you 
may want to do a diff on the version included and yours in order 
to patch crashing events when they originate from a gob which isn't 
a face.

henrik, I'll wait for the next release of r3-gui.  I wasn't able 
to launch the style browser.. it gave some error.

Maxim, I'll build a new r3-gui.r for you.

That should be discussed elsewhere, as well as discussed with Carl, 
along the lines of tasking and IPC model, etc. I think that timers 
could be usefull outside the GUI too ...

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 ?  ;-)

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?

the gui combo announced fails with  

** Script error: path styl/faced is not valid for none! type     
              which I posted in the wrong place (how I have come 
to loathe altme ...)

(now if I had a mini gui, I could make Rebamp:) I should invest some 
time to the view part as well.

nice work, Oldes.
I agree, a mini gui would allow atractive demos.

Seems Carl has worked on that in march...
http://www.rebol.com/r3/docs/gui/guide.html

the R3 chat architecture is VERY nice... it just needs a GUI client.

actually the r3 chat system *client* is still pretty simple... but 
the way messages are managed via the server seems to be much more 
flexible.  every msg and file is its own single item.  they are downloaded 
as items, not as groups of items.


so actually, all that needs to be done to make r3 chat scale is to 
improve how it stores its messages on disk and on RAM.   


the fact that the server supports moderation, threads, user levels, 
files, and things like item re-classification is very nice.


really, all it needs is a gui client.... that's If the server is 
able to respond quickly to requests.

something like REBOL3! low-level gfx  could be ok,

note this isn't about discussing how to use view or a gui.


this really is for talking about rendering, graphic pipelines, agg 
C code, gfx engines, CGRs, stuff like that.

!REBOL3 Gui is now [web-public] -- may take an hour for the content 
to fully apear on REBOL.org.

I'll change the others in the next couple of days, unless there are 
any objections.

http://www.altme.com/cgi-bin/lookup.cgi?lookup=rebol4


To get the WNS to refresh, the world must be started from the GUI, 
not via the CLI.

download latest version:
http://www.pointillistic.com/open-REBOL/moa/files/renote.zip

macro-editor:

http://www.pointillistic.com/open-REBOL/moa/files/renote-macro-editor.png

I also did a bit of gui polishing:
http://www.pointillistic.com/open-REBOL/moa/files/renote-6.png

So, we are back online with our AltME world. We mostly recovered 
everything thanks to Cyphre's effort. Now everything is backed up 
in 6h intervalls. Won't happen again.... back to work on R3-GUI stuff.

Announced systems, but never delivered. Max - this is not for this 
group, but - where is the GUI stuff (the names I don't even remember), 
where is DLL wrapper for R3? All stuff was supposed to be released 
in few days/weeks?

We have setup official R3-GUI download place: http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip


To access all our stuff directly: http://www.rm-asset.com/code/downloads/

please use the rebol 3 gui group, thanks.

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

If I had better relation with Robert and RM-Asset I could have updated 
MDP-GUI the only browser of MakeDoc Pro documentation made  in rebol/vid 
2. :)

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release change notes:

- added missing images to docs (thanks to Pekr)
- UNVIEW now works like in R2
- removed STYLE/FACED, now it is obsolete (use only STYLE/FACETS)
- improvements to facets creation
- fixed box-model border caclulation
- fixed binding of actors
- DO-STYLE code optimalization and fixes

- VIEW function cleanup, now it should work on block of faces as 
well
- fixed panel(container) names binding
- fixed 'load trigger calling
- fixed WHEN style
- misc smaller fixes
- old unused code cleanup

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release change notes:

- show-native recursive issue fixed
- enhancements to TEXT-LIST, TEXT-TABLE, TAB-BOX styles
- fixed DO reactor call
- fixed reactor actions handling
- optimized INIT-PANEL function
- added FOREACH-FACE function
- fixed internals of triggers subsystem
- optimized DRAW blocks handling
- optimized DO-STYLE and DO-TRIGGERS code
- added triggers handling to set/insert-panel-content
- lists.r3 code cleanup
- cleanup of unused/leaked variables

We just put the GUI panel documentation online at www.rm-asset.com

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-updated documentation (though still incomplete)
-complete new set of examples
-new hint based autosizing

-many internal and style related fixes and improvements, for details 
see: http://rm-asset.com/code/level1/r3-gui/#toc1

An evaluation of the compatibility of this new release of R3GUI with 
the standard r3-a111 release (recompiled), and an adaptation of the 
Carl's demo.r to this r3-gui.r3. Result : very good. It's time to 
develop r3 view applications !
http://www.colineau.fr/rebol/r3-gui.html

New RMA release of R3GUI version 2124 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-new set of examples
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

r3-gui demo updated. Present version : 0.5.0. New validated tests 
: drawing, clock, scroller, windows, text-list (simple system browser)

New update of RMA version of R3 host-kit is available at http://www.rm-asset.com/code/downloads/index.html

This release contains:

-enhanced GUI-METRIC function


NOTE: This version is also needed to be able run the latest R3GUI 
from RMA.

New RMA release of R3GUI version 2182 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-generic box-model presets
-better text sizing
-improved keyboard navigation
-correct handlind of minimal window size
-cleaned up style tags
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2338 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-new dividers subsystem

-support of application 'shortcut' and 'access' keys (see panels-15.r3 
for details)
-more stable resizing
-improved keyboard handling in some styles
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2367 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:


this is just minor update(as previous one has been published only 
2 days ago) so we(RMA) get back up-to-sync with 'Friday release' 
frequency ;-)


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

2367 version of the RMA/GUI and style not a menu bar .... pfffff...

if you have troubles with REBOL/View 2.7.8 on (stock) Ubuntu 11.04: 
install the xfonts-100dpi and xfonts-75dpi packages, and restart 
your GUI session afterwards

New RMA release of R3GUI version 3015 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes(just the main changes):

-removed reactors
-udpated documentation
-reworked text-list, text-table styles
-new testing tool + basic tests included 
-improved keyboard handling
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

Web-Site updated. See: http://saphirion.com/development/


- the rm-asset.com site is no longer valid, the company was terminated

- we use a web-font please let me know if you see any screwed up 
pages
- this R3-GUI release is a huge one, see history

Any comments and feedback welcome.

Pekr, yes you are lucky because czech chars are present in the default 
font. Chars of other languages can have problems so they need the 
Lucida COnsole font or even better one.
The current situation of the win console is:

-we can have core.exe as 'console app' which will work as the 'prototype' 
I released for testing

-we can have view.exe as 'GUI app' which will always open own console 
window (even from cmd.exe)


(If we make the view.exe as 'console app' there will be always quick 
console window blink during execution where only GUI window is shown 
initially)

first: it does not really matter for the graphics if the binary is 
compiled as console or gui app. keep that in mind

so when you start view.exe by dropping a script which displays a 
rebol gui on it, you'll have a short blink of a win32 console before 
the rebol stuff launches. which is probably undesirable.

I don't understand the issue sufficiently. What I simply want is 
- messing with just one exe. Being able to either use it in SSH session, 
or from icon, including GUI :-) I know I tend to require too much 
:-)

way around this: compile view.exe as gui app :)

This guy is somehow reusing dos console in GUI app, but maybe it 
is a different matter - it seems he is just redirecting the console 
to give it a GUI look? 
http://www.codeproject.com/KB/threads/consolepipe.aspx

Pekr, Andreas is right. The problem is that the 'flag' if the app 
is of Console or GUI type is set at compile time. So when you execute 
file th Windows kernel just checks that flag and if set to 'Console' 
immediately creates console *before* the main() of your programm 
is called. So even if you put: ShowWindow(console, SW_HIDE); as the 
first command in your app you'll always see the console window for 
a while, which is not so nice ;)

OTOH if your app is of 'GUI' type and you execute it from CLI (for 
example cmd.exe console) the CLI automatically detaches your exe 
from the console so the cmd.exe propmpt is able accept next commands. 
This is also problem because even if you try to re-attach your GUI 
app back to the console from which it was started, the console is 
shared in paralel with the CLI process and your app. So in the best 
way you'll see two interleaved input lines...one fro rebol commands 
and one for DOS commands.

Now Modules are here. A central repository is going to be created. 
Then GUI will be completed.

A question: what's next for REBOL ? Datatypes ? Will we go out of 
alpha then ?

in my opinion, R3 is already useable, apart from GUI, maybe pop, 
ftp, proxy support (nowadays I don't need it though), and ugly console 
:-)

Actually what is stopping me from using REBOL3 is the lack of GUI 
and SQLite support but I have them in REBOL2 and I'll continue using 
it.

In REBOL3 I am only a spectator. I do not complain on the time it 
gets to be complete. I do not need the very last feature. I am passionate 
about the work you are doing on it. It is very hard.  It is nice 
to see you, genius, at work.

And likewise Henrik can release his own GUI builds with his oid set

The practical advantages of the SET BIND/new trick as opposed to 
APPEND is that you don't have to REDUCE a block to be appended. The 
point to the IF :val guard in EXTEND was to screen out false and 
none in GUI code, but that is likely no longer necessary. There was 
a blog where it was suggested that EXTEND be rewritten to work differently, 
but I think that various natives were enhanced instead. EXTEND is 
now a little anachronistic.

I think that the code where we wanted to screen out none in the GUI 
code is now using the map! type instead, which does this itself.

That can be done in REBOL, but it requires planning for it ahead 
of time and a bit of explicit redirection. This is done in the R3 
GUI.

GUI frameworks tend to be a good place to use class-based or delegation-based 
OOP, as we do in the R3 GUI.

I don't really see the point though. Explicit delegation is not hard 
to do, especially when you write accessor functions, like in the 
R3 GUI.

Most things I still can't do with it, because there's no GUI

The lack of GUI means only web apps can be made, but there wasn't 
an acceptable web framework for REBOL

Btw Henrik, I read your GUI R3 code. It's R2 fashioned. You missed 
some R3 tricks. I suppose you already know it though ;-)

it's quite possible that some functions are from the original R3 
GUI, long before newer tricks were involved.

Hope 2011 will bring us GUI; SQLite, REBDB and other databases connection; 
many tickets closed. I don't ask for more.

Remembering the function naming discussion from the !REBOL3 GUI group 
and seeing the 

http://curecode.org/rebol3/ticket.rsp?id=667&cursor=1#comments

I could not help but point out:


As I see it, not using the question mark *is* violating a naming 
principle that was explicitly stated. I know, that in REBOL we don't 
have to be that rigid, but, when we have explicitly stated a principle, 
we *should* stick to it. ( http://www.rebol.com/r3/docs/concepts/scripts-style.html#section-10
)

The noun-OF convention is usually reserved for intrinsic properties 
rather than contents, at least for the mezzanines, but you might 
consider it for contents in the GUI code if it seems appropriate.

I can see that, and I'm not sure when work on threading will start 
or if Carl is studying it behind the scenes. All I can see is that 
many things right now are being handled on RM Asset needs, which 
right now is very focused on bringing certain tools to life. In that, 
there is work on GUI and database connectivity.


The SSL discussion was initially brought up by Cyphre as he talked 
about his prototype (which I now read is in fact done in R2, sorry). 
Carl gladly accepted this and asked for specification on what needs 
to be implemented natively to make it all work.

The same question for R3-GUI

R3-GUI is open.

So when GUI and SQLite will come they will be welcome.

a very important point is that this version (exe + dll from Carl) 
is compatible with the RMA R3-gui

presumably runs the gui

the rebol3-gui of RMA is on a good way. now we would like a R3 fixe 
to have the GUI on Linux & Mac !!!!!

R3 has a real chicken and egg problem. Much work could be done without 
Carl's direct involvement but for many people Carl's work is not 
yet sufficiently complete for them to do it. (A good example being 
the work you've put into R3 schemes, Graham).


The RM-Asset team are doing a great job of making progress with R3/GUI. 
Lets hope that they can continue and don't hit some issues which 
will need a lot of Carl's time to fix.

Nobody can take over from Carl as he has complete control over the 
source of the "core" of REBOL. Different people could take the lead 
for different "non-core" projects. Robert is taking the lead with 
R3/GUI. (Perhaps because he has a need for R3/GUI). You had taken 
the lead with R3/Network schemes.

There are two sides to R3 adoption for me. First is the available 
features. I greatly prefer to have basic schemes (HTTP and FTP in 
particular) built in. A basic GUI system is also important to me, 
but I can use R3 for non-GUI things without that. The second, and 
more important, aspect is stability and robustness. Is the module 
model stable, is it robust? Will tasks ever work? Are there outstanding 
core bugs that will prove problematic if they are never fixed. That 
is, if RT never did any more work on R3, could I use it for production 
work?

As for advantages, YMMV. For me, the improved PARSE, binary conversions 
that make sense, the map! type, the module system, the faster and 
more powerful loops, better error handling, and the increased consistency 
make R3 much easier to use. The extension model makes it more powerful 
- I always hated R2's library access model. But I don't do much GUI 
work in REBOL. R2 has database access that I use pretty often, and 
HTTPS support which I use rarely but it's important when I do. I've 
backported the most important missing functions from R3 to R2 in 
mezzanine form, though there is still some stuff I miss.

I can't invest any time in R3 without a fully working GUI and https

So, it's really waiting for the GUI team

(i have rebgui, cheyenne, vid-ext, rebdb, host-kit, musiclessonz, 
power-mezz, glass, r3 gui in this folder. ~500 files)

would it be possible (in general) to encapsulate the whole R2/3 GUI 
functionality incl. antigrain etc. into a lib, usable for other languages 

 as a out of the box GUI generator? communication & event handling 
 e.g. via TCP?

there has been a lot of work going on with a few R3 projects.  a 
few extensions, the gui, etc.

there has also been quite a bit of work done on Red.

I think so, but it was in that private world where Carl's GUI for 
R3 was being worked on with Henrik and me. It looks like INSERT works 
like SKIP.

- I / RMA will be the main communication channel. I have access to 
Rebol-3 twitter and there exists a RMA twitter.

- We will continue to work on the R3-GUI and release it as we did 
before (sometimes there might be longer periods of no-release, if 
we are doing massive changes)

- The main focus will be: fixing bugs, defining and writing down 
how datatypes are handled WRT conversion, priority, sorting etc.

Robert I'm happy you say you will continue to work on r3-gui but 
will that work produce some result  ?

Short update, we received a R3 Core version for OSX / Linux with 
the WAIT bug (consuming 100% CPU time) fixed. I still need to give 
it a try but I expect it to work. With this we now can use R3 on 
the non-GUI server side with our event driven BEEP based communication 
layer.

The core of REBOL3 appears sufficiently stable for a lot of work 
being put into developing a REBOL3 GUI.

I can accept that.  I've been looking at python and perl and cannot 
even choose a gui to work with.

I like python best, but there is no gui for v.3.0.

OK.  My interest is in a gui and a database.

Outside of rebol, what is the best free gui toolkit?

Hard to say... I'm not gui person, if I don't count Flash.. maybe 
other knows.

SFarber, regarding gui toolkits, maybe Qt is worth a look. Was created 
by norwegian Trolltech and acquired by Nokia:
http://qt.nokia.com/products/

I remember, it looked promising, when it came out. I don't know, 
if it still holds.

And of course, there was this strategy that R3 can't be released 
before the GUI is finished

hi, do you know if a r3 gui for linux will be out soon or later ?

On a separate note, I want to standardize on either R2 or R3 for 
work (no GUI or SDK required). What are the advantages of R3 compared 
to R2 at present, and what (apart from GUI and SDK) can R2 do that 
R3 can't?

Ashley: Good question, thank you.
Ladislav: Thank you for the answer.
apart from GUI
: there is still no official GUI for R3. You can use RMA's.

there is still no official GUI for R3

 - frankly, that is inaccurate. The GUI is "official" in the following 
 senses:

- Carl "delegated" the GUI development to our team
- the GUI is the continuation of the Carl's version
- the GUI is available for everyone
- the documentation is available as well

- the development of the GUI is continuing, for every new version 
of the interpreter, the corresponding GUI version is available

Ladislav - as due to low public interest the GUI is not going to 
be published so often, I would like to ask, if some work on "nice 
skin" has already started? (I am referring to a blog post :-)

Ladislav, how do we now access the R3 GUI and the REBOL core on which 
it runs?

No server problems: http://www.saphirion.com/development/r3-gui/

That would be great. Would you be willing to present a talk, for 
example I'm sure everybody is dying to know about R3 GUI development?

- State of the GUI 2011

- GLASS, a Data Flow Driven GUI Engine