Adding extensions to Visual Studio Shell

It is not well known, but you can install extensions into Visual Studio Shell (but not the Express versions of Visual Studio).

Extensions (for VS 2010/2012) and/or plugins (for VS 2008 and earlier) were traditionally targeted at the commercial versions of VS i.e. Standard/Professional/Enterprise/etc., and not the free versions such as Express. But VS Shell is a bit of an anomaly in this regard – it is free but you can install extensions into it.

Of course VS Shell does not come with any MS compilers and such, but there are now a small number of extensions (for VS 2010/2012) and/or plugins (for VS 2008 and ever earlier) for 3rd party compilers. For example I use VS 2008 Pro with the Visual-D plugin (targeting the D compiler of course).

This is very nice as you get a really powerful IDE along with your favourite (fancy-open-source-or-something) language. The only problem seems to be that many of the well known mainstream extensions to enhance VS do not want to install into the Shell version of VS, and for the really annoying reason that the developers typically just “forgot” to specify it as a valid installation target in the install manifest.

Well, this is a problem no more! A fellow D user (D-Ratiseur) has done a detailed forum posting (here) on how to edit the downloaded extension to achieve this! He also list a number of extensions which he successfully installed this way into VS Shell.

Short but nice D review: “A look at the D programming language”

Long time D user Ferdinand Górski has written a relatively short, but quite nice D review here.

Even though he is a D fan, the review is not all roses… he also addresses the GC shortcomings. As part of this he shows some example code to create a custom _new allocator (and _delete de-allocator) if you need to avoid using the GC.

To clear an Associate Array in D

From this D forum thread it transpires that D does not currently provide an easy way to clear an associative array.

It seems the only way currently is to iterate over the array and remove each element individually.

In the linked forum thread reader Andrea Fontana proposed the following nifty template functions to do this until a library solution is added to the Runtime or Phobos library:

void removeAll(T, K)(T[K] arr)
{
	foreach(k; arr.keys)
		arr.remove(k);
}

Or alternatively this:

import std.traits;
void removeAll(T)(T arr) if (isAssociativeArray!T)
{
	foreach(k; arr.keys)
		arr.remove(k);
}

Then, by making use of UFCS, the result is quite palatable:

string[int] test;
test[10] = "hello";
test[20] = "world";

test.writeln;
test.removeAll;
test.writeln;

DMD -L linkerflag

