World: r3wp

pekr yeah but when you computer is already filled with HTTP request 
adding more "SQL requests" slow downs your HTTP or at least that's 
the way i see it and that maybe too why all the database builders 
created another entry point called odbc

r3.0  will be only core right ?

Shadwolf - I am not dismissing opensourcing REBOL. I just try to 
point out, that open-sourcing it now would not bring us any significant 
advantage. It would not bring us hundreds of coders suddenly, being 
able to add good and quality code, so that Carl could accept it. 
I am for finishing Beta plan = finishing Core to the level of satisfaction 
and THEN releasing the Host code = everything except the interpreter. 
Interpreter code can be released later ...

pekr ... who open source a software in alpha stage ? (a part me but 
i'm special  ^^ )

3.0 beta? Dunno. There will be View in it, but not sure it will be 
finished. I expect it being Core release. But -look at beta plan 
here:

http://www.rebol.com/r3/project-plans.html

Carl even agreed to adapt list, to make it wikified, so that we could 
update it for the final beta list ...

cool so when VID 3 work starts again before or after new year's eve 
?

I think before ...

but we can't be sure. R3 progress in last year is good enough, at 
least for me. I am satisfied. If you will ask folks here, we would 
have some trouble to agree, upon what should be next. I like VID3, 
so I would like if View evolved a bit, but many others might prefer 
core stuff as tasking for e.g.

yeah with often ralpha release at least we have time to test and 
find most of the bugs and that makes the wrok more dynamic... In 
comparasion of the way the rebol implementation was done and how 
it's done now I from far prefere the actual way and it's getting 
our small community tigher to Carl ...

Shadwolf, Carl wasn't looking for a "SQL like language" to embed 
in REBOL, he was looking at projects like SQLite to see if he could 
extract their table engine and use it directly without using SQL 
at all. This was for RIF (REBOL Indexed Files).

who open source a software in alpha stage

 - Most open source projects do this. And most open source projects 
 never get out of the alpha phase, because open sourcing a project 
 doesn't get it done faster - most people don't contribute, period.

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.