nesdev.org

lidnariq wrote:

Imperial wrote:I'm sure there's a tool in BSD-land somewhere that can open deb packages

They're AR chives. 7z also can unpack them.
Naively you could do something like ar p foo.deb data.tar.gz | bsdtar xzvf -

In file included from Source/FFT/Fft.h:9,
                 from Source/FFT/Fft.cpp:9:
Source/FFT/Complex.h:45:7: warning: no newline at end of file
In file included from Source/FFT/Fft.cpp:9:
Source/FFT/Fft.h:62: error: expected unqualified-id before numeric constant
Source/FFT/Fft.h:62: error: expected ';' before numeric constant
Source/FFT/Fft.h: In member function 'double Fft::GetIntensity(int) const':
Source/FFT/Fft.h:26: error: invalid types 'int[int]' for array subscript
Source/FFT/Fft.h: In member function 'void Fft::PutAt(int, double)':
Source/FFT/Fft.h:54: error: invalid types 'int[int]' for array subscript
Source/FFT/Fft.cpp: In constructor 'Fft::Fft(int, long int)':
Source/FFT/Fft.cpp:41: error: lvalue required as left operand of assignment
Source/FFT/Fft.cpp: In destructor 'Fft::~Fft()':
Source/FFT/Fft.cpp:85: error: type 'int' argument given to 'delete', expected pointer
Source/FFT/Fft.cpp: In member function 'void Fft::Transform()':
Source/FFT/Fft.cpp:147: error: invalid types 'int[int]' for array subscript
Source/FFT/Fft.cpp:148: error: invalid types 'int[int]' for array subscript
Source/FFT/Fft.cpp:148: error: invalid types 'int[int]' for array subscript
Source/FFT/Fft.cpp:149: error: invalid types 'int[int]' for array subscript
Source/FFT/Fft.cpp:150: error: invalid types 'int[int]' for array subscript
gmake: *** [Fft.o] Error 1

Imperial wrote: Source/FFT/Fft.h:62: error: expected unqualified-id before numeric constant
Source/FFT/Fft.h:62: error: expected ';' before numeric constant

It is having trouble with Fft::_X, an array of Complex's. Have you gotten this error, or anything like it?

cpow wrote:

Imperial wrote: Source/FFT/Fft.h:62: error: expected unqualified-id before numeric constant
Source/FFT/Fft.h:62: error: expected ';' before numeric constant

It is having trouble with Fft::_X, an array of Complex's. Have you gotten this error, or anything like it?

No I haven't seen this error. But from the error it seems that perhaps something in the compile chain is #define'ing Complex as a numeric value. I can't look right now to see where else Complex class might be used, but you could try renaming the class to ComplexFT or something else. If that fixes this then we should post that as a bug/cross-platform issue to jsr so he can adjust the MFC source for future drops.

Imperial wrote:

cpow wrote:

Imperial wrote: Source/FFT/Fft.h:62: error: expected unqualified-id before numeric constant
Source/FFT/Fft.h:62: error: expected ';' before numeric constant

It is having trouble with Fft::_X, an array of Complex's. Have you gotten this error, or anything like it?

No I haven't seen this error. But from the error it seems that perhaps something in the compile chain is #define'ing Complex as a numeric value. I can't look right now to see where else Complex class might be used, but you could try renaming the class to ComplexFT or something else. If that fixes this then we should post that as a bug/cross-platform issue to jsr so he can adjust the MFC source for future drops.

I did try renaming it to CComplex, but the error was the same. If you Google this error, there are a few threads on stackoverflow, etc., and the solution is a missing semicolon. But I can't find a missing semicolon anywhere in FFT/*.

koitsu wrote:I can't help with the overall "stuff" being discussed here (no familiarity with Qt), but quickly read up on QRegExp. But, re:

Code: Select all

str = str.right(str.length()-str.lastIndexOf(QRegExp("[/\\\]")));

The regex in question does look to contain one too many backslashes -- and how that compiled at all for anyone is beyond me (shame on whoever wrote that parser!). The fixed regex in English would read "match the character slash (/) or backslash (\)". If the individual really did mean to say in addition "... or close-bracket (])" then that should have been QRegExp("[/\\\]]")

Also, I urge whoever's writing that code to read this and be aware of the performance hit. It appears QRegExp is really quite awful performance-wise compared to PCRE (or just change the code to just look for '/' or '\' using other means than a regex engine; come on this is easy ): http://blog.rburchell.com/2011/12/why-i ... nd-so.html

