World: r3wp

I wonder if it would preserve bindings? I can't see how...

I guess that the drawback is that RIF would probably be hidden in 
the Core part, so not open sourced.

Or it could be a UDT.

Probably if R3.1 takes another 3-4 years to be done ;-)

Just be thankful R3 is not a 100 year language like Paul Graham's 
ARC.

Steeve, as long as you're using a decent OS, any database should 
be kept all in memory regardless of size. Otherwise, you need a DBMS 
and a DBA.

Yes, some DBAs can do amazing things wih disks (disk tuning is a 
good selection criterion for a DBA)

Gabriele, it's your opnion not mine. we shouln't have to use DBMS 
or other external products (having to install them) for rebol applications 
which are standalone and not multi-user.

The file scheme of Rebol can do the job with a simple scheme wrapper 
(to hide complexity).

This has been requested by the community since long time ago. If 
you don't see the interest, good for you but let the other hope.

I have big long cutting knifes in my kitchen ! Who wants one ? It 
can help you finding who is right or wrong in a more funny (gore) 
manner ;-)

By the way, as Brian say, RebDev can stay as it is for a moment. 
It's simple Rebol data, so it could be easily transform to whatever 
new storage mechanism is needed when the time will require.

And, I don't think the client need to load the whole msgs db as most 
of the time (99.9%) user just read the lasts msgs. So It can be changed 
to cache last 10000 msgs and will only deal with the full db if user 
ask it to do (ie : search).


And to finnish, 24MB is not much for 100'000 msgs. I would not bother 
until it reach 200MB (It's what FF3 take after half a day of surfing) 
so I have 800'000 msgs left :-)

About protocols: Carl says that the basic foundation is not going 
to change, so he wants to see some protocols written. He wants to 
start with something simple like Finger. Here's your chance to contribute!

Carl: "most of the scheme structure has been solid and unchanged 
for more than a year. The main disruption was Unicode, but that's 
been done for a while too. I think we should pick a few very simple 
protocols, maybe one like Finger, and j ust show how they are done... 
as an example."

No Didec to work as you wish, rebdev client as to be rewritten completly, 
it's not a minor change.

What was the proposition for change for RebDev? If it would be upon 
me, I would accept SQLIte as small, robust RDBMS for R3, via plugin 
(to stay external). Wait, we don't have plugins :-)

Steeve, check your private messages.

Steeve, there isn't much code in the RebDev client, by design it 
wouldn't be much work to completely rewrite it. Everything at that 
scale is a minor change - that is the nature of the scale.

In any case, we can do this later.

Steeve: there are opinions, and there are facts. It is a fact that 
you can't be faster / more efficient than the OS. It is your opinion 
that you want to be less efficient.

Gabriele, you're out of my point, i don't say it can be faster than 
the OS.

Today I read acrticle about DB  market. There are going to be some 
specialised DBs in future, and the needs diversify and scenario usages 
too. E.g. IBM has SolidDB in-memory DB, which uses async syncrhonisation 
to DB2 or Informix or something like that ...

Yes it's cool, it's something i try to do with Virtual blocks (blocks 
which are synchronised with files). it"s a tiny scheme (script size 
less than 5 kb).
It doesn't allow sorted blocks currently but it could be.

I am also sure DB's will specialise and already do (couchDB, bigtable..), 
and I plan to make few simple specialised storages to for some my 
projects.

Steeve, exactly as I said, it is your opinion that you don't want 
to be efficient. It is my opinion that I want most of the time.

We have not the same defintion of efficience. 

The efficience of an application is a grid which contains several 
criteria. 

When you choose an implementation. All these criteria can't  have 
the best value together

Hiding this complexity by saying i'm efficient, and you are not, 
without saying you choose to lower some criteria, only reveals one 
thing, you're pretentious.

Can anyone give a range of time where rebol 3 will be released? If 
not, can I just be notified by email when it is?? I'm sick of logging 
onto rebol.com and checking the blogs. I've been doing this for at 
least a year and I'm sick of it.

sick of it

  seems a bit extreme.... there are other good reasons to check in 
  here.


But that aside, how about simply setting up an RSS feded off Carl's 
blog, and set it to pull once a month or so?

Feed.

Nicolas, what?  don't  you come here for abuse when you try to contribute?

Nicolas - your message is a little bit hars, so here's answer you 
deserve - don't come back until 2010 :-)

I personally take visiting blogs as a good sport, and am always glad 
that there is another blog posted, another piece of info available. 
You now have "what's next" kind of summary on rebol.com available, 
so how can you be sick of something, which CLEARLY states facts?

... I can understand, that you might be upset because you can't probably 
touch R3 yet. But that will change rather soon enough too. But even 
then - it is still going to be unfinished alpha, so if you plan R3 
level of functionality with all protocols, etc., you will not get 
it. OTOH you might get some new things .... R3 is product under development, 
and that is what we should remember.

Nicolas, the best you can do is just wait a few months and see what 
happens.

