Re: [Gnucap-devel] git repo proposal

[Felix Salfelder]

Hi Al.

On Sun, May 26, 2013 at 03:34:24PM -0400, al davis wrote:
> Yes .. that's what I mean.
> 
> Some of it exists
> 
> On Sunday 26 May 2013, Felix Salfelder wrote:
> > on my end, some things that might be worth importing are
> > - sensitivity analysis
> > - dc dynamics analysis
> > - dc sweep improvements
> > - lang_spectre patches/fixes
> 
> That's all plugins.  They should be developed out-of-tree, but 
> we need a place for them in the repository.

so actually the tree does not equal the repository? what exactly are you
referring to with "tree"?

i'd say plugins that are new should go to where the plugins are (i.e.
into 'apps'). patches/improvements to plugins should go to where the
plugin already is. what's the big deal? lets put it into a different
branch and merge it once it's complete.

> >   - some parameter scoping issues fixed 
> 
> Some of that is fixed in Gennady's branch.  I need to fold it in 
> to the master.

are you sure? the parameter patches i found within Gennadys repo didn't
really fix anything. (but maybe i'm wrong, need to take another look).

> > - basic unit testing
> 
> I have most of this .. need to upload it.  Also, I need to 
> document the procedure for this.  It works quite well.  It uses 
> the untested() macros from io_trace.h.  It needs to be more 
> complete than it is.  Wherever you see untested(), that 
> identifies a path that the test suite doesn't cover.  The empty 
> else clauses have significance in testing.

this sounds interesting.

> I don't think the whole test suite should be distributed in the 
> tarball, but it should be in git.

depending on how many tests this is about, i probably agree :)

> > - lots of experiments involving backend changes
> >   - parameter lists
> >   - ELEMENTs with more than 1 input
> 
> That's also something to try out-of-tree in plugins.  It would 
> be in addition to the existing ELEMENT, not instead of.  
> COMPONENT is more general.

no. parameter lists is a specialization of PARAMETER<T> in case T is
vector<PARAMETER<S> >. so it's part of u_parameter.h. iirc, my *IR
filters make use of it...

> The purpose of ELEMENT is to provide a high efficiency way to do 
> the simplest of devices.

an element has a forbidden and unused subckt pointer which can be used
to chain in more inputs. permitting its use wont affect efficiency.
forking ELEMENT just for that purpose doesn't make sense.

i have got a pretty complete poly(k) implementation (any k). lets talk
about the ELEMENT patch once its ready.

> I don't know either, but this looks a lot like my list.

tons of work :(

regards
felix