SRL Archive - Discussions and Debates

We should stop using the type Byte when there is no explicit reason you should use it. Why?
Well there are 2 'bugs' with using Bytes.. First of all PascalScript (the interpreter inside SCAR&Simba) doesn't handle them too well.

When you add up 2 bytes, it will result a byte.. Even if you expect it to return an Integer.. See the following code:

program New;
var
  x,y : byte;
  z : integer;
begin
  x := 200;
  y := 100;
  z := x + y;
  writeln(inttostr(x+y));
  Writeln(inttostr(z));
end.

Second of all bytes cannot hold a negative number, which isn't a problem in most cases.. However, it's common for functions to return a negative number if the function fails. So when using a byte, this negative number will be translated into some semi-random positive number and therefore ruin your script.

Yes, I know that SRL wrongly uses Bytes in several places. I will try to change this accordingly when I've got some time.

Interesting. I never really saw the real use in using bytes in the first place, but at least now I know why not to use them. :p

The main problem is no standardization of SRL is set in place…

LongInt, Integers, Bytes, Cardinal… just tell us which to use and when.

From: Coh3n
Interesting. I never really saw the real use in using bytes in the first place, but at least now I know why not to use them. :p

I think it is an e-peen thingy…or maybe its cuz they sincerely believe that the tiny amount of memory that they save when they use it actually matters.

From: IceFire908
The main problem is no standardization of SRL is set in place…

LongInt, Integers, Bytes, Cardinal… just tell us which to use and when.

Longint and Integers are the same, Byte and Cardinal are differrent. Cardinal is an unsigned integer, and byte is an unsigned byte.

SO:
For any normal number you use Longint + Integer
For any number than may grow larger than a longint -but only a bit- and can't become negative you use Cardinal. (I can't think of any situation where this happens, except when you are using pointers, so just don't use them)
You don't use Bytes as the Intepreter can't handle them.

From: Wizzup?
Longint and Integers are the same, Byte and Cardinal are differrent. Cardinal is an unsigned integer, and byte is an unsigned byte.

SO:
For any normal number you use Longint + Integer
For any number than may grow larger than a longint -but only a bit- and can't become negative you use Cardinal. (I can't think of any situation where this happens, except when you are using pointers, so just don't use them)
You don't use Bytes as the Intepreter can't handle them.

That's pretty much whats been done so far. I've read the whole list of delphi numericals, not sure anyone fully understands how well any of them work in SCAR/simba.

We haven't really run into any problems regarding this as of now, so I'm curious as to what the sudden revelation is.

From: IceFire908
That's pretty much whats been done so far. I've read the whole list of delphi numericals, not sure anyone fully understands how well any of them work in SCAR/simba.

We haven't really run into any problems regarding this as of now, so I'm curious as to what the sudden revelation is.

Probably just to give a heads up so people don't break something over a bug in the interpreter. :D

From: IceFire908
That's pretty much whats been done so far. I've read the whole list of delphi numericals, not sure anyone fully understands how well any of them work in SCAR/simba.

We haven't really run into any problems regarding this as of now, so I'm curious as to what the sudden revelation is.

There are plenty of problems with Bytes in the interpreter. I think freddy filed a bug report about it several months ago, and he was simply told to use an Integer.
There is no ``sudden'' revelation, it's just the first time we seem to be able to carry of over the message clearly. Ray and I have been saying this for months, if not longer.

Also something in general: if you use a cardinal/word/byte for a loop, make sure you don't compare it with anything that can become negative (for instance "High").

From: Wizzup?
There are plenty of problems with Bytes in the interpreter. I think freddy filed a bug report about it several months ago, and he was simply told to use an Integer.
There is no ``sudden'' revelation, it's just the first time we seem to be able to carry of over the message clearly. Ray and I have been saying this for months, if not longer.

Seems pretty safe imo when doing small stuff when you are 100% it won't cause any problems.

From: IceFire908
Seems pretty safe imo when doing small stuff when you are 100% it won't cause any problems.

I don't see how this related this to my post? What are saying is safe?

From: Wizzup?
I don't see how this related this to my post? What are saying is safe?

Dunno, I just think there's nothing wrong with using byte if you are sure it's not going to cause any problems.

for example

var
  I: Byte;
begin
  for I := 0 to 10 do
    WriteLn('Warning');
end;

Yeah, but Bytes do cause problems in for loops IIRC. And it really makes no sense to use a Byte there. Why not use an integer?

Int64 all the way

U are free to use Bytes, and said in my post if you are absolutely sure it won't do harm, please go ahead use them.. My advice is just to leaven them, as they may not behave the way you expect them to behave.

Since SCARring doesn't take much memory anyways, why do we stick with explicit type declaration? Why can't we do away with it altogether and be simple like PHP?

Not that I have anything against declaring variables, but I think that micromanagement of memory can be left to more memory intensive applications…

Here is results from running mastaraymond's Test Script with Scar and Simba.


Scar:

[PHP]Successfully compiled (93 ms)
300
300
Successfully executed[/PHP]


Simba:

[PHP]Compiled succesfully in 47 ms.
44
44
Successfully executed.[/PHP]


Why the results are so different :S


~Home :)

From: Home
Here is results from running mastaraymond's Test Script with Scar and Simba.


Scar:

[PHP]Successfully compiled (93 ms)
300
300
Successfully executed[/PHP]


Simba:

[PHP]Compiled succesfully in 47 ms.
44
44
Successfully executed.[/PHP]


Why the results are so different :S


~Home :)

No clue why SCAR behaves correct, according to this thread it shouldn't:
http://forums.remobjects.com/default.aspx?g=posts&t=421216

program new;
var
  B: byte;
begin
  WriteLn('Lowest Byte Value = ' + IntToStr(Low(B)));
  WriteLn('Highest Byte Value = ' + IntToStr(High(B)));
end.

Simba:

Compiled succesfully in 20 ms.
Lowest Byte Value = 0
Highest Byte Value = 255
Successfully executed.

SCAR:

Successfully compiled (111 ms)
Lowest Byte Value = 0
Highest Byte Value = 255
Successfully executed

Weird SCAR can add bytes past 255 o.O

Shouldn't a 8bit byte only go from 0 to 255?

No idea why SCAR and Simba behave differently in the above situation. Maybe SCAR copies the whole (32-bit) result register, as opposed to the low 8 bits that were used in the calculations (because both the integer and writeln request 32 bits, iirc)? The overflow in to the high 8 bits is what Simba is ignoring, so Simba probably only keeps the low 8 bits.

Conclusion (without looking at any of the underlying code; take it worth a grain of salt): SCAR does an implicit type cast on the byte operation to change it to an Integer temporarily, whereas Simba keeps the Byte type throughout the statement. Or, it could simply be a glitch with how SCAR is compiled. I'm not going to try and pull down the stoof that SCAR compiles my programs in to. :P

SCAR uses an ancient version of the interpreter, afaik.