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

Re: [ww-users] cleaning out old directories

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

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.

> 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

Re: [ww-users] cleaning out old directories

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

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.

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.

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.

Thanks-
lw

On 03/29/11 10:24, Peter L. Ralph wrote:
> I always feel nervous when there are large, costly files that WW might
> still decide to go ahead and re-make without my intending to.  Perhaps
> what we need is some easy mechanism to change the status of such files
> -- change them to 'source files' for instance.  This would be similar to
> a "DNE" flag, but would also flag "do not re-make"; so re-making would
> require first manual deletion.  Then any files not flagged as such could
> be deleted without problem.
>
> --peter
>
> On Mon, Mar 28, 2011 at 08:24:01PM -0700, Lee Worden wrote:
>> I have some open questions about WorkingWiki's features, where I would
>> appreciate your perspective as people who use WW, or even run your own
>> WW sites.  Please feel free to ignore this if you're busy or not interested.
>>
>> For quite a while, we've had a need to clean out old data that piles up
>> and isn't in use - not in the wiki pages themselves, but in the working
>> directories that we use behind the scenes to compute the output of
>> latex, R, etc.
>>
>> Most obvious is the preview sessions - any time you preview a page that
>> includes WW data while editing, it makes a copy of the data in the back
>> end to keep it separate from the unedited page's data.  When you save,
>> it gets rid of the copied files by merging with the saved ones, but if
>> you abandon the changes without saving (a completely reasonable thing to
>> do) the copy is left sitting there, and needs to be cleaned out sometime
>> later.  These can be quite large - we've seen project directories that
>> take up 4GB or even more.  That cleanout has been on my to do list, and
>> now it's getting done.
>>
>> More controversially, there are also old projects that eventually need
>> to disappear.  For instance, if someone creates a project and then
>> change its name, the old working directory just sits there abandoned.
>> Or if a page once had some WW files on it and now it doesn't, the
>> project directory is abandoned.  But also if I use the inline latex
>> features to add something like $$\alpha + \beta$$ to a page, then change
>> it to something else, a project is created to process that latex code,
>> and it needs to not be kept forever.  So at some point project
>> directories need to be cleared away or the disk will eventually fill up
>> with files that no one wants.  I'll probably do this by erasing things
>> that haven't been touched in over 3 months or something.
>>
>> Generally, this should be harmless even if I erase files that someone is
>> using, because they can be remade from the source files - it will just
>> mean waiting a minute or two (maybe more...) for them to be made.
>> Unfortunately,  in the worst case it could mean erasing a directory full
>> of output files that can't be easily recreated.  I could implement a "Do
>> Not Erase" feature to mark particular projects that are sensitive and
>> should never be erased.
>>
>> My first question: Is there a better way to protect project files that
>> should be permanent?  Does anyone have strong feelings about all this?
>>
>> Finally, I think background jobs should generally be left alone for as
>> long as it takes for people to decide whether to erase them.  But there
>> is a slight danger: suppose I create a project and run a background job,
>> then erase or rename the project.  The background job becomes orphaned,
>> and it won't show up in any listings.  So I should probably do something
>> to erase things like that.
>>
>> One way to address both of these things is to check whether each project
>> is actually connected to current pages in one of the wikis - that would
>> clear up whether it's orphaned or not.  But the directory cleaning is
>> done in a separate back-end component ("ProjectEngine") when requested
>> by the front end ("WorkingWiki"), and I'm trying to avoid two-way
>> communication where ProjectEngine has to ask questions of WorkingWiki
>> while it's completing a request, so I'm looking for an alternative...
>>
>> Lee
>>
>> ------------------------------------------------------------------------------
>> Enable your software for Intel(R) Active Management Technology to meet the
>> growing manageability and security demands of your customers. Businesses
>> are taking advantage of Intel(R) vPro (TM) technology - will your software
>> be a part of the solution? Download the Intel(R) Manageability Checker
>> today! http://p.sf.net/sfu/intel-dev2devmar
>> _______________________________________________
>> workingwiki-users mailing list
>> wor...@li...
>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] cleaning out old directories

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

