World: r3wp

it is not a wish it is a bug :-)

romano, which one?

- 2147483648

indeed, 3646 is a bug, not a wish.

A work-around!?
>> i: -2147483647
== -2147483647
>> i: i - 1
== -2147483648
>> type? i
== integer!

Yeah, I know there's workarounds, but I don't wish to have to use 
them.

Gabriele: mmm, it is not stated quite the same. Romano's bug report 
#3646 asks for an overflow error (and I agree), but I want that when 
-2147483648 is loaded it should remain an integer!  (It looks that 
Romano agrees with me.) Could that be added to the report ?

hmm, yes, and there's #3520 which is about the same issue but not 
exactly worded as you wish. well, let's just make a new ticket and 
reference #3646 and #3520 in it.

My bug about -2147483648 is more old, is 3099 and is set as "Done" 
also if it is not done or it is done in the wrong way.

that a bug from the rebol-view altme tracker... i guess it was misunderstood.

Yes, I think #3099 was misunderstood, and this is the report that 
agrees most with me. It should be changed from "Done" to "Issue"/"Bug".

who's car will I have to wash to get a RAMBO account? :-)

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).

couple of obvious and annoying ones in makedoc2.r. ahh... seems like 
I can

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.

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.

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

yes, upper than

4 values color tupples don't works with official version

Yes, but should work with AGG ones

I use a workaround, putting all text display last in draw block

Q: what result does "pen none" give ? Transparent color, or no drawing 
!

it does draw, with black color in this case

For the first box or the second ?

only the second

And the first ?

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

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

print rejoin [" " "whatever" " "] ;   ;)

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.

No real argument from me, though, since I don't know and have never 
used 'form or simply printed blocks

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 ?

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 ...

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

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

I am guessing the logic behind FORM is that it changes mode at the 
first non-empty string.

Basically what I tried to say but couldn't type correctly  ;)