openwebwork-devel — WeBWorK development discussion

[WWdevel] LaTeXMathML mode

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

I have added a LaTeXMathML mode based on the message we received from  
Peter Jipsen announcing the modification to ASCIIMathML.  This works  
a lot better for our needs than the original ASCIIMathML (though I  
didn't remove that mode), as it handles much more of the LaTeX  
commands and syntax.  I don't have MSIE with the MathPlayer plugin,  
so I can't test it there.  Could someone else check that?

There are still some problems, however:

1.  It doesn't handle all the plain TeX commands, only LaTeX ones.   
So things like \bf and \rm don't work.  I modified LaTeXMathML.js to  
handle these and a few other easy ones, but there are still plenty of  
others that it doesn't handle.  (For example, \kern, which is used in  
some of the table macros).  It does not appear easy to add this (and  
I'm not inclined to spend the time on it myself).

2.  It doesn't handle \begin{array}...\end{array}, which is central  
to a number of the layout macros.  I didn't look into how hard that  
would be to add.

3.  It doesn't do the optional parameter for \sqrt[n]{...} which is  
used by some problems.  It probably could be added, but I didn't try.

I worked around several other limitations listed on the LaTeXMathML  
home page (http://www.maths.nottingham.ac.uk/personal/drw/lm.html),  
so this is probably usable for many problems.

Anyway, thought I'd pass on this information.

Davide

[WWdevel] bugfix release 2.2.2

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

Hi All,

You may have noticed -- I released WeBWorK and PG 2.2.2 yesterday. It  
contains a few bug fixes and minor new features. Most of these are  
backports of fixes to HEAD from Davide Cervone. Thanks Davide. It  
should be safe to update running 2.2.x installations. There are no  
database or config file changes. Please let me know if you run into  
any difficulties updating. For full release notes, visit:
<http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
WeBWorKRelease2pt2pt2>
<http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
PGLanguageRelease2pt2pt2>

Enjoy.
-sam

Here are the changes:

* Updated to jsMath version 3.3c. See http://www.math.union.edu/ 
locate/jsMath/changes.html for details of the changes.

* Fixed a problem where WeBWorK assumed that columns were in a  
specific order in the database. Now, columns can be in any order.

* Make the Hardcopy Generator edit links use the same window as other  
edit links.

* Improve wording and fix typos in various modules.

* The Library Browser now indicates if a problem is already listed in  
the target set.

* Fixed a spurrious security error when previewing course info and  
set header files.

* Enable viewing of the default set and hardcopy header files in the  
PG Problem Editor. (This allows the files to be saved to the course  
templates directory for editing.)

* Fixed some problems with the Diagonstics output for Formula  
objects. (The tolerances used in the diagnostics didn't always match  
the ones used in the actual testing, and the wrong values were  
sometimes displayed when a multi-variable function was displayed as a  
graph.)

* Use tolerance flags from the Real object itself, if available,  
before looking at the context.

* Fixed a problem where polynomials like x+4x would be accepted even  
in single-power mode. The initial x was not being identified as a  
single power of x correctly.

* Ensure that ImageGenerator settings are correctly included from  
WeBWorK::Constants in all cases.

* Security: Since problems can provide their own graders, problem  
authors could previously use call PG_restricted_eval in a custom  
grader to gain access to the full WeBWorK environment. Graders are  
now evaluated in the PG safe compartment, preventing this.

* Fixed a spurrious warning in images mode when a hint or solution  
contains math expressions.

* FUNCTION_CMP now preserves the correct answer exactly as typed  
rather than reconstructing it from the parsed version.

* Fixed a problem with derivatives of constant-valued Matrices,  
Vectors, and Points. They were incorrectly getting an extra level of  
nesting.

Re: [WWdevel] National Problem Library

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

Hi,

I think it is a good idea.  Alphabetizing occurred to me in the past, 
but I didn't do it in part because it is also somewhat arbitrary, and in 
part out of laziness.  But, it would certainly be the easiest

To impart some other ordering, having an auxilliary file with this 
information in it would be a simple way to go.  When the database loads 
(by running loadDB2) it can read this information into the database as 
well.  The internal changes to webwork would still be minimal, confined 
to the file ListingDB.pm.

John


Arnold Pizer wrote:

>I find the ordering of  Subjects, Chapters and Sections in the 
>"Problem Library" strange and confusing. E.g. select "Calculus" and 
>then list the Chapters.  Except for the "All ..." on top, it looks 
>like the rest show up in a random order.
>
>One thing we could do is to use an alphabetic/numeric sort so at 
>present everything below  "All ..." would be alphabetic and in the 
>future if someone decides to add numerical labels, e.g. rename 
>"Advanced Calculus" to "17.  Advanced Calculus", then this would be 
>the 17th item on the list.  Maybe a better thing to do would be to 
>set up a hash and assign a numerical value to each heading and then 
>list the items in numerical order. Using this it would be easy to add 
>a new items anywhere in the list.  There would be a little work in 
>coming up with a good ordering but probably we would just follow the 
>ordering in popular text books.
>
>Any comments or other ideas on this?
>

[WWdevel] National Problem Library

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

Hi,

I find the ordering of  Subjects, Chapters and Sections in the 
"Problem Library" strange and confusing. E.g. select "Calculus" and 
then list the Chapters.  Except for the "All ..." on top, it looks 
like the rest show up in a random order.

One thing we could do is to use an alphabetic/numeric sort so at 
present everything below  "All ..." would be alphabetic and in the 
future if someone decides to add numerical labels, e.g. rename 
"Advanced Calculus" to "17.  Advanced Calculus", then this would be 
the 17th item on the list.  Maybe a better thing to do would be to 
set up a hash and assign a numerical value to each heading and then 
list the items in numerical order. Using this it would be easy to add 
a new items anywhere in the list.  There would be a little work in 
coming up with a good ordering but probably we would just follow the 
ordering in popular text books.

Any comments or other ideas on this?

Arnie





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

Re: [WWdevel] some 2.3 notes for you all (UPDATE)

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

I've been using it, but I agree it should be an experimental feature.

LDAPS should also be an experimental feature -- but probably a safer  
one to use.

-- Mike
On Aug 3, 2006, at 6:13 PM, Sam Hathaway wrote:

> -- Apache 2 --
>
> this seems to be working, but there are probably lingering bugs in
> code that doesn't get much exercise. have other people been testing
> it? it should probably be an "experimental feature" in 2.3.0.

[WWdevel] some 2.3 notes for you all (UPDATE)

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

-- Apache 2 --

this seems to be working, but there are probably lingering bugs in  
code that doesn't get much exercise. have other people been testing  
it? it should probably be an "experimental feature" in 2.3.0.

-- WW/Moodle --

make Course Title/Institution optional in Course Admin (but also pre- 
fill these values from mod.html?)

improve wwassignment user experience a bit by creating the bridge  
object before showing the mod.html form. that way, we can check for  
and report the existence of the WeBWorK course in mod.html. if it  
doesn't exist yet, give a message like "The WeBWorK course SCH103  
does not exist yet: _Create WeBWorK Course SCH103_".

fix problems with teacher login in sql_moodle -- this might not be  
replicable, mike or i will check this. <http:// 
bugs.webwork.rochester.edu/show_bug.cgi?id=1043>

moodle cookies are sometimes(?) not being parsed under apache 2.  
probably has something to do with raw commas in the cookie. <http:// 
comox.textdrive.com/pipermail/wp-trac/2006-April/001297.html>

-- Gateway Testing --

Gavin says: "The Gateway mods are tested---by hand, by myself---but  
not extensively. Which may mean that they're stable, but I usually  
reserve that characterization for when something has survived a  
semester of use. There are two possibly remaining issues: (1) I  
managed to completely lock IE and Windows a couple of times when  
playing with it.  That didn't happen later in testing, and one of the  
times it locked was from the ProblemSets page, not in a Gateway test,  
so I'm not sure if it is a problem, or if it is, if it's a Gateway  
problem, an IE problem, or a WeBWorK problem; and (2) there's a  
complication when a user who is able to print multiple sets tries to  
print a gateway test: the multi-set selector doesn't show the set  
versions, which makes printing not work.  I'm calling it a known bug  
for now."

he added another database field: i'd REALLY like to have an automatic  
update mechanism in place so that adding this field wouldn't have to  
happen manually. see below.

-- Automatic Database Update --

wwdb_check does simple things like adding tables/columns/indexes,  
changing column types, and the like. this is sufficient for gavin's  
current changes.

i'll be adding a framework to that script to allow it to execute  
arbitrary Perl or SQL code to affect more complicated upgrades. for  
now, it'll be inside wwdb_check, but eventually it'll go into a library.

Re: [WWdevel] some 2.3 notes for you all

[Sam H. <sa...@uo...>]

On Aug 3, 2006, at 4:49 PM, Michael Gage wrote:

> I think this feature should be the highest priority for your time.
> A beginning stub for database update will be useful -- it may not
> be full featured, but that's ok as long as the stub is moving in  
> the right direction.

Ok, I'll get to work on this.

I think I was unclear in my original notes -- wwdb_check can  
*already* do simple things like adding tables/columns/indexes,  
changing column types, etc. It does this by comparing the state of  
the database (using "SHOW TABLES" and "DESCRIBE") to the data in the  
WW Record classes.

With respect to database versioning, it currently just makes sure  
that the dbupgrade table exists and the db_version entry is set  
correctly. What I'll be working on is adding a framework to that  
script to allow it to execute arbitrary Perl or SQL code to affect  
more complicated upgrades.

> On Aug 3, 2006, at 2:05 PM, Sam Hathaway wrote:
>
>> -- Automatic Database Update --
>>
>> wwdb_check will do simple things like adding tables/columns/indexes,
>> changing
>> column types, and the like. this is sufficient for gavin's current
>> changes.
>>
>> eventually, we need a real database versioning system for more
>> complicated
>> changes -- filling default values, normalization, and the like -- but
>> we don't
>> technically have to have this mechanism in place right now.
>>
>> we just need to ensure that the state of 2.3.0 databases is:
>> 	- all tables/columns/indexes up-to-date and using the correct types
>> 	- dbupgrade table exists
>> 	- db_version=0 in dbupgrade table
>>
>> (i'm also starting to think that the database upgrading should
>> happend offline,
>> in a command-line script.)

> This is ok with with me, but I'd like it to be something that is  
> checked
> when the server starts up or restarts (there is an Apache hook for  
> that which might
> be the right thing to use.)  We do something like this for checking  
> global.conf
> and for that matter it wouldn't hurt to run a version of the  
> check_modules script.
> I really like the behavior of moodle which is quite good about  
> insuring database
> updates when ever an update of the system takes place, but we might
> not be able to achieve that all in one go.

I'm initially developing this stuff in wwdb_check, but eventually  
I'll put it into a library and we can call it from web code. Instead  
of doing this the way we did hashDatabaseOK, which ran on every  
request, we should probably call it from the code in webwork.apache- 
config, which gets executed at server startup time.

The check_modules.pl script could similarly be rolled into a library  
and called from webwork.apache-config.
-sam

Re: [WWdevel] some 2.3 notes for you all

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

Hi Sam,

I think this feature should be the highest priority for your time.
A beginning stub for database update will be useful -- it may not
be full featured, but that's ok as long as the stub is moving in the  
right direction.
On Aug 3, 2006, at 2:05 PM, Sam Hathaway wrote:

> -- Automatic Database Update --
>
> wwdb_check will do simple things like adding tables/columns/indexes,
> changing
> column types, and the like. this is sufficient for gavin's current
> changes.
>
> eventually, we need a real database versioning system for more
> complicated
> changes -- filling default values, normalization, and the like -- but
> we don't
> technically have to have this mechanism in place right now.
>
> we just need to ensure that the state of 2.3.0 databases is:
> 	- all tables/columns/indexes up-to-date and using the correct types
> 	- dbupgrade table exists
> 	- db_version=0 in dbupgrade table
>
> (i'm also starting to think that the database upgrading should
> happend offline,
> in a command-line script.)
This is ok with with me, but I'd like it to be something that is checked
when the server starts up or restarts (there is an Apache hook for  
that which might
be the right thing to use.)  We do something like this for checking  
global.conf
and for that matter it wouldn't hurt to run a version of the  
check_modules script.
I really like the behavior of moodle which is quite good about  
insuring database
updates when ever an update of the system takes place, but we might
not be able to achieve that all in one go.

Take care,

Mike

Re: [WWdevel] some 2.3 notes for you all

[P. G. L. <gl...@um...>]

Hi Sam,

> -- Gateway Testing --
> how far along is Gavin in getting this new stuff in/tested/stable?

The Gateway mods are tested---by hand, by myself---but not extensively. 
Which may mean that they're stable, but I usually reserve that 
characterization for when something has survived a semester of use. 
There are two possibly remaining issues: (1) I managed to completely lock 
IE and Windows a couple of times when playing with it.  That didn't happen 
later in testing, and one of the times it locked was from the ProblemSets 
page, not in a Gateway test, so I'm not sure if it is a problem, or if it 
is, if it's a Gateway problem, an IE problem, or a WeBWorK problem; and 
(2) there's a complication when a user who is able to print multiple sets 
tries to print a gateway test: the multi-set selector doesn't show the set 
versions, which makes printing not work.  I'm calling it a known bug for 
now.

I intend(ed) to revisit the instructors' interface to gateway tests, but 
haven't gotten to that.  I'm not sure what the time frame for addressing 
that is (I'm out next week for NExT/Mathfest), but I don't think the 
changes there are critical in any event.

Gavin

-- 
P Gavin LaRose, PhD  |  gl...@um... | 734.764.6454  |  ...you have
Program Manager, Instructional Technology |   to respect someone who can
Mathematics Dept,  University of Michigan | spell  Tuesday, even if they
http://www.math.lsa.umich.edu/~glarose/   | can't spell it right. -Milne

[WWdevel] some 2.3 notes for you all

[Sam H. <sa...@uo...>]

September is sneaking up -- it's looking a little late already to  
release a new
major version. If we were to release before I go to Santa Barbara  
(15-22 Aug),
what would be the minimum we'd need to do?

-- WW/Moodle --

make Course Title/Institution optional in Course Admin
(but also pre-fill these values from mod.html?)

improve wwassignment user experience a bit by creating the bridge  
object before
showing the mod.html form. that way, we can check for and report the  
existence
of the WeBWorK course in mod.html. if it doesn't exist yet, give a  
message like
"The WeBWorK course SCH103 does not exist yet: _Create WeBWorK Course  
SCH103_".

fix problems with teacher login in sql_moodle
<http://bugs.webwork.rochester.edu/show_bug.cgi?id=1043>

-- Gateway Testing --

how far along is Gavin in getting this new stuff in/tested/stable?

he added another database field: i'd REALLY like to have an automatic  
update
mechanism in place so that adding this field wouldn't have to happen  
manually.

-- Automatic Database Update --

wwdb_check will do simple things like adding tables/columns/indexes,  
changing
column types, and the like. this is sufficient for gavin's current  
changes.

eventually, we need a real database versioning system for more  
complicated
changes -- filling default values, normalization, and the like -- but  
we don't
technically have to have this mechanism in place right now.

we just need to ensure that the state of 2.3.0 databases is:
	- all tables/columns/indexes up-to-date and using the correct types
	- dbupgrade table exists
	- db_version=0 in dbupgrade table

(i'm also starting to think that the database upgrading should  
happend offline,
in a command-line script.)

Re: [WWdevel] Preserving state on the server

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

On Jul 28, 2006, at 4:09 PM, John Jones wrote:

> Michael Gage wrote:
>
>>> think the general gist of it is like this:
>>>
>>> So you have state objects in the database (or in memory, or
>>> whatever). They consist of an ID number and an arbitrary number of
>>> key/value pairs. The state IDs should be universally unique and
>>> unpredictable.
>>>
>>
>> Is there any reason the key and the stateID need to be different?
>> I've always
>> rather thought of the key as being a stateID.  One difference is that
>> the key gets updated from time to time and perhaps you'd like the
>> stateID to persist longer.
>
> My understanding was that Sam was suggesting that each stateID applies
> to only one page, whereas the key is typically fixed for a given
> session.  Basically, every page webwork generates would have its own
> stateID which is held until some time period elapses, or maybe killed
> earlier if the user logs out.

Right.
-sam

Re: [WWdevel] Preserving state on the server

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

Michael Gage wrote:

>> think the general gist of it is like this:
>>
>> So you have state objects in the database (or in memory, or
>> whatever). They consist of an ID number and an arbitrary number of
>> key/value pairs. The state IDs should be universally unique and
>> unpredictable.
>>
>
> Is there any reason the key and the stateID need to be different?  
> I've always
> rather thought of the key as being a stateID.  One difference is that  
> the key gets updated from time to time and perhaps you'd like the 
> stateID to persist longer.

My understanding was that Sam was suggesting that each stateID applies 
to only one page, whereas the key is typically fixed for a given 
session.  Basically, every page webwork generates would have its own 
stateID which is held until some time period elapses, or maybe killed 
earlier if the user logs out.

John

Re: [WWdevel] Preserving state on the server (was: SetMaker is slow!)

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

> think the general gist of it is like this:
>
> So you have state objects in the database (or in memory, or
> whatever). They consist of an ID number and an arbitrary number of
> key/value pairs. The state IDs should be universally unique and
> unpredictable.
>

Is there any reason the key and the stateID need to be different?  
I've always
rather thought of the key as being a stateID.  One difference is that  
the key gets updated
from time to time and perhaps you'd like the stateID to persist longer.

-- Mike

[WWdevel] Preserving state on the server (was: SetMaker is slow!)

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

On Jul 28, 2006, at 1:45 PM, Michael Gage wrote:

> (As Sam has
> pointed out elsewhere there are time when the data should really be  
> associated
> with the page and not the session.)

To expand on this... There's a way to store state on the server so  
that it's associated with a request, rather than with a session. I  
think the general gist of it is like this:

So you have state objects in the database (or in memory, or  
whatever). They consist of an ID number and an arbitrary number of  
key/value pairs. The state IDs should be universally unique and  
unpredictable.

Each request to the system would include a state ID parameter. Thus,  
we'd propagate "stateID" the same way we propagate user,  
effectiveUser, and key. (In fact, those variables could just be state  
variables, and the only thing you'd really need to preserve in the  
request would be the state ID.)

Whenever a request comes in, it's checked for a stateID parameter. If  
it has one, and a corresponding state record exists in the database,  
that record is cloned, and given a new ID. Otherwise, a new state  
record is created with a new ID.

So anyway, because each request has its own state record, and each  
subsequent request gets a copy of it's parent's record, you can  
always go back to an earlier page and the state for that page will  
always be there.

For example:

Go view a problem.  (window A)
  you get the problem, in images mode (the default) with stateID=1
Change the display mode to jsMath.
  the system clones state 1 -> state 2
  and sets displayMode to jsMath in state record ID 2
  you get the same page back, only with stateID=2 and jsMath selected
Now, open a link to the next problem in a new window. (window B)
  the system clones state 2 -> state 3
  you get the next problem, with stateID=3, and jsMath selected
Change the display mode to images
  the system clones state 3 -> state 4
  and sets displayMode to jsMath in state record ID 4
  you get the same page back, only with stateID=4 and images selected
Now, go back to window A and reload
  the system clones state 2 -> state 5
  state 2 had displayMode=jsMath, so state 5 does too
  you get the next problem, with stateID=5, and jsMath selected
Then, go back to window B and reload
  the system clones state 4 -> state 6
  state 4 had displayMode=images, so state 6 does too
  you get the next problem, with stateID=6, and images selected

The problem with a scheme like this is that it hides state on the  
server. Also, old state records need to be purged at some point,  
which makes old URLs lose whatever state was stored there. We'd have  
to be really careful about what we used it for -- going back to an  
old link and having the display mode revert to the default doesn't  
seem so bad, but other things might not fail so gracefully.

Re: [WWdevel] SetMaker is slow!

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

I would like to see some tools that would make it easier to cache  
session data
on the server instead of storing it on the page.  We've done that to  
some extent
with the PGproblem editor, but that's really the only place so far.

If we can store session information easily either on the server or on  
the page
we can make the appropriate choice for each piece of data. (As Sam has
pointed out elsewhere there are time when the data should really be  
associated
with the page and not the session.)

-- Mike

On Jul 28, 2006, at 1:29 PM, John Jones wrote:

> Option 2 would probably be the fastest for the user, but storing that
> kind of session information is kind of atypical of webwork.

Re: [WWdevel] SetMaker is slow!

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

Caching can't hurt, but I'd also take another look at the pg  
processing engine --it's pretty old code by now
That's actually a caching problem as well -- but at the moment we're  
only caching a fraction of the
code so perl has to recompile about about half the pg code each time.

Take care,

Mike


On Jul 28, 2006, at 12:16 AM, Sam Hathaway wrote:

> I was thinking that a solution to this would be to cache the entire
> output of the problem processor. For non-interactive situations like
> SetMaker, the only thing we'd need to cache on is the problem seed --
> other data (like num_correct, num_incorrect, etc.) are always the  
> same.

Re: [WWdevel] SetMaker is slow!

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

Hi,

Problem caching would probably speed things up considerably.  
Personally, I set the number of problems displayed to 5 to account for 
this (and use display=none as Arnie mentions for some special uses like 
cloning a problem set).  I guess the question is how much disk space 
this will use, especially if you do some sort of pre-caching.

Something else to be aware of is a second cause of slowness in SetMaker 
which this would not address.  When you ask for 1000 problems and only 
display 5 of them, it some how has to keep track of what those problems 
are, with the sequential order in tact, so that it can handle next/prev 
page links.  Currently it stuffs them all in a hidden cgi field of the 
page.  If someone accidentally asks for all problems from 
database_problems, that's 10,000 lines - you might as well kill the 
browser and start over.

It seems that there are 3 options for that: 1) leave it as it is; 2) 
store the information on the server instead of in the page; or 3) 
recompute the list on each refresh to know which problems to display.