I always feel nervous when there are large, costly files that WW might
still decide to go ahead and re-make without my intending to.  Perhaps
what we need is some easy mechanism to change the status of such files
-- change them to 'source files' for instance.  This would be similar to
a "DNE" flag, but would also flag "do not re-make"; so re-making would
require first manual deletion.  Then any files not flagged as such could
be deleted without problem.

--peter

On Mon, Mar 28, 2011 at 08:24:01PM -0700, Lee Worden wrote:
> I have some open questions about WorkingWiki's features, where I would 
> appreciate your perspective as people who use WW, or even run your own 
> WW sites.  Please feel free to ignore this if you're busy or not interested.
> 
> For quite a while, we've had a need to clean out old data that piles up 
> and isn't in use - not in the wiki pages themselves, but in the working 
> directories that we use behind the scenes to compute the output of 
> latex, R, etc.
> 
> Most obvious is the preview sessions - any time you preview a page that 
> includes WW data while editing, it makes a copy of the data in the back 
> end to keep it separate from the unedited page's data.  When you save, 
> it gets rid of the copied files by merging with the saved ones, but if 
> you abandon the changes without saving (a completely reasonable thing to 
> do) the copy is left sitting there, and needs to be cleaned out sometime 
> later.  These can be quite large - we've seen project directories that 
> take up 4GB or even more.  That cleanout has been on my to do list, and 
> now it's getting done.
> 
> More controversially, there are also old projects that eventually need 
> to disappear.  For instance, if someone creates a project and then 
> change its name, the old working directory just sits there abandoned. 
> Or if a page once had some WW files on it and now it doesn't, the 
> project directory is abandoned.  But also if I use the inline latex 
> features to add something like $$\alpha + \beta$$ to a page, then change 
> it to something else, a project is created to process that latex code, 
> and it needs to not be kept forever.  So at some point project 
> directories need to be cleared away or the disk will eventually fill up 
> with files that no one wants.  I'll probably do this by erasing things 
> that haven't been touched in over 3 months or something.
> 
> Generally, this should be harmless even if I erase files that someone is 
> using, because they can be remade from the source files - it will just 
> mean waiting a minute or two (maybe more...) for them to be made. 
> Unfortunately,  in the worst case it could mean erasing a directory full 
> of output files that can't be easily recreated.  I could implement a "Do 
> Not Erase" feature to mark particular projects that are sensitive and 
> should never be erased.
> 
> My first question: Is there a better way to protect project files that 
> should be permanent?  Does anyone have strong feelings about all this?
> 
> Finally, I think background jobs should generally be left alone for as 
> long as it takes for people to decide whether to erase them.  But there 
> is a slight danger: suppose I create a project and run a background job, 
> then erase or rename the project.  The background job becomes orphaned, 
> and it won't show up in any listings.  So I should probably do something 
> to erase things like that.
> 
> One way to address both of these things is to check whether each project 
> is actually connected to current pages in one of the wikis - that would 
> clear up whether it's orphaned or not.  But the directory cleaning is 
> done in a separate back-end component ("ProjectEngine") when requested 
> by the front end ("WorkingWiki"), and I'm trying to avoid two-way 
> communication where ProjectEngine has to ask questions of WorkingWiki 
> while it's completing a request, so I'm looking for an alternative...
> 
> Lee
> 
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

Re: [ww-users] cleaning out old directories

[Tallulah A. <tal...@gm...>]

Perhaps having button to delete old/moved projects that would mark them for
clean out. This could potentially be combined into a delete wiki page
function particularly for when pages are moved or renamed that would erase
the page and clear out all background jobs and projects associated with the
page.

I think a Do-Not-Erase is sufficient for preserving slow projects.

Tallulah

On Mon, Mar 28, 2011 at 11:24 PM, Lee Worden <wor...@gm...> wrote:

