** Using WeBWorK **

Debugging complicated algorithms in a local perl environment will speed things up for sure, particularly for the development of macros. My experience is that with these kinds of macros you won't need to worry too much about using functions that are restricted in the .pg language. Basically .pg doesn't allow you access to I/O operations or to the system. The most common functions that you are not allowed to use are print and require. For the most part you probably want to design algorithm macros that don't use print at all and if you really need require, then you may need to change some of the packages required in global.conf. Access to the disk is also restricted for security reasons. If you absolutely need to store things on the disk you'll need to create special macros -- dangerousMacros.pl contains examples.

To design macros that do input/output one uses TEXT() instead of print. It may actually be easier to design this kind of macro using .pg files as you have been doing. For example the routines in PGnumericalmacros.pl file were mostly developed in regular perl -- then the I/O features were developed on .pg. In one case javaScript was used instead of perl.

In general it's best if a single macro is not involved both with a complicated algorithm and with input/output. For error messages use warn -- it's not fancy, but it's the best we have at the moment. A more sophisticated exception handling mechanism would be a useful addition to the .pg language and the webwork framework.

If there are only a few macros you are using -- e.g. random and NchooseK -- you can just copy their definitions into your own macro file for development purposes.

One common problem with switching subroutines from .pg files to .pl macro files: The handling of backslashes in these two files is different. In .pg files, where TeX is heavily used, a backslash is interpreted to be a TeX backslash. So for example in a .pg file a quoted string "\cos(x)" is a TeX command -- in practice this is accomplished by automatically doubling the backslash so that when perl first reads it the double backslash is replaced by a single backslash and then passed on to the TeX interpreter. Unfortunately this means that if you want a perl backslash in a .pg file you have to write it as $rh_hash = ~~%hash (which creates a reference to a hash and stores it in $rh_hash).

In a .pl file the automatic doubling of the backslash does not occur so the creation of a reference to a hash is $rh_hash = \%hash as in regular perl. On the other hand if you want to print cos(x) in TeX you'll need to dobule the backslash by hand: "\\cos(x)".

This means that if you develop a subroutine in a .pg file you'll need to replace all the ~~ instances with backslashes, and sometimes (less often) replace backslashes in strings with double backslashes when you transfer the subroutine to the .pl file. I'm always falling into this trap. You won't have this problem developing in regular perl.

Hope this helps.

I'm really interested in the macros you are developing. Let me know when you are ready and we can provide space in the CVS for them -- or a pointer to your own CVS if you prefer.

-- Mike

<| Post or View Comments |>