MSK Software Development

All modern Smalltalk implementations have a way to interact with functions written in other languages - at least when these other languages support c calling conventions.

The reasons for calling those external function may be needed to get additional functionality or better speed.

Under VASmalltalk we have two choices to call external c code.

* Platform Functions *

In this way you may call every external function in a known external dynamic link library - if it is callable using stdcall or cdecl calling convention. When writing those external libraries you are thinking in typical c structures and when using base datatypes like double, integers, strings or byte arrays (on the Smalltalk side) you also get them when calling the c function: double, integers or pointers to strings or the memory of byte arrays.

In VASmalltalk the class hierarchy under OSObject is very useful to manage the data transfer between Smalltalk and the external world - they look and feel like normal c structures.

* Primitives *

With primitives you may also call external functions in a known external dynamic link library, BUT when writing those functions your parameters from Smalltalk are the plain Smalltalk structures accessable via c-function/macros.

In the general case you will then have to navigate (using c functions) through the Smalltalk object structure and look for the values you may need. More or less you will extract the needed values, prepare them for c computing and then call an additional function like in the first case.

Having to deal with return values you have to create new Smalltalk objects (in c code) and those objects are returned to the Smalltalk world.

Writing primitives is very low level stuff and there must be good reasons to use primitives instead of platform functions calling.

* Why Primitives ? *

There may be reasons for using and writing primitives: speed. It takes 6 times longer to make an external function call than to call a primitive. In general this is not worth the additional problems of writing a primitive, but when you know, that these calls are made very frequently in your image then you should consider the stony way of writing your primitives - with limited support of debugging etc …

I have never seen the real need for a user to write primitives and therefore I never wrote primitives in the last 13 years (when I started working with VASmalltalk) - but after talking with another Smalltalker about the OpenGL interface for VA I did a closer look in this topic and after some bug fixes in the sample primitive example (thanks to John O’Keefe from Instantiations) I sat down and wrote my own primitive.

PUMModeller is a Modelling software - originally written to produce C# code. The C# code generator is also included, but pretty useless, because the C# runtime source code is not available.

I now did dome further work on a plain VASmalltalk code generator and also added a plain VASmalltalk runtime.

PUMModeller - by the way - means PoorUsersModeller. We wrote this tool several years ago, because we did not find any code generating tool for VisualStudio 2002/2003 and we were not allowed to buy a Rational tool or another in the prica area. That was the reason for writing it.

When you load the configuration map “CodeManagement” all the needed stuff is loaded. You may start the modeller by looking at the “Tools”-menu, where you may find an additional menu entry named “PUM Modeller (MSK Version)”. This menu entry starts the tool.

To have nice icons you must download some icons and put them into a bitmaps directory of your VA installation. Download the icons from Icon-Files.

The tool may be downloaded from vastgoodies

Some additional documentation will follow, some additional vidoes might also follow.