World: r3wp

You released the toolbar somewhere...

uhmm... not sure about weirdest :-) but I build the toolbar layout 
from a block that is parsed, appending faces and their attributes 
as it gets parsed. when that's done, I show it..

can't remember if it's the latest version... it has a few extras

http://hmkdesign.dk/rebol/toolbar/toolbar.r

it's pretty new

and is your code to show the bug shortish ?

I'm not done with it yet. I still only have seen the problem in the 
complex application, but the test code is so far about 15 lines

I would make a "debug" copy of the complex application, then cut 
out chunks until the bug no longer appears.

the thing is that it happens when I close an INFORM too

but I'm not sure about the relation between that inform and a toolbar 
update.

:-( ran 2000 updates on the test version without problems.

Just looking at the toolbar code, I suspect the DRAW dialect, perhaps 
it is the use of FILL-PEN LINEAR ? I seem to remember a bug there...

I could try disabling it...

Well, the best idea is to start with a copy of the full app, as I 
suggested above. I've done the same thing as you, trying to track 
down bugs, trying to guess what it is.

Guessing is cool but it's not as sure as subdivision.

true, but it will be very time consuming...

Can be hard sometimes to remove certain chunks, but usually you can 
disable large chunks of code using comments, verify that the bug 
is still there, then remove the code - and repeat until there's not 
much left and the bug is obvious.

well, DRAW isn't the culprit

Ok, so my first guess has removed a small amount of code. (wouldn't 
it be better if it was 50% of the code ? :-)

http://hmkdesign.dk/rebol/toolbar/toolbar-demo.r<--- I don't know 
if the bug shows here

the thing is, what if it's a buffer overflow? that will be really 
hard to fix, because you might run into the bug randomly.

It could be. But never miss a chance to find a deterministic View 
bug. :)

phew.. down to 500 lines of code

REBOL []

stylize/master [
  f: FACE WITH [
    do-this: does [
      insert tail pane: [] make face [
        feel: make feel [
          detect: func [face evt] [
            if evt/type = 'up [
              repeat i 5000 [
                do-this
              ]
            ]
            evt
          ]
        ]
        pane: make face []
      ]
    ]
    init: [do-this]
  ]
]
view layout [
  f 100x100
]

This is about as small as it gets for now. Run the code and click 
the gray area to crash rebol

Mmm.. that code is asking for at least 143 MB for those 5000 faces. 
:)

err... that's if a 100x100 bitmap is allocated for each of them..

Ok, this still shows the bug:
- removed stylize
- removed layout and view
- set object facets to none

view make face [
	size: 10x10 
	do do-this: does [
		insert tail pane: [] make face [
			feel: make feel [
				detect: func [face evt][
					if evt/type = 'up [
						repeat i 5000 [
							do-this
						]
					]
					evt
				]
			]
			color: edge: font: para: none
			pane: make face [color: edge: font: para: feel: none]
		]
	]
	color: edge: font: para: none
]

Click the little 10x10 box once or twice to crash.

is that related to the inform bug you were talking about or something 
different?

anyway - please RAMBO it.

is this just a recursive crash ?

gabriele, in my program it was triggered by closing an inform window, 
but after stripping away all the code to the above, it didn't have 
anything to do with it. It merely triggered the bug accidentally.

anton, in the "insert tail pane: []" part, it will still crash, when 
using copy on that array

Yes, it looks like maybe the View system can't handle too much recursion 
while processing events. It's still fairly serious as it shuts down 
rebol.

anton, interestingly also, speed has nothing to do with it. you can 
do the same thing at keyboard typing speed.

(that is, run each iteration at keyboard typing speed, not full rebol 
light speed :-))

must go - more investigation later... :)

graham, some kind of buffer overflow I think. The more code that 
is used in the toolbar, the fewer iterations it requires to crash 
REBOL. In my program it takes 10-20 iterations to crash it.

if this can't be cooked any further down, I'll RAMBO it.

done

does anyone have a fix for SCROLLER, so that scroller buttons don't 
move the scroller only one pixel at a time when the scrollbar is 
only slightly smaller than max size?

The STEP facet controls how much the scroll buttons change the data 
value.

view layout [scroller with [ratio: 0.9 step: 1 / 10]]

Here I set RATIO to 0.9 which represents 90% of the total data.

The calculation is     step = 1 / (total rows - visible rows)

In my scroll-table style, what I do when resizing is this:

 vscroll/ratio: rows / (1 + length? list-data) ; visible rows over 
 total
	vscroll/resize vscroll/size: (calculate new size here)
	; step = 1 / (total rows - visible rows)
	use [y][
		y: max 0 ((length? list-data) - rows)

  vscroll/step: either 0 = y [1][1 / y] ; prevent division by zero
	]

Don't be worried that the unit of my data is rows of text and not 
pixels, it should be the same calculation.
Just change: 
	total rows  (length? list-data)  -->  total height in pixels 
	visible rows  (rows)  --> visible height in pixels

I've studied the problem now, and it's the same algorithm as I use 
in LIST-VIEW, but it's defective and causes the scroller only to 
move 1-2 pixels at a time, when the list is only slightly larger 
than the visible area. I found a different solution which was not 
to trust the step at all and use LIST-VIEW's own function to move 
the list and scroller separately, i.e. the list position is not derived 
from the scroller anymore.