PT Parser on OSX

[jas]

First, let me say "Thanks, Brad for releasing this parser code!" I've
had alot of fun over the last week playing with it.

I've got the PT Parser running on OSX 10.4.3 (well... maybe tottering
would be more accurate verb than running)

Screenshots here :

http://myguitars.home.comcast.net/01_PTP_Launch.jpg
http://myguitars.home.comcast.net/02_PTP_Open.jpg
http://myguitars.home.comcast.net/03_PTP_Parse.jpg
http://myguitars.home.comcast.net/04_PTP_Merge.jpg
http://myguitars.home.comcast.net/05_PTP_Test_Suite_Error.jpg
http://myguitars.home.comcast.net/06_PTP_Test_Framework.jpg
http://myguitars.home.comcast.net/07_PTP_About.jpg

I have 3 questions :

Is anyone familar with the "Cannot convert dialog units: dialog
unknown" error message shown in screenshot #5? I'm assuming it's a
wxWidgets error but having tracked it down yet. I'm also assuming that
it's contributing to the cramped look of the Testing Framework window.

After I open a .ptb and parse it, should there be output in the
PowerTabView window? Mine stays blank.

Finally, when I run the entire testing framework, I fail 55 of 10829
tests -- in the ChordDiagram, Direction, and Tuning tests. What is the
best way to begin troubleshooting these?

[dumm...@power-tab.net]

Sorry about the late reply. The notification got bunched in with the PT
support group notifications.

I don't have access to a Mac, so I was unable to test the code on that
platform. I'm not sure if there are any flags and such that need to be
set for the platform.

1) Not sure about the error here. Can you step through the code and
find out which line the error is occurring?

2) All the program does is demonstrate how a Power Tab file can be
parsed, so there's no displaying of the score.

3) Can you attach, or post the results of the exported results file in
the test framework. It will help narrow down the problem. (Click the
Export button in the Testing Framework)

[jas]

B-

Thanks for the reply and happy New Years.

1) The "Cannot convert dialog units: dialog
unknown" is related to the position code in the resource xml file for
the Testing Suite Dialog. If I remove the "d" after the position
coords, I don't get the error but the dialog will still be scrambled.
If I remove the "font" code from the resource file, I still get the
error, but the dialog looks okay. What's cool is that I can monkey
with the xml file while PTP is running -- no re-compile / re-link
required.

Screenshot here :
http://home.comcast.net/~myguitars/08_PTP_Corrected__Dialog.jpg

2) It turned out the .ptb file I was using for testing didn't have any
file/performance info. Once I began looking at more powertab files, I
found some would produce output.

Screenshot here :
http://home.comcast.net/~myguitars/09_PTP_Header_Info.jpg

3) Here's the export from my original test suite run:
http://home.comcast.net/~myguitars/ptp_testing_suite_results.txt

[dumm...@power-tab.net]

1) I'll have to look into this. It's been over a year since that file
was produced, and to be honest, I can't remember what I used to
generate it - whether it's automatically created by VS or it's
something I did by hand.

3) When you get a test failure in the testing framework, it will give
the file and line within the file where the failure occurred.

So this failure:

Test 'Operator== - chordDiagram != chordDiagram 3' failed.
/Users/jm/test/ptparser/ptparser/../chorddiagramtestsuite.cpp(193)

Is telling you the test that failed is in the chorddaigramtestsuite.cpp
file, line 193:

TEST(wxT("Operator== - chordDiagram != chordDiagram 3"), !(chordDiagram
== chordDiagram5));

That line is testing the equality between two variables, chordDiagram
and chordDiagram5, which should not be equal:

ChordDiagram chordDiagram(chordName, 3, 3, 4, 5, 5, 3,
ChordDiagram::stringMuted);
ChordDiagram chordDiagram5(chordName, 3, 4, 4, 5, 5, 3,
ChordDiagram::stringMuted);

If it's returning failure, then they both must be the same, which means
there's something wrong in the constructor or the equality operator.
Can you break at that line in the debugger and see if the objects are
in fact equal, and if there data matches the data passed to the
constructor?

[jas]

dumm...@power-tab.net wrote:

> 3)

> If it's returning failure, then they both must be the same, which means
> there's something wrong in the constructor or the equality operator.
> Can you break at that line in the debugger and see if the objects are
> in fact equal, and if there data matches the data passed to the
> constructor?

Looks like the problem is occuring with the equality operator -- before
the test the data in the array is good. During the test, the data
still looks good, but the size and count become "incomplete type".
Sounds like a wxWidgets / mac thing -- I'll google around and see who
else has run into it.

Before Screenshot :
http://myguitars.home.comcast.net/10_PTP_Before_test.jpg

During Screenshot :
http://myguitars.home.comcast.net/11_PTP_During_Test.jpg

[dumm...@power-tab.net]

I see the pattern - all of your test failures occur in a class that
uses the wxByteArray, or the wxWordArray.

These are macros defined in macros.h:

// Defines a byte array (although it uses 4 bytes per element)
WX_DEFINE_ARRAY_INT(wxByte, wxByteArray);
// Defines a word array (although it uses 4 bytes per element)
WX_DEFINE_ARRAY_INT(wxWord, wxWordArray);

I thought it might be a little endian/type size problem, but the
wxWidgets docs state that wxByte is wxUInt8, which should be 8 bits on
all platforms. Maybe it's a problem with the internals of the ARRAY_INT
macro.

There's a MAC FAQ here:
http://www.wxwidgets.org/faqmac.htm

Also found a blurb about problems with XCode on an A-Mule site:
http://www.amule.org/wiki/index.php/HowTo_compile_on_Mac

[jas]

For grins, I changed WX_DEFINE_ARRAY_INT(wxByte, wxByteArray) to
WX_DEFINE_ARRAY_INT(int, wxByteArray). This cleared up my "incomplete
type" in the debugger and reduced the total failures in the Test Suite.

Screen shot here :
http://myguitars.home.comcast.net/12_PTP_Testing_after_Macro_change.jpg

Test results here :
http://myguitars.home.comcast.net/ptp_testing_suite_results_2.txt

Unfortunately, it also introduced errors into the serialize tests. I'm
still not sure what the root cause of the problem is, I'll dig into
this tonight

[dumm...@power-tab.net]

The serialize is failing because it's saving each item in the array as
an int instead of a byte.

How about trying this:

WX_DEFINE_ARRAY_INT(unsigned char, wxByteArray)

and

WX_DEFINE_ARRAY_INT(unsigned short, wxWordArray)