Month: July 2009

Mating Vi IMproved with Visual C++, part I

by

Maybe it’s because it is an Integrated Development Environment, but Visual C++ seems to be a little lacking in its handling of external editors (at least in the express edition I have avail). It seems the best way to get MSVC to work with Vi IMproved for editing files, is to right click on a file in the solution explorer docklet, and click “Open with”. From there one can specify a program to open the file with and force it as the default editor; the down side is the bloody thing seems to reject the concept of command line arguments.

As such, I created a new win32 application in the IDE, and stripped the fundamental code down to the following

#define GVIM_EXE    _T("P:/Editors/Vim/vim-personal/gvim.exe")
#define GVIM_ARGS   _T("--servername"), _T("MSVC"), _T("--remote-tab-silent")

int APIENTRY
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
          LPTSTR lpCmdLine, int nCmdShow)
{
        UNREFERENCED_PARAMETER(hPrevInstance);
        UNREFERENCED_PARAMETER(hInstance);
        UNREFERENCED_PARAMETER(nCmdShow);

    _texecl(GVIM_EXE, _T("gvim"), GVIM_ARGS, lpCmdLine, NULL);

    return 0;
}

Which means I get one instance of Vim running and double clicking files in the solution explorer, will open a new tab in the GVim window; gotta love an editor with a client-server feature hehe.

I have Michael Graz’s visual_studio.vim installed along with the required python for windows extensions. The plugin loads and appears to be exactly the *first* vim plugin that I can actually find a purpose for using! Except for one small problem…. the plugin can’t seem to chatter with the running instance of Visual C++ 2008 Express Edition!

Of course, I could likely jerry rig vim’s :make command to invoke vcbuild for me without much trouble.

Heh, and just for the heck of it, I wonder if a similar plugin could be written for other IDEs, like Code::Blocks, XCode, and KDevelop?

The road I’m on

by

She said life’s a lot to think about sometimes
When you’re living in between the lines
And all the stars they sparkle and shine everyday

He said life’s so hard to move in sometimes
When it feels like I’m towin’ the line
And no one even cares to ask me why I feel this way

I know you feel helpless now and I know you feel alone
That’s the same road, the same road that I am on

He said life’s a lot to think about sometimes
When you keep it all between the lines
Of everything I want and I want to find, one of these days

What you thought was real in life somehow steered you wrong
Now you just keep drivin’ tryin’ to find out where you belong

I know you feel helpless now and I know you feel alone
That’s the same road, that same road that I am on

What you thought was real in life somehow steered you wrong
Now you just keep drivin’ tryin’ to find out where you belong

I know you feel helpless now and I know you feel alone
That’s the same road, that same road that I am on

The Road I’m On, 3 Doors Down

Building vim with support for Python and Perl on Windows

by

Previously:

install a suitable version of Visual Studio / Visual C++
install a suitable version of Python
install a suitable version of Perl
open a Visual Studio Command Prompt

I have VC Express 9.0, ActivePerl 5.10.0, and Python 2.6.2 installed from Python.org’s installer.

Check out the VIM source code, you can find directions here. I suggest using CVS or SVN to make the patching life easier. Precompiled binaries of CVS and SVN are available for Windows, and it is possible to build them yourself of course ;).

I use CVS and wish to keep the tree along side my regular vim:

> cd /d P:editorsvim
> cvs -z3 -d:pserver:anonymous@vim.cvs.sf.net:/cvsroot/vim checkout -Nd vim7-cvs-src vim7
> cd vim7-cvs-srcsrc

You should know read the Make_mvc.mak makefile to find the options you are interested in using. I’ll leave the viewing the file from the command line to a Windows users intelligence (hints: more, edit, notepad, wordpad, or gvim would be useful). We have to tell nmake.exe to use this file and our options, for asses who use Visual Studio all day but don’t remember nmake: we pass it VAR=value pairs.

> nmake /F Make_mvc.mak CPUNR=i686 FEATURES=HUGE GUI=yes OLE=yes CSCOPE=yes CTAGS=ctags POSTSCRIPT=yes PYTHON=P:DevelLanguagesPython2.6 PYTHON_VER=26 PERL=P:DevelLanguagesPerl PERL_VER=510

Obviously if you want same options, adjust the paths like a good little geek.

At least on my system, MSVCs compiler refuses to build the vimrun.exe, install.exe, uninstal.exe, and xxd/xxd.exe targets (and programs). As such, I build gvim and the gvimext.dll – the targets are in the makefile. if one wants to build a vim execuitable under a diffirent name, I suggest ‘nmake /e VIM=foo /f … OPTS=… foo.exe’ to create foo.exe (default is gvim).

As such we need a place to put vim so we can actually use it.


> MKDIR ....vim-personal
> FOR %F IN (*.dll *.exe) DO XCOPY /Y %F ....vim-personal
> XCOPY /Y P:DevelLanguagesPerlbinperl510.dll ....vim-personal
> XCOPY /I /E /Y ..runtime* ....vim-personal

and one can borrow the lost vimrun and diff files from a working install. If one also juggled the names so that vim-personal became vim72, one could also borrow the install.exe file most likely…

In doing all of this, I’ve written a batch script to use in automating the thing, which is not as good as my vimbuild shell script but still works lol. When I get some time I’ll make my script also update the spell files and what nots (hint: see spellreadme.txt)

by

Hahaha, here I am wondering ok, what the hell is wrong with 

if (statement that will return false)
    DEBUG(...);
    do action;

and then I noticed, uncommenting the DEBUG() macro a few minutes ago changed the dohicky.

