World: r3wp

Paul, that is the plan. The old monolithic REBOL will go away once 
the module system is up and running. There are already functions 
flagged for moving into non-default modules - especially ones that 
have limited use or too much overhead.


But remember that we add these mezzanines so that we can use them, 
and many are just cleaned-up versions of code that is used in the 
GUI, the other mezzanines, the intrinsics, etc. We are trying to 
keep things as efficient as possible so that the code that is loaded 
by default is minimal. Still, you will have to realize that REBOL 
is partly written in REBOL so you can't get rid of everything.

Some of the new code is there to get rid of common bugs in code that 
all REBOL programmers write, or to make efficient versions of functions 
that are done over and over again, poorly. Other functions are being 
written to figure out where R3 needs some improvement, though they 
will be usefl on their own (like REWORD).

We'll reorganize the functions when we have the facilities to organize 
stuff (modules). No worries.

Brian, I'm critical of how Carl and the dev team are handling things 
at this point.  At least from my perspective this project is being 
managed poorly.  The rollout to the new developers to test and provide 
feedback is not being equipped with a "hit the ground running" gameplan. 
 In order for anyone to know what a function is they must source 
it and they have no access to examples.  Sure we can eventually figure 
out how the code works but that comes at a cost to each of the new 
contributors in time and energy when this could have been facilitated 
by others of the reb dev team.  Regarding, the mezz functions, I'm 
glad to here they won't be built inside the main bin and includes 
as modules.  That is good news.  Regarding, chat, Carl needs to run, 
not walk, away from using console for chat.  The more that console 
chat is used the more concerned I get a feeling that R3 is a mirror 
of that same level of usability which is not a good impresion.

The advantage to the current chat is the messages in it, not the 
UI. Those messages are still going to be there when the GUI client 
is in use, and we needed something in place to get the information 
out there and managed (AltMe wasn't good enough at management). However, 
you have once again figred ot the plan: Carl intends to run, not 
walk, away from using console for chat.

I hope so Brian,  I don't want to be discouraging to others about 
R3 based on these observations because I know that objectively its 
a critical analysis in the midst of its evolution which is never 
a guage of what will be the final product.

I just think more care needs to taken to expedite those things I 
mentioned.

As for the project management, with the limited number of developers 
the self-organizing model has been working so far. We will manage 
to organize more developers when we get more developers. Which the 
release has not brought us yet - only users and testers (both appreciated).

We need help. There is only so much Carl and Henrik can do, and I 
am busy with work right now so I can do even less. I have seen people 
putting in bug tickets for changes to the wiki - when they could 
easily make these changes themselves. It's frustrating.

You need to ignore the UI of chat for now, because the important 
problem being worked on now is getting the source file database integrated 
so developers can see that source you were requesting. Then we will 
have more developers (in theory) and we can get the GUI working well 
enough to write the GUI chat client you also requested. Which shouldn't 
be that hard - all of the tough stuff is either handled by the chat 
infrastructure (which is mostly there now) or the GUI infrastructure.

If you want to help now I can get you an account on the current DevBase 
- be warned that the GUI is not great yet (because it's R2).

BrianH, I would love to help out where I can.

just want to express my oppinion that I am happy of the core things 
beeing in focus (language, runtime, core libs (tcp...)...) not the 
"addons" like gui

I sort of agree, but most of the core bugs were discovered and fixed 
during the course of writing the "addons" like the GUI or non-core 
mezzanine functions. Most of the core language enhancements came 
from the GUI work too. I expect the work on higher-level port schemes 
will help debug the low-level port code. You need to write the high-level 
stuff to help refine the low-level stuff.

I found two bugs, one issue and a potential language enhancement, 
all about the map! type, all during the writing of one function (REWORD) 
that many people may not use - it might be one of those functions 
put in a module that isn't loaded by default. Still, time well spent 
if it makes map! better for all of us.

most of the core bugs were discovered and fixed during the course 
of writing the 

addons" like the GUI or non-core mezzanine functions" yes, I fully 
agree with this and understand that higher level code tests and helps 
design (reiterate) the low level that it's build upon...

but I still take decision to make chat in CLI first and not focus 
on GUI etc too quickly very highly. Because having a good core on 
which gui (or many gui-s) and all things are built seems 100x more 
important than having *something to show* .. a nice gui on a patched 
core... I appreciate the priorities and focus, and this tells me 
that I can rely on R3 being good.

You caught onto a good principle there, Janko. We are really focused 
on the core now with chat. Admittedly, it is the core of chat rather 
than the core of R3 but the principle is the same: We need the communications 
infrastructure there so we can communicate now, and that will make 
it easier to make it pretty later :)

Don't worry, we are also focused on the core of R3 :)

R3 plan for February - http://www.rebol.com/article/0389.html

very good summary!

I ported my CMS to R3

The results are not very encouraging

It´s written in a simple style, yet I had to make a series of tweaks

I encountered several bugs and I had to write a series of wrappers 
for READ and WRITE to arrive at functions that act compatible between 
R2 and R3

Eventually, when I built a number of OpenOffice XML files that take 
three seconds on R2, it took twenty seconds

Is there any reason that R3 would be extremely slow under WINE?

Please post any bugs you find in CureCode. There are some changes 
in the way READ and WRITE work though.

I can't test in WINE, so any bug tickets would be appreciated.

Actually, I hit another bug that makes it impossible to port my CMS

In R2, dir? tests the file node to see if it´s a directory or just 
a file. However, in R3, dir? works like file? and only tests whether 
the value ends with a #¨ /¨

This leaves no way to detect an actual directory

alpha software is out there to be stressed

One doesn't really expect it to work ....

Did I say otherwise?

Yes.  You're implying it.

No, I´m not

Perhaps not consciously... but that's how it appears to me.

Are you a brain doctor?

Kaj, can you post some code which breaks DIR?

Just human

Why don't you just port dir? func from r2?

.... it is a mezzanine, you need to port throw-on-error to be compatible 
...

¨ dir? anything¨

interesting... dir? works fine here.

Thanks, Petr, that should work

ah, I get it now

but it does test correctly for existing directories. it's a little 
ambiguous, but testing also for EXISTS? could help

You sure??

>> dir? %asdfsdf/
== false