World: r3wp

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 ?

We'll see. Native changes to R2 are not as easy as mezzanine changes. 
This one doesn't seem to depend on new R3 structures, but...

R2 is not really in new-native-feature mode for the forseeable future, 
but we'll see what can be backported.

Changes in individual functions are more likely than changes in types 
or data structures.

it's curious that Carl is not aware of the "chaining" use of INSERT 
!!!!

If we don't have the "chaining"  behavior with reduce/into, then 
we will lost some speed in loops (because of the need to update the 
index of the serie separatly after each iteration).

Curious objection from Carl (The users may be unable to understand 
how to use it) 
Uh ?????

i want some proofs that we actually use "chaining" insertions ?
I can send him some dozen of old scripts if he wants... :-)

*he wants

He's aware of the value of chaining, but is wary of the "bug" reports 
he already gets about INSERT. Apparently there is some tiny amount 
of overhead too, which for a function as low-level as REDUCE might 
matter. "Penny wise, pound foolish" - I'm trying to convince him 
otherwise.

We can save much more overhead by replacing chained inserts in the 
mezzanines. COMPOSE/into will have massive impact :)

Actually, the first optimization i do in my scripts which need speed 
and low memory usage, is to remove all the reduce and compose usage.
It's always the first thing i do

Now, you will be replacing REDUCE and COMPOSE with REDUCE/into and 
COMPOSE/into and preallocated or reused buffers :)

but this optimization isn't always possible.  when nests are deep 
and composes are chained within each other, you can't just chain 
insert and remain sane  ;-)

with liquid-paint, this would have MASSIVE impact.

although liquid-paint is already much faster than AGG and lazy so 
the gains might not be as noticeable, but still I can't wait to have 
time to try and port my stuff to R3, it does seem to be much more 
series stable, by all accounts.

Nested REDUCE and COMPOSE is not that common outside of code generation 
and nested data structure creation. I do that a lot, but I write 
my own mezzanines and some of them compile internally. I can think 
of many mezzanines that could be sped up with /into.