World: r3wp

not yet ...

yeah, it's not a priority, but i moved the shortcut to my desktop

so... :)

some ideas from hostilefork - http://hostilefork.com/shared/rebol/rebol_rebooted_3d.png

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

Wher does he find the time?

maybe its the return of REBOL as a team instead of a one man show? 
  

like its used to be in the golden days of rebol 1.x   

ahh  Bo, was such a cool guy at support   :-D

Maxim, did you notice the link Henrik posted? The days of the one 
man show are over :)

Sorry, you were commenting on the link :)
Yes, it's the return of the team.

Protect with Path targets - http://www.rebol.net/r3blogs/0292.html

Some understandings.
What Rebol is doing when a serie is growing. ?
We know Rebol expands them, but following what scheme ?

I made some tests and saw really strange things.


Starting with an empty string and adding 32 * 1024 chars, I listed 
when the string is expanded.
>>8 16 48 112 240 512 2048 8192 32768


Meaning, when adding the eigth char, the string is expanded to fit 
15 chars.
It makes sense, because the size of a cell in memory is 16 bytes.

So, in the first cell, only 7 chars can be stored (remember, in R3 
a char takes 2 bytes)
Why 7 chars and not 8 ?
Because a string is terminated with the (null) char.


Another things we can see is that more a serie is large, more the 
reserved cells are numerous when an expansion occurs. 

It's a little frightening because we don't control very well the 
expansion in memory.

Now say, we're starting with a string of 8191 length.
>> 8192 16384 ... 

By, just adding one more char in it, my tests show it will double 
the whole size of the string in memory.
Is that not too much ?
Don't know...

hum, i think i'm wrong somewhere, need more tests....

I feel, it's a common thing to double sizes of series, when they 
grow. Lua does it too.

Steeve, it is not true that a char takes 2 bytes. That depends on 
the content of the string.

it is common practice to grow exponentially like REBOL does. it greatly 
limits the nuber of allocations and copies that need to be done.

Of course, there is a limit, after which the series is grown linearly. 
I don't remember what the limit is.

At least something is usefull to know.

Never initialize the length of an empty serie with a power of 2, 
because twice this length could be really allocated (really annoying 
for large series).
Instead, reduce the length of 1.

ie.
make string! 8 * 1024 (actually, allocates 16 KB, not 8KB)

Instead i will do:
make string! 8 * 1024 - 1 (allocates 8KB, not more)

Seems that stats/show give hints about the scheme used for expansions.
8B 16B 32B 48B 64B 80B 96B ...
But sometimes, some pools are skipped.

Pool[ 0]    8B   792/ 1024: 256 (77%)  4 segs,    8224 total
Pool[ 1]   16B   428/  512: 256 (83%)  2 segs,    8208 total
Pool[ 2]   32B  1663/ 2048: 512 (81%)  4 segs,   65568 total
Pool[ 3]   48B  2656/ 3072:1024 (86%)  3 segs,  147480 total
Pool[ 4]   64B  2226/ 2560: 512 (86%)  5 segs,  163880 total
Pool[ 5]   80B   962/ 1024: 256 (93%)  4 segs,   81952 total
Pool[ 6]   96B   467/  512: 128 (91%)  4 segs,   49184 total
Pool[ 7]  112B   329/  384: 128 (85%)  3 segs,   43032 total
Pool[ 8]  128B   250/  256:  64 (97%)  4 segs,   32800 total
Pool[ 9]  144B   203/  256:  64 (79%)  4 segs,   36896 total
Pool[10]  160B   163/  192:  64 (84%)  3 segs,   30744 total
Pool[11]  176B   109/  128:  32 (85%)  4 segs,   22560 total
Pool[12]  192B    83/   96:  32 (86%)  3 segs,   18456 total
Pool[13]  208B    78/   96:  32 (81%)  3 segs,   19992 total
Pool[14]  224B    85/   96:  32 (88%)  3 segs,   21528 total
Pool[15]  240B    58/   64:  32 (90%)  2 segs,   15376 total
Pool[16]  256B    37/   64:  64 (57%)  1 segs,   16392 total
Pool[17]  320B   132/  160:  32 (82%)  5 segs,   51240 total
Pool[18]  384B    68/   80:  16 (85%)  5 segs,   30760 total
Pool[19]  448B    31/   32:  16 (96%)  2 segs,   14352 total
Pool[20]  512B    23/   24:   8 (95%)  3 segs,   12312 total
Pool[21] 1024B    62/   64:  16 (96%)  4 segs,   65568 total
Pool[22] 2048B    11/   16:   8 (68%)  2 segs,   32784 total
Pool[23] 3072B     2/    8:   4 (25%)  2 segs,   24592 total
Pool[24] 4096B     0/    0:   4 ( 0%)  0 segs,       0 total
Pool[25]   20B 10934/12288:4096 (88%)  3 segs,  245784 total
Pool[26]   64B     1/  128: 128 ( 0%)  1 segs,    8200 total

