Print

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

[bruceuncle]

This release is a work-in-progress for a V2.10 release of AMOS Pro that is aimed at fixing the existing bugs.  You'll need to unzip the attached file and follow the readme.txt instructions to install it.

It includes the latest (today!) bug list as a PDF which should help explain what's going on and where I'm up to.  So I won't repeat it all here  .

I've got two main objectives at this stage:

• Progressively fix the existing bugs on the list (and any new ones I find)
• Improve the AMOS Help system so that I can generate it from the AMOS Documentation database.  (Which I regard as the biggest AMOS Pro bug - "If the Help don't work, people won't use it.")  It will then match the AMOS Reference Manual generated in RTF format from the same database.

So if my priorities seem a little strange, that's why.

As usual, all this takes time so I'll continue to release alpha and beta versions as I get the spare time to do them.  Until it's all fixed! 

If you don't like the new Help File format, you can leave the rest of the release in place and just replace the AMOSPro_Help.map and AMOSPro_Help.txt files from your backups (you did backup didn't you?  ).  The new AMOSPro_Help.AMOS program and the binaries are fully backwards compatible with the old files.

The important result I need from this release is for people to install it and check out the sections of the Help File in the new format (definitely read the readme.txt instructions !!!).  So please let me know if you think the colours, content and layout work okay  .

[SamuraiCrow]

It works here.

One comment of something to watch for when renaming libraries:  AmigaDOS is case-insensitive but Exec.library's OpenLibrary command might not be.  Be sure to rename AMOS.Library appropriately, not amos.library.  (If it works though, post here so I will update my knowledge.  I'm just going on the word of another programmer and haven't tried it out myself.)

Edit:
Confirmed as a bug in OpenLibrary Autodocs.  See here.

[OlafS3]

Thanx a lot

I have included AMOS Pro in AROS Vision and look forward to include new versions (expecially when AGA support is added). Thanx a lot for your work.

I will test 2.10 this weekend

[bruceuncle]

It works here.

One comment of something to watch for when renaming libraries:  AmigaDOS is case-insensitive but Exec.library's OpenLibrary command might not be.  Be sure to rename AMOS.Library appropriately, not amos.library.  (If it works though, post here so I will update my knowledge.  I'm just going on the word of another programmer and haven't tried it out myself.)

Edit:
Confirmed as a bug in OpenLibrary Autodocs.  See here.

Ah, but amos.library is not an AmigaDOS library (so maybe it shouldn't be in LIBS: in the first place  ).  It's a custom collection of three sets of library routines.  So AMOSPro uses LoadSeg() to get it into memory.   It expects to find it in one of three locations, which it tries in this sequence:

• APSystem/amos.library
• libs/amos.library
• libs:amos.library

These names are what are used in the +B.s source and are what you'll see in the resulting AMOSPro binary (i.e.  all lower-case).

Once in memory, it has a jump and data list in the first six longwords.  To cut a long story a bit shorter, the "startup" jump expects to find A5 pointing to an initialised AMOS data area.  It uses that to initialise the following vectors in the first three negative longword offsets from A5:

• SyVect - offset -4, points to the "system" jump table
• EcVect - offset -8, points to the "screens" jump table
• WiVect - offset -12, points to the "windows" jump table

The macros SyCall, EcCall, WiCall and their variants are used, together with the instruction number equates in +Equ.s, to call the functions.

AMOSPro only uses _LVOOpenLibrary() for:

• dos.library
• intuition.library
• mathffp.library
• graphics.library
• icon.library

which all appear in the sources, as in the above list, in lower-case.

[SamuraiCrow]

I've split off my off-topic reply into a separate thread. 

[Hungry Horace]

quick random question about the help file update.... is it possible for entries documenting Extension commands to be added?

Obviously, the help description would then need to state if a command is 'AMOS Command' or 'Extension Command: AMCAF' etc, and could even be used to verify if commands are AMOS original or AMOS Pro specific.

Just a thought!

[bruceuncle]

quick random question about the help file update.... is it possible for entries documenting Extension commands to be added?

Obviously, the help description would then need to state if a command is 'AMOS Command' or 'Extension Command: AMCAF' etc, and could even be used to verify if commands are AMOS original or AMOS Pro specific.

Just a thought!

A good thought!  Obviously, initially, I'll just be doing the AMOS Pro instruction set (over 1,000 to document!).  But the Help System in AMOS is flexible enough to cope with extra help files.

I'd prefer it to be 'seamless' to the user.  AMOS Pro 'knows' what extensions are present when it starts up (it has to load them and initialise them).  So if we use a naming convention and 'known' location for any associated help files, they can be integrated at load time.  There will be problems with that concept in merging the map and text files but I prefer to look on that aspect as just another challenge  .  Maybe they can still be separate files for each extension and AMOS just iterates the map files to find a match for context help (might be a bit slow though).  Otherwise, 'gluing' them into the Help system is no problem as that's how the "Latest News" files get picked up now.

[bruceuncle]

What I'd really like though, is some feedback on the new help topic format  .  It takes up more space but I think it will be worthwhile (especially as it's already in that format in the Help Database).  So read the readme.txt file about where the converted topics are and have a look, and think about what you like and what you don't like.

