BBC BASIC for Windows
Programming >> Libraries >> Will PROC_transpose(A$(), B$()) work ?
http://bb4w.conforums.com/index.cgi?board=libraries&action=display&num=1427030945

Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 22nd, 2015, 1:29pm

I'm stuck with a situation where my program stops without any error message when I execute PROC_transpose(A$(), B$()).
Both are 2D arrays with dimensions resp. A$(75,7) and B$(7,75)

Does PROC_transpose(A(), B()) from the ARRAYLIB library accept string arrays or do I have to look for another type of error?

Eddy

Re: Will PROC_transpose(A$(), B$()) work ?
Post by rtr2 on Mar 22nd, 2015, 2:09pm

on Mar 22nd, 2015, 1:29pm, Edja wrote:
I'm stuck with a situation where my program stops without any error message when I execute PROC_transpose(A$(), B$()).

I think the main problem is that ARRAYLIB hasn't been updated to work with BB4W v6.00a (it hasn't been modified since 2006!), so PROC_transpose$() is assuming your string arrays have v5-style 6-byte descriptors rather than v6-style 8-byte descriptors.

What I ought to do is produce a new version of ARRAYLIB with added support for v6.00 string arrays, but in the meantime you'll either have to run your program under v5.95a or do the transposition yourself (easy, but not as fast as the library which does it in assembler code).

In my defence I would point out that PROC_transpose$(), PROC_transpose%() and PROC_transpose&() are undocumented, so although it would be highly desirable if they all worked in v6.00a (I think it's only the string version which doesn't) officially they are not supported anyway.

Richard.

Re: Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 22nd, 2015, 2:31pm

I've made it a point to do any new coding with BB4W v6.00a.
So I'll write a procedure with interface PROC_My_transpose(A$(),B$()) to be able to proceed. Not hard at all, but, as you pointed out, much slower.
If/When you'll find the time to update ARRAYLIB, it wil only take me a minute to replace PROC_My_transpose(A$(),B$()) with the much faster assembler coded PROC_transpose(A$(),B$())
Thank you for the advice.
Eddy
Re: Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 22nd, 2015, 2:55pm

Some more info :
I've noticed that you refer to the transpose procedure as PROC_transpose$() while I was talking about PROC_transpose()

I've checked ARRAYLIB and saw that you have coded different versions of transpose to cope also with $,% and & arrays (undocumented and unsupported,as you said)
Nevertheless, I've returned to my program and changed it to call PROC_transpose$(A$(),B$())

The result : this time the program still doesn't work but at least it terminates more gracefully with the error message "No room"

Eddy


Re: Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 22nd, 2015, 3:02pm

And finally, to check that I've made no other mistake(s) ....
I've ran the program (with PROC_transpose$()) under v5.95a and it executes perfectly !

As you said !

Eddy
Re: Will PROC_transpose(A$(), B$()) work ?
Post by rtr2 on Mar 22nd, 2015, 3:23pm

on Mar 22nd, 2015, 2:55pm, Edja wrote:
I've noticed that you refer to the transpose procedure as PROC_transpose$() while I was talking about PROC_transpose()

If you had called PROC_transpose(A$(), B$()) it would have given rise to a Type mismatch error, but you said no error was reported.

Richard.

Re: Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 22nd, 2015, 3:50pm

Indeed, I would have expected that message, but the program just "hangs".
To summarize :
under 5.95a
PROC_transpose(A$(),B$()) ----> program "hangs", no messages
PROC_transpose$(A$(),B$()) ----> program works fine

under 6.00a
PROC_transpose(A$(),B$()) ----> program "hangs", no messages
PROC_transpose$(A$(),B$()) ----> program terminates with error message 'No room"

Eddy

Re: Will PROC_transpose(A$(), B$()) work ?
Post by rtr2 on Mar 22nd, 2015, 4:02pm

on Mar 22nd, 2015, 3:50pm, Edja wrote:
Indeed, I would have expected that message, but the program just "hangs".

