World: r3wp

Mezz or native? Not exactly clear how the /into refinement works.

/into is a new refinement for most series. It makes it possible to 
store the result directly in a series without copying. I've been 
watching BrianH jump up and down over this feature a few months ago. 
:-)

split is mezz.

So how does the "fixed size" bit of split work then?

the 'dlm can be either a char/string for variable size or an integer 
for fixed size.

>> split "1 2 3 4 4" 2   
== ["1 " "2 " "3 " "4 " "4"]

>> split "1 2 3 4 4" " " 
== ["1" "2" "3" "4" "4"]

Ah thanks. That's a very usefull addition.

ok, there are some bugs in this function. /into does actually not 
work this way. bug reports will be needed here.

it seems that it's bound for a rewrite. perhaps the priority should 
be bumped.

Being mezz makes that easier at least.

anyhoo, the point is that the obscurity of splitting using PARSE 
might be removed, so we will be using SPLIT in the future.

Maybe TOO is too similar to TO,  but it's meaning is appropriate 
for this AND or  &

write parsing CSV like input, there was a proposal to solve it via 
external function or decode-csv aproach, which could internally use 
parse.

for new parse rewrite, there is going to be default /all mode, and 
/ignore mode and even maybe /case, so dunno, if delimiters will be 
provided as with R2 parse ...

I have a small CSV parse and CSV generator library that we could 
start from.

Henrik, i hope we will not remove the splitting behaving of PARSE 
because actually SPLIT is damn slow

SPLIT has too much useless options and use other mezzanines (COLLECT) 
in his code, it why it's not a good mezznine to my mind.

Actually, i don't like mezzs which return block of data with unlimited 
sizes.

I like mezzs with async behavior, to treat each data set, step by 
step.

I'm reading several times needs for CSV parsing enhancements, are 
they issues with parsing CSV files with R2's parse?

On example here -- the specific problem is the same in R2 and R3:
   http://www.curecode.org/rebol3/ticket.rsp?id=1042&cursor=2

This highlights the actual change that would need to happen to PARSE: 
http://www.curecode.org/rebol3/ticket.rsp?id=1079

Thanks, so it's parse's splitting ability that is causing an issue.

Brian - it seems that Ladislav does not agree to your conclusions 
towards parse internals ... and Carl is all but silent :-)

It reminds me of old ML discussions of gurus, trying to find internal 
REBOL representation, and differing in opinion of how things are 
done under the hood.

Carl revealed the internals, inadvertantly, earlier in that comment 
discussion. It was easy to figure out. Ladislav needs to read closer.

Back in 2000 I was one of those gurus on the mailing list, and my 
argument with Gabriele was the initial documentation for R2's context 
model and behavior. I was glad when Ladislav later fleshed out that 
discovery with more detail in his Bindology papers.

I do remember guys like Tim Peters, Joel Neely, etc., Well, those 
were the times :-)

:)

I remember Carl used to be on the mailing list ...

I remember I used to be on the mailing list. Haven't been for many 
years now.

I have a proposal - I think that we all know, that View engine itself 
needs few enhancements, which would be nice to have for the official 
3.0 release. I would like to create wiki page similar to Parse proposal, 
to which we could contribute our requests. What do you think?

I don't think Carl will work in View engine anytime soon, but having 
those things collected in one place would be surely good.

Sounds good ... and won't hurt

I think that Cyphre can't work on View engine because of C code alignment. 
We have to wait, untill Carl isolates kernel and host, and releases 
the code. But then - even few small changes might make some difference 
in the end. I think that View engine deserves few weeks of additional 
developments ...

My favorites are:

- better font support
- ability to precisely measure font-size
- draw level events?
- move to Multimedia Timers
- transparent windows - just setting bits in API
- we don't use bitmap caching yet
- eventual switch to compound rasterizer

my requirements are 

draw item word reference,   [target: circle 0x0 50 ]
draw item as objects,    [target/offset: 20x20]
vertice access & control,

key up events.
timers

My preferences:

- Get it done
- Make it easy to use

- Use R3's existing timer system for long delays, and then multimedia 
timers for the last precise bit

- Get smart graphics people to help with the little details, but 
smart systems people for the overall design

- Make it so easy to use that I, as a non-graphics-person, can write 
GUI apps

Also, don't neglect R3's event system in favor of hooking in some 
external one. If there are problems with R3's system, fix them first.

- Hookable system dialects (draw effect text)
So that we can add our own commands or hook some existing ones.

brianH yeah ... i always said new VID have to be as easy to write 
as previous vid for non specialist and  it serves even a greater 
purpose the GUI designers area. With easy made gob or panels (windows 
where you arange the gob to be displayed on screen ... ) the the 
designer output source produced with those tools remains easy to 
read.

visual gui editing with row columns is pretty easy to build.

i was trying the new parse commands...

I came with something existing, and said: Now, how can i do this 
more rebolish...

parse/case opcode [
	any [
		start: 
		| "nn" end: (change/part start get-byte end)
		| "+d" end: (change/part start get-d end)
		| "e" end: (change/part start get-e end)
		| skip
	]
]

Because change still doesn't work , the best i can do is that:

parse/case opcode [
    any [
          "nn" remove -2 (new: get-word) insert new
        | #"n" remove -1 (new: form get-byte) insert new
        | "+d" remove -2 (new: get-d) insert new
        | #"e" remove -1 (new: get-e) insert new
        | skip
    ]
]

What the gain ? nothing...

Forget CHANGE for the moment. Even with INSERT and REMOVE commands, 
i see things i don't like.

What i should able to write is that:

parse/case opcode [
    any [
          remove "nn" insert get-word
        | remove #"n" insert get-byte
        | remove "+d" insert get-d
        | remove #"e" insert get-e 
        | skip
    ]
]

Wich means:

- Remove "nn" if  "nn" is matched and insert the result of the function 
get-word.
or  Remove "n" ..
or  remove "+d" ...
or remove "e" ..

- Remove should use any rule as argument and not an obfuscated relative 
counter, because we don't have to calculate that. 

We know what matching rule must be deleted, we don't have to calculate 
is length more over.


- Insert should accept calculated values, it's obvious. If not it's 
useless.

When Change will work, I expect to be able to write:

parse/case opcode [
    any [
          change "nn" get-word
        | change #"n" get-byte
        | change "+d" get-d
        | change #"e" get-e 
        | skip
    ]
]

nothing more, nothing less

First of all, Steeve, what you are suggesting is the original INSERT, 
CHANGE and REMOVE proposals. Which Carl said were infeasible to implement, 
which is why we have the new ones. Besides that, your example code 
is still too awkward. Try this:

parse/case opcode [
    any [ start:
          "nn" remove start insert (get-word)
        | #"n" remove start insert (form get-byte)
        | "+d" remove start insert (get-d)
        | #"e" remove start insert (get-e)
        | skip
    ]
]


If you are worried about change not working yet, don't be. It is 
still planned.

The change version of the above would be this:

parse/case opcode [
    any [ start:
          "nn" change start (get-word)
        | #"n" change start (form get-byte)
        | "+d" change start (get-d)
        | #"e" change start (get-e)
        | skip
    ]
]