The third option probably wouldn't be too bad, but it would require that 
when a list of problems is made, including by a database search or by 
disk searching, that they get sorted into some canonical order.

Option 2 would probably be the fastest for the user, but storing that 
kind of session information is kind of atypical of webwork.

John


Arnold Pizer wrote:

>At 12:16 AM 7/28/2006, Sam Hathaway wrote:
>
>I think something like this would be a very good idea. I almost 
>always use "none" for the display mode when"viewing" a large set. In 
>fact after the first time I tried the library browser, I told John we 
>needed a "none" mode because things were so slow. He added it almost 
>immediately.  The "none" mode would still be useful as it compresses 
>output but most people want to see the problems (not just file names) 
>so speeding things up would be a great help.
>
>Arnie
>
>
>  
>
>>Hey,
>>
>>Does it bother anyone else how slow SetMaker is? It's not that
>>module's fault, it just takes a long time to render problems, and
>>rendering 20 of them gets pretty insane.
>>
>>I was thinking that a solution to this would be to cache the entire
>>output of the problem processor. For non-interactive situations like
>>SetMaker, the only thing we'd need to cache on is the problem seed --
>>other data (like num_correct, num_incorrect, etc.) are always the same.
>>
>>The cache could simply be a file containing the problem TEXT, named
>>based on the source file name and the problem seed, or we could get a
>>little more complex and also store the names of any temporary files
>>that the problem depends on. That way, deleting, say, a generated
>>graph would invalidate the cache and cause the problem to be re-
>>rendered.
>>
>>This would speed up problem browsing TREMENDOUSLY, since PG wouldn't
>>even run once ANYONE had browsed a problem set. This might even be a
>>good candidate for pre-caching -- run through the problem library
>>once with seed 1234 to save a lot of instructor time down the road.
>>
>>Any thoughts?
>>-sam
>>    
>>