This is exactly why whenever I’ve written a ‘style’ file for any of the projects I’ve done (and in fact, usually follow) a note that it should *always* be if () { } and never if () just for this reason!!!

Ok, I’m so freaking stupid… I should just get some sleep and code when I can pay attention (and remember my old tool Perl).

by

Been playing a little bit of raven shield, set to some hard rock by way of www.pandora.com it makes a nice mixture. I’m still in a really pissy mood, think I might take up some OpenArena or something to pass the time for a bit more…

I’m so tired of this place.

Dark mood

by

I’m really not in a good mood right now. Tired and pissed off make for a piss poor pair. It just seems the more I’m here, the worse I feel; the more I know that something is missing from my world. Been fairly busy of late, mostly keeping myself busy, less time to think. It’s like just about anything that will fill space for a little while; rather then thinking about other issues. I’m also not looking forward to this coming week and such, because I know for what family has planned, is only likely to make me feel miserable in the long run. It’s been 21 years on earth, and I just know… being around family is usually a painful affair.

Plans as part of Operation Redeemer are more or less on schedule but things just are not going fast enough in the right directions to suit my needs; lately I feel like I’m just passing time again, but for different reasons. I draw breath, but what makes me move?

Being lazy: make.cmd

by

A short batch file that let’s me skip typing as much as possible when using vcbuild on my present projects.

@ECHO OFF
cls 
IF "%1" EQU "help" (
 ECHO %0 help           --  display this help
 ECHO %0 clean target   --  clean for "target"
 ECHO %0 target [run]   --  build and run "target"
 GOTO EXITPOINT
)

IF "%1" EQU "clean" (
 vcbuild /clean TheSolutionFile.sln "%2|Win32"
) ELSE (
 IF "%2" EQU "run" (
  vcbuild TheSolutionFile.sln "%1|Win32" && pathtothe.exe
 ) ELSE (
  vcbuild TheSolutionFile.sln "%1|Win32"
 )
)

:EXITPOINT

which is (obviously) saved in the same direction as my solution file. A trivial modification would allow passing the solution file through an environment variable, and one could always use vcbuild’s understanding of a lone project file in the present directory but I tend to keep a shell open to the same location as my solution file.

Then again, at the moment I am using a file system hierarchy that looks sort of like this for most of my current stuff:

...
SolutionFile.sln
Project/
  ProjectFile.vcproj
  Makefile # the big thing for conventional builds
  Makefile.compiler
  ...
  Source/
    *.c, *.cpp, ...
    include/
      *.h, *.hpp, ...
    lib/
      # project specific library files
  Build/
    Target/
      # result of compiling (e.g. 'make target')
  ...
by

I feel much better at the moment, lately life has just been a bit overly negative; the more things go on, the more deeply I am reminded of what it so terribly missing. The past couple weeks has felt a lot like limbo, just passing grueling time.

One of my favourite films was on tonight, The Teahouse of the August Moon. You could say, I really needed the chance to sit, enjoy, and laugh; there hasn’t been much joy in my life for a good long while now. In all honesty, I think I would take the slower way of life given the chance, hmm; what was the last time I could have seen the sun rise or set, and be at liberty to do so? The movies ending is also priceless! In a way, Sakini’s words also struck a cord:

“Pain make man think. Thought make man wise. Wisdom make life endurable.”

I find truth in it.

by

I’m kind of happy with myself at the moment. I’ve found that Visual Studio project files are about the only reliable way I can get things to compile with Visual C++’s compiler on my lone windows machine. Since i greatly prefer using a command prompt for development work, having to alt tab between programs like VCExpress/devenv and Explorer windows are not something I’ll put up with if I don’t have to lol.

Since I do require a real mans editor, I set the IDE to load gvim as the default editor for source files; soon I’ll rig it to use vim’s client-server feature (:he client-server). Like wise that made Visual C++ little more then a very big project management and build system. Some weeks ago whilst looking for cl/link (compiler/linker) switches and a reference to nmake (Microsoft’s make utility), I found the vcbuild utility; which is the “Visual C++ Project Builder – Command Line Version”. So far it seems to be very suitable, which would mean the IDE is now only needed for managing the project and solution files, right? Well, not really!

When I started using Microsoft’s development environment (this box only has the Express editions; I usually do development on my FreeBSD powered laptop!) the first thing I did was look at the .sln and .vcproj files it creates. The solution file (.sln) basically describes the bigger picture in XML format; for my present projects it does little more then reference the project files (.vcproj) that make up the solutions. The project files are also in XML, ‘‘. It defines the various details, essentially what you get in the IDEs configuration manager for a specific project, and the files in the solution explorer. I was very happy to see Visual C++ using XML files, because it means I can *read* the things before opening them with an IDE.

Since the files are XML, and the format is pretty obvious: one can modify the project file quiet easily, and adding/subtracting things like source files, include directories, and libraries is a trivial task. If it wasn’t for the use of ProjectGUID’s I might never need to run the IDE again :-/. Who knows, maybe I won’t even need that in a while lol.

Compiler errors: the art of reading Geek and laughing at your typos

by

The code, “typo”

RenderManager RManager;

The resulting compiler error

1>main.cpp
1>.Sourcemain.cpp(9) : error C2146: syntax error : missing ';' before identifier 'RManager'
1>.Sourcemain.cpp(9) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.Sourcemain.cpp(9) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

The correction

#include "RenderManager.hpp"

RenderManager RManager;

What makes me laugh: syntax error : missing ‘;’ before identifier.

The good thing: “missing type specifier – int assumed” actually hints that RenderManager is not yet a known type, as in I forgot to include the appropriate header… hehe.