openwebwork-devel — WeBWorK development discussion

Re: [WWdevel] jsMath v2.0 and WeBWorK

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 18, 2005, at 15:04, John Jones wrote:

>>> I guess right now I'd go for extracting the tarball manually.
>>
>> That is my inclination as well.  Unless I hear additional dissent,  
>> I'll go ahead and do that.  John, if you still have a strong  
>> preference for individual files, let me know.
>
> No, it isn't that strong.  Definitely go ahead and do the tarball.
> Would the added difficulty only affect cvs users?  If you bundle a  
> release, maybe it can have the jsMath fonts unpacked before  
> creating the main tarball.
>
> If it turns into a faq, then maybe something can be added to the  
> admin course to check some of the system configuration items, with  
> this being one thing which gets checked.

We want the tarballs to be updateable with CVS, so if someone did  
update, they'd get a new jsMath_fonts.tar.gz file that they would  
have to unpack. It's possible to have the code in webwork.apache- 
config (or in a webwork-startup.pl that would be PerlRequired) issue  
a warning if the tarball is newer than the individual files. It's  
relatively uninvasive and would only add overhead at server startup.
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDBUIA14CQX+2WvVgRApC9AJ9ZzHjV5+UycQKKveavddQ35w2S5ACfR+SO
8oNgTly7Bxeuw+fCM0KVfdk=
=GoNG
-----END PGP SIGNATURE-----

Re: [WWdevel] jsMath v2.0 and WeBWorK

[Davide P.C. <dp...@un...>]

> No, it isn't that strong.  Definitely go ahead and do the tarball.

OK, great.

> Would the added difficulty only affect cvs users?  If you bundle a 
> release, maybe it can have the jsMath fonts unpacked before creating 
> the main tarball.

That sounds like a reasonable suggestion (though it would mean a 
difference in the instructions for dealing with CVS versus tarball).  
Since I don't put together the WW releases, I can't say how easy this 
would be to do, or whether the folks at Rochester want to do it, but it 
seems like a reasonable thing to try.

Davide

Re: [WWdevel] jsMath v2.0 and WeBWorK

[John J. <jj...@as...>]

>> I guess right now I'd go for extracting the tarball manually.
>
>
> That is my inclination as well.  Unless I hear additional dissent, 
> I'll go ahead and do that.  John, if you still have a strong 
> preference for individual files, let me know. 

No, it isn't that strong.  Definitely go ahead and do the tarball. 

Would the added difficulty only affect cvs users?  If you bundle a 
release, maybe it can have the jsMath fonts unpacked before creating the 
main tarball.

If it turns into a faq, then maybe something can be added to the admin 
course to check some of the system configuration items, with this being 
one thing which gets checked.

John

Re: [WWdevel] jsMath v2.0 and WeBWorK

[Davide P.C. <dp...@un...>]

> I did some timing tests for 10,000 1024 byte binary files containing 
> random data.

Thanks for the hard data.

> It looks like the main bottleneck is remote checkouts. Checking out to 
> my machine took 15m43s, but after replacing the small files with a 
> tarball the same checkout only took 1m26s.
>
> Updates and commits don't seem to be a problem, since CVS only 
> consults the repository for files that have updated timestamps. Remote 
> update of the a small files working directory took 9.7 seconds, 
> compared to 1.5 seconds for a tarball working directory. (This is with 
> no updates to be made.)

I was concerned about the update times, but these are not as bad as I 
had thought they would be.  On the other hand, there are about 20,000 
files for the jsMath image fonts, not 10,000, so the times will be 
longer.  I think the checkout times make this prohibitive, and the 
extra work involved in unpacking the file is probably worth it.

> On Aug 16, 2005, at 11:20, John Jones wrote:
>
>> Personally, I would favor ease of installation over saving on cvs 
>> data.  A way of doing both would be to have it as a single tar 
>> archive, and let webwork deal with it.  When it looks for the images, 
>> if they don't exist it looks for the image archive file.  If that 
>> exists, webwork untars it automatically.  I think the path to tar is 
>> already in global.conf.
>
> This would certainly be convenient for the administrator, but I'm not 
> sure it would be worth it. Currently, static files are served by 
> Apache directly, without WW's involvement. Involving WeBWorK in the 
> delivery of static files could only be bad for speed.

I'm not sure I think it's worth it, either.  Remember that jsMath runs 
in the browser, not the server, and so it will not be able to check if 
the archive has been unpacked.  It would be possible for Problem.pm, 
ProblemSet.pm and the library browser to check if the fonts have been 
unpacked when jsMath mode is selected, but it seems like unnecessary 
overhead to me.  The tar file will only need to be unpacked once, so 
I'd hate to have every invocation of a WW problem require a file-system 
check for the jsMath fonts.

> I guess right now I'd go for extracting the tarball manually.

That is my inclination as well.  Unless I hear additional dissent, I'll 
go ahead and do that.  John, if you still have a strong preference for 
individual files, let me know.

Davide

Re: [WWdevel] boxes (or other formatting) around problems

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 17, 2005, at 15:33, John Jones wrote:

> Personally, I liked the way the boxes looked now.  To build this in  
> as an option, my suggestion is to add two variables to global.conf,  
> something like problemHtmlStart and problemHtmlEnd.  They would be  
> inserted by beginproblem() and ENDDOCUMENT() when displaying a HTML  
> related mode.

I'm hesitant to add more wiring between global.conf and the problem  
environment, especially if it requires adding to defineProblemEnvir  
in WeBWorK::PG. Could this be added to specialPGEnvironmentVars,  
since that entire hash gets passed through to the problem environment?
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDBLur14CQX+2WvVgRAr6NAJ9ZpCA29w8c8QX5yg5tY/4VU8RtAwCffyZK
1KLRdDIZjOdA/Rw0Tfbwps8=
=l/w2
-----END PGP SIGNATURE-----

[WWdevel] boxes (or other formatting) around problems

[John J. <jj...@as...>]

Hi,

