gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] New Developer


From: al davis
Subject: Re: [Gnucap-devel] New Developer
Date: Tue, 20 May 2014 01:26:12 -0400
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

On Monday 19 May 2014, Felix Salfelder wrote:
> On Mon, May 19, 2014 at 07:05:21AM -0700, Aidan Macdonald 
wrote:
> > Thank you for the quick response. I think I will take on
> > the first two (Make/Build/Test System, and Code Clean up).
> > That way I can get familiar with the code.

> there's an autotools and a cmake-WIP branch on savannah git.
> both have not been merged yet. i'm not sure about what is
> actually missing. the test suite (autotools based) is in the
> tests branch. perhaps Al should comment on what is still
> needed before he intends to merge it.

You can start there.  Also look at the "old" build system.  
There are advantages and disadvantages of both, including 
absolute needs that are met by  one and not the other, both 
ways.  This has meant so far to keep them both in parallel, 
which is evil, but has been a necessary evil.


> the situation with the code cleanup is similar, please have a
> look at the gnucap-devel achive for more details. or just
> ask.

I think new plugins for new features will be easier.  Taking on 
a "cleanup" is likely to be more difficult that you expect.

> > I will clone the code from GIT and work on it as stated.
> > Once I am satisfied, how should I submit it for review?
> 
> i think it makes most sense to use one branch (based on
> master) per topic. i expect that Al will grant you access to
> the repo, just request it somewhere on the savannah project
> page.

Access granted.  We need to set up a wiki account too.  I need 
to do that, because if I open it up it gets flooded with 
hundreds of bogus signups.

Yes .. one branch per topic ..  xxxx-WIP where xxx is the topic, 
your name, or something like that.  WIP means work in progress.  
When you think it is ready, say so on this list.  I guarantee 
that the first time it won't be.  That's one of the realities of 
development that it takes a few years to fully appreciate.

Any branch considered for merge must be based directly on 
"master"


Here are a few more ideas:

1. Make an ADMS/gnucap package.  This would be a version of ADMS 
that generates code for Gnucap, and is packaged so it is ready 
to be used.

2. Gnucap backend for Icarus Verilog.

3. Develop automatic derivative code for modelgen.  I have, 
stashed away, a little bit-rotted, a version of modelgen that 
takes Verilog syntax.  It is missing code to take derivatives of 
expressions.  Finish that, we have our own model compiler, an 
alternative to ADMS.  This is important because then we can 
extend it to handle the mixed-mode part of Verilog, which ADMS 
will probably never support.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]