Back on Trac

This is a follow on to my recent post about installing Trac on Ubuntu. I had installed Trac 12.1, served from Ubuntu 12.04, but running in Virtual Box.

Now I have a real live Mac Pro to play with. However, the Ubuntu is crusty old 11.04 but I did not install it and I don't know who did.. .I have 0 experience installing on the Mac, and am not ready to take the plunge and risk bricking the Mac Pro. The reason this is relevant is because this time when I install Trac, I don't want to go the apt-get route, because it will load version 11 of Trac.

Instead, I am going to use easy_install to get the latest Trac 1.0. There are two different references I am using:

UbuntuTracHowto: SVN + Apache + Trac setup. Installs Trac by apt-get.

Robert Basic: I used this reference for installation of Trac via easy_install, but I don't do the wsgi stuff.

At this point, I can now browse the minimal Trac setup. I don't want to bore you with the mundane details of setting permissions and what-not.... what's next:

Enable WebAdmin

Setup source code repository:  go to "Administration: Repositories" and add the path to the repository. Trac responds with the the following:

• The repository "test_repo_trac" has been added.
• You should now run trac-admin $ENV repository resync "test_repo_trac" to synchronize Trac with the repository. e.g. trac-admin /var/lib/trac/my_trac_proj/ repository resync "*"
• You should also set up a post-commit hook on the repository to call trac-admin $ENV changeset added "test_repo_trac" $REV for each committed changeset.

... so here is what I put in my hooks/post-commit:

#  /var/www/.python-eggs
# export PYTHON_EGG_CACHE="/var/lib/trac"

trac-admin /var/lib/trac/mytracproj/ changeset added "$1" "$2"


Issue:  Source Browser doesn't show up on the Trac page.

Try apt-get install python-subversion.

Try removing the repository from the Admin screen, and re-added it. The following error was shown:

Can't synchronize with repository "(default)" (Unsupported version control system "svn": Can't find an appropriate component


In Trac 1.0 (trunk, starting from r11082), the components for Subversion support must be explicitly enabled in trac.ini [components] section:

tracopt.versioncontrol.svn.* = enabled

... or by going into Admin | General | Plugins (Manage Plugins), and selecting the component in the Trac 1.0 plugin.


CommitTicketUpdater is working after following the instructions to enable components CommitTicketReferenceMacro and CommitTicketUpdater. 


CodeReviewerPlugin working.

Your Face is a Python

I was asked to find a way to programmatically analyze some log files - those files are a tab delimited format with something like 6 fields of data. This sort of thing I might have done in Perl at one time. However, having been some very long time since I did anything in Perl, and, I don't know, just not finding Perl very intuitive right now for some reason. With my recent discovery of the Trac software project management system, all written in Python, I decided it was time to jump right into some Python programming.

I have to say that it was pretty easy to knock together a simple text file parser... Python seems to be very clean and to the point. Maybe one day I'll stop using shell scripts and sed for everything (when all you have is a hammer, yada yada )..

Trac Setup

Trying to setup a Ubuntu Virtual Box to evaluate Trac (issue tracking system for software development projects). 


There were a lot of installation steps, since it requires setting up Subversion in Apache in addtion to the Trac server itself. There is plenty of documentation how to do this, but I found a handy guide by David Winter that gets right to the point.

One small change I made is using SVNParentPath, with multiple repos under /var/lib/svn, e.g.

  DAV svn
  SVNParentPath /var/lib/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user


I installed Trac (version 0.12.2-1build1) using apt-get.
Evaluation of some software peer review plugins for Trac:


PeerReviewPlugin: installed from the downloaded source zip file and followed the standard Trac plugin install instructions. When I attempted to open a new review I got the error "'NoneType' object has no attribute 'youngest_rev'". There was already a ticket - 7034 - for this issue and the multiple-repo.patch  seems to address the problem. But when creating a new code review ... how to easily add the files based on a diff or a changeset? like the line by line comments though.


I want to see the files committed in conjunction with the ticket ... TicketModifiedFilesPlugin ...
but only worked on some tickets references?