> I have some open questions about WorkingWiki's features, where I would
> appreciate your perspective as people who use WW, or even run your own
> WW sites.  Please feel free to ignore this if you're busy or not
> interested.
>
> For quite a while, we've had a need to clean out old data that piles up
> and isn't in use - not in the wiki pages themselves, but in the working
> directories that we use behind the scenes to compute the output of
> latex, R, etc.
>
> Most obvious is the preview sessions - any time you preview a page that
> includes WW data while editing, it makes a copy of the data in the back
> end to keep it separate from the unedited page's data.  When you save,
> it gets rid of the copied files by merging with the saved ones, but if
> you abandon the changes without saving (a completely reasonable thing to
> do) the copy is left sitting there, and needs to be cleaned out sometime
> later.  These can be quite large - we've seen project directories that
> take up 4GB or even more.  That cleanout has been on my to do list, and
> now it's getting done.
>
> More controversially, there are also old projects that eventually need
> to disappear.  For instance, if someone creates a project and then
> change its name, the old working directory just sits there abandoned.
> Or if a page once had some WW files on it and now it doesn't, the
> project directory is abandoned.  But also if I use the inline latex
> features to add something like $$\alpha + \beta$$ to a page, then change
> it to something else, a project is created to process that latex code,
> and it needs to not be kept forever.  So at some point project
> directories need to be cleared away or the disk will eventually fill up
> with files that no one wants.  I'll probably do this by erasing things
> that haven't been touched in over 3 months or something.
>
> Generally, this should be harmless even if I erase files that someone is
> using, because they can be remade from the source files - it will just
> mean waiting a minute or two (maybe more...) for them to be made.
> Unfortunately,  in the worst case it could mean erasing a directory full
> of output files that can't be easily recreated.  I could implement a "Do
> Not Erase" feature to mark particular projects that are sensitive and
> should never be erased.
>
> My first question: Is there a better way to protect project files that
> should be permanent?  Does anyone have strong feelings about all this?
>
> Finally, I think background jobs should generally be left alone for as
> long as it takes for people to decide whether to erase them.  But there
> is a slight danger: suppose I create a project and run a background job,
> then erase or rename the project.  The background job becomes orphaned,
> and it won't show up in any listings.  So I should probably do something
> to erase things like that.
>
> One way to address both of these things is to check whether each project
> is actually connected to current pages in one of the wikis - that would
> clear up whether it's orphaned or not.  But the directory cleaning is
> done in a separate back-end component ("ProjectEngine") when requested
> by the front end ("WorkingWiki"), and I'm trying to avoid two-way
> communication where ProjectEngine has to ask questions of WorkingWiki
> while it's completing a request, so I'm looking for an alternative...
>
> Lee
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users
>

[ww-users] cleaning out old directories

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

I have some open questions about WorkingWiki's features, where I would 
appreciate your perspective as people who use WW, or even run your own 
WW sites.  Please feel free to ignore this if you're busy or not interested.

For quite a while, we've had a need to clean out old data that piles up 
and isn't in use - not in the wiki pages themselves, but in the working 
directories that we use behind the scenes to compute the output of 
latex, R, etc.

Most obvious is the preview sessions - any time you preview a page that 
includes WW data while editing, it makes a copy of the data in the back 
end to keep it separate from the unedited page's data.  When you save, 
it gets rid of the copied files by merging with the saved ones, but if 
you abandon the changes without saving (a completely reasonable thing to 
do) the copy is left sitting there, and needs to be cleaned out sometime 
later.  These can be quite large - we've seen project directories that 
take up 4GB or even more.  That cleanout has been on my to do list, and 
now it's getting done.

More controversially, there are also old projects that eventually need 
to disappear.  For instance, if someone creates a project and then 
change its name, the old working directory just sits there abandoned. 
Or if a page once had some WW files on it and now it doesn't, the 
project directory is abandoned.  But also if I use the inline latex 
features to add something like $$\alpha + \beta$$ to a page, then change 
it to something else, a project is created to process that latex code, 
and it needs to not be kept forever.  So at some point project 
directories need to be cleared away or the disk will eventually fill up 
with files that no one wants.  I'll probably do this by erasing things 
that haven't been touched in over 3 months or something.

Generally, this should be harmless even if I erase files that someone is 
using, because they can be remade from the source files - it will just 
mean waiting a minute or two (maybe more...) for them to be made. 
Unfortunately,  in the worst case it could mean erasing a directory full 
of output files that can't be easily recreated.  I could implement a "Do 
Not Erase" feature to mark particular projects that are sensitive and 
should never be erased.

My first question: Is there a better way to protect project files that 
should be permanent?  Does anyone have strong feelings about all this?

