AltME groups: search

It reads it as a stream of bytes. As UTF-8 doesn't use null bytes 
in its encoding (except for codepoint 0), it can be fully loaded 
as string! or binary! in R2 (but you'll see garbage for non-ASCII 
characters).

I have just succesfully run demo.exe and got nice Ascii Red, created 
from Red letters :-)

We're just lacking some ASCII-art beer to make it more fun!

For those of us still dealing mostly in pure ASCII will there be 
a 1-byte per character string alternative?

Ashley: Red string! use 1-byte per character by default, so as long 
as you stick to ASCII, it takes the same storage space as C strings. 
As soon as you insert a non ASCII character, the string will automatically 
upgrade to the appropriate format. It's transparent for the Red user. 
Moreover, you'll be able to force string encodings back down to 2-bytes 
or 1-byte when possible.

0-127 ASCII, or UCS-1 (aka Latin1)?

Here is a new proposition for solving the "PICK issue":

1) Forbid <= 0 indexes.


2) Add a PICK-BACK action that will take only positive integers, 
PICK-BACK series 1 would return the first element on the left of 
current series position.


3) As PICK-BACK is not a very nice and concise name (I like actions 
to be named with a single word), an op! alternative would be provided: 
<- (opening angle-bracket followed by a dash aka "ASCII arrow")

Examples:
    >> series: next [A B C]
    >> pick-back series 1
    == A
    >> series <- 1
    == A
    >> series <- 2
    == none			;-- to be consistent with out-of-bound PICK


For path notations options in such scenario, I'm open to propositions. 
So what are the pros/cons of such solution?

It's interesting that we have all the symbols in unicode but still 
are lack of symbols because of we use only ASCII characters.

Being written in REBOL/View, ALTME encodes characters in the Windows 
codepage under Windows, MacRoman under OS X and UTF-8 (I think, it 
may be ISO-8859-1) under Linux. So if you use any character  other 
than standard ASCII characters, it will appear differently on differnet 
systems.

I've relabeled my console versions as supporting only ASCII

string/load can only load UTF-8, so only ASCII and UTF-8 files can 
be read, not Latin-1

Kaj: I think you're right about the console, it handles correcty 
only ASCII input.

For example, there's an internal single byte encoding that's marked 
"Latin1", but I now know there is no way to get Latin-1 data in or 
out, so I wonder if this encoding will ever be used for more than 
7-bit ASCII

So for most purposes, Red is currently ASCII only

It was announced last year that Unicode support was implemented in 
a week. What I found first is that Unicode support is useless, and 
now I've found that only ASCII is really supported

3) "So for most purposes, Red is currently ASCII only" Obviously 
not, it is for your specific purposes. Again, look at the Unicode 
tests.

4) "It was announced last year that Unicode support was implemented 
in a week. What I found first is that Unicode support is useless, 
and now I've found that only ASCII is really supported." Unicode 
support has been implemented exactly as stated in (will get back 
to that point later):
http://www.red-lang.org/2012/09/plan-for-unicode-support.html

So, currently, only 7-bit ASCII is safe to input in the console. 
This limitation has nothing to do with Red implementation or the 
interpreter, it's a console input issue, so generalizing it to whole 
Red is inaccurate and unfair.

The console script for Red supports only ASCII input.

when I type #
^(3B1)"     in the Red console, I get some errors too ..."

The console script for Red supports only ASCII input. :-)

OK but in a sense what I typed is in full ASCII, isn't ?

Yes, you input ASCII characters, but the runtime lexer needs to decode 
your Unicode codepoint in hex format, and the lexer has no support 
for that.

@Janko: rendering of 3d scene is similar to code in opengl.r found 
in rebol.org, and to control the printer I simpy send ascii gcode 
throu serial port.

Petr, R3 can't decode any 8bit encodings with its built-in code, 
just ASCII (which is 7bit) and UTF-8. However, its binary handling 
is better so it should be easy to write your own converters. For 
R2, I would suggest looking at Gabriele's PowerMezz package; it has 
some great text converters. Of course you lose out on R3's PARSE 
if you use R2.

Arnold: I believe that Rebol/View uses Windows Codepages under Windows, 
MacRoman on OS X and ISO-8859-1 on  Linux. Sadly this means it only 
really supports true ASCII characterrs cross platform unless you 
manage encoding your self.

Like the nchar and nvarchar types. OpenDBX converts those types to 
ASCII, then R3 would need to convert them back to Unicode.

This means that the difference between an ASCII character and a higher 
Unicode codepoint is significant. ASCII characters can be detected 
with a single byte of lookahead. Higher codepoints require multiple 
bytes of lookahead. That means that for most parsing models any rules 
that require multi-byte stop sequences are quite a bit more complicated, 
slower, and for some parsing models impossible. So I'm hoping we 
can fix this.

Poul Henning Kamp wrote an article about that some time back. The 
need to move away from the ASCII character set.

(I know that's ascii...was just downloading the chart...but guess 
I should write a script...)

Is there an existing Rebol function that will escape ascii from hex 
to char?  ie from %7C to | ?

