World: r3wp

I agree Pekr, R3 progress has been excellent, the project plan is 
solid and focused for an effort of this size.  Things have really 
picked up in a good way.

I want RIF, I want VID3, but I will be happy with the 3.0 beta without 
either, especially with extensions as a good way to work other options.

As soon as we get device extensions, SQLite can be wrapped, as well 
as any other DB with native libraries with compatible licenses (meaning: 
not MySQL). MySQL could be worked on right now through TCP.

BrianH: why do we need Device Extensions for DBs? To have it async? 
Because - DBs could be wrapped even now, no?

Carl replied to the stack size question:


Re #5530: Pekr, looks like a bug. The current stack limit is set 
to 400000. However, it is an arbitrary number. It can be user setable.

The 
PARSE limit can be made to use the entire C stack, rather than a 
forced limit.

is the project list on any wiki page at this point?

(Relating to Carl's surprise appearance on monday... darn... where 
was I on monday!)

not yet, and I wonder if Carl will make it. He's into parse right 
now ... we will see, we can always remind him of that ...

ok, I would have added my extension example there right away...


 its funny cause he made devbase so we would have a channel to speak 
 with him within R3... then I use it posting callback proposition. 
  a few days later, he asks me where I put it (it sticks out in the 
 extensions groups quite a bit).  Si I give him back the link to the 
 original post....


 and a bit more than week later... he says here that he doesn't know 
 where the source to my extension callbacks stuff is... <sigh>  

Carl really needs a brain maid  ;-)

Pekr, we need device extensions so the database's event flow (callbacks, 
incremental calls, whatever) can synchronize with that of R3.

Without devices you won't be able to specify which task is handling 
the events, and how the events will fit into R3's event model.

You won't need new devices for TCP-accessible databases because there 
is already a TCP device.

Yes, Petr, parse a map! - parse make map! ["one" "two"]["one" "two"]

PARSE is ordered, and maps don't have persistent ordering. Iterators 
and queries are better for maps.

Think SQL-style set query operations.

Nice - http://freebol.org/private/tryrebol/

oh, this is web-public, I just read the request of author to not 
publish it publicly yet ... hopefully it is used by the community 
at max ...

it doesn't work for me. returns empty lines.

it does work for me in FF 3.5 and IE 7

Works for me in Firefox too....But the site has some security flaws, 
so not yet ready for the big time.

The sideswipes at REBOL at the end of the (very short) interactive 
demo suggest that HF had some frustrations in creating the demo site 
:)

what is the base of the frustrations?

Some technical issues in getting it to work; and the apparent lack 
of willing in Rt to fix these problems....There are under six pages 
of tutorial, so it is easy to get to.

authors of various TryREBOL systems seem to have problem with persistence. 
Wouldn't Cheyenne be of some help here? By simple cookie you could 
identify the client and have one console session for him started. 
Cookie would expire at browser's end, or with zero activity for 15 
minutes for e.g. Is there anything I am missing here?

there would be a need for a session manager and process manager. 
I think, something like R3 Uniserve.

fastcgi keeps you connected to one process, persistently, and assures 
session affinity = it directs the same client always to the same 
process ...

do we have any date for gui R3 and the beta R3 ?

nop

could we aks for have gui R3 before decembre with Beta R3 ?

We can ask for anything, the question is, if it is possible to happen 
:-)

Carl expressed his will to release Beta this autumn, hopefully before 
Christmass.

before winter ;-)

Current project plan is here: http://www.rebol.com/r3/project-plans.html


Carl expressed his will to adapt the list and its priorities upon 
the needs of community ... I will ask him to wikify it, so that we 
might edit it ...

Do you need R3 GUI for any specific project, or just to play/learn? 
Because other folks might prefer more finished Core, e.g. Multitasking 
...

I am not sure everything on the list can make it into beta in reasonable 
timeframe ....

only for play and learn

i would like to upgrade the some of my app to R3

I thinkt that VID3 needs 2-3 weeks of work, maybe less, in order 
to be safe to suggest, because there are some structural changes/adjustments 
planned ...

I don't know how you can come with an estimate of 2-3 weeks especially 
as the current GUI only works on Windows and doesn't yet support 
Unicode..


Even if it only takes that little, I can't see Carl having 2 to 3 
weeks to dedicate to the GUI this side of the New Year.

Who said beta will span all platforms?

I am also not sure, GUI will support Unicode from the very beginning, 
altough many expressed it being a priority. There is a difference 
between GUI and VID. Carl worked on VID. Once he is back to it, I 
believe Cyphre is going to be contacted to do some work on View part 
...

My guess is 2-3 weeks for VID itself and 1-2 months for the skin. 
Really lowlevel stuff depends on the availability of Cyphre.

Cyphre is waiting for the C code alignment. He does not have recent 
sources for View. If I understand him correctly, he has to wait for 
the Host code release ...

... or for Carl sending him latest version ...

when it's ready, I hope that Cyphre can at least partially work independently 
from Carl.

A windows only beta will nicely establish R3's cross-platrom credentials.

A non-unicode GUI beta will nicely establish R3's internationalisation 
credentials.

OK, so wait another year for the beta ...

then I prefer Core only beta, all current R3 platforms ...

eek... I can use it to send email!

what else