World: r3wp

Notepad can apparently handle both UTF-8 and UTF-16 http://en.wikipedia.org/wiki/Notepad_(Windows)

it tries to detect UTF based on text content... broken up until vista.
http://en.wikipedia.org/wiki/Notepad_%28Windows%29

Ok, so... no one reads the wiki.  That's ok... we're all developers. 
We don't read things other than code.

So, here's a summary of R3 and Unicode:

http://www.rebol.net/r3blogs/0286.html

Max: maybe you should start using a real operating system. But, that 
aside, if you have any software that does not handle utf-8, simply 
trash it. guys, really, this is crazy, we are in 2009, let's put 
an end to this codepage crap!

sqlab: what you say would make some sense if converting files was 
in any way difficult. (apart from the fact that you should have stopped 
using latin1 almost 10 years ago...). I've been using utf-8 with 
R2 for years...

sqlab: rigth, let's make string handling MORE COMPLEX. we definitely 
need that. let's copy MySQL, shall we?

Max: a system wide default means that my script will NOT run in the 
same way on your system. that is the definition of bad language design.

Petr: notepad, as most windows stuff, uses utf-16. much easier to 
detect though, and R3 could do that (actually, didn't Carl just add 
that recently?) most "real" editors allow you to use whatever encoding 
you want, and definitely support utf-8.

Aha, I just realised that I have to use Save-as, and choose UTF-8 
or Unicode, instead of default ANSI preset of notepad

gab, having a system-wide option will allow people to use the same 
code for different encoded source data.  it doesn't break my code 
or yours.  its a setup not a definition.

i love that documentation on bitset http://rebol.com/r3/docs/datatypes/bitset.html
 -> I give it A+++ a you must read it documentation !!

CArl on french forum they are wating to now if you plan to bring 
rebol world to the modile phone 3 generation area ? (android windowsphone 
or iphone). Could be a good way to show that not only adobe flash 
can provide things  in that area i think. But they a special "set" 
of feature should be build in rebol to feet the particular need of 
those plateform. What do you thin about it Carl ?

this is what the host code is for.

carl T___T i read your documentation and post and all when i get 
some  free time to do it..

maxim too many groups here i'm dizzy just looking at the list ...

iphone will not allow any other dev tools on the iphone, unfortunately.

what people do is create an abstraction for their tools and spit 
out iphone sdk compileable code.

hum ... who said to develop an application that runs on a iphone 
you had to run it on an iphone ^^

action code 3 (flash) is now also licensed.

maxim if we as steeve jobs gently he will accept  ^^

ok so android seems the best choice it's wide open ...

the R3 host is what ultimately loads the rebol.dll and provides any 
platform-specific resources to it.

yep.

but creating abstractions in REBOL is quite easy (compared to other 
languages), as Oldes has shown with his impressive flash dialect

but then the ask is what kind of rebol feet the need of those fone 
(personnally VID would be an awsome way to do animated high sight 
GUI application on fones )

part of SCREAM's mission is to allow compilation targets for all 
of its tools.  this won't happen soon, but its one of the reasons 
for its existence in the first place.


Oldes' Flash dialect is very high on my list of Scream subprojects.

ok well that's an idea that poped out on the french forum i wanted 
to share to carl.

its easy to compile VID blocks into other languages.  the only real 
tricky part is the actions, which have to be compiled too... so the 
best approach is to use a dialect within your event code, and stick 
to it.  this dialect can then be built so it can compile into languages.

a lot of rebol can be converted line for line in just about any language... 
you just need to keep the compilable language basic and you should 
be fine.

its a recurring request since REBOL as firat released.  with R3 we 
will now be able to compile rebol on ANY platform, which allows us.

as firat.... was first

its possible even symbian can be compiled to  :-)

i'm lost ...  anyway  people will understand you probably better 
than me.

Max: "action code 3 (flash) is now also licensed." I don't bellieve 
this is the case. Adobe has gone to great lengths to develop a Flash 
SDK which builds "regular" iPhone apps.

yes, that is it.  its a licensed development tool.

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.