Print

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

[bruceuncle]

Okay, okay 

See if the attached version works.

WARNING!  Contains absolutely no spaces, periods nor hyphens but may contain traces of paranoia. 

[SamuraiCrow]

AFter wrestling with LibreOffice and updating to the latest version 4.0.3, I can safely say it still doesn't work.  The INFO() function doesn't support the "DIRECTORY" argument.  I took out the INFO() function and tried it without it.  It still wouldn't load.  I tried using relative paths with a file:// in front of it.  Still nothing.  I think it's hopeless.   

[Lonewolf10]

It shouldn't be hopeless. I know some people at work use workbooks filled with links to files, so I know it *should* work. However, I have never implemented anything like that in my workbooks (yet).

[SamuraiCrow]

I'm beginning to suspect the HYPERLINK() function isn't intended for use with local files in any form.  I haven't tried an absolute path yet because that would be a very hollow victory.

[Lonewolf10]

Hmmm... I got it to work in Excel by clicking on the insert hyperlink icon and typing in the filename (with NO filepath). For example, I typed in "amigaguide.guide" and it opened the file contained in the same directory as the workbook without any problems (full path is "C:\Documents and Settings\User\Desktop\amigaguide.guide").

I'm using an old version of Excel, on Windows 2K SP4.


Edit: Just got it to work with the HYPERLINK() function too, just using filename (no filepath).

