WeBWorK Problems

local/Library/....

local/Library/....

by Daryl Tingley -
Number of replies: 7
When I click "edit problem" for a problem, say,

Library/FortLewis/Calc3/13-3-Dot-product/geometric-dot-product/geometric-dot-product.pg

the default "Save As" location is something like

local/Library/FortLewis/Calc3/13-3-Dot-product/geometric-dot-product/geometric-dot-product.pg

which would be fine, except...

problems in local/Library do not appear in the list of "Select a Problem Collection" in the Library Broswer, when Browsing Local problems. If the problem is saved  anywhere except in local/Library it shows up fine when browing. 

Is this as intended?  If so, can it be changed?

Daryl
In reply to Daryl Tingley

Re: local/Library/....

by Michael Gage -
Hi Daryl,

I can reproduce this. I can't say that I've noticed this before. It's not intended. I've submitted as a bug.

-- Mike



In reply to Daryl Tingley

Re: local/Library/....

by Michael Gage -
for now you can work around this by relabeling this as /local/library/.....

you can use the FileManager to rename local/Library/.... to local/library


that will fix the problem.

SetMaker is not displaying directories named Library (at any level) because they might be links to the NationalProblemLibrary and your list will get overwhelmed.

There are a number of possibilities for fixing this -- they may have unintended consequences. For example:

If we determined that all files listed under Local Problems had to actually reside in the template directory (i.e. in searching for files the program would never follow symlinks (aliases) ) would that cause anyone any problems?

That seems the best fix to me at the moment.

In reply to Michael Gage

Re: local/Library/....

by Michael Gage -


On Sep 25, 2011, at 10:01 PM, Daryl Tingley wrote:

Hi Thanks for your efforts. My work around is to make a symbolic link to the Library directory in local: ln -s Library library
Although I wonder if that will have unintended consequences. Not following symbolic links would not be a problem for me, but I can see it might be confusing for anyone who is now using them in local.


Daryl

that will work as long as you are linking directly to the templates/Library directory. Normally Library is an alias
pointing to NationalProblemLibrary -- and the problem (which by the way turns out not to be new -- just that no-one noticed)
by an attempt NOT to follow the library list and list the entire NPL when listing local problems.

-- Mike
In reply to Michael Gage

Re: local/Library/....

by Michael Gage -
The problem seems to be that the editor, by default, saves files to local/Library/ so
why not just change the default file name to something like local/NPL/
that doesn't use the word "Library" ?

Maybe there ought to be an error message warning people that "subdirectories of templates/ with names containing
the word Library will not be displayed."

George

This would is simple and would solve the immediate problem. I'll make that change for now. Philosophically, should we insist that a search for "Local Problems" not follow links? or should we allow following links in general and simply not follow any link or directory labeled Library (the current behavior).
In reply to Michael Gage

Re: local/Library/....

by Arnold Pizer -
Hi,

I think I would vote for the "Local" button not to follow symlinks so that "Local" only gives things in the local templates directory.

Not looking at the code, I had assumed that the problem was that directories were not being search recursively when one hit "Local".  I think it's pretty fragile to base the action on the word "Library". 

Arnie
In reply to Michael Gage

Re: local/Library/....

by Dick Lane -
Do any of the options being considered affect the possibility of having tagging info in local problems be added to the local database for filtering and searching?

re Arnie's comment about fragility, might a variant of the "hide_directory" trick be useful to inhibit an accidental inundation caused by a deep recursion?