World: r4wp

I thought it worked without an account. But I haven't been logged 
out for a long time

I don't know if I am using it correctly but I attempted to run the 
build.r file (w/o any arguments...I think it builds the "eval.red"). 
I end up with:
Signing apk...
'jarsigner' is not recognized as an internal or external command,
operable program or batch file.
Aligning apk...
Unable to open 'builds\eval-signed.apk' as zip archive

It should have downloaded the jarsigner and other tools

Do you have a JDK installed?

Interesting, the lines for downloading that are commented out. I 
will try it again. I do have the JDK installed as I was doing some 
driod app stuff a while back.

Seems a mistake

Wonder how it worked for Petr

Getting closer. I now have jarsigner but the cmd expected to see 
it in the root dir. So I just placed jarsigner there along with the 
jli.dll.  That may not be a good idea because it seems to do its 
thing but finally dies with:
Signing apk...

Error: Could not find or load main class sun.security.tools.JarSigner
Aligning apk...
Unable to open 'builds\eval-signed.apk' as zip archive

Looks like Doc and Petr had jarsigner already installed with their 
tool suite

At this point I am stuck on the sun.security.tools.JarSigner file 
issue.

OK.  Next enigma about Red/System that I ran into.  Consider the 
two following sets of code and output.  Why are they different?

Code 1:
	im1: as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

 print-line as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

Output 1:
...
96
99
107
111
105
104
100
99
100
98

Code 2:
	im1: as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))
	print-line im1

Output 2:
...
4260192
4260451
4260203
4260207
4259945
4259944
4259940
4260451
4260196
4260194

The example is not complete. How do you get more than one value?

This is a loop that processes raw binary image data.  'r, 'g, and 
'b are incremented through an 'until loop until the data is all consumed.

But what is troubling to me is that

print-line im1

is not equal to


print-line as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

They should be equivalent.

It could be a Red/System bug, or it could be a result of the code 
you're not showing. Can't tell

Are you doing this on the Raspberry? Doc recently made fixes to the 
ARM code emitter. It was less mature than the x86 emitter

I am running this on Windows currently.  XP 32-bit.  Here's the complete 
code:

#include #../C-library/ANSI.reds

img1: as-binary 0
size1: 0

img1: read-file-binary "img1.bin" :size1

i: 0
r: 0
g: 0
b: 0
im1: 0
until [
	r: i + 2
	g: i + 3
	b: i + 4
	im1: as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

 print-line im1 ;as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b 
 / 3))
	i: i + 4
	i >= size1
]

If I change the line


 print-line im1 ;as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b 
 / 3))

to


 print-line as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

I get the expected output.

It could be caused by differences in the auto-casting between a simple 
assignment and a call to print-line.

Being conservative I would have written:


im1: (((as integer img1/r ) / 3) + (as integer img1/g) / 3) + (as 
integer img1/b) / 3)

plus one more ) at the end :-)

I already tried that and got an error from the compiler saying that 
there was an unnecessary cast from integer to integer.

*** Warning: type casting from integer! to integer! is not necessary

It would then exit.

What type is img1/r ?

img1 is binary (or byte!) I suppose.

img1 is a pointer to an array of those bytes, I should have said.

The addition can't result in more than a byte, so it should be no 
problem to do it with bytes

I just can't see how the output I'm seeing is not a bug.  I was hoping 
you could explain it.

But it seems as the compiler thinks that img/r is an integer!

Yes, it looks like a bug

Agreed.

Could it be a problem that I'm type casting im1 to an integer in 
the line

	im: 0

??

Forget it, that can't be the problem.

That's not a cast, just an assignment

I thought maybe the type was cast by the value you assigned to it.

Declared, but not cast, because it wasn't known yet

The problem I'm trying to solve is to convert two seperate images 
to grayscale and then compare the pixels in each image to each other 
to look for big variations in contrast between the pixels.

You did upgrade your Red/System, didn't you?

If I can't assign the answer of a calculation to a word and then 
use that word in other calculations, then it's a roadblock that I'm 
not sure how to overcome.

Yes, I updated Red/System yesterday from Github.

I found many such bugs in the past, so I would like to think they're 
gone, but it looks like you found another :-)

Doc doesn't do many byte manipulations, so it's up to us to test 
them

OK.  Curecode doesn't work for me for some reason, so how do I submit 
this bug?

Red is not in Curecode. The tracker is on GitHub

OK. I'll enter it there.

The calculation is okay.

Code:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + (as integer! green) + (as integer! 
blue)

print [greyscale lf]

OUTPUT:
-= Red/System Compiler =- 
Compiling /Users/peter/VMShare/Code/Red-System/test.reds ...
Script: "Red/System IA-32 code emitter" (none)
Script: "Red/System Mach-O format emitter" (none)

...compilation time:     122 ms
...linking time:         10 ms
...output file size:     16384 bytes
...output file name:     builds/test
260

It may be an issue with the dereferencing.

Could you try by assigning img1/r etc to temporary variables.

Oops, here's the proper code and correct answer:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + ((as integer! green) / 3) + 
((as integer! blue) / 3)

print [greyscale lf]

OUTPUT
...compilation time:     133 ms
...linking time:         13 ms
...output file size:     16384 bytes
...output file name:     builds/test
140

Your immediate problem should be solved if you do