This reports 'Type mismatch' here (BB4W v6.00a, Windows 8.1):

Code:
      INSTALL @lib$+"ARRAYLIB"
      DIM A$(75,7), B$(7,75)
      PROC_transpose(A$(), B$()) 

So I'd like to see some (similarly brief, hopefully) code from you to demonstrate the claimed issue.

Richard.

Re: Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 22nd, 2015, 4:31pm

The plot thickens ...
I've extracted the relevant parts of my program into a smaller one and executed this. The message "Type mismatch" now appears as it should.
BB4W clearly behaves correctly. I must have introduced an error somewhere else in my original program. I'll try to narrow down what type of bug I've created and let you know. It may take a few days.

Eddy
Re: Will PROC_transpose(A$(), B$()) work ?
Post by rtr2 on Mar 22nd, 2015, 5:12pm

on Mar 22nd, 2015, 4:31pm, Edja wrote:
I must have introduced an error somewhere else in my original program. I'll try to narrow down what type of bug I've created and let you know.

As a first step, make sure that there's just one ON ERROR statement, at the beginning of your program, which looks like this:

Code:
      ON ERROR SYS "MessageBox", @hwnd%, REPORT$, 0, 0 : QUIT 

The right-click (or Shift+F10) context menu will list ON ERROR statements, but only if they are at the start of a line (and only if you've enabled them in the Customize dialogue) so you can't guarantee to find them that way.

Richard.

Re: Will PROC_transpose(A$(), B$()) work ?
Post by rtr2 on Mar 22nd, 2015, 7:00pm

on Mar 22nd, 2015, 2:09pm, g4bau wrote:
What I ought to do is produce a new version of ARRAYLIB with added support for v6.00 string arrays

Uploaded here (members only):

https://groups.yahoo.com/neo/groups/bb4w/files/Libraries/

Richard.

Re: Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 25th, 2015, 11:14am

Quote:
I must have introduced an error somewhere else in my original program. I'll try to narrow down what type of bug I've created and let you know.

I 've tried to reproduce the problem starting from my original program but in the process of making many changes to the code I must have corrected my error without even being aware of it. The program works fine. PROC_transpose gives "Type mismatch" if called with string arrays.
I did have 3 instances of ON ERROR in different locations of my program that may have contributed to the wrong behaviour. I've corrected this as you advized.

And thank you(!) for updating PROC_transpose$ in ARRAYLIB to work with v6.00a. It worked first try.

Eddy
Re: Will PROC_transpose(A$(), B$()) work ?
Post by Edja on Mar 25th, 2015, 1:26pm

Quote:
I must have corrected my error without even being aware of it.

OK, I found an older version of my program with the same behaviour. The culprit was the following line ON ERROR PROC_comexit : QUIT

When I call PROC_transpose(A$(),B$()) control is given to the above line and PROC_comexit executes. BUT I forgot to execute PROC_cominit to initiate COMLIB. I suppose another error is then generated ....

When I remove ON ERROR PROC_comexit : QUIT control is given to another ON ERROR at the start o f my main program and the message "Type mismatch" correctly appears.
In the end it had nothing to do with PROC_transpose$ but with my clumsy way of error handling. As said in my previous mail this is now corrected.
Eddy


Re: Will PROC_transpose(A$(), B$()) work ?
Post by rtr2 on Mar 25th, 2015, 2:57pm

on Mar 25th, 2015, 1:26pm, Edja wrote:
ON ERROR PROC_comexit : QUIT

You should never - at least not in any normal circumstances - have a (non-LOCAL) ON ERROR statement which doesn't report the error! Not only will any mistakes you introduce into the program yourself lead to an unexplained exit, but any unexpected error which happens when your end user runs the program will generate no diagnostic information to help you trace the problem!

Options for reporting the error are to print it to the 'main window' (but that can very easily be hidden by something in the foreground, or disabled) display it in a message box (my usual preference, because it's guaranteed to be visible), write it to a log file, or perhaps a combination of these.

Richard.