Finally, I think background jobs should generally be left alone for as 
long as it takes for people to decide whether to erase them.  But there 
is a slight danger: suppose I create a project and run a background job, 
then erase or rename the project.  The background job becomes orphaned, 
and it won't show up in any listings.  So I should probably do something 
to erase things like that.

One way to address both of these things is to check whether each project 
is actually connected to current pages in one of the wikis - that would 
clear up whether it's orphaned or not.  But the directory cleaning is 
done in a separate back-end component ("ProjectEngine") when requested 
by the front end ("WorkingWiki"), and I'm trying to avoid two-way 
communication where ProjectEngine has to ask questions of WorkingWiki 
while it's completing a request, so I'm looking for an alternative...

Lee

[ww-users] more types when downloading files

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

I just found a bug in WorkingWiki that stopped it from properly 
specifying the types of files when you download them.  Now that it's 
fixed, your browser may suddenly need to know what application to use 
for various types of files (I just noticed I had to tell it how to open 
a .Rout file).  I apologize for any inconvenience.  Hopefully this 
actually means you have more flexibility over how to open the files.  As 
always, please talk to me if anything seems broken or puzzling.
Lee

[ww-users] WW slogan

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

Thanks David Goehring for this excellent slogan:

> "WorkingWiki: If you can make it anywhere, you can make it here."

I love it!  I've added it to the top of 
http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Documentation.

LW

[ww-users] improved support for section editing

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

Lindsay called my attention to the problem with section editing in 
WorkingWiki last week - when you edit a section of a wiki page, you get 
a bunch of cryptic error messages from WorkingWiki.  This bug has been 
swimming around in the lake of known issues for a long time, but hadn't 
really poked its head out at me in a while, so I was interested in being 
reminded of it.  Then in conversation with Jonathan I realized that it 
might actually be really easy to fix.  Sure enough, now I've fixed it up.

If you've been avoiding using the "[edit]" links attached to section 
headings, you can go back to using them now.

If you're curious about the details, see the bug tracker entry:

https://sourceforge.net/tracker/?func=detail&atid=1527385&aid=3103393&group_id=366300

Thanks!
Lee

[ww-users] when previews go bad

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

I've alluded to this in earlier email notices, conversations and such, 
but I think I should make it explicit: when your WorkingWiki project has 
a lot of big files in it, you will have trouble with previewing.

This is because when you preview a page that includes source-file and 
project-file tags, WorkingWiki's back end makes a copy of the working 
directory so that your preview operations don't mix with the operations 
on the saved version of the files.  When it's a big directory, it will 
take a long time to copy when you first start to preview a page.  (In 
earlier versions it didn't do this copying, it just did everything in 
the original directory.  That isn't sustainable because it can cause a 
huge amount of redundant recomputations when multiple people are using 
the wiki and garbled outputs when people preview changes but don't save 
them.)

Sometime in the future, we may solve this problem by using a 
copy-on-write filesystem (http://en.wikipedia.org/wiki/Btrfs, for 
example), which will make the initial copy operation virtually 
instantaneous.

In the present, here is what you can do to avoid slow previews.

Create a separate project for the things you want to preview.  Say your 
big files are in project P.  Create a new project Q where you will do 
your development.  Put the code you are working on, say file S, in 
project Q instead of project P.  Locate it on a page where no files from 
project P are displayed.  It will still require files in P, though: 
instead of just using file "T" in makefile rules you have to say 
"$(PROJECT_DIR_P)/T".  In perl, R, and other languages there are similar 
syntaxes for getting the value of environment variable PROJECT_DIR_P.

To make that environment variable appear, go to the Manage Project page 
for project Q and add project P to its list of prerequisites.  Then 
check the "do not copy" box since that's the whole point of this 
exercise, and take note of (and possibly change) the variable name there.

Then when you preview your work it will be quick, because it won't have 
to copy the big files in P.

I'm happy to answer questions and register complaints.

For relevant info see:

http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Documentation#Dependencies_between_projects

Lee W

[ww-users] upgrades at lalashan

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

I've upgraded all the remaining wikis at lalashan.mcmaster.ca to the current WorkingWiki software (the 1.0 beta).  If anyone encounters glitches or confusion, please let me know so I can keep abreast of what's going on.