Try CommitTicketUpdater and follow the instructions to enable the component.
Appears to setup correctly, but no information is added to tickets.
Tried some advice from the webs (maybe wasn't necessary after all?):
 However, the updater requires the changeset author to have TICKET_MODIFY
permission to close tickets. If your commit username is different from
your Trac username, you will not have the required permission. So you
should disable that check by setting the "[ticket]
commit_ticket_update_check_perms" option to "false" in trac.ini.


... because stupid me not properly "wikifying" my tag ... brackets dummy ... [re #4]

And then all is working after one more edit to the post-commit script: 


# The Python egg cache directory is currently set to:

#  /var/www/.python-eggs
export PYTHON_EGG_CACHE="/var/lib/trac"


CodeReviewerPlugin:  ok .. simple ... no line by line comments. But get an error when try to submit the code review.

AttributeError: 'NoneType' object has no attribute 'get_changeset'

NetBeans+gdb Breakpoints Fix/Workaround

NetBeans and gdb apparently don't always work well together.  If you find that the debugger won't stop on breakpoints, there is an easy fix. (I believe this applies to NB + MinGW, not NB + Cygwin).

In Windows XP, I added the additional command arguments, i.e. "-J-Dgdb.breakpoints.shortpaths=true", in the shortcut by appending to the "Target" string, after the program name. Yes it is true, we are still using XP at my work!

This fix seems to get breakpoints completely functional...   run to cursor (F4) still doesn't work but I guess that is just a slight nuisance.


Wait... there's more! I am surprised to find that I can't directly edit memory locations while debugging in NB. The workaround is to go directly to the console available in NB, but the console is not enabled by default in order to protect the innocent. There is an additional command line parameter which will enable the gdb console:

-J-Dgdb.console.window=true

Unfortunately, due to limitation of the gdb remote protocol, NB is not immediately notified of changes made to memory inside the gdb console... this requires closing and then reopening the memory window in order to force NB to synchronize with gdb.

Galaga Z80 Disassembly Uploaded

I've been pretty sidetracked lately but I finally got around to uploading the code for the Galaga Disassembly Project.

In order to rebuild the code and generate the ROM images for the program, you need to have a build environment with the asz80 assembler and sdcc compiler tools installed.

I've been working on and off on this project since 2001 (mostly off!). In 2001 I disassembled most of the code, primarily using MAME to analyze the code in the emulator and dump it to dis-assembly files. At the time I was building the resulting assembly code with a Z80 assembler that I had modified to support some of the undocumented opcodes. After a few months I moved on to other projects, and the project was not touched for some time.

In 2010 I got interested again after learning about the sdcc compiler. SDCC is interesting in that it targets the C language to many 8-bit micros. It is based on the asz80, which is a very advanced assembler and fairly unique in that it incorporates a linker. With this kind of compiler capability, I entertained the idea of porting the Galaga code to C on the original hardware Z80 architecture, but dropped that plan when I got interested in building C programs in gcc-m68k on the Genesis. I did a little work re-writing the Galaga code on the Genesis, but I doubt that will ever get completed. I've been looking a bit at SDL lately so maybe that's the direction I'll go.

The Galaga code is pretty fascinating in my opinion. Ideally I would have it translated to C, while preserving the structure and data organization as much as possible. We'll see what happens!

Spice It Up

I do not go around trying to pass myself off as a EE, but embedded software development does require a fair amount of knowledge in electronics and I thought it was high time to brush up on my circuit analysis skills ...a professional improvement activity! We have a PSpice license at my work, but it is usually needed by our EE for working on the board layout. I went looking for an alternative and discovered LTspice. Sadly this is only available for Windows, but it is free, and seems to provide fairly complete SPICE functionality in a GUI environment. I thought I'd make a few notes from my learning activities.

The following circuit is extracted from the fueling controller for which I write software in my job as a Control Systems Engineer. I thought I understood the function of the circuit, but it caused me considerable grief and wasted time trying to demonstrate the expected behavior in LTSpice.

In the circuit, Vout is connected to the gate of an N-channel MOSFET and the gate voltage is controlled by the 5V signal at Vctl. The non-inverting input of the LM2903 is connected to a voltage reference of approximately 500mV established by the potential divider at the junction of R3 and R4. The inverting input of the 2903 would be connected to the signal Voc, such that the comparator is turned on by the presence of a voltage on Voc in excess of 500mV. The intent is that Voc would be connected to some other diagnostic or protection circuitry, and used to detect when the gate drive to the MOSFET (connected at Vout, not shown) should be disabled because of some kind of fault condition. My understanding is that it is the open-collector characteristic of the LM2903 output that enables this to work as intended. Although the comparator can't drive it's output high (allowing Vout to be 5V when Vctl pulse is high), the 2903 is nonetheless able to pull Vout low when the inverting input voltage exceeds the .5V threshold. In the example circuit, Voc is connected to ground, in order to force the comparator ON for the demonstration.

The output of the circuit is shown in the waveform trace. I believe the open-collector characteristic of the 2903 is not being correctly modeled, preventing Vout from being pulled to 0V when the Vctl pulse goes low. The LM2903 model was downloaded from the ON website. 

The following circuit, when simulated, provides the desired behavior. Vout is pulled low by Vctl even though the 2903 output state is high. It uses an LM2903 model downloaded from the Texas Instruments website.

Apparently it is "buyer beware" when using 3rd party models in SPICE!

Definitive Galaga Disassembly Project Created

Finally got around to importing some files to an svn repository on Google Code. I could not get the authentication to go through using svn command line (in Cygwin). Eventually I got it to work in Tortoise SVN ... the winning recipe is copied here for my convenience:


Comment by nbutterworth1953@gmail.com, Jan 10, 2009
Here's how to import your project using TortoiseSVN, the most popular Windows SVN client.
I assume you have created your Google Code (GC) project and it is called PROJECT and that the local source you want import is in a directory tree rooted at SOURCE.
a) Go to your GC home page and select the "Profile" menu - this will give you your UID and then click the "Settings" tab to find your PASSWORD - this is not the same as your gmail password.
b) In Windows explorer, right click n your SOURCE directory to get the Tortoise context menu and choose "Import..." This will pop up a dialog asking for the repository url. Enter the following:
https://PROJECT.googlecode.com/svn/trunk
c) You will be prompted for a userid & password - enter UID and PASSWORD described above.
Your project should now be uploaded to the GC repository. From now on you can use the Tortoise repo-browser and other tools to access it via the url above.