If you went to see the jsMath images off Davide's server at Union, then 
you must have seen the boxes he has around his problems.  I liked how 
they were offset, so I tried to reverse engineer it.  I remember other 
people remarking about how nice it looked when Davide demo-ed some of 
his stuff at a conference, so maybe more people would like this as an 
option.

My first guess is that it was done by modifying ur.css since there is a 
css class "problem" already wrapped around the body of a problem.  One 
could still do that, but it would not look the same since between <div 
class="problem">/</div> is also the point value and messages such as 
"*Note:* / You can earn partial credit on this problem./"  As it stands, 
one could make the boxes by modifying ur.css, but it would include this 
other information.

Personally, I liked the way the boxes looked now.  To build this in as 
an option, my suggestion is to add two variables to global.conf, 
something like problemHtmlStart and problemHtmlEnd.  They would be 
inserted by beginproblem() and ENDDOCUMENT() when displaying a HTML 
related mode.

If they are left as empty strings, then one would get the current 
behavior.  If they are set to the right strings, one get's Union-style 
boxes.  If they are set to something like '<div class="problemBody">' 
and '</div>', then one can fiddle with the style through css.

It can also be set up so that the values can be overriden within the 
code, so for example, the values are set to empty for problems rendered 
in the library browser or ProblemSetDetail.

So, what do people think?  Should I add these variables to webwork?

John

/

/

Re: [WWdevel] jsMath v2.0 and WeBWorK

[John J. <jj...@as...>]

> On Aug 16, 2005, at 11:20, John Jones wrote:
>
>> Personally, I would favor ease of installation over saving on cvs  
>> data.  A way of doing both would be to have it as a single tar  
>> archive, and let webwork deal with it.  When it looks for the  
>> images, if they don't exist it looks for the image archive file.   If 
>> that exists, webwork untars it automatically.  I think the path  to 
>> tar is already in global.conf.
>
>
> This would certainly be convenient for the administrator, but I'm not  
> sure it would be worth it. Currently, static files are served by  
> Apache directly, without WW's involvement. Involving WeBWorK in the  
> delivery of static files could only be bad for speed.
>
> I guess right now I'd go for extracting the tarball manually.

I was assuming that jsMath would already have some code in it to check 
for the fonts since it detects if you have TeX fonts available.  But, 
now that I think about it, the checking of TeX fonts can be done client 
side in javascript whereas checking for images would be done on the 
server side.  So, it is a different story.

John

Re: [WWdevel] jsMath v2.0 and WeBWorK

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 15, 2005, at 18:25, Davide P.Cervone wrote:

> Before I make the changes to the CVS repository, I wanted to ask  
> the WW development community's advice.  The new image-font fallback  
> method uses a lot of small image files (6 fonts at 13 sizes in two  
> different formats yielding some 20000 separate images).  I don't  
> want to add that many individual files to the cvs repository, as  
> these are not going to be changing, and there is no need to keep  
> CVS data on them all, or have to scan them during updates, etc.   
> The alternative is to make an archive from them and put that in the  
> CVS repository.  Unpacking it would be another step in the WW  
> installation.  Failure to do this would cause jsMath's fallback  
> method to fail miserably.  There is a setting that can be made to  
> prevent jsMath from using the images (in case someone doesn't want  
> to install the images), and it will use the current unicode version  
> instead, though the image mode is much better.
>
> So, it an extra installation step acceptable?  Should the non-image  
> mode be enabled by default, so that if they don't unpack the fonts,  
> it still works?

I did some timing tests for 10,000 1024 byte binary files containing  
random data. It looks like the main bottleneck is remote checkouts.  
Checking out to my machine took 15m43s, but after replacing the small  
files with a tarball the same checkout only took 1m26s.

Updates and commits don't seem to be a problem, since CVS only  
consults the repository for files that have updated timestamps.  
Remote update of the a small files working directory took 9.7  
seconds, compared to 1.5 seconds for a tarball working directory.  
(This is with no updates to be made.)

On Aug 16, 2005, at 11:20, John Jones wrote:

> Personally, I would favor ease of installation over saving on cvs  
> data.  A way of doing both would be to have it as a single tar  
> archive, and let webwork deal with it.  When it looks for the  
> images, if they don't exist it looks for the image archive file.   
> If that exists, webwork untars it automatically.  I think the path  
> to tar is already in global.conf.

This would certainly be convenient for the administrator, but I'm not  
sure it would be worth it. Currently, static files are served by  
Apache directly, without WW's involvement. Involving WeBWorK in the  
delivery of static files could only be bad for speed.

I guess right now I'd go for extracting the tarball manually.
- -sam

- ----------------------------------------------------------------

[sh002i@devel] smallfiles$ time find . -name '*.bin' | xargs false

real    0m0.047s
user    0m0.037s
sys     0m0.042s

- ----------------------------------------------------------------

[sh002i@devel] smallfiles$ time find . -name '*.bin' | xargs cvs -Q  
add -m ''

real    20m57.029s
user    19m15.596s
sys     1m9.928s

[sh002i@devel] smallfiles$ time cvs -Q commit -m ''

(Ran into problems with commit, since CVS tries to pass the list of  
committed files to activitymail and runs out of argument space.  
disabled activitymail...)

(Even with -Q, RCS still managed to emit six lines per commit. The  
clock time is presumably affected by this.)

real    2m55.127s
user    1m32.384s
sys     0m48.355s

- ----------------------------------------------------------------

[sh002i@devel] work$ time cvs -Q -d /webwork/cvs/system checkout  
smallfiles

real    0m19.313s
user    0m4.389s
sys     0m13.971s

[sh002i@devel] smallfiles$ time cvs update

real    0m6.674s
user    0m2.110s
sys     0m4.564s

[sh002i@devel] smallfiles$ time cvs commit

(Null commit -- no changes to the working copy.)

real    0m6.645s
user    0m2.094s
sys     0m4.550s

- ----------------------------------------------------------------