Re: [WWdevel] how to set up directories

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

At 10:39 AM 7/28/2006, Sam Hathaway wrote:

Thanks Sam.  I'll write up my documentation using the setup below 
(with /opt/webwork/libraries/asu_problib, etc).

At some point we should change global.conf.dist and all the related 
documentation (including what I'm now writing) but I don't want to 
get sidelined with this just now.

Arnie

>On Jul 28, 2006, at 9:58 AM, Arnold Pizer wrote:
>
>>/opt/webwork/webwork2
>>/opt/webwork/pg
>>/opt/webwork/courses
>
>That works for me. Or even /opt/ww/... for conciseness.
>
>>for libraries we could do either
>>/opt/webwork/asu_problib
>>/opt/webwork/rochester_problib
>>/opt/webwork/union_problib
>>etc or
>>/opt/webwork/libraries/asu_problib
>
>I like the second option.
>-sam
>

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

Re: [WWdevel] how to set up directories

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

On Jul 28, 2006, at 9:58 AM, Arnold Pizer wrote:

> /opt/webwork/webwork2
> /opt/webwork/pg
> /opt/webwork/courses

That works for me. Or even /opt/ww/... for conciseness.

> for libraries we could do either
> /opt/webwork/asu_problib
> /opt/webwork/rochester_problib
> /opt/webwork/union_problib
> etc or
> /opt/webwork/libraries/asu_problib

I like the second option.
-sam

[WWdevel] how to set up directories

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

Hi,

I'm writing up specific instructions for installing WW on SUSE 10.1 
aimed at non unix experts. There will be versions for other OS's.  in 
doing this I'm thinking about our default directory set up. It is

/opt/webwork2
/opt/pg

For courses
/opt/webwork2/courses

and I can't find (but haven't looked much) default locations for 
libraries.  If we followed the pattern it would be I guess
/opt/asu_problib
etc
Also if wwmoodle remains a high level directory, I assume we would have
/opt/wwmoodle

