Scripts Part II

From the post before it can be realized that we do need some dynamic environment.
But how is it easy to achieve this?

Today I will talk about some common things. For these things one cannot find a good answer.

First, A script debugging.

Is this easy ? It should be, but not always.

Lets start from MS supported products.

VBA: So how do you do this in VBA ? There is a whole world of support. It works in all MS Office programs, moreover I there are more programs with VBA support. E.g. AutoCAD support VBA programming.
Scripting technology: Here you have a bunch of interfaces and baz words like “Machine Debug Manager” and “Process Debug Manager”. Active Scripting API
After reading a lot and trying a lot without a success you can manage to debug a script which runs in your executable file.

What with the open source projects?
Lua: There is no built-in debugger attached with the lua implementation from lua.org.
But there is a debugger called Decoda. It costs money of course if you are not sure.
It works very nice. It doesn’t work good with the compiled lua code and code in release. But works.
Python: You can try PDB.
Wingware claims to debug embedded Python script.
I did not check them, you can try and tell me if it works.
Ruby:Internet search (like with Python) gives the ruby-debug, it seems very similar to python debugger (pdb).
What with other languages ? There are few widespread scripting languages, so if you have something good and works, you can point me to.

What the next?

Second, Interoperability.

How you can call from script to your language, and from your language to the script?

The best what I know is the Boost.Python implementation.
It supports whatever you want and it works, yeah !
For Lua you have luabind of luabridge libraries, they are pretty good too.
There are more libraries than I can think about, so use the Internet search.
What we have for Ruby language: Rice

What about ActiveScripting ?
Here you have just to implement COM object and you are in. It was too easy, so the long answer that you have to implement IDispatch interface and maybe to write some more magic. To make it shorter, ATL solves all your problems.

The only problem with this that there is no automatic way to expose your classes to the script.
Not so!
With Boost.Python you have Pyste and the newer Py++:

Looks just great. It uses GCC XML so it can be a problem for some incompatible code.
One day we can see automation support for other scripts too.

For Active Scripting you just do nothing, because every COM object can be used automatically.
The only disadvantage of this technology that it is not cross platform. (You can use WINE to make it cross platform )

What else bothers you with the scripting languages ?
Something about the scripting virtual machine: Speed and size, multithreaded support.
Something more about the language itself: Strong typed or non strong typed. duck typing.

Conclusion:
In my opinion if you want some scripting environment in your program make it easy and extendable enough.

P.S.
Yes, I did not mention Perl language. If someone can give me a good link for Perl language debugging and embedding, it would be nice.

Scripts Part I

Dynamic and static.

What the difference and why do we need both, or perhaps don’t need

What the different between two approaches ?
The static approach means that all control paths are known before the application runs, the dynamic approach means that we can create on the fly different control paths.

It is easy to see that static approach is a subset of dynamic approach.
So why don’t we use dynamic in all ?
There are two main reasons:

Performance: When we have a knowledge about all control paths in our program, we can optimize it easy

Strictness: The most problems can be caught before we run our program and not when the program runs.

It seems that the best is something like dynamic environment but with a good performance and with ability for static checking. I will return to this statement some when after.

Let’s start from some examples and analyze why we have two approaches:
1. C – static language.
2. Perl – dynamic language.

In C we have a well written program with all static checks we have and we know everything to happen, in Perl we create code dynamically and run it thus providing flexibility and no checks
I know, it wasn’t a good competition. It was to demonstrate the competition.

Another example: We have a well designed program but we want to improve it simply by adding some dynamic abilities to our program. See Microsoft Word and VBA for example.

So what is the scripting language ? I won’t bother you with wikipedia and encyclopedia. I just tell you what I think.
The main advantage of scripting language is no need for compilation.
That’s why many languages have a success, you don’t have to wait Hours!! till you have your program compiled. Of course you pay in performance, but who cares about performance too much ?

Ok, but what about Virtual Machine based languages ? Here you have a very interesting case, on the one hand you have dynamic environment with JIT compilation with good optimizations, on the other hand you have static or dynamic language on top over.
E.g. .Net is a dynamic environment while most languages for .Net are static.
So I can claim that C# is a script language because you have C# interpreter ! C# Interpreter

It was a prelude. And now the back to the post. I will talk about adding scripting technology to C++ programs.
Why C++ ? Because sometimes you have to use it.
Of course I prefer .Net but you don’t have .Net anywhere, at least for now. I’m still waiting for MSIL based smartphone

Let’s see our candidates:
Lua
Squirrel
tiscript
JScript + VBScript
C interpreter
And more

The purpose is simple, I want some code base and then everyone can use abilities very simple and extend my program.

The choice is right to you.

Windows 7 x64

I have Windows7 for a long time in my laptop.

It works pretty good.

I have upgraded Windows7 from RC1 to post RC1 and to RC2. No problems.

The only one thing which doesn’t work good is Daemon Tools.

Today I have installed Windows 7 on my home computer.

I have AMD X2 Processor and 4Gb RAM so I wanted 64-bit system of course.

I have very good impression. It works fast. Even faster than my Windows XP x64 !

I don’t care about eye candy in Windows 7 but some eye candy features are definetly good.

And of course IE8 in Windows 7 works faster than in Windows XP

Conclusion: Windows 7 is the best Windows for today. Even in RC state.

I will buy it for a sure

P.P.S.

Currently I did have one problem. The quick launch bar.

You don’t have it automatically in Windows 7. I hope it will be restored in the RTM.

Now you have to use this trick:

http://www.howtogeek.com/howto/windows-7/add-the-quick-launch-bar-to-the-taskbar-in-windows-7/

Some magic but does the work.

And if you don’t want a watermark use patch:

http://www.megaupload.com/?d=3AKF1TDG

Enjoy.