Re: svn commit: r180173 - in /gump/branches/Gump3

[Leo Simons <ma...@leosimons.com>]

On 06-06-2005 01:22, "ajack@apache.org" <aj...@apache.org> wrote:
> 1) added -b --do-builds (defaults to FALSE, like --do-updates, for initial
> devel)

Do you think we should have a "stage" abstraction or something like that,
ie, will there be many more --do-blah-blah? If so, we might want to have
this

 gump run --stages=build,update,generate-docs

I'm not sure we want this, just an RT :-). Or maybe what we really want is

 gump run-build
 gump run-update
 gump run-doc-generation

Which delegate to the "run" option with some specific options.

> 2) Fixed Dynagumper workspace description crash (if none)
> 3) Avoid floating point crash when no statistics to display

That's a great example of something that I hacked together too quickly and
should've tested more properly. While I appreciate you cleaning up some of
my mess, you can also just slap me on the fingers :-)

...
> Modified: gump/branches/Gump3/pygump/main.py
...
> +    parser.add_option("-b",
> +                      "--do-builds",
> +                      action="store_true",
> +                      dest="do_build",
> +                      default=False, # Default to NOT. At least during
> initial development...
> +                      help="run builders")
...
> Modified: gump/branches/Gump3/pygump/python/gump/config.py
...
> -    # by contract, rmdir always needs to go before mkdir!
> -    from gump.plugins.dirbuilder import RmdirBuilderPlugin
> -    plugins.append(RmdirBuilderPlugin(config.paths_work))
> -    from gump.plugins.dirbuilder import MkdirBuilderPlugin
> -    plugins.append(MkdirBuilderPlugin(config.paths_work))
> +    if config.do_build:
> +        # by contract, rmdir always needs to go before mkdir!
> +        from gump.plugins.dirbuilder import RmdirBuilderPlugin
> +        plugins.append(RmdirBuilderPlugin(config.paths_work))
> +        from gump.plugins.dirbuilder import MkdirBuilderPlugin
> +        plugins.append(MkdirBuilderPlugin(config.paths_work))
>      
> -    buildlog = get_logger(config, "plugin.builder")
> +        buildlog = get_logger(config, "plugin.builder")
>      
> -    from gump.plugins.builder import ScriptBuilderPlugin
> -    plugins.append(ScriptBuilderPlugin(config.paths_work,buildlog))
> -    from gump.plugins.java.builder import ClasspathPlugin
> -    plugins.append(ClasspathPlugin(config.paths_work,buildlog))
> -    from gump.plugins.java.builder import AntPlugin
> -    plugins.append(AntPlugin(config.paths_work,buildlog))
> +        from gump.plugins.builder import ScriptBuilderPlugin
> +        plugins.append(ScriptBuilderPlugin(config.paths_work,buildlog))
> +        from gump.plugins.java.builder import ClasspathPlugin
> +        plugins.append(ClasspathPlugin(config.paths_work,buildlog))
> +        from gump.plugins.java.builder import AntPlugin
> +        plugins.append(AntPlugin(config.paths_work,buildlog))

You know, the lack of lots of new lines of code here is real cool! Adding a
new build option and updating the behaviour surrounding that option is very
neatly localized. I'm guessing it didn't take you ages to figure out how to
do this. Cool!

> Modified: gump/branches/Gump3/pygump/python/gump/engine/__init__.py
> +            import pprint
> +            pprint.pprint(domtree)

I'm guessing you didn't mean to commit that.

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: svn commit: r180173 - in /gump/branches/Gump3

["Adam R. B. Jack" <aj...@apache.org>]

> On 06-06-2005 01:22, "ajack@apache.org" <aj...@apache.org> wrote:
> > 1) added -b --do-builds (defaults to FALSE, like --do-updates, for
initial
> > devel)
>
> Do you think we should have a "stage" abstraction or something like that,
> ie, will there be many more --do-blah-blah? If so, we might want to have
> this

Like you, I expect more, but I figure we let the number get to 3
(semi-arbitrary, just the first real 'N') before we did anything. I do think
we need (desperately need, not just want) to be able to quickly
parse/validate the metadata and/or display it (before a commit, etc.) [We've
experienced a few metadata errors recently, and we ought have helped the
users through those.] This is only one example, and as such I think
configuring the plug-in selections/algorythms based of user choices (e.g
these or --debug) will likely become key.

For Gump2 we attempted separate scripts bin/build.py, bin/update.py,
bin/check.py and so forth. This was in part to emulate Gump1, in part to
allow separate comand lines per 'task'. I don't want to return to this
approach, just reminding of it. We probably have too many possible
permutations for simple combo-options like run-build. For now, I say keep
tinkering w/ options until we know better.

> > 3) Avoid floating point crash when no statistics to display
>
> That's a great example of something that I hacked together too quickly and
> should've tested more properly. While I appreciate you cleaning up some of
> my mess, you can also just slap me on the fingers :-)

Leo, bugs happen -- even to you. ;-) No finger slapping coming.

Sometimes the best ideas come from a good idea w/ a poor implementation
(again, something I've heard folks say about OSS projects :-). I say we
don't get anal about every line of code being great, just about having great
ideas.

> > Modified: gump/branches/Gump3/pygump/python/gump/engine/__init__.py
> > +            import pprint
> > +            pprint.pprint(domtree)
>
> I'm guessing you didn't mean to commit that.

Nope. Heck, I even do the "svn diff" religiously before commits, but missed
this. Oh well, thanks for catching it. Gone (for next commit).

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org