Edit2: Further playing shows that Excel supports the INFO function and DIRECTORY function... but it points to the "My Documents" folder, which is not where any of the files are stored. (The full path to the files is "C:Documents and Settings\User\My Documents\Amiga-HD\HD1-DEV_KIT\AMOS_Bugs\").

[bruceuncle]

To all.  Excel Hyperlinks are tricky because they usually embed the complete path to the target file in the =HYPERLINK() function.  Which is useless if you want to move the files around or distribute them.  That problem can be solved using a bit of VBA to get the workbook's full path, extracting the directory path and either updating the link cells or making a function for the cell instead.  I didn't want to do that 'cos it would only work for Excel users (and not everyone uses Excel).

The  method I used gets the "current directory" [ =INFO("DIRECTORY") ] in the cell formula instead.  As I pointed out, this will only work if you open the workbook from within Excel using File Open.  Each time you open a workbook, the "current directory" will change!  So, if you then go back to the hyperlinked workbook, the "current directory" function will get the wrong one.  If you double-click the workbook in Windows Explorer, you'll get whatever default directory Excel's set up to use.  Which is usually My Documents.  The same thing happens if you select from a Recent Files list too.

As the =INFO("DIRECTORY") function only seems to be available in Excel, it seems it was a bit pointless anyway   

Recommend you relink in the spreadsheet to the files manually.  Tedious, but the info's a lot easier to digest with the links working.

Notes on the Bugs List

This list may well contain bugs that were AMOS Pro V1.x specific and are fixed in V2.0.  I haven't checked as I just wanted to nail down a deliverables criterion.  If you know of any of these that have been fixed in V2.0, please let me know and I'll remove them.

I set a cut-off date of end of May (2013!  ) just so I can partition up the workload.  This batch will all be versioned internally as V2.01x.xxx.  Anything reported after that date will just go into the next batch (which will be versioned as V2.02x.xxx internally).  And so on.  I'd be very surprised if there are not some obscure bugs involving obscure instructions that haven't surfaced yet. 

For example, one I just came across in the last couple of weeks is that there's an error in the AMOS Equates file.  If I hadn't been testing the Ask Editor and Call Editor instructions for the docs, I doubt it would ever have surfaced!  (And just noticed it's in my list but not in the spreadsheet!  Mea culpa!  Mea maxima culpa!  )

The objective is to get a V2.01 release out in the next six months.  We won't get everything fixed by then, but should have something worthwhile releasing.

Note also that the version numbers I'm using internally (in the database that holds all this stuff) is in the format 2.xxx.xxx.  This is to give a finer granularity for controlling the fixes for us.  But releases I would expect to only use the V2.xx format unless there's any good reason not to.  So the user will see V2.01, V2.02, etc.

[SamuraiCrow]

The bank allocation bug (1.15) may solve multiple other bugs if solved first.  Cases in point:  the loading of samples into Fast RAM.

[bruceuncle]

A quick question (sic) on a Print bug.  The bug is:

If you use:

Print ,,
Print "a",,"b"

You get:

-2147483648 -2147483648
a -2147483648 b

This is caused by a bug in the Verification (syntax check) code.  AMOS Basic expects a Print statement to follow the format:

Print <expression><separator><expression><separator>...

and is supposed to choke if it gets something like:

Print <expression><separator><separator><expression>

or:

Print <separator><expression>

If you try the same thing with the other Print separator, the semicolon, you'll see what I mean.

With Verification letting that usage of the comma through instead of chucking it out, the Interpreter evaluates it instead of treating as a separator.  The comma (Token _TkVir, number $5C) uses L_FnNull if it's picked up as an expression.  So it's evaluated to #EntNul which is $80000000 or -2147483648 in decimal, which is what you're seeing.

Bear in mind that AMOS Basic was built for speed.  And although its syntax is similar to other Basic dialects, it is different.  It expects you to use Tab$ to do the job if you want a tab at the beginning of a line or if you need multiple tabs in the middle of a line.

So my question is "Do we want to correct the Verification bug to reject it as a Syntax error (simple and fast) or do we want to fix it in the Interpreter (much more complex, slightly slower and 'not really AMOS')?"

(Forgive my bias  )

[Hungry Horace]

I would have expected it to be a zero length string, rater than a VBA style Tab$....


Surely that would be faster also? Ie. ignore separators until you reach a valid string to print

[bruceuncle]

I would have expected it to be a zero length string, rater than a VBA style Tab$....


Surely that would be faster also? Ie. ignore separators until you reach a valid string to print

I just knew this would open a can of worms    Thanks for the feedback.

It's not that simple Hungry Horace.  The Print statement can contain all sorts of functions and expressions as well as quoted strings.  The Interpreter code that handles this is quite complex.

The way AMOS works is by using a very intensive Verification phase (the Test button) before it runs a program through the Interpreter.  That way, any syntax errors are detected before the Interpreter crashes the system.  (Yeah, I know.  Good theory that doesn't always work in practice.  But it's a good architecture for an Interpreter.)  The Interpreter then just has to run through the tokenised code picking up the tokens and acting on them.  Just like most other p-code style interpreters.

The problem with this little bug is as I stated in the original post:  The Interpreter expects a chain of <expression><separator><expression><separator>... for a Print.  To change that expectation is a lot more work than correcting the Verification code, which is where the bug is.  AMOS Basic syntax is pretty unique in that it's similar to the syntax used in other Basics, but it is different.  For example, using Tab$ to allow the programmer to do the equivalent of Print ,,"Hello World".  In AMOS Basic it would be Print Tab$;Tab$;"Hello World".  Tab$ takes no parameters (unlike, say, a VBA Tab$(Size)).  You're expected to preset the tab length using Set Tab Size.  It may be more cumbersome but it's the way AMOS Basic syntax works.

I think I'll just stick to plan A and correct the Verification to chuck it out as a syntax error, which is what it does for a semicolon used in the same way.  At least then it's consistent behaviour and still AMOS Basic  .

[SamuraiCrow]

* SamuraiCrow checks the PEG parser generator code Sidewinder and I wrote for Mattathias.

For Mattathias BASIC we just made the "Printval" rule optional within the repeated field of "PrintSeparator" rules so that the parser wouldn't choke.  For the comma separator, converting it to a Tab$; would work well too.

You can view the WIP PEG parser generator file here.

[bruceuncle]

* SamuraiCrow checks the PEG parser generator code Sidewinder and I wrote for Mattathias.

For Mattathias BASIC we just made the "Printval" rule optional within the repeated field of "PrintSeparator" rules so that the parser wouldn't choke.  For the comma separator, converting it to a Tab$; would work well too.

You can view the WIP PEG parser generator file here.

Many thanks SamuraiCrow.

To provide some context, what I'm aiming for is still to follow the original plan for "Classic AMOS" which is to fix the bugs, document and release a HDD install.  Then look at enhancements (AGA, extra instructions, etc).  I don't at this stage want to change its syntax rules.

Having said that, I very much like the idea of automatically converting a misplaced comma (as far as AMOS is concerned  ) into a Tab$ token during Verification.  That fits nicely with the universal Basic shorthand of a ? for a Print.

Thanks again mate. 

[Hungry Horace]

• Using the file-selector typing " / " <return>  to go back a directory, will change the path to include the current path *plus* a // drop-back for a folder.
  ref post
  
  

I would be incredibly grateful if this bug could be fixed....  i often surf around my Projects/ folders and watching the path get longer and longer and longer as i scoot back a folder is quite troublesome!!! [/list]

[bruceuncle]

• Using the file-selector typing " / " <return>  to go back a directory, will change the path to include the current path *plus* a // drop-back for a folder.
  ref post
  
  

I would be incredibly grateful if this bug could be fixed....  i often surf around my Projects/ folders and watching the path get longer and longer and longer as i scoot back a folder is quite troublesome!!! [/list]

Aaargh!  Do you want I should move this up the priority list?  I thought the nags had quietened down since MadAngus disappeared into the wild blue yonder.  I'm tackling all the bugs on the list (and thankfully some are cases of RTFM rather than a bug).  This is taking some time and I need the occasional diversion every now and again...

Since I discovered the real power in Resource now I've pulled the docs out of its help files, I'm currently putting the macros together to disassemble AMOS Pro Extensions to produce sources usable  with +amos_includes.s.  Luckily, I'd already done a lot of the hard stuff a couple of years ago (Good grief!  Is it really that long?) when I put all the Resource symbol libraries together for AMOS Pro.  Found bugs in a couple (chopped off some of the symbols for +LEqu.s at the full-stop  ) but the results look great so far.  As soon as I've finished that (and published a revised Help doc - the last one had the same errors as the help file that it came from - nothing like hands-on to really find out the truth) I'll be back on AMOS Pro V2.10.

[Hungry Horace]

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

Pulling apart the extensions could be really key, and to have some natively included and included in the in built help file would be amazing!

I am just saying, if it goes high up the list when you *do* resume by fixing, I'd be very happy! Hopefully it's not too difficult to fix either....