World: r3wp

Nope.

Hmm.

Only on recursed functions.

I guess it can't be otherwise we wouldn't need to use 'copy on series

It's a speed optimization. This might change with REBOL 3.

memory use is a large with Rebol.

The series copy thing is something different.

speed or memory ..

Most of the excessive memory overhead of REBOL is just sloppy (no 
offense Carl). It's not much of a problem for most, but I have run 
into memory limits when running on embedded or handheld platforms, 
or running hundreds of instances on servers.

You have to design your platform for memory efficiency or it won't 
be.

Little problem :(

** Script Error: Invalid argument: make bitset! #{
0004000001000000000000000000000000000000000000000000000000000000
}
** Where: expand-macros
** Near: parse/all data [some [any whitespace [
            macro-rule (
                macro: copy/part here there
           ...

whi the parens on   whitespace: rule?

nevermind it is in compose

but that can just be a static rule outside of compose

More efficiency. I build my charsets once, rather than on every call.

should probably build the rule outside the function as well since 
it only should be rebuilt when the macro list changes

cant say to whitespace

wish you could

tipicaly get around with

that's where my rule got stuck .. on to whitespace

bs: complement ws

any bs

Yeah, I'm changing my code now.

expand-macros: func [data [string!] macros [block!]
    /local ws non-ws macro-rule macro expansion here there
] compose [
    ws: (charset " ^/") non-ws: (complement charset " ^/")
    macro-rule: make block! 2.5 * length? macros
    foreach [macro expansion] macros [
        macro-rule: insert macro-rule
            compose [here: (macro) there: [ws | end] |]
    ]
    macro-rule: head remove back macro-rule
    parse/all data [some [any ws [
        macro-rule (
            macro: copy/part here there

            there: change/part here select/skip macros macro 2 there
        ) :there |
        some non-ws
    ]] to end]
    macro-rule: none
    data
]

See, I don't have to test. Graham has the data, he can test :)

that is the part I can't allways be bothered with either

LOL ...

When it's my data, I test it myself. After the major logc bugs are 
worked out in my head of course...

REBOL catches spelling errors (logc -> logic).

Have you guys made any submissions to RT for parse improvements for 
R3?

Any further submissions ie.

RT can just use the pending suggeations from before R3

Gabriele and I have worked extensively on such submissions.

Ok, Brian, this one seems to work :)

Hmm.  Another problem.  If the macro expansion contains newline characters 
ie. "^/", the returned text has "^/" in it

ros {ROS: ^/Gen: wt. stable,no fever,chills or night sweats^/CVS: 
neg cp, sob, pnd, orthopnea or dyspnea on exertion^/GI: neg constipation, 
bright red blood per rectum, or melena

I guess I need to form it before I add them to the macros block.

Trim it.

the above macro is supposed to expand into a multiline statement.

Then it is a good thing that the ^/ is in the expansion.

No, as it ends up on screen showing ^/ instead of a visual newline.

Are they writing ^/ in the expansion text source data to indicate 
a newline?

Yes.  So, somehow I need to force the area field to recognise them 
as newlines and reformat the screen.

They're using ^/ as the macros are being read in from a text file 
using read/lines

When you read the macro data, do this to the expansions:
replace/all expansion "^^/" "^/"

so, read/lines is escaping the ^/ ?

No, it isn't. You have to yourself. Can you save the macro data in 
REBOL data format?

I guess so, but I want to make it easy for the users ...

but that works now :)

Thanks for the help guys