Sunday, December 15, 2013

Eclipse, CDT and the codan syntax checker

I have been using eclipse CDT recently on a legacy C++ project and it took a while for me to get the codan syntax checker to work. When it wasn't working it gave syntax errors for things that weren't syntax errors and claimed it couldn't find standard headers like stdlib.h, string.h etc. Use this command to invoke the GNU compiler so that it tells you where it is looking for includes:
g++ -E -x c++ - -v < /dev/null
These are the include directories that need to be configured. I got this tip from StackOverflow at http://stackoverflow.com/questions/11946294/dump-include-paths-from-g

You need to turn on full tracing when invoking eclipse (as explain my earlier post), then you will see if all the paths are resolved or not.

There are lots of posts of how to solve the codan problem but they are tend to be superficial and dismissive, often saying things like "put /usr/include" in the path. That is not good enough, you have to put in all the paths that the compiler uses, including the internal ones. Don't forget that when using cygwin and codan that the paths will have to be DOS-like, i.e. starting with the C:/cygwinDir..blahBlah.

Monday, December 02, 2013

How to install eclipse plugins on a machine that is cut off from the internet

Recently I have been using a proprietary eclipse plugin in a corporate environment. The plugin seems to assume java and windoze but the project was in unix-specific C/C++ and on linux. So I was faced with the task of setting up the plugin on linux. It was then I discovered that all the linux machines are cut off from the internet. What to do? I asked around and I amazed to discover that apparantly, no-one else has ever had to deal with this issue. Lots of people guessed that you just copy the jar files over from the plugins directory and restart eclipse. Wrong.

Copying files from the plugin directory plays a part in the solution but is by no means the be all and end all. For a start, sometimes the plugin is OS-specific, so it might contain DLLs (windoze) or shared libraries (UNIX). Any such plugin has to be obtained on the target machine somehow.

One of the main challenges of installing your own plugins without using a network connection is that you will have to chase down any dependencies. By default, eclipse does not tell you when there is a problem installing plugins but you really do need this information. Here is what you do:

create a file called .options which contains:
org.eclipse.equinox.p2.core/debug=true
.org.eclipse.equinox.p2.core/reconciler=true

then enter this command:
./eclipse -clean -console -consoleDebug -debug ./.options

This produces output that tells you what troubles it had loading plugins.

Under the eclipse directory create a directory called dropins. It should be a peer of plugins and features. Below dropins create eclipse and below that create plugins and features.

For any plugins that are missing, copy them from a windows environment that has them. They can be directories, files or a combination of the two. Be careful to copy to the correct target directory, either dropins/eclipse/features or dropins/eclipse/plugins depending on where it comes from in the source. To copy them, using WinCp. This is often allowed in a corporate environment.

Monday, October 07, 2013

C++ bollocks

Every now and then I come across what I call "C++ bollocks". What do I mean? I am referring to various statements made about certain aspects of C++ that are, well, complete bollocks. The statements might have been true to some extent in the
dim and distant past, but anyone still trotting out these statements in this day and age is, in my arrogant opinion, talking bollocks. Here are some examples, divided into categories.

all too frequent bollocks

  • C++ iostream are too slow. Use the printf family instead.
    As one person has pointed out via the comments, I do not have a direct refutation for this yet. The FAQ link merely explains why iostreams are generally superior.
  • C++ exceptions are too slow. Use error codes or boolean return status instead.
    see the FAQ. Also see , "Why use exceptions?"
  • Don't use std::endl, it's too slow.
    It is true that std::endl flushes the output buffer, which has a performance hit. This is even mentioned in the FAQ-lite. However, such concerns over micro-efficiency are usually misplaced. Premature optimisation is the root of all evil.
  • C++ strings are too slow. Prefer C char arrays.
    Some people prefer C to C++. Those people should leave C++ alone and work in their preferred language. Also see , "What's wrong with arrays?".
  • avoid virtual functions. The performance hit on virtual dispatch is too great.
    See the FAQ
  • always implement getters and setters as inline. It's faster.
    See the FAQ. As ever, premature optimisation is the root of all evil. People making these claims never have the figures to back them up. Their response to being challenged is "everyone knows this".
  • provide convenient implicit type conversion by implementing cast operators
    Actually you usually want to do the complete opposite of this. This is why many coding guidelines say that single arg ctors must be qualified by explicit. and that cast operators should not be written.
  • Failing to make a base class dtor virtual is no big deal. It will just result in a small memory leak.
    Wrong. It is actually undefined behaviour. See the FAQ and the Jargon file
  • saying delete mem instead of delete []mem (to go with the new type[count]) is no big deal. It will just result in a small memory leak.
    Wrong. It is actually undefined behaviour. See the FAQ and
    of course, the Jargon File
  • Use Yoda notation to guard against accidental assignment. I have a rant about this one.

