March 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] dates of last change on PETSc web pages
by Barry Smith 20 Mar '12

20 Mar '12

On Mar 20, 2012, at 10:27 PM, Jed Brown wrote: > On Tue, Mar 20, 2012 at 22:15, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > http://mercurial.selenic.com/wiki/KeywordExtension seems to be what we should use. It appears that the hg makes sure the working copy always has the value (Date of last change in our case) in files one sees. > > I don't really want to read diffs of all those dates. You will not be reading diffs of dates if the keyword extension works properly (i.e. like the RCS stuff works) > > Proving Linus thinks like Satish: > > Not sure this will ever be in Git. To quote Linus: "The whole notion of keyword substitution is just totally idiotic. It's trivial to do "outside" of the actual content tracking, if you want to have it when doing release trees as tar-balls etc." > > Are we that concerned with src/docs/website being unnamed before writing the tarball? What does unnamed mean? I am concerned about any PETSc webpages anywhere not having dates on them because as you pointed out it can be problematic. So manually written webpages get their dates automatically when "accessed" from hg and automatically generated webpages get their dates when the manual page is made (nothing gets the dates when the tarball is made). > > I think the date should go into the generated man pages while they are generated because that is when you know the modification date of the file. Correct and they will. In factor for generated manual pages shouldn't we also put the PETSc version next to the date, easy enough for Satish to do. Barry

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Sean Farley 20 Mar '12

20 Mar '12

> > We could put the placeholder if necessary, but the date should not be in > the checked-in source, just in the result of "make alldoc". > Thanks for chiming in but it doesn't seem that Barry is talking about this. No > Indeed, I just wanted to figure out what Barry wanted. It's weird, though. I don't seem to remember asking Jed what he wanted, only Barry.

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Barry Smith 20 Mar '12

20 Mar '12

On Mar 20, 2012, at 10:23 PM, Jed Brown wrote: > On Tue, Mar 20, 2012 at 21:59, Sean Farley <sean(a)mcs.anl.gov> wrote: > Oh, I think I see why I was confused now. I was talking about having a place holder (i.e. something like <div id="modified"></div>) in each page and that something would need to insert the output of $(hg log -l 1 --template '{date|dateiso}'). If I added javascript to the page then it would just get the date from a webservice ... which is pretty much worthless because the content wouldn't necessarily match the date. > > We could put the placeholder if necessary, but the date should not be in the checked-in source, Correct, date will not be in the checked in source. > just in the result of "make alldoc". Incorrect, date will be in the manually written pages in your workspace automatically, make alldoc has nothing to do with it and will not touching the dates for the manually written pages. make alldoc will be putting the dates into the generated manual pages as the manual pages are built. > > > Editing the pages is no biggie, Jed can give you a perl one liner to put the chunk of stuff you need added to each page. > > So you want the dates stored permanently in each webpage under src/docs/website (which would alter the commit history)? > > No Correct. Barry

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Jed Brown 20 Mar '12

20 Mar '12

On Tue, Mar 20, 2012 at 22:15, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > http://mercurial.selenic.com/wiki/KeywordExtension seems to be what we > should use. It appears that the hg makes sure the working copy always has > the value (Date of last change in our case) in files one sees. > I don't really want to read diffs of all those dates. > Proving Linus thinks like Satish: > > Not sure this will ever be in Git. To quote Linus: "The whole notion of > keyword substitution is just totally idiotic. It's trivial to do "outside" > of the actual content tracking, if you want to have it when doing release > trees as tar-balls etc." Are we that concerned with src/docs/website being unnamed before writing the tarball? I think the date should go into the generated man pages while they are generated because that is when you know the modification date of the file.

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Jed Brown 20 Mar '12

20 Mar '12

On Tue, Mar 20, 2012 at 21:59, Sean Farley <sean(a)mcs.anl.gov> wrote: > Oh, I think I see why I was confused now. I was talking about having a > place holder (i.e. something like <div id="modified"></div>) in each page > and that something would need to insert the output of $(hg log -l 1 > --template '{date|dateiso}'). If I added javascript to the page then it > would just get the date from a webservice ... which is pretty much > worthless because the content wouldn't necessarily match the date. > We could put the placeholder if necessary, but the date should not be in the checked-in source, just in the result of "make alldoc". > > Editing the pages is no biggie, Jed can give you a perl one liner to put >> the chunk of stuff you need added to each page. > > > So you want the dates stored permanently in each webpage under > src/docs/website (which would alter the commit history)? > No

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Sean Farley 20 Mar '12

20 Mar '12

> > I thought that when someone committed one of these files, as part of the > commit process hg would stick the current data into that file. If that is > not possible then a trigger when pushing something to the master repository > with a change in the file the trigger would put the date into the file > (perhaps creating another entry in the commit history at that time). > > RCS has this support trivially and for a ton of decades. > > Demo program for RCS > // $Author: ola $ > // $Date: 1997/01/20 22:58:41 $ > // $Id: foo.cc,v 1.1 1997/01/20 22:58:41 ola Exp $ > > > http://mercurial.selenic.com/wiki/KeywordExtension seems to be what we > should use. It appears that the hg makes sure the working copy always has > the value (Date of last change in our case) in files one sees. > > Check it out. Ok, I was totally misunderstanding what was going on. There are some ways to do that I've seen on the mercurial list. I think you're right about the keyword extension being what we want but I'll have to check it out in depth more. Sorry about the confusion.

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Barry Smith 20 Mar '12