There is nothing standard when it comes to ascii.. bin version, hex 
version, oct version, binary version, windows 2k version, windows 
XP version, IBM PC version, and many others, no doubt.  I have more 
lines of code dealing with ascii, then all the rest combined :(

I have a block of value pairs, and can do a foreach [ascii chara][replace/all 
..] but that seems rather crude

It's not a perfect solution, I still need a block of values to handle 
odd browser escaping.. for example, when you add a © to  a url, Mozilla 
escapes it with "%C2%A9"  .. adding that extra ascii character for 
some reason.

And, while you are critiquing the Library, check out the Articles 
section.
http://www.rebol.org/cgi-bin/cgiwrap/rebol/art-index.r
It's often overlooked, and frankly quite bare of content.

But it is a central place to publish articles. And it accepts them 
in most common REBOL mark-up languages (MakeDoc variants, eText. 
ASCII etc) so no additional learning curve needed.

1.  link tasks with the calendar

2.  "clear all" a simple button which removes red color of all groups. 
usefull when skipping a few days...

3.  HIDE groups (and users).  just add simple check mark to  window 
which lists all available groups and any you check-off are removed 
from the list you look at (yet you still receive their posts, if 
you want to look at them another time).

4.  per group moderators for private AND public groups (delete posts, 
insert posts, manage users, etc.   A part from "opting out", users 
are not able to change the setup (like deleting the group), group 
name, list of users in private group, etc ).  

5.  single file export of all selected task lists and their tasks 
(ascii or html)

6.  SORT task list... we cannot sort the task lists... only the tasks 
they contain... a real bitch when working with others...

7.  Also allows read-only mode for private groups for people not 
in private users list.   Great to manage announcements for private 
tools.
8.  'workdays only - weekend only' option for calendar

9.  properly support hours in calendar tasks, so that hours are always 
available, right now, the software often ignores any data we put 
in the hours field..

Of course there are some limitations:
 1. if a post does not have a
    rebol []

    to identify the start of the code, we may fail in executing text
 2. ditto if there is text after the script
 3. assumed to be ascii file (not UTF-8 etc) right now
 4. post may take 12 to 18 hours to appear on REBOL.org archive

to-binary treats its input as a string -- not a number -- and converts 
each byte to it's hex ASCII respresentation  -- not ar all an intuitive 
meaning for to-binary.
Even worse, perhaps is
>> enbase/base "23" 2
== "0011001000110011"

which appears to have converted to binary. But, again, it's the ASCII 
for "2" and "3" not the binary for 23.

I think rebol doesn't load #"^M" and #"^J" because they are CR (ascii 
13) and LF (ascii 10).  In rebol, these are molded to #"^M" and #"^/".....

I wonder what font AGG use ? None of the ASCII 128+ char are displayed, 
 except 251 that show "OBJ" in a box !!

test-address-import: func [

 {Returns true if pass, false if discrepency and none if failed with 
 error.}
	limit [integer!] "Number of TO address to generate."
	/quiet "Does not display error."
	/local to-list eml sep msg obj
] [
	to-list: copy {} sep: ""
	repeat i limit [
		eml: to-email join "test-" [i "@test.com"]
		repend to-list [sep {"'} eml {'" <} eml {>}]
		if empty? sep [sep: {,^/	}]
	]

	msg: replace copy {Date: Thu, 12 Feb 2004 11:41:49 +0100
From: test <[test-:-test-:-com]>
MIME-Version: 1.0
To: TO_LIST
Subject: [REBOL] test message - edited copy of real message
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: [rebol-bounce-:-rebol-:-com]
Reply-to: [testing-:-testing-:-com]
Status:   


Test message.
} {TO_LIST} to-list

	either error? set/any 'result try [
		obj: import-email msg
		limit = length? obj/to
	][if not quiet [print mold disarm result] none][result]

]

parsing binary is a bit different than parsing ASCII...and I have 
done a bit for mp4...but I think your point of making it simple is 
a good thing.

Hello;
  How do you convert a letter (ASCII) to it's hex equivalent?

  I've tried to-hex but it wants an integer!?  You would think it would 
  be easier than:


print to-integer to-string to-hex to-integer to-decimal to-char "a"

which works but there has got to be an easier way.

seems like an empty block should only take 2 bytes...but then that 
is just the ASCII representation...binaries are bigger than their 
source code...I would expect some list links pointing, some datatype 
info...dunno.  Maybe try a small program like REBOL[] probe empty: 
[] and inspect the RAM of it.

hex-editor or ascii or decoding this unix-rights-numbers or such.

- Read a part of the file. If every byte is ASCII (or 8-bit), it's 
text, else it's binary. This is only a good guess, of course!

- Many types of files have some header information right at the start 
of the file. Make a list of those headers. (I think, this is the 
way, many datatypes works in Amiga OS.)

There's already an optional "see also" header, eg:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=ascii-chart.r

And there's no reason why that can't generate a footnote in the same 
way that the "replaced-by" header does, eg:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=calc-engine.r


All we need now is a volunteer to go through 600+ scripts and group 
them together.

Use the download URL, eg:

do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=ascii-chart.r

