World: r3wp

Anton: good point, i think that the path loader could be more relaxed 
on 2nd to last slot.

Also if i always thought that this file/url paths are a little strange.

I'll make a RAMBO ticket then. Any objections?

None from me, but no one answered why peeps use site/whatever instead 
of join site {whatever}

Your question was ambiguous (ie. which way were you referring to 
- the first or second way?). Anyway, the answer is: "Less typing".

ah.. sorry lol

Posted the ticket.

I don't like this behaviour:
>> 2147483648
== 2147483648.0
I would prefer an integer!

me too. I wanted it for the EAN13 barcode generator

that can't be a signed integer

Apparently decimals have more precision or something:
>> 1234567890123
== 1234567890123.0
>> to-integer 1234567890123
** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value

more precision, and they remember the decimal point. and throw away 
the littlest digits.

Sorry Romano, I meant it to be negative. -2147483648 becomes a decimal! 
too. This is a problem for code that deals with flags etc. I have 
some code for FMOD and one of the flags uses the highest bit, but 
it gets loaded to a decimal! :-/  I do not wish to make a special 
test for that case. I wonder if this behaviour is really necessary, 
so I would like to make a wish report.

anton: i think that bug is on rambo already, posted by romano.

Anton you can use bitsets and to-binary bitset! to handle flags it 
should make your life easier.

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