Forum archive 2000-2006

Andy Wildenberg - inserting downloaded code into WebWork

Andy Wildenberg - inserting downloaded code into WebWork

by Arnold Pizer -
Number of replies: 0
inserting downloaded code into WebWork topic started 2/14/2002; 11:27:43 AM
last post 2/14/2002; 1:11:21 PM
userAndy Wildenberg - inserting downloaded code into WebWork  blueArrow
2/14/2002; 11:27:43 AM (reads: 1063, responses: 2)
I'm sorry I can't come up with a better subject header, but this is what I'm interested in doing. I would like to be able to have WebWork download a URL and insert its text into the middle of a WebWork problem. The idea is that I might be able to use this to better integrate WebWork with some of the servlet applications I've written.

According to the Perl Recipes book, I should be able to do something like the following.

use LWP::Simple;
unless (defined ($content = get $URL)) {
die "could not get $URL\n";

Unfortunately, I get the following message when I try it. Problem1
ERROR caught by PGtranslator while processing problem
require trapped by operation mask at (eval 49) line 1.

In this particlar case I had the 'use' statement at the top of the .pg file, which is why it says line 1, but I've tried it at several spots and the error always seems to be with the use line.

Any idea what's going on? I'm not that great a Perl hacker, so I supposed it's foolish for me to be pushing the envelope like this, but I think it could potentially improve my particular situation a lot.

<| Post or View Comments |>

userMichael Gage - Re: inserting downloaded code into WebWork  blueArrow
2/14/2002; 1:11:21 PM (reads: 1346, responses: 0)

You've run into the security features of the PG language. Rather than to invent a new language, interpreter, etc. for writing math problems, we have instead used a powerful existing language and interpreter (perl) and cut it down so that it is not too powerful. In particular standard perl commands that directly access system calls, write to disk or interact with the outside environment in other ways, cannot be used in a standard PG problem. This prevents a problem writer editing a problem from the web from wrecking real havoc with the system, either inadvertently or on purpose. This is accomplished using the module supplied with perl.

For example "require" cannot be used, although it is called indirectly by the "loadMacros()" command. Even print can't be used -- instead one is supposed to use the TEXT() macro, or other macros built on it.

There are three places where the full power of the perl language can be used:

The first is to write a new module (a ... .pm file, such as which usually adds a new object to the list of objects available to the PG language. In your case a "java display object". New objects are added by writing the code in a file and then modifying the file "" found in the courseScripts directory, so that it is loaded into the interpreter. If your copy of LWP is in the standard directories for perl, you can probably simply add LWP to "". If the module loader (which at this point is not very sophisticated) can't find the file, you can make a copy of LWP or LWP::Simple in the courseScripts directory. Renaming LWP::simple might be a good idea, to avoid confusion. Another technique I have used (see the file in courseScripts for an example) is to make a subclass file: which in turn calls to accomplish most things. This allows me to make changes to fit the needs of PG and still remain compatible with the original objects.

I think that experimenting with this technique will allow you to do what you want. Once you have it working you should also think about whether it allows someone to do more than is desirable (inadvertently or not) and see if you can guard against this.

The other common place to put macros that reference the disk is in the file which is interpreted without any of the safety checks provided by (hence the name of the file). This file has been used mainly to house all in one place, macros that must have access to the disk. We then try to check these macros carefully to make sure that they can't be misused.

The final spot for putting macros that use the full power of perl is in itself. This is probably not appropriate for most macros. We try to keep only really fundamental macros defined in so that it changes relatively unfrequently.

Hope this helps.

-- Mike

<| Post or View Comments |>