infrequent bollocks

  • don't throw exceptions from constructors.
    this is from the same school of bollocks as "C++ exceptions are too slow".
    See the FAQ
  • prefer pointers to references since references dont make it clear when the object can be modified.
    See the FAQ and this Parashift article.


Thursday, September 26, 2013

A nasty .Net error in Visual Studio 2010 and how I fixed it

Every now and then I got a weird error whilst tinkering with some Visual Studio project files. The error was like this:

22>------ Build started: Project: myLibraryDll, Configuration: Release x64 ------
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(298,5): warning MSB8004: Intermediate Directory does not end with a trailing slash.  This build instance will add the slash as it is required to allow proper evaluation of the Intermediate Directory.
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018: The "VCMessage" task failed unexpectedly.
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018: System.FormatException: Index (zero based) must be greater than or equal to zero and less than the size of the argument list.
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at System.Text.StringBuilder.AppendFormat(IFormatProvider provider, String format, Object[] args)
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at System.String.Format(IFormatProvider provider, String format, Object[] args)
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at Microsoft.Build.Shared.ResourceUtilities.FormatString(String unformatted, Object[] args)
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at Microsoft.Build.Utilities.TaskLoggingHelper.FormatString(String unformatted, Object[] args)
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at Microsoft.Build.Utilities.TaskLoggingHelper.FormatResourceString(String resourceName, Object[] args)
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at Microsoft.Build.Utilities.TaskLoggingHelper.LogWarningWithCodeFromResources(String messageResourceName, Object[] messageArgs)
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at Microsoft.Build.CPPTasks.VCMessage.Execute()
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
22>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)
This is quite obscure, I think you'll agree. I eventually tracked it down to a spurious trailing slash on OutputFile. Remove it and the error goes away.

I have been bitten by this several times now so I thought if I blogged about it, then I would remember.

Wednesday, July 03, 2013

How to build libxml2 on Windows using Visual Studio

Libxml2 depends on libiconv so that is the first thing to build. Like many GNU projects it is UNIX-centric, so building on Windows is not easy. However, some kind soul has created full instructions.

Once you have libiconv you will need to copy the built library from libiconv.lib to iconv.lib. This is due to a quirk in the libxml2 build where it assumes UNIX (whose linker removes the leading "lib" characters).

Once the libxml2 source tarball has been downloaded, unzipped and de-tar'd, you will see there are instructions in win32/Readme.txt. These instructions are quite good as far as they go, but there are still a few gotchas which are covered here.

The commands need to be issued from a DOS cmd prompt. Start one. Execute the following commands to set the window up for using the Visual Studio compiler. I am using Visual Studio 2005, aka VC8 (aka vc80).

set PATH=pathToLibiconvDLL;%PATH%

rem to pck up vcvarsall.bat
set PATH=C:\Program Files (x86)\Microsoft Visual Studio 8\VC;%PATH%

rem to pick up nmake and compiler
set PATH=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin;%PATH%

cd win32
cscript configure.js compiler=msvc prefix=whereYouWantToInstall include=libiconvIncludeDir lib=libiconvLibDir debug=no

This will create an nmake file called Makefile.msvc. You need to edit it to set various compiler macros. Near line 65 you should see a line that looks like this:

CFLAGS = $(CFLAGS) /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE

Follow it with this line:

CFLAGS = $(CFLAGS) /D_SECURE_SCL=0 /D_SCL_SECURE_NO_WARNINGS /D_SCL_SECURE_NO_DEPRECATE

This will ensure that those nasty checked iterators are turned off along with other string checking nastiness that noone wants.
Then enter these commands:

vcvarsall.bat
nmake
nmake install

You will now have an install directory with subdirectories include, bin and lib.

The bin directory will contain several test programs and the utility xmllint. But there is a problem. The exes do not have the manifests embedded. For each executable you need to run the mt command to add the manifest to the exe. The format of the command is:

mt -manifest pathToManifestFile -outputresource:pathToExe;1

Note the semicolon one which is part of the command.

If you dont merge the manifest with the executable the first error you get is that msvcr80.dll cannot be found. You can also get the error R6034.



Thursday, April 18, 2013

problems with git svn clone on windoze using cygwin

I am back in a windoze development environment and am using subversion (svn) for source code control. I am trying to experiment with git so I thought I would try to use git in conjunction with svn. This is turning out to be quite a bit of trouble. It all depends on which version of svn you are using.

