Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bruceuncle]

Obviously I would never think of making any demands on your schedule

Just take any disparaging comments as "tongue in cheek" 

Having seen how much easier it is to move around file selectors in some other apps, I can appreciate what you're asking for.  The AMOS Pro file selector is common to both the language itself and anything else that cares to use it.  So it would work across the board (I can't really see anyone writing an alternative as it involves a lot of the dreaded DBL code  - maybe I would, always the masochist).

I'd also like to get both it and the editor to respond to a mouse wheel!  AMOS gives me keycodes for a mouse wheel but fitting them in is a little tricky, especially in the editor.  I'm hoping to try and sneak that one under the nose of the "no enhancements" rule for V2.10 (like the chromacoding for the Help display  ).

[Lonewolf10]

Having seen how much easier it is to move around file selectors in some other apps, I can appreciate what you're asking for.  The AMOS Pro file selector is common to both the language itself and anything else that cares to use it.  So it would work across the board (I can't really see anyone writing an alternative as it involves a lot of the dreaded DBL code  - maybe I would, always the masochist).

Hehe, I wrote my own file selector in AMOS which I have used ever since I wrote it. It isn't terrible fast (especially with directories containing 100+ files) and is obviously quite memory hungry, but it works. I have plans to give it and overhaul sometime as there are a few enhancements that would be it even better...

If anyone would like to see the code, just let me know.

[Lonewolf10]

I may have stumbled on another bug today (I'm trying to write a program to convert data into an IFF image, that I can later convert into PNG image for even better compression ) in AMOS Pro 2.00:

Code: [Select]

_DATA=130
IF _DATA and $40=64 then Print "1"; Else Print "0";

Always results in "1" being printed on the screen. Is this a bug or am I doing something silly???

Code: [Select]

_DATA=130
_DAT64=_DATA and $40
If _DAT64=64 then Print "1"; Else Print "0";

Works fine, but is uglier...

[bruceuncle]

I may have stumbled on another bug today (I'm trying to write a program to convert data into an IFF image, that I can later convert into PNG image for even better compression ) in AMOS Pro 2.00:

_DATA=130
IF _DATA and $40=64 then Print "1"; Else Print "0";

Always results in "1" being printed on the screen. Is this a bug or am I doing something silly???

_DATA=130
_DAT64=_DATA and $40
If _DAT64=64 then Print "1"; Else Print "0";

Works fine, but is uglier...

No, not a bug.  You've just fallen foul to the rules of "operator precedence".

What's happening is that the $40=64 is evaluated before the and.  So it evaluates as if written _DATA and ($40=64).  The equality operator (=) takes precedence over the logical operator (and).  To fix it, just write it as (_DATA and $40)=64.  And no, it's not silly  .  I've fallen for similar errors myself many times.  Different languages sometimes use slightly different operator precedence rules.  So, these days , I get so paranoid about operator precedence in complex expressions that I tend to go too far with the brackets! 

[Lonewolf10]

Bah!

I don't use brackets that often and didn't even think about it.
Thanks for the help, and glad it's not a bug
(PS. the program is almost finished, just need to add the ability to load in external files )

[DiskJuggler]

Hello mates,
i'm new here so please be gentle.

I recently started coding with AmosPro/Compiler (again) and came across a really hard to trace bug. It appears to be some kind of memory trash or something. Even the compiled executable has it.

I try to describe what is happening.
Sometimes, when entering a procedure, a local variable used for loops is pre-set with a random(?) number, so the inside of the ForNext-loop will fail, as described in the buglist above (it is always executed once).
I tried to make sure the variable is not GLOBAL or SHARED and even set it to =0. But then the Error is happening somwhere else, another variable (even GLOBAL ones) are set to e.g. =0.
Sometimes it results in "illegal ...." something something, sometimes it is a different error, like calling screen open with 0 as width, obviously.
I attached a picture of a Monitor screenshot.

Is this memory corruption, IF it is that, a known bug?

[SamuraiCrow]

Hello mates,
i'm new here so please be gentle.

I recently started coding with AmosPro/Compiler (again) and came across a really hard to trace bug. It appears to be some kind of memory trash or something. Even the compiled executable has it.

I try to describe what is happening.
Sometimes, when entering a procedure, a local variable used for loops is pre-set with a random(?) number, so the inside of the ForNext-loop will fail, as described in the buglist above (it is always executed once).
I tried to make sure the variable is not GLOBAL or SHARED and even set it to =0. But then the Error is happening somwhere else, another variable (even GLOBAL ones) are set to e.g. =0.
Sometimes it results in "illegal ...." something something, sometimes it is a different error, like calling screen open with 0 as width, obviously.
I attached a picture of a Monitor screenshot.

Is this memory corruption, IF it is that, a known bug?

It looks like your variable is getting overwritten by another task or the blitter.  Local variables are stored on the parameter stack.  Are you using any unknown codes or do you have any unusual extension installed that might not be fully debugged?

[DiskJuggler]

I don't know.
i have
AmosPro Music Extension v2.00,
AmosPro Picture Compactor v2.00,
AmosPro Requester v2.00,
AmosPro Compiler extension v2.00,
AmosPro IO Devices Extension v2.00,
TOME v4.24Plus,
AmosPro AMCAF extension v1.50Beta4 11-jan-98,
Amos Pro Club Extension v2.9Plus
installed. No idea, what all these are doing.

[DiskJuggler]

I just checked again and there was a short moment, where i got a "out of buffer" something displayed in red at the top.

I have Set Buffer 200 in the Code. That is 200kB, isn't it enough?

[SamuraiCrow]

I just checked again and there was a short moment, where i got a "out of buffer" something displayed in red at the top.

I have Set Buffer 200 in the Code. That is 200kB, isn't it enough?

I'm pretty sure that's 200 bytes.  Try 65536 for 64k buffer.

[DiskJuggler]

Help says 'Set Buffer kilobytes' 1024 bytes?

[SamuraiCrow]

Help says 'Set Buffer kilobytes' 1024 bytes?

Ok, the scanned manual also says kBytes.  Is the Set Buffer command the first in your program?  http://www.ultimateamiga.co.uk/HostedProjects/AMOSFactory/AMOSProManual/5/504.html

[adrazar]

I just checked again and there was a short moment, where i got a "out of buffer" something displayed in red at the top.

I have Set Buffer 200 in the Code. That is 200kB, isn't it enough?

I think 200 is a very large number for Set Buffer, but it makes sense if you use big arrays.

The strange result from the monitor session could perhaps be explained by the monitor itself being somewhat unstable (at least that's what I experience from time to time). I would try inserting some print statements where the errors occur and run the program normally to see what happens.

[DiskJuggler]

The problem is at runtime i use screens but i would like to print to the cli console. how can i do this?

[SamuraiCrow]

Writing to the CLI console requires an extension.  Otherwise you could open a console window of your own using file handling commands.