World: r3wp

I only make the distinction between chat and DevBase for technical 
reasons.

I think we should factor them .. and remove the redundant 'Base ...

That would turn them into generic terms, rather than the formal names 
for specific things that they are now.

As you can see the TRETBASE group has really been picking up - this 
is because I'm busy porting the older Tretbase DBMS to R3 and finding 
problems along the way so I'm going to post some of the problem here 
to see if anyone else is seeing the same.

try a rejoin using two binary values.

Looks like a problem with append:

	append "" ["a"]
	append #{00} [#{01}]

Note that join works (as it's not appending a block).

Already posted a ticket about that today.

Are modules working correctly?

>> system/version
== 2.100.96.2.5
>> import http://www.rebol.it/power-mezz/mezz/form-error.r
>> source form-error
form-error undefined


Also, are the Imports and Globals fields (as used in Gab's Power 
Mezz) supported? ... http://www.rebol.com/r3/docs/concepts/modules-defining.html#section-3

Gabriele's modules aren't compatible with R3 modules, and the Power 
Mezz package is for R2 (so far).

Looks like just the Name field is missing ... missed that.

What's the easiest way (under R3) to write code like this:

f: make function! [[][
	cols: [c1 c2]
	data: [2 4]
	cmd: [c1 + c2]
	set cols data
	do cmd
]


without adding words to the global context? (and not predefining 
c1, c2, etc).

Use FUNCT to define the function and use cols: [c1: c2:].

Slightly clearer example of what I'm trying to do:

f: make function! [[cols data cmd][
	set cols data
	do cmd 
]]

f [c1 c2] [2 4] [c1 + c2]

APPLY FUNC cols cmd data

Still no luck:

f: funct [cols data cmd][
	set cols data
	do cmd
]

apply :f [[c1 c2] [2 4] [c1 + c2]]

f: func [cols data cmd] [apply func cols cmd data]

FUNC in R3 does a COPY/deep of its spec and code blocks, so it's 
safe to use here.

Perfect. Elegant as well.

the new R3 web site is SOOOO much better to navigate on..... 


yeah, it doesn't look like a million, but at least it doesn't get 
in your way, like the old site did. 

just tought I'd share my POV.

Max - it is just a structure, which was reshapen, and the page was 
also de-stylled. The layout, styling and gfx of the new site is not 
done yet, as well as front page segmentation for particular target 
groups interests ...

but already looks and feels better.

more lightweight, better structured, yes ...

Anything new ??

no, nothing ... not even web site changes anymore .... so - R3 black-out 
for more than 2 months ....

he did post on the blogs about what he's been doing and that he is 
now back to R3 coding.

Time to resume some R3 builds.  Do we have an ordered list of what 
we want to do next?

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?