(Now, some tests on my home machine, on a residential cable broadband  
line in Boston.)

sam@g5:WeBWorK$ time wwcvs -Q - 
d :ext:an...@cv...:/webwork/cvs/system checkout  
smallfiles

real    15m43.233s
user    12m51.102s
sys     0m59.432s

sam@g5:smallfiles$ time wwcvs update

real    0m9.697s
user    0m0.645s
sys     0m0.550s

- ----------------------------------------------------------------

(After replacing the small files with a tarball in the repository...)

[sh002i@devel] tarfile$ time cvs -Q -d /webwork/cvs/system co smallfiles

real    0m2.023s
user    0m0.741s
sys     0m0.399s

[sh002i@devel] smallfiles$ time cvs -Q update

real    0m0.028s
user    0m0.019s
sys     0m0.012s

- ----------------------------------------------------------------

(Checking out the tarball to machine...)

sam@g5:WeBWorK$ time wwcvs -Q - 
d :ext:an...@cv...:/webwork/cvs/system checkout  
smallfiles

real    1m25.978s
user    0m1.109s
sys     0m0.697s

sam@g5:smallfiles$ time wwcvs -Q update

real    0m1.481s
user    0m0.096s
sys     0m0.069s

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDAjWW14CQX+2WvVgRAhC5AKDALXv2yARkY3uB8JRJ8H0Rd+n0AgCeP35I
JLUBBdqyIlied7bceBc2Lpc=
=ti1W
-----END PGP SIGNATURE-----

Re: [WWdevel] Predefined constants like NONE and DNE

[John J. <jj...@as...>]

I would like to see having this short list of strings always recognized 
by webwork.  I don't see any harm in it, and it will make some problems 
function better.

John


Davide P.Cervone wrote:

> Folks:
>
> When I wrote the Parser code, one of the things I was after was 
> consistency in terms of error messages.  Since the same parser was 
> being used for ALL types of answers, it would know about the other 
> types of objects no matter what type of answer you were looking for.  
> For example, if you are checking for a numeric answer, the Parser 
> still will give appropriate error messages even when the student types 
> an interval: it will say something to the effect that you typed an 
> interval but that it expected a number.  Since you have the ability to 
> change the Context, however, that somewhat undermines this, since you 
> can remove its knowledge of some types of objects (e.g., the Numeric 
> class does not know about points).
>
> When I developed the Legacy module for the Parser, which makes num_cmp 
> and fun_cmp use the Parser answer checkers, I implemented contexts 
> that mirrored the traditional num_cmp and fun_cmp environments as 
> closely as I could.  This is the right thing to do for backward 
> compatibility, but I'm not sure it is the best idea for the future.  
> For example, all the default Parser contexts include definitions for 
> NONE, INF, INFINITY, -INF, -INFINITY, and DNE, as common strings that 
> might be used in other parts of the problem, so the Parser should 
> recognize these and respond appropriately when the student enters them 
> when some other type of answer is expected (usually they are marked 
> incorrect silently).  I took these out of the num_cmp and fun_cmp 
> contexts, however, so if a student types NONE in an answer blank for 
> num_cmp, he or she will get an error message instead (but it will at 
> least be "'NONE' has no meaning in this context" rather than a message 
> about an undefined variable 'N').
>
> I think that in the long run, NONE, DNE, and the infinities should all 
> be defined all the time.  Do you think these should be added back into 
> the Parser-based versions of num_cmp and fun_cmp?
>
> Davide
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel

Re: [WWdevel] jsMath v2.0 and WeBWorK

[John J. <jj...@as...>]

The images look very good on my machines.  I have never turned enabled 
jsMath for our machines because of the fonts issue, but this may change 
my mind.

Davide P.Cervone wrote:

> Before I make the changes to the CVS repository, I wanted to ask the 
> WW development community's advice.  The new image-font fallback method 
> uses a lot of small image files (6 fonts at 13 sizes in two different 
> formats yielding some 20000 separate images).  I don't want to add 
> that many individual files to the cvs repository, as these are not 
> going to be changing, and there is no need to keep CVS data on them 
> all, or have to scan them during updates, etc.  ...


> So, it an extra installation step acceptable?  Should the non-image 
> mode be enabled by default, so that if they don't unpack the fonts, it 
> still works?

Personally, I would favor ease of installation over saving on cvs data.  
A way of doing both would be to have it as a single tar archive, and let 
webwork deal with it.  When it looks for the images, if they don't exist 
it looks for the image archive file.  If that exists, webwork untars it 
automatically.  I think the path to tar is already in global.conf.

> Also, the image fallback method is good enough that it might be 
> reasonable not to put up the missing font message at all.  (There is a 
> setting in global.conf that disables it.)  Users can still get to the 
> download site from a link on the control panel.  Should the message be 
> disabled entirely?

No missing-fonts-message sounds good to me.  I can imagine it being 
annoying for students who routinely access webwork from public campus 
computer sites where they don't have permission to install the needed 
fonts (any why bother if you are going to be at a different computer 
tomorrow).  The missing fonts message sends a message of "there is 
something wrong you should fix".  With some students, we don't need any 
bad karma.

John

Re: [WWdevel] jsMath v2.0 and WeBWorK

[Arnold P. <ap...@ma...>]

At 09:01 AM 8/16/2005, Davide P.Cervone wrote:


Hi Davide,

All the problems I saw seem to come from the resolution I was using: 
1024 x 768 on a 19" SyncMaster 930MP.

At 1280 x 1024 and  800 x 600 everything looks fine.  Also 1152 X 864 
looked OK but as I was just clicking on links in the email message, I 
ran out of guest users and didn't check all problems at that resolution.

Maybe IE7 will surprise you in a good way.  Hope springs eternal.

