World: r3wp

Not as far as I know ...

as for show stoppers, resolve has a serious crash bug on all platforms, 
not only osx

Maybe we need to get Carl to fix the real show stoppers

that would be a big help

Yes

Can we get a list together ?

And the ODBC scheme is indeed using the Windows interface

I volunteer Andreas to draw up a list :)

I meant nominate :)

A prioritized list

CALL is important to me. Not sure where that stands.

CALL we can mostly do on our own, as extension.

(And get that merged back into the native later on.)

blocking stuff is that which can not be done except by Carl

Well, that's interesting .. nothing blocking!

wasn't there a bug also in the extensions which crashed the core 
under some relatively obscure case, like the number of commands or 
something like that?

here's one list i once started of crashes and blockers:
1422    Rebol crashes when opening the 128th port
1799    maps broken for >2**24 entries

1806    Error after loading an extension: "REBOL System Error #1207: 
assertion failed"
1825    Crash in RESOLVE
1865    SIGSEGV when importing modules

1867    In extensions, returning with RXR_BAD_ARGS or RXR_ERROR has 
no effect

feel free to send me your blockes, and i'll collect them as well

Want to publish a list somewhere?

yes maxim, that's 1825/1865 which is most likely a bug in resolve

Andreas, is there a RESOLVE bug which affects Windows?

Or we could use the checklists on Altme ... though I'd rather not

Brian, I think 1865 does.

Do we have serial port access?

I guess that could be done by extension too

1865 affects Windows too (just tested).

we are missing device extensions and there are some limitations in 
the event model which make it impossible to extend it with new event 
types or actually fixing some of the weird event handling I've seen 
(its munging some events being fed by windows).

is that really blocking though?

it prevents us from doing some things yess... just like the threading. 
 if you need it, you can't go around it.

Ok, that can be prioritised .. I personally was thinking of getting 
R3 up to R2's level

So, we can say to Carl .. if you fix n1 ... n10 or whatever, 90% 
of us can start to use R3

And it can't be called alpha or beta.

So, would this be agreeable to those here?

sure.

I'm all for anything that moves us forward, but solutions like cURL 
and CALL via an extension means I know I'm going to have to change 
things later, or live with more pieces.

And it can't be called alpha or beta.
 ?

CALL via extension should ideally not require any changing later 
on.

I guess I assume Carl has a prioritized list already. :-\

We can fix CALL - it's in the host code.

Ideally, yes. :-)

Carl's priorities may not match those of us in the real world

I'm assuming his main priority is for people to use R3

If it's not,everything else breaks down

We need a prioritized list of stuff that we need Carl to fix. The 
rest (mezzanine and host) we can do ourselves.

Brian, for deployment purposes. Running production services on something 
listed as Beta doesn't fly. If anything goes wrong, labeling matters.

It doesn't matter if Google gets away with it. :-)

Do we need the alpha/beta label removed for just the r3lib changes? 
It might be worth labeling as a separate product, so we can work 
on the host/extension stuff ourselves.

I narrowed down 1825/1865 to the minimal code. I'll comment them 
accordingly.

Tried on Linux or OSX as well?

(Just privmsg me and I can try it quickly.)