xnec2c is a GTK+ graphical interactive version of nec2c. It incorporates the nec2c core which it uses for reading input files and calculating output data, but it does not need and indeed does not produce an output file by default. Since xnec2c incorporates the nec2c core, it has access to all internal buffers, including structure data, frequency-related data (structure currents, input impedance, gain etc) and radiation pattern data (for the far field and near field). It therefore has the ability to graphically display user-requested data directly, as the frequency loop progresses or after input from the user. Graphs of frequency-related data and the current or charge distribution evolve as the frequency loop progresses, and radiation patterns (far and near field) are sequentially drawn for each frequency step. A new frequency can be entered by the user from spin buttons in the main or radiation pattern windows or by clicking on the graphs of frequency-related data. New output data are then computed and displayed in text and graphical form. nec2c is based on nec2. The Numerical Electromagnetics code (NEC-2) is a computer code for analyzing the electromagnetic response of an arbitrary structure consisting of wires and surfaces in free space or over a ground plane. The analysis is accomplished by the numerical solution of integral equations for induced currents. The excitation may be an incident plane wave or a voltage source on a wire, while the output may include current and charge density, electric or magnetic field in the vicinity of the structure, and radiated fields.
Created attachment 88386 [details] sci-misc/xnec2c ebuild Work just fine for me. Not sure about the dependancies.
Few comments here as well: 1. RESTRICT="nomirror" The package is under GPL according to the LICENSE line, why the restrict? 2. src_compile() { econf || die "configure failed" emake || die "emake failed" } is totally unnecessary. This is the default, in fact the simplified default. src_compile should only be provided if you are doing something non-standard/non-trivial.. 3. einfo install is there a purpose to this? You do get notification that you are in the install phase anyway, just without color :). 4. cd ${S}/examples doins * could have been simply doins examples/* (you start in ${S} when you enter any of the src_* functions) 5. same comment on the docs installation as in #135573 George
(In reply to comment #2) > Few comments here as well: > > 1. RESTRICT="nomirror" > The package is under GPL according to the LICENSE line, why the restrict? > because the download is not on a sourceforge mirror. Maybe I misunderstand the meaning of nomirror. > 2. > src_compile() { > econf || die "configure failed" > emake || die "emake failed" > } > is totally unnecessary. This is the default, in fact the simplified default. > src_compile should only be provided if you are doing something > non-standard/non-trivial.. > I was not aware of it, thanks to tell me that. > 3. einfo install > is there a purpose to this? You do get notification that you are in the install > phase anyway, just without color :). > No special purpose. I believe at I was just doing as in some another ebuild. > 4. > cd ${S}/examples > doins * > could have been simply > doins examples/* > (you start in ${S} when you enter any of the src_* functions) > Maybe some sandbox violation and I was working that way for me. It is just fine if it is a simpler way to do it. Thank you, Dominique > 5. same comment on the docs installation as in #135573 > > George >
(In reply to comment #3) > > 1. RESTRICT="nomirror" > > The package is under GPL according to the LICENSE line, why the restrict? > > > because the download is not on a sourceforge mirror. Maybe I misunderstand the > meaning of nomirror. Argh, I for some reason read that as RESTRICT="fetch", sorry about that, but nomirror should not be there either. Strictly speaking, this restriction is for the situation when we cannot mirror sources (for some legal reasons) or we would rather not. The most common example of the last one is actually related to surceforge, but is the opposite of what you seem to think :). Gentoo has its own, quite intensive system of source mirrors, so most of the time sources are fetched off the mirrors and not from the upstream location (and thus upstream does not suffer huge hit rates and even small sites can survive). Sourceforge.net has its own similarly intense mirror system. In fact many mirrors carry both sourceforge and gentoo. So, in this particular case there is no gain by mirroring sources twice and putting that restriction makes sense. Then you put RESTRICT="nomirror" and specify SRC_URI in a special form: SRC_URI="mirror://sourceforge/..." thus avoiding the duplication of sources on mirrors. However this is usually taken care by the developer who commits the ebuild, so original submitters need not worry (as they don't usually know about all these small issues). > > 3. einfo install > No special purpose. I believe at I was just doing as in some another ebuild. Sometimes I do something like this when debugging the ebuild, however normally this should not go into the final version, but sometimes may slip in, as people are usually concentrated on a "real" issues. Possibly you saw one of such slips. Here in is a value of revisiting one's commits after a while :). > > 4. > > cd ${S}/examples > > doins * > > > Maybe some sandbox violation and I was working that way for me. It is just fine > if it is a simpler way to do it. Well, these two ways are completely identical. I do not see how having it in one line could cause sandbox violation. May be were at some very external location? But you should not have been able to go outside sandbox anyway.. So, could you update the ebuilds please, taking these notes into account? Even if no developer takes upon them to maintain it is still beneficial to users who may need one of these packages and who are going to just take them off bugzilla. It is better that they take the more "appropriate" version :). Speaking of these ebuilds making it into the official tree: the major requirement is that they are actively maintained, meaning that there is an active maintainer (a developer) taking on it specifically or a herd (a grouping of packages that can be overseen by one or more developers) to which it can belong. So, would you be willing to take on the maintainership of these ebuilds and join Gentoo (Scientific Gentoo project specifically ;))? If you subscribe to gentoo-dev you may have noticed that we are reorganizing Scientific Gentoo and will have multiple groups of developers managing reasonably sized herds. I would guess these ebuilds would fall under sci-electronics, if they were going to go in eventually.. George
(In reply to comment #4) > (In reply to comment #3) > > > 1. RESTRICT="nomirror" > > > The package is under GPL according to the LICENSE line, why the restrict? > > > > > because the download is not on a sourceforge mirror. Maybe I misunderstand the > > meaning of nomirror. > Argh, I for some reason read that as RESTRICT="fetch", sorry about that, but > nomirror should not be there either. Strictly speaking, this restriction is for > the situation when we cannot mirror sources (for some legal reasons) or we > would rather not. The most common example of the last one is actually related > to surceforge, but is the opposite of what you seem to think :). Gentoo has its > own, quite intensive system of source mirrors, so most of the time sources are > fetched off the mirrors and not from the upstream location (and thus upstream > does not suffer huge hit rates and even small sites can survive). > Sourceforge.net has its own similarly intense mirror system. In fact many > mirrors carry both sourceforge and gentoo. So, in this particular case there is > no gain by mirroring sources twice and putting that restriction makes sense. > Then you put RESTRICT="nomirror" and specify SRC_URI in a special form: > SRC_URI="mirror://sourceforge/..." Actually use RESTRICT="mirror" instead, nomirror is the deprecated form. We're restricting mirroring rather than restricting not mirroring.
Created attachment 90472 [details] ebuild for xnec2c-0.3 + use flag for nec2 documentation + some minor changes (better syntax)
Created attachment 90768 [details] ebuild for xnec2c-0.3 Removed the doc use flag and added sci-electronics/nec2doc as dependency. nec2doc ebuild: http://bugs.gentoo.org/show_bug.cgi?id=138770
Created attachment 90769 [details] ebuild for xnec2c-0.3 removed nomirror restriction
It is maybe the same problem with this ebuild and the -O3 flag as with nec2++. http://bugs.gentoo.org/show_bug.cgi?id=135550 I asked the xnec2c's developper if he is aware about that.
Is this the same program that has a 1.0 beta out? http://ftp.de.debian.org/debian/pool/main/x/xnec2c/xnec2c_1.0b5.orig.tar.gz For some reason I can't reach the project homepage right now, but the above version seems to build on my system.
New homepage is http://5b4az.chronos.org.uk/pages/nec2.html and actual version is 1.3
Why not sci-electronics?
Ebuild for xnec2c-1.3 is now in sci overlay
MOved to the tree. + 25 Aug 2010; Thomas Beierlein <tomjbe@gentoo.org> +xnec2c-1.4.ebuild, + +metadata.xml: + Moved from science overlay, bug # 135573 +