Arnie
>>The fonts look nice.  You may or may not care, but there are some 
>>problems viewing things on MSIE 6 (at least on my PC at home).
>
>Is the screen resolution 120 dpi at 1600 pixels or more?  At these 
>resolutions, MSIE automatically scales images for you (it's so 
>helpful), and I know that this screws up jsMath.  I've been trying 
>to fix that, but I don't have access to a PC in that configuration, 
>so it is hard to do.
>
>I'll look into your other problems.  It has been a real pain to get 
>jsMath to work with MSIE, which has an order of magnitude more (and 
>more serious) bugs than any of the other nine browsers I've tested 
>with.  There seems to be no end to the quirky display bugs 
>associated with it.  I can't wait for IE7 and a whole NEW crop of bugs.  :-)
>
>Thanks for trying it out.
>
>Davide


Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767 

Re: [WWdevel] jsMath v2.0 and WeBWorK

[Davide P.C. <dp...@un...>]

> The fonts look nice.  You may or may not care, but there are some 
> problems viewing things on MSIE 6 (at least on my PC at home).

Is the screen resolution 120 dpi at 1600 pixels or more?  At these 
resolutions, MSIE automatically scales images for you (it's so 
helpful), and I know that this screws up jsMath.  I've been trying to 
fix that, but I don't have access to a PC in that configuration, so it 
is hard to do.

I'll look into your other problems.  It has been a real pain to get 
jsMath to work with MSIE, which has an order of magnitude more (and 
more serious) bugs than any of the other nine browsers I've tested 
with.  There seems to be no end to the quirky display bugs associated 
with it.  I can't wait for IE7 and a whole NEW crop of bugs.  :-)

Thanks for trying it out.

Davide

Re: [WWdevel] jsMath v2.0 and WeBWorK

[Arnold P. <ap...@ma...>]

At 06:25 PM 8/15/2005, Davide P.Cervone wrote:

Hi Davide,

The fonts look nice.  You may or may not care, but there are some 
problems viewing things on MSIE 6 (at least on my PC at 
home).  Basically it looks like horizontal lines don't display 
correctly. E.g. in
http://omega.math.union.edu/webwork2/05SP-MTH015-01/Week9/1/
the horizontal line in the fraction doesn't appear and the numerator 
appears to the right of the denominator.

In
http://omega.math.union.edu/webwork2/05SP-MTH015-01/Week9/10/
the horizontal line in the radical sign doesn't appear.

In
http://omega.math.union.edu/webwork2/05SP-MTH015-01/Week6/4/
the bar over the v does appear, but it appears above and to the right 
of the v, not directly over it.

In
http://omega.math.union.edu/webwork2/05SP-MTH015-01/Week6/6/
instead of v bar, I see a v with a dot above and to the right of the v, etc.

Arnie


>Folks:
>
>I have recently released version 2.0 of jsMath, which includes a 
>number of important new features.  The most apparent of these are:
>
>1.  A new fallback method for when the TeX fonts are not installed 
>on the user's computer.  It now uses images of the individual 
>characters rather than unicode characters to display the 
>mathematics.  This is more reliable, in general, and produced better 
>results, though there are issues about printing and the mathematical 
>notation can't be colored as it could be with the TeX fonts and unicode fonts.
>
>2.  There is now a control panel for jsMath that lets the user 
>adjust the settings for jsMath, including which fallback method to 
>use, and the relative size of the mathematics compared to the 
>surrounding text.
>The panel can be opened by pressing a small floating button at the 
>lower right-hand side of the screen or by ALT-clicking on any 
>mathematical expression.
>
>3.  The font warning message now only appears on the first page 
>containing jsMath during your browser session.  (The control panel 
>can be used to turn off these messages for longer periods of time.)
>
>4.  Better support for Konqueror under unix, and Safari under OS X 10.4.
>
>There are lots of internal improvements, better documentation, and 
>more customization possibilities, but these will not impact jsMath 
>particularly.
>
>Before I make the changes to the CVS repository, I wanted to ask the 
>WW development community's advice.  The new image-font fallback 
>method uses a lot of small image files (6 fonts at 13 sizes in two 
>different formats yielding some 20000 separate images).  I don't 
>want to add that many individual files to the cvs repository, as 
>these are not going to be changing, and there is no need to keep CVS 
>data on them all, or have to scan them during updates, etc.  The 
>alternative is to make an archive from them and put that in the CVS 
>repository.  Unpacking it would be another step in the WW 
>installation.  Failure to do this would cause jsMath's fallback 
>method to fail miserably.  There is a setting that can be made to 
>prevent jsMath from using the images (in case someone doesn't want 
>to install the images), and it will use the current unicode version 
>instead, though the image mode is much better.
>
>So, it an extra installation step acceptable?  Should the non-image 
>mode be enabled by default, so that if they don't unpack the fonts, 
>it still works?
>
>Also, the image fallback method is good enough that it might be 
>reasonable not to put up the missing font message at all.  (There is 
>a setting in global.conf that disables it.)  Users can still get to 
>the download site from a link on the control panel.  Should the 
>message be disabled entirely?
>
>For those of you interested in seeing the new version of jsMath, I 
>have installed it on our server at Union, and you can try it out there.  Go to
>http://omega.math.union.edu/ and select the Math 15 course, logging 
>in as guest.  We will be putting up new courses for the fall term 
>shortly, so you may need to go to the "past courses" link to find 
>something with any non-trivial assignments in it.  Note that jsMath 
>is not the default mode, so you will have to change to it.  Use the 
>control panel at the lower right to change the selected display mode 
>if you want to try out the different image/unicode methods.  Note, 
>however, that jsMath will reload the page when you change one of the 
>settings, so you might get a alert box asking if that is acceptable.
>
>Let me know how you think the images should be handled in the CVS repository.
>
>Davide
>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>OpenWeBWorK-Devel mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openwebwork-devel


Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767 

[WWdevel] Predefined constants like NONE and DNE

[Davide P.C. <dp...@un...>]

Folks:

