World: r4wp

In Ladislav's examples I am not ablie to understand the use of Break. 
Why it is useful ?

 - in any [</div> break ...] the BREAK keyword stops searching for 
 the terminator when one was found (</div>). If you don't use BREAK, 
 you simply don't stop searching even if you already found the terminator.

Also in the second example why there isn't a 

end:" before "</div> break" ?" - it is because the first END: was 
already used and the position is remembered. (however, you can use 
end: twice if you like)

You should just remember that end: never fails, so the expression:

    end: </div> break | </br> break | ...

is equivalent to:

    end: [</div> break | </br> break ...]

, i.e., the end: part is known for all alternatives

'Could it be written as:

parse/all s1 [any [to "http://"copy link TO any [</br> break | </div> 
break | skip] (print link)]]' - no, since:

- TO ANY is not supported

- if it were supported it would not do what you want (you want to 
find the first terminator whatever it is, while TO ANY would find 
the </div> if it were in the input text even when a "closer" </br> 
would be "closer"

Or
parse/all s1 [any [to 

http://"copy link any [TO </br> break |TO  </div> break | skip] 
(print link)]]" - this *is* supported, but it does not do what you 
want; it finds the </br> even if </div> occurs "sooner"

Finally, which is the purpose of the SKIP keywork in this context 
?
 - that is the easiest question. The expression

    any [end: </div> break | </br> break | skip]


simply checks whether it "sees" the </div> terminator. If it does 
then the search for the terminator is over. If it does not then we 
check immediately whether we do not "see" the second possible terminator. 
However, if we are not at the terminator, both alternatives fail 
and the third alternative has to advance to the next position to 
be able to finally find the terminator.

(if you do not advance you cannot expect to find the terminator)

This may be a simpler/more understandable description of the idea:

    terminator: [</div> | </br>]

    find-terminator: [start: any [end: terminator break | skip] (contents: 
    copy/part start end)]

The code is a simplification anyway. It does not work well when the 
rule is expected to fail at the tail of the input if the terminator 
was not found. That would require the REJECT keyword or a more complicated 
expression.

The simplest way how to write the FIND-TERMINATOR would be recursive:

find-terminator: [terminator | skip find-terminator]


However, this version is recursive, which means that it fails when 
the search is "long" exceeding the available stack size.

By "it fails" I mean that the recursive expression would not be able 
to find the terminator even if it were present when the length of 
the search would exceed the available stack size.

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.

Ladislav, some questions are still open. I am currently remotely 
connected to my machine. I'll study your "lesson" tomorrow and I'll 
reply.

Peter, seeing your conversion routine on rebol.org, you know the 
ins and outs ;-)

All the special ones I need are in the next 127. On the windows they 
show up. That's one of the points to be taken into account for Red 
development.

And knowing even this small community has less members then the diacrits 
they are using in everyday living it is a requirement to deal with 
UTF-8 UCS or other encodings.

Why isn't there to-dir when there is to-file? Would adding to-dir: 
:dirize do the trick of making a to-dir function? Why isn't it implemented 
as a standard?

Because all of the to-somedatatypeword functions are specifically 
only for datatype conversion, and we don't have a dir! or directory! 
type.

It doesn't really matter though; these aren't keywords. If you want 
to-dir: :dirize in your own code, put it in. Or put it in your rebol.r 
file.

I've decided to start hacking about a GPL REBOL written in Squeak 
Smalltalk. The goal is to start crafting a REBOL's copy maximally 
close to the original REBOL2. Another goal is to study REBOL2    
:)

You're kidding!

We're going to have more forks than users

Children's adventures :)

Who is writing another strict rebol copy? I could join in

Brian (Hostile Fork) was interested in developing a strict REBOL 
clone though his proposal was to use a "modern" cross platform approach 
such as QT/C++ 11.

That is an OK approach. I could join Brian if he is working on that.

Brian, are you here?

