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

Henrik
14-Mar-2005
[277]
who's car will I have to wash to get a RAMBO account? :-)
Anton
14-Mar-2005
[278]
Do you want to submit a bug ? I'm pretty sure you don't need an account 
to do that (although it *looks* like you do).
Henrik
14-Mar-2005
[279]
couple of obvious and annoying ones in makedoc2.r. ahh... seems like 
I can
Anton
14-Mar-2005
[280]
You should usually search the rambo database to see if it hasn't 
been submitted already, and also check here before submitting, unless 
you are really pressed for time.
Vincent
17-Mar-2005
[281]
I have problems with draw block in betas > 1.2.48:

draw [pen none box 0x0 100x20 pen 0.0.0 text 2x2 "hi!" pen none box 
0x21 100x40]

second box border isn't transparent. It seems that drawing text with 
a non-invisible pen override any future invisible pen color setting.
DideC
17-Mar-2005
[282]
Version > 1.2.48
 does it mean "version upper than 1.2.48" ?
It mean AGG inside so!! It's alpha, with many bugs arround.

Try with a tupple of 4 value with max alpha value :
pen 0.0.0.255
Vincent
17-Mar-2005
[283x2]
yes, upper than
4 values color tupples don't works with official version
DideC
17-Mar-2005
[285]
Yes, but should work with AGG ones
Vincent
17-Mar-2005
[286]
I use a workaround, putting all text display last in draw block
DideC
17-Mar-2005
[287]
Q: what result does "pen none" give ? Transparent color, or no drawing 
!
Vincent
17-Mar-2005
[288]
it does draw, with black color in this case
DideC
17-Mar-2005
[289]
For the first box or the second ?
Vincent
17-Mar-2005
[290]
only the second
DideC
17-Mar-2005
[291]
And the first ?
Vincent
17-Mar-2005
[292x5]
the first is transparent

'text seem to affect pen selection: if I change 'text location, it's 
after 'text this problem happens
('text location in draw block)
I tried to make a face with text and invisible boxes
the boxes colors are changed at runtime
it's a draw version of 'textlist
Anton
18-Mar-2005
[297x6]
s1: make struct! [] none
s2: make struct! [] none
same? s1 s2
;== none  ; (expected false)
same? s1 s1
;== none  ; (expected true)
blk: reduce [s1]
;== [make struct! [] []]
find blk s2
;== [make struct! [] []]  ; (expected none)
equal? s1 s2

;== none  ; (are struct! comparable like string! (expect true) or 
incomparable like object!  (expect false) ?)
Doesn't look like this bug is in rambo database. I should submit 
a bug. Any complaints?
Here's a more difficult one - FORM.
I always guessed that PRINT uses FORM internally:
print ["" "hello"]
;hello
print [" " "hello"]
;  hello    ; <--- 2 leading spaces
form ["" "hello"]
;== "hello"
form [" " "hello"]
;== "  hello"  ; <--- 2 leading spaces
Isn't that kind of inconsistant ? You have a choice of 0 or 2+.  
How do you get just 1 leading space ?
Furthermore:
prin ["" "hello" ""] print "."
;hello .   ; <---- 1 traling space
form ["" "hello" ""]
;== "hello "   ; <--- 1 trailing space
Izkata
18-Mar-2005
[303]
print rejoin [" " "whatever" " "] ;   ;)
Anton
18-Mar-2005
[304x2]
The inconsistency is also between empty strings which are in first 
position or a later position in the block.
Yes, Izkata, I am well aware of that workaround.
Izkata
18-Mar-2005
[306]
No real argument from me, though, since I don't know and have never 
used 'form or simply printed blocks
Anton
18-Mar-2005
[307x2]
However, I keep bumping into this problem and so it wastes my time 
continually. I also imagine it's a small confusion for beginners.
So, I would like:
print ["" "hello"]
; hello  ; <---- 1 leading space
form ["" "hello"]
;== " hello"  ; <--- 1 leading space
form ["" "hello" ""]
;== " hello "  ; <--- 1 leading and 1 trailing space
And similar results for PRINT.
Anyone have any objections ?
Pekr
18-Mar-2005
[309]
Anton - how can you produce space without actually providing a space? 
;-) "" is empty string. Even 'empty? tells you so ... it can't add 
space by some magis, just only because it is used in a  block or 
form ...
Anton
18-Mar-2005
[310x3]
FORM puts a space between all items in the block when it is joining 
them together, even items which are empty strings - *except* if it 
is the first item.
You should read my examples more carefully.
Well now, that is not always true either !
form [{} {} {} {} {}] ; a whole bunch of empty strings
;== ""  ; <--- empty string
form [{} {a} {} {} {}] ; one character added
;== "a   "  ; <--- three trailing spaces
Izkata
18-Mar-2005
[313]
Perhaps form is just waiting until there's a value before it adds 
stuff?
>> form [{} {} {} {Hi} {} {}]
== "Hi  " ;2 spaces, and only after string w/value found
>> form [{} {} {} {Hi} {} {} {Hi} {}]
== "Hi   Hi " ;2 spaces and 1 space..


But yes, there probably ought to be a space in fron like you said 
before.  If the behavoir I think is happening, then 'trim should 
just be used, not letting it be automatic
Anton
18-Mar-2005
[314]
I am guessing the logic behind FORM is that it changes mode at the 
first non-empty string.
Izkata
18-Mar-2005
[315]
Basically what I tried to say but couldn't type correctly  ;)
Pekr
18-Mar-2005
[316]
Anton - it does not matter imo. It is design of 'form or 'print, 
that those add spaces between chars, but once you put empty string 
into block, it is value, and the value is empty string, so it is 
imo incorrect to want it represent space
Anton
18-Mar-2005
[317x2]
Read my comment above.
Pekr, look at this example. There are five items in the block (some 
are empty strings). So I expect five items to be separated by four 
spaces. 
form ["" 1 "" 2 ""] 

;== "1  2 "     ; <<<< but I count only three spaces in the result
Anton
20-Mar-2005
[319x2]
Gabriele, I see #3455 and #3576 are basically identical. I think 
#3576 is more accurate, so older #3455 should be removed.
Ok, submitted a report for the struct! comparison bugs above.
Anton
21-Mar-2005
[321x5]
Undecided about FORM....
Here's another bug:

BUG: using DETECT (instead of ENGAGE) is unreliable with stopping 
time events, as in this example:
lay: layout [btn "start" [lay/rate: 1 show lay] btn "stop" [lay/rate: 
none show lay]] lay/feel: make lay/feel [detect: func [face event][if 
event/type = 'time [print ['tick now/precise lay/rate]] event]] view 
lay
p: open http://www.rebol.com
close p
view lay
If you paste the above code straight into your console, the problem 
is present in the first VIEW as well as the second VIEW.

If you type/paste each line individually into your console, the problem 
is only present after the network access.

Once a console has the problem, it remains "contaminated", and you 
will need to open another console to continue testing.
Testing on REBOL/View 1.2.57.3.1e
Gabriele
21-Mar-2005
[326]
Anton: I have no idea if the FORM behavior is intentional or a bug. 
about detect: maybe the difference is due to copy&paste?