Nevertheless, here is the revised version that does work as expected even in IE9: (still requires jQuery)

jQuery(function() {
	jQuery.support.placeholder = false;
	test = document.createElement('input');
	if('placeholder' in test) jQuery.support.placeholder = true;
});
 
$(function() {
	if(!$.support.placeholder) { 
		var active = document.activeElement;
		$(':text').focus(function () {
			if (($(this).attr('placeholder') != "") 
			&& ($(this).val() == $(this).attr('placeholder'))) {
				$(this).val('').removeClass('hasPlaceholder');
			}
		}).blur(function () {
			if (($(this).attr('placeholder') != "") 
			&& (typeof ($(this).attr('placeholder')) == 'string') 
			&& ($(this).val() == "" || $(this).val() == $(this).attr('placeholder'))) {
				$(this).val($(this).attr('placeholder')).addClass('hasPlaceholder');
			}
		});
		$(':text').blur();
		$(active).focus();
		$('form').submit(function () {
			$(this).find('.hasPlaceholder').each(function() { $(this).val(''); });
		});
	}
});

I don’t think that windows will ever have quite as big library of automatically installed programs, but Ninite certainly does create that feeling, as it is one of most successful and user-friendly attempts to do automatic installing in Windows.

It is an automatic and customizable installer of mostly used programs for windows. After configuration, it will automatically download latest versions of the software such as Skype, Open Office, Mozilla software, other browsers, messengers and such and such, automatically click away all adware/toolbars. It is mostly useful on new installations, but it can also keep your usual software up to date. It is of course completely free, definitely worth a try if you haven’t already!

Combining two great concepts in programming world – color themes and the StackOverflow engine, http://studiostyl.es gives you a one-stop place for all the nice Visual Studio color themes. No more searching “the ogl” for themes and typing them in manually into the settings window.

All the themes can be downloaded for all the latest versions of VS, however it is still not particularly user friendly to install them, at least not in VS2008. I hope their coders are at least a little bit ashamed, but hey, it’s not like this is the primary point of VS.

In VS2008, you just download the file, and in Options > Environment > Import And Export Settings point the “team settings file” to the file you’ve downloaded. If you already had a team setting file, I can’t really help you, but the settings are just an XML so you could easily migrate them into your personal settings file using your favorite text editor.

(Update: found it, it is much simpler to install those using Tools > Import And Export Settings.)

