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
9-Mar-2005
[259]
me too. I wanted it for the EAN13 barcode generator
Romano
9-Mar-2005
[260]
that can't be a signed integer
Izkata
9-Mar-2005
[261]
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
Volker
10-Mar-2005
[262]
more precision, and they remember the decimal point. and throw away 
the littlest digits.
Anton
10-Mar-2005
[263]
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.
Gabriele
10-Mar-2005
[264]
anton: i think that bug is on rambo already, posted by romano.
JaimeVargas
10-Mar-2005
[265]
Anton you can use bitsets and to-binary bitset! to handle flags it 
should make your life easier.
Romano
10-Mar-2005
[266]
it is not a wish it is a bug :-)
Gabriele
10-Mar-2005
[267]
romano, which one?
Romano
10-Mar-2005
[268]
- 2147483648
Gabriele
10-Mar-2005
[269]
indeed, 3646 is a bug, not a wish.
Geomol
10-Mar-2005
[270]
A work-around!?
>> i: -2147483647
== -2147483647
>> i: i - 1
== -2147483648
>> type? i
== integer!
Anton
10-Mar-2005
[271x2]
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 ?
Gabriele
11-Mar-2005
[273]
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.
Romano
11-Mar-2005
[274]
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.
Gabriele
11-Mar-2005
[275]
that a bug from the rebol-view altme tracker... i guess it was misunderstood.
Anton
13-Mar-2005
[276]
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".
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 ?