Title: Adventures in Kylix, Part II
Question: Dinking around with Kylix...
Answer:
Adventures in Kylix
Part Two: Digging In
Dinking around:
Setting up editor properties, I see the Code Insight Delay setting goes
down to 0.1 seconds, instead of 0.5 seconds. I like the "instant" pop-up.
The pop-ups narrow themselves down intelligently as one types. This is
very
convenient.
Dropping some database components on the form, I can easily hook up
to the Interbase database that is hosted on my Linux box (using the Firebird
server). I'll have to play with this a little more. Attaching a TDBGrid
to the data source complains about the fact that the data set is unidirectional.
I'll play with the database stuff a little later.
Interesting columns for the tree view. Nice, actually.
Whoah! There are a lot of border styles. The default is "bsSunken3d"
bsDouble
bsEmbossed
bsEtched
bsNone
bsRaised3d
bsRaisedPanel
bsSingle
bsSunken3d
bsSunkenPanel
One thing that I do like is that each of the windows in the IDE
show up in the window list on the main GNOME panel (the "task bar"). It's
a small thing, but I like it.
HEY!!! THERE'S A FPU VIEWER!!!
This may not be big news to many people, but I have some hand-tuned
FPU code that's been difficult to debug without the viewer. We have a certain
routine that's a bottleneck as it solves a nastly non-linear curve fit.
I'll be able to break out the code and try again. I'll be able to debug
the code in an instant with the FPU viewer.
Anyhow, enough screwing around.
Fire up VMWare, copy a project to Linux. This project contains a bunch
of core utilities, which will be a great non-visual test for Kylix.
I know that I can't directly compile this project since it uses the
Interbase controls, but I'll try building it up from the non-GUI level.
I have a huge file of "utility" functions that I commonly use. I included
this one first. First of all, the "uses" clause needs tweaking. Note that
CLX has a "Q" in front of the GUI units, indicating they're built on the
Qt libraries.
Also note the new symbol "Linux" is defined in Kylix.
[Post-editing note: The following is an example of how to not
differentiate bewteen Linux and Windows. See part III a better way.]
uses
SysUtils,
{$ifdef Linux}
Types,
QForms,
QControls,
QGraphics,
{$else}
Windows,
Forms,
Controls,
Graphics,
{$endif}
Classes;
and
uses
{$ifdef Linux}
Variants,
{$endif}
Math;
I moved the Windows-specific routines to their own file.
I moved system routines to their own file.
One interestng thing is that when I type in the name of a libc function
(libc is the "standard" library of system functions), the normal Kylix
help page does not pop up, but a new window with the Linux "man" pages.
This is kind of nice, though it took me a little searching to figure out
that I had to "use Libc" to get access to these functions.
Ahhh... having access to libc! The feeling of raw POWER! OK. Calm down.
Check this out. Under Linux, to get the name of a machine, you call
uname
and pass in a structure. The nodename field contains the name of
the machine. This is how it's done in Kylix. 1
function ComputerName :string;
{$ifdef Linux}
var
uts :utsname;
begin
uname(uts);
Result := uts.nodename;
{$else}
var
Len :Cardinal;
begin
Len := MAX_COMPUTERNAME_LENGTH;
SetLength( Result, Len+1 );
if GetComputerName( @Result[1], Len ) then
SetLength( Result, Len )
else
Result := '';
{$endif}
end;
Note that it's much cleaner than the Win32 code.
And here we pull up the name of the username underwhich the program
is executing. All users have a number associated with them, their "uid"
(user ID), as well as a group numer, their "gid" (group ID). It's
possible to launch a program using another user's identity. This is called
the "effective" user ID. The libc call geteuid returns the effective
uid. getuid returns the real uid. 1
function UserName;
{$ifdef Linux}
var
pwr :PPasswordRecord;
begin
pwr := getpwuid(geteuid);
Result := pwr^.pw_name;
{$else}
var
lLength :DWORD;
begin
lLength := 1024;
SetLength( Result, lLength );
if GetUserName( PChar(Result), lLength ) and (lLength0)
then
SetLength( Result, lLength-1 ); // Hack off
trailing #0
{$endif}
end;
Again, the libc (Linux) version is much cleaner than in Win32.
One thing to note: Everything else compiled fine!
I tried running the little program from the command line, and I ran
across one little thing that'll bite you. The Qt libraries that Kylix uses
need to be added to the library loader path. There are two ways one might
do this.
I opted to edit /etc/ld.so.config, add the path /opt/kylix/bin, and ran
ldconfig
to update the loader cache.
Note:
I got an e-mail from Mat Ballard with the following:
i did this one on Mandrake 7.2, FT3, and it nuked KDE. turned out some
library in /opt/kylix/bin was being loaded in preference to the existing
library the Mandrake installed. had to remove /opt/kylix/bin from
ld.so.config, re-run ldconfig, and all was well.
not sure if this was addressed by the FT4 and product patches.
Looks like a Qt library conflict. I don't run KDE, so I can't comment on this behaviour.
The other method is to set the LD_LIBRARY_PATH environment variable. This
can be done on a per-user level in the .bashrc file, or globally in the
/etc/bashrc file. If you have a lot of machines to administer, you're probably
using something like NIS already to synchronize system files across machines.
You can use something like this to synch /etc/bashrc across machines, for
example.
Started pulling in more files. I'm can't figure out the replacement for
OutputDebugString so I can see progress on unit tests in the Event Log
window. Posted a message to the Borland news groups. Gotta take my wife
to the doctor, so hopefully an answer will show up while I'm gone.
OK, we're back. It turns out that there is no direct Linux equivalent
of OutputDebugString, so the event log window can't be used for the same
type of thing that it can in Windows. It's a minor inconvenience. I created
a small function to spit out debug messages to syslogd (the system log
daemon), thus:
In the exchange on the ng, I responded with the following:
Writeln(ErrOutput, 'Heeeeeeeeeeeeeeeeeeeeelp!');
Does Kylix have any means to output to the syslog?
Yep. Though it's a small shame that there's no way to output directly
to the
Event Log window, I can certainly live with syslogd. Actually I kind
of like
being "forced" to use syslogd because it's so flexible. One can customize
what
is sent where.
I made the following little procedure to make my code OS-neutral. Any
better
suggestions welcome. It's not super graceful, but gets the job done.
procedure DebugLog( const aMessage :string );
begin
{$ifdef Linux}
syslog( LOG_INFO or LOG_USER, PChar(aMessage) );
{$else}
OutputDebugString( PChar(aMessage) );
{$endif}
end;
In a shell window I do the following:
sudo tail -f /var/log/messages
et viola`! Instant Event Log messaging... after a manner of speaking.
(I have to get "C" out of my head when programming Linux now.
I instinctively wrote "LOG_INFO | LOG_USER". grrrr...)
I responded to a number of questions in the ngs. Some good information
is popping up, which I'm saving off for safe keeping.
Regression testing on another core library passed with flying colours.
1 The code is an example of how to not differentiate
bewteen Linux and Windows. See part III for a better way.
Version History:
2001-03-15:
Added warning from Mat Ballard
Copyright 2001 James
R. Knowles