There is big problem with rebol.org library if you are using different 
than ascii chars. I've just submited a script which contains latin2 
chars and it's not uploaded correctly as there were converted to 
utf8 (so the script will not be working correctly as the chars are 
used in parse.

I just added ascii-math.r to the library. It looks fine in the  view 
, but the downloaded file contains gibberish characters before each 
non-standard ascii char. This problem may be related to the problem 
that Oldes was having on 14-Mar-08.

Thanks for the script -- and for the problem report.

Looks to me like the script, as uploaded, contained non-UTF8 characters, 
and they are being treated as multi-byte characters.

REBOL, and REBOL.org can really only handle ASCII....Unicode and 
such like is for R3.


If you email (preferably in a ZIP to prevent email software from 
chewing up the code) the original script, I'll take a look.

If most of it is currently ascii, would it not just be a case of 
adding a few filters?

We've had a similar problem before (I've just checked the source 
code, and it's prompted my memory).


To solve it, we analyse the script for various extended ascii chars 
and then perform some messing around on HTTP content-type headers.


It's messy, and it's worked up til now......But obviously, we need 
some more analysing and messing around for this script.

Results of a tiny bit of debugging on the ascii chars problem:
-- problem seems to be at the input stage:

     -- if you have exended ascii characters (top bit set, like the 1/4 
     used in the script) what we get from the webserver is bad (extra, 
     unexpected extended ascii chars)

    -- only download is (visibly) affected, although the extra extended 
    ascii chars are present in the text streams

     -- though there is some REBOL mezz code (decode-cgi) that may be 
     doing something I do not understand

    -- I can replicate the problem with both Apache and Xitami which 
    suggests the problem may be in REBOL rather than a given server.


-- the quick fix would be to add accept-charset="ISO-8859-1" to the 
<form ....> or <textarea ....>

    -- but that stops all extended ascii, including the ones we want. 
    So we won't do that.

-- the slower fix has yet to emerge from the available options.

does not support UTF-8

 - what do you mean by "support"? if you mean having native encoders/decoders, 
 no, it does not. but, utf-8 is just 8 bit characters, and it is backwards 
 compatible with ascii. if you can handle ascii, and leave alone any 
 char > 127, you already support utf-8.

Sadly, REBOL running as CGI under the two servers I've tested (Apache 
and Xitami) does not seem to support the whole range of ASCII -- 
ASCII chars with the 8th bit set seem to cause problems.

I don't know where the problem really is, but right now, we do not 
even support 8-bit ASCII, let alone anything more modern :-)

Sunanda, can you publish some files with the 8-bit ascii and note 
what the problems are ?

Anton, REBOL.org uses 2.5.6.4.1

The obvious bad file is the one Scott added recently:
http://www.rebol.org/view-script.r?script=ascii-math.r

If you view it with that URL, all looks good.

If you click the [Download script] link you'll see many spurious 
high-ascii chars in the source.

Those high ascii _are_ actually in the source. But where they came 
from is a mystery.

Sunanda, you're right about that ascii-math.r file. When I clicked 
the [Download script] link, the browser (konqueror) downloaded and 
directly opened it with the editor (SciTE). SciTE thought it was 
8-bit ascii, and showed the characters incorrectly. All I had to 
do was change the file encoding from 8-bit to utf-8 and the characters 
appeared correctly. I guess the editor had no way of determining 
the encoding, and incorrectly guessed 8-bit ascii.

Thanks Gabriele -- that's a clear explanation, and has helped me 
work out what is going on.


Anton and Gabriele -- I have tried changing the charset we emit on 
the download to say UTF-8. But that makes little difference. As both 
of you note, once the file has been saved then (without a MAC-type 
resource fork) there is no obvious indication of the encoding. And 
several editors I have tried get it wrong -- thus "revealing" the 
extra ASCII chars.


Not sure what the solution is other than to de-UTF-8 files on download.

Anton -- not yet run a crawl to check for other scripts with high 
ascii chars.

It seems the responsibility lies with the clients to interpret encodings 
properly. As we move to a unicode world, software assuming 8-bit 
encodings are some ASCII encoding should drop off. But until the 
transition is complete, there's not much we can do about client software 
guessing wrong like that, except stating the encoding in the script 
header, in the web page that provides the download link, and by helping 
confused newbies.

If the offending downloaded script is executed in Rebol/Core, the 
extra ASCII chars are also present in the executed code.  The script 
defines ½ to be 0.5. If "help ½" is typed into the console, the result 
is "Found these words:   ½              decimal!  0.5". However, 
if the script is executed in Rebol/View, the result is "½ is a decimal 
of value: 0.5". It seems that View handles it correctly, while Core 
doesn't.

Thanks guys.
Other scripts with the same problem.....there are a couple. 

About 10% of all scripts have at least one extended ASCII char....But 
most of them are acceptable in LATIN-1 code page / charset (eg copyright 
symbol, some accented letters). It's just a very few scripts that 
use 1/4 and similar symbols that cause the problem.


What other editors? Windows NOTEPAD is one example of a common one 
that gets this wrong.

Of the various editors / word processors I have immediately to hand:

-- credit.exe -- [my usual editor] shows incorrect chars, and has 
no option to switch to UTF-8

-- open office writer -- works fine if you take the UTF-8 option 
when asked
-- ms word -- claims file is corrupt
-- word perfect -- makes a complete mess

-- R2/View's built in editor ( editor %/c/path to my local copy//ascii-math.r) 
-- shows incorrect chars

Ok, so there are some editors which don't support unicode, don't 
guess encoding correctly, or can change encoding only with difficulty.

How about this suggestion; if a rebol.org script is known to be UTF-8, 
then an additional link should appear:

[Download as ASCII] download-a-script?script-name=ascii-math.r&encoded-as=8-bit-ascii
which transcodes a UTF-8 file to ASCII.
Just have to get a conversion function in place for this to work.

Thanks everyone.

I think our first step is to add a warning to any download for scripts 
that contain UTF-8 chars.

