World: r3wp

Do you get what I'm saying Brian?

not explaining it well I don't think.

I got two conversations going on - one here and another with Graham 
on his server.

I get what you're saying, but AT is still not modifying for series.

Yeah I know but in this case if it has a navigational argument I 
was thinking it should.

Naw, the navigational functions are just functions for series - except 
++, -- and FIRST+. They are only modifying for ports. By design :)

Can I modify my ticket to better reflect what I was trying to communicate?

Sure. I haven't reviewed it yet in case you wanted to.

I will in a few minutes.

Wonderful bugreporting by Ladislav. Thanks.

http://www.rebol.net/r3blogs/0207.html- Should UNSET act as a value?

(continued from !CureCode) When the time comes, the Parse Proposals 
will need to be reorganized so that there are separate sections for 
general operatioons, and for the operations that are specific to 
blocks, strings, binaries, ports. At the very least, there needs 
to be good binary pattern recogntion operations.

Having the copy operation when applied to a binary! return a binary! 
is an improvement of R3 over R2 already though :)

Steeve, it's not working..
>> str: to-string #{C49BC5A1C48DC599C5BEC3BDC3A1C3ADC3A9313278}
== "ešcržýáíé12x"

>> parse str [some [copy tmp 1 skip (probe tmp)]]
c
ž
á
é
2
x
== true

(you will not see correct chars here probably)

but you can see, that the skip is not working as expected.

parse/all

That's an error - using /all shouldn't fix it because there are no 
spaces there.

Write it up in CureCode.

hm.. than it's ok... BUT there are no spaces inside the string, so 
why /all ?

Because it's a bug.

yes... I was slower than you:)

A bug in PARSE.

Sorry, my AltME is slow today.

well, actually i didn't found the bug, it's Brian

In R2 the underlying data of strings and binaries is the same: bytes. 
In R3, strings are made up of Unicode codepoints, binaries of bytes.

Anyway.. I almost always use parse with /all in R2.

me too

Same here. I never was good at predicting what PARSE without /all 
would do, exactly.

yep, it's why i didn't saw that bug in R3

we need serrious doc on parse i'm sure i could use parse more if 
i had some serrious explain of it

Parse is the main reason why I use REBOL:)

I too i love parse and i'm sad to not understand it enough to exploit 
it to its extend

oldes i'm doing irc client with colot text support that's fun i tool 
your irc-core as base

and that's the kind of application where the use of parse to colorise 
the text would be fantastique

oldes i'm doing irc client with color text support that's fun i took 
your irc-core as base

actually i'm thinking about the best way to handle client side texte 
in color

for example i would like to make it something like 1 color for server 
messages then 1 color for each chat you enter in

and 1 color for private message

you could enter 5 différente channel and see them all in the same 
window no need to switch channel to follow it

I prefere multiple channels:)

hum ... yeah but that's a pain to have to switch betwin them

i think i will do that anyway since it's so usual way to handle chatting

i just hope memory will not explode lol

i will do a treeview with the server name as root and as leaf channel 
name you entered clickin on root you have the server messages displayed 
clicking on leaf you have the channel displayed

Wow, reduce/into, compose/into at least...
Great improvement !

yes that is major !

thanks Brian!

I've been waiting for this siince last year. I posted a comment about 
usage :)

retro-fittable to R2 ?