Hi, I wrote a simple console application with widgetype NoGui to test a connection to Firebird 2.5 on FreeBsd. When I run in the console, it hangs when the method TIBConnection.Connected := True is called (isc_attach_database). I don't get any error message, it just hangs until I press ctrl+c.

The conflict is between "interfaces" unit and FreeBSD on a headless machine (without graphical user interface).

Here's the program:

program test;
{$mode objfpc}{$H+}

uses
interfaces,
fpCGI,

  IBConnection;

{$R *.res}
var
  FIbConnection: TIBConnection;
  SQLTransaction1: TSQLTransaction;
begin
  FIbConnection := TIBConnection.Create(nil);
  SQLTransaction1 := TSQLTransaction.Create(nil);
  FIbConnection.Connected := False;
  FIbConnection.DatabaseName := 'test';
  FIbConnection.UserName := 'SYSDBA';
  FIbConnection.Password := 'masterkey';
  FIbConnection.HostName := '127.0.0.1';
  FIbConnection.LoginPrompt := False;
  writeln('--- Here the program freezes ---');
  FIbConnection.Connected := True;
  SQLTransaction1.Free;
  FIbConnection.Free;
end.

If I compile the program with "fpc test.pas" commenting out the interfaces unit, it works ok.

My setup is this:

Freebsd 8.2 - amd64 - without X.
Lazarus 0.9.31 - SVN Revision: 30780
FPC 2.5.1 - SVN Revision: 17494

Why use NoGui in this example?

Marcos Douglas

"Leonardo M. Ram?" hat am 18. Mai 2011 um 20:45
geschrieben:

Have you used lazbuild to compile the program?
I found a bug and fixed it. It might have caused, that you didn't use the nogui widgetset.
?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110518/4a3afd9f/attachment.html>

You should not need this unit for this pulls in the LCL when there is no need for this.

Michael.

This is a small example. I need the LCL because a "real" program needs TAChart.

Mattias, I use lazbuild.

What was the bug? did you commited it to svn?

[...] Mattias, I use lazbuild. What was the bug? did you commited it to svn?

Where else? ;)

Mattias

Sorry, I was asking because just after you answered, I did an svn update and recompiled the program. Sadly it didn't work, so I thought your changes weren't applied.

Anyway, the problem is still present.

Leonardo M. Ram? wrote

This is a small example. I need the LCL because a "real" program needs

"interfaces" allows for instantiating the "Application" Object (I suppose that is what Michael meant by"It pulls in the LCL"). There are many functions in the LCL that are usable without TApplication and "Interfaces".

What you can't do without "interfaces" is (1) use a local GUI (such as GTK or QT) and (2) do the usual "event driven programming" (e.g. use TTimer and anything based on "normal" inter-Thread notification).

So without "interfaces" your project is not an "Application" but a "Program" (AKA "command line tool") that is started, does its work, and stops; without waiting for anything to happen while it runs.

I suppose by "real Program" you mean "Application" (according to Lazarus-speak), so you can't use noGUI.

-Michael

No, my real program is a CGI app wich uses TAChart, wich doesn't link without interfaces unit.

Leonardo M. Ram? wrote

No, my real program is a CGI app wich uses TAChart, wich doesn't link without interfaces unit.

AFAIK, with Lazarus there is no way to do a CGI that is a decent "Application" providing real event driven programming. If same is somehow implicitly used within TAChart (what I cant comment), I suppose you are lost here.

You can do a normal Lazarus Application and have it run as a service (Windows) or daemon (Linux), and have your web-server (e.g. Apache) communicate with it via TCP/IP. Look up "FCGI" or "FastCGI" for this.

-Michael

Sorry, but you are wrong here. You easily can create a "CGI Application" with widgetset nogui. I have a couple of them running on headless Linux servers. The problem seems to be related to LCL on Freebsd.

No, of course a TTimer is a nonsense in a CGI.

Leonardo M. Ram? wrote