We'll see if it generates any interest....

PICOS18 on dsPIC

Porting application code to a new processor, the dsPIC33EP64. The present code base is from the dsPIC30, and we have a brand new board design.

Working from Code Example CE443, a simple demonstration of the Timer 1 interrupt, I could verify the operation of the board with the scope. Adding some extra test leads to the board is very necessary, as the chip pins are much too fine for probing! Any new PIC requires some time fiddling about with the configuration "fuses" to get the basic chip configuration straightened out. In this case, a matter of setting up for an external crystal with PLL, and also setting the specific pins for the ICD debugger.

I am actually running the dsPIC version of "PICOS18" and have now verified that all the basic OS timing.

Having now got the board alive and working, I now need to get the ECAN device driver setup, and then the board will begin to resemble something with slightly higher function than a mere brick!

More MegaDrive MegaFun

Last post was my notes for the build-your-own-Sega-Genesis-gcc-cross-compiler. Alternative is a pre-built kit if you are running on Windows. This one is actually much more than just the toolchain, as it is a library built around an SDK which has been in the works for a while.

Even though the sgdk is hosted in Windows, it is way easier to work with in Cygwin because the whole DOS environment is such an unwieldy piece of crap.

Now,  after unzipping the download, run the following commands in your Cygwin shell:

export PATH=$PATH:/cygdrive/d/mYJUNK/sgdk/bin
cd /cygdrive/d/mYJUNK/sgdk/sample/cube_flat
make GDK="d:/mYJUNK/sgdk" -f ../../makefile.gen

The GDK environment variable will be propagated into the makefile. Note that it uses the DOS letter, but Unix-style forward slashes.

One clever thing about this is how he used make wild-carding to use the same makefile for all the examples.

Now, go get Quest for Money and compile it. This is a very nice game with beautiful graphics and sound layers, with all the source code included and detailed descriptions of how it was developed. Thanks to Shiru for promptly answering my questions!

--target=m68k-elf

More nerd-notes. Setting up m68k cross compiler in gcc under Cygwin to build some code for Sega Genesis.

I installed the dgen Genesis emulator in the MinGW environment by building it and SDL-1.2.15 from sources. I am interested in experimenting with using the GNU debugger, with the Genesis emulator as the target, by integrating dgen with the modified Musashi 68k core.

Building the m68k-gcc may be a problem in MinGW - my gcc build for --target=m68k-elf failed with errors on 'pipe' 'fork' 'sleep' 'fcntl' etc. I don't know enough about MinGW to know if there is a workaround. It could be that I need to download newer sources for gcc ... I am using binutils-2.20.1.tar.bz2 and  gcc-core-3.4.6.tar.bz2. Why? because I did this about 2 years ago in Ubuntu and those were the files that worked for me then.