I think it would be better to put everything under a webwork 
directory and also to move courses up from under webwork2.  People 
might want to update WW by moving webwork2 to webwork2.bak and 
installing a complete new system but they will most likely want to 
keep their courses directory. Everything in the courses directory is 
local except for the model course and even that get's 
localized.  When installing we could tell people to move the model 
course and associated classlists (they are in fact .dist versions 
without the .dist extension). So here is what I think would be better:

/opt/webwork/webwork2
/opt/webwork/pg
/opt/webwork/courses

for libraries we could do either
/opt/webwork/asu_problib
/opt/webwork/rochester_problib
/opt/webwork/union_problib
etc or
/opt/webwork/libraries/asu_problib

Any thoughts on this?

Arnie



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

Re: [WWdevel] SetMaker is slow!

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

At 12:16 AM 7/28/2006, Sam Hathaway wrote:

I think something like this would be a very good idea. I almost 
always use "none" for the display mode when"viewing" a large set. In 
fact after the first time I tried the library browser, I told John we 
needed a "none" mode because things were so slow. He added it almost 
immediately.  The "none" mode would still be useful as it compresses 
output but most people want to see the problems (not just file names) 
so speeding things up would be a great help.

Arnie


>Hey,
>
>Does it bother anyone else how slow SetMaker is? It's not that
>module's fault, it just takes a long time to render problems, and
>rendering 20 of them gets pretty insane.
>
>I was thinking that a solution to this would be to cache the entire
>output of the problem processor. For non-interactive situations like
>SetMaker, the only thing we'd need to cache on is the problem seed --
>other data (like num_correct, num_incorrect, etc.) are always the same.
>
>The cache could simply be a file containing the problem TEXT, named
>based on the source file name and the problem seed, or we could get a
>little more complex and also store the names of any temporary files
>that the problem depends on. That way, deleting, say, a generated
>graph would invalidate the cache and cause the problem to be re-
>rendered.
>
>This would speed up problem browsing TREMENDOUSLY, since PG wouldn't
>even run once ANYONE had browsed a problem set. This might even be a
>good candidate for pre-caching -- run through the problem library
>once with seed 1234 to save a lot of instructor time down the road.
>
>Any thoughts?
>-sam
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>OpenWeBWorK-Devel mailing list
>Ope...@li...
>https://lists.sf.net/lists/listinfo/openwebwork-devel

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

