World: r3wp

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?

if you open console://, can you get anything out of it?

No. wait or first just hang.

do not know about termcap

is anyone able to reproduce it? i'm sure that if we can let Carl 
reproduce this he will fix it.

I've tried the recent linux alpha on Fedora Core 2 (redhat) and it 
works great - seems to be a debian base issue - has anyone tried 
it on a sarge build?  I've tested an old woody build and a new woody 
build with the same hang result.

what could be different in Debian?

[I hate these kind of things: there's so much (useless) complexity 
underneath that you have no idea why something is not working]

could be a different glibc version or sommit like that

could you try an STRACE on both Debian and Fedora to see what's really 
different?

gabriele: will do later today