World: r3wp

done.

I've got an interesting bug:  If you enable the outer detect, the 
inner detect receives a face object to its EVENT argument. Weird.

view layout [
	face with [ 
		init: [
			size: 600x400

			pane: layout [
				my-list: list 600x400 [
					my-text: text 600 feel [
						detect: func [face event][
							print ["inner -" mold type? event]
							event
						]
					]
				] data [["hello"]["there"]]
			] 

		] 

		feel: make face/feel [
			detect: func [face event][
				print ["outer -" mold type? event]
				event
			]
		]
	]
]

happens only with iteration?

I have to spend some more time stripping it down, removing layouts 
and list etc.. but can anyone see anything wrong ?

I think so.

Oh, by the way, you need to put your mouse over the text for any 
events to be sent to the inner text face, in order to see the bug.

(I spent six hours isolating this from my enormous scroll-table style, 
so don't be mad at me for too much code right now.)

The code is bigger, but I've removed both instances of layout, and 
still showing the bug:

it-face: make face [
	size: 200x20 
	offset: 20x20
	text: "iterated face"
	feel: make feel [
		detect: func [face event][
			print ["inner -" mold type? event]
			event
		]
	]
]

append system/view/screen-face/pane make face [
	size: 400x400
	pane: make face [
		size: 400x400
		color: gray
		pane: func [face index][
			either integer? index [
				if index < 10 [
					it-face/offset/y: index * 21
					return it-face
				]
			][
				return to-integer index/y - 21 / 21 + 1
			]
		] 

		feel: make feel [
			detect: func [face event][
				print ["outer -" mold type? event]
				event
			]
		]
	]
]
show system/view/screen-face
do-events

It's really bizarre. If you comment the bottom "outer" detect, or 
move it to the window feel, the inner detect starts receiving events 
again normally.

Is this a known issue? LINEAR in the draw dialect's FILL-PEN command 
seems to be case-sensitive, it throws an error if given in uppercase:

view layout [box 100x100 effect [draw [fill-pen LINEAR 0x0 0 99 90 
1 1 white gold red box 0x0 99x99]]]

Whereas "linear" works:

view layout [box 100x100 effect [draw [fill-pen linear 0x0 0 99 90 
1 1 white gold red box 0x0 99x99]]]

Anton: it looks like a bug to me.

ChristianE: put it into RAMBO please.

Should I put these to RAMBO or not? (question for Gabriele):

Use and word:

>> same? 'a first use 'a [['a]]
== true

Use and get-word:

>> same? 'a first use [:a] [['a]]
== true

Use and lit-word:

>> same? 'a first use ['a] [[a]]
== true

Reformulation:

Use and word:

>> same? 'a use 'a ['a]
== true

Use and get-word:

>> same? 'a use [:a] ['a]
== true

Use and lit-word:

>> same? 'a first use ['a] ['a]
== true

sorry: Use and lit-word:

>> same? 'a use ['a] ['a]
== true

Not following closely, but it seems to me you can't rely on SAME? 
when both words are unset (it's comparing null pointers internally, 
I suppose). Maybe you should also check that the word is set ? eg:

word1: 'a
word2: first use 'a [[a]]
if all [not value? word1  same? word1 word2]["sameness unknown"]

Oh, I see you are concentrating on USE.
>> use 'a [a: 123]
== 123
>> a   ; <--- word in global context
== 123  ; <-- supposed to be still unset

Looks like a bug to me.

Ladislav, yes add it please. i remember seeing a report about this 
but maybe it never got into rambo.

the above quirks posted to Rambo

I just posted a RAMBO entry (currently #-663), accidently before 
I was finished writing it. There are errors. What do I do?

I got the example code wrong, and the description should have referenced 
an older RAMBO entry (3575) that was wrongly prioritized.

I backed up, fixed it and resubmitted. Whoever is watching RAMBO, 
please disregard #-663, it is superceded by #-664.

done.

;Little bug in formatting, worth a ticket?
probe [
 0
]
probe [
 12
]
==
[0
]
[
    12
]

got this error from a rebol process launched by another rebol process 
running uniserve:

dyld: Library not loaded: /usr/lib/libncurses.5.4.dylib
Referenced 
from: /bin/bash
Reason: image not found
*** Boot Error 951
What may that Boot Error 951 be?

This is probably the shortest code which shows the bug:

img: copy help.gif
equal? img help.gif
view layout [image img effect [key 128]]
equal? img help.gif

OK - submitted to RAMBO.

dear all, does anyone have an idea about  "Boot Error 951" mentioned 
above? Is it a rebol initialization problem? Maybe betwen rebol process 
and its dns resolving brother process?
..or is it more related to uniserve code? thx

Will, see if this helps
http://www.mail-archive.com/[list-:-rebol-:-com]/msg06327.html

thank you Anton, but /usr/lib/libncurses.5.4.dylib does exist! After 
a while rebol process launched by main uniserve process show this 
error and then rebol seams to loose ability to read/write files, 
restarting brings everything back to normal,

*** Boot Error 951

 is this a rebol error that should not happen or is it a programming 
 error?

This is a rebol error message - "*** Boot Error %d" appears in a 
recent rebview.exe - but I think the error code 951 is being passed 
to rebol from an OS call.

I think this question should be asked and discussed in the Uniserve 
group until Uniserve is eliminated as a possible cause.

re #4116 - the same bug happens even via ODBC Oracle driver. So maybe 
Oracle driver is just a wrapper to ODBC? My suspicion is, that result 
of such query is non-standard, it is returned to the pipe, and rebol 
crashes by trying to parse it. Just a wild speculation though ...

simplification for above ticket -  "begin my_proc; end;" crashes 
rebol. Never mind, lost the case for php anyway ...

OT: Is there are Rebol based RAMBO editor available that works on 
the web version's database?