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

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Rebolek
19-Apr-2006
[1671]
I'm afraid there isn't. This is same as the "comma bug"

>> parse [.]['.]
== true
>> parse [,][',]
** Syntax Error: Invalid word -- ,
** Near: (line 1) parse [,][',]
Pekr
19-Apr-2006
[1672]
it seems 'parse needs some overhaul?
Ladislav
19-Apr-2006
[1673x9]
this is the way: parse [/] [set w word! (nx: unless w = first [/] 
[[end skip]]) nx]
the same way can be used for [.]
(but is is not very elegant, I admit)
hmm, the situation with comma *can* be handled this way too, but 
comma normally isn't a REBOL word
yet another word of this kind: '<>
and '<
and '>=
another "problem":
>> first [<]
** Syntax Error: Invalid tag -- <
** Near: (line 1) first [<]
>> first [< ]
== <
PeterWood
19-Apr-2006
[1682x2]
I reported that the interpreter doesn't accept get-wrods startting 
with < (#3641)
get-words !!
Gregg
19-Apr-2006
[1684]
>> lit-slash: to lit-word! "/"
== '/
>> parse [/] [lit-slash]
== true
Chris
19-Apr-2006
[1685x2]
>> first [< ]
== <
Sorry, I came across this recently too...
Ladislav
19-Apr-2006
[1687]
thanks, Gregg, that looks more readable
Gabriele
20-Apr-2006
[1688]
I use to lit-word! "/" too, it's the best way.
JaimeVargas
20-Apr-2006
[1689x2]
I guess there is a problem with rebol loader, because it needs quoting 
of some "special" chars.
The rebol parser should understand '/ and not required to-litword! 
"/", specially when the latter is a valid expression.
eFishAnt
29-Apr-2006
[1691]
Gab or some RAMBO editor, can you update RAMBO ticket #4087

there is a workaround from Edgar which is to so system/ports/serial: 
[ttyS0 ttyS1] to patch the ubuntu port of REBOL.  I suspect that 
can be done in a future release for ubuntu, but at least for now 
I have a workaround.
Gabriele
30-Apr-2006
[1692]
done.
Anton
2-May-2006
[1693x2]
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
			]
		]
	]
]
Gabriele
2-May-2006
[1695]
happens only with iteration?
Anton
2-May-2006
[1696x4]
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.)
Anton
3-May-2006
[1700x3]
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.
ChristianE
3-May-2006
[1703x4]
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]]]
Cyphre
3-May-2006
[1707x2]
Anton: it looks like a bug to me.
ChristianE: put it into RAMBO please.
Ladislav
13-May-2006
[1709x9]
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
Anton
13-May-2006
[1718x3]
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