World: r3wp

Looks like he needs a project manager

Another activity, which actually helps nothing ....

There is one thing, I hardly understand.

It was said, that he wrote R2 in a very short time, as he was not 
satisfied with R1.

Now he has the the experience with two shots, he has got a community 
with people ready to help and knowing his intentions and experience 
too.

What happens?
It fizzles out ....

One has to take the help, give some control away, live with the fact 
that not 100% will be as if you would do it yourself. But that's 
how woring in a team / with others is.

The benefit? It scales better than on person.

(wow several typos in just three lines...)

http://www.rebol.com/projects.html

Looks good so far. One complaint: In the binary conversions section, 
R2's struct! type is mentioned, then it says "Something similar is 
needed in R3". Please, no, at least not for conversions.

Each of those pages needs to point to a page on rebol.net's wiki 
so we can edit them

of those points ...

Yes

Each of those pages should have something like:

Lead: ..
Members:
Completion Status: ...
Discussions: altme web link
Repository: ..

or similar

which means removing the lead and status fields from the projects 
page

No, duplicating that info on the projects page is fine. If someone 
is willing to do the work, they deserve to be recognized.

Think of the projects page as a summary.

Eh?  I'm talking about redundancy ...

unless the projects page is dynamically generated it will get out 
of sync rapidly

Right. Redundancy is fine on a summary page.

Disagree ..it must means more misinformation we don't need

The lead and status won't change that often.

That's because everything goes so slowly ...

I don't have that expectation in the future

The purpose of a summary page is to allow people to get a quick overview 
without having to go to the detail pages if they don't need to.

The lead and status summary are exactly the kind of details you want 
there.

So, use parse and extract that detail and put it on the summary page!

Can you imagine Carl is going to maintain the summary page??

Fine, but I don't expect the details page to have a summary of the 
status, I expect it to have a detailed status. If you are expecting 
projects to have a lot of activity, is it so implausible to imagine 
the projects page being maintained?

Yes, because they're different sites and different people.  We know 
Carl is the only one with access to rebol.com pages and history tells 
us he can't maintain them.

We know that Carl being the only one with access to rebol.com pages 
is considered by Carl to be a bug in the permissions system of the 
rebol.com site, and that he is working on it.

People with sufficient rank in DevBase are supposed to be able to 
edit some pages.

Of course if that is abused, they lose the rank.

Is anything being done to support proxies?

nothing is done to support anything, imo :-)

what I like though about the project is the specific one - Codecs 
being reworked from functional to port model, to better support streaming 
:-)

Does proxy support require work at the C level?

I think not necessarily. R2 supported proxies (at least some proxies) 
too. There was an idea to have networking protocols use OS specific 
layers. That would still be imo a possibility.

fromt he priorities page: "Text codec project has been deferred due 
to community input. The project will be reorganized to make codecs 
into a port datatype and allow external codec devices as well as 
streaming (with port's holding the steam state.)" ---- I really like 
it :-)

Announcing the availability of the http://www.rebol.net/wiki/Pair_enhancements
article. Discussion welcome.

As it looks, due to the efficiency issues (speed), the implementation 
of REBOL pairs as pairs of floats looks to be the fastest (since 
AGG needs double values, and conversion from float to double is faster 
than conversion from integer subpixel count to double using a foating 
point division looks slow)

So, everybody opposing this pair implementation change: please speak 
now or remain silent for long time...

Ladislav, you need to put the AGG implementation considerations on 
that page. The page currently looks like you are advocating using 
48bit integers, not floats.

OK

You might even be able to use doubles on 64bit builds of R3, due 
to the need to have larger value slots.

has it been already settled how big the available space is? (in 32-bit 
version we have 96 bits at most, as it looks)

Some of the value types require 2 pointers. On a 64bit build, pointers 
are the same size as doubles. It's an internal matter anyways.

So it looks like 128bits are available.

I'd prefer to get the 96-bit pairs with each x and y using 16 bits 
for subpixels, keeping the memory down, and not reducing the integer 
range. So I'd like to know just *how* much slower this implementation 
would be than using floats or doubles.

Anton, do you happen to know any example that would show 96-bit = 
48x48 bits with 16-bit subpixels to have an advantage over 2 floats?

Anton, there would be no memory savings by using 48x48 integers. 
The pair would still be in a value slot, and value slots are fixed 
size. And they would be slower to access because of alignment issues, 
plus the floating point multiply to convert them to the doubles used 
internally in AGG. "So it looks like 128bits are available." - only 
on 64bit builds of R3, not on the 32bit builds we have now.

Test results (Brian is right, that 96-bit pairs cannot save any space 
compared to pairs of floats - actually just 64-bit pairs):


1 conversion of the X coordinate to double when using 96-bit pairs: 
ca 50 ns

1 conversion of the X coordinate to double when using pairs of floats: 
ca 10 ns