World: r3wp

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

Of course, other operations, like conversion to integer, e.g., are 
needed sometimes, and for those, the situation would be the other 
way around

Oh, ok, so R3 is still mainly being built 32-bit.

Ladislav, no example that shows an advantage springs to mind.

Could you also measure conversion to int for 96-bit pairs and pairs 
of floats?

Pairs of floats look more advantageous to me now.

I agree on the pairs of floats... much better programatically, especially 
since the pairs will be used for things other than simple "pixel" 
coordinates.

it would also be VERY nice to be able to do tripplets or quads.

hmm, actually, triplets of floats may be possible

(96 bits)

one thing I wonder is that when 64 bit builds do get released, are 
we sacrificing the future by tuning the present, using only floats 
now?

We can upgrade to doubles in the future, in the 64bit builds - AGG 
uses them already. Though I don't know the effects that would have 
on rounding and such.

exactly, I wouldn't want a 64 bit build to perform different maths 
on values.  it should just be faster for bigger numbers.


if we go with floats, I feel that we'll be forced to keep them even 
in 64 bit builds.


also, generally, all graphics libs and most math related libs now 
use doubles.  so if we need to convert the floats from rebol everytime 
we use the value within an extension its going to incur some speed 
hits no?

An extension like AGG, which also uses doubles. But we can't fit 
two doubles in a value slot on a 32bit build, sorry.

And if we don't fit a pari into a value slot, it changes its whole 
behavior.

yeah, I see the problem.

they could be stored like vectors internally, but would that make 
them MUCH slower?

Yes, due to at least one added pointer indirection, and added code 
to prevent aliasing (in the pointer sense, not the graphics sense). 
And they could be modifiable, unless we are careful, and that brings 
in another whole host of issues.

well, I guess they could just be stored as a two double struct, but 
then we still get the added indirection everytime they are used.

Development roadmap. There's also Carl's blog about it. I just wonder, 
if it differs from the priority page that much?

http://www.rebol.com/roadmap.html
http://www.rebol.com/priorities.html