Executing DMD without any command line arguments displays all the compiler switches/flags. When you do this the -L flag is described as “Linkerflag – pass linker flag to linker“. Not very illuminating. From the D forums (http://forum.dlang.org/thread/yfihvlvherkbdzvfuhsl@forum.dlang.org) I got this:

For Windows this flag is used to specify the windows subsystem:

• -L/SUBSYSTEM:WINDOWS:4 (-L/SUBSYSTEM:WINDOWS without any numeric argument at the end default to this) – support for Win 9x and later. Arguably this will become redundant now that support for Win 9x is coming to an end.
• -L/SUBSYSTEM:WINDOWS:5 – support for Win XP and later.
• -L/SUBSYSTEM:WINDOWS:6 – ???? Is this Win Vista or later? Anyone knows?

Note that this flag also allows you to use the standard D main function, rather than WinMain. This is handy since the DRuntime will store the args argument of the main function (but you need to import core.runtime) in the Runtime.args property.

Blog postings on using GTK+ and Libcurl in D

Nice articles on http://kalekold.net/ on:

• Cross-platform GUI Programming Using D And Gtk+. Targets Windows and Ubuntu.
• Getting the Built-in Libcurl Library Working In D on Windows. Libcurl is a commonly used library to transfer data over a network.

Nice article on using CTFE (Compile Time Function Evaluation) in D

CTFE is one of those nifty and very powerful features in D which is always mentioned in every review of D, but I have often wondered how widespread its actual use is. The typical “hello-world” example for CFTE is to compute the factorial of a value during compile time, which I frankly have never had to do as part of a real-world programming task.

Previously I was of the opinion that CTFE finds most of its use in template-metaprogramming, which in itself is such a specialized and esoteric field that I’ve suspected that CTFE usage is actually not that widespread.

The other typical use case is to pre-compute some commonly occurring value during compile time, and then use it as immutable constant during run-time – to give your run-time performance a boost. The typical way to do this would not be to spend much time upfront on this (“premature optimization being the root of all evil” according to Donald Knuth), but to profile your code once it is running to find any potential bottle-necks, and see if if you can optimize it (and here CTFE would be a potential optimization technique).

My problem with this is that I personally cannot remember a single occasion where CTFE was possible on those pieces of code that I wanted or needed to optimize. There was always some run-time computed entity that made CTFE impossible. So personally I have never had a good use-case for CTFE.

Well this blog gives a very nice use-case in typical 3D programming – and no fancy template-metaprogramming is involved.

Hmmm, maybe my previous opinion was skewed by impressions from template-metaprogramming in C++  – which is truly mid-bending stuff and far removed from every-day C++ programming.

CTFE is definitely more useful in D than in C++, so hopefully I will get some use of it myself soon!

MAKE, ehh… NMAKE shenanigans with building & installing ERIC Python IDE

Even though I prefer strongly typed languages such as C/C++, D, Pascal, etc, I am finding it hard to avoid the growing dominance of dynamic languages in some quarters. Well, okay, I can no longer avoid Python to be more specific.  Junior needs it for a programming course, so I am going to have to step up to the party if he is going to ask me anything!

As a result I decided to install the whole shebang (IDE, Python itself, etc.) to see how good Python really is (I’ve heard lots of good things about it). I’ll post later on that. So this post is really just on how to set up the “Python ecosystem” i.e. the IDE/editor/debugger of my choice.

I started with Sublime Text 2 (which I have been checking out in parallel) as my editor-of-choice for Python, but quickly decided to switch to the Eric Python IDE, at least for starters. It seems easy enough to write and run Python code in ST2, but I could not sort out symbolic debugging and did not want to spend too much time on this. With the Eric IDE things just looked a lot easier i.e. everything is nicely integrated – including the debugger.

I have installed CPython 2.7.3 on my system, so I needed to use the Eric4 Python IDE. For this you also need to have also pre-installed:

• Qt (v4.6.0 or better – I have v4.6.3 installed)
• PyQt (v4.6.0 or better – I downloaded v4.9.3)
• QScintilla (v2.2.0 or better – I downloaded v2.6.2)

It isn’t mentioned on the Eric Python IDE downlaod page, but PyQt also requires SIP. (I downlaoded SIP v4.13.3).

Note it is very important to install everything in the right order. From the Eric4 installation Readme you have install in this order:

1. Qt4
2. Build + install SIP
3. Build + install QScintalla2
4. Build + install PyQt4
5. Build + install QScintalla2 Python bindings.
6. Eric4/Eric5

On my system I am already using Qt under Visual C++ (VS2008 Professional). As a result I did not want to download the PyQt Windows binary installer, since that includes a copy of Qt as well as various Qt tools (which I have already installed and have been using for quite some time). Qt anyway is massive (and takes ages to build), so I really wanted to avoid redoing that.

This meant I had to download the PyQt Source package, and rebuild that. But for this you have to install SIP and build SIP 1st. So it all starts with SIP – and this is where the MAKE/NMAKE fun started…

SIP installation

1. After unzipping the  SIP archive I ran (with default arguments):

python configure.py

This creates a number of C/CPP files, some python scripts as well as a number of MakeFiles. The next step is then to build SIP by using the generated MakeFile – which will use your included C/C++ compiler. In my case this did not work though:

• The MakeFile had calls to $(MAKE) which can be problematic if your system contains multiple make.exe (or derivatives). On my system the Path environment variable caused this to resolve to the Digital Mars Make utility, which could not parse the SIP MakeFile script.
• Only when I analysed this error did I remember that the Microsoft version is called nmake.exe, and not make.exe.
• The main problem with using the MS NMAKE utility is that the Visual Studio installer does not update the Path environment variable with the path; in fact the Visual Studio Project system does not even use nmake from inside the IDE; it is only used for command-line building. In this case I could of course update the Path environment variable myself, but (in my opinion) the easiest way to handle this is to simply run the vsvars32.bat file included with VS (this only modifies the Path environment variable for the current session). For my VS2008 installation I simply ran from a Console command line (and used this same Console for the installation of everything described here):

c:\>"C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"

• In addition you also have to add a MAKE=nmake to the generated SIP MakeFile in the root SIP folder. The 1st few lines of this MakeFile will look like this:

MAKE=nmake

all:
	cd sipgen
	$(MAKE)
	@cd ..
	...etc...

2. SIP will now successfully build by running (note nmake, not make):

nmake

3. And SIP will now install by running:

nmake install

4. (And to clean run ‘nmake clean‘)

QScintilla2 installation

Building QScintilla proceeds by first using Qt’s qmake on the QScintilla project file as follows :

qmake qscintilla.pro

The next step is to build the shared QScintilla DLLs using your C++ compiler. As before you need to make sure you have run vsvars32.bat (see above) as well as now add the familiar MAKE=nmake to the root MakeFile. Then you run (by now familiar):

nmake

And here the wheels fell off when NMAKE failed with:

.\ListBoxQt.cpp(250) : error C2039: 'convertFromImage' : is not a member of 'QPixmap'
        c:\qt\4.6.3\include\qtgui\../../src/gui/image/qpixmap.h(70) : see declaration of 'QPixmap'

A quick investigation showed that the compiler was unhappy with the call to convertFromImage(..), which was not a member of Qt’s QPixmap – at least not in Qt v4.6.3 that I was using. It was still supported as part of Qt3 Support, but I do not have Qt3 support enabled. But, interestingly enough, convertFromImage(..) was again a member of QPixmap in Qt v4.7.x or later (reintroduced no less!). So the QScintilla version I downloaded was based on a later version of Qt than I was using.

Hmmm, how to proceed? Basically, I now had two choices:

• Uninstall Qt v4.6.3. and install Qt v4.7.0 or later – which will take ages to download on my slow connection and even longer to build (and which I have been putting off for many months now!). Not an attractive option at all!
• Modify the QScintilla sources (and hope I know what I am doing!).

A quick investigation showed that the code in question was quite simple. So this…

void QsciListBoxQt::RegisterRGBAImage(int type, int, int,
        const unsigned char *pixelsImage)
{
    QPixmap pm;

    pm.convertFromImage(*reinterpret_cast<const QImage *>(pixelsImage));
    ...

…was quickly replaced by this…

void QsciListBoxQt::RegisterRGBAImage(int type, int, int,
        const unsigned char *pixelsImage)
{
    QPixmap pm;

    pm = QPixmap::fromImage(*reinterpret_cast<const QImage *>(pixelsImage));
    ...

…and the compiler was happy once again and QScintalla build fine. As before nmake install did the necessary installation.

PyQt4 installation

Check the included Readme but, in short, PyQt installation follows exactly the same process and sequence as SIP. As before, the 1st step is to run:

python configure.py

Then, as before add MAKE=nmake to the top of the MakeFile in  the root PyQt folder. Note that you do not have to do this for any of the other generated MakeFile‘s (in sub-folders from the root PyQt folder).

Now, as before, you can execute nmake followed by nmake install from the command line. Note this takes ages to build as this creates and builds the bindings for the whole of Qt.

According to the PyQt installation guide, you may also want to copy %QTDIR%\lib\qscintilla2.dll to %QTDIR%\bin at this point. Judging by the types alone (lib vs dll) this seems a good idea.

Note that, as mentioned previously, you need to install QScintilla before PyQt.

QScintilla2 Python bindings

Now you have to return to QScintilla and, as the final step,  you have to create, build and install the Python bindings (but only after installing PyQt). Again this entails a directory change (see instructions) and follows the by-now familiar sequence:

python configure.py
nmake
nmake install

As before you can clean afterwards with nmake clean.

Eric4 IDE

If all the previous installations succeeded (and were in the right order), you install Eric with a simple:

python install.py

And that is it! Apparently, python uninstall.py will do the necessary if you want to uninstall the Eric4 IDE. Obviously I have not tried that.

To launch the Eric4 IDE you run eric4.bat in your main Python folder (for me c:\python27).  There are also various other batch files (which I still have to investigate), including one called eric4_tray.bat which installs a icon in your system tray, which you can use to launch Eric4.