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).

The 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 Files

I'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 into line.

Reading The Manual

First 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 IIS

Seemed 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.

Loads 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.

web.config

This 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...

<configuration>
<appSettings>
        <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" />
</appSettings>
  <system.codedom>
    <compilers>
      <compiler language="dyalog" extension=".apl" type="Dyalog.Compiler.DyalogCodeProvider,dyalogprovider,Version=12.1.1.4858,Culture=neutral,PublicKeyToken=eb5ebc232de94dcf" />
      <compiler language="dyalog" extension=".dyalog" type="Dyalog.Compiler.DyalogCodeProvider,dyalogprovider,Version=12.1.1.4858,Culture=neutral,PublicKeyToken=eb5ebc232de94dcf" />
      <compiler language="dyalog" extension=".dws" type="Dyalog.Compiler.DyalogCodeProvider,dyalogprovider,Version=12.1.1.4858,Culture=neutral,PublicKeyToken=eb5ebc232de94dcf" />
    </compilers>
  </system.codedom>
  <system.web>
    <!--  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">
      <compilers>
        <compiler language="dyalog" extension=".apl" type="Dyalog.Compiler.DyalogCodeProvider,dyalogprovider,Version=12.1.1.4858,Culture=neutral,PublicKeyToken=eb5ebc232de94dcf" />
        <compiler language="dyalog" extension=".dyalog" type="Dyalog.Compiler.DyalogCodeProvider,dyalogprovider,Version=12.1.1.4858,Culture=neutral,PublicKeyToken=eb5ebc232de94dcf" />
        <compiler language="dyalog" extension=".dws" type="Dyalog.Compiler.DyalogCodeProvider,dyalogprovider,Version=12.1.1.4858,Culture=neutral,PublicKeyToken=eb5ebc232de94dcf" />
      </compilers>
    </compilation>

    <!--  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.
    -->
    <httpRuntime executionTimeout="90"/>
  </system.web>
</configuration>

Two important things here...

Dyalog's Samples Don't All Work

There 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-bit

With 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 Applet

Time to try a few steps on my own, so...
For the record, here's one I made earlier...

<script Language="Dyalog" runat="server">

∇ Select args;tie
:Access Public
:Signature Select Object,EventArgs
tie←'d:\dick\testsite\dogaspnew\testfile.dycf' ⎕fstie 0
out.Text←'File size is ',⍕⎕fsize tie
 ⎕funtie tie

</script>

<html>
<body>
<form runat=server>
<asp:Button id="btn" Text="Check File Size" runat="server" OnClick="Select" />
<p>
<asp:Label id=out runat="server"/>
</form>
</body>
</html>

If 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.

Acknowledgements

Couldn't have done this without the input of Vince and Andy at Dyalog.

Page created 7 March 2010; Copyright © Dogon Research 2010