Entries Tagged 'Programming' ↓

Through a recent stackoverflow question I learned that Posix reserves any identifier ending in “_t”. News to me! I really liked naming my classes starting with a lowercase letter and ending in an “_t”. This permits code like:

     class list_t { };
     ...
     int
     main(int argc, char *argv[])
     {
          list_t list;
     }

This pretty much forces me to start any type in the global namespace with a capitol letter (not my preference). To keep things consistent, that means all my classes/structs will now start with a capitol letter. See here for the posix rules.

1. Install perl (needed for building OpenSSL).
2. Follow OpenSSL instructions to build and install (README.W32 or README.W64, use the masm target). I installed OpenSSL into the same prefix that I’m using for Qt.
3. Copy the Qt mkspeks directory to the Qt prefix directory.
4. Run configure, something like:
   ./configure -release -no-qt3support -prefix C:\qt\4.5.2 -qt-libjpeg -qt-libpng -openssl -I c:\qt\4.5.2\include -L c:\qt\4.5.2\bin

   (based on instructions from http://wiki.secondlife.com/wiki/QtWebkitWin32BuildInstructions)

5. nmake && nmake install

Pygments has a very short tutorial for integrating itself with docutils here: http://pygments.org/docs/rstdirective/. However, that was not enough info to get me started using Pygments with rst2html.py. Here are the missing steps:

1. Copy the Pygments supplied rst-directive.py to your docutils installation. Something like:

   cp Pygments/external/rst-directive.py \
    .../site-packages/docutils/parsers/rst/directives/rst_directive.py

   Notice that rst-directive.py became rst_directive.py (dash changed to underscore).

2. Modify rst_directive.py in the docutils directives directory to set INLINESTYLES = True and add a style option to the formatter. Something like:

   # Set to True if you want inline CSS styles instead of classes
   INLINESTYLES = True
   
   from pygments.formatters import HtmlFormatter
   
   # The default formatter
   DEFAULT = HtmlFormatter(noclasses=INLINESTYLES, style='trac')

3. Modify rst2html.py to import the Pygments directive. I added the following line:

   from docutils.parsers.rst.directives import rst_directive

That’s it. Now I can use the ..sourcecode directive in my rst documents. For example:

.. sourcecode:: c++
	int
	main(int argc, char *argv[])
	{
	}

When I started using jEdit it took me a while to figure out how to begin building and developing jEdit and its plugins. I don’t know of a well documented tutorial, so I’m documenting the way I get started here. I typically develop on Windows, but most steps equally apply on Linux. I strongly recommend using jEdit trunk, it is very stable and is required for the latest and greatest plugins.

1. Install subversion
2. Install the Sun Java JDK. Unfortunately, the completely free IcedTea JDK isn’t up to running jEdit.
3. Download Apache ant and put the bin directory in your path.
4. You’ll need xsltproc and docbook to build the jEdit documentation. Download the docbook xsl scripts from http://sourceforge.net/project/showfiles.php?group_id=21935&package_id=16608&release_id=603854 and unpack somewhere (I unpack into c:\workspace\docbook, this path is needed later in step 7). The above links to version 1.74. The most recent version can be found from http://wiki.docbook.org/topic/DocBookXslStylesheets.
5. Download xsltproc. I downloaded a binary from http://xmlsoft.org/XSLT/downloads.html. On Windows, you’ll also need iconv.dll, zlib1.dll, libxslt.dll, libxml2.dll, and libexslt.dll to run xsltproc.exe. Put the exe and dll’s in your path.
6. Check-out jEdit from svn:

   svn co https://jedit.svn.sourceforge.net/svnroot/jedit/jEdit/trunk jEdit

7. Create jEdit’s build.properties from the build.properties.sample file:

   cd jEdit
   cp build.properties.sample build.properties

   Edit the build.properties file to point to your xslt installation. The following are the lines I add (the path to docbook.xsl should match the directory in step 4):

   xsltproc.executable=C:\\workspace\\bin\\xsltproc.exe
   docbook.xsl=C:\\workspace\\docbook\\docbook-xsl-1.74.0
   docbook.catalog=C:\\workspace\\docbook\\docbook-xsl-1.74.0\\catalog.xml

8. Now build jEdit, run:

   ant
   ant userdocs

   This builds jedit.jar and the userdocs in the build directory (a normal jEdit prints numerous warnings that can be ignored). You can run this jEdit with something like:

   javaw.exe -Xmx1024M -Dswing.aatext=true -Dawt.useSystemAAFontSettings=lcd -Dsun.java2d.d3d=false -jar build\jedit.jar

9. If the above was successful, you should now have a .jedit settings directory in your home directory. We can now setup the necessities for building a plugin. Go to your settings directory and check-out jEdit’s build-support.

   cd ~/.jedit/jars
   svn co https://jedit.svn.sourceforge.net/svnroot/jedit/build-support/trunk build-support

10. Now copy the build-support build.properties sample and edit for your installation (should still be in ~/.jedit/jars).

    cp build-support\build.properties.sample build.properties

    Edit build.properties to set the jEdit install directory (I don’t change anything else). On my system, that line looks like this:

    jedit.install.dir=c:\\workspace\\jedit\\jEdit\\build

11. Finally, check-out a plugin to build and build it.

    svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/VoxSpell/trunk VoxSpell
    cd VoxSpell
    ant

    This should build VoxSpell and place the jar file in your settings directory plugin-jars directory. The next time you start jEdit it will find the jar file and load the plugin.

I recently wrote a tool in C++ that would run a large number of tasks in the background, parse the results, and print simple pass/fail information for each task. I used the tool as an opportunity to start using boost::threads which resembles the upcoming C++0x threading support. The multithreaded portion of the code was very simple, all contained in my own futures class.

Everything ran well, except occasionally a test would time-out. I figured this was a problem with how I was setting up the stdin/stdout pipes to the subtask (each thread would fork() to run the sub-task and use a timed poll() to wait for results). On Friday, I finally sat down to figure out what was causing the test hangs.

Turns out it had nothing to do with sub-task input and output. Each thread is responsible for one subtask. The thread creates the necessary pipes, performs some other book keeping, and then forks. The child process then transforms a vector of command line arguments to an argv[] style array, sets up stdin/stdout with dup2, and calls execvp.

To debug, I modified the parent to print the hung pid which I would attach to using gdb. Every time I attached, the child process was stuck in the same place: waiting on a mutex used by the std::string implementation.

The child process doesn’t use any threading functions, and all of its parameters are passed on the stack. However, I didn’t consider that most of libstdc++ is thread safe (I can’t find a reference that specifies exactly what is and isn’t thread safe in glibc/libstdc++). Each time the process forked, it risked forking while the underlying std::string memory mutex was being held by another thread. As documented in the pthread_atfork man page, those mutexes are not useable after the fork, and must be re-initialized with pthread_mutex_init in the child process. This caused the child process to hang indefinitely waiting on a mutex that would be released only in the parent’s process space.

The solution was to move the std::string processing before the fork. That left only dup2 calls and the execvp after the fork. Result: no more hangs!

I recently took advantage of the Windows7 beta and think it’s a great upgrade over Vista. However, anything I compiled with the Windows SDK resulted in a binary that was reported to be an invalid windows image. Turns out the issue is documented in the SDK release notes (section 5.3.6). A resource section is required (even an empty resource) before you can embed a manifest resource.