Alternatively, I should be able to run the m68k tools in Cygwin. My first binutils build in Cygwin blew up, but one update fixed it.

Here's a link to the setup that I followed, abeit with the file versions identified above, and changed coff to elf.

In addition, I found that the code I was building needed some standard C libraries and headers ... more on that later. I had a copy of newlib-1.12.0.tar.gz laying around so I built that with the same settings as binutils and gcc, i.e.

cd newlib-1.12.0/ ; ./configure --prefix=/usr/local/m68k --target=m68k-elf

So having done all that, the build is very close to complete, but there is one more error:


/usr/local/m68k/m68k-elf/lib/m68000//libmvme135.a(lseek.o): In function `lseek':
/cygdrive/d/tmp/m68k_cyg/newlib-1.12.0/m68k-elf/m68000/libgloss/m68k/../../../.././libgloss/m68k/../lseek.c:28: undefined reference to `__errno'

I hunted around for a second and did not find a tight solution, so I simply improvised and added the necessary definition to one of the C files in my sources:

int __errno;

... and now the make completes!

Invincibility in Galaga

It's simple.... just disable the periodic task at address 0x05EE in the "slave" CPU ('sub' Z80 in MAME). That routine handles the collision detection, so if it isn't executed, the evil-mongers can shoot and ram you till doomsday with no effect. Rebuild the code and voila...

Problem resolved with NetBeans+gdb

Apparently NetBeans is still burdened with some issues when it comes to C++ and gdb integration. I previously described changing the project tool suite from Cygwin to MinGW and back to Cygwin. This came about when gdb just mysteriously stopped working. Then I completely rebuilt my project from scratch. gdb working again. Adding files back to the project one-by-one and checking in changes to source control. Oh no gdb not working again. Back out the last set of changes. gdb still not working !@#$@!#$@!#$#$#@$. Try a new simple project.. gdb working. It must be something I've screwed up in my real project settings. I'm new to NB so looking at the project.xml isn't helping much, but strangely enough I can't even find anything change in my project xml files.  OK, do a clean checkout from source control, even my comments in the log say proudly "gdb is working". But gdb is not working even on a fresh checkout. WTF WTF WTF. OK ... nothing works right on Windows. Set everything up in Ubuntu. gdb working! Curse you Windows you have cost me a week on this stupid issue. Happily debugging my project now. WTF WTF WTF gdb is not working. Try cleaning out the project again. Restart NB. Restart Ubuntu. No joy. Open up  Debugger Console in NB. There's that message again "internal-error: is_thread_state: Assertion `tp' failed" Back to the web.... when I read the phrase 're-add all my watches" in the bug report, it suddenly struck me that it was setting the watches that was killing gdb. (I never made the connection before because I had actually been able to get through a couple runs of the program with the watches working before gdb croaked.)

I guess the upside of all this I got REAL familiar with the project files and settings in NB. Actually, while I was running in Ubuntu, I noticed the ".netbeans" in my home directory, which must be where NB would have stored the debugger configuration i.e. breakpoints, watches, etc. Thus explaining why the gdb fault condition could not be fixed by checking out a fresh copy of the project.

One thing I haven't determined if any of this is related to the fact that I am using the capability of NB to integrate with CUnit.

Cygwin or MinGW with Netbeans?

On Windows, there are two options to use the GNU build system: with Cygwin and MinGW.

There are valid technical reasons why one might prefer MinGW over Cygwin. In fact, there even seems to be some issues with NB and gdb in the Cygwin environment. My first experience with NB seemed to go pretty well - I was able to debug into unit test modules created with the CUnit framework. I did however observe one odd thing in that I was not able to use the Debug 'Run to Cursor' (F4) feature - I get a popup box with the warning message "No source file named D.". I believe this is related to the bug. On my system, gdb -v shows the following:

$ gdb -v
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)

I went ahead and switched the project to Mingw.


Follow instructions to setup MinGW Compilers and Tools.

Now the problems start.

Our project code (target is dsPIC30) is not compatible with gcc 3.4.x.whatever in MinGW for a couple of reasons. One is the use of newer compiler directive "-Wno-attributes". Another is the use of binary literal constants in the code.

Anyway, I  installed GCC 4.3.3 for Windows and it seemed to take care of those issues.

As I mentioned previously, it is necessary to revert to CUnit-2.1-0 to achieve complete integration with NB.