(Yet Another Update: here is where I took my theme needs before the studiostyl.es came along: http://www.hanselman.com/blog/VisualStudioProgrammerThemesGallery.aspx)

1
Other
2
Unknown
3
Desktop
4
Low Profile Desktop
5
Pizza Box
6
Mini Tower
7
Tower
8
Portable
9
Laptop
10
Notebook
11
Hand Held
12
Docking Station
13
All in One
14
Sub Notebook
15
Space-Saving
16
Lunch Box
17
Main System Chassis
18
Expansion Chassis
19
SubChassis …

Pizza Box!? Lunch box!?

“Missing good old 80es when you ran dos on a pizza box…

(as seen on http://msdn.microsoft.com/en-us/library/Aa394474 and http://stackoverflow.com/questions/2837152/how-can-i-tell-if-a-user-is-using-a-laptop

So, long story short, I had to come up with some reliable debugging methods for the release builds, and there are quite a few.

Internal methods

Well, just to mention, of course, there is logging. However, my error was producing a nice and loud access violation and quitting, so instead of starting to log everything that happens I wanted to start working from that AV. But do not undermine the power

Try/catch

Firs on my list is the good old c++ try/catch blocks. In case of debugging crashes you can use them by just putting the main() or WinMain in one big try/catch, and get the exception object in the catch and start working from there. Based on that object you can deduce the exact error, line, sometimes even the callstack (probably the single most valuable piece of information about a crash). Nothing out of the ordinary, plain and simple.

However, this method will only catch c++ exceptions, not the hardware errors or even things like bad pointers, which is quite a pity because most of bugs lead just to those.

wait, what?- you say, try does not catch all the errors? What is the point then?

Well, basically, there are two kinds of exceptions in C++. First one is

1. C++ exceptions. These are the errors the code is sort of throwing itself. For example, you download a library for opening image files, and calling a function for opening a jpeg. However it cannot open the file, and uses c++ Throw() to throw an exception, to report that something went wrong and processing of that function has stopeed.
   The control now goes back to your innermost try/catch block and you get your exception there.
   These errors are always thrown by the code itself. It may not be your code, but somewhere there is a Throw() that wants to signal that something went wrong, but it knows about it.
   So these errors are handled in the c++ code, basically by the compiler, and even though they are errors, they are sort of already managed, at least partly. Because somwhere there is a throw, and its purpose is to manage an error.
   These errors a pretty high-level compared to the SEH exceptions, can basically be used as a valid control structure, not only as a fail-safe mechanism. You are free to use try/catch blocks to catch these exceptions through arbitrary calling levels, cycles, and so on. The compiler will automatically free all the memory when it unwinds the call stack to get to your innermost catch block.
2. SEH exceptions. (and this is windows-specific)
   Now, let’s say you are doing a simple *i = 1;, where i is a pointer that for some reason is pointing to null. This means your program will try to access memory at the very beginning (0) of the address space, and that memory is very reserved, so the operation is invalid.
   But what happens? You have obviously not written any code to Throw() an exception to manage this error. In fact, if you were aware of that this could happen, you could’ve just checked if i is equal to 0, and not assign a value in that case.
   Of course, other scenarios are possible, but bottomline is that sometimes there are operations that produce errors on the assembly level. The bugs (poorly designed code) probably happen before, and lead to these situations, but nevertheless, when this happens, neither the compiler nor the processor know what to do, they cannot analyze the code for you, they just see that something is wrong. Which brings us to

_try/_except

To handle these low-level errors, MS gave us a non-standard extesion to C++, which can be used in visual C++: __try and __except. The OS itself of course has a mechanism for handling these errors, otherwise any poor-written program would be able to cause havoc. There are WINAPI functions for setting SEH exception handlers, getting information about the error and so on. And in Visual C++ we can catch these errors using __try. (If you are on other platforms or other compilers, this section might be of no use to you).

Now, you might ask why isn’t this a standard C++ thing, these are still errors? The usual argumentation is that while C++ exceptions might be thrown by design (instead of constructing a lot of if’s, an author of a problematic function just put a throw() and was done with it), SEH errors often represent serious bugs in the program, and the chance is not big that the program will be able to recover from it, and this is why simply putting a try/catch around a SEH exception and trying to mask it is much more dangerous than doing so with a C++ exception. (For example it could cause a damaged information to be written to disk, instead of just being damaged in a memory)

This is of course, true to some extent, but hey, as long as you know where and how to use it, an error log during debugging is much better than just a binary dump saved by Windows’ default error mechanism.

Basically, if you put a try/catch block around your error, but it doesn’t catch it, try _try/_except. But you will need some other things to make it useful, for example StackWalker, a class to parse all the information from the SEH handler and print it to a nice readable stack trace. (Even with line numbers! And even in release builds! It is very simple to use and all the examples are provided in http://www.codeproject.com/KB/threads/StackWalker.aspx, so I am not going to cite them here.)

Just before we continue, there are some specialties in how VC++ compiles, first which errors are catched by normal try/catch can depend on whether you are building a debug or a release build, this is supposedly a bug in an older version of the compiler. Secondly, there are some compiler switches to make try/catch catch *all* errors in all types of builds (/EH{s|a}[c][-], http://msdn.microsoft.com/en-us/library/1deeycx5(v=vs.71).aspx), but there are a ton of information about this around the google and StackOverflow…

Proper IDE-debugging

A very important fact that you may or may not know is that debugging  in an IDE does not actually require the binary to be built in any special way (i.e. debug configuration). The debugger could go into any userlevel program and start stepovering and stepintoing, except in some very special cases. So what is the debug configuration really good for, except slowing down the program you ask? Well I wonder that too sometimes, but basically it adds some extra checks for things that can go wrong (a LOT of checks in STL for example), which can sometimes get you a more comprehend-able error than without those checks. Nevertheless, it is in now way a *requisite* to IDE debugging.

But what is an (almost) requisite are the symbols. The symbols are human-readable markers of things in your binary, like functions and c++ lines. When debugging, it is a lot easier to understand what is going on if the debugger tells you that you are in function suchAndSuch(), on line 342, instead of “You are at location 0x00400F3d”.

Those symbols are saved in a separate file (.pdb), and saving them contra not saving them does not modify the binary itself, so it will run exactly like a binary without those debug symbols, and will most probably crash at the same place (which is what you want to debug).

Long story short, you will need these settings:
1) C/C++ > Debug Information Format: /Zi or /ZI, chances are you won’t have to change this from the default value.
2) Linker > Debugging > Generate Debug Info : YES /DEBUG
3) Linker > Optimization > References: Eliminate Unreferenced Data (/OPT:REF) and Linker > Optimization > Enable COMDAT Folding > Remove Redundant COMDATs (/OPT:ICF). Without going into too much detail about these options, when you set the /DEBUG option, that modifies the default behavior of the linker regarding comdats and references, and by setting these two options you modify those behavior back to the way it is without the /DEBUG option, thus making sure your binary will be the same.

The symbols file will be saved by default in some intermediate directory for your project. While debugging, the IDE will have to find that file.

An interesting fact: by default, Visual Studio stores absolute path to your symbols file in your binary. This is good for debugging on the same machine, because no matter where you start your binary from, if it is debugged in Visual Studio, it will always find the symbols, but if you need to debug on different machines or just think that it is not in any way pro to ship your binaries with absolute paths to things on your development machine in them (like me), you can make it store the relative path with an undocumented command line switch: “/pdbpath:none “. (source: http://groups.google.com/group/microsoft.public.vc.debugger/browse_thread/thread/abbbdead63dfe5ac?pli=1)

So that basically should get you started on debugging release builds, for more info, google is always your dearest friend!

Just a couple of years ago, there only were bcompiler, eaccelerator and perhaps some others, but none really good. Eaccelerator would be sensitive to server environment and only work under certain conditions, and even have special problems with different php programs, and others had similair problems.

But now it seems like there are 5-10 different compilers, and all seem to work really nice. An especially interesting one is HipHop for PHP – a php compiler written by facebook to run in their own servers. The ultimate goal of all compilers is the SPEED (and, hwell, perhaps, obsfucation too), and I can only imagine what kind of speed problems the facebook experiences, with all their traffic, so if hiphop is good for them, then it should be too for the rest of the normal mortal aplications out there.

One important thing to know though is that hiphop for PHP is not an opcode cacher or a JIT. It is actually a compiler, and produces binary code as such. Probably because of that it has problems with eval() and some other dynamic features of PHP. If that is the case with your application, then it’s probably not for you, but how often does one really use eval?

Definetely check it out if you are looking to speed up your php application without changing a line of code. http://developers.facebook.com/blog/post/358/

Github: https://github.com/facebook/hiphop-php/wiki/



Steve Rambam (who is/was a private investigator, and ironically looks very much like one, thou also like an italian mafia boss) takes on many interesting things in this 3 hour long talk, including
- What information we are putting in “The Database” ourselves and how the way people are disclosing information about themselves changed over the past 10 years.
- Just how much information does a mobile phone broadcast about its owner.
- How easy it is nowadays for a detective to find out anything about you without leaving his or her desk.
- What kind of databases are being put together, sold and used, and what kind of information can be found there.
- A couple of interesting sites for information hunting.

First I tried using luabind, which didn’t work at all for me. I didn’t want to include and build both luabind and boost (which it requires), and all of the precompiled solutions didn’t work either on my setup for different reasons, plus I just didn’t have time nor motivation to spend an hour trying to setup paths, projects, solutions, includes and so on for a library which should be precompiled.

So I thought screw luabind and I will go with tolua++. Which does almost the same thing but in a different way. Basically, luabind is like a library with a lot of macros, which you use to define your bindings in certain way in your code, and when the macros get expanded before compilation, the bindings start working. Tolua++ (and its predecessor tolua) on the other hand, only includes a very small runtime library, and most of the work is done before compilation by an external command line tool. It takes in special header files which you must write for your bindings and converts them to cpp files which you then include into your project like any other cpp file, and all the bindings are defined there. (This step is automated of course, you only define the special header and include the output file once).

tolua++ doesn’t require boost, which would mean less trouble compiling it, and also I thought that the exe file itself would be just downloadable precompiled.

However it wasn’t. But now after some time figuring out the compilation routine, I have compiled it and thought that I can put it out here for everyone who wants to save an hour or so by just fetching the file which should have been available from the author’s site from the beginning.

Anyways, here is the binary. It is for win32 and is tolua++ 1.0.93:

tolua++ 1.0.93 compiled binary (exe).

When compiling this, I have had a great help from this guide: http://lua-users.org/wiki/CompilingToluappWithoutScons

Although some things in that guide seemed to be incorrect, so here is my modified version: Tolua++ compilation guide.

As for actually using the tolua++, here is another awesome guide which should get you started: http://www.icynorth.com/forums/viewtopic.php?t=301

So, needless to say, most credit goes for the author of the original guide, I have just modified some stuff!

I wanted to post this on the tolua++ site but they dont have a wiki.

The tolua++ INSTALL file lets you figure out how to compile it without SCons. Its easy enough, but I wanted to save the people the 5 ( err… 15 ) minutes they need to figure this out.

Using GCC/Mingw

I am using gcc 3.4.2, on a mingw installation. But I think this should work for most people, at least those using gcc, with minor modifications.

The commands used are :
tolua++_1.0.5\src\lib> gcc -shared -o tolua++.dll *.c
\Lua502.dll -I..\..\include -I
\include
- This will create the dynamic library tolua++.dll in the src\lib directory.
tolua++_1.0.5-1\src\lib> gcc -c *.c -I..\..\include -I
\include
tolua++_1.0.5-1\src\lib> ar rcsv libtolua++.a *.o
- This will create the static linking library in the src\lib dir.
tolua++_1.0.5\src\bin> gcc tolua.c toluabind.c -I..\..\include -I
\include
\Lua502.dll -L..\lib\ -ltolua++
- This creates the tolua++ executable in the src\bin dir, assuming the libtolua++.a was created in the src\lib dir.

Note1: If you are linking against the lua static library instead of the dynamic library, replace
\Lua502.dll with -L
\lib -llua .

Using Visual Studio 2003

Library (.DLL/.lib)

Open the “File->New Project” menu. From the project types listbox, select “Visual C++ Projects->Win32″. From the Templates listbox, select “Win32 project”. For a project name, type in “tolua++”.

When the wizard opens, select “Application Settings” on the right hand side. Choose “DLL” and click ‘Finish’. If you want to compile to a static library, choose Static Library (.lib)

In the Solution Explorer right click on “source files” and select “Add->Existing Item”. Browse to the location of the tolua++\src\lib directory. Highlight all .c and .h files and add them to the project. You may also optionally want to add the tolua++.h file from the include directory into the “header files” folder.

Right click on the tolua++ project in the Solution Explorer and select “Properties”.

Under the “C/C++ -> General” section select the “Additional include directories” option. Navigate to the location of your Lua include files.

Under the “C/C++ -> Preprocessor” section add the following: TOLUA_API=extern __declspec(dllexport) Under the “C/C++ -> Precompiled headers” section, turn off precompiled headers. Under the “Linker -> General” section select the “additional library directories” option and navigate to the location of your Lua .lib library files. Under the “Linker -> Input” section add lua.lib and lualib.lib (assuming those are your lua libraries).
In more recent versions of lua there is just one library, for example “lua5.1.lib”. In that case, just include that.

Compiling the project should result in a tolua++.dll. or tolua++.lib, whichever you chose in the project settings.

Executable (.exe)

Now, to build the executable, you must first build the library. And even thou there is probably some way to do this using the .dll for of the library, it’s easier to do it with a static one. So before compiling the executable, first compile the library as a static library (not as .dll (project settings)), to get a proper .lib file.

To create tolua++.exe, open the “File->New Project” menu, select Visual C++-> Win32 -> Win32 console project. Add the files “tolua.c”, “toluabind.c” and “toluabind.h” to the project. (NOT toluabind_default.*)

Similarly to the previous step, add the lua .lib include directory (in project settings – linker – additional library directories) and the lib itself (project settings – linker – input (just write the library filename there (no path)))

If you have listened to my advice and linked the tolua++ library statically, don’t add anything in the “C/C++ -> Preprocessor” section. If you went with dll, you will probably have to add
“TOLUA_API=extern __declspec(dllimport)”

(NOTE: this is not the same line as in previous step. That one was with dllEXPORT).

Note that for v1.0.92, I had to remove the TOLUA_API that appears in toluabind.c:
int TOLUA_API tolua_tolua_open (lua_State* tolua_S)
becomes
int tolua_tolua_open (lua_State* tolua_S)

Update: For 1.0.93 with static linking, I didn’t have to remove anything like that. So don’t worry about this unless you get compiler errors.

Using Visual Studio 2005

The same comments as above (for vs2003) generally apply, although some minor tweaks need to be made.

Note that, due to VS’ poor c99 support, ‘toluabind.c’ in the “EXE” build will not compile. There are many lines that look like:

… int top; top = lua_gettop(tolua_S); static unsigned char B[] = { …

These need to be changed to:

… int top = lua_gettop(tolua_S); static unsigned char B[] = { …

or similar.

Tested with vs2005 (no service packs) and tolua++ 1.0.91.

Codereactor update: Had no problems like this in VS2008, so maybe this is not the problem at all anymore.

You can also download the precompiled executable from here: tolua++.exe precompiled executable download.

As for the precompiled library, I advice you not to bother. Tolua++ is just a couple of c files, just include them into the sources in your project, and forget about all that library inclusion hassle.

After reading a little about this, I found out that there are a lot of options, and most of them are really easy!

My first idea was to have two different programs, one in C++ and the other one in PHP (but any other multipurpose script language would suffice), and make them communicate with each other. The best choice for communication would the TCP/IP sockets, and interface could be coded pretty easily. Each function that needed to be exported, could easily be mapped through the network code. Two different programs could even be located on different machines and easily connect through the net.

This solution is possible, and is not that bad actually, but it can get pretty annoying to have two different programs to run and maintain.

So there I came upon the Real solution.

The two script embedding options I liked the most were Lua and JavaScript engine spidermonkey.

Lua is an opensource scripting language, which is very easy to embed and is being used worldwide mostly in games to script the gaming logic. It’s biggest advantage is the speed. By checking different benchmarks, I found out that lua code can be just around 30 times slower than c++ code, which is VERY fast for a scripting language. (For comparison, php is like 300-400 times slower, perl is something like 100-300 times, and Java approx. 10 times).

With this speed, some pretty complex calculations could be easily done in lua, instead of being hardcoded. The other advantage is that lua is semantically extensible, which means that it has very few features out of the box, but you could easily implement almost any paradigm or design pattern, whichever is most suitable for your application.

For example, there are no classes in their usual meaning in lua, they are instead “implemented” in code. When using lua, you are not only writing programs, but also sort of create your own language as you go.

As for embedding, with a small additional opensource library (of mostly macros) Luabind, binding functions and classes of your c++ program to lua becomes a piece of cake. It almost comes down to 1 extra line of code per mapped function, really smooth.

The second option I am considering is JavaScript spidermonkey, which is an embeddable JavaScript engine from Mozilla.

It would be great to have JavaScript in my project, since it’s awesomely flexible, wide-spread and very easy to code in, having a common syntax. Also, for most web developers, JavaScript is a language where you know every class and every function already.

The downside is the speed (approx. 300-400 times slower than native) and the complexity. Also, since the language itself is much more complex than barebone lua, embedding it to applications and mapping functions and classes from c++ can sometimes be tricky and bloated with type conversions and argument checks.

So this seems to be the pro way to do it, so that’s what I am gonna do.  (This time it’s gonna be lua but I am eager to try the spidermonkey some time also).

PS. It’s a pity I have overlooked this at first, but apparently, boost (which you should use most of the time anyway, cz its awesome) has built-in python bindings which work almost as easy (sometimes even easier) than luabind. So that’s a great alternative also, especially if you are a python fan.