Basically version 1.7 is fine but version 1.6 gives horrendous problems. Version 1.6 is being used because the server backend is version 1.6.

Googling reveals that the git svn clone problems in 1.6 are acknowledged and reported as fixed in version 1.7. Deep sigh. The problems are due to missing components. Several people have made attempts to build or install the missing components but I have not come across any success stories yet. And all my attempts failed.

You might think why not just move to version 1.7. Well, there's a reason and it's to do with a bit of svn nastiness. It is to do with repo format and compatibility and is discussed in the svn release notes at http://subversion.apache.org/docs/release-notes/1.7.html. The notes says:

Subversion 1.7 servers use the same repository format as Subversion 1.6. Therefore, it is possible to seamlessly upgrade and downgrade between 1.6.x and 1.7.x servers without changing the format of the on-disk repositories.

People have quoted this and concluded that:

There is no need to do anything, your working copy will be upgraded, and will still be able to talk to the 1.6 server.


However, someone on stackoverflow responded with:

Note: TortoiseSVN will update the working copy format which will create problems for older clients. This is only a problem if you have an environment where multiple different clients are used to access the same working copy. E.g. if you access the working copy from TortoisSVN and from IDE (e.g. PHPStorm) that only supports 1.6 working copy format.

This is exactly the issue for me. Changing to a 1.7 command line client forces me to change all clients. So that'll be native WIN32 command line, cygwin command line and TortoiseSVN. And all because the client changes the working copy so it won't work with older clients. I reckon this is a nasty on the part of SVN.

I am getting quite desperate to move to git now since I am grappling with some merge issues that are decidedly more awkward in svn. I may have to bite the bullet and change all my svn clients to be version 1.7. I hope to add to this blog entry to report any issues when I get around to making the move.


Wednesday, February 20, 2013

The daily scrum - not!

More thoughts about the so-called daily scrum

Further to my moaning entitled "when is a scrum not a scrum" I have seen people moaning about a related phenomenon that is starting to be called "cargo cult scrum". Now after looking into this for a bit I have decided that my situation is not exactly "cargo cult scrum" but there are some similarities so I will start by talking about it.


The cargo cult

Cargo Cult Scrum is what happens when you adopt the practices,vocabulary, and artifacts of scrum but you don't understand why or how they work. It comes from the phrase "cargo cult", which I only came across a few years ago. Here is a brief summary culled from wikipedia, for those who haven't come across it yet.
The wikipedia article opens with:

"A cargo cult is a religious practice that has appeared in many traditional pre-industrial tribal societies in the wake of interaction with technologically advanced cultures. The cults focus on obtaining the material wealth the "cargo") of the advanced culture through magic and religious rituals and practices. Cult members believe that the wealth was intended for them by their deities and ancestors."

It talks about the behaviour of Melanesian islanders during and after WW2, living on islands occupied by the military. It says:

"With the end of the war, the military abandoned the airbases and stopped dropping cargo. In response, charismatic individuals developed cults among remote Melanesian populations that promised to bestow on their followers deliveries of food, arms, Jeeps, etc. The cult leaders explained that the cargo would be gifts from their own ancestors, or other sources, as had occurred with the outsider armies. In attempts to get cargo to fall by parachute or land in planes or ships again, islanders imitated the same practices they had seen the soldiers, sailors, and airmen use. Cult behaviors usually involved mimicking the day to day activities and dress styles of US soldiers, such as performing parade ground drills with wooden or salvaged rifles. The islanders carved headphones from wood and wore them while sitting in fabricated control towers. They waved the landing signals while standing on the runways. They lit signal fires and torches to light up runways and lighthouses."


Cargo cult scrum examples

