qucs-devel — Development related topics. Please subcribe before posting.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(12) |
Feb
(9) |
Mar
(2) |
Apr
(9) |
May
(15) |
Jun
(2) |
Jul
|
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(4) |
Dec
|
| 2005 |
Jan
(3) |
Feb
(11) |
Mar
(9) |
Apr
(26) |
May
(10) |
Jun
(1) |
Jul
(10) |
Aug
(2) |
Sep
(8) |
Oct
(15) |
Nov
(8) |
Dec
(15) |
| 2006 |
Jan
(53) |
Feb
(21) |
Mar
(26) |
Apr
(20) |
May
(30) |
Jun
(22) |
Jul
(24) |
Aug
(36) |
Sep
(61) |
Oct
(21) |
Nov
(7) |
Dec
(8) |
| 2007 |
Jan
(30) |
Feb
(43) |
Mar
(40) |
Apr
(59) |
May
(8) |
Jun
(19) |
Jul
(34) |
Aug
(35) |
Sep
(9) |
Oct
(9) |
Nov
(66) |
Dec
(36) |
| 2008 |
Jan
(22) |
Feb
(42) |
Mar
(19) |
Apr
(25) |
May
(36) |
Jun
(16) |
Jul
(31) |
Aug
(16) |
Sep
(27) |
Oct
(25) |
Nov
(36) |
Dec
(24) |
| 2009 |
Jan
(38) |
Feb
(20) |
Mar
(62) |
Apr
(81) |
May
(53) |
Jun
(5) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(9) |
Nov
(8) |
Dec
(5) |
| 2010 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(10) |
| 2011 |
Jan
(4) |
Feb
(6) |
Mar
(29) |
Apr
(19) |
May
(4) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(3) |
Nov
(13) |
Dec
(3) |
| 2012 |
Jan
(2) |
Feb
(3) |
Mar
(3) |
Apr
(1) |
May
(7) |
Jun
(3) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(6) |
Dec
(4) |
| 2013 |
Jan
(41) |
Feb
(8) |
Mar
(14) |
Apr
(15) |
May
(15) |
Jun
(95) |
Jul
(91) |
Aug
(20) |
Sep
(19) |
Oct
(47) |
Nov
(29) |
Dec
(55) |
| 2014 |
Jan
(56) |
Feb
(7) |
Mar
(16) |
Apr
(14) |
May
(3) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
(4) |
Oct
(10) |
Nov
(35) |
Dec
(51) |
| 2015 |
Jan
(31) |
Feb
(28) |
Mar
(4) |
Apr
(31) |
May
(6) |
Jun
(23) |
Jul
(16) |
Aug
(2) |
Sep
(10) |
Oct
(9) |
Nov
(3) |
Dec
(6) |
| 2016 |
Jan
(14) |
Feb
(8) |
Mar
(11) |
Apr
(7) |
May
(1) |
Jun
(6) |
Jul
(5) |
Aug
(6) |
Sep
(3) |
Oct
(10) |
Nov
(12) |
Dec
(14) |
| 2017 |
Jan
(13) |
Feb
(8) |
Mar
(14) |
Apr
(26) |
May
(37) |
Jun
(15) |
Jul
(15) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(4) |
Dec
|
| 2018 |
Jan
(26) |
Feb
(7) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
|
2
|
3
|
4
|
5
(1) |
6
|
7
|
|
8
(2) |
9
(8) |
10
(2) |
11
(5) |
12
|
13
|
14
|
|
15
(1) |
16
(8) |
17
(2) |
18
(2) |
19
(1) |
20
|
21
(1) |
|
22
|
23
(1) |
24
(2) |
25
|
26
|
27
(2) |
28
(1) |
|
29
(1) |
30
(12) |
31
(1) |
|
|
|
|
|
From: Stefan Jahn <stefan@gr...> - 2006-01-17 07:38:29
|
On Di, 17.01.2006, 00:48, Edwin Naroska wrote: > Hi, Hallo! >>>1) ein freehdl-release muss verfuegbar sein, wenn qucs releast wird, >>>damit die die anwender ueberhaupt die moeglichkeit haben, sich ne >>>laufende installation zu bauen. das ist must-have. >> >> >> ja, dafuer wird gesorgt. >> >> > Ich schlage auch Lösung 1 vor. Ok. Zur Zeit gefaellt mir bei freehdl alles ganz gut. Raimund koennte ein tag (freehdl_0_0_1) in cvs tun und ich bastel das freehdl-0.0.1.tar.gz und schicke das an edwin, der es auf <http://cran.mit.edu/~enaroska/>? Oder doch irgendwo anders hin? Ich wuerde dann den Link auf der Qucs-Seite einbasteln. Ist das ein Plan? Gruesse, Stefan. |
|
From: Edwin Naroska <edwin@ds...> - 2006-01-16 23:48:22
|
Hi, Stefan Jahn schrieb: >> >>1) ein freehdl-release muss verfuegbar sein, wenn qucs releast wird, >>damit die die anwender ueberhaupt die moeglichkeit haben, sich ne >>laufende installation zu bauen. das ist must-have. >=20 >=20 > ja, dafuer wird gesorgt. >=20 >=20 Ich schlage auch L=F6sung 1 vor. -- Edwin |
|
From: Raimund 'Raimi' Jacob <raimi@lk...> - 2006-01-16 15:59:59
|
Stefan Jahn wrote:
hi!
>>i still not fully understand why this is neccessary, but that might work.
>
> is the "wait $!" posix compatible?
i wouldnt suggest anything that i didnt have the hope it would be
portable. so, the underlying system call is posix and i would test it on
freebsd and solaris before going on. but i'm pretty confident here.
Raimund
--
___ ___ _____________
/ /| / /_ / ____/ ___/\ Nothing useful for
/ / / / _ / / __/ / __\/ more than a decade
/ /_/_/ \/ /_/_/ /_/
{www.|raimi@} /______/__/\._\.____/\.____/\ .org
\._____\._\/\._\.___\/\.___\/
|
|
From: <Michael.Margraf@al...> - 2006-01-16 15:45:05
|
Hallo,
> Es ist die Frage aufgetreten, wie die naechste Release aussehen soll.
> Mit dem FreeHDL mit drin (so wie qucs-core auch). Oder FreeHDL weiter
> als eigenstaendiges Packet. Ich bin ja fuer letzteres.
>
> Raimund ist wohl fuer ersteres.
>
> Irgendwelche Meinungen?
Die Frage ist nicht leicht. Grundsätzlich bin ich ich auch dafür,
daß FreeHDL in Qucs rein muß. Irgendwann muß das so sein.
Momentan ist das aber meiner Meinung nach noch zu früh, so daß
ich für ein Extra-Paket stimmen würde.
Ich könnte mich allerdings mit beidem anfreunden und will hier
nicht das letzte Wort haben.
Grüße ...
Michael
|
|
From: Stefan Jahn <stefan@gr...> - 2006-01-16 14:08:24
|
On So, 15.01.2006, 16:42, Raimund 'Raimi' Jacob wrote: > hey folks! hello! > but there still is the problem that only the qucsdigi script itself is > killed, not its children. this can be solved by not killing the process > itself but the entire process group. this is easily done with kill(2) > but i see no QT API for it. > > it would be possible to do that from the qucsdigi script itself. adding > this at the beginning of qucsdigi: > > trap 'kill 0; exit 0' SIGINT SIGTERM > > would make it kill all children when it receives the INT or TERM signal > (which is what QProcess::kill/tryTerminate should do). > > for this to work each invocation in the script would have to be changed: > > echo -n "Doing something ..." > $something > echo "done" > > to > > echo -n "Doing something ..." > $something & > wait $! > echo "done" > > i still not fully understand why this is neccessary, but that might work. is the "wait $!" posix compatible? cheers, stefan. |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-16 13:27:26
|
On Mo, 16.01.2006, 14:20, Raimund 'Raimi' Jacob wrote: > huhu! hallo! >> Es ist die Frage aufgetreten, wie die naechste Release aussehen soll. >> Mit dem FreeHDL mit drin (so wie qucs-core auch). Oder FreeHDL weiter >> als eigenstaendiges Packet. Ich bin ja fuer letzteres. >> >> Raimund ist wohl fuer ersteres. >> >> Irgendwelche Meinungen? > > also ich kann schon verstehen, wenn freehdl und qucs nicht gebundelt > werden sollen, vielleicht muss das gar nicht unbedingt sein. mir sind > nur folgende sachen wichtig: > > 1) ein freehdl-release muss verfuegbar sein, wenn qucs releast wird, > damit die die anwender ueberhaupt die moeglichkeit haben, sich ne > laufende installation zu bauen. das ist must-have. ja, dafuer wird gesorgt. > 2) idealerweise hat alles die selbe versionsonummer, dann ist es > besonders leicht zu erklaeren, mit welchen freehdls das qucs > zusammenarbeitet. das ist aber nur nice-to-have. das wird wahrscheinlich nix... idealerweise, soll qucs mit jedem freehdl spielen. > 3) ich haette ja gerne, dass man das freehdl einfach in die distro mit > reinlegt und die dann automatisch configured und gebuildet wird, so > aehnlich wie mit dem qucs-core. das ist aber auch nur ein nice-to-have > und bisher ungeklaert, ob man die autotools ueberhaupt dazu kriegt. uhm. habe ich vergessen zu erwaehnen. das geht jetzt noch einfacher. mal im configure.ac von qucs reingucken. das ist jetzt die einzige stelle, wo was geaendert werden muss. :-) also die autotools kriegt man leicht dazu. > alles zu einem zusammenzupacken waere halt ziemlich anwenderfreundlich, > aber fuer die distributoren ist es eher oll, weil die ja freehdl als > eigenstaendiges paket haben (sollten). also mein wunsch ist eigentlich > (3). es wird meiner meinung nach einfach (1). also wenn keine groesseren widerstaende auftreten. steht ja grade 1:1... :-) stefan. |
|
From: Raimund 'Raimi' Jacob <raimi@lk...> - 2006-01-16 13:20:53
|
Stefan Jahn wrote:
huhu!
> Es ist die Frage aufgetreten, wie die naechste Release aussehen soll.
> Mit dem FreeHDL mit drin (so wie qucs-core auch). Oder FreeHDL weiter
> als eigenstaendiges Packet. Ich bin ja fuer letzteres.
>
> Raimund ist wohl fuer ersteres.
>
> Irgendwelche Meinungen?
also ich kann schon verstehen, wenn freehdl und qucs nicht gebundelt
werden sollen, vielleicht muss das gar nicht unbedingt sein. mir sind
nur folgende sachen wichtig:
1) ein freehdl-release muss verfuegbar sein, wenn qucs releast wird,
damit die die anwender ueberhaupt die moeglichkeit haben, sich ne
laufende installation zu bauen. das ist must-have.
2) idealerweise hat alles die selbe versionsonummer, dann ist es
besonders leicht zu erklaeren, mit welchen freehdls das qucs
zusammenarbeitet. das ist aber nur nice-to-have.
3) ich haette ja gerne, dass man das freehdl einfach in die distro mit
reinlegt und die dann automatisch configured und gebuildet wird, so
aehnlich wie mit dem qucs-core. das ist aber auch nur ein nice-to-have
und bisher ungeklaert, ob man die autotools ueberhaupt dazu kriegt.
alles zu einem zusammenzupacken waere halt ziemlich anwenderfreundlich,
aber fuer die distributoren ist es eher oll, weil die ja freehdl als
eigenstaendiges paket haben (sollten). also mein wunsch ist eigentlich (3).
Raimund
--
___ ___ _____________
/ /| / /_ / ____/ ___/\ Nothing useful for
/ / / / _ / / __/ / __\/ more than a decade
/ /_/_/ \/ /_/_/ /_/
{www.|raimi@} /______/__/\._\.____/\.____/\ .org
\._____\._\/\._\.___\/\.___\/
|
|
From: Stefan Jahn <stefan@gr...> - 2006-01-16 13:14:42
|
Hallo! Es ist die Frage aufgetreten, wie die naechste Release aussehen soll. Mit dem FreeHDL mit drin (so wie qucs-core auch). Oder FreeHDL weiter als eigenstaendiges Packet. Ich bin ja fuer letzteres. Raimund ist wohl fuer ersteres. Irgendwelche Meinungen? Gruesse, Stefan. |
|
From: <Michael.Margraf@al...> - 2006-01-16 07:43:50
|
Hello, that sounds good! Thanks a lot! I will have a try. Would be very nice if that works.... Regards, Michael > hey folks! > > Stefan told me that there is a problem with the qucsdigi script not > being possible to be killed using the 'cancel' button of the simulation > window. > > i spent some time playing around with the problem and found out this: > Currently there is a QProcess::kill() that terminates the qucsdigi > script. according the docs it might be better to use tryTerminate() > first: > http://doc.trolltech.com/qtopia1.7/html/qprocess.html#kill > > but there still is the problem that only the qucsdigi script itself is > killed, not its children. this can be solved by not killing the process > itself but the entire process group. this is easily done with kill(2) > but i see no QT API for it. > > it would be possible to do that from the qucsdigi script itself. adding > this at the beginning of qucsdigi: > > trap 'kill 0; exit 0' SIGINT SIGTERM > > would make it kill all children when it receives the INT or TERM signal > (which is what QProcess::kill/tryTerminate should do). > > for this to work each invocation in the script would have to be > changed: > echo -n "Doing something ..." > $something > echo "done" > > to > > echo -n "Doing something ..." > $something & > wait $! > echo "done" > > i still not fully understand why this is neccessary, but that might > work. > Want me to create a patch for this? > > Raimund > > -- > ___ ___ _____________ > / /| / /_ / ____/ ___/\ Nothing useful for > / / / / _ / / __/ / __\/ more than a decade > / /_/_/ \/ /_/_/ /_/ > {www.|raimi@} /______/__/\._\.____/\.____/\ .org > \._____\._\/\._\.___\/\.___\/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that > makes searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Qucs-devel mailing list > Qucs-devel@... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
|
From: Raimund 'Raimi' Jacob <raimi@lk...> - 2006-01-15 15:40:25
|
hey folks! Stefan told me that there is a problem with the qucsdigi script not being possible to be killed using the 'cancel' button of the simulation window. i spent some time playing around with the problem and found out this: Currently there is a QProcess::kill() that terminates the qucsdigi script. according the docs it might be better to use tryTerminate() first: http://doc.trolltech.com/qtopia1.7/html/qprocess.html#kill but there still is the problem that only the qucsdigi script itself is killed, not its children. this can be solved by not killing the process itself but the entire process group. this is easily done with kill(2) but i see no QT API for it. it would be possible to do that from the qucsdigi script itself. adding this at the beginning of qucsdigi: trap 'kill 0; exit 0' SIGINT SIGTERM would make it kill all children when it receives the INT or TERM signal (which is what QProcess::kill/tryTerminate should do). for this to work each invocation in the script would have to be changed: echo -n "Doing something ..." $something echo "done" to echo -n "Doing something ..." $something & wait $! echo "done" i still not fully understand why this is neccessary, but that might work. Want me to create a patch for this? Raimund -- ___ ___ _____________ / /| / /_ / ____/ ___/\ Nothing useful for / / / / _ / / __/ / __\/ more than a decade / /_/_/ \/ /_/_/ /_/ {www.|raimi@} /______/__/\._\.____/\.____/\ .org \._____\._\/\._\.___\/\.___\/ |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-11 13:59:08
|
hello all!
again a small status of how digital simulations will be performed
using qucs.
what has already been done:
1) freehdl better compiler compatibility and build system improved
2) some minor bugfixes in freehdl
3) qucs is able to run a digital simulation by:
- creating vhdl code
- translate and compile it using freehdl installation
- running the produced binary, this produces the output vcd file
4) qucs has new diagrams: truth-table and timing diagram
5) a vcd to qucs dataset converter
what may be necessary in future:
1) qucs dataset must be enhanced by binary values, like 'b001XZ10X'
so right now it seems we have all the pieces together. michael is
going to put them together to see the whole picture. i am quite confident
that it will be available in the upcoming release...
cheers, stefan.
|
|
From: Stefan Jahn <stefan@gr...> - 2006-01-11 13:04:32
|
On Mi, 11.01.2006, 13:25, Raimund 'Raimi' Jacob wrote: > hi! hello! >>>>looks like you were too tired to send the correct (solaris) logs... >>>> the >>>>remaining warinings for freebsd were expected. thanks a lot! >>> >>>ok, find the new logs attached. i mixed up my files yesterday. turns out >>>that this solaris 2.9 machine is running 32-bit, too. doesnt work yet, >>>but i think the remaining problems are solvable. >> >> yup, probably it helps #include <alloca.h> ? > > yes, the following files miss that alloca.h: > > std/standard.cc > std/internal_textio.cc > std/vhdl_types.cc > kernel/main.cc ok. i am going to prepare a patch. > this worked out so far, but i failed here: > > v2cc.cc:51:20: getopt.h: No such file or directory > > ... i guess the configure script needs some improvement here. i stop for > now... can you check on the solaris system: 1. if getopt() is contained probably in 'libc' or in 'libiberty' 2. if there is a getopt() prototype in any header thanks in advance, stefan. |
|
From: Raimund 'Raimi' Jacob <raimi@lk...> - 2006-01-11 12:26:19
|
Stefan Jahn wrote:
hi!
>>>looks like you were too tired to send the correct (solaris) logs... the
>>>remaining warinings for freebsd were expected. thanks a lot!
>>
>>ok, find the new logs attached. i mixed up my files yesterday. turns out
>>that this solaris 2.9 machine is running 32-bit, too. doesnt work yet,
>>but i think the remaining problems are solvable.
>
> yup, probably it helps #include <alloca.h> ?
yes, the following files miss that alloca.h:
std/standard.cc
std/internal_textio.cc
std/vhdl_types.cc
kernel/main.cc
this worked out so far, but i failed here:
v2cc.cc:51:20: getopt.h: No such file or directory
... i guess the configure script needs some improvement here. i stop for
now...
Raimund
--
___ ___ _____________
/ /| / /_ / ____/ ___/\ Nothing useful for
/ / / / _ / / __/ / __\/ more than a decade
/ /_/_/ \/ /_/_/ /_/
{www.|raimi@} /______/__/\._\.____/\.____/\ .org
\._____\._\/\._\.___\/\.___\/
|
|
From: Stefan Jahn <stefan@gr...> - 2006-01-11 11:43:51
|
On Mi, 11.01.2006, 11:37, Raimund 'Raimi' Jacob wrote: > hi! hello! >> looks like you were too tired to send the correct (solaris) logs... the >> remaining warinings for freebsd were expected. thanks a lot! > > ok, find the new logs attached. i mixed up my files yesterday. turns out > that this solaris 2.9 machine is running 32-bit, too. doesnt work yet, > but i think the remaining problems are solvable. yup, probably it helps #include <alloca.h> ? cheers, stefan. |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-11 07:25:45
|
On Mi, 11.01.2006, 00:01, Raimund 'Raimi' Jacob wrote: > re! hi! >>>it's not in CVS but it's part of the distribution. isnt it generated by >>>configure? or autogen.sh (in maintainer-mode)? >> >> It's generated by autogen.sh (in maintainer-mode). It just means your >> auto??? is too old or something. The --run command line parameter works >> with my dist... > > i created those files with the auto*-1.4 versions. > > missing -> /usr/share/automake-1.4/missing > ./missing: Unknown `--run' option > > i think it happened again. see the attached logs from Solaris 2.9 (which > did not work) and the 64-Bit Freebsd (sorry about the silly file names). > > some warnings remain. looks like you were too tired to send the correct (solaris) logs... the remaining warinings for freebsd were expected. thanks a lot! cheers, stefan. |
|
From: Raimund 'Raimi' Jacob <raimi@lk...> - 2006-01-10 22:59:06
|
Stefan Jahn wrote:
re!
>>it's not in CVS but it's part of the distribution. isnt it generated by
>>configure? or autogen.sh (in maintainer-mode)?
>
> It's generated by autogen.sh (in maintainer-mode). It just means your
> auto??? is too old or something. The --run command line parameter works
> with my dist...
i created those files with the auto*-1.4 versions.
missing -> /usr/share/automake-1.4/missing
./missing: Unknown `--run' option
i think it happened again. see the attached logs from Solaris 2.9 (which
did not work) and the 64-Bit Freebsd (sorry about the silly file names).
some warnings remain.
Raimund (tired)
--
___ ___ _____________
/ /| / /_ / ____/ ___/\ Nothing useful for
/ / / / _ / / __/ / __\/ more than a decade
/ /_/_/ \/ /_/_/ /_/
{www.|raimi@} /______/__/\._\.____/\.____/\ .org
\._____\._\/\._\.___\/\.___\/
|
|
From: Stefan Jahn <stefan@gr...> - 2006-01-10 08:25:50
|
On So, 8.01.2006, 18:46, Raimund 'Raimi' Jacob wrote: > hi! hello! > freehdl-v2cc: ELF 64-bit LSB executable, AMD x86-64, version 1 > (FreeBSD), dynamically linked (uses shared libs), not stripped > > g++ (GCC) 3.4.4 [FreeBSD] 20050518 > > this one compiled, but both configure and gmake showed some warnings. i > attached the log files. i've send some patches which should fix most of the warnings. can retry and send the make logs, again? > the system itself is a proper 64 bit opteron. so it looks as if freehdl > is 64bit safe. however, i didnt run any code. > > i wanted to test a solaris compile as well, but guile doesnt work in my > uni. with the patches applied, no more guile is necessary :-) cheers, stefan. |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-09 10:27:24
|
On Mo, 9.01.2006, 11:22, Raimund 'Raimi' Jacob wrote: > hi! hello! >>>this one compiled, but both configure and gmake showed some warnings. i >>>attached the log files. >> >> is the "missing" file actually in the cvs or does it get copied by >> autogen.sh? > > it's not in CVS but it's part of the distribution. isnt it generated by > configure? or autogen.sh (in maintainer-mode)? It's generated by autogen.sh (in maintainer-mode). It just means your auto??? is too old or something. The --run command line parameter works with my dist... Cheers, Stefan. |
|
From: Raimund 'Raimi' Jacob <raimi@lk...> - 2006-01-09 10:22:37
|
Stefan Jahn wrote:
hi!
>>this one compiled, but both configure and gmake showed some warnings. i
>>attached the log files.
>
> is the "missing" file actually in the cvs or does it get copied by
> autogen.sh?
it's not in CVS but it's part of the distribution. isnt it generated by
configure? or autogen.sh (in maintainer-mode)?
Raimund
--
___ ___ _____________
/ /| / /_ / ____/ ___/\ Nothing useful for
/ / / / _ / / __/ / __\/ more than a decade
/ /_/_/ \/ /_/_/ /_/
{www.|raimi@} /______/__/\._\.____/\.____/\ .org
\._____\._\/\._\.___\/\.___\/
|
|
From: Stefan Jahn <stefan@gr...> - 2006-01-09 10:15:18
|
On So, 8.01.2006, 18:46, Raimund 'Raimi' Jacob wrote: > hi! hi! > this one compiled, but both configure and gmake showed some warnings. i > attached the log files. is the "missing" file actually in the cvs or does it get copied by autogen.sh? cheers, stefan. |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-09 08:48:23
|
On Mo, 9.01.2006, 09:18, Vincent wrote: > Stefan, Hello Vincent! >> I've just sent Raimund some patches which also incorporate changes to >> the QucsFilter program. I've built in the qf_* files sent in by >> Vincent. > >> The only thing missing is now a Qucs Schematic creation. >> >> Also I've some questions to Vincent: >> >> 1. It looks like there is a bug during the BANDPASS/BANDSTOP creation: >> the if (j==ncomp) break; condition does not work... >> 2. What's the exact meaning of the stopband frequency for bandpass/ >> bandstop? > > Verschiedene Dinge :) > > 1. I'm in the process of cleaning up the qf_poly file. It is also > undergoing a major change, in that "qf_poly" class shall now be only a > pointer to a struct polynom. That way, we spare the overhead of copying > polynoms when performing arithmetical operations, while preserving the > ease of notation. Some redundant variables have been wiped out. Can you sent the patch to me, please? > 2. I have begun, but not yet finished, the integration of "traditional" > Butterwoth and Chebychev filters into the new frame. Hm... > 3. I know there is a bug in bandstop design, that I had no time to > really chase out. For the bandpass, the parameters are : > > 1. The center frequency; > 2. The bandwith; > 3 and 4. A point in the stopband where the attenuation is known. > > E.g : let's synthesize a bandpass filter whose center frequency is 10,7 > MHz, bandwith 25 kHz and that rejects by more than 70 dB an image > frequency at 30 MHz. > > The bandstop specification is actually the same, but, for a reason that > I do not know, I can't really make it work that way (the bandwith is > always less than specified, though all other parameters work fine). Thanks for clarification! > I'll correct the erroneous condition. Thanks in advance, Stefan. |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-09 08:45:16
|
On So, 8.01.2006, 18:56, Raimund 'Raimi' Jacob wrote: > hi! hello! > as promised: qucs-core configures/compiles without a warning. here is > the platform identifier: > > x86_64-unknown-freebsd6.0 > g++ (GCC) 3.4.4 [FreeBSD] 20050518 > > i cannot compile qucs due to missing Qt stuff and time/priviledges to > install them on this host (i probably wont have access to it again). > > perhaps i should install debian on my Athlon64 (the other partition, > that is) ... Thanks a lot! I am going to add the line to the PLATFORMS file. Cheers, Stefan. |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-09 08:43:57
|
On So, 8.01.2006, 18:46, Raimund 'Raimi' Jacob wrote: > hi! hello! > stefan asked me to compile-test freehdl on some (64-bit) platforms. > > * here is the first one: > > target='powerpc64-unknown-linux-gnu' > target_alias='' > target_cpu='powerpc64' > target_os='linux-gnu' > target_vendor='unknown' > > freehdl-v2cc: ELF 32-bit MSB executable, PowerPC or cisco 4500, > version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared > libs), not stripped > > g++ (GCC) 4.0.2 (Debian 4.0.2-2) > > strange, this just just became a 32-bit executable. hm. perhaps this > isnt much of a 64bit system after all. however, it compiled like a > charm, just configure emitted this: > > ./configure: line 20811: WORDS_BIGENDIAN: command not found > > ...but guessed correctly that this is a bigendian system. hm... i'll look at this. > * and here the second one: > > target='x86_64-unknown-freebsd6.0' > target_alias='' > target_cpu='x86_64' > target_os='freebsd6.0' > target_vendor='unknown' > > freehdl-v2cc: ELF 64-bit LSB executable, AMD x86-64, version 1 > (FreeBSD), dynamically linked (uses shared libs), not stripped > > g++ (GCC) 3.4.4 [FreeBSD] 20050518 > > this one compiled, but both configure and gmake showed some warnings. i > attached the log files. > > the system itself is a proper 64 bit opteron. so it looks as if freehdl > is 64bit safe. however, i didnt run any code. > > i wanted to test a solaris compile as well, but guile doesnt work in my > uni. nice. thanks a lot! i've seen some pointer/integer warnings. i'll probably fix these. also i'll make it being compil'able without guile (actually not necessary). edwin: i just finished all the manpages. can you have a look at them? cheers, stefan. |
|
From: Vincent <10.50@fr...> - 2006-01-09 08:18:24
|
Stefan, > I've just sent Raimund some patches which also incorporate changes to > the QucsFilter program. I've built in the qf_* files sent in by Vincent. > The only thing missing is now a Qucs Schematic creation. > > Also I've some questions to Vincent: > > 1. It looks like there is a bug during the BANDPASS/BANDSTOP creation: > the if (j==ncomp) break; condition does not work... > 2. What's the exact meaning of the stopband frequency for bandpass/ > bandstop? Verschiedene Dinge :) 1. I'm in the process of cleaning up the qf_poly file. It is also undergoing a major change, in that "qf_poly" class shall now be only a pointer to a struct polynom. That way, we spare the overhead of copying polynoms when performing arithmetical operations, while preserving the ease of notation. Some redundant variables have been wiped out. 2. I have begun, but not yet finished, the integration of "traditional" Butterwoth and Chebychev filters into the new frame. 3. I know there is a bug in bandstop design, that I had no time to really chase out. For the bandpass, the parameters are : 1. The center frequency; 2. The bandwith; 3 and 4. A point in the stopband where the attenuation is known. E.g : let's synthesize a bandpass filter whose center frequency is 10,7 MHz, bandwith 25 kHz and that rejects by more than 70 dB an image frequency at 30 MHz. The bandstop specification is actually the same, but, for a reason that I do not know, I can't really make it work that way (the bandwith is always less than specified, though all other parameters work fine). I'll correct the erroneous condition. Cheers! Vincent |
|
From: Stefan Jahn <stefan@gr...> - 2006-01-09 08:07:40
|
Hi there!
I've just sent Raimund some patches which also incorporate changes to
the QucsFilter program. I've built in the qf_* files sent in by Vincent.
The only thing missing is now a Qucs Schematic creation.
Also I've some questions to Vincent:
1. It looks like there is a bug during the BANDPASS/BANDSTOP creation:
the if (j==ncomp) break; condition does not work...
2. What's the exact meaning of the stopband frequency for bandpass/
bandstop?
Cheers, Stefan.
|