You might think you could try to simply download a pre-built binary of a CUNIT build for windows ... but it is probably linked against different libc libraries that won't be compatible with the MinGW you have installed.

Building CUnit from the sources is straightforward (the "configure-make-install" process) but that does require availability of automake/autoconf tools on your build system. I had to go ahead and Install MSYS DTK 1.0 as per instructions on the MinGW site.  (If you followed the instructions from NetBeans to the letter then you probably did not  "install the DTK or the core files mentioned in the wiki page").

Here we go ... Oh goody, more errors:
configure.in:4: error: Autoconf version 2.58 or higher is required

I found some advice on the web about updating packages in MinGW.

Installed msys-autoconf-2.59.tar.bz2 (updated autoconf to version 2.59. ). In MSYS window:

cd /
tar xvjfp /d/dload/msys-autoconf-2.59.tar.bz2


Compiled and installed CUnit from source (configure --debug)

Add the paths for CUNIT library and headers to my project:
../../../../msys/1.0/local/include
../../../../msys/1.0/local/lib

Now I can debug into the Unit Test module. However, the test runner seems to go out into the weeds. After debugging into CUnit, I find that the code hangs up on the following:

"fprintf(stdout,  ..." f_pTestStartMessageHandler

At this point, I am pretty disgusted with MinGW, give up and go back to Cygwin!

It seems that I have somehow deleted the CUnit libraries and header files that I had previously installed into my Cygwin environment. After rebuilding and reinstalling CUnit, and rebuilding my code, I find that I have some compilation errors in my project which hadn't been there before when trying to run the unit test module (Alt+F6):

build/Debug/Cygwin_4.x-Windows/main_nomain.o: In function `bswap_16':
/usr/include/byteswap.h:20: multiple definition of `_bswap_16'


The errors aren't there when running the main project (F6).

I find that the error is precipitated by the presence of the standard  #include :

#include 

... so if I need to print or open files I'm screwed!.

Better way to access share folder in VirtualBox

I should make an addendum to comments I made some time ago regarding setting up a VirtualBox share folder. At the time, I had found a work around was to simply remount the share folder with the uid/guid of my user account. However, I realized recently that the more better righter way to do this would be add my user to the vboxsf group. This is easy to do:

sudo usermod -a -G vboxsf myuser

The result: VBox can automatically mount the Share Folder, as shown here...

Factoring out some drudgery from Unit Testing

I discovered that there is a nice set of features in NetBeans to automate some (but not nearly all!) of the grunt work associated with software Unit Testing. This is my first experience with NB, and I am very impressed with the degree to which Unit Testing work flow is incorporated into theNetBeans IDE. NB provides built in support for the C Unit Testing Framework (in addition to its own built in "Simple" Unit Testing framework).

Unfortunately, NB doesn't completely work with the latest C Unit (version 2.1.2). I got past this issue by building CUnit 2.1.0 from source code, which may introduce yet another issue. If NB complains that the cunit library is not detected, it is because the C Unit library and/or header files have not been found in the expected locations. The C Unit source is set up to install C Unit libraries and header files under /usr/local by default. Rather than changing the default CU install locations or changing the default path settings in my NB project,  I simply made a couple of sym links to fix things up:

ln -s /usr/local/lib/libcunit.a /lib 
ln -s /usr/local/include/CUnit /usr/include

(or alternatively, just add the lib and include paths under Project Properties C Compiler and Linker configurations, and ignore the warning from NB that cunit library is not detected).

The result...

C Unit reports out through NetBeans!

Update 9/18/2013:
Found this post  advising the use of CUnit 2.1.0 due to incompatibility of output format with NB 7.0
Now running CUnit 2.1.2.with NB 7.3 without issue. CUnit and CPPUnit both installed from Cygwin.

Simulink Fun

In my day job I write software for embedded control systems - actually most of my time in the last few months has been spent spent working with Simulink Coder. I put a question out there several weeks ago, to which a usable answer was provided within a surprisingly short time. However, only in the last few days has my Simulink expertise advanced to the point to where I actually understood how to get this to work. I already knew how to define mpt.Signal objects with attribute ImportedExtern which would pick up the actual definition from legacy code. But objects defined that way would not be accepted by Simulink as inputs to a Table Lookup block. What I finally realized was that those objects must be defined as mpt.Parameter instead. I also discovered that using n-D Lookup Table (instead of the simplified 2-D Lookup Table) offered some additional flexibility, such as allowing input table data of integer type (as opposed to the default double precision type).