Forum archive 2000-2006

Nandor Sieben - system calls in macro packages

Nandor Sieben - system calls in macro packages

by Arnold Pizer -
Number of replies: 0
inactiveTopicsystem calls in macro packages topic started 6/27/2005; 4:58:39 PM
last post 6/27/2005; 7:27:49 PM
userNandor Sieben - system calls in macro packages  blueArrow
6/27/2005; 4:58:39 PM (reads: 883, responses: 4)
The link below explains the possibilities to make system calls in webwork problems:$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.


<| Post or View Comments |>

userMichael Gage - Re: system calls in macro packages  blueArrow
6/27/2005; 6:02:44 PM (reads: 1084, responses: 0)
I believe that all of the statements in the earlier discussion still hold. It seems to me that creating a new module (for example) and placing it in /pg/lib is exactly the right solution to your problem. (This is the first method described on the page you reference.) The module can simply be a shell which calls a C program to do the real work. An existing example of this is which calls gdlib to get the real work done. (These are standard CPAN modules, not ones that we wrote for WeBWorK.) I am not experienced in grafting perl interfaces onto C programs -- but this operation is commonly performed and there exist such experts in the open source world. (The location of the list of loaded modules given on that page is no longer correct -- this list is now found in global.conf rather than in By wrapping the method in a perl subroutine inside a module you can, in principal, provide access to anything that runs on the unix machine -- including routines written in python, lisp, ruby, c, forth, mathematica, maple etc. etc.

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.


<| Post or View Comments |>

userNandor Sieben - Re: system calls in macro packages  blueArrow
6/27/2005; 6:40:48 PM (reads: 1078, responses: 0)
I created /opt/pg/lib/



package Chromatic;

sub chn {


I edited global.conf:


        [qw(Parser Value)],

I created a pg file:


$a= chn(1);

I even restarted the web server. The result is:

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

What's wrong?

<| Post or View Comments |>

userMichael Gage - Re: system calls in macro packages  blueArrow
6/27/2005; 6:54:33 PM (reads: 1087, responses: 0)
Restarting the webserver is important since the modules are loaded in when a child process starts up. I think your problem is that you need to call

$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 to define


sub chn {

Where chn was defined in package Chromatic; in file

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

userNandor Sieben - Re: system calls in macro packages  blueArrow
6/27/2005; 7:27:49 PM (reads: 1104, responses: 0)
It works, thank you. Nandor

<| Post or View Comments |>