Adventures in Kylix: Digging In

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. Click here for 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. ¹

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

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 (lLength>0) 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 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.

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

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

(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. <g>

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. Click here for a better way.

Version History:
2001-03-15:
Added warning from Mat Ballard

Part Two: Digging In

Contents