Print

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

[Lonewolf10]

I have installed AMOSPro TURBO Plus Extension V 2.15 and successfully compiled the "F_Plot_Starfield.AMOS" file from the editor.

However, after copying across the "AMOSPro_Interpreter_Config" file in to the "Compiler/s/" folder and adding the "AMOSPro_TURBO_Plus.Lib" file into "Compiler/APSystem/" folder I get the same error you get ("Extension not loaded at line: xx").
This is probably why I always compiled from the editor, as I never got the standalone compiler to work with 3rd-party libraries (extensions).

[gibs]

Thanks Lonewolf.
Since the beginning I don't understand what you mean when you say : "Compiler/s/" because I only have a directory named "Compiler" which is inside "AmosPro" directory.
So I thought you were talking about the Floppy "Compiler" directory "S" in the Amiga world I thought you were talking about : "Compiler:S".

I did the HD installation. So I have the "AmosPro" directory in DH0:

What are thou talking about when you say "Compiler/s/"

Thanks again.

[gibs]

I have re-installed the Compiler, and now I can compile with the Turbo Extension.

Unfortunately I didn't found the reason of the issue, but at least it's working.

Note that I had the same problem on 3 different Amiga hard drive. I would have give up if you were not here. Thank you all.

Note: If you have "PowerBobs Registered" it's welcome I tried to contact the author on Linkdin but I wasn't able to send him a message. I failed (seems that you can't send a message if you don't know the person, if you don't have its email).

[Lonewolf10]

Thanks Lonewolf.
Since the beginning I don't understand what you mean when you say : "Compiler/s/" because I only have a directory named "Compiler" which is inside "AmosPro" directory.
So I thought you were talking about the Floppy "Compiler" directory "S" in the Amiga world I thought you were talking about : "Compiler:S".

I did the HD installation. So I have the "AmosPro" directory in DH0:

What are thou talking about when you say "Compiler/s/"

Thanks again.

It seems we have 2 different setups. As I use an emulated Amiga (WinUAE on my laptop) I guess I must have created an alternate setup for AMOS Pro. I have a version of the Compiler separate to the editor (along with the program source - Compiler_Shell.AMOS), though looking at the editor, I see that some of the compiler files are part of the editors setup.

I have used multiple versions of AMOS over the years, starting with AMOS BASIC, AMOS Pro 1 and now AMOS Pro 2. Somewhere along the line the mix-up must have occured.
Either way your issue is now fixed

I have PowerBobs V1.0, but that should be the same one that is available to download from the downloads section on here (link at the top of the page if you are signed in).

[bruceuncle]

Hmmm.  I'm still not convinced that there's nothing wrong with the extension. 
Why is gibs able to compile without it but it fails when the extension is loaded?

Then again, the following descriptions may throw some light on it...

Hello,
You are talking about the "AMOSPro_Interpreter_Config" file which is located is S:

Yes. Make sure that the above named file is the same for both the editor and the compiler. The easiest way is to carefully copy it from "AMOSPro/S/" to "Compiler/s/". If you want to be safe rename "Compiler/s/AMOSPro_Interpreter_Config" to something else (e.g. "old_Interpreter_Config"), just incase something goes wrong.

I hope this helps. It is frustrating spending ages coding something and then finding that it won't compile.

The *_Config files work like this:

AMOSPro_Interpreter_Config		This is the key config file for AMOS Pro.  It's used by the Loader, Interpreter, Editor, Monitor and Compiler.  You should only have one copy of this file and keep it in one of the following places: S: S/ <Current Directory> The Loader looks for it in each of those places in turn.  The <Current Directory> is only really useful if you're playing around with different configs for different programs.  But note that it looks in S: and S/ first, so you'd need to do some renaming to force that option. The best place IMHO is S:.
AMOSPro_Editor_Config		Contains all the additional stuff the Editor and Monitor use.  Mostly the Editor Commands, Editor Shortcut Keys, Accessory Program locations, User Menu, and all the text strings used in the editor.
AMOSPro_Compiler_Config		Contains all the texts strings used in the compiler (including the one that contains the flag characters for the compiler setup).

The compiler first checks to see if the AMOSPro_Interpreter_Config file is already loaded.  If it's been called from the editor, it doesn't need to load the file.  If not, it looks for its own config file in these locations and in this sequence:

• <Current Directory>
• S/
• S:

which is the reverse of the sequence the Loader/Interpreter uses.  That's why I think it's a bad idea to have the config files in more than one location  .

I haven't checked any further yet, but the strings it uses in the code to check the above locations are a bit strange:

• "AMOSPro_Compiler_Config" is <Current Directory>
• "S/" is a bit of a worry as there's no file name! 
• "S:AMOSPro_Compiler_Config" is for the S: assigned directory.

I haven't fully pulled the compiler apart yet so I've no idea how it uses AMOSPro_Interpreter_Config.  But the AMOSPro_Compiler_Config file references it as "S:AMOSPro_Interpreter_Config" which is, presumably, where it expects to find it after it's loaded its own config file.


As to gibs problem:
If the compiler is picking up a different AMOSPro_Interpreter_Config to the one used by the editor, and that file hasn't got the extension included, maybe that's the cause.  The editor will run it okay, but the compiler won't know the extension exists and will throw up those errors.

Sorry to still be a bit vague on the compiler.  I'll be up to my neck in the Loader/Interpreter/Editor bug fixes, docs and help files for a long while yet and can't afford to get too distracted... 

[gibs]

Hi Bruce.
Thanks for the information.

As you said I wasn't able to compile with the Turbo Extension (1.0/1.9/Plus) SET in the editor.
I could not compile even commands if the code were not using commands from the Turbo Extension. Example a single "Cls" failed.

Then Booboo send a tip about compiling from DH0: ,so I put the code (containing Turbo Extension commands) in DH0, and I tried to compile it but it also failed. Therefore from DH0: I could compile code that excluded the Turbo Extension. Ex: I could compile a "Cls" with the Turbo Extension SET in the editor.

I spent almost 10 days on that.
I didn't had a copy AMOSPro_Interpreter_Config elsewhere in the FileSystem that in S: (or DH0:S/).
I was aware of this issue because it's written in the Troubleshooting documentation of the Compiler Documentation.

Then, I have re-installed the Compiler (from the Floppy and while while the Turbo Extension was SET in the Edifor) and the problem has gone.

Note that I still have some Amiga with the same problem that I haven't fixed yet, so I you wish me to make some tests in the "issue environment", I can.

[bruceuncle]

Thanks for the feedback gibs.  I'm going to register this as a bug as it shouldn't be this difficult and confusing to simply add an extension library and compile with it. 

My preference is for all config files to reside in the S: assigned directory and for there to only be one set named with the 'official' names.  Any that are backups or defaults for restoring when things get messy should be named differently and appropriately.

Note that I still have some Amiga with the same problem that I haven't fixed yet, so I you wish me to make some tests in the "issue environment", I can.

Many thanks for the kind offer but I think that might be overkill as we'd need a full dump of each installation to be really useful.  If you've got the time, the location of any config files in each system, plus the files themselves would be a big help anyway.  But don't sweat on it.  I've got enough to be going on with for a bug description.  Don't get too excited (sic) as it will be a while before I pull the compiler apart properly and get into fixing its bugs.

[Lonewolf10]

My preference is for all config files to reside in the S: assigned directory and for there to only be one set named with the 'official' names.  Any that are backups or defaults for restoring when things get messy should be named differently and appropriately.

Sounds like a great idea