World: r3wp

>> series
== [1 2 3 4 5 6 7 8 9 10]
>> series: back tail series
== [10]
The AT is implied by TAIL, and then again by BACK.

yeah only example I can think of.

I had it written down from something I had been working on.  Go ahead 
and resolve the ticket if you like - if I come across the problem 
that resulted in my notes then we can revisit it.

An example where you are trying to go to the same position of another 
series would be more useful, since that would mean removing an INDEX? 
function instead of adding an AT function.

Yeah in my notes I have "no copy'" so something I was involved with 
wanted the fucntionality without copy.

Interesting. No copying is going on here, just references passed 
around.

Ahhh, just AT series back tail series.

so in other words the following:

at series back tail series

The assingment is implied.

no need to set series: at series back tail series.  But instead the 
at command is manipulating the series directly for the navigation 
arguments.

Wait... Are you Paul ? really ?

Yes Steeve.

No, the at series is implied. The assignment is also implied for 
ports in R3 though.

Never left.

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