[WWdevel] SetMaker is slow!

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

Hey,

Does it bother anyone else how slow SetMaker is? It's not that  
module's fault, it just takes a long time to render problems, and  
rendering 20 of them gets pretty insane.

I was thinking that a solution to this would be to cache the entire  
output of the problem processor. For non-interactive situations like  
SetMaker, the only thing we'd need to cache on is the problem seed --  
other data (like num_correct, num_incorrect, etc.) are always the same.

The cache could simply be a file containing the problem TEXT, named  
based on the source file name and the problem seed, or we could get a  
little more complex and also store the names of any temporary files  
that the problem depends on. That way, deleting, say, a generated  
graph would invalidate the cache and cause the problem to be re- 
rendered.

This would speed up problem browsing TREMENDOUSLY, since PG wouldn't  
even run once ANYONE had browsed a problem set. This might even be a  
good candidate for pre-caching -- run through the problem library  
once with seed 1234 to save a lot of instructor time down the road.

Any thoughts?
-sam

[WWdevel] LaTeXMathML.js

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

Folks:

We recently received the following from Peter Jipsen, the author of  
ASCIIMathML.js:

> Dear WeBWorKers,
>
> I am flattered that ASCIIMathML.js became a display option of  
> WeBWorK a couple of years ago. Unfortunately it never really worked  
> well enough for the LaTeX that is used in most WeBWorK problems, so  
> I am happy to report that Douglas Woodall has recently created a  
> modified version of ASCIIMathML.js, called LaTeXMathML.js that  
> handles a much greater fragment of LaTeX (and disables the  
> ASCIIMath syntax). So this should integrate better with WeBWorK,  
> producing mostly correct MathML output for the LaTeX in the input  
> problems.
>
> Regards,
> Peter

