World: r3wp

yeah, for what you are doing Drop and Off definitely have to work!

posted question to rebdev, how far are we with March dev plan, in 
order to sync sources with Cyphre once again and let him fix few 
things.

Steeve, I think one gob per character may operate fast enough, if 
it's a modern machine. But then you have to do your own paragraph 
flowing etc.

argh, i was hoping you will not notice this

one gob per line is my aim

one gob per char, i don't ever try it. It will be slow and memory 
consumming

That's how I did my editor replacement in R2. But then I started 
wondering how to do my own flowing and I decided multiple gobs per 
line is the way to go. Needs some clever way of indexing lines and 
caching gobs so small near-constant number of gobs are produced and 
reused per window of text.

Sorry, I didn't mean per char, but per font / formatting change.

i can manage multiple gobs per line (depending of the grammar) but 
i don't want to use a gob per char, what a pain in ass when the text 
is scrolled or modified ...

yes but in that case, wrapped text, is hard to handle if it's not 
one gob per char

Yes, you would have to do the flow / wrapping algorithm yourself.

doubling the size of my script at least :-)

Yes, lots more fun.

pfff

Rejoining a massive block of strings after reading from the clipboard 
causes a crash...

---------------------------
REBOL System Error
---------------------------
REBOL System Error #1215: assertion failed

Program terminated abnormally.
This should never happen.
Please contact www.REBOL.com with details.
---------------------------
OK   
---------------------------

; pasting this code into the console seems to be just fine but if 
you

; do read clipboard:// it fails on the first or second attempt causing 
the above error...

blk: []
str: to string! to char! 0
repeat i 256 [insert str to char! i]

rdm-str: has [txt] [txt: copy "" repeat i random 80 [insert txt random/only 
str]]
repeat i 4020 [insert blk rdm-str]
probe length? blk
probe length? rejoin blk

and the length of the block appears to be key here. at 4019 I never 
see a crash but once you go over 4020 REBOL becomes unstable.

what a dummy test :-)

is that a real program ?

I was planning on using it to test my scrolling quality on a large 
chunk of text...

it's about 160k characters over 4k lines.

but it's much more memory overhead, cause your blocks and temp strings 
are expanded at each add

many many temporary strings are created and fill the memory

Memory overhead?  NOPE.   The console doesn't even increase 1MB memory 
use during or after execution of the above test.

hmmm

That was my first thought after I ran it a couple of times.  I figured 
I had to have used up at least 50MB or maybe a lot more, but nope.

The garbage collector do a nice job in R3

=D

I was going to put this on CureCode but when I go to the Add Ticket 
link it tells me to pick a project.  Project?  What Project and how 
do I pick it?

Oh, there it is.  I'm just blind...

I'm missing the --DO command line usage functionality from R2, here 
on linux.

I am missing --DO, but actually I miss -- even more.

I need to pass command line options in and be able to inspect them 
in system/options/args in user.r.

we've talked about functions like NFOREACH before, regarding multiple 
blocks of different lengths, and it makes me think there is a need 
for handling numbers, where each digit is handled as a separate base.

It's tiresome to build counters and I feel there must be some common 
ground, som built in base counter could cover.

but this would not be normal number handling in that math isn't involved, 
only INC and DEC and some indicator of which digit is currently changing.

right now, I'm rebuilding the MAKE-TICKS function for the R3 GUI 
as I need more flexibility, and it would be greatly simplified and 
easier to understand with something like this.

Consider if we had a COUNTER! datatype. The counter would create 
a series of integers, each holding a separate base. The trick to 
COUNTER! is that it is a structure that holds more information than 
just the numbers, but also states, in the same way that a block holds 
an index or whether a port! is open or closed.

First the bad things:


- It can be complex and there are many things to consider. Many functions 
would be affected.

Now the good:


- This takes all the thinking out of building trivial counters and 
could greatly simplify it.
- It could be used as an any-base converter.
- No new functions to add specifically for it.

It should be possible to:

- Specify as many numbers per counter as we like.

- Each number would be within the limits of positive integers and 
each number would act as an integer! type.

- Extract information about which digit is currently counting or 
which number was last changed.
- Extract base information.
- Perform basic math (add/subtract).
- Perform base conversion for the entire counter.
- Perform base conversion between a counter and an integer.

A counter would hold four pieces of information:

- The base for each number
- The numbers themselves
- The last changed number as a one-based integer index

- The last numbers that were reset at last count as a block of one-based 
integer indexes

The nature of a counter:

- It would be a number!.
- It would not be a series!.

Specifying a counter:

- The above four pieces would be specified in order
- Each piece is separated by an exclamation mark
- Possible to skip pieces by leaving the field empty

- Syntax: !<base definition>!<number>!<last changed number>!<last 
reset numbers>
- Counter base alone: !12.14.16
- Counter base with number: !12.14.16!0.0.0

- Counter base with number and last changed number: !12.14.16!0.0.0!3

- Counter base with number and last changed number and last reset 
indexes: !12.14.16!0.0.0!3![2 1]
- Number without base: !!0.0.0

There's more, but it's a little much to write. :-)

Henrik, what are the different usecases, you don't talk about it 
as much.

Can you fulfill a mezzanine which simulates his expected behavior 
?
Because, just by reading your specs, i can trully figure it.

(*i can't trully...)

Ammon, what about your tests on rich-text. Is that fast enough ?

Steeve, I'm writing it up now. It's probably possible to do with 
a series of mezzanines, but it would not be very elegant.

By elegant, you mean fast enough for your need :-)

No, I mean being able to use ordinary math functions directly on 
the counter.

I'm changing my mind on not needing math and it not being a series. 
Sorry, if that seemed confusing.

Don't worry, it seems confusing only because i'm stupid :)

I just have a very clear example in MAKE-TICKS, where it would reduce 
about 10 hard to understand lines of code to 1 or 2 very clear lines 
of code.

Just to replace 10 lines of code in one usecase ? You're assuming 
Rebol should behave as your own or what ? :-)

I have encountered this problem before, where I just had to give 
up, because the problem became too complex to solve in a hurry. With 
the counter! datatype, it would not be a problem.

If it can be used to maintain large index on any data structure efficiently, 
it could be usefull. I'm waiting for your code

It'll be a while. Some things to think through first.