World: r3wp

Just for those reading here (that is, please.... do not post web 
links to it), new wiki has:
www.rebol.com/priorities.html

(So Pekr, if you're wondering what's happening, that's where you 
check.)

:-)

Hi James.   There's actually an outline mode in the new wiki... so 
it's very easy to maintain and update this list.

Yes, very impressive.

I probably need to put a no-cache meta directive on it.

OF course the issue is not the list, is it? It's "doing" all the 
stuff.

BTW, the website looks nice and it's fast. I miss the link to the 
 script library though.

Correct.  But, I want to findout what people want the most now.  
I think last time "conference" was about posting the Console code 
from R2 as a starting point for that project.

Anyway, bbl to read replies.

My regards to Cindy and your kids. I'll get out of the way for the 
"real" rebol troops. Thanks for all your effort. See you at the Devcon 
:-)

Just for those reading here (that is, please.... do not post web 
links to it), new wiki has:

This group is web public !!

With the progress Graham, Andreas, and Steeve (and maybe others I've 
missed) have made on schemes, I would like to see their momentum 
and work leveraged. 


The host kit is probably also very important, so others can pursue 
that. Redirection, for writing pipe and filter apps. If the GUI console 
for Windows isn't too hard, that would be great IMO.

My feeling is that whatever is the most enabling should be done first.

Otherwise a lot of people remain blocked.

i agree. which is why i would like to see renewed focus on the hostkit

Working on compressed modules this week, inline export already done, 
protected header fields waiting on PROTECT fixes. It would be really 
helpful for there to be a discussion about the design requirements 
for embedded deferred init modules.


Really looking forward to host kit changes. Waiting on READ/as and 
WRITE/as before I start improving the clipboard:// scheme.

here's a personal wishlist:


1. a license for the hostkit, which would allow us to publish and 
distribute patches and custom builds. this would be a necessary precondition 
to bootstrap a healthy hostkit ecosystem (if such a thing is desired).


2. documentation of more hostkit intricacies, such as "documenting 
the boot script build method" mentioned on the priorities page. another 
pet peeve of mine would be documentation on how to add new native 
port types (such as ssl). and fixes (if any) to enable creation of 
such native ports by only touching mezzanines and the host kit.

3. a libr3.dylib built for osx.

right now flushing out (finishing) the extensions is actually the 
most enabling.  so: 


1.  Releasing the view host-kit with improved extensions would be 
the first step into finishing WHAT the first R3 beta will be, in 
terms of architecture. Right now, there are a lot of datatypes missing, 
and a proper REBOL callback mechanism *** with return value***  is 
probably the most frustrating issue with R3 extensibility.  image 
and vector types are critical to extensions... please they have to 
be part of next extensions.


2. Schemes!!!   with a lot of work ALREADY done,  plus willing and 
able helpers, Carl, you should REALLY look into this and orient the 
spontaneous team that is dying to get your attention so they can 
proceed FOR YOU.


3. Documentation ... I'd say.. .TWO complete and final pages a day... 
no need to do more.   At that rate, the documentation will be much 
more helpfull within weeks.  But sections of it will start to be 
worthy of being called documentation... right now... I'd call it 
the "sprawled notes" part of the site.

So, is SSL an extension?

SSL needs the ability to add devices, which in theory you can do 
in the host kit but noone has managed it yet. It would not be addable 
as an extension until we get device extensions. So many things are 
waiting on device extensions...

So, is there a documented dependency tree somewhere ....?

On external libs, or internal dependencies?

so that the most enabling work can be done .. what's at the top of 
the tree?

I suspect it's the license!

Oh, sorting the todo list. No, the license isn't at the top.

Let's see:
- 1.6 depends on 1.2, and 1.3, 1.5 and 1.6 are related to these
- 2.1 and 4.3 depends on 1.1 (probably)
- 2.2 depends on 1.6 (probably)
- 3.3 depends on 2.1, 3.1 and 3.2
- 4.1 is written and submitted already
- 4.2 is in process
- 4.3 is waiting for discussion
- 4.4 depends on 7.1

- Clipboard support for other formats than text depends on 5.1 and 
5.2
- 7.3 and 7.4 will probably use the same code
- 8.2 depends on 5.7

- 8.5 (and secure use of R3) depends on 5.5, 5.8, 7.1, 7.2 and possibly 
6.2
Those are the dependencies I can see in the R3 priorities list.

now topo-sort it, break cycles and off you go :)

hahaha.

Has return changed in R3?

requires a value now?

No, it's function argument handling that has changed. RETURN required 
a value in R2 as well, you could just cheat.

yes, use EXIT if you don't want to return a value

got ya.

thanks.

You can't cheat on word [unset!] arguments anymore. You have to use 
lit-word [unset!] or get-word [unset!].

ahh - that is good to know also.

Look at the source of CD for an example.

will do.

yeah unset it returns current directory - nice feature.

That kind of thing is *only* for use in functions meant to be used 
interactively from the console (at least that's the policy).

this means R3 *technically* actually has variable length arguments 
 :-)

on top of refinements.

That CD has been ported to 2.7.8 - see the Core group for the source.

Maxim, you misspelled :-(

Priorities not in the priorities list:

- User-addable devices in the host, and device extensions (probably 
the same mechanism) in section 1
- SSL in section 8

misspelled what?

You spelled :-( as :-)

aaaah hehehehe

but don't see why this is bad, its very confined... I mean... its 
not like we're going to start seeing this in code:

do [cd]

just so we can supply less arguments and slow down our code.