Sorry, but you are wrong here. You easily can create a "CGI Application" with widgetset nogui. I have a couple of them running on headless Linux servers.

Did you try to do a TTimer in such a CGI ?

-Michael

Leonardo M. Ram? wrote

No, of course a TTimer is a nonsense in a CGI.

Yep. That is why a "standard"l CGI is not an "Application" but a "command line tool" (runs just from start to end without waiting on anything) and is not done with event driven programming. OTOH, a FastCGI can live longer and can be able to wait on something and it can be appropriate to do it with event driven programming.

Now as said somehow implicitly within TAChart (what I cant comment on, as I don't know it),event driven programming or an external GUI framework might be used. This seems likely, as otherwise it would not request for the "interface" unit.

-Michael

Leonardo M. Ram? wrote

The conflict is between "interfaces" unit and FreeBSD on a headless machine (without graphical user interface).

There is an open bugreport for that.

http://bugs.freepascal.org/view.php?id=6259

I never looked into it, since I don't have firebird installs. IIRC the comment is a report of Ales testing.

If the IB headers have a way to statically link instead of using loadlibraries versions, try if that solves the problem.

TAChart mainly needs "Graphics" unit for things like TPen, TBrush and TFont. Unfortunately, using Graphics brings in the whole LCL. I still have plans to hack around that problem --
just did not have time to work on TAChart lately.
Maybe in a month or two, after the end of summer exams at the university.

Leonardo M. Ram? wrote

The conflict is between "interfaces" unit and FreeBSD on a headless machine (without graphical user interface).

Years ago when tiOPF Core still had GUI dependencies, I couldn't run a console based test suite without an X11 install. Your problem sounds similar. I think LCL (even the NoGUI widgetset) still pulls in GUI dependencies irrespective of the name they gave it.

TAChart needs to be refactored so as to have a non-GUI and GUI portion. This is the only true solution.

Years ago, I was able to run a program called "fake X11" (the name was something like that). This allowed be to run my test suite from years ago on a headless Linux server. Maybe that Fake X Server can run under FreeBSD as well.

I did a quick Google search, and I think the fake X Server application was called Xvfb

http://en.wikipedia.org/wiki/Xvfb

Hope that helps for now, but as I said, the actual problem lies with TAChart, than needs to be fixed.

No, the nogui widgetset does not pull in any GUI libs. For example lazbuild under linux:
linux-vdso.so.1
libc.so.6
/lib64/ld-linux-x86-64.so.2

Under OS X it uses iconv and carbon framework. This is not passed to the compiler as command line parameters, so it must be something in the OS X units.

I guess something similar happens on BSD.

Is there a tool to see what ppu drags what libraries? Maybe I will add this feature to the ppu list.

TAChart needs to be refactored so as to have a non-GUI and GUI portion. This is the only true solution.

A fpcanvas solution would be useful.

Mattias

Graeme Geldenhuys wrote

Hope that helps for now, but as I said, the actual problem lies with TAChart, than needs to be fixed.

I am still of the opinion that the actual problem lies in LCL design, which is being fixed, but slowly, since it involves FPC changes. So, as I said, there will be GUI-less TAChart version, but it will either be not soon or not pretty ;-)

Mattias Gaertner wrote

> TAChart needs to be refactored so as to have a non-GUI and GUI > portion. This is the only true solution. A fpcanvas solution would be useful.

TAChart already has FPCanvas back-end. See nogui demo for an example.

I think Mattias meant that if TAChart was based on fpcanvas alone, it would work without nogui, and would still work in all other LCL apps.

Michael.

Yes, but it would regress on features.
There are basically two options for TAChart now:
1) Wait until FPCanvas/FPPen/FPBrush/FPFont interface is exactly the same as LCL equivalents.
2) Introduce TAChart-specific classes for that.

Option 1 is architecturally better, but will require waiting for at least one FPC release, maybe longer. So I think I'll implement option 2.

iconv is integrated in glibc on Linux. (since both are GNU).

On BSDs iconv is a separate lib.

