From: Michael G. <ga...@ma...> - 2005-08-31 20:51:56
|
On Aug 31, 2005, at 3:08 PM, Davide P. Cervone wrote: >> Michael Gage wrote: >> >>> Privately (but not formally) I had used the convention that when >>> constructing a directory contaning a >>> .pg file and auxiliary files that the directory name was >>> related to the .pg name e.g. prob1/prob1.pg >>> >>> Would it be reasonable to add that condition to the default >>> method for "combining up"? I know the rules I used for making >>> these problems, but I haven't searched through the rest of the >>> problem collections, so perhaps there are reasons not to do this. >>> >> >> I am not sure I understand. Is the suggestion that outside of >> other hints like =library-combine-up, a directory named this- >> directory containing one pg file problem.pg should not be combined >> up because the name of the pg file doesn't match the name of the >> directory? >> > > I think what he is suggesting is that (in the absense of =library- > combine-up or =library-no-combine-up) a directory with one pg file > will be combined upward only if the directory name is the same as > the problem name. So prob1/prob1.pg would but setSparse/prob1.pg > would not. I don't have any problem with that, but haven't looked > at hard it would be to accomplish it. Should be straight forward, > I would think. > That's what I'm suggesting. It is my private naming convention for problems with auxiliary files. > Another possibility would be not to combine up into the top level > at all (unless explicitly requested). > I'd prefer the currently implemented system to this. The goal of representing a ".pg file with accompanying auxiliary files" as a single problem in the library is the right approach. The only question is how to best recognize when we are dealing with a ".pg file with accompanying auziliary files". What I'd REALLY like is resource forks for files a la the old mac system -- but that's not immediately available. Perhaps there is some other way to implement it. How does the new Mac simulate "applications" that are really folders containing code files and auxiliary files? > >>> On Aug 31, 2005, at 8:20 AM, Davide P. Cervone wrote: >>> >>>> Yes, that was the problem. I still can't think of a better >>>> name, can anyone else? "Toplevel Problems"? "Unclassified >>>> Problems"? >>>> >> >> I don't have strong feelings about this, especially since it >> should be a moot question (a standard problem collection probably >> shouldn't have problems there). But, now that I think about it, >> Unclassified might be better than Main or Toplevel. The latter >> two could be construed as meaning that these problems are >> especially important. But, Unclassified could inaccurate if a >> problem is the lone problem in its classification. How about >> "Misc. Problems"? >> > > That would be fine by me. It is easy to change, since there is a > constant at the top of the file for the phrase to be used. > Unclassified sounds good to me. Take care, Mike > 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 > |