So, for that I need a function:

     utf-8?: func [data [string!] [ ...]   ; returns true or false [and 
     perhaps "not sure" in ambiguous cases]

I've done the easy part :-)
Can anyone help with the difficult "..." part ?


It is not as simple as just looking for ASCII > 128 .... some high 
ASCII is acceptable as part of, say, ISO 8859-1

Something new in the Library....If you own scripts, you can add images 
to them to make it all a bit more graphic.

Only example to date here:
    http://www.rebol.org/view-script.r?script=ascii-chart.r

Notes about how to add images to yoour scripts here:
    http://www.rebol.org/boiler.r?display=script-images

Thanks to Maxim for the original change request.

Sort sorts only by ascii, the other things you need to compare yourself.

what is MDP-Browser ? MDP-Browser is a software designed to work 
with IOS server  in a wiki like way. MDP-browser is a merge betwin 
MD-Viewer and  MDP-GUI some kind of nutural son of those two programs. 
It's similar to his parents but entends truelly the capabilities 
of both program.  First of all VID rendering have been improved (bullet 
points  are drawn using effect/Draw and not any more ascii chars), 
Viewed text resizing exist

Yeah, it's amazing that good old text format is now starting to break 
down as we head toward different encodings.  System designers like 
to outsmart themselves sometimes.  :)  Not that advancing out of 
an English only ASCII character set is a bad thing, but it may take 
a while to get everything back to quick and easy again.

non-ascii: the only supported encoding so far is latin1 (basically... 
more precisely i think i have it set to the Windows variation, which 
iirc is windows-1252) - that is, the same that View uses on western 
Windows installations.

space/spc
whitespace/wsp
alpha
digit(s)
alpha-num	; should digit be num?
ctl/control
non-US-ASCII/high-ASCII
quoted-string
escaped-char    ; what is the escape though; REBOL ^, C \, etc.?

What other standard sets would we want?

ah, got reply on Chat from Carl towards complementing:


Re #5718: Pekr, that's a good question, and I think the answer must 
be YES. We need to be able to complement bitmaps in a 

nice way". Otherwise, Unicode bitmaps, even if simply used on ASCII 
chars, would take a lot of memory.


This change should be listed on the project sheet, and if not, I'll 
add it there."

>> db: open mysql://root:[gaia-:-127-:-0-:-0-:-1]/information_schema
connecting to: 127.0.0.1
>> insert db "select * from collations"
== none
>> length? copy db
== 124
>> probe copy db
none
== none
>> insert db "select * from collations"
== none
>> probe copy db

