Dyalog.NET – First Impressions
Vector 19:1, page 68
Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 68
Disclaimer¶
This is my view of ".NET" (pronounced "dot-net") as a practical APL programmer. Due to time restraints (Dyalog.NET becoming available and Vector being sent off to the printers, ready for distribution at the Madrid 2002 conference) this is by no means a "full review".
Some Questions¶
When I started out with Dyalog.NET, what I wanted to know was; What is it? What it good for? How easy is it to use? Is it portable? Will it be worth investing my time in learning? What’s the learning curve? Will I enjoy using it? Will I be able to put up my charging rates as a ".NET" APL consultant?
Don’t expect me to be able to answer these questions for you, its hard enough answering them for myself, but at least I can share my impressions with you.
What is this ".NET"¶
Microsoft’s ".NET Platform" is a completely new API (Application Programming Interface). An API provides a programmer with "hooks" into the utilities and services supplied as part of the (extended) operating system/platform. ".NET" is I guess, an order of magnitude bigger (in terms of the number of utility calls available) than the 32bit Windows API. ".NET" is fully "Object-Oriented" whatever that means.
What Dyalog have done, is to make all of these API call available from within the Dyalog APL environment via a single new system function "USING" which only require the name of the ".NET namespace" and the name of the file (a DLL) as arguments. The DLL name is not even required for some "core" utilities. So, once you have said what ".NET namespace" you want, (and if necessary where to find it), you can use all the "utilities" within that namespace from APL.
Not only is this new API much bigger, it is also constantly growing, as it can be added to by anyone writing in a ".NET" language. So you and I (as a Dyalog.NET programmer) can write new ".NET" utilities, Microsoft can write new utilities, and third parties can write new utilities AND WE CAN ALL USE THEM. All you need is the DLL file installed on your PC.
(".NET" is much more then just a set of utilities, it’s a concept, a paradigm, an environment, a protocol, a discipline. But if we just stick to the idea that it is a very large set of new utilities, we have something tangible, and immediately useful.)
Prerequisites¶
"OK, you sold the idea of .NET to me, what do I need?"
(Lifted straight from Dyadic’s Dyalog.Net manual)
Dyalog.NET requires a computer running Windows 2000 or Windows XP Professional with the following installed:
- Dyalog APL/W Version 9.0
- The Microsoft .NET Framework SDK version V1.0.3705 or higher.
- Microsoft Internet Information Services (IIS) 5.0 or 5.1
- Microsoft Internet Explorer version 6.00.
Please note the Win2000/XP requirement. I do not know what the restrictions are caused by, but UNICODE is certainly one of them. However, I believe a resulting Dyalog.NET application can be run under Win98SE, if it has been upgraded with ".NET". It will never run under Win95, as Microsoft have stopped supporting that OS.
Installation¶
Note that the Dyalog.NET CD does not install any files which are unchanged from version 9.0 (such as "win.dot"), hence part of the requirement is having Dyalog 9.0 already installed.
Having just installed the whole of Microsoft’s Visual Studio.NET and the Framework SDK (a massive 4Gb), the installation of Dyalog.Net was a doddle (that is quick and easy).
The only problem I had was when I installed the "Dyalog APL Input Method Editor". (This allows you to type APL characters in Notepad for use in "scripts". It uses the same standard techniques as those used to enter Japanese characters in Notepad.)
By error, I selected (via a Microsoft wizard) the option to make Dyalog APL my "default" input method. In this context, APL is, to coin a phrase, "the wrong type of Language".
On re-starting Windows 2000, the system hung, being unable to find the correct file to with which to start Windows up in "APL" (as against starting Windows up in English or Japanese).
This was NOT an error that Dyadic have any real control over, it’s a problem with Windows 2000, and XP (as I found out when I told John Daintree about it, and he said that he has had the same problem under XP at home).
Getting stared – "RTFM"¶
It always a problem when you start learning a new language. You type in the instruction to get "Hello world" displayed, but what next? Well reading Dyalog’s manual (and trying it out on the PC) is a good start. But where do you go for help?
I started by joining the Dyalog.NET mailing-list. It’d friendly and very helpful.
Initially, I made some fundamentally wrong assumptions, which caused me to ask for the same information (which I already had) a couple of times. The members of the mailing list were helpful, and quickly pointed in the right direction.
What I wanted to do was use the SetPixel "method" of the Bitmap "class". Where can I find it?
When using Microsoft’s documentation about the "methods" (functions) in a "class" (utility sub-system), you will find there is no information about the name of the DLL file (the file containing the "class" that the "method" is a member of) in the method documentation You will however find this information is available in the documentation for the class.
The Bitmap class is in the file "SYSTEMS.DRAWING.DLL".
Another part of my problem was that I could not find this file, using the standard Windows "SEARCH" item on the popup menu from the "START" button. Searching, starting from my "C:" drive produced no results.
I eventually found it by starting my search from "C:\WINNT\Microsoft.NET".
C:\WINNT\Microsoft.NET\Framework\v.1.0.3705\SYSTEMS.DRAWING.DLL on my machine, contains the "Bitmap" class, that contains the "SetPixel" method I wanted.
My first project¶
Since "Hello world" hardly qualifies as a project, I decided to write a Dyalog.NET application that would generate Mandelbrot bitmaps. (Hence the "SetPixel".)
I wrote my very first Mandelbrot generator in the early 1980’s in Basic on a BBC Computer (with a 6502 chip). It took four plus hours to create a very small four-colour image.
I wrote a DOS based version for 386 chip in C plus assembler which took about a minute. I then wrote a Windows (3.0) version which run in sub 1-second time on a 486 or better.
With a 1GHz Pentium, and using tail-recursive "dfns" under Dyalog, I thought I might be able to speed things up a bit from my Basic version.
It did, but, I quickly found that to create a decent image, even with tail recursion, APL was not fast enough. (I was initially "recursing" up to 10,000 times for each pixel in the "black hole" areas of the Mandelbrot image. Some images require and even higher number.)
So I wrote a small programme in C# to do the intensive calculation required to calculate the "value" for each pixel.
C¶
Microsoft’s new language "C#" has been developed as the "recommended" development language for "Microsoft.NET". Charles Petzold has even re-written his classic book for C#, which is now called "Programming Microsoft Windows with C#" - Microsoft Press, ISBN 0-7356-1370-2. (I still have my 1992 copy of "Petzold" written for Windows 3.0 and have this latest one on order.)
After trying my hand in the past at Borland C++, I found C# (under the Visual .NET IDE) quite straight forward. I had to create a new "class" and save it as a DLL file. After a couple of false starts, I got the hang of the IDE. I can now edit the source code C#, re-compile it into a DLL, and test it from APL in a minute or so.
Calling my "home-made" classes was no different from calling those supplied by Microsoft. First I had to say I wanted to "also" use my DLL:
Then I had to initialise my class (called "Manbot")
This created a new namespace called "m", by running the "New" (constructor) method, with two arguments.
When it came to calling the main routine (ManColour), all I needed was
This ran the "ManColour" method, with the supplied arguments returning the "colours" I required.
I can now do simple 320x240x32bit colour Mandelbrot image in under a second from Dyalog.NET
The time cost of calling the C# for a single pixel, was greater than doing the calculation from within APL. However, calling C# once to calculate ALL the pixels, was much faster. But this is still slower than my C++ version with its hand crafted in-line floating-point assembler.
(C# does not support in-line assembler.)
Problems and Feedback.¶
As with any new software product, there will be bugs and problems. Dyalog.NET was no exception.
I had problems with creating a BITMAP from Dyalog.NET. The code worked fine from Dyalog APL/W 9.0.3 but failed to create a valid "bmp" file from "Dyalog.NET Release 1". This was due to an incorrect header in the "bmp" file.
I reported the problem back to Dyadic. They put a fix in the first update for this, which I have now installed, and it is now all working fine.
(In the mean time I starting using "PNG" rather than "BMP", with the result that the size of my image files went down from 906 KB to 66KB.)
Conclusions.¶
What is it? A set of utilities.
What it good for? Anything Dyalog APL can do plus a whole lot more.
How easy is it to use? For an APL programmer, compared to C#, much easier.
Is it portable? No - it will only run on ".NET" enabled systems.
Will it be worth investing my time in learning? Yes I think so.
What’s the learning curve? With the right support, gentle enough to ride a bicycle up. I might sweat a little, but not so steep that I will have to "get off and push".
Will I enjoy using it? I hope so, I have so far.
Will I be able to put up my charging rates as a ".NET" APL consultant? I intend to, as soon as my client starts using a Microsoft.Net environment.