Another such case on Linux dynamic linking is in libdl, while in most BSDs it is in libc.

Haiku has own names for nearly everything, and solaris generally is the same as Linux in these matters.

Is there a tool to see what ppu drags what libraries?

iconvenc and/or widestring manager. Most likely both.

Thanks, adding cthreads fixed the IBConnection issue.

(I still have the problem of TAChart-LCL dependencies).

What is still missing ?

If you expect to see the Color property as it is in the LCL, that will not happen. But using TFPColor as in fpCanvas should work in the LCL as well.

Michael.

I compiled nogui demo on FreeBSD and I got this, on my Linux machine it works (but I have X installed):

[FORMS.PP] ExceptionOccurred
Sender=FreeTypeException
Exception=Error 10 while making string bitmaps step 4 Stack trace:
$0000000000790283
$0000000000790308
$0000000000791EA7
$000000000079268D
$000000000078FD15
$000000000078F9BB
$000000000044A56F
$0000000000449116
$0000000000459302 line 275 of ../../tadrawerfpcanvas.pas $000000000045ADE3 line 344 of ../../tadrawutils.pas $0000000000659C99 line 634 of ../../tatypes.pas
$00000000006575A9 line 666 of ../../tachartaxis.pas $000000000065725D line 689 of ../../tachartaxis.pas $000000000065827C line 915 of ../../tachartaxis.pas $0000000000452660 line 1052 of ../../tagraph.pas
$0000000000450C69 line 711 of ../../tagraph.pas
TApplication.HandleException Error 10 while making string bitmaps step 4 Stack trace:
$0000000000790283
$0000000000790308
$0000000000791EA7
$000000000079268D
$000000000078FD15
$000000000078F9BB
$000000000044A56F
$0000000000449116
$0000000000459302 line 275 of ../../tadrawerfpcanvas.pas $000000000045ADE3 line 344 of ../../tadrawutils.pas $0000000000659C99 line 634 of ../../tatypes.pas
$00000000006575A9 line 666 of ../../tachartaxis.pas $000000000065725D line 689 of ../../tachartaxis.pas $000000000065827C line 915 of ../../tachartaxis.pas $0000000000452660 line 1052 of ../../tagraph.pas
$0000000000450C69 line 711 of ../../tagraph.pas
exception at 0000000000790283:
Error 10 while making string bitmaps step 4.

Yes. That would be useful.

Of course only if this does not make the code
unreadable and does not increase the maintenance burden too much.

Mattias

Maybe the freetype unit works different under BSD?

Mattias

You can easily check yourself by comparing FPCanvas and Graphics source. In particular,
TFPCustomPen misses Cosmetic, EndCap and JoinStyle propertues, TFPCustomBrush is ok except for Color, and
TFPCustomFont misses CharSet, Pitch, Quality and Style, and overrides Name and Size which may lead to subtle bugs.

If you expect to see the Color property as it is in the LCL, that will not happen.

Why? It is only a few lines of code.

But using TFPColor as in fpCanvas should work in the LCL as well.

Except it will not work with Object Inspector and is stylistically incompatible with quite large base of Delphi/Lazarus graphics application.

Lack of Color will force me to create TChart-specific versions of pen/brush/font despite all the other work you have done.

Alexander Klenin wrote

On Mon, May 23, 2011 at 00:47, Michael Van Canneyt Lack of Color will force me to create TChart-specific versions of pen/brush/font despite all the other work you have done.

After finishing my morning cofee, I realized that TChart will need those versions anyway
for published properties.
So I retract the quoted statement above.

Or maybe you want to change the font name from 'Arial'. Is there a cross-platform name for "default sans-serif" font in FreeType?

[...] > If you expect to see the Color property as it is in the LCL, that will not > happen. Why? It is only a few lines of code.

It is not that simple. TColor supports some special color constants like clBtnFace. This makes only sense in the LCL.

> But using TFPColor as in fpCanvas should work in the LCL as well. Except it will not work with Object Inspector and is stylistically incompatible with quite large base of Delphi/Lazarus graphics application.