When I wrote the Parser code, one of the things I was after was 
consistency in terms of error messages.  Since the same parser was 
being used for ALL types of answers, it would know about the other 
types of objects no matter what type of answer you were looking for.  
For example, if you are checking for a numeric answer, the Parser still 
will give appropriate error messages even when the student types an 
interval: it will say something to the effect that you typed an 
interval but that it expected a number.  Since you have the ability to 
change the Context, however, that somewhat undermines this, since you 
can remove its knowledge of some types of objects (e.g., the Numeric 
class does not know about points).

When I developed the Legacy module for the Parser, which makes num_cmp 
and fun_cmp use the Parser answer checkers, I implemented contexts that 
mirrored the traditional num_cmp and fun_cmp environments as closely as 
I could.  This is the right thing to do for backward compatibility, but 
I'm not sure it is the best idea for the future.  For example, all the 
default Parser contexts include definitions for NONE, INF, INFINITY, 
-INF, -INFINITY, and DNE, as common strings that might be used in other 
parts of the problem, so the Parser should recognize these and respond 
appropriately when the student enters them when some other type of 
answer is expected (usually they are marked incorrect silently).  I 
took these out of the num_cmp and fun_cmp contexts, however, so if a 
student types NONE in an answer blank for num_cmp, he or she will get 
an error message instead (but it will at least be "'NONE' has no 
meaning in this context" rather than a message about an undefined 
variable 'N').

I think that in the long run, NONE, DNE, and the infinities should all 
be defined all the time.  Do you think these should be added back into 
the Parser-based versions of num_cmp and fun_cmp?

Davide

[WWdevel] jsMath v2.0 and WeBWorK

[Davide P.C. <dp...@un...>]

Folks:

I have recently released version 2.0 of jsMath, which includes a number 
of important new features.  The most apparent of these are:

1.  A new fallback method for when the TeX fonts are not installed on 
the user's computer.  It now uses images of the individual characters 
rather than unicode characters to display the mathematics.  This is 
more reliable, in general, and produced better results, though there 
are issues about printing and the mathematical notation can't be 
colored as it could be with the TeX fonts and unicode fonts.

2.  There is now a control panel for jsMath that lets the user adjust 
the settings for jsMath, including which fallback method to use, and 
the relative size of the mathematics compared to the surrounding text.  
The panel can be opened by pressing a small floating button at the 
lower right-hand side of the screen or by ALT-clicking on any 
mathematical expression.

3.  The font warning message now only appears on the first page 
containing jsMath during your browser session.  (The control panel can 
be used to turn off these messages for longer periods of time.)

4.  Better support for Konqueror under unix, and Safari under OS X 10.4.

There are lots of internal improvements, better documentation, and more 
customization possibilities, but these will not impact jsMath 
particularly.

Before I make the changes to the CVS repository, I wanted to ask the WW 
development community's advice.  The new image-font fallback method 
uses a lot of small image files (6 fonts at 13 sizes in two different 
formats yielding some 20000 separate images).  I don't want to add that 
many individual files to the cvs repository, as these are not going to 
be changing, and there is no need to keep CVS data on them all, or have 
to scan them during updates, etc.  The alternative is to make an 
archive from them and put that in the CVS repository.  Unpacking it 
would be another step in the WW installation.  Failure to do this would 
cause jsMath's fallback method to fail miserably.  There is a setting 
that can be made to prevent jsMath from using the images (in case 
someone doesn't want to install the images), and it will use the 
current unicode version instead, though the image mode is much better.

So, it an extra installation step acceptable?  Should the non-image 
mode be enabled by default, so that if they don't unpack the fonts, it 
still works?

Also, the image fallback method is good enough that it might be 
reasonable not to put up the missing font message at all.  (There is a 
setting in global.conf that disables it.)  Users can still get to the 
download site from a link on the control panel.  Should the message be 
disabled entirely?

For those of you interested in seeing the new version of jsMath, I have 
installed it on our server at Union, and you can try it out there.  Go 
to
http://omega.math.union.edu/ and select the Math 15 course, logging in 
as guest.  We will be putting up new courses for the fall term shortly, 
so you may need to go to the "past courses" link to find something with 
any non-trivial assignments in it.  Note that jsMath is not the default 
mode, so you will have to change to it.  Use the control panel at the 
lower right to change the selected display mode if you want to try out 
the different image/unicode methods.  Note, however, that jsMath will 
reload the page when you change one of the settings, so you might get a 
alert box asking if that is acceptable.

Let me know how you think the images should be handled in the CVS 
repository.

Davide

Re: [WWdevel] help with refreshCachedImages

[John J. <jj...@as...>]

Michael Gage wrote:

>
> On Aug 12, 2005, at 6:36 PM, John Jones wrote:
>
>> Hi,
>>
>> There was a discussion on the discussion board stemming from  
>> Nandor's problems which generate graphs based on student answers.   
>> Part of the resolution was that a problem should always refresh its  
>> on the fly graphics if refreshCachedImages is non-zero.
>>
>> I created a problem and set $refreshCachedImages=1 in the problem.   
>> The place to check this is in dangerousMacros.pl.  I have tried  
>> $main::refreshCachedImages and $main::PG_FLAGS{refreshCachedImages}  
>> (and a few other variations), and I cannot see the value of this  
>> variable.
>>
>> What is the right way to access this value, or is there none?  For  
>> example, if the call from the problem to insertGraph is evaluated  
>> before ENDDOCUMENT, then any help from ENDDOCUMENT won't be seen.
>>  
>
> Try  my $refreshedCachedImages =  eval ( "$main::refreshCachedImages");

That doesn't work either, nor does

my $refreshCachedImages = eval("$main::PG_FLAGS{refreshCachedImages}");

Are used variables inside the pg files accessible from functions like 
pg/macros?

John

Re: [WWdevel] help with refreshCachedImages

[Michael G. <ga...@ma...>]

On Aug 12, 2005, at 6:36 PM, John Jones wrote:

> Hi,
>
> There was a discussion on the discussion board stemming from  
> Nandor's problems which generate graphs based on student answers.   
> Part of the resolution was that a problem should always refresh its  
> on the fly graphics if refreshCachedImages is non-zero.
>
> I created a problem and set $refreshCachedImages=1 in the problem.   
> The place to check this is in dangerousMacros.pl.  I have tried  
> $main::refreshCachedImages and $main::PG_FLAGS{refreshCachedImages}  
> (and a few other variations), and I cannot see the value of this  
> variable.
>
> What is the right way to access this value, or is there none?  For  
> example, if the call from the problem to insertGraph is evaluated  
> before ENDDOCUMENT, then any help from ENDDOCUMENT won't be seen.
>
Hi John,


Try  my $refreshedCachedImages =  eval 
( "$main::refreshCachedImages");  I

I think that might work. There are several examples of this kind of  
problem in PG.pl, PGanswermacros.pl and
PGbasicmacros.pl -- all of these are scripts which are precompiled.

The problem is that because dangerousMacros.pl is cached "main::"  
means one thing when
the script is compiled (perhaps main:: is SafeRoot1::   ) and another  
when the problem script is
compiled (main:: is SaveRoot 21::)  so you need to delay evaluation  
of the variable name until
"run time".


See if that works.  I haven't tested it, some experimentation might  
be needed.

Take care,

Mike


> If there is not a reasonable way to access refreshCachedImages,  
> maybe it should be removed since it doesn't have a use (aside from  
> debugging).  Having an optional flag in the graph object for forced  
> refreshing is something I suggested on the discussion board.  We  
> could still do that pretty easily I think.  The call to insertGraph  
> does have access to the graph object.
>
> John
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>