If I understand the last blog correctly, we can expect public version 
of R3 soon: "If you do not have R3, watch the website over the next 
day or so."

yes... that's what we normally translate into "the next 2 months 
or so" :-)

I know of a killer app for REBOLers. A few lines really: one BIG 
RED BUTTON that launches on startup of your PC and turns GREEN the 
day R3 is released.

I think I know what is wrong: Carl is thinking near the speed of 
light, thus time slows down for him, so while it takes two months 
to get the next R3 release to the public, it only takes a day for 
him. :-)

LOL

Steeve: again, that is your opinion here. The OS will always be more 
efficient at handling syncronization between memory and file, be 
it a swap file, or using mmap() and so on. So if your reason is "saving 
memory", then you are wrong here, because any real OS will do better 
than you. Then of course there's Windows, but that's a different 
story...

Okay, I get abuse, a good answer - "check again in 2 months", and 
banter. Pekr, "soon enough"? - what does that mean? and when I get 
it, it'll be an alpha? Now, I don't want to agravate anyone. But 
I'm tired of having absolutely no idea when rebol 3 will be out, 
and out of beta. An acceptable answer to me would be something like 
6 months give or take a year. If that kind of assurance can't be 
given then I'd like a bit of honesty. It's nice to be able to plan 
things.

I guess I'm just angry at myself for having waited this long, this 
eagerly.

Nicolas - every sane person should be able to read between the lines, 
no? So I tell you that all you can get for now is alpha, and you 
ask, if it is going to be an alpha? Waht if NOONE really knows, when 
we will be in beta stage? There were various propositions, and mine 
proposition was to create 3.0 with fixed featureset, and then go 
with 3.1 and later, adding other stuff. I can e.g. imagine 3.0 beta/full 
release just with GUI and R2 level featureset, plus Unicode, which 
is in there. Later can come things like plug-ins, threading, etc.

It's hard to plan at the alpha stage, especially since R3 is not 
at feature freeze at this moment. I use REBOL full-time here, and 
I won't be using R3 in my own projects for another year or so. It 
would be crazy to start doing that now for me. For new users, it's 
a matter of waiting. There is simply nothing else to do.

R3 development effort takes much longer, then we all initially wished 
for. But - in the end, it will pay of. What we should now concentrate 
upon and be grateful of is, that we can be involved in the development 
process, offer our ideas, influence final desing. Carl is exchanging 
ideas with the group on daily basis.

Nicolas, you could do what I did: Instead of waiting, help. If you 
passively wait you get back exactly what you put into it. All of 
that eagerness was wasted energy that could have been applied to 
helping get R3 out, or writing documentation, or even discussing 
semantics here. Complaints are a waste of time that could instead 
have been spent volunteering.

If you were so eager to use R3, why don't I know what you want to 
use R3 *for*? We could have added that use case to those being considered 
in the design. Even that could have helped a little - not to get 
R3 out the door faster, but to make it better when it does.

From Pekr: "I already asked Carl for some resolution towards RebDev. 
I really don't like it. We should get back to the main task - R3. 
So - my proposition is to create some plan to link apropriate RebDev 
chat to CureCode and other chat to current DevBase and get back to 
R3 GUI to get it to state, where we can rework DevBase, create RebDev 
GUI client, etc."

It is easier to add the VCS parts of DevBase to RebDev chat and rename 
RebDev to DevBase (the current plan) than it would be to get DevBase 
into a usable state. I know - I am the lead programmer of DevBase.


What we really need to do to is get the project to the point where 
we can release it to the developing public without it turning into 
a disaster and the project dying. We needed a way to enable and organize 
development discussions, completely integrated with DevBase, to help 
people cooperate instead of hinder the project. We have that now.


I agree that the CLI client for RebDev sucks, and that we need a 
GUI client. We don't need it *now* though: RebDev already works better 
than AltME for our purposes, and we can do the GUI after the public 
release. The messages we write now will still be there later, ready 
to be read in the GUI client if you want to wait for that.


We absolutely do *not* want chat in CureCode - comments in CureCode 
are *documentation*, not chat.


Because we went the route we did R3 is nearly ready for release to 
the developing public (as an alpha). If we had done as you suggested 
we would not be so close to release. Keep in mind that what you are 
suggesting we do is what we were doing before, and it failed badly. 
That is why we are doing what we are doing now, which is succeeding.

We are at a point in the development of R3 where we need the help 
of the rest of the REBOL community. This is why I think complaints 
from people impatient for R3's release are silly: Noone needs this 
release more that the people who are already working on R3. We will 
be releasing soon because we need to asap. The only delays to release 
now are practical ones, and not many, and we are focusing exclusively 
on fixing those problems right now (sorry Steeve, we'll get to the 
concerns you have been expressing recently, after release).

If we could have R3 modules feature available for R2, that would 
make the waiting for R3 easier...

BrianH: what has failed? :-) So far AltME worked - discussions, sharing, 
everything worked. Even r3-alpha as released one year ago did not 
cause any disaster. So - what actually failed? I have to be missing 
something ...