|development of perl functions for webwork||topic started 6/12/2005; 2:35:10 AM
last post 6/12/2005; 12:46:31 PM
|Michael Gage - Re: development of perl functions for webwork
6/12/2005; 12:46:31 PM (reads: 1310, responses: 0)
should be pretty easy to use "require" in a regular perl script to
include .pl file macro commands and "use" to include the .pm modules. |
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.
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
In a .pl file the automatic doubling of the backslash does not occur so the creation of a reference to a hash is
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.