Then let me know. 

The alternative is to add a briefer version just for the Help files.  But I don't like that option as I never like storing the same data in more than one place.  And I'd have to rewrite each topic for the shortened version.  Heck, that thought alone makes me think I've already made up my own mind!  .  But I would appreciate some feedback.

[bruceuncle]

Attached is a release that fixes a bug in Hypertext in the last release:

If the new escape sequence ( "{{" ) was used to allow printing of Hypertext syntax instead of it being interpreted as a Hyperlink, the rest of the line disappeared when the text was scrolled.

There's also an updated bugs list doc.  It explains why too many Data statements or lengthy If ... End If structures can stuff up AMOS.  Read it!  It's something important in AMOS that needs to be understood.   

I've included all the other files from the previous release.  So, if you've already installed that, you only need to copy one file.  Read the readme.txt file for details.

[SamuraiCrow]

Excellent!  One more bug bites the dust!

[Lonewolf10]

I've just read the bugslist PDF. Great job bruceuncle

I will install the new version of AMOS at the weekend

[bruceuncle]

Quick progress report:

• I've changed the docs DB schema to now handle both the Ref Manual and AMOS Help File data.  There's just a few cases where I can't use the material for both purposes and some duplication of effort is required.  Three target document types: Ref-Manual-only, AMOS-Help-only and Both (the vast majority thank goodness!)
• The data now comprises: the original Ref Manual stuff so far, the AMOS Help File contents in full (for the menus) and stuff I've formatted into the new schema.
• Both the DB and the Help Editor now handle AMOS Help Menus (they'll just be ignored for the Ref Manual extract, or a separate AMOS-Help-only record used where necessary).  The menu links have been validated, which corrects those few incorrect pointers in the original.  I've also incorporated the Latest News and Compiler Help files - messy but I can now sort that out with all the benefits of a rigid database schema to ensure it stays sorted!
• I now need to re-program the extractions as I've changed the formatting markups.  I'm using a strict sub-range of HTML (the one an Access RTF Textbox understands, so I get my WYSIWYG).  Both the original extractor programs are OO (as far as VBA allows anyway) so it won't be too much hassle.
• I've done no more on AMOS bugs as I wanted the above sorted (and make damned sure it was achievable) before I continued on in that direction.  And to get a more substantial chunk of Help File out there from the already written Ref Manual stuff.  I need to continue with that too (writing the Ref Manual material I mean - but for both targets now).

Food for thought...  The current AMOS Help system looks for keyword matches in its *.map files.  But the AMOS Editor tokenises and detokenises each line in its window as the user moves around in it.  So it knows what AMOS Token(s) is(are) under the cursor or selected text.  This includes the Extension Number as part of the tokenisation.  I would suspect that a far more accurate and flexible AMOS Help system could be designed to use AMOS Token lookup instead.  More compact, far quicker (the *.map files would then only contain tokens which would be sorted for quick binary searching) and, as Hungry Horace suggested, able to cope with any loaded extensions that had compatible Help Files.  Just a thought...

[SamuraiCrow]

Food for thought...  The current AMOS Help system looks for keyword matches in its *.map files.  But the AMOS Editor tokenises and detokenises each line in its window as the user moves around in it.  So it knows what AMOS Token(s) is(are) under the cursor or selected text.  This includes the Extension Number as part of the tokenisation.  I would suspect that a far more accurate and flexible AMOS Help system could be designed to use AMOS Token lookup instead.  More compact, far quicker (the *.map files would then only contain tokens which would be sorted for quick binary searching) and, as Hungry Horace suggested, able to cope with any loaded extensions that had compatible Help Files.  Just a thought...

It's a good thought but you'd be the only one that understands the tokenizer well enough at this point to accomplish it.  How long do you think that would take out of other programming time?  In other words, do you think it would take time away from other bugs that still need fixing?

I think it was your idea in the first place to resist the temptation to add many features until the bugs are fixed.

[bruceuncle]

In other words, do you think it would take time away from other bugs that still need fixing?

I think it was your idea in the first place to resist the temptation to add many features until the bugs are fixed.

That's why that "thought bubble" isn't in the bullet point list.  It belongs in V3.x along with OCS/ECS/AGA capabilities.  And we have all speculated on what we want when we get around to working on that version  .

To make it clear, V2.10 is purely a bug-fix version.

A few of the reported bugs refer to the AMOS Help system - missing and incorrect links, topics cut off in the middle, etc.  Plus, quite a few of the AMOS Help topics are blatantly incorrect!  To me, that is a much of a problem as something that just doesn't work.  If the Help is wrong, the user loses confidence.  So part of my bug-fix process is to get a better quality and quantity of help available to the user.  As I'd already got a swag of new documentation available in the AMOS Reference Manual project, that content is being incorporated into the bug-fixed help system.  I've taken a little time out from the AMOS source files to ensure that I can generate both AMOS Help files and the Reference Manual from the same database.  Otherwise, I'd be rewriting all the stuff I'd already got in the database  .  The same will eventually apply to a possible HTML version of the Reference Manual.

The database contents are by no means complete.  That's another on-going project and will take some time yet before everything is in the new format and accurate.  It's also why I kept bleating about some feedback on the new Help File format.  It's a major change to the look-and-feel of the help files.

As the database contents grow (something I get back to every now and then) I can then just issue Help File updates at the push of a button.  The programming for that is now nearly complete.


It also gives me a break from wading through the sources checking the implications of bug fixes and ensuring the integrity of the code.  Which can be a real pain at times.  The latest fix (I'm in the middle of it) is a good example.  It's the one about long (out-of-range) numbers being accepted by the editor, but truncated or otherwise mashed around.  There's no error message for that and no mechanism to handle the message.  I'm re-using some of the existing code routines but have to double-check for any unexpected repercussions from the changes.  At that point in the code, I'm up to my neck in stack frames that are maintained over many hundreds of lines of code.  I think I can see the way to do it... 

For that bug, there's also the problem of how to release the fixes.  The editor configuration file needs to be changed without upsetting the user's personal settings.  So I'll have to build an updater!  And so it goes on.

I released that alpha version to give people a chance to okay or veto the help file formats and to see that something is happening.  And, as the changes were minor, I could get away with a simple "just backup and replace these files".  All future fixes will need a formal updater package for release as many more files will be affected and configuration files will need to be changed in-situ.  So it may be a little while before the next batch of fixes appears.  At which stage I should be able to raise the level to a beta release.

So don't worry too much.  I'm still on track and fully committed    (or should that be committable?  )

[SamuraiCrow]

@bruceuncle

I've verified that the bug was fixed and the new format looks good.  After I installed it and posted on AmigaCoding.de about it, Olaf put the bug-fixed AmosPro in the AROS Vision 2.3 release.  I guess alpha code has moved to beta but bug-fixes are really good to get feedback on.  I haven't seen any harmful repercussions of the existing bug fixes but haven't done much with AmosPro either.

I'm glad you're keeping the new coding priorities straight.  I've put FS-UAE on my Mac and it seems to work quite a bit better than EUAE especially with regard to capturing the mouse input and only releasing it when I hit the middle mouse button/wheel.  This makes working with AmosPro so much easier.