World: r3wp

jocko - the same happened to me here under Windows. The problem is, 
that I used plain Notepad, which by default stores in ANSI compatible 
charset. Then I realised, that on a Save-as dialog, there is a button, 
where I can change ANSI to UTF-8 unicode. Then my strings loaded 
correctly. So - you have to be sure that your editor by default saves 
in UTF-8.

http://curecode.org/rebol3/ticket.rsp?id=1309&cursor=5<- see this 
report

Yes, that was the problem ... and I already had it. But it will really 
be a trap for many non english users, from many countries. Another 
point to consider is that we may have difficulties reading normal 
(non-UTF-8) text files coming from other environments. In R2, this 
constraint did not exist.

I can see it as a problem too. The trouble is, that I can't see any 
practical solution to it.

actually, it is a problem in R2.  if you store your code, and I open 
it with a different codepage version of windows... some letters will 
be skewed. 


In an application I wrote, I couldn't write out proper strings for 
the netherlands, as an example.


unicode is slowly becoming the standard for text... especially utf-8. 
 but yes, users have to be educated.  


within your apps, though, you can handle the encoding as you want... 
only the rebol sources have to be UTF-8 .  as R3 matures, more encodings 
will be most probably be included in string codecs to support 8 bit 
Extended ascii from different areas of the world.


and even high-profile applications like Apple's iweb have issues 
with text encoding... so this is a problem for the whole industry 
& users to adapt to.

its a relatively new preoccupation, because the internet forces people 
from all around the world to exchange data in real time...

One interesting thing about R3 scripts is that they are UTF-8 *binary*, 
not converted strings. A header setting would just require R3 to 
convert the script to string! and then back to UTF-8 binary before 
reading the file. This is why we recommend that people DO [1 + 1] 
instead of DO "1 + 1", because that string needs to be converted 
to binary before it can be parsed.

Even if we had a text encoding header for R3, it would be a *bad* 
idea to ever use encodings other than UTF-8. So don't.

I just tried to see, what is in my bitset. I used to-string, and 
received following result:

>> bits: make bitset! "abc"
>> to-string bits
== "make bitset! 64#{AAAAAAAAAAAAAAAAcA==}"


This is more lika a mold, right? What is bitset internally, a binary? 
I probably expected some conversion, but curious if the output is 
what you would expect?

It can be easier to read if you have:
   system/options/binary-base: 16

 bits: make bitset! "abc"
== make bitset! #{00000000000000000000000070}

Why 'remove requires /part refinement? I have never seen function 
to be pushed to use refinement by default:

otoh bitset probably does not have seriea-like "current position", 
so it might be questionable, what single remove bitset should do 
....

I never programmed in assembler, so I am not quite strong with all 
those binary things. Could someone explain to me, how are bitsets 
done in low level? E.g.:

>> bits: make bitset! 1
== make bitset! #{00}

>> find bits 1
== none

>> append bits 1
== make bitset! #{40}

>> find bits 1
== true


What does the binary #{40} = integer 64 mean? How is this value constructed?

You created a bitset of just one byte. When you append 1 to the bitset, 
you set the bit representing position 1 in the bitset, so you get 
#{40}, which is equal to binary: 2#{01000000}
Position 0 in the bitset is the first bit. Example:

>> bits: append make bitset! 1 0
== make bitset! #{80}

which is equal to binary: 2#{10000000}

Note that bitsets have changed in R3!

Precision delta time measurements - http://www.rebol.net/r3blogs/0289.html

Have Bitset! some limit?  May it be used as bitmap index for some 
larger set?

Bitset Virtual Length: http://rebol.com/r3/docs/datatypes/bitset.html#section-28

I read it, as if bitsets can be as long as you need, but try it out.


More information about bitsets, including details of changes from 
R2 to R3:
http://www.rebol.net/wiki/Bitsets

>> make bitset! to-integer power 2 24
** Script error: invalid argument: 16777216
** Where: make
** Near: make bitset! to-integer power 2 24

>> make bitset! to-integer (power 2 24) - 1
== make bitset! #{
00000000000000000000000...

>>

do you really need a 16MB bitset !! ?

no, but that seems to be the limit

Thanks for analysis Kcollins! Maxim the question was if Bitmap may 
be used as searchable bitmap index into dataset (key-value, index-value 
in this case) all this in searching of holly grail what is named 
RIF in Rebol :). The answer is yes if you would use max 16 M of indexes. 
The merit is using somehow compressed format. Oher info in Wikipedia 
bitmap indexes, or Fastbit database (database for very large datasets 
from particle colliders).

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?