For non-lalashan people: is there anyone still running older WW code?  If not, I'll remove those parts of the documentation.

Lee

Re: [ww-users] Using latex locally?

[lee w. <wor...@gm...>]

I've created a new documentation page for WorkingWiki administrators, and 
written a section on creating site makefiles:
http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Administration

While I was doing that I noticed that if your latexml executable is in a 
nonstandard location, the same applies to latexmlpost and latexmlmath (WW 
needs all three).  So you would actually need

  export LATEXML=/path/to/latexml
  export LATEXMLPOST=/path/to/latexmlpost
  export LATEXMLMATH=/path/to/latexmlmath

They should all be in the same place.

Likewise, you might also need to provide definitions for BIBTEX, DVIPDF or 
the like, depending on your needs and installation.

Lee

On Tue, 21 Dec 2010, lee worden wrote:
> 
> In order to use WorkingWiki as is, you need both latex (TeXlive should be 
> fine) and latexml.  If you have a need for WorkingWiki without latexml, I can 
> work with you - in that case, you would not be able to view latex documents 
> as HTML in the wiki pages, only by opening their pdf versions as downloaded 
> documents.
>
> It should be possible to install latexml in your home directory and configure 
> WorkingWiki to use it.  First you would need to get latexml installed and 
> running, of course.  Then you may need to create a "site makefile" to make 
> the latex and latexml executables available to WorkingWiki's makefile.  This 
> means creating a file called
> resources/site/makefile-before containing lines like
> export LATEX=/path/to/latex
> export LATEXML=/path/to/latexml
>
> Site makefiles may not be very well documented - I'll have a look and try to 
> improve the docs if needed.  Write me or the list if you need more info. 
> Thanks!
>
> Lee
>
>
> On Mon, 20 Dec 2010, Cesar Flores wrote:
>> Subject: [ww-users] Using latex locally?
>> 
>> For rendering latex documents is Tex Live enough? Or I need to install
>> latexml too?
>> 
>> Is there some way of using a local installation? I do not have root access
>> in the server and Tex Live has been installed locally.
>> 
>> 
>> Thanks
>> 
>

[ww-users] 3134685: one-stop makefile for recursive operations

[lee w. <wor...@gm...>]

An open question about how to make "make" include the special WorkingWiki 
rules when appropriate and not when it isn't.  These are the rules for 
making .tex into .pdf and .xhtml, but also a bunch of useful rules for R 
programs that Jonathan created for use on the McMaster site.

Below is the discussion so far from the feature-requests tracker, 
including my very biased roundup.  Jonathan, I invite your response.

Lee

---------- Edited and forwarded ----------

Feature Requests item #3134685, was opened at 2010-12-10 16:33

Submitted By: Lee Worden (worden)
Assigned to: Lee Worden (worden)
Summary: one-stop makefile for recursive operations

Initial Comment:

Date: Fri, 10 Dec 2010 16:29:19 -0800 (PST)
From: lee worden <wor...@gm...>

Okay.  As I understand it, the unmet need is to be able to write a simple
recursive make line like

         $(MAKE) -C $(PROJECT_DIR_Somewhere) -f [SOMETHING SIMPLE] target

which will include all the same makefiles that would be included by a WW
operation in PROJECT_DIR_Somewhere.  That is, either the one file
{makefile,Makefile,GNUMakefile}, or that file plus the default makefiles,
site makefiles, and .mk files, depending on whether the Use default
makefiles option is enabled for that project.

Correct me if I'm wrong.

I propose to have WW create for each project a file called
$(PROJECT_DIR_Somewhere).makefile that will do that job.  That is, it will
not be in the directory but next to it.  This will meet the above needs,
plus the needs of hypothetical WW users who want to import a project and not
have WW add unexpected files to it.

I'll implement this by having two standard makefiles, one with the WW stuff
enabled and one without, and each of these project-specific makefiles will
be a link to one or the other of these.

How does that sound?
lw

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

Comment By: Lee Worden (worden)
Date: 2010-12-24 12:08

Message:
from dushoff:

