World: r3wp

its not flash in the browser.

I don't think there is a standalone Flash player for the iPhone either.

nope... Apple doesn't want you to use flash in the browser... it 
kills their app market  :-(   
for example:

  bejeweled, one of the most successfull flash games ever, is available 
  as an app... they wouldn't want you to just play in on the net.. 


This is my only real Anger generating aspect of the iphone.   but 
this is true of just about every digital device out there... the 
provider wants to make money out of their appliances, so they control 
as much of what you can do on it, so they get a few cents every time.

Max, maybe i was not clear. If your rebol scripts are latin1 by default, 
while my rebol scripts are utf-8 by default, when i send you a rebol 
script IT WILL NOT WORK in the same way in your machine. the *script*'s 
encoding *must* be a standard everyone agrees on. then, the script 
can do whatever it wants with the data, it's your fault if you make 
it so data cannot be exchanged easily among systems.

on this we agree, I am talking about read/write operations *from* 
the script.

although having an encoding parameter in the header would allow us 
to tell the interpreter in what format the text is without breaking 
anything.

I may miss something, but still I have problems with accentuated 
letters: 
when I type print "terminé" in the console, the result is ok.

When I put this instruction in a file, I get a syntax error: invalid 
"string" -- {"terminé"}

are you putting it in a file from a text editor?

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