Web Server Adventures
Applying the general principle
that if the crowd is headed in one direction it's often sensible to go
in the other I've started pondering taking my web sites out of the
hands of "providers" and running my own Web server locally. Not
least of the reasons being that I can then run whatever combination of
back-end software I like (or can get to run). With that in mind I
decided to start exploring Web servers and particularly Dyalog's
APLScript (which can be used to implement ASP.NET applications with
code written in APL).
Main operational regime here at Dogon
Global HQ is 64-bit Windows 7, while the travelling representatives
make do with a 32-bit Windows 7 laptop (also useful as an alternative
home for various bits of software). Both machines have APL/W 12.1
Unicode installed (64-bit on the fixed box, 32-bit on the laptop).
initial aim was to use the Abyss Web Server (available from
www.aprelium.com) because I was leery of IIS (historically) and Apache
seemed to emanate from Nerd Central. Initial setup looked
promising, but trying to get APLScript on it needed a resort to first
principles and reading the manuals. Here's the saga...
Patch All Of Your Dyalog FilesI've
always cheerfully patched dyalog.exe whenever a patch is notified, and
downloaded updated files as advised. But I hadn't been patching
runtimes and dlls. This was a mistake - something I discovered
while on my explorations is that while Dyalog as first installed would
work, things went belly-up after patching unless everything was brought
Reading The ManualFirst place to study is the Dyalog Forums FAQ entry entitled "Installing ASP.NET Applications on a "Clean Machine".
Read on and you'll find that this doesn't necessarily tell you
everything you need to know (or even anything, but the hints are there
for the more sensible).
After doing everything there, Abyss was
throwing up error messages, so the next stop was reading relevant part
of the Dyalog DotNet Interface guide (thank you, Vince). And to
do what it says there by making things run using IIS rather than
visiting too much unexplored territory by trying to meld together
APLScript and Abyss while in a state of blissful ignorance.
Setting Up IISSeemed
like a sensible idea at this point to avoid possible confusions between
32-bit and 64-bit processes to shift hostilities onto the 32-bit laptop
(another helpful hint from Vince). I'm using the IIS 7.5 that comes as part of Windows 7.
of new and partially unexplained concepts like "Virtual Directories"
(well, I'm not about to read all of the manuals) - Microsoft have
changed the IIS configuration interface since Dyalog wrote their
manual, but there's enough there to get you going. And also to
concentrate on getting Dyalog's supplied samples to work.
is a file that's incomprehensible to the average APLer and also
absolutely vital to making APLScript work, here's what my working
version (64-bit) looks like...
<add key="DyalogIsolationMode" value="DyalogIsolationProcess" />
<add key="DyalogCompilerEncoding" value="unicode" />
<add key="DyalogCompilerFullPath" value="C:\Program
Files\Dyalog\Dyalog APL-64 12.1\bin\dyalogc64_unicode.exe" />
<compiler language="dyalog" extension=".apl"
<!-- DYNAMIC DEBUG COMPILATION
Set debug="true" to enable debugging and bind to dyalog.net.dll.
Otherwise, setting this value to false will bind to
dyalog.net.runtime.dll which will prohibit debugging.
<compilation debug="true" batch="false">
<compiler language="dyalog" extension=".apl"
<!-- EXECUTION TIMEOUT
This controls the time in seconds for which a resource is allowed to
try to execute before ASP.NET cancels (times out) the execution of the
request. 90 seconds is the default value. If you know that a certain
process will take longer than 90 seconds to execute you should increase
this value. Note that if debug is true, ASP.NET automatically resets
this parameter to a very high number.
Two important things here...
line starting <add key="DyalogCompilerFullPath" tells ASP.NET where
to look for the files needed by APLScript. As both my machines
have APL/W development versions installed it's indicating the
"official" location. Andy Shiers suggested this, to avoid
possible confusion when mutiple versions of APL/W are installed.
Morten's FAQ suggests that these files be put into a /bin folder
for each of your APLScript applications - but I got "unable to find..."
messages when I tried this. Smarter and more patient folk will
probably have more success.
- Version is set to 22.214.171.12458,
which is the current file version for dyalognet.dll etc. (not the file
version for dyalog.exe). If you don't get this right nothing will
work. I've found it useful to have Windows Explorer display file
version as a "details" column.
Dyalog's Samples Don't All WorkThere
are (at the time of writing) some errors in the asp.net tutorials files
of the Dyalog 12.1 installation, so if you are working your way through
you'll find that intro1.aspx and intro2.aspx are fine, intro3.aspx
displays an empty drop-down box and some of the later pages also show
errors. The manual appears to be correct (it showed me how to fix
intro3.aspx, didn't try any others), Dyalog are aware and no doubt
corrected files will appear in due course.
Back to 64-bitWith
some success happening on the 32-bit box it seemed like a good idea to
replicate everything where it was supposed to work. So, install
IIS on the 64-bit machine, copy the folder over from the laptop, adjust
filename in web.config, and it "just works".
Well, not quite
that simple. If you're also exploring, adding bits and so forth,
you may find as I did that IIS is a bit pernickety. Seems to want
to allow you to remove some Virtual Diectories, but not others.
Seems to sort itself out after a restart or two, and takes due
account of "real" folder deletes. I've also seen FireFox being
more temperamental (wanted to save my .aspx files rather than run them
from time to time) than other browsers (flavour of the month here at
Dogon Towers is SRWare Iron). Again, restarts are a cure.
Write a Little AppletTime to try a few steps on my own, so...
For the record, here's one I made earlier...
- Create a folder to hold the necessary
- Declare it to IIS as a Virtual Directory
- Create/edit a .aspx file
in web.config (maybe this isn't necessary, a global home might be
adequate - but let's be wasteful and have one for every application
- Restart IIS
- Load the file up with your browser of choice and gasp in wonder...
<script Language="Dyalog" runat="server">
∇ Select args;tie
:Signature Select Object,EventArgs
tie←'d:\dick\testsite\dogaspnew\testfile.dycf' ⎕fstie 0
out.Text←'File size is ',⍕⎕fsize tie
<asp:Button id="btn" Text="Check File Size" runat="server" OnClick="Select" />
<asp:Label id=out runat="server"/>
there's anything wrong with your APL you may not get too many hints, so
look at Morten's other FAQ about debugging ASP.NET applications.
What About Path?Morten
says to add your folders to the system PATH. I haven't done that
(well, I did, then undid it). I guess this is because I have
APL/W installed on the machines, so all is set as it needs to be.
I find PATH a messy thing to deal with - if I can ignore it I do,
so I did.
Whatever Happened to Abyss?
Some wars are worth fighting and others aren't. I thought
everything was set up properly but Abyss decided that Server Error 500
was an appropriate reward for my struggles. I can't really be
bothered to try to get to the bottom of it, IIS is working well enough
for my present purposes.
AcknowledgementsCouldn't have done this without the input of Vince and Andy at Dyalog.
Page created 7 March
2010; Copyright © Dogon Research 2010