I took a quick look at LaTeXMathML, and it definitely would be a  
useful output mode, and would not be hard to include into WeBWorK.   
I'll volunteer to do it, since I added ASCIIMathML, but I won't be  
able to work on it until after MathFest next month.

Although this will be much more compatible with the existing WeBWorK  
problems, there are still going to be some problems.  One is that he  
has not implemented \sqrt[n], which I know is used in some problems.   
Another is that it looks like he hasn't really implemented the  
difference between in-line and display math (the fact that  
mathematics is on a line by itself is to be handled by the  
surrounding HTML).  I think that everything is typeset as though it  
were in display mode, so that means that things like sums and limits  
that appear in-line will be typeset using large operators with limits  
above and below, rather than the text-style smaller operators with  
limits to the right.  That may not be a big deal, but it is one way  
that the output will differ from what is actually indicated in the  
problem.  (I haven't really checked this carefully, but that's what  
seemed to be indicated in the documentation.)  There will probably be  
some other commands that are used in WeBWorK problems that might not  
be rendered properly by LaTeXMathML, so I think the result will be  
that most, but not all, problems will work with it.

In any case, it looks like a valuable addition to the WeBWorK display  
options.

Davide

Re: [WWdevel] CGI weirdness under Apache 1

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

On Jul 20, 2006, at 9:14 PM, Michael Gage wrote:

