** Using WeBWorK **

http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$800#802

This discussion was a long time so I am wondering if this is still the current situation. I understand why it's not safe to allow system calls in pg files. It too dangerous. It's probably not a good idea to allow system calls in macro files which are in templates/macros. These are also accesible for instructors. On the other hand, there might not be much danger allowing system calls for macros in /opt/pg/macros. The reason I'd like this because it's sometimes too hard to implement something in perl and I'd rather do it in C++. Perl is not very strong with complex data structures. In particular, we are trying to write problems for the chromatic number of a graph. The is C source available for it but rewriting it in Perl would be a lot of work. Macros in /opt/pg/macros are installed by an administrator so they can be considered safe. The Perl only aspect of webwork is a limitation. It's likely that we are going to reach this limit sooner or later.

Nandor

<| Post or View Comments |>

When writing modules my own philosophy has been to concentrate on the tasks and the algorithms. I then call the module procedures from a regular macro which adds some syntactic sugar which makes it easier for problem writers to use. The idea is that the user interface (problem writer interface) may change somewhat as experience is gained in its use. I try to make the module itself as stable and unchanged as possible. Others may write other user macros that interface to the same module, but provide a different kind of communication with the user.

--Mike

<| Post or View Comments |>

BEGIN {
        be_strict();
}

package Chromatic;

sub chn {
"Blah";
}

1;

I edited global.conf:

        [qw(Parser Value)],
        [qw(Apache::Log)],
        [qw(Chromatic)],
];

I created a pg file:

DOCUMENT();
loadMacros("PGstandard.pl",
);
TEXT(&beginproblem);
$a= chn(1);
BEGIN_TEXT
$a
END_TEXT
ENDDOCUMENT();

I even restarted the web server. The result is:

Undefined subroutine &main::chn called at line 25 of [TMPL]/home/chromatic.pg

What's wrong?

<| Post or View Comments |>

$a = Chromatic::chn(1);

since chn is defined in the Chromatic namespace.

It's a matter of preference whether you want to make copies of certain calls in the main:: namespace so that problem writers don't need to worry about such things. My practice in the early days was to use a macro package such as Chromaticmacros.pl to define

sub chn {
       Chromatic::chn(@_);
}

Where chn was defined in package Chromatic; in file Chromatic.pm.

The subroutine chn is automatically imported into the main namespace by WeBWorK from the macro pl file. Some of the more esoteric methods I didn't export and these would be accessed by something like Chromatic::foobar(). Davide's parser methods are more likely to refer to commands within namespaces. As the number of tools available in WeBWorK continues to grow we may well want to change our practice about how macros are named.

<| Post or View Comments |>