r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Steeve
23-Mar-2009
[12189]
i don't use those Carl's style
Ammon
23-Mar-2009
[12190x2]
I'm not impacted because each style change creates a separate face.
I'm not using Draw directly.
Steeve
23-Mar-2009
[12192x2]
and ? 
How do you handle imbricated styles in the same line of text ?
Like:

 gob/text: [ bold "this is bold" italic "this is it talic and bold" 
 off "this is bold" ]

Especially if the line is wrapped
don'
Ammon
23-Mar-2009
[12194]
Hehe, I'm not writing that kind of Rich Text editor...  It's really 
just a syntax highlighter so all of the formatting is implicit.
Steeve
23-Mar-2009
[12195x3]
if you construct linked gobs for the same line of text (one gob = 
one style), i say good luck to manage wrapped lines.
hum ok, it's more simple
you just change colors
Ammon
23-Mar-2009
[12198x2]
Managing wrapped lines isn't a concern at the moment.   What I will 
be able to do with the structure I've chosen far outweighs the extra 
cost dealing with wrapped lines if I ever decide to add that functionality.
No, not just colors.  You have full font control, bold, italic, etc
Steeve
23-Mar-2009
[12200x3]
i'm fucked, my current development is about editing makedoc documents, 
i can't bypass this request
i need wrapped paragraphs
rich-text at gob level must work
Ammon
23-Mar-2009
[12203]
yeah, for what you are doing Drop and Off definitely have to work!
Pekr
23-Mar-2009
[12204]
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.
Anton
23-Mar-2009
[12205]
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.
Steeve
23-Mar-2009
[12206x3]
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
Anton
23-Mar-2009
[12209x2]
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.
Steeve
23-Mar-2009
[12211x2]
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
Anton
23-Mar-2009
[12213]
Yes, you would have to do the flow / wrapping algorithm yourself.
Steeve
23-Mar-2009
[12214]
doubling the size of my script at least :-)
Anton
23-Mar-2009
[12215]
Yes, lots more fun.
Steeve
23-Mar-2009
[12216]
pfff
Ammon
23-Mar-2009
[12217x3]
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.
Steeve
23-Mar-2009
[12220x2]
what a dummy test :-)
is that a real program ?
Ammon
23-Mar-2009
[12222x2]
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.
Steeve
24-Mar-2009
[12224x2]
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
Ammon
24-Mar-2009
[12226]
Memory overhead?  NOPE.   The console doesn't even increase 1MB memory 
use during or after execution of the above test.
Steeve
24-Mar-2009
[12227]
hmmm
Ammon
24-Mar-2009
[12228]
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.
Steeve
24-Mar-2009
[12229]
The garbage collector do a nice job in R3
Ammon
24-Mar-2009
[12230x3]
=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...
Anton
24-Mar-2009
[12233x3]
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.
Henrik
24-Mar-2009
[12236x3]
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.