Re: New release of Electric (6.05)

[Tuukka Toivonen]

On Thu, 21 Feb 2002, Steven Rubin wrote:

> > An optional interface to the Qt window system (written by Dmitry Nadezhin).

I didn't get it working. Maybe I have wrong version of Qt library (I'm
using Debian Woody package libqt2 version 3:2.3.1-19 and libqt2-dev version
1:2.0.2-1.1). I think different versions of Qt are not compatible, so one
probably should mention which version of Qt is required (I couldn't find
that info). [Then again I could advocate that there's much less version
incompatibilities with Motif :)]

Here are the error messages I got:

g++ -O2 -DUSEQT -I/usr/lib/qt2/include   -Isrc/include -DFORCELISP=1
-Isrc/elk -DFORCETCL=1 -Isrc/tcl/generic  -DFORCEIRSIMTOOL    -c
src/db/dblang.c -o src/db/dblang.o
src/db/dblang.c: In function `bool languageconverse(long int)':
src/db/dblang.c:396: passing `const char *' as argument 2 of
`Tcl_GetVar(Tcl_Interp *, char *, int)' discards qualifiers
make: *** [src/db/dblang.o] Error 1

...so I first removed TCL support and tried compiling again (make
clean;make)

gcc -O2 -DUSEQT -I/usr/lib/qt2/include   -Isrc/include -DFORCELISP=1
-Isrc/elk   -DFORCEIRSIMTOOL    -DUSETIF -DANYDEPTH  -I/usr/lib/qt2/include
-c src/graph/graphqt.cpp -o src/graph/graphqt.o
src/graph/graphqt.cpp: In method `EApplication::EApplication(int &, char
**)':
/usr/lib/qt2/include/qfontdatabase.h:57: `QFontDatabase::QFontDatabase()'
is private
src/graph/graphqt.cpp:830: within this context
/usr/lib/qt2/include/qfontdatabase.h:59: `const class QStringList &
QFontDatabase::families(bool = 1) const' is private
src/graph/graphqt.cpp:831: within this context
src/graph/graphqt.cpp: In method
`MessagesMainWindow::MessagesMainWindow()':
src/graph/graphqt.cpp:940: `NoWrap' is not a member of type
`QMultiLineEdit'
src/graph/graphqt.cpp: In method `GraphicsDraw::GraphicsDraw(QWidget *)':
src/graph/graphqt.cpp:1658: `WRepaintNoErase' undeclared (first use this
function)
src/graph/graphqt.cpp:1658: (Each undeclared identifier is reported only
once
src/graph/graphqt.cpp:1658: for each function it appears in.)
src/graph/graphqt.cpp: In method `bool GraphicsDraw::event(QEvent *)':
src/graph/graphqt.cpp:1665: `AccelOverride' is not a member of type
`QEvent'
src/graph/graphqt.cpp: In function `char * fileselect(char *, long int,
char *)':
src/graph/graphqt.cpp:3256: no matching function for call to
`QFileDialog::getOpenFileName (const QString &, QString &, QWidget *&,
const char[14], QString &)'
/usr/lib/qt2/include/qfiledialog.h:159: candidates are: static class
QString QFileDialog::getOpenFileName(const QString & = QString::null, const
QString & = QString::null, QWidget * = 0, const char * = 0)
src/graph/graphqt.cpp:3265: no matching function for call to
`QFileDialog::getSaveFileName (QString &, QString &, QWidget *&, const
char[14], QString &)'
/usr/lib/qt2/include/qfiledialog.h:162: candidates are: static class
QString QFileDialog::getSaveFileName(const QString & = QString::null, const
QString & = QString::null, QWidget * = 0, const char * = 0)
make: *** [src/graph/graphqt.o] Error 1

...and then I gave up and selected Motif instead. Now it compiled, but the
linker gave the following warnings:

src/tcl/unix/tclUnixPipe.o: In function `TclpCreateTempFile':
src/tcl/unix/tclUnixPipe.o(.text+0xd4): the use of `tmpnam' is dangerous,
better use `mkstemp'
src/graph/graphunixx11.o: In function `emaketemp':
src/graph/graphunixx11.o(.text+0x8e36): the use of `mktemp' is dangerous,
better use `mkstemp'

man mktemp says:

BUGS
       Never use mktemp(). Some implementations  follow  BSD  4.3
       and  replace XXXXXX by the current process id and a single
       letter,  so  that  at  most  26  different  names  can  be
       returned.   Since  on  the  one hand the names are easy to
       guess, and on the other hand there is a race between test­
       ing  whether  the  name exists and opening the file, every
       use of mktemp() is a security risk.  The race  is  avoided
       by mkstemp(3).

> > A foreign language interface (with a French version of Electric

I can not understand why anybody would want to use any other language than
English. The more languages, the more difficult place this world is to live
in ;) Anyway, Electric developers of course can not do anything about it.

>Happy designing!

Thanks! I'm not so much anymore using Electric since it is customary to
write VHDL by hand. Anyway, Electric is great even for drawing
non-functional illustrations of hardware designs. If the VHDL generator
could generate something like
        x : std_logic_vector(10 downto 0);
instead of
        x_10_,x_9_,x_8_,...x_0_ : bit;
Electric would be much more useful for automatically generating VHDL.