[WWdevel] help with refreshCachedImages

[John J. <jj...@as...>]

Hi,

There was a discussion on the discussion board stemming from Nandor's 
problems which generate graphs based on student answers.  Part of the 
resolution was that a problem should always refresh its on the fly 
graphics if refreshCachedImages is non-zero.

I created a problem and set $refreshCachedImages=1 in the problem.  The 
place to check this is in dangerousMacros.pl.  I have tried 
$main::refreshCachedImages and $main::PG_FLAGS{refreshCachedImages} (and 
a few other variations), and I cannot see the value of this variable.

What is the right way to access this value, or is there none?  For 
example, if the call from the problem to insertGraph is evaluated before 
ENDDOCUMENT, then any help from ENDDOCUMENT won't be seen.

If there is not a reasonable way to access refreshCachedImages, maybe it 
should be removed since it doesn't have a use (aside from debugging).  
Having an optional flag in the graph object for forced refreshing is 
something I suggested on the discussion board.  We could still do that 
pretty easily I think.  The call to insertGraph does have access to the 
graph object.

John

[WWdevel] bugzilla

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I just upgraded Bugzilla to the latest stable version. Please let me  
know if you run into any problems.
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC9+HX14CQX+2WvVgRAlW5AJ0RpKv7IKtUUeKJ2Eg4oJiXDYUkEACgu+My
tYSounJQ1Poel95oOzZwY5o=
=Gi+7
-----END PGP SIGNATURE-----

[WWdevel] graphical diff/merge for Gtk+

[Samuel H. <sh...@ma...>]

I just read about Meld <http://meld.sourceforge.net/> on Ars Technica 
<http://arstechnica.com/columns/linux/linux-20050804.ars/2>.

Looks like a useful tool.
-sam

[WWdevel] Fwd: [WWcvs] webwork: Imported Sources

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,

I just noticed this message, and since it appears to be an import  
coming from the anoncvs account and I haven't seen anything like it  
before, I'm suspending anonymous CVS and backing up the repository  
until I can check it out tomorrow.
- -sam

Begin forwarded message:

> From: Anonymous CVS Access via activitymail  
> <we...@ma...>
> Date: August 5, 2005 2:33:58 EDT
> To: ope...@li...
> Subject: [WWcvs] webwork: Imported Sources
> Reply-To: ope...@li...
>
>
> Update of /webwork/cvs/system/webwork
> In directory devel.webwork.rochester.edu:/tmp/cvs-serv52311
>
> Log Message:
> .
>
> Status:
>
> Vendor Tag:    INITIAL_IMPORT_VENDOR_TAG
> Release Tags:    INITIAL_IMPORT_RELEASE_TAG
>
>
> No conflicts created by this import
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> Openwebwork-cvs mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-cvs
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC8wvu14CQX+2WvVgRAn/tAJ9AvOUczt4fL7h3F5PrBXjJTRv1cACfZAG0
qmHpjWIT5KDnF7ZxL/i1Oo8=
=gHJV
-----END PGP SIGNATURE-----

Re: [WWdevel] summary of $SIG{__DIE__} and $SIG{__WARN__} usage in Translator.pm

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 31, 2005, at 14:32, Davide P.Cervone wrote:

>> Davide -- can you take a look at the changes I made to error  
>> handling in process_answers?
>>
>
> I will, but I've been out of town, and have not had good access to  
> mail while away.  Now that I'm back, my DSL modem has died, and I'm  
> having trouble getting through the campus firewall on my dial-up  
> access, so I'm STILL rather out of communication.  I'll check into  
> it as soon as I can get everything under control here.
>
> The whole error handling mechanism was pretty involved, as I  
> recall, and I had to do some things I wasn't happy with in order to  
> get it to work at all, but I've learned some things since then, and  
> perhaps can simplify things a bit.  it will take some time for me  
> to remember how it all worked, though.  :-)

Thanks. Take your time, it seems to be stable (although I have not  
tested my changes extensively), and it fixes a couple of problems we  
were having.
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC7UVO14CQX+2WvVgRAsw7AJsEhhnBO/syOGFCxlV6QWKwiAB+/QCgm58b
JsOD1k141dqgzsDNY914IwI=
=/Lw3
-----END PGP SIGNATURE-----

Re: [WWdevel] summary of $SIG{__DIE__} and $SIG{__WARN__} usage in Translator.pm

[Davide P.C. <dp...@un...>]

> Davide -- can you take a look at the changes I made to error handling 
> in process_answers?

