World: r3wp

neat.

the R3 bitset object is really nice.

Would it just be clutter to add a synonym for 'not  ... eg. 'no ?

'NO is already used for 'FALSE   as in yes/no.

ok.

Host builds plan:

http://www.rebol.net/wiki/Host-Builds

so Carl, seems it was a bit more work than expected to get that host 
code out of your disk  ;-)
(reffering to this http://www.rebol.net/wiki/Host-Builds)

would someone please run his in r3 and let me know the result

mod (power 2 63 - 3) 10

>> mod (power 2 63 - 3) 10
== -4.0

(in A94)

-4.0 in OSX A94.

mine was on XP

-4.0
.....A94, Windows Vista

hmmm ...should not underflow and underflow should be reported.

it is the same back in r2 on solais & windows

2^48 is as high as I can go on a 32 bit windows intel  before  abundant 
underflows    

and  only  2^ 49 on a  64 bit solaris sparc . Does R3 use the entire 
width of the available processor?

I realize these are decimal aproximations (at least on the 32 bit 
machine) 
but rebols mod function returns decimals
for example mod (PI + 50.0) 10 .  

why would these aproximated large values not come back as their nearest 
decimal aproximations if t

.. if that is the problem

is this a common IEEE floating point issue?

I could see that  being the case on a 32 bit machine but not one 
with an exact representation

you should create a curecode ticket and discuss this with Carl.  
AFAIK he is savy about this stuff, so you could help him improve 
this if at all possible  :-)

he takes curecode VERY seriously.  and it will act as a databank 
of info however this turns out, for future reference.

standard significand for iEEE single precision is 24 bits  so yes 
it is likely related to double precision behavior

I haven't got time to dig in deeper right now, but remember, there 
are many MOD functions:
MOD, REMAINDER, MODULO, //
Other?

origanally there was just mod  I may have assumed the rest were alias'

modulo is a wrapper  around mod to make the result pretty in some 
cases

by re-reading some of Max ideas about draw, View, etc., I now think 
that deeper change is needed. Gobs sound so old-school by his propositions 
....

anyone got a rebol 3 icon for the desktop?

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/