fenics team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 03/22/2013 10:10 AM, Martin Sandve Alnæs wrote:
> Having outdated docstrings if you forget to run a magic script in some
> folder is not very convenient. 

That has been the behavior up to now anyhow. I agree it is suboptimal.

> (And why is it so slow?)

I did some profiling a while ago bu I do not remember. Kristian wrote
the algorithm, but it should be pretty straightforward to optimize. It
is just not on the top of my list...

Johan

> Martin
> 
> 
> On 22 March 2013 10:07, Johan Hake <hake.dev@xxxxxxxxx
> <mailto:hake.dev@xxxxxxxxx>> wrote:
> 
>     On 03/22/2013 09:06 AM, Anders Logg wrote:
>     > On Fri, Mar 22, 2013 at 12:58:43AM +0000, Florian Rathgeber wrote:
>     >> -----BEGIN PGP SIGNED MESSAGE-----
>     >>> On Thu, Mar 21, 2013 at 11:06:14PM +0100, Martin Sandve Alnæs
>     >>>
>     >>>
>     >>> By this argument, there isn't much we can remove.
>     >> How about using git-fat to handle large files that we don't want in
>     >> the repository, but still be able to pull in on demand? Jed has a
>     >> recipe for filtering an existing repository and taking a list of
>     files
>     >> to be handled by git-fat:
>     >> https://github.com/jedbrown/git-fat/blob/master/test-retroactive.sh
>     >
>     > For me as a newcomer to git, it seems like an extra complication, and
>     > the problem is not that we have a bunch of files which are very
>     > large. It's more that we have very many files of moderate size that we
>     > generate and these change frequently. Furthermore, we can only a apply
>     > a filter to a few of these files so we would need to list them
>     > manually.
>     >
>     > It seems there a differing opinions on a few matters:
>     >
>     > - Should we care about conversion of branches?
>     >
>     >   My opinion is yes. There are quite a few active branches on
>     >   Launchpad, more than I had thought.
> 
>     Agree.
> 
>     > - Should we strip files from the history? Or just leave it as it is?
>     >
>     >   My opinion is yes. We will archive the full repository on the web
>     >   page and possibly some archive site so that historians can go back
>     >   and excavate the history in full detail.
>     >
>     >   It needs to be discussed exactly which files to remove. See earlier
>     >   post for a suggestion.
>     >
>     > - Should we remove meshes from the repository?
>     >
>     >   My opinion is yes. The meshes have already been removed and
>     >   a working system for easily downloading the meshes is in place.
>     >   This system will encourage the use of more interesting meshes (since
>     >   they no longer need to be very small) and will encourage
>     >   contribution of meshes to the gallery on the web page.
> 
>     Just to clarify. The meshes you are talking about are meshes not used in
>     demos, right? If so, I agree.
> 
>     > - Should we remove generated code from the repository?
>     >
>     >   Martin has some good arguments in favor of keeping the generated
>     >   code, but I'm not fully convinced. A compromise would be to include
>     >   all files needed to build the library itself, which essentially
>     >   means keeping the generated code in dolfin/ale.
> 
>     I think we should keep these in the repo.
> 
>     >   But does that mean we should also keep all the old generated code
>     >   that was part of the library at some point?
> 
>     No strong opinion.
> 
>     All the swig code can be regenerated by dolfin provided tools so that is
>     OK to remove. However the docstring generation code is really slow, and
>     is pretty annoying to generate. But as others have mentioned. This could
>     be a cmake-cached process, which is only done once, unless the
>     CMakeCache is removed or one trigger the generation script under
>     cmake/scripts.
> 
>     Johan
> 
>     > --
>     > Anders
>     >
>     > _______________________________________________
>     > Mailing list: https://launchpad.net/~fenics
>     > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>     <mailto:fenics@xxxxxxxxxxxxxxxxxxx>
>     > Unsubscribe : https://launchpad.net/~fenics
>     > More help   : https://help.launchpad.net/ListHelp
>     >
> 
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~fenics
>     Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>     <mailto:fenics@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~fenics
>     More help   : https://help.launchpad.net/ListHelp
> 
>