I will, but I've been out of town, and have not had good access to mail 
while away.  Now that I'm back, my DSL modem has died, and I'm having 
trouble getting through the campus firewall on my dial-up access, so 
I'm STILL rather out of communication.  I'll check into it as soon as I 
can get everything under control here.

The whole error handling mechanism was pretty involved, as I recall, 
and I had to do some things I wasn't happy with in order to get it to 
work at all, but I've learned some things since then, and perhaps can 
simplify things a bit.  it will take some time for me to remember how 
it all worked, though.  :-)

Davide

Re: [WWdevel] summary of $SIG{__DIE__} and $SIG{__WARN__} usage in Translator.pm

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok,

I've implemented the changes to Translator.pm as discussed in this  
thread. Here's the commit message:

> Fix use of $SIG{__WARN__} and $SIG{__DIE__}.
>
> * Each change to $SIG{__WARN__} and $SIG{__DIE__} is now dynamically
> scoped with "local", rather than changing globally and then  
> restoring at
> the end of the block.
>
> * The special value "DEFAULT" is used instead of sub {CORE::die 
> (@_)} or
> sub {CORE::warn(@_)} when preparing to eval STRING code.
>
> * Where $SIG{__WARN__} and $SIG{__DIE__} are overridden to do
> preprocessing with PG_errorMessage, the previously installed handlers
> will be called instead of the built-in warn or die functions after
> preprocessing occurs. (For example, the warn and die handlers  
> defined in
> Apache::WeBWorK or the warn handler defined in WeBWorK::PG will be
> called.)
>
> * The behavior in process_answers is modified so that the custom
> handlers are installed once before the answer evaluation loop. This
> causes them to be in effect during the setup/teardown code, but I  
> don't
> think this will be a problem.

Davide -- can you take a look at the changes I made to error handling  
in process_answers? Mike tried pulling the handler out of the for  
loop and it worked for him, so I committed that. Do you see any  
problem with that? I also made %errorTable a lexical instead of  
dynamically scoped. It's not used anywhere else but inside that  
scope, so I think it'll be fine.

I think I understand how %errorTable functions. Am I correct that it  
stores the output of PG_errorMessage (so that it doesn't step on the  
toes of answer evaluators that throw and then catch their own  
exceptions), and then if an exception goes uncaught (inside the  
answer evaluator), it is caught in process_answers and the full error  
message is retrieved from the table?

If so, I don't think we need a hash at all, since there will only be  
one uncaught exception per answer evaluated, and that will be the  
most recently thrown exception. So, it seems to me that it would  
suffice to just store the most recent error message in a scalar since  
that's the only one we're going to report on.

This whole mechanism seems dodgy to me, but I can't think of any  
better way to do it. We need to be high up on the stack than the code  
that caused the exception in order to generate a stack trace, and we  
have to wait and see if the exception gets caught by someone else  
before we commit to reporting the trace. It seems to me that this is  
the only way to go.

Please let me know if I'm thinking about this properly. :)
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC6omt14CQX+2WvVgRAnNOAKC/BEdf7fOtlMkydVR2e2u4G34/fgCeNK3D
ozaNL+yNHcx73jBKI6GI498=
=JmMS
-----END PGP SIGNATURE-----

Re: [WWdevel] summary of $SIG{__DIE__} and $SIG{__WARN__} usage in Translator.pm

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 29, 2005, at 14:24, Michael E. Gage wrote:

> On Jul 29, 2005, at 1:00 PM, Sam Hathaway wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Mike,
>>
>> Here is my assessment of what's going on with $SIG{__WARN__} and  
>> $SIG{__DIE__} in Translator.pm.
>>
>> evaluate_modules() uses:
>>
>>     local $SIG{__DIE__} = "DEFAULT";
>>
>> to set the default handler for the duration of the subroutine. It  
>> then goes onto use eval STRING to read in PG modules, and checks  
>> $@ for any error messages. This is not harmful, and it saves us a  
>> little time since the handler defined in Apache::WeBWorK would  
>> waste time generating a backtrace before calling the default  
>> handler. (But see below for why I think we should just let the  
>> Apache::WeBWorK handlers run.)
>>
>> At the beginning of translate(), we see a few things:
>>
>>     # reset the error detection
>>     $SIG{__WARN__} = sub {CORE::warn(@_) } unless ref($SIG 
>> {__WARN__}) =~/CODE/;
>>     my $save_SIG_warn_trap = $SIG{__WARN__};
>>     #FIXME  -- this may not work with the xmlrpc access
>>     # this formats the error message within the existing warn  
>> message.
>>     $SIG{__WARN__} = sub {&$save_SIG_warn_trap(PG_errorMessage 
>> ('message',@_))};
>>     #$SIG{__WARN__} = sub {CORE::warn(PG_errorMessage 
>> ('message',@_))};
>>     my $save_SIG_die_trap = $SIG{__DIE__};
>>     $SIG{__DIE__} = sub {CORE::die(PG_errorMessage('traceback',@_))};
>>
>> This is a trouble spot, since it sets the handlers without using  
>> "local". From what I can tell, what we WANT to do here is provide  
>> a level of preprocessing to any warning or exception that comes  
>> out. We may also want to avoid calling the Apache::WeBWorK warn/ 
>> die handlers, although I think we should leave them alone and  
>> assume our caller has some way they want to collect errors and  
>> warnings. (For example, WeBWorK::PG::Local has its own warn  
>> handler that accumulates warnings and returns them as part of the  
>> WeBWorK::PG object.) It seems to me that the simplest way to  
>> accomplish this is:
>>
>>     # reset the error detection
>>     my $outer_sig_warn = $SIG{__WARN__};
>>     local $SIG{__WARN__} = sub {
>>         my $munged = PG_errorMessage('message', $_[0]);
>>         ref $outer_sig_warn eq "CODE" ? &$outer_sig_warn 
>> ($munged) : warn $munged;
>>     };
>>     my $outer_sig_die = $SIG{__DIE__};
>>     local $SIG{__DIE__} = sub {
>>         my $munged = PG_errorMessage('traceback', $_[0]);
>>         ref $outer_sig_die eq "CODE" ? &$outer_sig_die($munged) :  
>> die $munged;
>>     };
>>
>> This doesn't deal with the case where the handlers are set to  
>> string names of subroutines, but that could be added. It also  
>> doesn't handle "IGNORE", but that could be added as well.
>>
>>
> OK.  I'd made this change also, omitting calling the outer DIE and  
> WARN handlers.  I think your idea is better.