What are your status re: strict rebol clone and plans about it?

Brian left after a disagreement ...

I currently read his blog. I am also liker of Robert Piersig's books, 
and that's fantastic about Brian...

Evegeniy: I will contact Brian and give him your email address.

Peter, that would be good. If I will have his e-mail I will probably 
write him.

That's a very good Brian's comment: "REBOL's rejection of the multi-markup 
madness is a very good thing." (Here: http://hostilefork.com/2008/09/08/is-rebol-actually-a-revolution/
)

I've emailed Brian your emal address.

His blog is highly interesting read....

I have a problem renaming files. rename does not change the filename 
on MacOSx. In the terminal it is no problem but in my script the 
filenames are not changed.

            fileo: to-file rejoin [what-dir add-suffix naam-oud-z-ext extensie]
            filen: to-file add-suffix naam-oud-z-ext extensie
            rename fileo filen

I have tested with probe that the types are ok and with the resulting 
values for fileo and filen the rename command worked like a charm. 
Any more ideas what is happening and how to debug this further? Thanks.

A found it! typo! I should have used the new name ;-) naam-new-z-ext

Would have searched for hours if I hadn't posted this :-D

Petr, if you need a quick command line codepage converter program, 
try txtcnv32 here: http://www.ltr-data.se/files/txtcnv32.zip

It lets you specify code pages by number. The documentation of the 
code page numbers is here:

    http://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx

It's just a 3KB wrapper around the Windows code page conversion functions. 
There's source too.

Arnold, for the dir issue:

>> ?? dirize
dirize: func [
    {Returns a copy of the path turned into a directory.}
    path [file! string! url!]
][

    either #"/" <> pick path length? path [join path #"/"] [copy path]
]

>> ?? undirize
undirize: func [
    {Returns a copy of the path with any trailing "/" removed.}
    path [file! string! url!]
][
    path: copy path
    if #"/" = pick path length? path [clear back tail path]
    path
]

In the original script I use a change-dir to get into the right directory. 
Then renaming is just the rename filename newname. I stuffed the 
renaming into a function and changed the variable names. Everywhere 
but in this place where I wanted to rename the file for real and 
I forgot to change old to new.... so here I tried debugging it while 
using the complete path and filename, because I was afraid there 
could be an issue there.

The positive side of things is I am starting to make real errors 
in stead of messing about with the functions in REBOL.

Is there any other way to make an iterated label or text item in 
VID then the way stated in http://www.rebolforces.com/zine/rzine-1-03/#sect5.
or http://www.rebol.com/docs/view-face-other.htmlbecause this seems 
to me to be too complicated for REBOL. At least for me.

it depends on what you want to do. LIST is not very flexible.

Well I found a more promising way here http://www.codeconscious.com/rebol/view-notes.html
What I want to do is have a number of text/labels that I want to 
show a short text from a block of values. So I prefer to do it in 
a loop like loop 8 [mylabel/index/text: myblock/index]

If the number of texts doesn't vary, it might be simpler to make 
the fields manually instead of using an iterated face. The reason 
for this is that you need to write the SUPPLY code yourself, which 
will run every time you run the code and will run on every mouse 
move, if your text has a FEEL object with ENGAGE, OVER or DETECT 
functions, whereas simply making 8 texts once with VID is both faster 
and requires less code.

iterated faces are best for large arrays of faces.

I'll stick to the keep it simple strategy then, only 32 labels in 
my little app. I am recreating my Java mirror-game applet using REBOL 
Thank you very much Henrik!

NP. I don't usually mess around with iterated faces unless I really 
need to, so I have some standard styles for lists that abstracts 
this stuff away.

Anyone has a good idea to count number of values in a block? Ofcourse 
it is not difficult to write, but I want to ee some clever ideas 
:)

>> b: ["a" k 99 k k 99 55 "a" 1]
>> count-values b
== ["a" 2 k 3 99 2 55 1]  ;value-count