20 Mar '12

On Mar 20, 2012, at 9:59 PM, Sean Farley wrote: > I thought you had some mechanism to get the date from Mecurial and put it into the page automatically. Did you or did you not have that? > > Oh, I think I see why I was confused now. I was talking about having a place holder (i.e. something like <div id="modified"></div>) in each page and that something would need to insert the output of $(hg log -l 1 --template '{date|dateiso}'). I thought that when someone committed one of these files, as part of the commit process hg would stick the current data into that file. If that is not possible then a trigger when pushing something to the master repository with a change in the file the trigger would put the date into the file (perhaps creating another entry in the commit history at that time). RCS has this support trivially and for a ton of decades. Demo program for RCS // $Author: ola $ // $Date: 1997/01/20 22:58:41 $ // $Id: foo.cc,v 1.1 1997/01/20 22:58:41 ola Exp $ http://mercurial.selenic.com/wiki/KeywordExtension seems to be what we should use. It appears that the hg makes sure the working copy always has the value (Date of last change in our case) in files one sees. Check it out. Proving Linus thinks like Satish: Not sure this will ever be in Git. To quote Linus: "The whole notion of keyword substitution is just totally idiotic. It's trivial to do "outside" of the actual content tracking, if you want to have it when doing release trees as tar-balls etc." > If I added javascript to the page then it would just get the date from a webservice .. No no no don't want that. Barry > . which is pretty much worthless because the content wouldn't necessarily match the date. > > Editing the pages is no biggie, Jed can give you a perl one liner to put the chunk of stuff you need added to each page. > > So you want the dates stored permanently in each webpage under src/docs/website (which would alter the commit history)?

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Sean Farley 20 Mar '12

20 Mar '12

> > I thought you had some mechanism to get the date from Mecurial and put it > into the page automatically. Did you or did you not have that? > Oh, I think I see why I was confused now. I was talking about having a place holder (i.e. something like <div id="modified"></div>) in each page and that something would need to insert the output of $(hg log -l 1 --template '{date|dateiso}'). If I added javascript to the page then it would just get the date from a webservice ... which is pretty much worthless because the content wouldn't necessarily match the date. Editing the pages is no biggie, Jed can give you a perl one liner to put > the chunk of stuff you need added to each page. So you want the dates stored permanently in each webpage under src/docs/website (which would alter the commit history)?

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Barry Smith 20 Mar '12

20 Mar '12

On Mar 20, 2012, at 9:35 PM, Sean Farley wrote: > I don't want the dates being put in when the tarball is created (for snapshots or anywhere else) I want them to go in when each manual page is made during the make docs process. > > Unfortunately, I just followed his method which saved me the task of editing each webpage. I thought you had some mechanism to get the date from Mecurial and put it into the page automatically. Did you or did you not have that? Editing the pages is no biggie, Jed can give you a perl one liner to put the chunk of stuff you need added to each page. Barry > > The reason is that we ALWAYS want dates in the manual pages, not just sometime in them (those without the dates will be the hardest to eradicate from the web). > > I agree but I haven't become too familiar with the maint scripts that generates and builds all of this stuff. If someone can work faster than I, just look at my changeset: > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/4b70b7e05675 > > for the regex I use to add the date. The important bit is to put the date in the header div: > > <div id="header"> > <div id="modified">Mar 20 2012 blah foo</div> > <h1>Header Text</h1> > </div> > > but if I recall correctly, the manual (web) pages aren't using a style sheet, so you might want to manually specify the style from this changeset: > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/51010035f538 > > <div id="header"> > <div style="font-size: 1em; float: right;">Mar 20 2012 blah foo</div> > <h1>Header Text</h1> > </div>

1 0

Re: [petsc-dev] dates of last change on PETSc web pages
by Barry Smith 20 Mar '12

20 Mar '12

On Mar 20, 2012, at 9:39 PM, Satish Balay wrote: > On Tue, 20 Mar 2012, Sean Farley wrote: > >>> >>> I don't want the dates being put in when the tarball is created (for >>> snapshots or anywhere else) I want them to go in when each manual page is >>> made during the make docs process. >>> >> >> Unfortunately, I just followed his method which saved me the task of >> editing each webpage. > > I thought this method was reasonable because: all docs are generated > primarily at tarball generation time. And the "canonical" tag for > google is added here - so modified the script to also add 'date' at > the same time. I thought I was pretty clear in my original request months ago. You have scripts that run through and build up the manual pages in several stages. Just add another simple stage that puts in the date, how is that hard? No harder then doing it at tarball time. Barry > > Satish > >> >> The reason is that we ALWAYS want dates in the manual pages, not just >>> sometime in them (those without the dates will be the hardest to eradicate >>> from the web). >> >> >> I agree but I haven't become too familiar with the maint scripts that >> generates and builds all of this stuff. If someone can work faster than I, >> just look at my changeset: >> >> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/4b70b7e05675 >> >> for the regex I use to add the date. The important bit is to put the date >> in the header div: >> >> <div id="header"> >> <div id="modified">Mar 20 2012 blah foo</div> >> <h1>Header Text</h1> >> </div> >> >> but if I recall correctly, the manual (web) pages aren't using a style >> sheet, so you might want to manually specify the style from this changeset: >> >> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/51010035f538 >> >> <div id="header"> >> <div style="font-size: 1em; float: right;">Mar 20 2012 blah foo</div> >> <h1>Header Text</h1> >> </div> >> >

1 0