I'll implement that then.

>> in process_answers(), we have:
>>
>>     local %errorTable;
>>     $SIG{__DIE__} = sub {
>>         #
>>         #  Get full traceback, but save it in local variable so that
>>         #  we can add it later.  This is because some evaluators use
>>         #  eval to trap errors and then report them in the message
>>         #  column of the results table, and we don't want to include
>>         #  the traceback there.
>>         #
>>         my $fullerror = PG_errorMessage('traceback',@_);
>>         my ($error,$traceback) = split /\n/, $fullerror, 2;
>>         $fullerror =~ s/\n   /<BR>&nbsp;&nbsp;&nbsp;/g; $fullerror  
>> =~ s/\n/<BR>/g;
>>         $error .= "\n";
>>         $errorTable{$error} = $fullerror;
>>         CORE::die($error);
>>     };
>>     # reset the error detection
>>     my $save_SIG_warn_trap = $SIG{__WARN__};
>>     $save_SIG_warn_trap = sub {CORE::warn @_} unless  ref 
>> ($save_SIG_warn_trap) =~/CODE/;
>>     $SIG{__WARN__} = sub {&$save_SIG_warn_trap(PG_errorMessage 
>> ('message',@_))};
>>     my $save_SIG_die_trap = $SIG{__DIE__};
>>
>> and then later on, after the answers are evaluated:
>>
>>     $SIG{__DIE__} = $save_SIG_die_trap;
>>     $SIG{__WARN__} = $save_SIG_warn_trap;
>>
>> First of all, restoring the die handler doesn't work at all, since  
>> $save_SIG_die_trap is set to the custom die handler we just  
>> installed a few lines before. In addition, I think we can do the  
>> same thing here that we did up above, inserting the code that  
>> accumulates exceptions. Also, I think %errorTable can be a lexical.
>>
>>
> This is the error that was causing the immediate trouble in  
> Hardcopy.pm (the generation of the ARRAY string, but no ARRAY  
> reference).

As far as I can tell, the actual reference is preserved until the  
point at which it is printed. Our outermost error reporting code,  
which generates the "Software error" text, assumes that the argument  
to die is a string, not any sort of reference or object. It's up to  
us (in Hardcopy.pm in this case) to deal with non-string exceptions.  
So we'll be fine as long as we fix this part to restore the original  
handlers when we're done, or better yet, use localized handlers --  
we'll need that if we ever want this to be thread safe.

>>     # reset the error detection
>>     my $outer_sig_warn = $SIG{__WARN__};
>>     local $SIG{__WARN__} = sub {
>>         my $munged = PG_errorMessage('message', $_[0]);
>>         ref $outer_sig_warn eq "CODE" ? &$outer_sig_warn 
>> ($munged) : warn $munged;
>>     };
>>     my %errorTable;
>>     my $outer_sig_die = $SIG{__DIE__};
>>     local $SIG{__DIE__} = sub {
>>         my $fullerror = PG_errorMessage('traceback', $_[0]);
>>         my ($error,$traceback) = split /\n/, $fullerror, 2;
>>         $fullerror =~ s/\n   /<BR>&nbsp;&nbsp;&nbsp;/g; $fullerror  
>> =~ s/\n/<BR>/g;
>>         $error .= "\n";
>>         $errorTable{$error} = $fullerror;
>>         ref $outer_sig_die eq "CODE" ? &$outer_sig_die($error) :  
>> die $error;
>>     };
>>
>>
> The other thing I did in my fix was to move the definition of the  
> WARN and DIE handlers outside of the for loop.  %errorTable can be
> moved outside the loop to.  I think this works ok.  I'm still  
> thinking about the role of %errorTable and whether it has to be  
> localize
> for each answer.  If necessary it could be emptied out at the top  
> of each loop.

That sounds good. I think it would be bad if %errorTable had to be  
local, since it would leak into called subroutines. I'm also unclear  
as to whether it's robust. Is it possible for there to be two errors  
that have the same value for $error but different values for $fullerror?

Maybe Davide would like to give some input on this one.

>> There are three more places where warn/die handlers get messed  
>> with - -- PG_restricted_eval(), PG_macro_file_eval(), and  
>> PG_answer_eval(). In each case, subroutine begins with:
>>
>>     my $save_SIG_warn_trap = $SIG{__WARN__};
>>     $SIG{__WARN__} = sub { CORE::die @_};
>>     my $save_SIG_die_trap = $SIG{__DIE__};
>>     $SIG{__DIE__}= sub {CORE::die @_};
>>
>> then some code gets passed to eval STRING, and then:
>>
>>     $SIG{__DIE__} = $save_SIG_die_trap;
>>     $SIG{__WARN__} = $save_SIG_warn_trap;
>>
>> We can replace these with the same type of code that's used in  
>> evaluate_modules():
>>
>>     local $SIG{__WARN__} = "DEFAULT";
>>     local $SIG{__DIE__} = "DEFAULT";
>>
>>
> Is there an advantage to calling "DEFAULT" instead of
> local $SIG{__WARN__} = sub { CORE::die @_};

I think we avoid a level of subroutine call, since there's no  
anonymous sub getting called.
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC6njO14CQX+2WvVgRAhKZAJ9MiprIQ+EaZHG4/CD1ILmjc0sdowCdFXVM
5MpEOuQZd/kUDSQzoSMXLng=
=yrOi
-----END PGP SIGNATURE-----