[["big5_chinese_ci" "big5" "1" "Yes" "Yes" "1"] ["big5_bin" "big5" 
"84" "" "Yes" "1"] ["dec8_swedish_ci" "

dec8" "3" "Yes" "" "0"] ["dec8_bin" "dec8" "69" "" "" "0"] ["cp850_general_ci" 
"cp850" "4" "Yes" "" "0"] [
cp850_bin

 "cp850" "80" "" "" "0"] ["hp8_english_ci" "hp8" "6" "Yes" "" "0"] 
 ["hp8_bin" "hp8" "72" "" ""
0

] ["koi8r_general_ci" "koi8r" "7" "Yes" "" "0"] ["koi8r_bin" "koi8r" 
"74" "" "" "0"] ["latin1_german1_c

i" "latin1" "5" "" "" "0"] ["latin1_swedish_ci" "latin1" "8" "Yes" 
"Yes" "1"] ["latin1_danish_ci" "latin1"

 "15" "" "" "0"] ["latin1_german2_ci" "latin1" "31" "" "Yes" "2"] 
 ["latin1_bin" "latin1" "47" "" "Yes" "1"

] ["latin1_general_ci" "latin1" "48" "" "" "0"] ["latin1_general_cs" 
"latin1" "49" "" "" "0"] ["latin1_spa

nish_ci" "latin1" "94" "" "" "0"] ["latin2_czech_cs" "latin2" "2" 
"" "Yes" "4"] ["latin2_general_ci" "lati

n2" "9" "Yes" "" "0"] ["latin2_hungarian_ci" "latin2" "21" "" "" 
"0"] ["latin2_croatian_ci" "latin2" "27"


 "" "0"] ["latin2_bin" "latin2" "77" "" "" "0"] ["swe7_swedish_ci" 
 "swe7" "10" "Yes" "" "0"] ["swe7_bin"

 "swe7" "82" "" "" "0"] ["ascii_general_ci" "ascii" "11" "Yes" "" 
 "0"] ["ascii_bin" "ascii" "65" "" "" "0"

] ["ujis_japanese_ci" "ujis" "12" "Yes" "Yes" "1"] ["ujis_bin" "ujis" 
"91" "" "Yes" "1"] ["sjis_japanese_c

i" "sjis" "13" "Yes" "Yes" "1"] ["sjis_bin" "sjis" "88" "" "Yes" 
"1"] ["hebrew_general_ci" "hebrew" "16" "

Yes" "" "0"] ["hebrew_bin" "hebrew" "71" "" "" "0"] ["tis620_thai_ci" 
"tis620" "18" "Yes" "Yes" "4"] ["tis

620_bin" "tis620" "89" "" "Yes" "1"] ["euckr_korean_ci" "euckr" "19" 
"Yes" "Yes" "1"] ["euckr_bin" "euckr"

 "85" "" "Yes" "1"] ["koi8u_general_ci" "koi8u" "22" "Yes" "" "0"] 
 ["koi8u_bin" "koi8u" "75" "" "" "0"] ["

gb2312_chinese_ci" "gb2312" "24" "Yes" "Yes" "1"] ["gb2312_bin" "gb2312" 
"86" "" "Yes" "1"] ["greek_genera

l_ci" "greek" "25" "Yes" "" "0"] ["greek_bin" "greek" "70" "" "" 
"0"] ["cp1250_general_ci" "cp1250" "26" "

Yes" "" "0"] ["cp1250_czech_cs" "cp1250" "34" "" "Yes" "2"] ["cp1250_croatian_ci" 
"cp1250" "44" "" "" "0"]

 ["cp1250_bin" "cp1250" "66" "" "" "0"] ["gbk_chinese_ci" "gbk" "28" 
 "Yes" "Yes" "1"] ["gbk_bin" "gbk" "87
 
 

Yes" "1"] ["latin5_turkish_ci" "latin5" "30" "Yes" "" "0"] ["latin5_bin" 
"latin5" "78" "" "" "0"] ["

armscii8_general_ci" "armscii8" "32" "Yes" "" "0"] ["armscii8_bin" 
"armscii8" "64" "" "" "0"] ["utf8_gener

al_ci" "utf8" "33" "Yes" "Yes" "1"] ["utf8_bin" "utf8" "83" "" "Yes" 
"1"] ["utf8_unicode_ci" "utf8" "192"


 "Yes" "8"] ["utf8_icelandic_ci" "utf8" "193" "" "Yes" "8"] ["utf8_latvian_ci" 
 "utf8" "194" "" "Yes" "8"

] ["utf8_romanian_ci" "utf8" "195" "" "Yes" "8"] ["utf8_slovenian_ci" 
"utf8" "196" "" "Yes" "8"] ["utf8_po

lish_ci" "utf8" "197" "" "Yes" "8"] ["utf8_estonian_ci" "utf8" "198" 
"" "Yes" "8"] ["utf8_spanish_ci" "utf

8" "199" "" "Yes" "8"] ["utf8_swedish_ci" "utf8" "200" "" "Yes" "8"] 
["utf8_turkish_ci" "utf8" "201" "" "Y

es" "8"] ["utf8_czech_ci" "utf8" "202" "" "Yes" "8"] ["utf8_danish_ci" 
"utf8" "203" "" "Yes" "8"] ["utf8_l

ithuanian_ci" "utf8" "204" "" "Yes" "8"] ["utf8_slovak_ci" "utf8" 
"205" "" "Yes" "8"] ["utf8_spanish2_ci"
utf8

 "206" "" "Yes" "8"] ["utf8_roman_ci" "utf8" "207" "" "Yes" "8"] ["utf8_persian_ci" 
 "utf8" "208" ""
Yes

 "8"] ["utf8_esperanto_ci" "utf8" "209" "" "Yes" "8"] ["ucs2_general_ci" 
 "ucs2" "35" "Yes" "Yes" "1"]

 ["ucs2_bin" "ucs2" "90" "" "Yes" "1"] ["ucs2_unicode_ci" "ucs2" "128" 
 "" "Yes" "8"] ["ucs2_icelandic_ci"
ucs2

 "129" "" "Yes" "8"] ["ucs2_latvian_ci" "ucs2" "130" "" "Yes" "8"] 
 ["ucs2_romanian_ci" "ucs2" "131"


 "Yes" "8"] ["ucs2_slovenian_ci" "ucs2" "132" "" "Yes" "8"] ["ucs2_polish_ci" 
 "ucs2" "133" "" "Yes" "8"]

 ["ucs2_estonian_ci" "ucs2" "134" "" "Yes" "8"] ["ucs2_spanish_ci" 
 "ucs2" "135" "" "Yes" "8"] ["ucs2_swedi

sh_ci" "ucs2" "136" "" "Yes" "8"] ["ucs2_turkish_ci" "ucs2" "137" 
"" "Yes" "8"] ["ucs2_czech_ci" "ucs2" "1

38" "" "Yes" "8"] ["ucs2_danish_ci" "ucs2" "139" "" "Yes" "8"] ["ucs2_lithuanian_ci" 
"ucs2" "140" "" "Yes"

 "8"] ["ucs2_slovak_ci" "ucs2" "141" "" "Yes" "8"] ["ucs2_spanish2_ci" 
 "ucs2" "142" "" "Yes" "8"] ["ucs2_r

oman_ci" "ucs2" "143" "" "Yes" "8"] ["ucs2_persian_ci" "ucs2" "144" 
"" "Yes" "8"] ["ucs2_esperanto_ci" "uc

s2" "145" "" "Yes" "8"] ["cp866_general_ci" "cp866" "36" "Yes" "" 
"0"] ["cp866_bin" "cp866" "68" "" "" "0"

] ["keybcs2_general_ci" "keybcs2" "37" "Yes" "" "0"] ["keybcs2_bin" 
"keybcs2" "73" "" "" "0"] ["macce_gene

ral_ci" "macce" "38" "Yes" "" "0"] ["macce_bin" "macce" "43" "" "" 
"0"] ["macroman_general_ci" "macroman"
39

 "Yes" "" "0"] ["macroman_bin" "macroman" "53" "" "" "0"] ["cp852_general_ci" 
 "cp852" "40" "Yes" "" "0
] [

cp852_bin" "cp852" "81" "" "" "0"] ["latin7_estonian_cs" "latin7" 
"20" "" "" "0"] ["latin7_general_ci
 

latin7" "41" "Yes" "" "0"] ["latin7_general_cs" "latin7" "42" "" 
"" "0"] ["latin7_bin" "latin7" "79" ""

 "" "0"] ["cp1251_bulgarian_ci" "cp1251" "14" "" "" "0"] ["cp1251_ukrainian_ci" 
 "cp1251" "23" "" "" "0"] [
cp1251_bin

 "cp1251" "50" "" "" "0"] ["cp1251_general_ci" "cp1251" "51" "Yes" 
 "" "0"] ["cp1251_general_cs
 

cp1251" "52" "" "" "0"] ["cp1256_general_ci" "cp1256" "57" "Yes" 
"" "0"] ["cp1256_bin" "cp1256" "67" ""

 "" "0"] ["cp1257_lithuanian_ci" "cp1257" "29" "" "" "0"] ["cp1257_bin" 
 "cp1257" "58" "" "" "0"] ["cp1257_

general_ci" "cp1257" "59" "Yes" "" "0"] ["binary" "binary" "63" "Yes" 
"Yes" "1"] ["geostd8_general_ci" "ge

ostd8" "92" "Yes" "" "0"] ["geostd8_bin" "geostd8" "93" "" "" "0"] 
["cp932_japanese_ci" "cp932" "95" "Yes"

 "Yes" "1"] ["cp932_bin" "cp932" "96" "" "Yes" "1"] ["eucjpms_japanese_ci" 
 "eucjpms" "97" "Yes" "Yes" "1"]
 ["eucjpms_bin" "eucjpms" "98" "" "Yes" "1"]]

== [["big5_chinese_ci" "big5" "1" "Yes" "Yes" "1"] ["big5_bin" "big5" 
"84" "" "Yes" "1"] ["dec8_swedish_ci
 
dec8" "3" "Yes" "" "0"...

I'm working on a text to speech processor that could use MBROLA  
as  engine ASCII TEXT would be converted to PHO mbrola phonetic describtion 
file. Of course using rebol/view  1.3
 :)

REBOL is using a windows function for decimal to ascii conversion 
that wine implements incorrectly.

I use have used Unix without a gui  well  forever,   but unless gimp 
has an ascii rendering mode  (netpbm does) it may not be what you 
want .

Well, in Rebol/View 2.7.6.4.2, I can paste the multiply sign (copied 
from ascii-math.r) straight into the console and it shows correctly. 
In a field, however, it shows incorrectly, eg. if I try to paste 
it in the field:
	view layout [f: field]
I get two characters,  'Ã' and a dotted box, displayed instead.

The binary information is correct, it's just not rendered correctly, 
for if back in the console I do:
	probe f/text
then I get the multiply symbol displayed correctly again.

So it looks like View face/text rendering is expecting 8-bit ascii 
of some encoding.
Probably ISO/IEC_8859-1

re: ios, if you have non-ascii chars, it could be a problem.

Take a look at http://www.johnsons-web.com/cgi-bin/test.r.This is 
very bizarre! If you use netscape, you will see the entire usage 
message from rebol displayed prior to the mime-type header. If you 
use IE, it is likely that some but not all of these effects will 
be obfuscated, but you should be able

to see the entire output if you view the source. The sources from 
the script is being sent from a windows computer to a linux server. 
Now, if

I use a FTP client like WS_FTP which as a "ascii" mode, it automatically 
converts line enders to unix style, and this problem does not occur.

Janeks,  here are some things to try:

1. Make sure you uploaded the rebol exe as binary and the rebol script 
as ascii.

2. make sure you chmod your rebol files, rebol and even the cgi-bin 
(755).

Hope that helps. I have seen the same thing as you many times when 
I first set up rebol.

From Didier

	; decode ISO-8859-1 / ASCII-US encoded text

 decode-iso8859: func [str /local ascii non-ascii char text emit quoted-printable 
 encoded-word res b e] [
		emit: func [v][append res v]
		ascii: charset [#" " - #"^(7f)"]
		non-ascii: complement ascii
		text: exclude union ascii non-ascii charset ["="]
		char: exclude ascii charset ["?_=^-"]
		encoded-word: [
			"=?" ["ISO-8859-1" | "us-ascii"] [
				"?q?" some quoted-printable |
				"?b?" b: to "?" e: (emit to-string debase copy/part b e)
			] "?="
		]
		quoted-printable: [
			"_" (emit #" ") |
			b: some char e: (emit copy/part b e) |

   b: "=" (emit do rejoin [ {#"^^(} second b third b {)"} ]) 2 skip
		]

		res: make string! length? str

  parse/all str [any [encoded-word | "=" (emit #"=") | "^/ " | b: some 
  text e: (emit copy/part b e)] to end]
		res
	]

rebmail 4.10.11 & associated helptext has been released (18/06/2005) 
...

Changes Since 4.9.6
4.9.7   - Enhancement - Import emails" "Phil Bevan" 21/02/2005]

4.9.8   - Enhancement - Apply rules to a folder" "Phil Bevan" 30/05/2005]

4.9.9   - Bug Fix - Correct backdrop on getmail progress window" 
"Phil Bevan" 31/05/2005]

4.9.10  - Enhancement - decode ISO-8859-1 / ASCII-US encoded text" 
"Phil Bevan" 31/05/2005]

4.9.11  - Enhancement - allow Shift select to select multiple emails" 
"Phil Bevan" 01/06/2005]

4.9.12  - Bug Fix - Ensure download time is updated correcly" "Phil 
Bevan" 01/06/2005]
4.10.1  - Enhancement - Add options window
4.10.2  - Enhancement - Add rules maintenance
4.10.3  - Bug Fix - Remove Debugging info
4.10.4  - Bug Fix - Make Select Folder in Rules work
4.10.5  - Bug Fix - Apply send patch under View 1.3
4.10.6  - Bug Fix - Better Error trapping when applying fixes
4.10.7  - Bug Fix - Fix folder returned from unknown folder name

4.10.8  - Bug Fix - Do not try to copy email to itself when applying 
rules
4.10.9  - Enhancement - Add default inbox for incoming mail

4.10.10 - Bug Fix - Make Select Folder in Rules datila work for View 
1.2
4.10.11 - Bug Fix - Ensure preferences work on new install


rebmail.r can be found at .... http://www.upnaway.com/~philb/philip/pbmail/readmail.r

reabmail is also the following formats 

rip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.rip

zip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.zip


the archive containing rebmail.r & rebamail.html (rip = compressed 
self extracting rebol archive)
 
Any problems let me know.

Kru, as I understood on unix, filenames could contain any ascii characters 
0-255, but using characters such as "?" would confuse a lot of programs, 
so it was avoided. I don't know what the situation is these days.. 
Maybe they are more restrictive of allowed filenames.

Visit  http://www.TGD-Consulting.de/Download.htmland take a look 
at

the final release of Hex-It!. (I posted on behalf of Dirk Weyand, 
since he cannot reach AltME)


Hex-It! is a small but powerful hex-editor. You can use this tool 
to analyse
or alter the "fingerprints" for any kind of files.

Known first as a contribution to the REBOL Demo 2006 contest, the 
final
release with enhanced features is available now.
Features of Hex-It! v1.2.0:
---------------------------
* cross platform hex-editor

* free "save-feature" for small files sized lesser 15 KB, to edit 
larger
  files purchase a license-key that unlocks this limitation
* enhanced spot navigation with mouse scroll-wheel support
* non blocking file access 

* support of large files (a maximum chunk of 1MB file-data is only 
held in
  memory at once)
Some notes and useful tips & tricks on the usage of Hex-It!:
------------------------------------------------------------

- Modifications of files were automatically saved on exit, if you 
load

another file or if a different chunk of the same file is selected.
- Byte selection:

  + Select a byte with a left mouse button (LMB) click on the hexadecimal
    values to the left. The byte is highlighted then.

  + If a byte is selected, either use the cursor keys or the scroll-wheel 
  of
    the mouse to scroll through the bytes of the file.

  + Change a selected byte with plus (+) & minus (-) or just enter 
  its

    new value. Single characters, three digit numbers or single hexadecimal
    values are valid.

  + Use the right mouse button (RMB) to deselect a highlighted byte.
- Spot-navigation:

  + The spot specifies the index/position of a byte in the file. If 
  no byte

    is selected it shows the position of the top left byte displayed. 
  + Enter a number to set directly the spot to a byte-position.

  + Skip a certain amount of bytes relative to the current spot by 
  using

    plus (+) & minus (-), e.g. "+10000" skips 10000 bytes forward and
    "-1000" skips 1000 bytes backwards. 

  + Skip to end of file: Click with the RMB on the arrow-down Spot-button
    or use the "End"-Key.

  + Skip to first byte of file: Click with the RMB on the arrow-up
    Spot-button or use the "Home"-Key. 
- Seek:
  + ASCII- or Hex-Strings are valid queries.

  + LMB click on the "Seek"-button seeks from the current position.

  + RMB click on the "Seek"-button seeks from the beginning of the 
  file.

Please note, that the license of this release is not BSD like anymore.

Renote v0.9.2


Adds many little improvement, bug fixes, and you can now export the 
whole view into an ascii file.
Filtering is much improved (its interactive everywhere)

same download url

pics:
http://www.pointillistic.com/open-REBOL/moa/files/renote-1.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-2.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-3.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-4.png
http://www.pointillistic.com/open-REBOL/moa/files/renote-5.png

I just finished adding complete Macro control to Renote (v0.9.3). 
 


basically, you can use any one-line REBOL script and assign it to 
keys f1-f9.   Nothing is prevented, so you have full access to the 
running script data.  a small level of sandboxing even allows you 
to safely assign values to words without risk of side-effects.


In a single line, I can thus save out an ascii version of the filtered 
view and call notepad on it... its so fast, it feels like notepad 
is a window of the app!

I agree about the pictures. Too bad AltME uses variable length fonts, 
or I could do ASCII art. It's a good thing that denismx already told 
us that he is familiar with C++, so I don't have to explain what 
I mean by a pointer or a string here.

Look at the binary/ascii value of those chars; what are they?

Gregg -- I dont know how to reveal the binary/ascii values of the 
file, but the spanish y looks like it may be hex FF.  Do you have 
rebol code that can convert the characters into hex?

here's list from my system:

connecting to: www.jablunkovsko.cz
Net-log: [none ["220" "230"]]
Net-log: "220 (vsFTPd 1.2.1)"
Net-log: [["USER" port/user] "331"]
Net-log: "331 Please specify the password."
Net-log: [["PASS" port/pass] "230"]
Net-log: "230 Login successful."
Net-log: ["SYST" "*"]
Net-log: "215 UNIX Type: L8"
Net-log: ["PWD" "25"]
Net-log: {257 "/"}
Net-log: "Opening listen port 50061"
Net-log: [["PORT" port/locals/active-check] "200"]
Net-log: "200 PORT command successful. Consider using PASV."
Net-log: "Type: dir"
Net-log: ["TYPE A" "200"]
Net-log: "200 Switching to ASCII mode."
Net-log: ["LIST" ["150" "125"]]
Net-log: "150 Here comes the directory listing."
Net-log: "Closing listen port 50061"
Net-log: "Closing data port 193.85.151.2 50061 20"
Net-log: [none ["226" "250"]]
Net-log: "226 Directory send OK."
Net-log: "Caching cmd-port www.jablunkovsko.cz 50060 21"

I tried it here, here's where it starts to differ:

Net-log: ["TYPE A" "200"]
Net-log: "200 TYPE is now ASCII"
Net-log: ["LIST" ["150" "125"]]
Net-log: "150 Accepted data connection"
Net-log: "Closing data port 194.9.94.127 50078 56405"
Net-log: [none ["226" "250"]]
Net-log: "226-Options: -a -l "
Net-log: "226 11 matches total"
Net-log: "Caching cmd-port 194.9.94.127 50077 21"

apl/ apl101/ apl104/ apl105/ apl201/ apl202/ apl204/ apl206/ visaprom.com/

No.     Time        Source                Destination           Protocol 
Info

     90 2.750586    192.168.2.108         194.9.94.127          FTP   
        Request: TYPE I

     97 2.823074    194.9.94.127          192.168.2.108         FTP   
        Response: 200 TYPE is now 8-bit binary

     98 2.828500    192.168.2.108         194.9.94.127          FTP   
        Request: PASV

    113 3.171841    192.168.2.108         194.9.94.127          FTP  
        [TCP Retransmission] Request: PASV

    114 3.244193    194.9.94.127          192.168.2.108         TCP  
        [TCP Previous segment lost] ftp > mgemanagement [ACK] Seq=80 
    Ack=15 Win=16500 Len=0

    131 3.889034    194.9.94.127          192.168.2.108         FTP  
        [TCP Retransmission] Response: 227 Entering Passive Mode (194,9,94,127,250,69)

    137 3.984887    192.168.2.108         194.9.94.127          FTP  
        Request: STOR ik104test.zip

    149 4.247163    194.9.94.127          192.168.2.108         TCP  
        ftp > mgemanagement [ACK] Seq=80 Ack=35 Win=16500 Len=0

    210 7.046287    194.9.94.127          192.168.2.108         FTP  
        Response: 150 Accepted data connection

    241 7.218716    192.168.2.108         194.9.94.127          TCP  
        mgemanagement > ftp [ACK] Seq=35 Ack=110 Win=16269 Len=0

   1613 17.145048   194.9.94.127          192.168.2.108         FTP 
        Response: 226-File successfully transferred

   1617 17.172970   192.168.2.108         194.9.94.127          FTP 
        Request: SIZE ik104test.zip

   1620 17.277591   194.9.94.127          192.168.2.108         FTP 
        Response: 213 566605

   1623 17.375906   192.168.2.108         194.9.94.127          FTP 
        Request: TYPE A

   1628 17.498619   194.9.94.127          192.168.2.108         FTP 
        Response: 200 TYPE is now ASCII

   1629 17.516657   192.168.2.108         194.9.94.127          FTP 
        Request: PASV

   1633 17.644044   194.9.94.127          192.168.2.108         FTP 
        Response: 227 Entering Passive Mode (194,9,94,127,205,237)

   1637 17.750889   192.168.2.108         194.9.94.127          FTP 
        Request: LIST

   1643 17.835367   194.9.94.127          192.168.2.108         FTP 
        Response: 150 Accepted data connection

   1644 17.863490   194.9.94.127          192.168.2.108         FTP 
        Response: 226-Options: -a -l 

   1645 17.863548   192.168.2.108         194.9.94.127          TCP 
        mgemanagement > ftp [ACK] Seq=75 Ack=364 Win=16015 Len=0

Thanks Petr. He may have to wait for a supported UNICODE-enabled 
release.


Having given it a few moments thought, he may be able to fake it 
in *some* controls with font-name:

    view layout [box "hello" font-name "xxx"]  ;; where xxx is the name 
    of an installed font on his machine.

I tried that with my ASCII chart script, making that change. And 
it does (for me) show some Cyrillic. Not sure it's a complete solution 
though:
   http://www.rebol.org/view-script.r?script=ascii-chart.r

Thank you Pekr and Sunanda for your replies and suggestion on my 
question about unicode and cyrillic. I tried ascii-chart script and 
it unfortunately doesn't show any cyrillic letters :-(  I understand 
you, I have to wait until r3 is released, but I don't want to wait 
for it (as I can see from forum posts it could be not very soon).

Alexandr: < I tried ascii-chart script and it unfortunately doesn't 
show any cyrillic letters>
What I did that showed me some cyrillic was this:
** download the ascii-chart.r script from rebol.org
** change this line
     [append hex-lo [box 25x25 blue]
to
    [append hex-lo [box 25x25 blue font-name "WP CyrillicA"]
WP CyrillicA

 is a Cyrillic font I happen to have installed on my Windows PC. Any 
 Cyrilic font you have is likely to have a different name. When specifying 
 the font name it is case sensitive.


If this works for you. it may also help for many VID styles (BOX, 
BUTTON etc) It probably won't help for ALTER and other pop-up boxes

REBCODE is AMAZING ...


I am trying to convert a 300+ MB file from little-endian 16-bit Unicode 
to UTF-8. I am pretty sure that all the characters in this file are 
ASCII characters, so I can just discard the second byte (0x00) of 
every 16-bit Unicode character. Beside that, the beginning 2 bytes 
(0xFFFE) need to be discard too. 


In these two days, I wrote REBOL scripts for this purpose in different 
ways, and I suffered in different ways, too. Sometime I got out-of-memory 
error, sometimes I didn't. Even if I didn't get any error, the performance 
would definitely dramatically dropped down after few minutes because 
of the memory issue, I guess. I would take me 30 minutes to convert 
the file in my PC. I was trying to make it less than 10 minutes, 
so I kept asking stupid questions in the AtlME REBOL3 World.

 

Few ours ago, REBCODE came to my mind out of the blue. I remembered 
Carl said something like 10-30 faster. Because I am no REBOL expert, 
I'd never used REBCODE before. I took 1-2 hours to read the REBCODE 
document, then I do my very first REBCODE code in my life. Guess 
what? It turned out very well. The REBCODE version took only 45 seconds. 
It's AMAZING.

It's quite possible these days that it doesn't take ascii.

If you look in postscript.r, I encode the image data in line 211-220. 
It's just normal hex written as ASCII, so you get '0'-'9' + 'A'-'F'.

Looks like Cheyenne is trying to create a new form of ASCII art :-). 
First time I see that on Cheyenne. Will reset the server at once.