Imperial wrote:

Code: Select all

/usr/local/lib/libglib-2.0.so.3400.0: warning: stpcpy() is dangerous GNU crap; don't use it

The stpcpy() and stpncpy() functions conform to IEEE Std 1003.1-2008 (``POSIX.1'').

Code: Select all

mainwindow.o(.text+0xef): In function `MainWindow::~MainWindow()':
: undefined reference to `vtable for MainWindow'

koitsu wrote:

Imperial wrote:

Code: Select all

/usr/local/lib/libglib-2.0.so.3400.0: warning: stpcpy() is dangerous GNU crap; don't use it

RL LOL -- that warning is stupid. The glib folks (assuming it's coming from them -- maybe it's coming from the compiler) should be ashamed. stpcpy() is POSIX compliant (specifically POSIX 2008), specifically quoting the FreeBSD man page STANDARDS section:

The stpcpy() and stpncpy() functions conform to IEEE Std 1003.1-2008 (``POSIX.1'').

stpcpy() returns a pointer to the trailing NULL that was copied into the destination; strcpy() returns a pointer to the start of the beginning of the string copied. If the warning is annoying (and I agree it is), you can accomplish the exact same thing as stpcpy() by using a combination of strcpy() and strrchr() (searching for '\0' in strrchr() -- yes, strrchr(buf, '\0') will work and find the last occurrence of a NULL in buf)).

Note: this is hardcore C++ bullshit and I do not do C++ (this is a great example why. ).

I had no idea what a vtable was until I read this gobbledegook. Way to make programming confusing for virtually no gain. Check out my hate-on!

You might be getting a lot of these warnings/issues as a result of compiler differences between yourself and the author. g++ -v (assuming it's the g++ compiler being used and not clang) would be useful here from both of you, I think.

$ g++ -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd5.3/4.2.1/specs
Target: i386-unknown-openbsd5.3
Configured with: OpenBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719 

koitsu wrote:I can't help with the overall "stuff" being discussed here (no familiarity with Qt), but quickly read up on QRegExp. But, re:

Code: Select all

str = str.right(str.length()-str.lastIndexOf(QRegExp("[/\\\]")));

The regex in question does look to contain one too many backslashes -- and how that compiled at all for anyone is beyond me (shame on whoever wrote that parser!). The fixed regex in English would read "match the character slash (/) or backslash (\)". If the individual really did mean to say in addition "... or close-bracket (])" then that should have been QRegExp("[/\\\]]")

Also, I urge whoever's writing that code to read this and be aware of the performance hit. It appears QRegExp is really quite awful performance-wise compared to PCRE (or just change the code to just look for '/' or '\' using other means than a regex engine; come on this is easy ): http://blog.rburchell.com/2011/12/why-i ... nd-so.html

Imperial wrote:The vtable error was caused by this:

Code: Select all

class MainWindow : public QMainWindow
{
    Q_OBJECT

Right there. This is my first venture with Qt, as well, but a quick search for Q_OBJECT explained that you have to run this header through moc. So I did this: $ moc4 mainwindow.h -o mainwindow.cc. Then I copied the contents of mainwindow.cc, minus #include "mainwindow.h" and the generated comments, right into mainwindow.cpp. Then $ gmake clean; gmake and there it is.

FamiTracker on OpenBSD. Tested with Shiru's after_the_rain.ftm.

cpow wrote:Ok first of all...FREAK ON! That's ridiculously cool! Thanks for the effort!

Could you do me a favor and post your machine stats and your observations on performance? [I take it since you didn't start out with ... meh it compiles but it sounds like excrement ... that you're happy with how it sounds?]

$ uname -mrs
OpenBSD 5.3 i386
$ dmesg | grep CPU
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz
$ sysctl -a | grep hw.*mem 
hw.physmem=1064497152
hw.usermem=1044496384

The Q_OBJECT macro should be automatic when doing qmake/make it should just do what it's supposed to do -- no manual intervention required. That's very strange.

I will cross-post to FamiTracker to have jsr update the MFC Fft.h usage of _X and _W.

Imperial wrote: I'm on a 2ish-year-old EeePC so I'm not using a power-house over here. It doesn't sound fantastic, but I attributed that to the fact that it's Nintendo music. Are you saying there's something I could do in the build process to tweak it?

I think so, too. I shouldn't have to do anything with generated code, but I did it to make it work.

I will cross-post to FamiTracker to have jsr update the MFC Fft.h usage of _X and _W.

That's still weird.