The OI has no problem with TFPColor. Just write a property editor. But TFPColor does not support the LCL TColor constants, so we can not simply replace "Color" with "FPColor".

Lack of Color will force me to create TChart-specific versions of pen/brush/font despite all the other work you have done.

Mattias

I know, and I have already suggested to write virtual getter and setter and ignore those constants in the basic version.

The PPU list of package Cody now shows the linked files, libraries and frameworks of a project.
Can someone test it on BSD?

http://wiki.lazarus.freepascal.org/Cody#Linked_Files

Mattias

Alexander Klenin wrote

Or maybe you want to change the font name from 'Arial'. Is there a cross-platform name for "default sans-serif" font in FreeType?

'Liberation Sans' and all other Liberation style fonts are metric compatible with Arial. It is included as standard in all new Linux distros as far as I know.

I have no idea about any of the BSD's though.

http://en.wikipedia.org/wiki/Liberation_fonts

Regards,
- Graeme -

How do you know the problem is because FreeType is not finding the Arial font?. I don't see anything related in the error message.

Just a guess.

But it is absent on Windows, so no better than Arial as a cross-platform font

Alexander Klenin wrote

But it is absent on Windows, so no better than Arial as a cross-platform font

It's free, so deploy it with your application, or use Arial under Windows and Liberation under Linux/*BSD etc. As the wiki site says, they are metric compatible so look pretty much identical.

I guess this is where LCL fails miserably. For example, in fpGUI I have "font descriptions" (aka Font Aliases) just like I have "color aliases". By the latter I mean colors like clButtonFace, clWindow etc.. They are numbers to LCL, but depending on the OS and theme, they mean some platform/theme RGB like that, fpGUI uses font
descriptions/aliases: eg: #Edit1, #Label1, #Grid etc.. In the case of fpGUI #Edit1 can mean different fonts and styles depending on the OS or theme being used. Currently under Windows '#Edit1' means 'Arial-8' and under Linux it means 'Liberation Sans-10'

So form a developer point of view, when I want to set a font I use #Edit1 instead of a font name - thus giving be a cross-platform way of working with fonts.

Regards,
- Graeme -

Of course the LCL fails here, because it is not used here, but the freetype unit.

Graeme, it is ok to promote your fpgui, but this kind of bashing makes fpgui looking as developed by trolls. fpgui deserves better.

Mattias

Mattias Gaertner wrote

Of course the LCL fails here, because it is not used here, but the freetype unit.

I did not mean it as trolling, but rather as an idea for improved cross-platform support. I believe I mentioned this font issue with Lazarus some years ago, when we still used LCL in our applications (around v0.9.18 I think). Nothing about this problem has since been changed.

LCL does not warn the developer that if they pick a font in the Form Designer (say under Windows), that that font will probably not exist under Linux or Mac or FreeBSD. So that part of LCL is really not cross-platform at all! Luckily freetype will try and pick a similar alternative font - but with no guarantees that it will look good.

I was simply suggesting a solution - using what I have done in fpGUI as an example of one such solution. I did not mean it any other way.

LCL is developed and promoted as a cross-platform framework, so surely that should translate to the Font usage too?

Regards,
- Graeme -

Alternatively this issue should be listed in the "Things that will never be fixed" wiki page? And the usual Object Inspector hint regarding the Font property limitation.

http://wiki.lazarus.freepascal.org/Lazarus_known_issues_%28things_that_will_never_be_fixed%29

Regards,
- Graeme -

How about:
http:/msg07707.html

?
:)
L.

While what you say may be a good idea,
note that the discussion you responded to was about the failure when trying to NOT use the LCL, so your implication of "LCL fails here" is misplaced.

Alexander Klenin wrote

note that the discussion you responded to was about the failure when trying to NOT use the LCL, so your implication of "LCL fails here" is misplaced.

Well, I was responding to you comment about the Liberation font not being available in Windows.

Regards,
- Graeme -