My first choice is that we make a directory by saying "make" in the
directory.  This seems transparent to me for calling, exporting, etc.
My current idea for implementation would be to _keep_ the checkbox ["Use
default rules" or whatever it's called - lw].
Iff "use rules" is on, WW would place a "makefile" in the directory at
source-sync.  Users who want to provide their own "makefile" but want
to use our rules, would need to invoke our -before and -after stuff
themselves; we would of course make this easy.

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

Comment By: Lee Worden (worden)
Date: 2010-12-24 12:17

Message:
Thus we have two competing proposals:

1. mine: put a makefile outside the project directory.
Pros: You can import your existing project and it will work the same in WW
as outside.  This seems important to me:
- a. in the future when I picture us moving projects in and out of WW more
fluidly.
- b. when prospective users try out WW but putting their current project
in it.  If it messes with their working directory by hijacking the makefile
structure, they will be offended even if it's functionally unobtrusive.
Cons: When you create a project in WW and export it, in order to get the
same make behavior as inside you have to use "make -f <something>" rather
than plain make.  (You can make it a shell alias though, like "wwmake
target".)

2. JD's: put a "makefile" in the project directory that will unobtrusively
override and extend the behavior of any existing "Makefile".
Pros: "make" just works and includes the WW-specific rules.
Cons: see "Pros" for proposal 1.  Do we create "makefile" for projects
that have a "Makefile" but not for ones that have a "makefile"?  This
imposes an interpretation on the project author's intentions that I don't
think is warranted.  The idea that "Makefile" means you want our rules for
making .tex files into .pdf and .xhtml, while "makefile" means you want
those features disabled seems inaccurate and can cause great confusion and
frustration.

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

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

Re: [ww-users] Using latex locally?

[lee w. <wor...@gm...>]

In order to use WorkingWiki as is, you need both latex (TeXlive should be 
fine) and latexml.  If you have a need for WorkingWiki without latexml, I 
can work with you - in that case, you would not be able to view latex 
documents as HTML in the wiki pages, only by opening their pdf versions as 
downloaded documents.

It should be possible to install latexml in your home directory and 
configure WorkingWiki to use it.  First you would need to get latexml 
installed and running, of course.  Then you may need to create a "site 
makefile" to make the latex and latexml executables available to 
WorkingWiki's makefile.  This means creating a file called
resources/site/makefile-before containing lines like
  export LATEX=/path/to/latex
  export LATEXML=/path/to/latexml

Site makefiles may not be very well documented - I'll have a look and try 
to improve the docs if needed.  Write me or the list if you need more 
info.  Thanks!

Lee


On Mon, 20 Dec 2010, Cesar Flores wrote:
> Subject: [ww-users] Using latex locally?
> 
> For rendering latex documents is Tex Live enough? Or I need to install
> latexml too?
>
> Is there some way of using a local installation? I do not have root access
> in the server and Tex Live has been installed locally.
>
>
> Thanks
>

[ww-users] Using latex locally?

[Cesar F. <ce...@gm...>]

For rendering latex documents is Tex Live enough? Or I need to install
latexml too?

Is there some way of using a local installation? I do not have root access
in the server and Tex Live has been installed locally.


Thanks
-- 
Cesar Flores

Re: [ww-users] 3139540 timeout should be per-page, not per-target (fwd)

[lee w. <wor...@gm...>]

Yes. Maybe a "click here to remake this file", and/or "click to remake 
this file in the background", not just "click to retry the page" as we 
used to have (maybe still do?).  "Retry the page", aka purge, will help if 
the makefile is organized so that some intermediaries get made before the 
timeout, and going back for a second try will help finish the job, not so 
much if it's just one 10-minute process that everything depends on.

ps. sometime in the future I might be able to provide each project file 
asynchronously - like give you the page with empty boxes that say "waiting 
for project file" and then each one will fill in its box when the make 
process is done...

On Sat, 18 Dec 2010, Peter L. Ralph wrote:
> To: lee worden <wor...@gm...>
> Cc: wor...@li...
> Subject: Re: [ww-users] 3139540 timeout should be per-page,
>     not per-target	(fwd)
> 
> I agree.  And what happens if it's more than three minutes?  Providing
> something like "This timed out; click here to remake this file in a more
> relaxed manner."
>
> On Fri, Dec 17, 2010 at 10:12:58PM -0800, lee worden wrote:
>> What do you guys think about this one?  Any objections?
>> lw
>>
>> ---------- Forwarded message ----------
>> Date: Sat, 18 Dec 2010 06:11:05 +0000
>> From: SourceForge.net <no...@so...>
>> Subject: [ workingwiki-Bugs-3139540 ] timeout should be per-page, not per-target
>>
>> [...]
>>
>> Summary: timeout should be per-page, not per-target
>>
>> Initial Comment:
>>
>> The 3 minute timeout can add up to a long wait since it's 3 minutes for
>> each project file on the page.  It should be 3 minutes total, which would
>> not be hard to implement.  (It wouldn't strictly be 3 minutes from start
>> to end, since the wikitext parsing could take longer, but would mean no
>> more make operations once 3 minutes has passed.)
>>
>> ----------------------------------------------------------------------
>>
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=1527385&aid=3139540&group_id=366300
>>
>> ------------------------------------------------------------------------------
>> Lotusphere 2011
>> Register now for Lotusphere 2011 and learn how
>> to connect the dots, take your collaborative environment
>> to the next level, and enter the era of Social Business.
>> http://p.sf.net/sfu/lotusphere-d2d
>> _______________________________________________
>> workingwiki-users mailing list
>> wor...@li...
>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users
>

Re: [ww-users] 3139540 timeout should be per-page, not per-target (fwd)

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

I agree.  And what happens if it's more than three minutes?  Providing
something like "This timed out; click here to remake this file in a more
relaxed manner."

On Fri, Dec 17, 2010 at 10:12:58PM -0800, lee worden wrote:
> What do you guys think about this one?  Any objections?
> lw
> 
> ---------- Forwarded message ----------
> Date: Sat, 18 Dec 2010 06:11:05 +0000
> From: SourceForge.net <no...@so...>
> Subject: [ workingwiki-Bugs-3139540 ] timeout should be per-page, not per-target
> 
> [...]
> 
> Summary: timeout should be per-page, not per-target
> 
> Initial Comment:
> 
> The 3 minute timeout can add up to a long wait since it's 3 minutes for 
> each project file on the page.  It should be 3 minutes total, which would 
> not be hard to implement.  (It wouldn't strictly be 3 minutes from start 
> to end, since the wikitext parsing could take longer, but would mean no 
> more make operations once 3 minutes has passed.)
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=1527385&aid=3139540&group_id=366300
> 
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users

[ww-users] 3139540 timeout should be per-page, not per-target (fwd)

[lee w. <wor...@gm...>]

What do you guys think about this one?  Any objections?
lw

---------- Forwarded message ----------
Date: Sat, 18 Dec 2010 06:11:05 +0000
From: SourceForge.net <no...@so...>
Subject: [ workingwiki-Bugs-3139540 ] timeout should be per-page, not per-target

[...]

Summary: timeout should be per-page, not per-target

Initial Comment:

The 3 minute timeout can add up to a long wait since it's 3 minutes for 
each project file on the page.  It should be 3 minutes total, which would 
not be hard to implement.  (It wouldn't strictly be 3 minutes from start 
to end, since the wikitext parsing could take longer, but would mean no 
more make operations once 3 minutes has passed.)

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

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

[ww-users] File cannot be displayed directly (fwd)

[lee w. <wor...@gm...>]

I've just submitted this tracker entry, and I'm interested in your 
opinions. - lw

---------- Forwarded message (lightly edited) ----------
Date: Fri, 17 Dec 2010 01:20:36 +0000
From: SourceForge.net <no...@so...>
Subject: [ workingwiki-Bugs-3138873 ] File cannot be displayed directly

Bugs item #3138873, was opened at 2010-12-16 17:20
Message generated for change (Tracker Item Submitted) made by worden
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1527385&aid=3138873&group_id=366300

Submitted By: Lee Worden (worden)
Assigned to: Lee Worden (worden)
Summary: File cannot be displayed directly

Initial Comment:

When you go to Special:GetProjectFile for a pdf, eps, or other filetype 
that can't be viewed in the browser (that is, files that display as "link" 
by default), newer versions of GetProjectFile display a link with a notice 
that the file can't be displayed.  Is this ever useful?  Should it just 
give you a download of the file and save you a second click?

The idea behind this change was that the page with the link and notice 
gives you the opportunity to click on "make" and "log", where the raw file 
doesn't.  I had a request at the time that when you view a project file 
that hasn't been remade, for instance from a link in a makefile, there 
should be a "make" link to remake it easily.

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

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

Re: [ww-users] new latexml bindings

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

Ah ha!  Good thinking!  That worked!

On Thu, Dec 02, 2010 at 06:20:11PM -0800, lee worden wrote:
> Hmm, it wouldn't be able to do any latex at all if it wasn't finding its  
> package files.  It looks for them in the Perl search path, not the TeX  
> search path.  I suggest you check whether the Package directory has been  
> copied into for instance /usr/local/share/perl.  "locate LaTeX.pool" is  
> useful for finding out where it's installed its files.
>
> lw
>
> On Tue, 30 Nov 2010, Peter L. Ralph wrote:
>> To: wor...@li...
>> Subject: [ww-users] new latexml bindings
>>
>> Hi, all -- I'm trying to put in support for \Venus and \Mars symbols
>> (from package mathabx, btw), and I have made a mathabx.sty.ltxml file
>> that works, but I haven't been able to figure out where to put it. I put
>> it with all the other .ltxml files,
>> /usr/local/LaTeXML/lib/LaTeXML/Package/ , but it doesn't find it there
>> unless I use the latexml --path option to tell it to.  Has anyone
>> figured this out yet?
>>
>> -p
>>
>>
>> ------------------------------------------------------------------------------
>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>> Tap into the largest installed PC base & get more eyes on your game by
>> optimizing for Intel(R) Graphics Technology. Get started today with the
>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
>> http://p.sf.net/sfu/intelisp-dev2dev
>> _______________________________________________
>> workingwiki-users mailing list
>> wor...@li...
>> https://lists.sourceforge.net/lists/listinfo/workingwiki-users
>>

Re: [ww-users] new latexml bindings

[lee w. <wor...@gm...>]

Hmm, it wouldn't be able to do any latex at all if it wasn't finding its 
package files.  It looks for them in the Perl search path, not the TeX 
search path.  I suggest you check whether the Package directory has been 
copied into for instance /usr/local/share/perl.  "locate LaTeX.pool" is 
useful for finding out where it's installed its files.

lw

On Tue, 30 Nov 2010, Peter L. Ralph wrote:
> To: wor...@li...
> Subject: [ww-users] new latexml bindings
> 
> Hi, all -- I'm trying to put in support for \Venus and \Mars symbols
> (from package mathabx, btw), and I have made a mathabx.sty.ltxml file
> that works, but I haven't been able to figure out where to put it. I put
> it with all the other .ltxml files,
> /usr/local/LaTeXML/lib/LaTeXML/Package/ , but it doesn't find it there
> unless I use the latexml --path option to tell it to.  Has anyone
> figured this out yet?
>
> -p
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> workingwiki-users mailing list
> wor...@li...
> https://lists.sourceforge.net/lists/listinfo/workingwiki-users
>

[ww-users] new latexml bindings

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

Hi, all -- I'm trying to put in support for \Venus and \Mars symbols
(from package mathabx, btw), and I have made a mathabx.sty.ltxml file
that works, but I haven't been able to figure out where to put it. I put
it with all the other .ltxml files,
/usr/local/LaTeXML/lib/LaTeXML/Package/ , but it doesn't find it there
unless I use the latexml --path option to tell it to.  Has anyone
figured this out yet?

-p

[ww-users] test message #3

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

If you are reading this, you are on the new 
wor...@li... email list (and I am also, this time).

I've created a code repository, bug tracker and email list for WorkingWiki at 
sourceforge.net:

bug tracker:
  https://sourceforge.net/tracker/?group_id=366300&atid=1527385
email list:
  https://lists.sourceforge.net/lists/listinfo/workingwiki-users
(the code isn't moved there from lalashan yet.)

This list is for people who have workingwiki running at their sites.  I don't 
know whether we'll want to have separate lists for people who run working wikis 
and people who use them...  for now this is maybe for both.

There are other trackers, forums, etc. attached to the project on sourceforge, 
but I plan to disable some or all of them for simplicity.

lw