Now I hope you understand where the phrase "cargo cult scrum" comes from and what it refers to. I am now seeing blogs appear where developers complain about it and describe it. I suppose I am just adding to that list. Here are some examples I found:

  • I recently attended a meeting at a company that considers itself to be agile. It was a regular meeting that occurred every two weeks. It was not attended by a scrum team, but instead by a bunch of people from two different groups. The three questions were not used. The meeting was scheduled for, and took, 30 minutes. Yet the meeting was called a scrum. Other meetings at this company are called scrums, so much so that "scrum" has become a synonym for "meeting". This is a cargo cult. The true meaning of "daily scrum" has been lost, if it was ever apprehended in the first place.
  • An example from a [paraphrased] conversation:
    Customer: Oh yes, we've been doing agile for a while.
    Coach: That's great! So you haven't had any trouble getting the Product Owner to work closely with the team?
    Customer: Well, we...uh...don't really have a Product Owner.
    Coach: Oh. Well, who keeps the Product Backlog in shape?
    Customer: Well, we...uh...don't really have a Product Backlog, per se.
    Coach: Oh. So how do you plan your sprints?
    Customer: Well, we really don't do that in a very formal way. But we do meet every morning. That's what it's all about, right?
  • I saw a good summary by an agile coach which said:
    A "good" scrum implementation will be a wonderful experience only if you have people who want to be a part of a cross-functional team who trust and respect one another. You also need a spirit of self reflection, and a desire to always improve and serve the customer. You also have to have leadership that is there for support. If you hate being a part of a cross functional team, and just want to be left alone to code (or whatever) heads down, then any agile or lean
    methodology will be sheer torture. If you have a strong team with micro managers, then it will be sheer torture. If you have both...ouch, I feel bad for everyone there.
  • Another person summed it up with:
    The problem with Scrum and daily scrums is:
    1) Organizations that are doing fine do not need to change anything
    2) Organizations that are failing want a quick fix. So they choose scrum
    3) Now they are doing a bunch of quick fixes, calling it progress, doing Cargo Cult Scrum, and making people miserable
    That's what I see in the field. Failed organizations choose scrum because they are failing, and then they fail harder with scrum but pretend they are on a path to salvation.

A name has yet to be invented

So, if I am not in a cargo cult scrum situation, what situation am I in? As far as I know it doesn't have a name yet. One thing it isn't is "ScrumBut", i.e. "we do scrum, but...". That's because there are no scrum practices at all.
The only reason scrum is mentioned is because the meeting is called a scrum instead of being called a meeting. Here are some of the symptoms:

  • The daily meeting is called a scrum and consists of "what did you do since the last scrum, what are you doing now?" for each attendee. Everyone waits patiently and politely for the meeting to end, saying the minimum possible when it is their turn.
  • The daily meeting gradually reduces in frequency until it is officially only once a week but in practice it is not even that. It is scheduled once a week but is frequently cancelled at point blank range ("we're too busy to have it").
  • The meeting is attendees rather than team members. There are no teams in the sense of multiple people pulling in the same direction; rather, there are disparate solo workers that do not communicate with anyone. They're not
    anti-social, it's just that the nature of their work is isolated and communication is discouraged by the management.
  • It lasts for the scheduled time, no more and no less. People are cut short if it looks like it is going to over-run. As attendees learn that it is has almost no value they learn to speak less and less to avoid the danger of overrun.
  • The meeting does not talk about progress, how we are going to get there, the need to improve, remove obstacles etc. Instead it is about what time is being booked to (I worked on blah, today I will continue working on blah)..
  • There is no allocation of work from the backlog; there is no backlog! There are no stories and no use-cases and no input from the business. There are no iterations, no releases, no burndown charts. Hence these things cannot be talked about in the meeting!
  • People turn up late, the meeting starts late. The non-communication, lack of purpose or value and general lack
    of interest and the fact that the meeting is often cancelled at the last minute, means there is little reason to be there on time.
  • They are not standups. No one stands up. Everyone is seated. The meeting typically lasts for one hour. Try standing up for that length of time. The word "scrum" is used not but they have not heard of "standups". Or if they have then they agree that one hour is a long time to be standing up! If you were to point out that standups should take around 15 minutes you will be told that with the number of attendees this is impossible. Plus it's impossible because of the time it takes for the management to say its piece.

Tuesday, February 12, 2013

Barf bags

Q. When is a brown bag not a brown bag?
A. When it's not held at lunchtime.

I have noticed a tendency to call training sessions "brown bags". I reckon it is part of the same tendency that causes people to say "scrum" when they mean "team meeting" (I use the word 'team' very loosely here).

First, here's what a brown bag is supposed to be according to wikipedia:

A brown bag seminar, session or lunch is generally a training or information session during a lunch break. "Brown bag" is representative of meals brought along by the attendees, or provided by the host. In the USA, those are often packed in brown paper bags. Brown bag seminars normally run an hour or two.

Brown bags are also described in Linda Rising's book "Fearless Change" as a way of introducing people to new ideas without it taking up official project time.

Now here's what they are not: compulsory sessions to disseminate information that is important for the project. You know the kind of thing: you are expected to attend and it is not held at lunchtime. It is not open the the general project but only to the people that are required to receive the information. It is supplied on a need-to-know basis, i.e. if they need you to know then they will tell you. There is a slideshow that is supposed to act as a substitute for attending if for some reason you cannot attend. I call these sessions 'barf bags'.