>>
>> I tried attacking this from the other angle -- delete all the  
>> params from the CGI object before any form field functions can be  
>> called. This makes all requests (GET and POST) under both versions  
>> of Apache behave like POST requests under Apache 1. As far as I  
>> can tell, this is working. Plus, it's a much less invasive  
>> solution than CGIParamShim or CGIeasytags -- it's pretty much a  
>> one-liner in a subclass.
>>
>> I've added it as WeBWorK::CGIDeleteParams. I also added it as an  
>> alternative in WeBWorK::CGI. It needs additional testing, which I  
>> will give it as I continue porting efforts.
>>
> I thought of that but I was afraid that would mean disabling the $r- 
> >param()  function as well.  How do you keep $r->param from being  
> affected?

CGI.pm keeps its own internal copy of the params, that it parses  
itself from $r->args (in the case of GET requests) or STDIN (in the  
case of POST requests). I clear our that list, but don't touch  
WeBWorK::Request.

CGI and WeBWorK::Request are still inconsistent w.r.t. to params, but  
now they're inconsistent in a safe way. :)
-sam

Re: [WWdevel] CGI weirdness under Apache 1

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

>
> I tried attacking this from the other angle -- delete all the  
> params from the CGI object before any form field functions can be  
> called. This makes all requests (GET and POST) under both versions  
> of Apache behave like POST requests under Apache 1. As far as I can  
> tell, this is working. Plus, it's a much less invasive solution  
> than CGIParamShim or CGIeasytags -- it's pretty much a one-liner in  
> a subclass.
>
> I've added it as WeBWorK::CGIDeleteParams. I also added it as an  
> alternative in WeBWorK::CGI. It needs additional testing, which I  
> will give it as I continue porting efforts.
>
I thought of that but I was afraid that would mean disabling the $r- 
 >param()  function as well.  How do you keep $r->param from being  