Hmm, according to Carl's comment in following blog comment section, 
it seems we are not going to get SSL in an easy way, unless someone 
from community does it :-( .... that is bad, as it might never come 
.... http://www.rebol.net/cgi-bin/r3blog.r?view=0290#comments

But maybe some networkin guru will appear here, and will pick-up, 
where Holger left :-)

Followup on R3 marketing - http://reboltutorial.com/blog/marketing-sits-above-strategy/

It will be a shame if Rebol3 doesn't support SSL. I think Rebol's 
buitlt-in network features such as the HTTP:// and Mail:// schemes 
used to be a big attraction. I think that not supporting them properly 
in R3, being able to read and write Gmail for example, is like shooting 
yourself in the foot from a marketing perspective.

Agreed, not being able to access GMail out of the box is a real negative...

Yes, that would be bad. Fortunately the relevant will be in the open 
source portion of R3, so it shouldn't be too difficult for the community 
to add. R3 is a community project, remember.

The Putty SSL code is supposed to be good and tiny, so we cold adapt 
that.

I would still expect such fundamental feature to be delivered by 
RT.

Community project, partially open source, and what you are talking 
about is in the open source portion. Volunteers? Contributions?

Do you think Python magically got SSL support? Nope, someone contributed 
it.

Being an open source part, implemented by a third party, doesn't 
mean it's not "delivered by RT" as seen from the user's perspective.

I think people are still thinking of R3 based on the situation with 
R2. With R2 if something wasn't "delivered by RT", you couldn't do 
it at all in some (lower-level) cases. This is simply not true with 
R3. R3 is not a black box, and SSL in particular would be easy to 
retrofit even if the base distribution doesn't include it. Plus, 
the pace of development of R3 is pretty fast, and any release that 
doesn't have the feature you want could be followed pretty quickly 
with a release that includes it. The only limitation is time, effort, 
and money (to buy the other two). If people don't contribute, it 
doesn't get done, period. If you want the feature, add it yourself 
or pay someone to write it. Adding it yourself will be easy in this 
case - we'll see about how easy the other method will be.

implemented by a third party

 - this is just wrong. In a community project, anyone in the community 
 is a first party. The only third-parties are the ones who don't contribute.

I'm a little surprised to hear this from you two, Pekr and Henrik, 
since both of you *do* contribute quite a lot. Good work, guys :)

by third party, I simply meant "not at Carl's house" :-)

Well, that's all right then :)

WIth R3, I suppose we can include as little or as much as we want 
and still get an R3, that is a whole product as seen by an end-user.

Brian: I judge situation upon recent experience! Networking protocols 
are NOT delivered by anyone for something like 3 years. So "it can 
be" means nothing for me, especially for the low-level C code of 
certain quality. How many C coders do we have here? How many of them 
are able to write the code, which would be accepted by Carl to be 
included in official distro?

As for me, current situation means just one thing. As a customer/developer, 
looking at feature sheet for R3, searching for the SSL and HTTPS, 
all I can see is big NO.

the feature is so fundamental, like Unicode is. That is why it should 
be delivered by default, with no excuses. There is no web without 
https nowadays ...

That's funny, I see the same thing when I look for the "not an alpha" 
feature :(

If we did not get single networking protocol in 3 years, no single 
fix to http protocol (and we are talking mezzanine level here), WHEN 
do you expect, that feature like SSL/TLS, https could appear for 
R3? That is my only worry here. I am not agains the delivery by some 
"third party", I am just worried judging by recent experience ...

Not looking recently enough. However, your approach is counterproductive 
here. Asking for "RT" to provide this feature is not appropriate 
for a community project. What you should be asking for is contributions. 
RT's time is finite, and we have to triage features based on their 
feasibility, not just how "important" they are. The increasing proportion 
of R3 that is or will be open source is a testament to that. Every 
part of R3 that is open source is *our* responsibility, not just 
RT's.

People can say that a feature is important, but in a community project, 
in the community-created portion of that project, the way you express 
the importance of a feature is with time, effort, or the money to 
buy time and effort. As you have done with HTTP. If the community 
thinks that SSL in an important feature to have, then get to work. 
Complaining only has limited usefulness.

Is there a bounty on native SSL ?

not yet. We need bounties imo ...

I should note... HTTP stalled because I never got answers by Carl... 
about how to implement timeouts (has support for timeouts been added 
to ports in the meantime?), how to handle errors (i think i have 
a decent implementation, so maybe this is ok), what the semantic 
of QUERY should be, and so on. there are a ton of little details 
about port schemes that have not been DESIGNED yet...

(same thing that happened with R/S... priorities switched)

hmm, interesting ...

I thought that networking device is finished ...

More importantly are there people who can do the work if bounties 
are set?

Bounties may not be a bad idea, but you have to get the right people 
to do the work.