[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.