affected?


>> I haven't been doing
>> lots of testing with the standard CGI -- are you still getting  
>> weird behavior a lot of the time?
>
> Yeah, CGIParamShim wasn't really solving the problem. But  
> CGIDeleteParams seems to so far.
>
Good.
>> We could also decide to go with CGIeasytags.  If the extra {} are  
>> bothering you, we can
>> be a bit more clever about deciding whether the input to CGI::foo 
>> () is of the form:
>> (1) CGI::foo({params], text]    -- easy
>> (2) CGI::foo(-name=>'foo', value = >'bar') or
>> (3) CGI:: foo( "name", "foo", "value", "bar")  i.e.  is supposed  
>> to produce namefoovaluebar
>> (4)CGI::foo("foo", "bar");
>>
>> Nothing would be perfect but one could do a lot more than I tried to.
>
> The extra {} are a bit annoying, but what really bugs me about  
> CGIeasytags is that you've had to reimplement parts of CGI (and  
> CGI::Util) to make it compatible with how we've been calling CGI  
> functions.
>
Yep.  I wasn't happy as things went that way either.  I think I kept  
the rules so that they were a slightly more rigid version of the  
original CGI rules
fewer special cases.
> I just recently discovered the rearrange function in CGI::Util. It  
> does most of the parameter munging for the CGI functions, and  
> handles all four of the forms you list above. For example, here's  
> the call in CGI::hidden:
>
>     my($name,$default,$override,@other) =
> 	rearrange([NAME,[DEFAULT,VALUE,VALUES],[OVERRIDE,FORCE]],@p);
>
I'll keep that in mind.  I hadn't looked at that function -- it might  
well make CGIeasytags even more CGI compatible.  I'll take a look at  
it if it's needed.
let's see how this deleteparameter patch goes.


> If you think CGI::EasyTags is the way to go, you might consider  
> replacing the parameter parsing with calls to rearrange.
Good idea.

> -sam

Take care,

Mike