World: r3wp

Ok, I think we have lost one week or two of work here...

I will set the tested tickets to tested state in the next few days.

But, I think some tickets got lost, so please resubmit them if you 
don't see them in RAMBO.

is this a bug? (occurs in all core and view versions I have tried). 
 to-binary 23  returns the same as to-binary "23"  This is VERY non 
intuitive behaviour.

I think this is known. But, what are you expecting for to-integer 
23, considering that integers can be stored differently on different 
platforms.

?

I noticed that the library version of rebocalc.r doesn't display 
the COLUMN Letters, but puts them all at offset 100x20 which is the 
size of the cells, which somehow gets into the offset.

this started happening  .between 1225031 and 1226031 is the exact 
change

append pane make label [offset: xy text: char]   ;is where the problem 
is generated, but I don't yet see why.

xy is calculated to the right value, like 0x51 for "A" column label 
... but when the label is make'd the cellsize, 100x20 gets stuffed 
into the offset as well.

There was a discussion of this somewhere ......REBOL or REBOL2 worlds? 
And a solutiion found. I forget what it was.

The library version of Rebocalc has not been changed for several 
years:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/script-history.r?script-name=rebocalc.r
So the issue is a change in behaviour in REBOL/View

RAMBO #3526

ah, he just crammed it in there.  That could be done, but a patch, 
rather than a fix ... ;-/

Is there a place where the older change log (meaning back to View 
1.2.25.0.31 at least) is stored?

Thanks for finding it on RAMBO.

I've updated the script n REBOL.org....Also enabled it to run under 
the plugin:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/run-plugin.r?script-name=rebocalc.r

did it work for you?  I don't think that patch works.

It draws the headings for COLUMNS but not the cells...

It works for me under the plugin -- but that's an older version, 
so may not make any difference. Not tried the version that breaks 
the original script.

ah...wait...it does work..some other debug code in my script I was 
testing it in...I had isolated the same thing he did.

however, I think there is some underlying bug which needs to be fixed...

Agreed -- Could be 100s of scripts out there with the same problem.
Backward compatibility is important.

make label [offset: xy] ;seems like it should work.  I am making 
a tiny script to see how much is needed to repeat it.

(nice to see it run in the plug-in...neat demo for that)

Pretty much any View script should be able to run in the plugin.

REBOL.org doesn't  offer the plugin as a default . The script owner 
has to tell us explicity that it can run under the plugin:

    http://www.rebol.org/cgi-bin/cgiwrap/rebol/one-click-submission-help.r?help=plugin

anton: the behavior I was expecting is as follows:

to-binary integer! value -> binary of smallest possible byte size.
Example:
n: between 0 and 255
to-binary n -> single byte binary #{XX}
n: between 256 and 65535
to-binary n -> 2 byte binary #{XXXX}
n: between 65536 and 16777215
to-binary n -> 3 byte binary #{XXXXXX}
etc.

endianness is a factor - but that could be handled by a reverse could 
it not?

to-binary treats its input as a string -- not a number -- and converts 
each byte to it's hex ASCII respresentation  -- not ar all an intuitive 
meaning for to-binary.
Even worse, perhaps is
>> enbase/base "23" 2
== "0011001000110011"

which appears to have converted to binary. But, again, it's the ASCII 
for "2" and "3" not the binary for 23.

>> debase/base to-hex 23 16
== #{00000017}

i think that TO should handle this case though. it's very useful.

and if you need it in the platform's endianess, then you can just 
use a struct!

>> s: make struct! [val [integer!]] [0]
>> s/val: 23
== 23
>> third s
== #{17000000}

Doesn't look like there is a rambo ticket for this issue... want 
to create one?

Ladislav, I think your ticket about the GC bug with parse has been 
lost in the crash.

OK, will try to put it there again

i think i have set to tested almost all the bugs that were tested. 
please check the waiting for testing list again to make sure i didn't 
miss anything.

#3533 - think I marked it before. Tested OK on 2.5.57 under W2K.

#3560 - Tested OK on 2.5.57 under W2K.

Oops, that's a Linux bug. Sorry.

yep i have 3533 ok-ed from you already.

3436 has been changed too (now just throws a normal error) so will 
need testing again on the new build

Weird RAMBO behavior... Waiting for Approval shows one ticket with 
blank information.

(maybe Carl?)

you mean, "New submissions"?

both

it's a blank ticket submitted (i guess) because of an early click 
on the submit button

it should be delete but i can't do it

*deleted

with the new cores input does not work on my system. a knoppix 3.4/ct. 
i see cursor, but no chars are accepted. on nother linux it works. 
happens with rebols since the redicretion-change. has somebody seen 
that problem too, or have i messed up my system?

(linux, that is)

could it be a TERMCAP problem or something like that?