workingwiki-users — Email list for WorkingWiki users (including WW admin and ProjectEngine topics)

[ww-users] FAQs?

[Peter L. R. <pl...@st...>]

Hi, all -- I've added an FAQ page for WW to the documentation.  This is
because I wanted to write up the answer to "How do I upload a
{spreadsheet, image, binary file} to my project?" and this didn't seem
to go exactly into the other categories of documentation existing.  The
information is certainly there otherwise, but harder for people to
access.  If you disagree, move it?  We could also collect ideas of FAQs
here to serve as a useful reference to folks trying to remember what the
right way to do certain things is.

-p

Re: [ww-users] Latex batch mode

[Lee W. <wor...@gm...>]

Yes, the workflow is different.  Currently if WW successfully produces a 
pdf file or any other file, it provides the file and the usual link to 
the logfile without indicating whether there are errors reported in the 
logfile or not.  It would be possible for WW to parse the messages 
output by latex and produce a message if there were non-fatal errors, 
but it seems like it would require a somewhat deep change in WW's design.

Users can display the .make.log file on the wiki page, to see whether 
there are errors without needing to follow the [log] link.

It would also be possible to do more sophisticated error reporting 
within the current design, by creating a rule to make a .latex.errors 
file from the .make.log file and displaying that in the wiki page - or, 
if you want to be fancy, a nicely formatted .latex.errors.wikitext or 
.latex.errors.html (or even .latex.errors.tex).  You can do this 
yourself, and if I did it for you this is probably the route I would 
favor.  Jonathan has done error output rules much like this for R output.

Relatedly, I've learned of a tool called latexmk and am wondering 
whether we should consider using that instead of the make rules that are 
currently in there to coordinate remaking pdfs from all the source 
files.  All opinions are welcome.  The sourceforge tracker entry is open 
for comments: 
https://sourceforge.net/tracker/index.php?func=detail&aid=3388647&group_id=366300&atid=1527388

Thanks for the ideas -
LW

On 08/17/11 09:38, Walt Mankowski wrote:
> I'll give you an example of how emacs handles this.  Let's say I have
> this line in my dissertation
>
>    $i$.  As with edit distance (c.f.\ Equation~\ref{eqn:sim_ed}), we
>
> and I change it to this:
>
>    $i$.  As with edit distance (c.f.\ Equation~\reff{eqn:sim_ed}), we
>
> When I compile the first one inside emacs, it chugs for a few seconds
> and then says
>
>    LaTeX: successfully formatted {58} pages
>
> and creates a new PDF.  But when I compile the second one, it says
>
>    LaTeX errors in `*~/drexel/thesis/dissertation/thesis output*'. Use C-c ` to display.
>
> If I enter C-c `, I go to a new buffer emacs created with the LaTeX error:
>
>    ERROR: Undefined control sequence.
>
>    --- TeX said ---
>    l.924 ... with edit distance (c.f.\ Equation~\reff
>                                                      {eqn:sim_ed}), we
>    --- HELP ---
>    TeX encountered an unknown command name. You probably misspelled the
>    name. If this message occurs when a LaTeX command is being processed,
>    the command is probably in the wrong place---for example, the error
>    can be produced by an \item command that's not inside a list-making
>    environment. The error can also be caused by a missing \documentclass
>    command.
>
> But it *also* created the PDF, and the line with the equation
> reference has an obvious formatting problem on it.
>
> Obviously your workflow is different inside workingwiki, but this
> sounded like what David was asking for.  I just wanted to point out
> that it's at least possible to get both an error report and a new PDF.
>
> Walt
>
> On Wed, Aug 17, 2011 at 04:41:12AM -0400, Jonathan Dushoff wrote:
>> It's not obvious (at least to me) what you both mean by "error
>> report".  WW will certainly put the latex errors into the make log,
>> but I guess Lee means to make it not report an error condition (so
>> that it will keep going ahead with make, and so that WW will be
>> willing to show you the file).
>>
>> Probably we should all be looking at our make logs more -- and looking
>> at the log before submitting something important in LaTeX has always
>> been a good idea that a lot of us skip, even before we had WW.
>>
>> JD
>>
>> On Tue, Aug 16, 2011 at 10:35 AM, Walt Mankowski<wa...@po...>  wrote:
>>> I generally compile latex documents inside emacs.  Emacs's latex mode
>>> is somehow smart enough to do both -- produce a (generally wrong) PDF
>>> file, and give you an error report.  I don't know how it's doing that,
>>> but it's at least possible to do both.
>>
>>> On Mon, Aug 08, 2011 at 03:25:20PM -0700, Lee Worden wrote:
>>>> By request, I'm trying a change in WorkingWiki's behaviour, by having it
>>>> try to finish processing latex documents even if they have errors in
>>>> them.  This only applies to creating pdf files, not to creating the HTML
>>>> version of the document that you see in the wiki page (which is already
>>>> error-tolerant).
>>
>>>> This means that if your document has errors, you're more likely to get a
>>>> pdf file and less likely to get an error report.  If the pdf file seems
>>>> strange, you may want to look at the log file despite the lack of error
>>>> report.
>>
>>>> If you get messages like "make succeeded but did not produce
>>>> my-thing.pdf" (or if anything else seems strange or wrong) please let me
>>>> know and I'll try to improve the situation.
>>
>>>> Thanks,
>>>> Lee
>>
>>>> -------- Original Message --------
>>>> Subject: [ workingwiki-Feature Requests-3297260 ] Latex batch mode
>>>> Date: Mon, 08 Aug 2011 15:07:14 -0700
>>>> From: SourceForge.net<no...@so...>
>>>> To: SourceForge.net<no...@so...>
>>
>>>> Feature Requests item #3297260, was opened at 2011-05-03 19:28
>>>> Message generated for change (Comment added) made by worden
>>>> You can respond by visiting:
>>>> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300
>>
>>>> Please note that this message will contain a full copy of the comment
>>>> thread,
>>>> including the initial issue submission, for this request,
>>>> not just the latest update.
>>>> Category: None
>>>>> Group: Refactored WorkingWiki
>>>>> Status: Closed
>>>> Priority: 5
>>>> Private: No
>>>> Submitted By: Jonathan Dushoff (dushoff)
>>>>> Assigned to: Lee Worden (worden)
>>>> Summary: Latex batch mode
>>
>>>> Initial Comment:
>>>> David Earn suggests that the wiki should do latex in batch mode by
>>>> default.  This just means that it would try to produce PDF output even
>>>> when encountering an error.  This could help in finding errors, I think,
>>>> but I'm not sure how valuable it would be -- given that we already have
>>>> the .xhtml version.
>>
>>
>>>> ----------------------------------------------------------------------
>>
>>>>> Comment By: Lee Worden (worden)
>>>> Date: 2011-08-08 15:07
>>
>>>> Message:
>>>> OK, trying it out in r729.  I had to put -interaction=nonstopmode on the
>>>> command line to have it keep going to the end of the document, and put a -
>>>> sign in front of the command to have make ignore the error code that it
>>>> returns.  So we'll want to keep an eye out for 'make succeeded but did not
>>>> produce document.pdf'.  If that starts happening, please let me know and
>>>> I'll try to come up with a better kind of diagnostic output.
>>
>>>> ----------------------------------------------------------------------
>>
>>>> You can respond by visiting:
>>>> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300
>>
>>>> ------------------------------------------------------------------------------
>>>> uberSVN's rich system and user administration capabilities and model
>>>> configuration take the hassle out of deploying and managing Subversion and
>>>> the tools developers use with it. Learn more about uberSVN and get a free
>>>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>>>> _______________________________________________
>>>> workingwiki-users mailing list
>>>> wor...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] Latex batch mode

[Walt M. <wa...@po...>]

I'll give you an example of how emacs handles this.  Let's say I have
this line in my dissertation

  $i$.  As with edit distance (c.f.\ Equation~\ref{eqn:sim_ed}), we

and I change it to this:

  $i$.  As with edit distance (c.f.\ Equation~\reff{eqn:sim_ed}), we

When I compile the first one inside emacs, it chugs for a few seconds
and then says

  LaTeX: successfully formatted {58} pages

and creates a new PDF.  But when I compile the second one, it says

  LaTeX errors in `*~/drexel/thesis/dissertation/thesis output*'. Use C-c ` to display.

