World: r3wp

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

it seems it will do this:

- it tests FALSE for an existing file
- it tests FALSE for an existing file and adding a /

- it tests TRUE for a non-existing dir with an ending / <-- bogus?
- it tests TRUE for an existing dir with an ending /
- it tests TRUE for an existing dir without an ending /

crap ... had wrong version of rebol up

the bogus one would be eliminated with an EXISTS?. still it's a simpler 
way to test for non-existing dirs, say in preferences files for paths 
and some basic syntax checking.

but you also have to check the ending / if you want to form paths

in R2, we have to do the "#"/" = last file" check

annoying ...

so, I think there should be a function for that, but having it in 
DIR? may be ambiguous.