If I enter C-c `, I go to a new buffer emacs created with the LaTeX error:

  ERROR: Undefined control sequence.

  --- TeX said ---
  l.924 ... with edit distance (c.f.\ Equation~\reff
                                                    {eqn:sim_ed}), we
  --- HELP ---
  TeX encountered an unknown command name. You probably misspelled the
  name. If this message occurs when a LaTeX command is being processed,
  the command is probably in the wrong place---for example, the error
  can be produced by an \item command that's not inside a list-making
  environment. The error can also be caused by a missing \documentclass
  command.

But it *also* created the PDF, and the line with the equation
reference has an obvious formatting problem on it.

Obviously your workflow is different inside workingwiki, but this
sounded like what David was asking for.  I just wanted to point out
that it's at least possible to get both an error report and a new PDF.

Walt

On Wed, Aug 17, 2011 at 04:41:12AM -0400, Jonathan Dushoff wrote:
> It's not obvious (at least to me) what you both mean by "error
> report".  WW will certainly put the latex errors into the make log,
> but I guess Lee means to make it not report an error condition (so
> that it will keep going ahead with make, and so that WW will be
> willing to show you the file).
> 
> Probably we should all be looking at our make logs more -- and looking
> at the log before submitting something important in LaTeX has always
> been a good idea that a lot of us skip, even before we had WW.
> 
> JD
> 
> On Tue, Aug 16, 2011 at 10:35 AM, Walt Mankowski <wa...@po...> wrote:
> > I generally compile latex documents inside emacs.  Emacs's latex mode
> > is somehow smart enough to do both -- produce a (generally wrong) PDF
> > file, and give you an error report.  I don't know how it's doing that,
> > but it's at least possible to do both.
> 
> > On Mon, Aug 08, 2011 at 03:25:20PM -0700, Lee Worden wrote:
> >> By request, I'm trying a change in WorkingWiki's behaviour, by having it
> >> try to finish processing latex documents even if they have errors in
> >> them.  This only applies to creating pdf files, not to creating the HTML
> >> version of the document that you see in the wiki page (which is already
> >> error-tolerant).
> 
> >> This means that if your document has errors, you're more likely to get a
> >> pdf file and less likely to get an error report.  If the pdf file seems
> >> strange, you may want to look at the log file despite the lack of error
> >> report.
> 
> >> If you get messages like "make succeeded but did not produce
> >> my-thing.pdf" (or if anything else seems strange or wrong) please let me
> >> know and I'll try to improve the situation.
> 
> >> Thanks,
> >> Lee
> 
> >> -------- Original Message --------
> >> Subject: [ workingwiki-Feature Requests-3297260 ] Latex batch mode
> >> Date: Mon, 08 Aug 2011 15:07:14 -0700
> >> From: SourceForge.net <no...@so...>
> >> To: SourceForge.net <no...@so...>
> 
> >> Feature Requests item #3297260, was opened at 2011-05-03 19:28
> >> Message generated for change (Comment added) made by worden
> >> You can respond by visiting:
> >> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300
> 
> >> Please note that this message will contain a full copy of the comment
> >> thread,
> >> including the initial issue submission, for this request,
> >> not just the latest update.
> >> Category: None
> >> >Group: Refactored WorkingWiki
> >> >Status: Closed
> >> Priority: 5
> >> Private: No
> >> Submitted By: Jonathan Dushoff (dushoff)
> >> >Assigned to: Lee Worden (worden)
> >> Summary: Latex batch mode
> 
> >> Initial Comment:
> >> David Earn suggests that the wiki should do latex in batch mode by
> >> default.  This just means that it would try to produce PDF output even
> >> when encountering an error.  This could help in finding errors, I think,
> >> but I'm not sure how valuable it would be -- given that we already have
> >> the .xhtml version.
> 
> 
> >> ----------------------------------------------------------------------
> 
> >> >Comment By: Lee Worden (worden)
> >> Date: 2011-08-08 15:07
> 
> >> Message:
> >> OK, trying it out in r729.  I had to put -interaction=nonstopmode on the
> >> command line to have it keep going to the end of the document, and put a -
> >> sign in front of the command to have make ignore the error code that it
> >> returns.  So we'll want to keep an eye out for 'make succeeded but did not
> >> produce document.pdf'.  If that starts happening, please let me know and
> >> I'll try to come up with a better kind of diagnostic output.
> 
> >> ----------------------------------------------------------------------
> 
> >> You can respond by visiting:
> >> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300
> 
> >> ------------------------------------------------------------------------------
> >> uberSVN's rich system and user administration capabilities and model
> >> configuration take the hassle out of deploying and managing Subversion and
> >> the tools developers use with it. Learn more about uberSVN and get a free
> >> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> >> _______________________________________________
> >> workingwiki-users mailing list
> >> wor...@li...
> >> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] Latex batch mode

[Jonathan D. <du...@mc...>]

It's not obvious (at least to me) what you both mean by "error
report".  WW will certainly put the latex errors into the make log,
but I guess Lee means to make it not report an error condition (so
that it will keep going ahead with make, and so that WW will be
willing to show you the file).

Probably we should all be looking at our make logs more -- and looking
at the log before submitting something important in LaTeX has always
been a good idea that a lot of us skip, even before we had WW.

JD

On Tue, Aug 16, 2011 at 10:35 AM, Walt Mankowski <wa...@po...> wrote:
> I generally compile latex documents inside emacs.  Emacs's latex mode
> is somehow smart enough to do both -- produce a (generally wrong) PDF
> file, and give you an error report.  I don't know how it's doing that,
> but it's at least possible to do both.

> On Mon, Aug 08, 2011 at 03:25:20PM -0700, Lee Worden wrote:
>> By request, I'm trying a change in WorkingWiki's behaviour, by having it
>> try to finish processing latex documents even if they have errors in
>> them.  This only applies to creating pdf files, not to creating the HTML
>> version of the document that you see in the wiki page (which is already
>> error-tolerant).

>> This means that if your document has errors, you're more likely to get a
>> pdf file and less likely to get an error report.  If the pdf file seems
>> strange, you may want to look at the log file despite the lack of error
>> report.

>> If you get messages like "make succeeded but did not produce
>> my-thing.pdf" (or if anything else seems strange or wrong) please let me
>> know and I'll try to improve the situation.

>> Thanks,
>> Lee

>> -------- Original Message --------
>> Subject: [ workingwiki-Feature Requests-3297260 ] Latex batch mode
>> Date: Mon, 08 Aug 2011 15:07:14 -0700
>> From: SourceForge.net <no...@so...>
>> To: SourceForge.net <no...@so...>

>> Feature Requests item #3297260, was opened at 2011-05-03 19:28
>> Message generated for change (Comment added) made by worden
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300

>> Please note that this message will contain a full copy of the comment
>> thread,
>> including the initial issue submission, for this request,
>> not just the latest update.
>> Category: None
>> >Group: Refactored WorkingWiki
>> >Status: Closed
>> Priority: 5
>> Private: No
>> Submitted By: Jonathan Dushoff (dushoff)
>> >Assigned to: Lee Worden (worden)
>> Summary: Latex batch mode

>> Initial Comment:
>> David Earn suggests that the wiki should do latex in batch mode by
>> default.  This just means that it would try to produce PDF output even
>> when encountering an error.  This could help in finding errors, I think,
>> but I'm not sure how valuable it would be -- given that we already have
>> the .xhtml version.


>> ----------------------------------------------------------------------

>> >Comment By: Lee Worden (worden)
>> Date: 2011-08-08 15:07

>> Message:
>> OK, trying it out in r729.  I had to put -interaction=nonstopmode on the
>> command line to have it keep going to the end of the document, and put a -
>> sign in front of the command to have make ignore the error code that it
>> returns.  So we'll want to keep an eye out for 'make succeeded but did not
>> produce document.pdf'.  If that starts happening, please let me know and
>> I'll try to come up with a better kind of diagnostic output.

>> ----------------------------------------------------------------------

>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300

>> ------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> workingwiki-users mailing list
>> wor...@li...
>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] Latex batch mode

[Walt M. <wa...@po...>]

I generally compile latex documents inside emacs.  Emacs's latex mode
is somehow smart enough to do both -- produce a (generally wrong) PDF
file, and give you an error report.  I don't know how it's doing that,
but it's at least possible to do both.

On Mon, Aug 08, 2011 at 03:25:20PM -0700, Lee Worden wrote:
> By request, I'm trying a change in WorkingWiki's behaviour, by having it 
> try to finish processing latex documents even if they have errors in 
> them.  This only applies to creating pdf files, not to creating the HTML 
> version of the document that you see in the wiki page (which is already 
> error-tolerant).
> 
> This means that if your document has errors, you're more likely to get a 
> pdf file and less likely to get an error report.  If the pdf file seems 
> strange, you may want to look at the log file despite the lack of error 
> report.
> 
> If you get messages like "make succeeded but did not produce 
> my-thing.pdf" (or if anything else seems strange or wrong) please let me 
> know and I'll try to improve the situation.
> 
> Thanks,
> Lee
> 
> -------- Original Message --------
> Subject: [ workingwiki-Feature Requests-3297260 ] Latex batch mode
> Date: Mon, 08 Aug 2011 15:07:14 -0700
> From: SourceForge.net <no...@so...>
> To: SourceForge.net <no...@so...>
> 
> Feature Requests item #3297260, was opened at 2011-05-03 19:28
> Message generated for change (Comment added) made by worden
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300
> 
> Please note that this message will contain a full copy of the comment 
> thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: None
> >Group: Refactored WorkingWiki
> >Status: Closed
> Priority: 5
> Private: No
> Submitted By: Jonathan Dushoff (dushoff)
> >Assigned to: Lee Worden (worden)
> Summary: Latex batch mode
> 
> Initial Comment:
> David Earn suggests that the wiki should do latex in batch mode by 
> default.  This just means that it would try to produce PDF output even 
> when encountering an error.  This could help in finding errors, I think, 
> but I'm not sure how valuable it would be -- given that we already have 
> the .xhtml version.
> 
> 
> ----------------------------------------------------------------------
> 
> >Comment By: Lee Worden (worden)
> Date: 2011-08-08 15:07
> 
> Message:
> OK, trying it out in r729.  I had to put -interaction=nonstopmode on the
> command line to have it keep going to the end of the document, and put a -
> sign in front of the command to have make ignore the error code that it
> returns.  So we'll want to keep an eye out for 'make succeeded but did not
> produce document.pdf'.  If that starts happening, please let me know and
> I'll try to come up with a better kind of diagnostic output.
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300
> 
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model 
> configuration take the hassle out of deploying and managing Subversion and 
> the tools developers use with it. Learn more about uberSVN and get a free 
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

[ww-users] Latex batch mode

[Lee W. <wor...@gm...>]

By request, I'm trying a change in WorkingWiki's behaviour, by having it 
try to finish processing latex documents even if they have errors in 
them.  This only applies to creating pdf files, not to creating the HTML 
version of the document that you see in the wiki page (which is already 
error-tolerant).

This means that if your document has errors, you're more likely to get a 
pdf file and less likely to get an error report.  If the pdf file seems 
strange, you may want to look at the log file despite the lack of error 
report.

If you get messages like "make succeeded but did not produce 
my-thing.pdf" (or if anything else seems strange or wrong) please let me 
know and I'll try to improve the situation.

Thanks,
Lee

-------- Original Message --------
Subject: [ workingwiki-Feature Requests-3297260 ] Latex batch mode
Date: Mon, 08 Aug 2011 15:07:14 -0700
From: SourceForge.net <no...@so...>
To: SourceForge.net <no...@so...>

Feature Requests item #3297260, was opened at 2011-05-03 19:28
Message generated for change (Comment added) made by worden
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300

Please note that this message will contain a full copy of the comment 
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Refactored WorkingWiki
>Status: Closed
Priority: 5
Private: No
Submitted By: Jonathan Dushoff (dushoff)
>Assigned to: Lee Worden (worden)
Summary: Latex batch mode

Initial Comment:
David Earn suggests that the wiki should do latex in batch mode by 
default.  This just means that it would try to produce PDF output even 
when encountering an error.  This could help in finding errors, I think, 
but I'm not sure how valuable it would be -- given that we already have 
the .xhtml version.


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

>Comment By: Lee Worden (worden)
Date: 2011-08-08 15:07

Message:
OK, trying it out in r729.  I had to put -interaction=nonstopmode on the
command line to have it keep going to the end of the document, and put a -
sign in front of the command to have make ignore the error code that it
returns.  So we'll want to keep an eye out for 'make succeeded but did not
produce document.pdf'.  If that starts happening, please let me know and
I'll try to come up with a better kind of diagnostic output.

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1527388&aid=3297260&group_id=366300

Re: [ww-users] new features to suppress making; feature request award

[Lee W. <wor...@gm...>]

On 08/05/11 23:09, Jonathan Dushoff wrote:
> On Wed, Aug 3, 2011 at 6:40 PM, Lee Worden<wor...@gm...>  wrote:
>
>> ... I have awarded the WW Feature Request of the
>> Year to J. C. Szamosi for a request titled "Making background jobs
>> happen faster"
>> [https://sourceforge.net/tracker/?func=detail&aid=3303508&group_id=366300&atid=152738].
>
> Lee apparently dropped a digit from the link.  The curious should try
> https://sourceforge.net/tracker/?func=detail&aid=3303508&group_id=366300&atid=1527388

Sorry about that.

Re: [ww-users] new features to suppress making; feature request award

[Jonathan D. <du...@mc...>]

On Wed, Aug 3, 2011 at 6:40 PM, Lee Worden <wor...@gm...> wrote:

> ... I have awarded the WW Feature Request of the
> Year to J. C. Szamosi for a request titled "Making background jobs
> happen faster"
> [https://sourceforge.net/tracker/?func=detail&aid=3303508&group_id=366300&atid=152738].

Lee apparently dropped a digit from the link.  The curious should try
https://sourceforge.net/tracker/?func=detail&aid=3303508&group_id=366300&atid=1527388

JD

[ww-users] new features to suppress making; feature request award

[Lee W. <wor...@gm...>]

In response to a feature request 
[http://sourceforge.net/tracker/index.php?func=detail&aid=3383198&group_id=366300&atid=1527388] 
I have added a couple wikitext keywords that can be inserted into a page 
to cause WorkingWiki to skip making files when it otherwise would.

The keyword __DISABLE_MAKE__ causes it to skip the make operation for 
targets encountered after the keyword in a page's text; __ENABLE_MAKE__ 
cancels out the effect of disabling make.

Make operations can be disabled for an entire page without editing it by 
appending the key-value pair "disable-make=true" to the page's URL.

To enable these features, update to revision 727 from the SVN repository 
(is anyone using a non-SVN copy of the code out there?).

In slightly related news, I have awarded the WW Feature Request of the 
Year to J. C. Szamosi for a request titled "Making background jobs 
happen faster" 
[https://sourceforge.net/tracker/?func=detail&aid=3303508&group_id=366300&atid=152738].

All responses welcome.

lw

Re: [ww-users] oops

[Jonathan D. <du...@mc...>]

Not to deny that this should be addressed, but an easy, robust way
around it is to specify figure extensions (ie.,
\includegraphics{figure.eps}).  I've been doing it this way even since
before WW.

JD

On Fri, Jun 17, 2011 at 12:35 AM, Lee Worden <wor...@gm...> wrote:
> On 06/16/11 21:11, Peter L. Ralph wrote:
>> Ooops, meant to reply to the list earlier.

> I should have too.

>>> seems to me that if latex and latexml accept png and jpg files I should
>>> strive to have makefile rules that don't make you jump through
>>> unnecessary hoops

>>>> I have not committed the change you mention.  Er, I appreciate the work,
>>>> but perhaps you were too hasty?  It seems to me that it is better to
>>>> have changes in figures noticed than the alternative?  Either way we go,
>>>> I forsee some documentation.

>>> I decided it's better to miss some dependencies sometimes than to
>>> completely crash and refuse to make the output sometimes - the latter
>>> condition can hurt people when they're on a paper submission deadline
>>> and the like.  So I made the choice independently of whether it actually
>>> relates to the problem you had...

>> I agree; but I can also imagine the case when, under a deadline, someone
>> has to figure out why their figure isn't updating in their paper.  The
>> unnecessary hoops are better, in that case, because they give an error
>> message, and tell you what to do to fix it, even if it is annoying.

> Of course, it's best if it works right.  But if the paper isn't updating
> you can make it update by using the "sync all source files" action, or
> by just making a trivial edit in the .tex file.  If it refuses to give
> you the output 5 minutes before you leave for the airport it's a real
> problem.

>> But, perhaps Jonathan's (magic) solution will work?

> Yes.  For anyone who's wondering, Jonathan's proposal is on the bug
> tracker:
> https://sourceforge.net/tracker/index.php?func=detail&aid=3317645&group_id=366300&atid=1527385

> lw

>> -p

>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> workingwiki-users mailing list
>> wor...@li...
>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] oops

[Lee W. <wor...@gm...>]

On 06/16/11 21:11, Peter L. Ralph wrote:
> Ooops, meant to reply to the list earlier.

I should have too.

>> seems to me that if latex and latexml accept png and jpg files I should
>> strive to have makefile rules that don't make you jump through
>> unnecessary hoops
>>
>>> I have not committed the change you mention.  Er, I appreciate the work,
>>> but perhaps you were too hasty?  It seems to me that it is better to
>>> have changes in figures noticed than the alternative?  Either way we go,
>>> I forsee some documentation.
>>
>> I decided it's better to miss some dependencies sometimes than to
>> completely crash and refuse to make the output sometimes - the latter
>> condition can hurt people when they're on a paper submission deadline
>> and the like.  So I made the choice independently of whether it actually
>> relates to the problem you had...
>
> I agree; but I can also imagine the case when, under a deadline, someone
> has to figure out why their figure isn't updating in their paper.  The
> unnecessary hoops are better, in that case, because they give an error
> message, and tell you what to do to fix it, even if it is annoying.

Of course, it's best if it works right.  But if the paper isn't updating 
you can make it update by using the "sync all source files" action, or 
by just making a trivial edit in the .tex file.  If it refuses to give 
you the output 5 minutes before you leave for the airport it's a real 
problem.

> But, perhaps Jonathan's (magic) solution will work?

Yes.  For anyone who's wondering, Jonathan's proposal is on the bug 
tracker:
https://sourceforge.net/tracker/index.php?func=detail&aid=3317645&group_id=366300&atid=1527385

lw

> -p
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] oops

[Peter L. R. <pl...@st...>]

Ooops, meant to reply to the list earlier.

> seems to me that if latex and latexml accept png and jpg files I should  
> strive to have makefile rules that don't make you jump through  
> unnecessary hoops
>
>> I have not committed the change you mention.  Er, I appreciate the work,
>> but perhaps you were too hasty?  It seems to me that it is better to
>> have changes in figures noticed than the alternative?  Either way we go,
>> I forsee some documentation.
>
> I decided it's better to miss some dependencies sometimes than to  
> completely crash and refuse to make the output sometimes - the latter  
> condition can hurt people when they're on a paper submission deadline  
> and the like.  So I made the choice independently of whether it actually  
> relates to the problem you had...

I agree; but I can also imagine the case when, under a deadline, someone
has to figure out why their figure isn't updating in their paper.  The
unnecessary hoops are better, in that case, because they give an error
message, and tell you what to do to fix it, even if it is annoying.

But, perhaps Jonathan's (magic) solution will work?  

-p

Re: [ww-users] oops

[Lee W. <wor...@gm...>]

I've looked in (my copy of) the WW makefiles.  It does seem to be 
somewhat wrong, but I'm not sure about this followup issue.  I don't 
think this line should have any effect on how latexml runs.

WorkingWiki's makefiles handle dependencies in .tex files by making an 
auxiliary makefile "document.d" for each file "document.tex".  There are 
three relevant lines there.  If document.tex contains 
\includegraphics{figure} document.d will contain:

document.pdf document.latex.pdf : figure.eps

because if we run latex it will look for figure.eps [document.pdf is 
made using latex, the same as document.latex.pdf].  Next

document.pdflatex.pdf document.xelatex.pdf : figure.pdf

because pdflatex and xelatex will look for figure.pdf.

Then for latexml:

document.latexml.xhtml document.latexml.html : figure.pdf

This seems to be the problem.  As you say, latex is the default, so why 
not put figure.eps here?  As far as I can see from the latexml source, 
it will accept eps, png, pdf, and various other file types here - I 
don't know in what order of precedence.

I seem to have three options:

make document.latexml.* depend on figure.pdf, as we have now
   This works when the document is written for pdflatex, and fails when 
it's written for latex.  "Fails" means it refuses to run latexml because 
it can't make figure.pdf, even though figure.eps is provided and would 
work fine.

make it depend on figure.eps instead
   This works on documents written for latex and fails if the document 
is written for pdflatex.

make it not depend on either
   In this case, it won't refuse to run latexml outright when the guess 
is wrong about which file to look for.  Unfortunately, there will be 
times when the figure is updated - or when the figure wasn't there but 
now you've uploaded it - and it won't rerun latexml.

I'll change to not depending on either, but if anyone has a better idea 
I'm interested.  Thank you for the report.  If I've misunderstood and 
you are actually reporting a failure to make a .pdf file, not a .xhtml 
file, let me know.

Lee

On 06/15/11 09:12, Peter L. Ralph wrote:
> OK, it is due to my not understanding something.  Deleting a line in
> the makefile made the problem dissappear.  Now my question is why having
>
> debug-nup.pdf: debug-page.latex.pdf
> 	pdfnup  --nup 2x1 --outfile $@ $^
>
> in the makefile should cause it to use pdflatex rather than latex?
>
> I'm still having the same problem in an actual project, and can't find
> anything that might be telling it to use pdflatex.  In fact the string
> "pdf" doesn't appear in the page with the latex on it, or any of the
> makefiles associated with the project.
>
> ???, peter.
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

[ww-users] implicit figuretype

[Peter L. R. <pl...@st...>]

Hi, folks -- not sure if this is a bug, or me not knowing how something
works.

On our wiki, if a latex file includes a figure either with no file
extension, e.g.
 \includgraphics{figure}
or with a file extension that doesn't exist, like
 \includgraphics{figure.png}
then WW looks for the figure as a pdf.  So if figure.pdf exists, then
all is good; if we only have figure.eps then fails to compile.

(BTW, it would be nice if rather than failing to compile, it substituted
in an error message or something?)

This is strange, since looking at the page, and at the site makefiles,
it looks like the default figuretype is eps, and the default latex is
latex, not pdflatex, and I haven't changed it anywhere -- not in a
project makefile, a site makefile, in the source-file tag.

For an example, see
 http://ibis.ucdavis.edu/mw/index.php?title=DebugPage
 
Please advise?

--p

[ww-users] oops

[Peter L. R. <pl...@st...>]

OK, it is due to my not understanding something.  Deleting a line in
the makefile made the problem dissappear.  Now my question is why having 

debug-nup.pdf: debug-page.latex.pdf
	pdfnup  --nup 2x1 --outfile $@ $^

in the makefile should cause it to use pdflatex rather than latex?

I'm still having the same problem in an actual project, and can't find
anything that might be telling it to use pdflatex.  In fact the string
"pdf" doesn't appear in the page with the latex on it, or any of the
makefiles associated with the project.

???, peter.

Re: [ww-users] R off-wiki

[Jonathan D. <du...@mc...>]

I'm not sure how this relates to your vision, but I do the part
described at the beginning all the time.  I download a .RData file
from the wiki and play with it until I have an idea what I want to
code on the wiki.  It's fairly straightforward.  Just save an .RData
file to my local disk and say 'R --vanilla' and then
'load("wiki.RData")'.  It's simple enough that I don't feel very
tempted to worry about the rest of it in the short term.  In the long
term, we might aim for a broader approach to treating WW files as
files

I'll mention too that R can already read both .R and .RData files
directly from publicly readable wikis, so the only possibly
non-trivial obstacle to the vision below is passwords.

Another trick that I guess is worth sharing is that I rarely click on
a .make.log file when debugging.  At the first sign of trouble, I put
temporary tags for "target.Rout" and "target.Rout.make.log" (and often
"target.dmp") right at the top of the page.  It makes a surprisingly
large difference in the "feel" of the interaction.

JD

On Mon, May 23, 2011 at 11:53 AM, Lee Worden <wor...@gm...> wrote:
> Imagine you are working on R programs in a project in a wiki.  You start up
> R on your own workstation, load in the data and functions from the files on
> the wiki, and try out R commands until you're satisfied, then go back to the
> wiki and update it.  Much easier than editing, saving to the web browser,
> previewing, reloading the .make.log file, right?  Also easier than exporting
> the whole project, unpacking the tar file, and loading from there.  It may
> be doable without any changes to WorkingWiki.

> I think it would just require writing an R library that can load data files,
> .RData files, and maybe .R files from wiki locations into your R session.
> It might have functions like attachToWWProject(wikiname, projectname),
> loadFromWW(rdatafilename).

> If anyone feels like writing something like that, I'd be happy to consult
> with them.  I don't have experience writing R libraries, and I won't have
> time to do something like this anytime soon.

[ww-users] R off-wiki

[Lee W. <wor...@gm...>]

Imagine you are working on R programs in a project in a wiki.  You start up
R on your own workstation, load in the data and functions from the files on
the wiki, and try out R commands until you're satisfied, then go back to the
wiki and update it.  Much easier than editing, saving to the web browser,
previewing, reloading the .make.log file, right?  Also easier than exporting
the whole project, unpacking the tar file, and loading from there.  It may
be doable without any changes to WorkingWiki.

I think it would just require writing an R library that can load data files,
.RData files, and maybe .R files from wiki locations into your R session.
It might have functions like attachToWWProject(wikiname, projectname),
loadFromWW(rdatafilename).

If anyone feels like writing something like that, I'd be happy to consult
with them.  I don't have experience writing R libraries, and I won't have
time to do something like this anytime soon.
LW

Re: [ww-users] WorkingWiki changes in MediaWiki 1.18alpha

[Lee W. <wor...@gm...>]

Yes, it does.  It probably runs faster.  You might have users who are 
used to it or pages that are written using it.  But otherwise, when 
you're using WW anyway it seems more parsimonious just to use the $$.
l

On 04/27/11 13:40, Peter L. Ralph wrote:
> So, is there any reason to install the math extension as well?  It seems
> to provide the same functionality as the $$\blah$$ syntax?
>
> -p
>
> On Wed, Apr 27, 2011 at 01:32:16PM -0500, Lee Worden wrote:
>> To WorkingWiki admins, in case anyone besides Peter wants to run on the
>> "trunk" version of MediaWiki - the latest source code that's actively
>> changing day by day: you should know that a small change is needed to
>> keep WorkingWiki running.
>>
>> Up till now we've been passively using the "Use MathML if available"
>> preferences setting provided by MediaWiki's optional LaTeX math feature.
>>    In the new MediaWiki code, that feature is spun off into an optional
>> extension.  So you need to either install the Math extension or use
>> WorkingWiki's new homespun "Use MathML when the browser supports it"
>> feature.
>>
>> The new setting won't automatically inherit the old value, so either you
>> or the users will have to reset their MathML preferences.
>>
>> See
>> http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Downloading_and_Installing_WorkingWiki#Changes_in_MediaWiki_1.18
>> for more information.
>>
>> Thanks!
>> Lee
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> workingwiki-users mailing list
>> wor...@li...
>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] WorkingWiki changes in MediaWiki 1.18alpha

[Peter L. R. <pl...@st...>]

So, is there any reason to install the math extension as well?  It seems
to provide the same functionality as the $$\blah$$ syntax?

-p

On Wed, Apr 27, 2011 at 01:32:16PM -0500, Lee Worden wrote:
> To WorkingWiki admins, in case anyone besides Peter wants to run on the 
> "trunk" version of MediaWiki - the latest source code that's actively 
> changing day by day: you should know that a small change is needed to 
> keep WorkingWiki running.
> 
> Up till now we've been passively using the "Use MathML if available" 
> preferences setting provided by MediaWiki's optional LaTeX math feature. 
>   In the new MediaWiki code, that feature is spun off into an optional 
> extension.  So you need to either install the Math extension or use 
> WorkingWiki's new homespun "Use MathML when the browser supports it" 
> feature.
> 
> The new setting won't automatically inherit the old value, so either you 
> or the users will have to reset their MathML preferences.
> 
> See
> http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Downloading_and_Installing_WorkingWiki#Changes_in_MediaWiki_1.18
> for more information.
> 
> Thanks!
> Lee
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

[ww-users] WorkingWiki changes in MediaWiki 1.18alpha

[Lee W. <wor...@gm...>]

To WorkingWiki admins, in case anyone besides Peter wants to run on the 
"trunk" version of MediaWiki - the latest source code that's actively 
changing day by day: you should know that a small change is needed to 
keep WorkingWiki running.

Up till now we've been passively using the "Use MathML if available" 
preferences setting provided by MediaWiki's optional LaTeX math feature. 
  In the new MediaWiki code, that feature is spun off into an optional 
extension.  So you need to either install the Math extension or use 
WorkingWiki's new homespun "Use MathML when the browser supports it" 
feature.

The new setting won't automatically inherit the old value, so either you 
or the users will have to reset their MathML preferences.

See
http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Downloading_and_Installing_WorkingWiki#Changes_in_MediaWiki_1.18
for more information.

Thanks!
Lee

[ww-users] svn repository change

[Lee W. <wor...@gm...>]

This email is only for people responsible for running WorkingWiki sites 
outside of McMaster.

I've relocated the WorkingWiki subversion repository from 
lalashan.mcmaster.ca to sourceforge.net, as part of my preparations for 
releasing the source code to the public as free software.

In order to keep up with updates to the source code, you'll need to 
change your working copy to point to the new location.  There's no rush, 
because the old repository is still there, but you won't get revisions 
after number 680 until you switch over.

I just made the change on the McMaster wikis, and it was very simple:

$ cd /usr/src
$ cp -r WorkingWiki WorkingWiki-sf
$ cd WorkingWiki-sf
$ svn switch --relocate svn://lalashan.mcmaster.ca/WorkingWiki 
https://workingwiki.svn.sourceforge.net/svnroot/workingwiki .
$ svn update
$ cd ..
$ mv WorkingWiki WorkingWiki-local && mv WorkingWiki-sf WorkingWiki

Be sure to back up the code directory beforehand, and after making the 
switch, double check that you have a compiled ProjectEngine/pe-make 
executable, and if you have anything in ProjectEngine/resources/site, 
make sure it's in place.

(For reference: 
http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Installing)

Enjoy!
Lee

[ww-users] svn repository change

[Lee W. <wor...@gm...>]

This email is only for people responsible for running WorkingWiki sites 
outside of McMaster.

I've relocated the WorkingWiki subversion repository from 
lalashan.mcmaster.ca to sourceforge.net, as part of my preparations for 
releasing the source code to the public as free software.

In order to keep up with updates to the source code, you'll need to 
change your working copy to point to the new location.  There's no rush, 
because the old repository is still there, but you won't get revisions 
after number 680 until you switch over.

I just made the change on the McMaster wikis, and it was very simple:

$ cd /usr/src
$ cp -r WorkingWiki WorkingWiki-sf
$ cd WorkingWiki-sf
$ svn switch --relocate svn://lalashan.mcmaster.ca/WorkingWiki 
https://workingwiki.svn.sourceforge.net/svnroot/workingwiki .
$ svn update
$ cd ..
$ mv WorkingWiki WorkingWiki-local && mv WorkingWiki-sf WorkingWiki

Be sure to back up the code directory beforehand, and after making the 
switch, double check that you have a compiled ProjectEngine/pe-make 
executable, and if you have anything in ProjectEngine/resources/site, 
make sure it's in place.

(For reference: 
http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Installing)

Enjoy!
Lee

[ww-users] Fwd: [LaTeXML] Workshop on Mathematical Wikis at ITP 2011 (Nijmegen, NL, August 27; abstract submission May 30)

[Lee W. <wor...@gm...>]

fyi - lee

-------- Original Message --------
Subject: [LaTeXML] Workshop on Mathematical Wikis at ITP 2011 (Nijmegen, 
NL, August 27; abstract submission May 30)
Date: Fri, 08 Apr 2011 20:16:19 +0200
From: Christoph LANGE <ch....@ja...>
Reply-To: LaTeXML project <pro...@li...>
Organization: Jacobs University Bremen
To: pro...@ja..., 
pro...@ja..., 
pro...@ja..., pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 
pro...@ja..., 	SWiM 
<pro...@ja...>,	pro...@ja...

Workshop on Mathematical Wikis (MathWikis-2011)
at ITP (2nd International Conference on Interactive Theorem Proving) 2011
Nijmegen, Netherlands, August 27th, 2011
INVITED SPEAKER: Joe Corneli: The PlanetMath Encyclopedia

ABSTRACT SUBMISSION DEADLINE May 30th

Mathematics is increasingly becoming a collaborative discipline. The
Internet has simplified the distributed development, review, and
improvement of large proofs, theories, libraries, and knowledge
repositories, also giving rise to all kinds of collaboratively developed
mathematical learning resources. Examples include the PlanetMath free
encyclopedia, the Polymath collaborative collaborative proof development
efforts, and also large collaboratively developed formal libraries.
Interactive computer assistance, semantic representation, and linking
with other datasets on the Semantic Web are becoming very interesting
aspects of collaborative mathematical developments. The ITP 2011
MathWikis workshop aims to bring together developers and major users of
mathematical wikis and collaborative and social tools for mathematics.

TOPICS include but are not limited to:

    * wikis and blogs for informal, semantic, semiformal, and formal
mathematical knowledge;
    * general techniques and tools for online collaborative mathematics;
    * tools for collaboratively producing, presenting, publishing, and
interacting with online mathematics;
    * automation and computer-human interaction aspects of mathematical
wikis;
    * practical experiences, usability aspects, feasibility studies;
    * evaluation of existing tools and experiments;
    * requirements, user scenarios and goals.

SUBMISSIONS

Researchers interested in participating are invited to submit a short
(2-10 pages) abstract via EasyChair. Submissions will be refereed by the
program committee, which will select a balanced program of high-quality
contributions.

Submissions should be in standard-conforming Postscript or PDF.

To submit a paper, go to the EasyChair MathWikis page
(http://www.easychair.org/conferences/?conf=mathwikis11) and follow the
instructions there.

FINAL VERSIONS

Final versions should be prepared in LaTeX using the easychair.cls class
file (http://www.easychair.org/easychair.zip). Proceedings will be
published as EasyChair or CEUR Workshop Proceedings.


IMPORTANT DATES

    * Submission of abstracts: May 30th, 2011, 8:00 UTC+1
    * Notification: June 23rd, 2011
    * Camera ready versions due: July 11th, 2011
    * Workshop: August 27th, 2011

PROGRAM COMMITTEE

    * Jesse Alama
    * David Aspinall
    * Joe Corneli
    * Cezary Kaliszyk
    * Fairouz Kamareddine
    * Michael Kohlhase
    * Markus Krötzsch
    * Christoph Lange (co-chair)
    * Lionel Mamane
    * James McKinna
    * Piotr Rudnicki
    * Carst Tankink
    * Josef Urban (co-chair)
    * Denny Vrandečić

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype
duke4701
Semantic Publication workshop at ESWC 2011, May 30, Hersonissos, Crete,
Greece
Submission deadline March 15, http://SePublica.mywikipaper.org
LNCS Post-proceedings of selected submissions, Best Paper Award by Elsevier

Re: [ww-users] cleaning out old directories

[Peter L. R. <pl...@st...>]

> >> A way to change things to source files might be useful - or something
> >> like Jonathan has suggested (if I remember right), where project files
> >> that are being archived in the wiki get written back out to the working
> >> directory, so they're preserved even if the whole directory gets
> >> removed.  But those kind of ideas are confusing and troubling to me and
> >> I don't know what to do with them.
> >
> > Here's something I've always wanted to try.  You could have a valuable
> > target be an archived project file living in the Media: space.  Then
> > another project could use that same Media: page as a source file.
> > Seems like it should work well.  I was thinking it should be done
> > across projects, but it seems like it would work to allow you to
> > control the flow within a project as well.
> >
> > JD
> 
> Oh, man.  You could do that.  I should make sure that when it archives 
> to that page it flags it properly, because any time a source file is 
> changed, pages need to be expired from the parser cache so things will 
> be remade.  I think it would work actually.  (Though it wouldn't matter 
> if it's in the same project, because it's coming from the working 
> directory and syncing it back to the directory would be a null operation 
> and wouldn't necessitate any further makes, so actually it doesn't need 
> to be flagged in that case.  But it does if it's a source file in a 
> different project.)  If you do try it I'd like to watch! :)

Yes, this is just what I was thinking; perhaps we can assume that if any
file is costly enough it should not be erased that it will be stored as
an archived project file?

--peter

Re: [ww-users] cleaning out old directories

[Lee W. <wor...@gm...>]

On 04/04/11 20:56, Jonathan Dushoff wrote:
> On Fri, Apr 1, 2011 at 7:04 PM, Lee Worden<wor...@gm...>  wrote:
>> Hi Peter!
>
>> So the recommended treatment for big costly files is to isolate their
>> make rules to be run only in background jobs:
>> http://lalashan.mcmaster.ca/theobio/projects/index.php/Background_Jobs#Background_jobs_design_pattern
>
>> If you do that, they won't be remade unless you do it explicitly by
>> creating a background job.
>
> Another recommended move is to save them on the wiki as archived project files.
>
>> Or you can just make sure to use<project-file ... make=false/>  and
>> write your make rules so that nothing that makes automatically has a
>> dependency on any of your costly targets.
>
> This is tricky, because you typically want to make things from your
> costly targets, and you would like your make rules to reflect that
> accurately.

True.

>> If we did have a "do not remake" flag I'd hesitate to assume that
>> anything not tagged could be erased, because it's common to put off
>> housekeeping tasks like making sure all the files are tagged when you
>> add new ones.
>
>> A way to change things to source files might be useful - or something
>> like Jonathan has suggested (if I remember right), where project files
>> that are being archived in the wiki get written back out to the working
>> directory, so they're preserved even if the whole directory gets
>> removed.  But those kind of ideas are confusing and troubling to me and
>> I don't know what to do with them.
>
> Here's something I've always wanted to try.  You could have a valuable
> target be an archived project file living in the Media: space.  Then
> another project could use that same Media: page as a source file.
> Seems like it should work well.  I was thinking it should be done
> across projects, but it seems like it would work to allow you to
> control the flow within a project as well.
>
> JD

Oh, man.  You could do that.  I should make sure that when it archives 
to that page it flags it properly, because any time a source file is 
changed, pages need to be expired from the parser cache so things will 
be remade.  I think it would work actually.  (Though it wouldn't matter 
if it's in the same project, because it's coming from the working 
directory and syncing it back to the directory would be a null operation 
and wouldn't necessitate any further makes, so actually it doesn't need 
to be flagged in that case.  But it does if it's a source file in a 
different project.)  If you do try it I'd like to watch! :)