Re: [fpc-devel] googleapiconv issues

[Michael Van Canneyt via fpc-devel]

On Thu, 5 Jan 2023, Wayne Sherman via fpc-devel wrote:


The google api binding generator "googleapiconv" is generating empty
files for the api pascal bindings and it also causes access violations
randomly.  I have not found the issue with AVs yet, but I found out
why it is creating empty source code files.

restcodegen.pp TRestCodeGenerator was refactored in 2018 to use pascodegen:
   - TRestCodeGenerator = Class(TComponent)
   + TRestCodeGenerator = Class(TPascalCodeGenerator)

ref:  
https://gitlab.com/freepascal.org/fpc/source/-/commit/d7fa0b19988f753873f498b9424dcf82ba1b271e#b4a1b63d04b721fa6db35bc226d44a63a21fda40

Before the refactoring, TRestCodeGenerator.SaveToStream used to call
"Execute;" if the source code string list was empty:
   procedure TRestCodeGenerator.SaveToStream(const AStream : TStream);
   begin
 if (FSource.Count=0) then
   Execute;
 FSource.SaveToStream(AStream)
   end;

ref:  
https://gitlab.com/freepascal.org/fpc/source/-/blob/0eddef3d093c53fca0526b7bc558ffeef42a79df/packages/fcl-web/src/base/restcodegen.pp#L186

Now "Execute;" is not being called and no code is generated because
pascodegen.pp "TPascalCodeGenerator.SaveToStream" looks like this:
   procedure TPascalCodeGenerator.SaveToStream(const AStream : TStream);
   begin
 FSource.SaveToStream(AStream)
   end;

ref:  
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fcl-base/src/pascodegen.pp#L255

Two options to fix this are:
1)  Add the "FSource" check and "Execute;" statements to
TPascalCodeGenerator.SaveToStream
 or
2) Add "Execute;" to TGoogleAPIConverter.DoConversion
(googleapiconv.pp) before it calls "SaveToStream" here:
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/googleapi/generator/googleapiconv.pp#L575


The latter. I must have missed the above when refactoring :/



Question:  Do you prefer I discuss issues like this here on the
mailing list or instead open a bug report and discuss in the bug
report?


Both are fine for me.

But maybe it makes more sense to use a bugreport, 
since that's where eventually a patch/merge request will have to end up ?


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] googleapiconv issues

[Wayne Sherman via fpc-devel]

The google api binding generator "googleapiconv" is generating empty
files for the api pascal bindings and it also causes access violations
randomly.  I have not found the issue with AVs yet, but I found out
why it is creating empty source code files.

restcodegen.pp TRestCodeGenerator was refactored in 2018 to use pascodegen:
- TRestCodeGenerator = Class(TComponent)
+ TRestCodeGenerator = Class(TPascalCodeGenerator)

ref:  
https://gitlab.com/freepascal.org/fpc/source/-/commit/d7fa0b19988f753873f498b9424dcf82ba1b271e#b4a1b63d04b721fa6db35bc226d44a63a21fda40

Before the refactoring, TRestCodeGenerator.SaveToStream used to call
"Execute;" if the source code string list was empty:
procedure TRestCodeGenerator.SaveToStream(const AStream : TStream);
begin
  if (FSource.Count=0) then
Execute;
  FSource.SaveToStream(AStream)
end;

ref:  
https://gitlab.com/freepascal.org/fpc/source/-/blob/0eddef3d093c53fca0526b7bc558ffeef42a79df/packages/fcl-web/src/base/restcodegen.pp#L186

Now "Execute;" is not being called and no code is generated because
pascodegen.pp "TPascalCodeGenerator.SaveToStream" looks like this:
procedure TPascalCodeGenerator.SaveToStream(const AStream : TStream);
begin
  FSource.SaveToStream(AStream)
end;

ref:  
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fcl-base/src/pascodegen.pp#L255

Two options to fix this are:
1)  Add the "FSource" check and "Execute;" statements to
TPascalCodeGenerator.SaveToStream
  or
2) Add "Execute;" to TGoogleAPIConverter.DoConversion
(googleapiconv.pp) before it calls "SaveToStream" here:
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/googleapi/generator/googleapiconv.pp#L575

Question:  Do you prefer I discuss issues like this here on the
mailing list or instead open a bug report and discuss in the bug
report?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 11.11.2015 17:47, Michael Van Canneyt wrote:

I have several remarks:

a) Your TBaseSingleInstance class contains too many methods.
   It assumes you are using advancedipc.


I refactored TBaseSingleInstance so that it doesn't depend on advancedipc.


   I suggest refactoring such a way that advancedipc is in the 
implementation section of the class.


This is unfortunately not possible now because there are no interfaces 
(nor abstract classes) for TIPCServer and TIPCClient.
IMO this is not a problem, if you don't want singleinstance.pp to be 
dependent on advancedipc.pp at all, TAdvancedSingleInstance can be 
easily moved into another unit - e.g. "advancedsingleinstance.pp". 
CustApp.pp will need to use "advancedsingleinstance.pp" in 
implementation section then.


If you want to have abstract classes for TIPCServer and TIPCClient, 
advancedipc.pp would need a bigger refactoring. Adding interfaces for 
them seems to be a simpler and better solution for me. - But as I said 
before, IMO neither interfaces nor abstract classes are needed for now.

TBaseSingleInstance already introduces the bare minimum of methods needed.

   or introduce TAbstractSingleInstance as a parent of 
TBaseSingleInstance with the bare minimum of methods/properties.


TBaseSingleInstance is now such "TAbstractSingleInstance". You can 
rename it to TAbstractSingleInstance if you like.



b) There is no way to have TCustomApplication create a different 
singleinstance class, for 2 reasons:

  1. Your property is declared as TCustomSingleInstance.
 It should be TBaseSingleInstance (or TAbstractSingleInstance)
 That means that the 'enabled' property should be in 
TBaseSingleInstance or TAbstractSingleInstance.


The Enabled property doesn't belong into TBaseSingleInstance - it has a 
meaning only in TCustomApplication. I solved it by introducing 
SingleInstanceEnabled in TCustomApplication.



  2. You create the instance as TCustomSingleInstance.Create in the 
constructor.
 It should be a function CreateSingleinstance : 
TCustomSingleInstance;


I solved it by introducing SingleInstanceClass. IMO it's better because 
SingleInstanceClass can be easily changed without the need to create a 
new TCustomApplication descendant and override a virtual function.


Feel free to comment on my changes.

BTW, there are some compiler hints/warnings in CustApp.pp. At least the 
one warning should be solved, IMO:


Compile Project, Target: sitest.exe: Success, Warnings: 1, Hints: 8
custapp.pp(175,6) Note: Local variable "l" is assigned but never used
custapp.pp(57,21) Hint: Parameter "EventType" not used
custapp.pp(57,51) Hint: Parameter "Msg" not used
custapp.pp(391,25) Hint: Local variable "B" does not seem to be initialized
custapp.pp(408,29) Warning: Local variable "I" does not seem to be 
initialized

custapp.pp(408,27) Hint: Local variable "B" does not seem to be initialized
custapp.pp(453,30) Hint: Local variable "B" does not seem to be initialized
custapp.pp(502,31) Hint: Local variable "B" does not seem to be initialized
custapp.pp(524,8) Note: Local variable "SO" is assigned but never used

Ondrej
Index: packages/fcl-base/examples/sitest.pp
===
--- packages/fcl-base/examples/sitest.pp(revision 32548)
+++ packages/fcl-base/examples/sitest.pp(working copy)
@@ -40,7 +40,7 @@
 WriteLn('Sending response to client.');
 xStringStream := TStringStream.Create('my response');
 try
-  Sender.ServerPostCustomResponse(MsgID, MsgType_Response, xStringStream);
+  (Sender as TAdvancedSingleInstance).ServerPostCustomResponse(MsgID, 
MsgType_Response, xStringStream);
 finally
   xStringStream.Free;
 end;
@@ -66,9 +66,9 @@
 begin
   xApp := TMyCustomApplication.Create(nil);
   try
-xApp.SingleInstance.Enabled := True;
+xApp.SingleInstanceEnabled := True;
 xApp.SingleInstance.OnServerReceivedParams := @xApp.ServerReceivedParams;
-xApp.SingleInstance.OnServerReceivedCustomRequest := 
@xApp.ServerReceivedCustomRequest;
+(xApp.SingleInstance as 
TAdvancedSingleInstance).OnServerReceivedCustomRequest := 
@xApp.ServerReceivedCustomRequest;
 xApp.Initialize;
 Writeln(xApp.SingleInstance.StartResult);
 xApp.Run;
@@ -79,15 +79,15 @@
   begin
 xStream := TStringStream.Create('hello');
 try
-  
xApp.SingleInstance.ClientSendCustomRequest(MsgType_Request_No_Response, 
xStream);
+  (xApp.SingleInstance as 
TAdvancedSingleInstance).ClientSendCustomRequest(MsgType_Request_No_Response, 
xStream);
 finally
   xStream.Free;
 end;
 xStream := TStringStream.Create('I want a response');
 try
-  
xApp.SingleInstance.ClientSendCustomRequest(MsgType_Request_With_Response, 
xStream);
+  (xApp.SingleInstance as 
TAdvancedSingleInstance).ClientSendCustomRequest(MsgType_Request_With_Response, 
xStream);
   xStream.Size := 0;
-  

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 12:52, Michael Van Canneyt wrote:
Juha, if you want to implement the single IDE instance, then I would 
like to ask you to implement this in custapp.pp. This is useful 
functionality for all kinds of applications, and is since very long on 
my todo list.


On 30.09.2015 18:50, Ondrej Pokorny wrote:

On 29.09.2015 22:47, Michael Van Canneyt wrote:

Let's first see how Ondrej does it.


See the patch attached. A simple demo program is attached as well 
(SITest.lpr).


Hello Michael,

you asked for implementing "single instance" in custapp.pp. I did it and 
sent a patch on Sept 28th. Did you have the time to check it and find 
eventual issues?


I am resending the patch against current trunk and a testing application.

Ondrej
Index: packages/fcl-base/src/custapp.pp
===
--- packages/fcl-base/src/custapp.pp(revision 32284)
+++ packages/fcl-base/src/custapp.pp(working copy)
@@ -18,12 +18,15 @@
 
 Interface
 
-uses SysUtils,Classes;
+uses SysUtils,Classes,singleinstance;
 
 Type
   TExceptionEvent = Procedure (Sender : TObject; E : Exception) Of Object;
   TEventLogTypes = Set of TEventType;
 
+  TCustomApplication = Class;
+  TCustomSingleInstance = Class;
+
   { TCustomApplication }
 
   TCustomApplication = Class(TComponent)
@@ -30,6 +33,7 @@
   Private
 FEventLogFilter: TEventLogTypes;
 FOnException: TExceptionEvent;
+FSingleInstance: TCustomSingleInstance;
 FTerminated : Boolean;
 FHelpFile,
 FTitle : String;
@@ -86,8 +90,17 @@
 Property CaseSensitiveOptions : Boolean Read FCaseSensitiveOptions Write 
FCaseSensitiveOptions;
 Property StopOnException : Boolean Read FStopOnException Write 
FStopOnException;
 Property EventLogFilter : TEventLogTypes Read FEventLogFilter Write 
FEventLogFilter;
+Property SingleInstance: TCustomSingleInstance read FSingleInstance;
   end;
 
+  TCustomSingleInstance = class(TBaseSingleInstance)
+  private
+FEnabled: Boolean;
+  public
+//you must set Enabled before CustomApplication.Initialize
+property Enabled: Boolean read FEnabled write FEnabled;
+  end;
+
 var CustomApplication : TCustomApplication = nil;
 
 Implementation
@@ -228,7 +241,10 @@
 
 procedure TCustomApplication.DoRun;
 begin
-  // Do nothing. Override in descendent classes.
+  if FSingleInstance.IsServer then
+FSingleInstance.ServerCheckMessages;
+
+  // Override in descendent classes.
 end;
 
 procedure TCustomApplication.DoLog(EventType: TEventType; const Msg: String);
@@ -250,6 +266,7 @@
   FOptionChar:='-';
   FCaseSensitiveOptions:=True;
   FStopOnException:=False;
+  FSingleInstance := TCustomSingleInstance.Create(Self);
 end;
 
 destructor TCustomApplication.Destroy;
@@ -276,6 +293,18 @@
 procedure TCustomApplication.Initialize;
 begin
   FTerminated:=False;
+  if FSingleInstance.Enabled then
+  begin
+case FSingleInstance.Start of
+  siClient:
+  begin
+FSingleInstance.ClientPostParams;
+FTerminated:=True;
+  end;
+  siNotResponding:
+FTerminated:=True;
+end;
+  end;
 end;
 
 procedure TCustomApplication.Run;
@@ -442,11 +471,11 @@
   end;
 
   Procedure AddToResult(Const Msg : string);
-  
+
   begin
 If (Result<>'') then
   Result:=Result+sLineBreak;
-Result:=Result+Msg;  
+Result:=Result+Msg;
   end;
 
 begin
program SITest;

{$mode objfpc}
{$h+}

uses
  Classes,
  CustApp, advancedipc, singleinstance;

type
  TMyCustomApplication = class(TCustomApplication)
  private
procedure ServerReceivedParams(Sender: TBaseSingleInstance; aParams: 
TStringList);
procedure ServerReceivedCustomRequest(Sender: TBaseSingleInstance; 
{%H-}MsgID: Integer; aMsgType: TMessageType; MsgData: TStream);
  end;

const
  MsgType_Request_No_Response = 1;
  MsgType_Request_With_Response = 2;
  MsgType_Response = 3;

{ TMyCustomApplication }

procedure TMyCustomApplication.ServerReceivedCustomRequest(
  Sender: TBaseSingleInstance; MsgID: Integer; aMsgType: TMessageType;
  MsgData: TStream);
var
  xData: string;
  xStringStream: TStringStream;
begin
  MsgData.Position := 0;
  SetLength(xData, MsgData.Size div SizeOf(Char));
  if MsgData.Size > 0 then
MsgData.ReadBuffer(xData[1], MsgData.Size);

  WriteLn('Request: ', xData);

  if aMsgType = MsgType_Request_With_Response then
  begin
WriteLn('Sending response to client.');
xStringStream := TStringStream.Create('my response');
try
  Sender.ServerPostCustomResponse(MsgID, MsgType_Response, xStringStream);
finally
  xStringStream.Free;
end;
  end;
end;

procedure TMyCustomApplication.ServerReceivedParams(Sender: TBaseSingleInstance;
  aParams: TStringList);
var
  I: Integer;
begin
  Writeln('-');
  Writeln('Params:');
  for I := 0 to aParams.Count-1 do
Writeln(aParams[I]);
  Writeln('-');
end;

var
  xApp: TMyCustomApplication;
  xStream: TStringStream;
  xMsgType: TMessageType;
begin
  xApp := TMyCustomApplication.Create(nil);
  

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Wed, 11 Nov 2015, Ondrej Pokorny wrote:


On 29.09.2015 12:52, Michael Van Canneyt wrote:
Juha, if you want to implement the single IDE instance, then I would like 
to ask you to implement this in custapp.pp. This is useful functionality 
for all kinds of applications, and is since very long on my todo list.


On 30.09.2015 18:50, Ondrej Pokorny wrote:

On 29.09.2015 22:47, Michael Van Canneyt wrote:

Let's first see how Ondrej does it.


See the patch attached. A simple demo program is attached as well 
(SITest.lpr).


Hello Michael,

you asked for implementing "single instance" in custapp.pp. I did it and sent 
a patch on Sept 28th. Did you have the time to check it and find eventual 
issues?


I am resending the patch against current trunk and a testing application.


Well, I had an uncommitted patch for custapp.pp at the time
(better non-options and multiple-options support), which made applying and 
testing quite difficult.
So I waited, but forgot about it.

I checked the patch and applied it, so people can try it.

I have several remarks:

a) Your TBaseSingleInstance class contains too many methods.
   It assumes you are using advancedipc.
   I suggest refactoring such a way that advancedipc is in the implementation 
section of the class.

   or introduce TAbstractSingleInstance as a parent of TBaseSingleInstance with 
the bare minimum of methods/properties.

b) There is no way to have TCustomApplication create a different singleinstance 
class, for 2 reasons:
  1. Your property is declared as TCustomSingleInstance.
 It should be TBaseSingleInstance (or TAbstractSingleInstance)
 That means that the 'enabled' property should be in TBaseSingleInstance or 
TAbstractSingleInstance.
  2. You create the instance as TCustomSingleInstance.Create in the constructor.
 It should be a function CreateSingleinstance : TCustomSingleInstance;

Can you have a look at these remarks ? If something is not clear, let me know.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 11.11.2015 17:47, Michael Van Canneyt wrote:

I checked the patch and applied it, so people can try it.

I have several remarks:

a) Your TBaseSingleInstance class contains too many methods.
   It assumes you are using advancedipc.
   I suggest refactoring such a way that advancedipc is in the 
implementation section of the class.


   or introduce TAbstractSingleInstance as a parent of 
TBaseSingleInstance with the bare minimum of methods/properties.


b) There is no way to have TCustomApplication create a different 
singleinstance class, for 2 reasons:

  1. Your property is declared as TCustomSingleInstance.
 It should be TBaseSingleInstance (or TAbstractSingleInstance)
 That means that the 'enabled' property should be in 
TBaseSingleInstance or TAbstractSingleInstance.
  2. You create the instance as TCustomSingleInstance.Create in the 
constructor.
 It should be a function CreateSingleinstance : 
TCustomSingleInstance;


Can you have a look at these remarks ? If something is not clear, let 
me know.


Great!

Your remarks are reasonable. I'll rewrite the code so that it supports 
modifications!


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 03.10.2015 19:21, Tomas Hajny wrote:

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently searching for a
file FindFirst without any sleep in between. Maybe related to
PeekRequest calls?
The solution is simple and is only a problem of the demo application 
(not advancedipc.pp code). Just add an "ELSE SLEEP(XYZ)" block into the 
server while-loop.


Ondrej
program TestIPC_Server;

{$MODE ObjFPC}{$H+}

uses
  Classes, SysUtils, AdvancedIPC;

const
  STRINGMESSAGE_WANTS_RESPONSE = 3;
  STRINGMESSAGE_NO_RESPONSE = 2;
  MESSAGE_STOP = 4;

var
  xServer: TIPCServer;
  xStream, xResponseStream: TStringStream;
  xMsgID: Integer;
  xMsgType: TMessageType;
  xNotRunningMessagesCount: Integer;
begin
  xServer := nil;
  xStream := nil;
  xResponseStream := nil;
  try
xStream := TStringStream.Create('');
xResponseStream := TStringStream.Create('OK');

//first get all messages from the hello server
xServer := TIPCServer.Create(nil);
xServer.ServerID := 'hello';
xServer.StartServer;

WriteLn('Server ', xServer.ServerID, ' started.');
WriteLn('-');

while True do
begin
  if xServer.PeekRequest(xMsgID{%H-}, xMsgType{%H-}) then
  begin
case xMsgType of
  STRINGMESSAGE_WANTS_RESPONSE, STRINGMESSAGE_NO_RESPONSE:
  begin
xServer.ReadRequest(xMsgID, xStream);
WriteLn('Received string message:');
WriteLn(xStream.DataString);
if xMsgType = STRINGMESSAGE_WANTS_RESPONSE then
begin
  xResponseStream.Position := 0;
  xServer.PostResponse(xMsgID, STRINGMESSAGE_NO_RESPONSE, 
xResponseStream);
  WriteLn('Posting response.');
end;
WriteLn('-');
  end;
  MESSAGE_STOP:
  begin
WriteLn('Stopping '+xServer.ServerID+' server.');
WriteLn('-');
Break;
  end;
end;
  end else
Sleep(50);
end;

FreeAndNil(xServer);

//now try to get all unhandled messages from the not_running server
//please see that the messages are not peeked in the order they have been 
posted (this is correct/designed behavior).
xServer := TIPCServer.Create(nil);
xServer.ServerID := 'not_running';
xServer.StartServer(False);

WriteLn('');
WriteLn('Server ', xServer.ServerID, ' started.');
WriteLn('-');

xNotRunningMessagesCount := 0;
while xServer.PeekRequest(xStream, xMsgID, xMsgType) do
begin
  if xMsgType = STRINGMESSAGE_NO_RESPONSE then
  begin
WriteLn('Received message: ', xStream.DataString);
Inc(xNotRunningMessagesCount);
  end else
WriteLn('ERROR: Wrong message type: ', xMsgType);

  WriteLn('-');
end;

if xNotRunningMessagesCount <> 10 then
begin
  WriteLn('ERROR: Wrong message count: ', xNotRunningMessagesCount);
  WriteLn('-');
end;

WriteLn('Stopping '+xServer.ServerID+' server.');
WriteLn('-');
FreeAndNil(xServer);
  finally
xServer.Free;
xStream.Free;
xResponseStream.Free;
  end;
end.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 03.10.2015 19:21, Tomas Hajny wrote:

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently searching for a
file FindFirst without any sleep in between. Maybe related to
PeekRequest calls? Second, I noticed that unlike the "simple" test,
the "advanced" leaves a temporary file 'hello--t' in the
temporary directory after finishing.
First - Yes that's true, I didn't add any sleep into the code for 
testing purposes.

Second - I'll check that!


Apart from that, I replaced the hard-coded '*' with a reference to
AllFilesMask constant defined in unit System, because some of FPC
targets need a different mask when searching for all files (that is
not the case of OS/2, but e.g. GO32v2 would need that if not running
on a LFN enabled system) - committed in svn trunk.



Thanks! I found some smaller bugs that I send over to the temporary copy 
in Lazarus trunk. I'll sync both files and send patches back.


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 03.10.2015 19:21, Tomas Hajny wrote:

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently searching for a
file FindFirst without any sleep in between. Maybe related to
PeekRequest calls? Second, I noticed that unlike the "simple" test,
the "advanced" leaves a temporary file 'hello--t' in the
temporary directory after finishing.

Apart from that, I replaced the hard-coded '*' with a reference to
AllFilesMask constant defined in unit System, because some of FPC
targets need a different mask when searching for all files (that is
not the case of OS/2, but e.g. GO32v2 would need that if not running
on a LFN enabled system) - committed in svn trunk.



Attached patched for FPC and Lazarus to sync advancedipc.pp. The current 
version in FPC trunk is out-dated (the Lazarus trunk version just misses 
the AllFilesMask constant).


I could not reproduce the "temporary file 'hello--t' was not 
deleted" problem. Actually all files should be deleted in 
StopServer(True) or Free -> DeletePendingRequests.


What demo did you observe the problem in? TestIPC_Server/TestIPC_Client?

Ondrej
Index: packages/fcl-base/src/advancedipc.pp
===
--- packages/fcl-base/src/advancedipc.pp(revision 31926)
+++ packages/fcl-base/src/advancedipc.pp(working copy)
@@ -30,7 +30,11 @@
   {$IFDEF UNIX}
   baseunix,
   {$endif}
-  sysutils, Classes;
+  sysutils, Classes
+  {$IF FPC_FULLVERSION<20701}
+  ,LazUTF8SysUtils
+  {$ENDIF}
+  ;
 
 const
   HEADER_VERSION = 2;
@@ -60,13 +64,14 @@
 FMessageVersion: Integer;
   protected
 class function ServerIDToFileName(const aServerID: string; const aGlobal: 
Boolean): string;
-function GetResponseFileName(const aMsgID: Integer): string;
+function GetResponseFileName(const aRequestID: Integer): string;
 function GetResponseFileName(const aRequestFileName: string): string;
-function GetPeekedRequestFileName(const aMsgID: Integer): string;
+function GetPeekedRequestFileName(const aRequestID: Integer): string;
 function GetPeekedRequestFileName(const aRequestFileName: string): string;
 function GetRequestPrefix: string;
-function GetRequestFileName(const aMsgID: Integer): string;
-function RequestFileNameToMsgID(const aFileName: string): Integer;
+function GetRequestFileName(const aRequestID: Integer): string;
+function RequestFileNameToID(const aFileName: string): Integer;
+function RequestExists(const aRequestFileName: string): Boolean;
 
 function GetUniqueRequest(out outFileName: string): Integer;
 procedure SetServerID(const aServerID: string); virtual;
@@ -122,19 +127,19 @@
   public
 //peek request and read the message into a stream
 function PeekRequest(const aStream: TStream; out outMsgType: 
TMessageType): Boolean; overload;
-function PeekRequest(const aStream: TStream; out outMsgID: Integer; out 
outMsgType: TMessageType): Boolean; overload;
-function PeekRequest(const aStream: TStream; out outMsgID: Integer; out 
outMsgType: TMessageType; const aTimeOut: Integer): Boolean; overload;
+function PeekRequest(const aStream: TStream; out outRequestID: Integer; 
out outMsgType: TMessageType): Boolean; overload;
+function PeekRequest(const aStream: TStream; out outRequestID: Integer; 
out outMsgType: TMessageType; const aTimeOut: Integer): Boolean; overload;
 //only peek request, you have to read/delete the request manually with 
ReadRequest/DeleteRequest
 function PeekRequest(out outMsgType: TMessageType): Boolean; overload;
-function PeekRequest(out outMsgID: Integer; out outMsgType: TMessageType): 
Boolean; overload;
-function PeekRequest(out outMsgID: Integer; out outMsgType: TMessageType; 
const aTimeOut: Integer): Boolean; overload;
+function PeekRequest(out outRequestID: Integer; out outMsgType: 
TMessageType): Boolean; overload;
+function PeekRequest(out outRequestID: Integer; out outMsgType: 
TMessageType; const aTimeOut: Integer): Boolean; overload;
 //read a peeked request (that hasn't been read yet)
-function ReadRequest(const aMsgID: Integer; const aStream: TStream): 
Boolean;
+function ReadRequest(const aRequestID: Integer; const aStream: TStream): 
Boolean;
 //delete a peeked request (that hasn't been read yet)
-procedure DeleteRequest(const aMsgID: Integer);
+procedure DeleteRequest(const aRequestID: Integer);
 
 //post response to a request
-procedure PostResponse(const aMsgID: Integer; const aMsgType: 
TMessageType; const aStream: TStream);
+procedure PostResponse(const aRequestID: Integer; const aMsgType: 
TMessageType; const aStream: TStream);
 
 //find the highest request ID from all pending requests
 function FindHighestPendingRequestId: 

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On 21 Sep 15, at 14:03, Ondrej Pokorny wrote:
 .
 .
> Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
> 
> I prepared a fully compatible AdvancedIPC unit. See the attachment.
> There is a unit mysimpleipc.pp that should replace the simpleipc.pp in 
> FPC sources. I renamed it in order to prevent file name problems and to 
> be able to check the compatibility without recompiling FPC sources 
> (basically just use "mysimpleipc" in the uses instead of "simpleipc").
 .
 .

Thanks, I tested it under OS/2 now. Both the "simple" and "advanced" 
test programs work, well done! I noticed two issues when running the 
"advanced" tests, though. First, the server increases the CPU 
considerably. There seems to be a loop permanently searching for a 
file FindFirst without any sleep in between. Maybe related to 
PeekRequest calls? Second, I noticed that unlike the "simple" test, 
the "advanced" leaves a temporary file 'hello--t' in the 
temporary directory after finishing.

Apart from that, I replaced the hard-coded '*' with a reference to 
AllFilesMask constant defined in unit System, because some of FPC 
targets need a different mask when searching for all files (that is 
not the case of OS/2, but e.g. GO32v2 would need that if not running 
on a LFN enabled system) - committed in svn trunk.

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On Sat, October 3, 2015 19:59, Ondrej Pokorny wrote:
> On 03.10.2015 19:21, Tomas Hajny wrote:
>> Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
>> test programs work, well done! I noticed two issues when running the
>> "advanced" tests, though. First, the server increases the CPU
>> considerably. There seems to be a loop permanently searching for a
>> file FindFirst without any sleep in between. Maybe related to
>> PeekRequest calls?
> The solution is simple and is only a problem of the demo application
> (not advancedipc.pp code). Just add an "ELSE SLEEP(XYZ)" block into the
> server while-loop.

Yes, indeed, that fixed it, thanks. I've added the test / example to FPC
SVN under the directory examples.

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On Sat, October 3, 2015 19:54, Ondrej Pokorny wrote:
> On 03.10.2015 19:21, Tomas Hajny wrote:
 .
 .
> Attached patched for FPC and Lazarus to sync advancedipc.pp. The current
> version in FPC trunk is out-dated (the Lazarus trunk version just misses
> the AllFilesMask constant).

Thanks, I applied a modified version of your patch to FPC SVN; since we
put the file to FPC trunk, the modifications related to support of FPC
2.6.4 would be superfluous there and I skipped them.


> I could not reproduce the "temporary file 'hello--t' was not
> deleted" problem. Actually all files should be deleted in
> StopServer(True) or Free -> DeletePendingRequests.
>
> What demo did you observe the problem in? TestIPC_Server/TestIPC_Client?

Yes. I cannot reproduce it either, though. I guess that it must have
resulted from me killing the server at some point (due to the high CPU
load), i.e. apparently a false alarm - sorry. :-(

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 22:47, Michael Van Canneyt wrote:

Let's first see how Ondrej does it.


See the patch attached. A simple demo program is attached as well 
(SITest.lpr).


advancedipc.pp: refactoring MsgID -> RequestID and some smaller issues 
solved. API hasn't changed.

singleinstance.pp: class implementing single instance.
custapp.pp: added singleinstance property. Set Enabled to True (before 
CustomApplication.Initialize) and it does everything for you. You can 
also set more properties like ID and Global.
You can talk to the server single instance after Application.Initialize 
if you want to (see SITest.lpr).


+ I am now travelling so I have only MS Windows to check. There is a 
workaround for UNIX to solve the filelock problem. The problem is that 
if you execute more files from the explorer, the instances are started 
at the same time so there could be problems with creating the file lock 
(double file locks can occur). The clue is that you wait for other 
instances to start (timeout 100ms) and then use the highest instance as 
server. If there are some pending wait-requests (if the program 
collapsed or something like that) there is a random sleep to decide what 
instance should be the server. This approach is very bullet-proof, as my 
tests showed (the random sleep is not needed in normal situations).


+ A small issue is that checking for new messages in 
CustomApplication.DoRun too often uses a lot of CPU power. The check 
should be made only about every 50ms (then the CPU needed is at ~0%). I 
don't know how to do it the best way, because eg. using GetTickCount 
needs also a lot of CPU. I don't know how it behaves with TApplication 
(maybe there is no such problem).


+ I had a problem with random numbers (I checked windows implementation 
only). If randomize is executed from 2 different processes at exactly 
same moment, it returns the same randseed (GetTickCount). This is a big 
problem with processors with multithreading. In this case you can have 
exactly same random sequences for 2 different threads/processes. I 
suggest to include GetCurrentThreadID into randomize somehow.


Something like:
  procedure randomize;
  begin
randseed:=Integer(Int64(GetTickCount)+GetCurrentThreadID);
  end;

Addition is maybe not the best operation, but you should get the idea.
I solved this problem by adding GetCurrentThreadID to the random result, 
so advancedipc is not affected by this problem any more.


+ Juha, I will upload a new patch for Lazarus IDEInstances. Probably 
nothing changed, but just to be sure.


Ondrej
Index: packages/fcl-base/src/advancedipc.pp
===
--- packages/fcl-base/src/advancedipc.pp(revision 31890)
+++ packages/fcl-base/src/advancedipc.pp(working copy)
@@ -60,13 +60,14 @@
 FMessageVersion: Integer;
   protected
 class function ServerIDToFileName(const aServerID: string; const aGlobal: 
Boolean): string;
-function GetResponseFileName(const aMsgID: Integer): string;
+function GetResponseFileName(const aRequestID: Integer): string;
 function GetResponseFileName(const aRequestFileName: string): string;
-function GetPeekedRequestFileName(const aMsgID: Integer): string;
+function GetPeekedRequestFileName(const aRequestID: Integer): string;
 function GetPeekedRequestFileName(const aRequestFileName: string): string;
 function GetRequestPrefix: string;
-function GetRequestFileName(const aMsgID: Integer): string;
-function RequestFileNameToMsgID(const aFileName: string): Integer;
+function GetRequestFileName(const aRequestID: Integer): string;
+function RequestFileNameToID(const aFileName: string): Integer;
+function RequestExists(const aRequestFileName: string): Boolean;
 
 function GetUniqueRequest(out outFileName: string): Integer;
 procedure SetServerID(const aServerID: string); virtual;
@@ -122,19 +123,19 @@
   public
 //peek request and read the message into a stream
 function PeekRequest(const aStream: TStream; out outMsgType: 
TMessageType): Boolean; overload;
-function PeekRequest(const aStream: TStream; out outMsgID: Integer; out 
outMsgType: TMessageType): Boolean; overload;
-function PeekRequest(const aStream: TStream; out outMsgID: Integer; out 
outMsgType: TMessageType; const aTimeOut: Integer): Boolean; overload;
+function PeekRequest(const aStream: TStream; out outRequestID: Integer; 
out outMsgType: TMessageType): Boolean; overload;
+function PeekRequest(const aStream: TStream; out outRequestID: Integer; 
out outMsgType: TMessageType; const aTimeOut: Integer): Boolean; overload;
 //only peek request, you have to read/delete the request manually with 
ReadRequest/DeleteRequest
 function PeekRequest(out outMsgType: TMessageType): Boolean; overload;
-function PeekRequest(out outMsgID: Integer; out outMsgType: TMessageType): 
Boolean; overload;
-function PeekRequest(out outMsgID: Integer; out 

Re: [fpc-devel] simpleipc issues

[Juha Manninen]

On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt
 wrote:
> I am not proposing to make a new class.
> I want a property "SingeInstance" in CustApp which activates this
> automatically.

I had the very same idea when this was discussed a long time ago in
Lazarus list.
Martin Friebe noted that every application would then depend on this
single-instance IPC code.
It was a valid point. There should not be such a dependency.

The right way is to use a drag-and-drop LCL component like the one
from Luiz Américo.
The question is should we replace his component with a better one
based on Ondrej's AdvancedIPC.
I think we should because SimpleIPC apparently has limitations.

Michael, an LCL component is as beginner friendly as your
SingeInstance property would be.

Regards,
Juha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 14:42, Michael Van Canneyt wrote:

On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
OK, I see your point. Yes, I think it is possible and even not that 
much work to do.


I programmed "multiple instances" handling into Lazarus IDE. It's the 
same like e.g. Adobe Photoshop or VLC player work - if you start the 
IDE without files in cmd parameters, the IDE is started. If you start 
IDE with files, the files are opened in already running instance. You 
can enable a truly "single instance" (always only single instance 
allowed) with an environment setting option.


IMO, we should keep the code in CustApp simple and don't do this 
advanced stuff. Only single/multiple instances option. If single 
instance is selected, allow to talk with the one single instance 
through IPC. If there are multiple instances, you cannot talk to 
other instances.

This should be doable.

What do you think?


Exactly what I had in mind, simple yet functional :-)


OK,  I'll prepare this one as well. But the Lazarus IDE won't take 
advantage of CustApp (it will use AdvancedIPC directly with the custom 
advanced possibilities I already programmed).


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Ondrej Pokorny wrote:


On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no dangerous 
dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the latest 
simpleipc-compatible one from the mailing list. Please apply the patch from 
the attachment!


Strange. I took the one from the mail ? Maybe some name mixup :(

My apologies. Applied the patch, rev.  31890. Thanks !

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no 
dangerous dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the 
latest simpleipc-compatible one from the mailing list. Please apply the 
patch from the attachment!


Thanks
Ondrej
Index: packages/fcl-base/src/advancedipc.pp
===
--- packages/fcl-base/src/advancedipc.pp(revision 31886)
+++ packages/fcl-base/src/advancedipc.pp(working copy)
@@ -2,7 +2,13 @@
 This file is part of the Free Component Library (FCL)
 Copyright (c) 2015 by Ondrej Pokorny
 
-Unit implementing two-way (request/response) IPC between 1 server and more 
clients, based on files.
+Unit implementing two-way (request/response) IPC between 1 server and more
+clients, based on files.
+The order of message processing is not deterministic (if there are more
+pending messages, the server won't process them in the order they have
+been sent to the server.
+SendRequest and PostRequest+PeekResponse sequences from 1 client are
+blocking and processed in correct order.
 
 See the file COPYING.FPC, included in this distribution,
 for details about the copyright.
@@ -27,13 +33,14 @@
   sysutils, Classes;
 
 const
-  HEADER_VERSION = 1;
+  HEADER_VERSION = 2;
 
 type
+  TMessageType = LongInt;
   TMessageHeader = packed record
-HeaderVersion: Integer;
+HeaderVersion: Byte;
 FileLock: Byte;//0 = unlocked, 1 = locked
-MsgType: Integer;
+MsgType: TMessageType;
 MsgLen: Integer;
 MsgVersion: Integer;
   end;
@@ -45,47 +52,58 @@
 destructor Destroy; override;
   end;
 
-  TIPCBase = class
+  TIPCBase = class(TComponent)
   private
 FGlobal: Boolean;
 FFileName: string;
-FServerName: string;
+FServerID: string;
 FMessageVersion: Integer;
   protected
-class function ServerNameToFileName(const aServerName: string; const 
aGlobal: Boolean): string;
+class function ServerIDToFileName(const aServerID: string; const aGlobal: 
Boolean): string;
 function GetResponseFileName(const aMsgID: Integer): string;
 function GetResponseFileName(const aRequestFileName: string): string;
+function GetPeekedRequestFileName(const aMsgID: Integer): string;
+function GetPeekedRequestFileName(const aRequestFileName: string): string;
 function GetRequestPrefix: string;
 function GetRequestFileName(const aMsgID: Integer): string;
 function RequestFileNameToMsgID(const aFileName: string): Integer;
 
 function GetUniqueRequest(out outFileName: string): Integer;
-procedure SetServerName(const aServerName: string); virtual;
+procedure SetServerID(const aServerID: string); virtual;
 procedure SetGlobal(const aGlobal: Boolean); virtual;
 
-function CanReadMessage(const aFileName: string; out outStream: TStream; 
out outMsgType, outMsgLen: Integer): Boolean;
-procedure DoPostMessage(const aFileName: string; const aMsgType: Integer; 
const aStream: TStream);
+function CanReadMessage(const aFileName: string; out outStream: TStream; 
out outMsgType: TMessageType; out outMsgLen: Integer): Boolean;
+procedure DoPostMessage(const aFileName: string; const aMsgType: 
TMessageType; const aStream: TStream);
 
 property FileName: string read FFileName;
   public
-constructor Create; virtual;
+class procedure FindRunningServers(const aServerIDPrefix: string;
+  const outServerIDs: TStrings; const aGlobal: Boolean = False);
+class function ServerRunning(const aServerID: string; const aGlobal: 
Boolean = False): Boolean; overload;
   public
-class procedure FindRunningServers(const aServerNamePrefix: string;
-  const outServerNames: TStrings; const aGlobal: Boolean = False);
-class function ServerIsRunning(const aServerName: string; const aGlobal: 
Boolean = False): Boolean;
-property ServerName: string read FServerName write SetServerName;
+//ServerID: name/ID of the server. Use only ['a'..'z', 'A'..'Z', '_'] 
characters
+property ServerID: string read FServerID write SetServerID;
+//Global: if true, processes from different users can communicate; false, 
processes only from current users can communicate
 property Global: Boolean read FGlobal write SetGlobal;
+//MessageVersion: only messages with the same MessageVersion can be 
delivered between server/client
 property MessageVersion: Integer read FMessageVersion write 
FMessageVersion;
   end;
 
   TIPCClient = class(TIPCBase)
-  var
+  private
 FLastMsgFileName: string;
   public
-function PostRequest(const aMsgType: Integer; const aStream: TStream): 
Integer;//returns ID
-function PeekResponse(const aStream: TStream; var outMsgType: Integer; 
const aTimeOut: Integer): Boolean;
+//post request to server, do not wait until request is peeked; returns 
request ID
+  

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 15:42, Ondrej Pokorny wrote:

On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no 
dangerous dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the 
latest simpleipc-compatible one from the mailing list. Please apply 
the patch from the attachment!


Thanks
Ondrej
Sorry for the double email, I am using mobile internet now and it 
reported mail send error.
Thanks for committing the patch, maybe it was my mistake, no problem 
anyway. It's OK now!


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Juha Manninen]

On Tue, Sep 29, 2015 at 2:35 PM, Ondrej Pokorny  wrote:
> Juha, I changed the advancedipc.pas unit (this one from the mailing list is
> newer than from the bug report). I can prepare a new patch for the bug
> report.

No need for a new patch if it did not change otherwise. I only would
like to move the AdvancedIPC unit to somewhere else from ide
directory.
I can ask opinions at Lazarus developer list.

Juha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 15:01, Juha Manninen wrote:

On Tue, Sep 29, 2015 at 2:35 PM, Ondrej Pokorny  wrote:

Juha, I changed the advancedipc.pas unit (this one from the mailing list is
newer than from the bug report). I can prepare a new patch for the bug
report.

No need for a new patch if it did not change otherwise. I only would
like to move the AdvancedIPC unit to somewhere else from ide
directory.
I can ask opinions at Lazarus developer list.

Juha

The API may have changed a little bit. I'll recheck it.
Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Juha Manninen wrote:


On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt
 wrote:

I am not proposing to make a new class.
I want a property "SingeInstance" in CustApp which activates this
automatically.


I had the very same idea when this was discussed a long time ago in
Lazarus list.
Martin Friebe noted that every application would then depend on this
single-instance IPC code.
It was a valid point. There should not be such a dependency.


For simpleIPC, yes. But the new implementation has no dependencies 
except sysutils, classes. So the argument becomes void.


That's why I was glad with Ondrej's implementation.



The right way is to use a drag-and-drop LCL component like the one
from Luiz Américo.


That is IMHO a completely wrong implementation for 2 reasons:

1. Using a LCL component means that you must instantiate a form/datamodule 
first.
   By that time, a database connection may already have been made (just
   to name something), which is exactly what you want to avoid.

   The check for single instance should be done before the first form is 
created.

2. Then it is only available in visually designed applications.
   Services, website servers and custom console apps are non-visual.
   I am specificially thinking FastCGI processes.

   All these have in common that they descend from TCustomApplication.

That is why I think TCustomApplication is the only good location;
So if Ondrej does not do it, I will add it myself anyway.

Lazarus is free not to use it, obviously.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Juha Manninen]

On Tue, Sep 29, 2015 at 4:35 PM, Michael Van Canneyt
 wrote:
> For simpleIPC, yes. But the new implementation has no dependencies except
> sysutils, classes. So the argument becomes void.

It adds extra code to every application. Maybe not too much though.

> ...
> That is why I think TCustomApplication is the only good location;
> So if Ondrej does not do it, I will add it myself anyway.

Ok, I see your point. I am not arguing against it.

> Lazarus is free not to use it, obviously.

TApplication inherits from TCustomApplication, thus it will be
included in every LCL application.

Juha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Ondrej Pokorny wrote:


On 29.09.2015 15:35, Michael Van Canneyt wrote:


1. Using a LCL component means that you must instantiate a form/datamodule 
first.

   By that time, a database connection may already have been made (just
   to name something), which is exactly what you want to avoid.

   The check for single instance should be done before the first form is 
created.


2. Then it is only available in visually designed applications.
   Services, website servers and custom console apps are non-visual.
   I am specificially thinking FastCGI processes.

Actually, you could create the LCL component manually in the LPR and use it 
non-visually before any code is run (except initialization sections). The 
visual component could be only for the hobbyists.


So for me both CustApp or LCL component are OK. You decide :)


Both are OK. Use of one does not exclude use of the other.

I was going to add it in CustApp anyway as soon as I had looked at your 
implementation.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 15:35, Michael Van Canneyt wrote:


1. Using a LCL component means that you must instantiate a 
form/datamodule first.

   By that time, a database connection may already have been made (just
   to name something), which is exactly what you want to avoid.

   The check for single instance should be done before the first form 
is created.


2. Then it is only available in visually designed applications.
   Services, website servers and custom console apps are non-visual.
   I am specificially thinking FastCGI processes.

Actually, you could create the LCL component manually in the LPR and use 
it non-visually before any code is run (except initialization sections). 
The visual component could be only for the hobbyists.


So for me both CustApp or LCL component are OK. You decide :)

Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Ondrej Pokorny wrote:


On 29.09.2015 13:50, Michael Van Canneyt wrote:


You may not think this is important, but for beginners, this can be a 
tremendous aid.

The easier we make it, the better. Lazarus is a RAD environment, after all.

Michael.


OK, I see your point. Yes, I think it is possible and even not that much work 
to do.


I programmed "multiple instances" handling into Lazarus IDE. It's the same 
like e.g. Adobe Photoshop or VLC player work - if you start the IDE without 
files in cmd parameters, the IDE is started. If you start IDE with files, the 
files are opened in already running instance. You can enable a truly "single 
instance" (always only single instance allowed) with an environment setting 
option.


IMO, we should keep the code in CustApp simple and don't do this advanced 
stuff. Only single/multiple instances option. If single instance is selected, 
allow to talk with the one single instance through IPC. If there are multiple 
instances, you cannot talk to other instances.

This should be doable.

What do you think?


Exactly what I had in mind, simple yet functional :-)

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no 
dangerous dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the 
latest simpleipc-compatible one from the mailing list. Please apply the 
patch from the attachment!


Thanks
Ondrej
Index: packages/fcl-base/src/advancedipc.pp
===
--- packages/fcl-base/src/advancedipc.pp(revision 31886)
+++ packages/fcl-base/src/advancedipc.pp(working copy)
@@ -2,7 +2,13 @@
 This file is part of the Free Component Library (FCL)
 Copyright (c) 2015 by Ondrej Pokorny
 
-Unit implementing two-way (request/response) IPC between 1 server and more 
clients, based on files.
+Unit implementing two-way (request/response) IPC between 1 server and more
+clients, based on files.
+The order of message processing is not deterministic (if there are more
+pending messages, the server won't process them in the order they have
+been sent to the server.
+SendRequest and PostRequest+PeekResponse sequences from 1 client are
+blocking and processed in correct order.
 
 See the file COPYING.FPC, included in this distribution,
 for details about the copyright.
@@ -27,13 +33,14 @@
   sysutils, Classes;
 
 const
-  HEADER_VERSION = 1;
+  HEADER_VERSION = 2;
 
 type
+  TMessageType = LongInt;
   TMessageHeader = packed record
-HeaderVersion: Integer;
+HeaderVersion: Byte;
 FileLock: Byte;//0 = unlocked, 1 = locked
-MsgType: Integer;
+MsgType: TMessageType;
 MsgLen: Integer;
 MsgVersion: Integer;
   end;
@@ -45,47 +52,58 @@
 destructor Destroy; override;
   end;
 
-  TIPCBase = class
+  TIPCBase = class(TComponent)
   private
 FGlobal: Boolean;
 FFileName: string;
-FServerName: string;
+FServerID: string;
 FMessageVersion: Integer;
   protected
-class function ServerNameToFileName(const aServerName: string; const 
aGlobal: Boolean): string;
+class function ServerIDToFileName(const aServerID: string; const aGlobal: 
Boolean): string;
 function GetResponseFileName(const aMsgID: Integer): string;
 function GetResponseFileName(const aRequestFileName: string): string;
+function GetPeekedRequestFileName(const aMsgID: Integer): string;
+function GetPeekedRequestFileName(const aRequestFileName: string): string;
 function GetRequestPrefix: string;
 function GetRequestFileName(const aMsgID: Integer): string;
 function RequestFileNameToMsgID(const aFileName: string): Integer;
 
 function GetUniqueRequest(out outFileName: string): Integer;
-procedure SetServerName(const aServerName: string); virtual;
+procedure SetServerID(const aServerID: string); virtual;
 procedure SetGlobal(const aGlobal: Boolean); virtual;
 
-function CanReadMessage(const aFileName: string; out outStream: TStream; 
out outMsgType, outMsgLen: Integer): Boolean;
-procedure DoPostMessage(const aFileName: string; const aMsgType: Integer; 
const aStream: TStream);
+function CanReadMessage(const aFileName: string; out outStream: TStream; 
out outMsgType: TMessageType; out outMsgLen: Integer): Boolean;
+procedure DoPostMessage(const aFileName: string; const aMsgType: 
TMessageType; const aStream: TStream);
 
 property FileName: string read FFileName;
   public
-constructor Create; virtual;
+class procedure FindRunningServers(const aServerIDPrefix: string;
+  const outServerIDs: TStrings; const aGlobal: Boolean = False);
+class function ServerRunning(const aServerID: string; const aGlobal: 
Boolean = False): Boolean; overload;
   public
-class procedure FindRunningServers(const aServerNamePrefix: string;
-  const outServerNames: TStrings; const aGlobal: Boolean = False);
-class function ServerIsRunning(const aServerName: string; const aGlobal: 
Boolean = False): Boolean;
-property ServerName: string read FServerName write SetServerName;
+//ServerID: name/ID of the server. Use only ['a'..'z', 'A'..'Z', '_'] 
characters
+property ServerID: string read FServerID write SetServerID;
+//Global: if true, processes from different users can communicate; false, 
processes only from current users can communicate
 property Global: Boolean read FGlobal write SetGlobal;
+//MessageVersion: only messages with the same MessageVersion can be 
delivered between server/client
 property MessageVersion: Integer read FMessageVersion write 
FMessageVersion;
   end;
 
   TIPCClient = class(TIPCBase)
-  var
+  private
 FLastMsgFileName: string;
   public
-function PostRequest(const aMsgType: Integer; const aStream: TStream): 
Integer;//returns ID
-function PeekResponse(const aStream: TStream; var outMsgType: Integer; 
const aTimeOut: Integer): Boolean;
+//post request to server, do not wait until request is peeked; returns 
request ID
+  

Re: [fpc-devel] simpleipc issues

[Juha Manninen]

On Mon, Sep 21, 2015 at 3:03 PM, Ondrej Pokorny  wrote:
> Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
>
> I prepared a fully compatible AdvancedIPC unit. See the attachment.
> ...

Michael and Tomas, I am planning to copy AdvancedIPC temporarily to
Lazarus sources.
If you are planning changes for it, I can wait.
The temporary copy does not need to be identical but it should be API
compatible.
With it we can finally implement the single IDE instance feature
without depending on the latest FPC libs.
  http://bugs.freepascal.org/view.php?id=8051

Regards,
Juha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 13:50, Michael Van Canneyt wrote:


You may not think this is important, but for beginners, this can be a 
tremendous aid.
The easier we make it, the better. Lazarus is a RAD environment, after 
all.


Michael.


OK, I see your point. Yes, I think it is possible and even not that much 
work to do.


I programmed "multiple instances" handling into Lazarus IDE. It's the 
same like e.g. Adobe Photoshop or VLC player work - if you start the IDE 
without files in cmd parameters, the IDE is started. If you start IDE 
with files, the files are opened in already running instance. You can 
enable a truly "single instance" (always only single instance allowed) 
with an environment setting option.


IMO, we should keep the code in CustApp simple and don't do this 
advanced stuff. Only single/multiple instances option. If single 
instance is selected, allow to talk with the one single instance through 
IPC. If there are multiple instances, you cannot talk to other instances.

This should be doable.

What do you think?

Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Ondrej Pokorny wrote:


On 29.09.2015 12:52, Michael Van Canneyt wrote:


I added it to fpc/packages/fcl-base. It compiles OK, there are no dangerous 
dependencies except sysutils and classes.



Thanks!

Juha, if you want to implement the single IDE instance, then I would like 
to ask you to implement this in custapp.pp. This is useful functionality 
for all kinds of applications, and is since very long on my todo list.



I don't think it is needed (see comments further down).


I think it is very much needed.


I think the functionality can be split out in 2 parts:
- Make sure a single instance is running.
The IPC does it by design - you start a server and you have the check, so you 
get it. IMO it's not needed to make another component above AdvancedIPC with 
exactly the same functionality but different name.


I am not proposing to make a new class.
I want a property "SingeInstance" in CustApp which activates this automatically.




- Sending messages to running instance.

Again, IPC does it.


I know that, I simply want it integrated in CustApp.

By doing this, 'Single instance' can be a simple flag in the project options.

You may not think this is important, but for beginners, this can be a 
tremendous aid.
The easier we make it, the better. Lazarus is a RAD environment, after all.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On Tue, September 29, 2015 12:30, Juha Manninen wrote:
> On Mon, Sep 21, 2015 at 3:03 PM, Ondrej Pokorny  wrote:
>> Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
>>
>> I prepared a fully compatible AdvancedIPC unit. See the attachment.
>> ...
>
> Michael and Tomas, I am planning to copy AdvancedIPC temporarily to
> Lazarus sources.
> If you are planning changes for it, I can wait.
> The temporary copy does not need to be identical but it should be API
> compatible.
> With it we can finally implement the single IDE instance feature
> without depending on the latest FPC libs.
>   http://bugs.freepascal.org/view.php?id=8051

Unfortunately, I didn't have time for testing it yet, sorry. :-( If you
can wait until end of this week, I'll make sure to do so during the
weekend at the latest.

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 12:52, Michael Van Canneyt wrote:


I added it to fpc/packages/fcl-base. It compiles OK, there are no 
dangerous dependencies except sysutils and classes.



Thanks!

Juha, if you want to implement the single IDE instance, then I would 
like to ask you to implement this in custapp.pp. This is useful 
functionality for all kinds of applications, and is since very long on 
my todo list.



I don't think it is needed (see comments further down).


I think the functionality can be split out in 2 parts:
- Make sure a single instance is running.
The IPC does it by design - you start a server and you have the check, 
so you get it. IMO it's not needed to make another component above 
AdvancedIPC with exactly the same functionality but different name.



- Sending messages to running instance.

Again, IPC does it.

Actually, you can achieve "single instance" with AdvancedIPC with only a 
few lines of code (I think the simplest code would be under 10 lines). 
Every application can have different needs about the "single" instance 
so a customization is needed anyway (e.g. passing over other command 
line parameters etc.)


Juha, I changed the advancedipc.pas unit (this one from the mailing list 
is newer than from the bug report). I can prepare a new patch for the 
bug report.


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Tomas Hajny wrote:


On Tue, September 29, 2015 12:30, Juha Manninen wrote:

On Mon, Sep 21, 2015 at 3:03 PM, Ondrej Pokorny  wrote:

Michael Van Canneyt & Tomas Hajny & everybody who wants to test:

I prepared a fully compatible AdvancedIPC unit. See the attachment.
...


Michael and Tomas, I am planning to copy AdvancedIPC temporarily to
Lazarus sources.
If you are planning changes for it, I can wait.
The temporary copy does not need to be identical but it should be API
compatible.
With it we can finally implement the single IDE instance feature
without depending on the latest FPC libs.
  http://bugs.freepascal.org/view.php?id=8051


Unfortunately, I didn't have time for testing it yet, sorry. :-( If you
can wait until end of this week, I'll make sure to do so during the
weekend at the latest.


I added it to fpc/packages/fcl-base. It compiles OK, there are no dangerous 
dependencies except sysutils and classes.


Juha, if you want to implement the single IDE instance, then I would like 
to ask you to implement this in custapp.pp. This is useful functionality 
for all kinds of applications, and is since very long on my todo list.


I think the functionality can be split out in 2 parts:
- Make sure a single instance is running.
- Sending messages to running instance.
The first can be implemented in custapp, I am not sure about the second.
At first sight, I think that this should be possible.

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:


2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara <
luizameri...@gmail.com>:




It can be used without the component. The component is just a convenience.
 See the examples



https://github.com/blikblum/luipack/blob/master/uniqueinstance/testraw/project1.lpr


unit uniqueinstance;

interface

uses
  Forms, Classes, SysUtils, simpleipc, ExtCtrls;

Forms, ExtCtrls ??

This disqualifies your component fully for anything but GUI apps.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Luiz Americo Pereira Camara]

2015-09-29 10:35 GMT-03:00 Michael Van Canneyt :

>
>
> On Tue, 29 Sep 2015, Juha Manninen wrote:
>
> On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt
>>  wrote:
>>
>>> I am not proposing to make a new class.
>>> I want a property "SingeInstance" in CustApp which activates this
>>> automatically.
>>>
>>
>> I had the very same idea when this was discussed a long time ago in
>> Lazarus list.
>> Martin Friebe noted that every application would then depend on this
>> single-instance IPC code.
>> It was a valid point. There should not be such a dependency.
>>
>
> For simpleIPC, yes. But the new implementation has no dependencies except
> sysutils, classes. So the argument becomes void.
>
> That's why I was glad with Ondrej's implementation.
>
>
>> The right way is to use a drag-and-drop LCL component like the one
>> from Luiz Américo.
>>
>
> That is IMHO a completely wrong implementation for 2 reasons:
>
>
It can be used without the component. The component is just a convenience.
 See the examples


> 1. Using a LCL component means that you must instantiate a form/datamodule
> first.
>By that time, a database connection may already have been made (just
>to name something), which is exactly what you want to avoid.
>
>

>The check for single instance should be done before the first form is
> created.
>

It can be done


>
> 2. Then it is only available in visually designed applications.
>Services, website servers and custom console apps are non-visual.
>I am specificially thinking FastCGI processes.
>
>
See above


>All these have in common that they descend from TCustomApplication.
>
>
And console apps without TCustomApplication?

Luiz
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:



2. Then it is only available in visually designed applications.
   Services, website servers and custom console apps are non-visual.
   I am specificially thinking FastCGI processes.



See above


I didn't say it could not be done with that component. 
But IMHO you should have gone the extra mile and implement it in TCustomApplication.


Ondrej's class has the advantage that it introduces no extra dependencies. 
It builds on classes and sysutils.



   All these have in common that they descend from TCustomApplication.



And console apps without TCustomApplication?


They can use advancedipc directly if they want. I rarely make those any more 
for production,
- Because the command-line handling of TCustomApplication is convenient.
- Most often you need a class anyway for event handling or to use as owner. 
We must assume something. 
The minimum shared code is in TCustomApplication, it is the most logical place.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Luiz Americo Pereira Camara]

2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara <
luizameri...@gmail.com>:

>
>
> It can be used without the component. The component is just a convenience.
>  See the examples
>

https://github.com/blikblum/luipack/blob/master/uniqueinstance/testraw/project1.lpr

Luiz
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Luiz Americo Pereira Camara]

Unit uniqueinstanceraw

Please look carefully

Luiz
Em 29/09/2015 12:01, "Michael Van Canneyt" 
escreveu:

>
>
> On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
>
> 2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara <
>> luizameri...@gmail.com>:
>>
>>
>>>
>>> It can be used without the component. The component is just a
>>> convenience.
>>>  See the examples
>>>
>>>
>>
>> https://github.com/blikblum/luipack/blob/master/uniqueinstance/testraw/project1.lpr
>>
>
> unit uniqueinstance;
>
> interface
>
> uses
>   Forms, Classes, SysUtils, simpleipc, ExtCtrls;
>
> Forms, ExtCtrls ??
>
> This disqualifies your component fully for anything but GUI apps.
>
> Michael.
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 29.09.2015 16:09, Michael Van Canneyt wrote:

Both are OK. Use of one does not exclude use of the other.

I was going to add it in CustApp anyway as soon as I had looked at 
your implementation.


I started working on the CustApp variant. It's even simpler than the LCL 
component because you can handle the check in DoRun() and so you don't 
need any timer or watch thread, if I am correct.


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:


On the other side, i still think that should be kept out of TCustomApplication.


Well, I have already explained why I want it exactly there :)


While the simple requirement of checking another
instance is easy to implement into TCustomApplication, others may want more
features / control (See bug report for examples). Those that need it would
duplicate part of the code.


Yes and no, it depends on how you expose the feature. 
When I said I want a single property, I meant of course that it can be enabled in it's most basic form 
with just property. That does not exclude that more properties can be exposed to offer more functionality.


The big advantage of Ondrej's functionality is that it will work on all 
platforms.
SimpleIPC will not work on all platforms.



Maybe create fpUniqueInstance on top of Ondrej work, making extensible and
plugabble?


Yes. I had thought about this too, we are of the same idea :-)

Let's first see how Ondrej does it.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Ondrej Pokorny wrote:


On 29.09.2015 16:09, Michael Van Canneyt wrote:

Both are OK. Use of one does not exclude use of the other.

I was going to add it in CustApp anyway as soon as I had looked at your 
implementation.


I started working on the CustApp variant. It's even simpler than the LCL 
component because you can handle the check in DoRun() and so you don't need 
any timer or watch thread, if I am correct.


That was what I thought too.

What I failed to see were provisions for per-user and global instances, maybe I 
missed them.
If not, these can be addressed later on.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:


Unit uniqueinstanceraw




Please look carefully


My sincere apologies,

I was too fast and indeed opened the wrong unit. uniqueinstance, and 
uniqueinstancebase, not uniqueinstanceraw :(

So, it could be used as well, if we can sort out the dependency on simpleipc.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Luiz Americo Pereira Camara]

2015-09-29 16:12 GMT-03:00 Michael Van Canneyt :

>
>
> On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
>
> Unit uniqueinstanceraw
>>
>
>
>> Please look carefully
>>
>
> My sincere apologies,
>
>
No problem.

To be clear, i don't plead to uniqueinstance be used by fpc or Lazarus at
all.

This is the message i sent to Lazarus dev list when discussing the
possibility of using in Lazarus IDE:

"
See
https://github.com/blikblum/luipack/blob/master/uniqueinstance/uniqueinstanceraw.pas
and
https://github.com/blikblum/luipack/blob/master/uniqueinstance/uniqueinstancebase.pas

This all the code that is needed to implement unique instance feature on
top of simpleipc.
Such simple logic could even be copied to IDE instead of using the package
itself
"

On the other side, i still think that should be kept out of
TCustomApplication. While the simple requirement of checking another
instance is easy to implement into TCustomApplication, others may want more
features / control (See bug report for examples). Those that need it would
duplicate part of the code.

Maybe create fpUniqueInstance on top of Ondrej work, making extensible and
plugabble?

Luiz
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[waldo kitty]

On 09/15/2015 12:07 PM, Tomas Hajny wrote:

On Tue, September 15, 2015 10:04, Michael Van Canneyt wrote:

On Tue, 15 Sep 2015, Ondrej Pokorny wrote:

  .
  .

Are there some high level crossplatform semaphore functions in the FCL?
The cthreads/cIntSemaphoreOpen etc. seem to be available on unix only.
What about OS/2?


Careful, these are thread semaphores, I think. I am talking about
cross-process semaphores. They are in the baseunix/unix units.

I suppose OS/2 has semaphores, but Tomas will need to confirm.


OS/2 certainly has semaphores (three types of them, in fact ;-) - event
semaphores, mutex semaphores and muxwait semaphores).


and there's also file based semaphores still used by a huge number of programs 
to signal needed actions between disparate programs that may be pressed into 
operation together ;)


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] simpleipc issues

[Ondrej Pokorny]

I've developed a "single/multiple instances" feature for the Lazarus 
IDE. For this feature I need an IPC. First I tried to use simpleipc but 
I have struggled on bugs and missing functionality.


Particularly what I found:
1.) BUG: You can register multiple servers on Windows with the same name 
(with StartServer procedure).
2.) Small issue: simpleipc uses exceptions if something fails (e.g. in 
StartServer procedure). I would prefer using a function with boolean 
result (true = OK, false = fail).

3.) MISSING: Multiple clients (from different processes) talk to one server.
4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a 
server that isn't running. The server is able to handle these requests 
when it is started.


So I developed "advancedipc.pas" that does what I need. It can do 
everything that is in simpleirc but a little bit differently (I changed 
the exception behavior and also method names). The question is now what 
to do?

1.) Include advancedipc.pas into FCL as a standalone unit.
2.) Make advancedipc.pas backwards compatible to simpleipc.pas and use 
the new code in simpleipc.pas.


I attached the advancedipc.pas file.
The discussion about "multiple instances" is here: 
http://bugs.freepascal.org/view.php?id=8051


Ondrej
{
*** Please use appropriate header ***

License standard LCL (GPL/LGPL ?)


  Author: Ondrej Pokorny

  Abstract:
Unit implementing two-way (request/response) IPC between 1 server and more 
clients

 **}
unit AdvancedIPC;

{$mode objfpc}{$H+}

interface

uses
  {$IFDEF UNIX}
  baseunix,
  {$endif}
  sysutils, Classes;

const
  HEADER_VERSION = 1;

type
  TMessageHeader = packed record
HeaderVersion: Integer;
FileLock: Byte;//0 = unlocked, 1 = locked
MsgType: Integer;
MsgLen: Integer;
MsgVersion: Integer;
  end;

  TFileHandle = Classes.THandle;

  TReleaseHandleStream = class(THandleStream)
  public
destructor Destroy; override;
  end;

  TIPCBase = class
  private
FGlobal: Boolean;
FFileName: string;
FServerName: string;
FMessageVersion: Integer;
  protected
class function ServerNameToFileName(const aServerName: string; const 
aGlobal: Boolean): string;
function GetResponseFileName(const aMsgID: Integer): string;
function GetResponseFileName(const aRequestFileName: string): string;
function GetRequestPrefix: string;
function GetRequestFileName(const aMsgID: Integer): string;
function RequestFileNameToMsgID(const aFileName: string): Integer;

function GetUniqueRequest(out outFileName: string): Integer;
procedure SetServerName(const aServerName: string); virtual;
procedure SetGlobal(const aGlobal: Boolean); virtual;

function CanReadMessage(const aFileName: string; out outStream: TStream; 
out outMsgType, outMsgLen: Integer): Boolean;
procedure DoPostMessage(const aFileName: string; const aMsgType: Integer; 
const aStream: TStream);

property FileName: string read FFileName;
  public
constructor Create; virtual;
  public
class procedure FindRunningServers(const aServerNamePrefix: string;
  const outServerNames: TStrings; const aGlobal: Boolean = False);
class function ServerIsRunning(const aServerName: string; const aGlobal: 
Boolean = False): Boolean;
property ServerName: string read FServerName write SetServerName;
property Global: Boolean read FGlobal write SetGlobal;
property MessageVersion: Integer read FMessageVersion write FMessageVersion;
  end;

  TIPCClient = class(TIPCBase)
  var
FLastMsgFileName: string;
  public
function PostRequest(const aMsgType: Integer; const aStream: TStream): 
Integer;//returns ID
function PeekResponse(const aStream: TStream; var outMsgType: Integer; 
const aTimeOut: Integer): Boolean;
procedure DeleteRequest;
function ServerRunning: Boolean;
  end;

  TIPCServer = class(TIPCBase)
  private
FFileHandle: TFileHandle;
FActive: Boolean;

function FindFirstRequest(out outFileName: string; out outStream: TStream; 
out outMsgType, outMsgLen: Integer): Integer;

  protected
procedure SetServerName(const aServerName: string); override;
procedure SetGlobal(const aGlobal: Boolean); override;
  public
constructor Create; override;
destructor Destroy; override;
  public
function PeekRequest(const aStream: TStream; var outMsgType: Integer): 
Boolean; overload;
function PeekRequest(const aStream: TStream; var outMsgID, outMsgType: 
Integer): Boolean; overload;
function PeekRequest(const aStream: TStream; var outMsgID, outMsgType: 
Integer; const aTimeOut: Integer): Boolean; overload;
procedure PostResponse(const aMsgID: Integer; const aMsgType: Integer; 
const aStream: TStream);

function FindHighestPendingRequestId: Integer;
function GetPendingRequestCount: Integer;

function StartServer(const 

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On Tue, September 15, 2015 08:58, Michael Van Canneyt wrote:
> On Mon, 14 Sep 2015, Ondrej Pokorny wrote:
>
>> I've developed a "single/multiple instances" feature for the Lazarus
>> IDE. For
>> this feature I need an IPC. First I tried to use simpleipc but I have
>> struggled on bugs and missing functionality.
>>
>> Particularly what I found:
>> 1.) BUG: You can register multiple servers on Windows with the same name
>> (with StartServer procedure).
>> 2.) Small issue: simpleipc uses exceptions if something fails (e.g. in
>> StartServer procedure). I would prefer using a function with boolean
>> result
>> (true = OK, false = fail).
>> 3.) MISSING: Multiple clients (from different processes) talk to one
>> server.
>> 4.) MISSING: Client is able to receive a response on a request.
>> 5.) MISSING: (Optionally, not default) client sends a request to a
>> server
>> that isn't running. The server is able to handle these requests when it
>> is
>> started.
>>
>> So I developed "advancedipc.pas" that does what I need. It can do
>> everything
>> that is in simpleirc but a little bit differently (I changed the
>> exception
>> behavior and also method names). The question is now what to do?
>> 1.) Include advancedipc.pas into FCL as a standalone unit.
>> 2.) Make advancedipc.pas backwards compatible to simpleipc.pas and use
>> the
>> new code in simpleipc.pas.
>
> Well, both 1 and 2 are the way to go if you want it included in FPC :-)
>
> I see no point in including duplicate functionality, it means duplicate
> maintenance.
> You can keep it as separate units, just make sure simpleipc runs on top of
> advancedipc.
 .
 .

One additional remark - it would be useful to have a test/example using
advancedipc directly, so that users can base their code on it and platform
maintainers can test easily and reliably whether the code works correctly
on their platform (e.g. me on OS/2 ;-) ).

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Mon, 14 Sep 2015, Ondrej Pokorny wrote:

I've developed a "single/multiple instances" feature for the Lazarus IDE. For 
this feature I need an IPC. First I tried to use simpleipc but I have 
struggled on bugs and missing functionality.


Particularly what I found:
1.) BUG: You can register multiple servers on Windows with the same name 
(with StartServer procedure).
2.) Small issue: simpleipc uses exceptions if something fails (e.g. in 
StartServer procedure). I would prefer using a function with boolean result 
(true = OK, false = fail).

3.) MISSING: Multiple clients (from different processes) talk to one server.
4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a server 
that isn't running. The server is able to handle these requests when it is 
started.


So I developed "advancedipc.pas" that does what I need. It can do everything 
that is in simpleirc but a little bit differently (I changed the exception 
behavior and also method names). The question is now what to do?

1.) Include advancedipc.pas into FCL as a standalone unit.
2.) Make advancedipc.pas backwards compatible to simpleipc.pas and use the 
new code in simpleipc.pas.


Well, both 1 and 2 are the way to go if you want it included in FPC :-)

I see no point in including duplicate functionality, it means duplicate maintenance. 
You can keep it as separate units, just make sure simpleipc runs on top of advancedipc.


As for no semaphores on linux: of course there are semaphores, they exist since 
many many years, they are part of POSIX: "man sem_overview".


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 15.09.2015 08:58, Michael Van Canneyt wrote:

On Mon, 14 Sep 2015, Ondrej Pokorny wrote:

I've developed a "single/multiple instances" feature for the Lazarus 
IDE. For this feature I need an IPC. First I tried to use simpleipc 
but I have struggled on bugs and missing functionality.


Particularly what I found:
1.) BUG: You can register multiple servers on Windows with the same 
name (with StartServer procedure).
2.) Small issue: simpleipc uses exceptions if something fails (e.g. 
in StartServer procedure). I would prefer using a function with 
boolean result (true = OK, false = fail).
3.) MISSING: Multiple clients (from different processes) talk to one 
server.

4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a 
server that isn't running. The server is able to handle these 
requests when it is started.


So I developed "advancedipc.pas" that does what I need. It can do 
everything that is in simpleirc but a little bit differently (I 
changed the exception behavior and also method names). The question 
is now what to do?

1.) Include advancedipc.pas into FCL as a standalone unit.
2.) Make advancedipc.pas backwards compatible to simpleipc.pas and 
use the new code in simpleipc.pas.


Well, both 1 and 2 are the way to go if you want it included in FPC :-)

I see no point in including duplicate functionality, it means 
duplicate maintenance. You can keep it as separate units, just make 
sure simpleipc runs on top of advancedipc.


As for no semaphores on linux: of course there are semaphores, they 
exist since many many years, they are part of POSIX: "man sem_overview".


Michael.


Thanks a lot Michael!

I'll prepare it, write (unit) tests and some demo and then send them 
over! Thanks also for the semaphore information. I couldn't find 
anything on the internet, therefore I thought Lazarus doesn't support them.


Are there some high level crossplatform semaphore functions in the FCL? 
The cthreads/cIntSemaphoreOpen etc. seem to be available on unix only. 
What about OS/2?


What about Windows? It looks like semaphores are supported only since 
XP: 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682438(v=vs.85).aspx 
. Is this a problem for the FCL? (Basically, semaphores are only needed 
on unix due to the file locking. But I am still interested.)


If I'll have more questions, I'll write them here.

Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 15 Sep 2015, Ondrej Pokorny wrote:


On 15.09.2015 08:58, Michael Van Canneyt wrote:

On Mon, 14 Sep 2015, Ondrej Pokorny wrote:

I've developed a "single/multiple instances" feature for the Lazarus IDE. 
For this feature I need an IPC. First I tried to use simpleipc but I have 
struggled on bugs and missing functionality.


Particularly what I found:
1.) BUG: You can register multiple servers on Windows with the same name 
(with StartServer procedure).
2.) Small issue: simpleipc uses exceptions if something fails (e.g. in 
StartServer procedure). I would prefer using a function with boolean 
result (true = OK, false = fail).
3.) MISSING: Multiple clients (from different processes) talk to one 
server.

4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a server 
that isn't running. The server is able to handle these requests when it is 
started.


So I developed "advancedipc.pas" that does what I need. It can do 
everything that is in simpleirc but a little bit differently (I changed 
the exception behavior and also method names). The question is now what to 
do?

1.) Include advancedipc.pas into FCL as a standalone unit.
2.) Make advancedipc.pas backwards compatible to simpleipc.pas and use the 
new code in simpleipc.pas.


Well, both 1 and 2 are the way to go if you want it included in FPC :-)

I see no point in including duplicate functionality, it means duplicate 
maintenance. You can keep it as separate units, just make sure simpleipc 
runs on top of advancedipc.


As for no semaphores on linux: of course there are semaphores, they exist 
since many many years, they are part of POSIX: "man sem_overview".


Michael.


Thanks a lot Michael!

I'll prepare it, write (unit) tests and some demo and then send them over! 
Thanks also for the semaphore information. I couldn't find anything on the 
internet, therefore I thought Lazarus doesn't support them.


Are there some high level crossplatform semaphore functions in the FCL? The 
cthreads/cIntSemaphoreOpen etc. seem to be available on unix only. What about 
OS/2?


Careful, these are thread semaphores, I think. 
I am talking about cross-process semaphores. They are in the baseunix/unix units.


I suppose OS/2 has semaphores, but Tomas will need to confirm. 
But if OS/2 currently does not support simpleIPC, then the point is moot anyway.




What about Windows? It looks like semaphores are supported only since XP: 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682438(v=vs.85).aspx 
. Is this a problem for the FCL? (Basically, semaphores are only needed on 
unix due to the file locking. But I am still interested.)


Officially, FPC no longer supports Windows 95. The compiler and most parts of the 
RTL will function on Windows 95, so it will do some basic stuff.


For the FCL, I really do not see this as a problem. 
If you need advanced IPC such as this, you will no longer be using Windows 95.

We must be practical in such matters.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Jonas Maebe]

On 15/09/15 13:33, Ondrej Pokorny wrote:

This is because Michael Van Canneyt pointed me to "man sem_overview".
The first Google search pointed me to
http://linux.die.net/man/7/sem_overview  where I found the "Named
semaphores" with functions sem_open,  sem_close etc. with the
description that they can be used across processes. A quick search in
FPC sources pointed me again to the cthreads unit.


All semaphore use has been removed from the cthreads unit in the mean time.

They also should not be used on OS X anymore, because Apple forbids 
their use in applications submitted to their appstore (I guess because 
it is difficult for system frameworks to automatically determine whether 
they are only used in safe way; i.e., in a way that doesn't make the 
codesigned host application into a proxy for any other application to 
carry out operations on their behalf).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Ondrej Pokorny]

On 15.09.2015 13:22, Michael Schnell wrote:

On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:


IPC = Inter PROCESS Communication.

I know that you know this, but Ondrej is talking about cthreads in one 
of his message, so I tried to politely set a trigger.


-Michael


This is because Michael Van Canneyt pointed me to "man sem_overview". 
The first Google search pointed me to 
http://linux.die.net/man/7/sem_overview  where I found the "Named 
semaphores" with functions sem_open,  sem_close etc. with the 
description that they can be used across processes. A quick search in 
FPC sources pointed me again to the cthreads unit.
I haven't done any Linux development with semaphores, so sorry if I am 
completely wrong here. I will also welcome if you correct me.


BUT semaphores are not directly needed by the IPC. simpleipc doesn't use 
them either.


It would be nice to have solved the issue with double file locks on 
unix, but this is not the core problem.


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 15 Sep 2015, Michael Schnell wrote:


On 09/14/2015 03:56 PM, Ondrej Pokorny wrote:
3.) MISSING: Multiple clients (from different processes) talk to one 
server.

4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a server 
that isn't running. The server is able to handle these requests when it is 
started.


Do I understand correctly that you are talking about "real" inter-Process 
communication and not inter-Tread-Communication within the same project ? 
(IMHO, this would require completely different paradigms.)


IPC = Inter PROCESS Communication.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Schnell]

On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:


IPC = Inter PROCESS Communication.

I know that you know this, but Ondrej is talking about cthreads in one 
of his message, so I tried to politely set a trigger.


-Michael


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Tomas Hajny]

On Tue, September 15, 2015 10:04, Michael Van Canneyt wrote:
> On Tue, 15 Sep 2015, Ondrej Pokorny wrote:
 .
 .
>> Are there some high level crossplatform semaphore functions in the FCL?
>> The
>> cthreads/cIntSemaphoreOpen etc. seem to be available on unix only. What
>> about
>> OS/2?
>
> Careful, these are thread semaphores, I think.
> I am talking about cross-process semaphores. They are in the baseunix/unix
> units.
>
> I suppose OS/2 has semaphores, but Tomas will need to confirm.

OS/2 certainly has semaphores (three types of them, in fact ;-) - event
semaphores, mutex semaphores and muxwait semaphores).


> But if OS/2 currently does not support simpleIPC, then the point is moot
> anyway.

See packages/fcl-process/src/os2/simpleipc.inc. Moreover, the code posted
by Ondrej does not contain anything that should not compile on OS/2 at the
first sight, that's why I wanted to have a test allowing to check whether
it really works. The fact that sending messages across processes would be
usually implemented differently if using OS/2 API features directly may
not be so important.

Tomas


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 15 Sep 2015, Tomas Hajny wrote:


On Tue, September 15, 2015 10:04, Michael Van Canneyt wrote:

On Tue, 15 Sep 2015, Ondrej Pokorny wrote:

.
.

Are there some high level crossplatform semaphore functions in the FCL?
The
cthreads/cIntSemaphoreOpen etc. seem to be available on unix only. What
about
OS/2?


Careful, these are thread semaphores, I think.
I am talking about cross-process semaphores. They are in the baseunix/unix
units.

I suppose OS/2 has semaphores, but Tomas will need to confirm.


OS/2 certainly has semaphores (three types of them, in fact ;-) - event
semaphores, mutex semaphores and muxwait semaphores).


Excellent !





But if OS/2 currently does not support simpleIPC, then the point is moot
anyway.


See packages/fcl-process/src/os2/simpleipc.inc. Moreover, the code posted
by Ondrej does not contain anything that should not compile on OS/2 at the
first sight, that's why I wanted to have a test allowing to check whether
it really works. The fact that sending messages across processes would be
usually implemented differently if using OS/2 API features directly may
not be so important.


Well, the implementation looks as if it will work on all platforms.

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Schnell]

On 09/14/2015 03:56 PM, Ondrej Pokorny wrote:
3.) MISSING: Multiple clients (from different processes) talk to one 
server.

4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a 
server that isn't running. The server is able to handle these requests 
when it is started.


Do I understand correctly that you are talking about "real" 
inter-Process communication and not inter-Tread-Communication within the 
same project ? (IMHO, this would require completely different paradigms.)


I understand that IPC is done with non-Lazarus projects in mind. Hence 
it is done to be used "straight forward"  independent of the Lazarus 
Event Queue. If doing something on top of SimpleIPC it might be viable 
to consider Event Queue integration for Lazarus users, as well (but If 
you don't consider Lazarus this might be a completely unrelated issue).


-Michael


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Schnell]

On 09/15/2015 02:43 PM, Michael Van Canneyt wrote:


With my paranoid mind I of course assumed you were hijacking the 
thread...
Of course I was eagerly waiting on Ondrej to confirm that he was looking 
for thread support :-) :-) :-)


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] simpleipc issues

[Michael Van Canneyt]

On Tue, 15 Sep 2015, Michael Schnell wrote:


On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:


IPC = Inter PROCESS Communication.

I know that you know this, but Ondrej is talking about cthreads in one of his 
message, so I tried to politely set a trigger.


With my paranoid mind I of course assumed you were hijacking the thread...

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Lazarus issues on ARM Linux

[Thaddy]

On 8-4-2013 14:49, peter green wrote:

Michel Catudal wrote:
I am also having some issues with Lazarus, I am not sure if it is the 
right forum to talk about it. I had a previous version working fine 
on Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have 
compiled it on gentoo on the Mele, using distcc and locally, same 
results. I didn't get any error during compile so I was expecting it 
to work. fpc seems to work, I haven't written any code with it yet, I 
was expecting to use lazarus to do that.


My system on Mele A2000G is gentoo with mate desktop. I have 
everything compiled with hard float as I did on the Raphsberry Pi. 
Upstream 2.6.x does not support the hard float ABI so unless you have 
a patched version (such as the one shipped in debian) it won't 
correctly link against C libraries on a system that uses hard float 
ABIS. Also even when the hard float ABI support is present in the 
compiler source code you need to either bootstrap with a starting 
compiler that uses the hard float ABI or explictly specify -d 
FPC_ARMHF during the build.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
At the moment the current lazarus doesn't compile here for trunk, not 
even on raspberry. A couple of days ago it did.
But this is today. I will put in a bug report if I checked my build 
stup, can reproduce it and if so  isn't fixed within two days or so. 
Most of the time it will.
You probably definitely must use trunk to get proper results for arm. 
Lot's of changes/improvements.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Lazarus issues on ARM Linux

[peter green]

Michel Catudal wrote:
I am also having some issues with Lazarus, I am not sure if it is the 
right forum to talk about it. I had a previous version working fine on 
Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have compiled 
it on gentoo on the Mele, using distcc and locally, same results. I 
didn't get any error during compile so I was expecting it to work. fpc 
seems to work, I haven't written any code with it yet, I was expecting 
to use lazarus to do that.


My system on Mele A2000G is gentoo with mate desktop. I have 
everything compiled with hard float as I did on the Raphsberry Pi. 
Upstream 2.6.x does not support the hard float ABI so unless you have a 
patched version (such as the one shipped in debian) it won't correctly 
link against C libraries on a system that uses hard float ABIS. Also 
even when the hard float ABI support is present in the compiler source 
code you need to either bootstrap with a starting compiler that uses the 
hard float ABI or explictly specify -d FPC_ARMHF during the build.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Lazarus issues on ARM Linux

[mcatudal]

- Original Message -
From: peter green plugw...@p10link.net 
To: FPC developers' list fpc-devel@lists.freepascal.org 
Sent: Monday, April 8, 2013 8:49:06 AM 
Subject: Re: [fpc-devel] Lazarus issues on ARM Linux 

Michel Catudal wrote: 
 I am also having some issues with Lazarus, I am not sure if it is the 
 right forum to talk about it. I had a previous version working fine on 
 Rasphberry Pi. 
 For some reason I can't get it to work on Mele A2000G. I have compiled 
 it on gentoo on the Mele, using distcc and locally, same results. I 
 didn't get any error during compile so I was expecting it to work. fpc 
 seems to work, I haven't written any code with it yet, I was expecting 
 to use lazarus to do that. 
 
 My system on Mele A2000G is gentoo with mate desktop. I have 
 everything compiled with hard float as I did on the Raphsberry Pi. 
Upstream 2.6.x does not support the hard float ABI so unless you have a 
patched version (such as the one shipped in debian) it won't correctly 
link against C libraries on a system that uses hard float ABIS. Also 
even when the hard float ABI support is present in the compiler source 
code you need to either bootstrap with a starting compiler that uses the 
hard float ABI or explictly specify -d FPC_ARMHF during the build. 
___ 
fpc-devel maillist - fpc-devel@lists.freepascal.org 
http://lists.freepascal.org/mailman/listinfo/fpc-devel 







This web editor from comcast doesn't work correctly, only the winblows way with 
messages on top, so here : 


--- start of response-- 


I am not using an upstream binary file but compiled my own on gentoo. On gentoo 
you compile everything. The scripts that come with gentoo ARM are setup for 
hard floats only. I will check what you are saying tonight anyway. I will first 
write some pascal code to test. I think that lazarus might be the only problem 
since fpc didn't barf when I ran it. 


I might have tried lazarus on debian on Rasphberry Pi, not sure, I will double 
check that. I know that it worked perfectly when I did and it was hard float. I 
will just use Rasphberry pi as a programmer for AVR32 and PIC32, too slow for 
anything graphical. 


Michel ___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Lazarus issues on ARM Linux

[Michel Catudal]

Le 2013-04-08 13:44, mcatu...@comcast.net a écrit :


 I am not using an upstream binary file but compiled my own on gentoo. On 
 gentoo you compile everything. The scripts that come with gentoo ARM are 
 setup for hard floats only. I will check what you are saying tonight anyway. 
 I will first write some pascal
 code to test. I think that lazarus might be the only problem since fpc didn't 
 barf when I ran it.

 I might have tried lazarus on debian on Rasphberry Pi, not sure, I will 
 double check that. I know that it worked perfectly when I did and it was hard 
 float. I will just use Rasphberry pi as a programmer for AVR32 and PIC32, too 
 slow for anything graphical.

 Michel


It was on debian that I tested Lazarus. On my rasphberry Pi I tried both. I 
went to debian when I realized that it was no possible to get firefox compiled 
on gentoo on the rasphberry Pi. Funny thing, I had no problem compiling it on 
Mele A2000G same
version 17.0.
I did manage to compile Mate Desktop on the raphberry Pi. It is not very fast 
though, much better on Mele A2000G.

I will try to compile the way you explained later this week and will post my 
results.

-- 
For Linux Software visit
http://home.comcast.net/~mcatudal

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Lazarus issues on ARM Linux

[Michel Catudal]

I am also having some issues with Lazarus, I am not sure if it is the right 
forum to talk about it. I had a previous version working fine on Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have compiled it on gentoo on the Mele, using distcc and locally, same results. I didn't get any error during compile so I was expecting it to work. fpc seems to work, I haven't written any code with 
it yet, I was expecting to use lazarus to do that.


My system on Mele A2000G is gentoo with mate desktop. I have everything 
compiled with hard float as I did on the Raphsberry Pi.
This is a much faster ARM processor (1Ghz with 1G of RAM). Gentoo is on a 32G SD Card. Speed throttles down to 408 Mhz when idle, could that be the problem? If that is I might need to put a heatsink and recompile the uboot and/or kernel to stop the change 
in speed.


qt is 4.10.1  I have 4.9 on rasphberry pi

michel@catudal ~ $ lazarus
bash: /usr/bin/lazarus: Aucun fichier ou dossier de ce type
michel@catudal ~ $ ls -la /usr/bin/laz
lazarus   lazbuild
michel@catudal ~ $ ls -la /usr/bin/lazarus
lrwxrwxrwx 1 root root 29  4 avr 07:39 /usr/bin/lazarus - 
../share/lazarus/startlazarus
michel@catudal ~ $ ls -la /usr/share/lazarus/startlazarus
-rwxr-xr-x 1 root root 18763274  4 avr 07:30 /usr/share/lazarus/startlazarus
michel@catudal ~ $

michel@catudal ~ $ fpc
Free Pascal Compiler version 2.6.0 [2013/04/03] for arm

Lazarus is 1.0.4, i think that I have a slightly earlier version on  Rasphberry 
Pi. It works nicely on mate. Interesting considering that the browser isn't too 
good on it and some applications were rather slow. Rasphberry pi is much slower 
than the Mele A2000G


michel@catudal ~ $ emerge -p lazarus

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   *] dev-lang/lazarus-1.0.4


Michel Catudal

--
For Linux Software visit
http://home.comcast.net/~mcatudal

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Lazarus issues on ARM Linux

[Sven Barth]

Am 08.04.2013 02:34 schrieb Michel Catudal mcatu...@comcast.net:

 I am also having some issues with Lazarus, I am not sure if it is the
right forum to talk about it. I had a previous version working fine on
Rasphberry Pi.
 For some reason I can't get it to work on Mele A2000G. I have compiled it
on gentoo on the Mele, using distcc and locally, same results. I didn't get
any error during compile so I was expecting it to work. fpc seems to work,
I haven't written any code with it yet, I was expecting to use lazarus to
do that.

 My system on Mele A2000G is gentoo with mate desktop. I have everything
compiled with hard float as I did on the Raphsberry Pi.
 This is a much faster ARM processor (1Ghz with 1G of RAM). Gentoo is on a
32G SD Card. Speed throttles down to 408 Mhz when idle, could that be the
problem? If that is I might need to put a heatsink and recompile the uboot
and/or kernel to stop the change in speed.

 qt is 4.10.1  I have 4.9 on rasphberry pi

 michel@catudal ~ $ lazarus
 bash: /usr/bin/lazarus: Aucun fichier ou dossier de ce type
 michel@catudal ~ $ ls -la /usr/bin/laz
 lazarus   lazbuild
 michel@catudal ~ $ ls -la /usr/bin/lazarus
 lrwxrwxrwx 1 root root 29  4 avr 07:39 /usr/bin/lazarus -
../share/lazarus/startlazarus
 michel@catudal ~ $ ls -la /usr/share/lazarus/startlazarus
 -rwxr-xr-x 1 root root 18763274  4 avr 07:30
/usr/share/lazarus/startlazarus
 michel@catudal ~ $

 michel@catudal ~ $ fpc
 Free Pascal Compiler version 2.6.0 [2013/04/03] for arm

 Lazarus is 1.0.4, i think that I have a slightly earlier version on
 Rasphberry Pi. It works nicely on mate. Interesting considering that the
browser isn't too good on it and some applications were rather slow.
Rasphberry pi is much slower than the Mele A2000G


 michel@catudal ~ $ emerge -p lazarus

 These are the packages that would be merged, in order:

 Calculating dependencies... done!
 [ebuild   R   *] dev-lang/lazarus-1.0.4

Is it just me or did you forget to mention which problems you have exactly?

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Two issues with variant type definitions

[Sergei Gorelkin]

Hello,

Two questions I wanted to ask:

1) There are two variant type defintions (varxxx constants): one in compiler/symdef.pas, another one 
in rtl/inc/varianth.inc. Worse, they are out of sync. Is it really necessary to have a separate set 
of these definitions in compiler?


2) In FPC, varunicodestr=22 (in symdef.pas), while Delphi defines varUString=$102. Although meaning 
of these types are a bit different in FPC and Delphi, probably we should change varunicodestr in 
range  256, because values below 256 are used for types that are known to COM.

Are there objections/opinions on doing so?

Regards,
Sergei
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Two issues with variant type definitions

[Florian Klaempfl]

Am 11.11.2010 15:19, schrieb Sergei Gorelkin:
 Hello,
 
 Two questions I wanted to ask:
 
 1) There are two variant type defintions (varxxx constants): one in
 compiler/symdef.pas, another one in rtl/inc/varianth.inc. Worse, they
 are out of sync. Is it really necessary to have a separate set of these
 definitions in compiler?

Previously we always decided to keep two separate files, see e.g.
fpcinnr.inc and innr.inc, so I'd prefer just to update the compiler one.

 
 2) In FPC, varunicodestr=22 (in symdef.pas), while Delphi defines
 varUString=$102. Although meaning of these types are a bit different in
 FPC and Delphi, probably we should change varunicodestr in range  256,
 because values below 256 are used for types that are known to COM.
 Are there objections/opinions on doing so?

No.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Two issues with variant type definitions

[Sergei Gorelkin]

Florian Klaempfl пишет:

Am 11.11.2010 15:19, schrieb Sergei Gorelkin:

Hello,

Two questions I wanted to ask:

1) There are two variant type defintions (varxxx constants): one in
compiler/symdef.pas, another one in rtl/inc/varianth.inc. Worse, they
are out of sync. Is it really necessary to have a separate set of these
definitions in compiler?


Previously we always decided to keep two separate files, see e.g.
fpcinnr.inc and innr.inc, so I'd prefer just to update the compiler one.


Ok, I'll then add comments reminding to update another copy in sync.

Sergei
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] $IF issues

[Peter Vreman]

 Looking at the code below...

 {$if defined(ver2_0)}
   {$note This is not delphi compatible. }
 {$endif}


 Is this a feature or a FPC bug?  FPC allows the $IF to be closed with
 the $ENDIF as well as the $IFEND.  This is not Delphi compatible.

 The closing tag for $IF is $IFEND
 The closing tag for $IFDEF is $ENDIF

Feature.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] $IF issues

[Daniël Mantione]

Op Mon, 14 Aug 2006, schreef Graeme Geldenhuys:

 On 8/14/06, Peter Vreman [EMAIL PROTECTED] wrote:
   Is this a feature or a FPC bug?  FPC allows the $IF to be closed
   with
   the $ENDIF as well as the $IFEND.  This is not Delphi compatible.
   
   The closing tag for $IF is $IFEND
   The closing tag for $IFDEF is $ENDIF

As I read it, $IF/$IFEND was added to Delphi in Delphi 6. FPC supports 
this construction much longer, I think since the 0.9.x series. The FPC way 
has always been to use $ENDIF and FPC will of course not break 
compatibility with itself. Go ask Borland why they wanted to be FPC 
incompatible :)

  
  Feature.
 
 Maybe this should be controlled by the compiler mode?  Delphi vs
 ObjFPC.  Or should we leave it up to the developer to remember which
 one to use when writing code to be compiled with Delphi and FPC?

You could make it dependent on the compiler mode, but I don't see the 
point, any Delphi code will still compile.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] $IF issues

[Graeme Geldenhuys]

On 8/14/06, Vincent Snijders [EMAIL PROTECTED] wrote:

You miss the point: Delphi compatibility mode is for people who develop for 
FPC, but
want to compile occasionally in Delphi. In the current situation they are not 
aware
of this weakness of Delphi (no support of $ENDIF for $IF), until they compile in
Delphi.


That is exactly what happened.  I only develop under FPC, but
contribute a lot to the tiOPF project, which is mostly used by Delphi
developers.   I broke the Delphi builds by adding the $IF..$ENDIF
code.  The tiOPF project uses the Delphi Mode for the FPC compiler,
and I was surprised when notified of the problem.


But maybe Graeme should make a Delphi feature request too (and see which is
honoured first) :-)


Where do I go, to ask for such a feature in Borland Delphi?  I guess
it would take years to materialize. :-)   Borland is not as pro-active
as the FPC maintainers!!

Regards,
 Graeme.


--
There's no place like 127.0.0.1
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] $IF issues

[Daniël Mantione]

Op Mon, 14 Aug 2006, schreef Vincent Snijders:

 You miss the point: Delphi compatibility mode is for people who develop for
 FPC, but want to compile occasionally in Delphi.

It can be used that way, but its main purpose is to support Delphi 
constructions that we consider broken and therefore do not want in objpas 
mode. To write new code that is compilable by both FPC and Delphi, Objpas 
mode should suit as well as Delphi mode.

 In the current situation they
 are not aware of this weakness of Delphi (no support of $ENDIF for $IF), until
 they compile in Delphi. But maybe Graeme should make a Delphi feature request
 too (and see which is honoured first) :-)

In all modes a significant portion of FPC functionality is still enabled; 
the modes not designed with this goal in mind. It will always be possible 
to write code in FPC that Delphi doesn't accept; for example there exists 
no sane way you can prevent people from using FPC specific features in the 
RTL.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] $IF issues

[Michael Van Canneyt]

On Mon, 14 Aug 2006, Daniël Mantione wrote:




Op Mon, 14 Aug 2006, schreef Vincent Snijders:


You miss the point: Delphi compatibility mode is for people who develop for
FPC, but want to compile occasionally in Delphi.


It can be used that way, but its main purpose is to support Delphi
constructions that we consider broken and therefore do not want in objpas
mode. To write new code that is compilable by both FPC and Delphi, Objpas
mode should suit as well as Delphi mode.


This is not quite correct: Think of e.g. the @Method issue.

And the Delphi/TP modes are designed to be as Delphi/TP compatible as possible.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] $IF issues

[Graeme Geldenhuys]

On 8/14/06, Daniël Mantione [EMAIL PROTECTED] wrote:

mode. To write new code that is compilable by both FPC and Delphi, Objpas
mode should suit as well as Delphi mode.


Not quite!  The project I am working on (tiOPF) is mainly used by
Delphi developers, as I mentioned before.  My first thought was to use
tiOPF with FPC in compiler mode ObjFPC.  I had to add over a hundred
IFDEF's for all the @ProcedureName assignments.  A few months later,
the Delphi delevelopers got sick of all the IFDEF's in the code.  I
changed the FPC compiler mode to Delphi and could remove all those
IFDEF's with the @ sign.  That is just one such difference in the
compiler modes.

Regards,
 - Graeme -



--
There's no place like 127.0.0.1
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] $IF issues

[Florian Klaempfl]

Graeme Geldenhuys wrote:

On 8/14/06, Vincent Snijders [EMAIL PROTECTED] wrote:
You miss the point: Delphi compatibility mode is for people who 
develop for FPC, but
want to compile occasionally in Delphi. In the current situation they 
are not aware
of this weakness of Delphi (no support of $ENDIF for $IF), until they 
compile in

Delphi.


That is exactly what happened.  I only develop under FPC, but
contribute a lot to the tiOPF project, which is mostly used by Delphi
developers.   I broke the Delphi builds by adding the $IF..$ENDIF
code.  The tiOPF project uses the Delphi Mode for the FPC compiler,
and I was surprised when notified of the problem.


Well, the delphi mode is made to compile delphi programs with fpc not to check 
your programs for delphi compliance ;)





But maybe Graeme should make a Delphi feature request too (and see 
which is

honoured first) :-)


Where do I go, to ask for such a feature in Borland Delphi?  I guess
it would take years to materialize. :-)   Borland is not as pro-active
as the FPC maintainers!!

Regards,
 Graeme.




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Daniël Mantione]

Op Tue, 18 Jul 2006, schreef Jonas Maebe:

 You need something more than merely the remapping of library names.

As I said, you can remap unit names. At some point the user will have to 
decide to which one he wants to link, doing it by a unit name remap looks 
an elegant solution to me.

   I think all this competing with C and not-invented-here syndrome is
   downright silly, along with all the claiming that most bad things
   come from C.
  
  That was Almindor not me.
 
 I was replying to a mail from Daniel.

Doesn't matter: Marco was pointing out that all the (bandaid) stuff was 
designed for a single toolchain: gcc. We have the opportunity to do better, and 
therefore save our users from all kinds of bandaids gcc users need.

If you think supporting gtk-config doesn't hurt the users: If we don't fix 
this properly, our users will feel necessary to write this kind of 
band-aids for their own libraries as well.

  and parse it and try to merge it
  with our own state and support that?
 
 For the external linker not a single bit of internal state merging is
 necessary. It's just a fire-and-forget string. For the internal linker, yes,
 you need some kind of parsing just like you need it for the assembler reader
 and the binary writer (like Daniel mentioned iirc).

I'm quite sure it will at some point be necessary to parse it even for 
the external linker, we had our own parsers before we had an internal 
assembler. 

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Vinzent Hoefler]

On Monday 17 July 2006 15:33, Micha Nelissen wrote:
 Vinzent Hoefler wrote:
  Of course they don't. Unlike some other languages where such things
  are standardized quite clearly, (most) consistency, dependency and
  linking issues are beyond the scope of the official C-standard.

 I'm not talking about the C language, but the vendors, the C library
 implementors, etc.

And I was talking about the deficiency of its language definition that 
leads to exactly what your complaining about.

Don't make the mistake to reduce language to syntax only.


Vinzent.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

 Tue, Jul 18, 2006 at 01:22:40AM +0200, Jonas Maebe wrote:
 libnames when determining how to link, with the default being 1:1.
 
 I know, but I was trying to point out that e.g. on Mac OS X sometimes  
 you may need
 
 -lgtk-1.2.0 -lgdk-1.2.0 -lgdk_pixbuf
 
 and sometimes
 
 -framework Gtk+-Cocoa
 
 and sometimes
 
 -framework Gtk-Carbon

 (and there's a fourth native Mac OS X gtk port underway, because  
 the two previous ones were never really finished)
 
 You need something more than merely the remapping of library names.

I know. We already need more to change libs from static to shared. And I
knew there was more, which I wanted this as formally undocumented
functionality. IIRC I referenced that in the mail to core about the
linkordering.

I'm not entirely happy having put this in parameter form. A keyword based
configuration file is a better way.
 
 discovery process must be done up front).
 
 I want more out of source.
 
 I don't really care where exactly the information is stored (although  
 the unit somehow seems logical to me, if you want to keep the  
 interface and libs specification together),

Yes and no. The unit should only reference some abstract keyword, and the
mapping to exact actions should happen outside the source. Otherwise
overriding becomes nearly impossible.

Maybe this can be easily introduced by having a second parameter to linklib.
something like 

{$linklib packagename,libraryname} // the comma makes it possible to
keep the old syntax also for migrational purposes.

We can then e.g. easily transform either on libraries or on groups of
libraries ( the packagename above, in the linklib), e.g. to -framework.

This would work for your system too, for the same reasons. If something
fails (e.g. wrong script called, since the new version names it differently,
or some distribution renames it to something-x.y because of a newer version
occupies the something name), you'd be able to override simply by
installing a new config file (no new binaries or precompiled sourcetree
needed)

This is also the main reason to make this config a separate file, or a
fpc.cfg #include. Default not for user editing.

So the hoisting out of the source (and too much hardcoding in t_*) should be
separate from if we go -config or manual. The abstract, transformable
representation is needed in either case, also to allow overrides on the
-config usage.

  but if we change things from the way they are now, then the information
 should be dynamic (i.e., not merely determined at install time, because
 that only shifts the problem) and preferably come from available automatic
 sources (as opposed to the developer having to specify it).

You could simply exit with a hint to run the configuration tool if you
detect that ldconfig has been run. ldconfig is the key here, because to my
limited knowledge it should be run after library changes. 

But IMHO this automatic behaviour is a disaster waiting to happen.
Untransparant, unsupportable, to easily broken, hard to override (it is
easier to let the user make FPC specific config changes, than to have him
edit global pkgconfig and risk breaking his KDE)

But as long as the automated is not the default (which then can be
automatically turned on by IDEs), I don't care, as long as I don't have to
support it.

(Most of the rest of the discussion skipped, only replying to concrete
parts. Viewpoints won't change with more discussion anyway)

 The problem is that it needs to be refed every time you compile  
 something using particular units (those depending on libraries  
 requiring this mumbo-jumbo).

(I didn't get this? Surely reading an own config file is quicker than
calling a bunch of external _scripts_ ?)

 This because I want to be able to say mail me your compiler state, and
 send back a new one. Too much automatism will make things less
 transparant. To the user, but also to the one who has to support it.
 
 That's what -al -s is for.

Too crude. Only the output, not the input. Maybe combined with -va it could
work if enough msgs were emitted with relevant info, but way overkill for
99% of the cases that revolve recognizing variations of a few common
scenario's.
 
(Unix philosophy)
 _eighties_ Unix philosophy. Have you seen the sheer size of an avg Linux
 distribution?
 
 Many small things (and some larger, like OpenOffice.org) together  
 make for large sizes.

I haven't seen small things made in recent years, and previously small
things have grown big.

gcc isn't exactly small, neither is glibc or KDE or Gnome or Eclipse or
Mozilla or Evolution or Samba, or X or anything that the user sees. And
nearly any of them are not run by volunteers anymore either. Nearly all have
fulltimers.

The only stuff that is small are the remnants of the said eighties unix
culture. Tail,wc and friends. The newer branches of that family (perl,
python etc) are all again huge.

 and parse it and try to merge it
 with our own state and support that?
 
 For the external linker not a single 

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Aleš Katona]

Alright everyone, just stop this ok?

I was angry like hell when I first read the ORIGINAL poster's message
about FreeBSD (hint, topic no longer valid in your discussion) I got
even more angry and my response was very immature. I would like to
apologise to everyone and especialy the original poster for my tone.

This whole discussion is useless. I hate to be the one who brakes the
party, but it all started because I said a few completly untrue things
about C with relation to binary compatibility. Honestly I didn't expect
you guys to catch up (when I cooled down that is).

So there it goes, return to whatever you were doing before and we'll all
be better of I think.

Ales

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 18 Jul 2006, at 12:05, Aleš Katona wrote:


This whole discussion is useless.


Better library linking support is not useless.


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Bob]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ale? Katona wrote:

 
 Btw. fpc 2.0.2 is in ports now.
 

Just a binary distribution right? I did not see the sources in ports,
which would have to be patched to fix the lib naming errors.

 You need to symlink those libraries or patch manualy, but we can't
 change it to the new ones since anyone with FreeBSD 6.0 or older (if
 they didn't portupgrade) won't work then.
 

I patched
packages/extra/gtk/gdk/gdk.pp
packages/extra/gtk/gdk/gdk.pp
packages/extra/gtk/glib/glib.pp
in the 2.0.2 source tree to reflect the proper lib names

I then port-installed graphics/gdk-pixbuf, which provided the last
missing lib (/usr/X11R6/lib/libgdk_pixbuf.a)

Then Lazarus compiled and linked without error, and seems to run fine.

Are you saying that code produced by this Lazarus/FPC setup will not run
properly on older freebsd systems?

Seems to me that FPC-2.0.2 is broken as far as freebsd is concerned. It
can't be just lazarus which needs those libs properly defined; so what
we have here is essentially a bug fix to FPC itself.

 FPC 2.0.4 will have a new mechanism of libalias which will enable us
 to fix this by just adding either command line params (eg: fpc
 -Laglib=glib-12.so) or changing it in fpc.cfg for all compilations
 (preffered and porters can do this)
 

I don't understand, why not just fix the missing - in the IFDEF
FreeBSD statement, and produce a working FPC?

Bob
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEuygWAexE5bK/mHkRAmoXAJwIpLvEqBxi6NCSXZtlmFG99iC1wgCfVuGw
SR+WySQahOIX+0GtDmwQ+Js=
=bNo7
-END PGP SIGNATURE-
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Aleš Katona]

 Just a binary distribution right? I did not see the sources in ports,
 which would have to be patched to fix the lib naming errors.

Yes but one guy said he's working on source based one.

 Are you saying that code produced by this Lazarus/FPC setup will not run
 properly on older freebsd systems?

Yes
 
 Seems to me that FPC-2.0.2 is broken as far as freebsd is concerned. It
 can't be just lazarus which needs those libs properly defined; so what
 we have here is essentially a bug fix to FPC itself.

Seems to me that FreeBSD is broken as far as everything which uses those
libnames... it's not only fpc problem. Old binaries won't work on new
freeBSD and vice versa. It's their idiocy not our, we didn't rename
those libs 2x.

You don't have a bugfix, you can't ifdef ports version. It doesn't
depend on OS version of FreeBSD but on the fact that the person has new
ports or not. If someone on 6.0 updates his ports he'll have the new -
version of glib and others. Same for 5.4.

 I don't understand, why not just fix the missing - in the IFDEF
 FreeBSD statement, and produce a working FPC?

See above.
 
 Bob

Your signature is broken.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

 Greetings to the Fpc-Devel list:
 
 the following libraries were not found by ld: glib12, gdk12, and gtk12.

This is a know issue without good solution, since the problem originates in
the FreeBSD ports management.

The best solution is:

- for 2.0.2  manually create relevant symlinks to the libs.
- for 2.0.4, use linkaliasing 

 Funny! I moved away from Linux mainly because of Library-Hell issues :-)

Me too. I really hate the mentality behind this change. It made me
reconsider my stance on ports tree usage of FPC. (read: give it up)

(from a mail to sb else explaining this, I'll be adding this to the wiki
today in a modded form):

What happens is that all xxx12 libs were renamed to xxx-12 (note that this
is STILL different from conventional xxx-1.2)

FreeBSD Ports put this change silently in a doc in nov 2005, and removed the
old names in feb 2006 in -STABLE, and refuses to fix the port with a symlink
and thus have a longer grace period.

The only way you can know, inside the port building, is to test what name of
gtk lib exists (libgtk12 or libgtk-1.2, same for gdk12 and glib12). THE
CHANGE DOESN'T FOLLOW ANYT VERSION LINES IF YOU TRACK -STABLE.  They refer
to pkgconfig or keep on using the -RELEASE ports branch (which is security
only), 

Of course I can't take a tool that emits gcc parametes seriously (since
some ad hoc parsing will probably break on the first gcc change). 

So I consider calling pkgconfig/gtkconfig a way to fragile solution long
term, I decided to solve it differently, and have some form of config
options for them.

This because FPC wasn't entirely innocent too, in that library names in
sourcecode ($LINKLIB xxx) couldn't be changed after compilation, this is now
fixed in 2.0.4.

The 2.0.4 sourcecode defaults to the new library naming. If you install FPC
on a system with gtk compiled from the pre februari portstree (like a stock
6.0 release), you need to add

-XLAglib-12=glib12 
-XLAgdk-12=gdk12 
-XLAgtk-12=gtk12 

to the 2.0.4 fpc.cfg

It is also the most neutral choice. People that disagree with me can try to
hack up something to query pkgconfig and install that into fpc.cfg, without
risking breakage of the compiler due to some pkgconfig problem.

Note that the a 2.0.4 FreeBSD rc2 will become available today for testing.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Micha Nelissen]

Aleš Katona wrote:
 Hi Bob and welcome to the world of crap.
 
 Seriously and honestly, the FreeBSD porters made a big bad pile of crap
 when they some years ago decided to name gtk-12 and others as gtk12.
 
 Welcome to the world of shit.. eh sorry I ment unix.
 
 It was written in C what would you expect?

This is not a C based problem, you can do the same thing using FPC, but
only few people make libraries with FPC in the first place.

This issue is a typical source-based distribution problem, because when
you recompile everything from scratch every day (or, often) anyway, you
can change a whole lot more without breaking things than if you need to
keep binary packages in sync with each other.

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

 Ale? Katona wrote:
  Hi Bob and welcome to the world of crap.
  
  Seriously and honestly, the FreeBSD porters made a big bad pile of crap
  when they some years ago decided to name gtk-12 and others as gtk12.
  
  Welcome to the world of shit.. eh sorry I ment unix.
  
  It was written in C what would you expect?
 
 This is not a C based problem, you can do the same thing using FPC, but
 only few people make libraries with FPC in the first place.
 
 This issue is a typical source-based distribution problem, because when
 you recompile everything from scratch every day (or, often) anyway, you
 can change a whole lot more without breaking things than if you need to
 keep binary packages in sync with each other.

This has nothing to do with source based vs binary. If e.g. debian renamed
libs tomorrow inside a branch, it would have the same effect.

Note that the problems are the same in FreeBSD, source based or not.

It is simply bad release management. Probably they want to keep this 5.x and
6.x compat and feel that the hard way will convert most installations
quickly.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Michael Van Canneyt]

On Mon, 17 Jul 2006, Marco van de Voort wrote:


Greetings to the Fpc-Devel list:

the following libraries were not found by ld: glib12, gdk12, and gtk12.


This is a know issue without good solution, since the problem originates in
the FreeBSD ports management.

The best solution is:

- for 2.0.2  manually create relevant symlinks to the libs.
- for 2.0.4, use linkaliasing


Funny! I moved away from Linux mainly because of Library-Hell issues :-)




Library hell exists on all platforms. Running from it is futile.
Maybe the maintainers of one platform/OS distribution do slightly better
than the others, but in essence the problem always exists.

Even on Windows, where there is only 1 manufacturer, the problem exists.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

On Mon, Jul 17, 2006 at 10:50:33AM +0200, Michael Van Canneyt wrote:

 - for 2.0.2  manually create relevant symlinks to the libs.
 - for 2.0.4, use linkaliasing
 
 Funny! I moved away from Linux mainly because of Library-Hell issues :-)
 
 Library hell exists on all platforms. Running from it is futile.

It is not a purely qualitative thing.  You can try to minimize it. All
distro's do this to some extend.

 Maybe the maintainers of one platform/OS distribution do slightly better
 than the others, but in essence the problem always exists.
 
 Even on Windows, where there is only 1 manufacturer, the problem exists.

Windows native misses any library versioning, which is why it is quite
notorious. .NET has quit elaborate library (assembly) versioning, but
rumours are that the constant security patches can cause problems too.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

On Mon, Jul 17, 2006 at 11:21:36AM +0200, Micha Nelissen wrote:
 Marco van de Voort wrote:
  This has nothing to do with source based vs binary. If e.g. debian renamed
  libs tomorrow inside a branch, it would have the same effect.
 
 They can't do that without breaking all other packages in the archive
 using this package. They don't get rebuilt automatically AFAIK, and
 that's where the difference is IMHO.

I don't understand this. Afaik there is no difference at all. Could you be
more elaborate in what you think would go wrong automatically?
 
 Furthermore it's policy to change the name of the package when the ABI
 changes, but that's also what you said: kind of release management.

Same also. The problem is that this is the exception where they didn't.

I suspect they simply didn't want to wait till after 6.x, and wanted to keep
5.x-6.x congruency. (if 5.x implements this change at all).

There is also the matter of -RELEASE vs -STABLE, a principle that is hard to
explain, since other distro's don't implement it;

see it like this: a series of releases becomes STABLE when the generic
advise changed to target that series as stable.   x.0 versions are typically
never stable (the first 4.x stable was 4.4 the first 5.x was 5.3)

If they changed it only for 6.x, they might consider it minor because it is
affects non-upgraded 6.0 only, and before the -STABLE moniker is applied to
6.x.

However the difference is that 6.0 is (due to the large compability of 6.x
to 5.x, and its stability) way more widely used for serious work than the
avg FreeBSD x.0 release.  (people were generally afraid of 5.0-DP, and right
so :-))
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

On Mon, Jul 17, 2006 at 11:19:22AM +0200, Jonas Maebe wrote:
 
  They refer
 to pkgconfig or keep on using the -RELEASE ports branch (which is  
 security
 only),
 
 Of course I can't take a tool that emits gcc parametes seriously  
 (since
 some ad hoc parsing will probably break on the first gcc change).
 
 It generates ld parameters, not gcc parameters. So you don't have to  
 parse them unless you want to use an internal linker.

Thnks, will improve the text for the wiki. Not that it changes much, don't
like an external called from the compiler.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 17 Jul 2006, at 11:59, Marco van de Voort wrote:


It generates ld parameters, not gcc parameters. So you don't have to
parse them unless you want to use an internal linker.


Thnks, will improve the text for the wiki. Not that it changes  
much, don't

like an external called from the compiler.


There is no other way to properly support linking to external  
libraries, unless you use something like Mac OS X' frameworks (which  
does support transparent versioning and multi-version support,  
including name changes of individual libraries part of a framework  
even if they represent the same library version if you'd feel  
inclined to do that).


That doesn't mean Mac OS X doesn't potentially have the same library  
problems though, since most open source based libraries are not  
distributed as a framework.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 17 Jul 2006, at 12:21, Daniël Mantione wrote:

That doesn't mean Mac OS X doesn't potentially have the same  
library problems
though, since most open source based libraries are not distributed  
as a

framework.


IMHO crap like *_config are only tricks used by C people used to work
around defficiencies in their toolchains.


There's nothing C-specific about libraries, nor about the *config  
scripts. At most it would be linker-specific.



There simply should be no reason
why you want such complexity. A library has a name, you link to it by
name, basta.


A library also exist in at least multiple locations, versions (both  
ABI-compatible and -incompatible with previous versions) and  
implementations (e.g. a native Mac OS X GTK and an X-based one).


You can of course give everything a different name (which is what  
often happens in practice), but that doesn't work all that well as  
demonstrated by everyone's experience.


If people start renaming libraries we make us resistant to library  
name
changes. Otherwise the compiler needs to support a_config for  
library x

and b_config for package and the end is loose.


The whole point of the *config stuff is exactly to be resistant  
against that.



Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 17 Jul 2006, at 12:33, Jonas Maebe wrote:


There simply should be no reason
why you want such complexity. A library has a name, you link to it by
name, basta.


A library


can

also exist in at least multiple locations, versions (both ABI- 
compatible and -incompatible with previous versions) and  
implementations (e.g. a native Mac OS X GTK and an X-based one).


If people start renaming libraries we make us resistant to library  
name
changes. Otherwise the compiler needs to support a_config for  
library x

and b_config for package and the end is loose.


The whole point of the *config stuff is exactly to be resistant  
against that.


Against name changes of course. Supporting the multiple *config stuff  
could happen via a linklib-like statement in the unit sources.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Florian Klaempfl]

Bob wrote:
 Funny! I moved away from Linux mainly because of Library-Hell issues :-)

You've to move away from unix then :) I made similiar experiences when porting
FPC to Solaris.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

On Mon, Jul 17, 2006 at 12:16:10PM +0200, Jonas Maebe wrote:
 
 There is no other way to properly support linking to external  
 libraries, unless you use something like Mac OS X' frameworks (which  
 does support transparent versioning and multi-version support,  
 including name changes of individual libraries part of a framework  
 even if they represent the same library version if you'd feel  
 inclined to do that).

That's not the point. The point is that I consider a solution, that tries to
collect this data automatically, worse than the current situation.

IOW I consider this cure to be worse (more likely to break a release
systematically and harder to support due to a lack of transparancy to end
users) than the problem, specially since now we don't have to recompile FPC
anymore for a lib change.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Micha Nelissen]

Marco van de Voort wrote:
 They can't do that without breaking all other packages in the archive
 using this package. They don't get rebuilt automatically AFAIK, and
 that's where the difference is IMHO.
 
 I don't understand this. Afaik there is no difference at all. Could you be
 more elaborate in what you think would go wrong automatically?

My view of source based distributions (in the general software sense) is
that when a package maintainer uploads a new library version (changing
the library name correctly according to that distro's packaging rules)
then all dependent software is automatically recompiled for the new
version (and name), and thus no one notices any breakages. Except 3rd
parties like us.

For a binary distribution like debian, if a package maintainer uploads a
(binary) package with different containing library name, bug reports
will be compiled due to other packages being broken now. This package
thus cannot transition to the 'testing' (RC) debian distribution, and
the only possible fix is to revert the package name to the old one.

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 17 Jul 2006, at 13:42, Marco van de Voort wrote:

That's not the point. The point is that I consider a solution, that  
tries to

collect this data automatically, worse than the current situation.


There's no reason why a default fallback to the current system  
couldn't be supported.



IOW I consider this cure to be worse (more likely to break a release
systematically and harder to support due to a lack of transparancy  
to end

users) than the problem,


I cannot see how this is more likely to break a release  
systematically. And it's only as intransparent as we make it (e.g.,  
apart from the compiling, assembling and linking, there could  
just as well be a Determining needed libraries using gtk-config...  
message)



specially since now we don't have to recompile FPC
anymore for a lib change.


I do not understand this last part. Are you talking about dynamically  
loading libraries at run time or so?



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Daniël Mantione]

Op Mon, 17 Jul 2006, schreef Jonas Maebe:

 There's nothing C-specific about libraries, nor about the *config scripts. At
 most it would be linker-specific.

There is, those scripts mainly exist because a C compiler cannot determine 
the dependencies of a library. I.e. if you like libgtk you must also link 
libglib.

We don't need this in Pascal, the compiler can perfectly determine the 
dependencies by checking the used units. So the primary reason for this 
cruft is void in Pascal.

  There simply should be no reason
  why you want such complexity. A library has a name, you link to it by
  name, basta.
 
 A library also exist in at least multiple locations, versions (both
 ABI-compatible and -incompatible with previous versions) and implementations
 (e.g. a native Mac OS X GTK and an X-based one).

I don't see how *_config guards you against this:
* In case of a version change it will simply return the new version. The 
  .so symlink does this as well. If the new version is incompatible with 
  the old one, bad luck.
* It doesn't guard you against ABI changes, because that it determined 
  at the compiler level. I.e. there is no way to make cdecl code using a 
  register calling convention by using a linker option.

It helps for locations, but we already have a well adequate solution for 
that: Putting the location in fpc.cfg.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 17 Jul 2006, at 14:03, Daniël Mantione wrote:

There's nothing C-specific about libraries, nor about the *config  
scripts. At

most it would be linker-specific.


There is, those scripts mainly exist because a C compiler cannot  
determine
the dependencies of a library. I.e. if you like libgtk you must  
also link

libglib.

We don't need this in Pascal, the compiler can perfectly determine the
dependencies by checking the used units. So the primary reason for  
this

cruft is void in Pascal.


You could support exactly the same in C with some #pragma statements  
in the header files. This is implementation-specific rather than  
language specific.



A library also exist in at least multiple locations, versions (both
ABI-compatible and -incompatible with previous versions) and  
implementations

(e.g. a native Mac OS X GTK and an X-based one).


I don't see how *_config guards you against this:
* In case of a version change it will simply return the new  
version. The
  .so symlink does this as well. If the new version is incompatible  
with

  the old one, bad luck.


But if the new version has additional (or different) dependencies or  
library names, everything will remain fine with the script (as e.g.  
with the FreeBSD problem which started this discussion). It's the  
same with different implementations which maybe be ABI- and API- 
compatible, but have different dependencies.


It helps for locations, but we already have a well adequate  
solution for

that: Putting the location in fpc.cfg.


Of course you can require the user to manually specify everything in  
his config file or on the command line, but it's nicer if this can be  
avoided.



Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote:
 Marco van de Voort wrote:
  They can't do that without breaking all other packages in the archive
  using this package. They don't get rebuilt automatically AFAIK, and
  that's where the difference is IMHO.
  
  I don't understand this. Afaik there is no difference at all. Could you be
  more elaborate in what you think would go wrong automatically?
 
 My view of source based distributions (in the general software sense) is
 that when a package maintainer uploads a new library version (changing
 the library name correctly according to that distro's packaging rules)
 then all dependent software is automatically recompiled for the new
 version (and name), and thus no one notices any breakages. Except 3rd
 parties like us.

This is not for inbetween releases, since not all software will be
automatically recompiled in all cases. And in this case specifically it
doesn't matter at all. Moreover source and binary packages can be used
together (and in practice, are), and there are build clusters (pointy hat)
that check this.

It only is true for full releases, since that forces all apps to recompile,
then we get the heat. But this is also so on Linux, usually we only get the
indication that something is wrong when new distro (+version) emerges.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Marco van de Voort]

On Mon, Jul 17, 2006 at 01:57:01PM +0200, Jonas Maebe wrote:

 That's not the point. The point is that I consider a solution, that  
 tries to
 collect this data automatically, worse than the current situation.
 
 There's no reason why a default fallback to the current system  
 couldn't be supported.

If it doesn't exist. But what if it fails? Or if a user pops up in the
maillist with a gtk-config related error? Do you really want to support
something that you don't control? _and_ at the same time have to maintain
the backup too?
 
 IOW I consider this cure to be worse (more likely to break a release
 systematically and harder to support due to a lack of transparancy  
 to end
 users) than the problem,
 
 I cannot see how this is more likely to break a release  
 systematically. And it's only as intransparent as we make it (e.g.,  
 apart from the compiling, assembling and linking, there could  
 just as well be a Determining needed libraries using gtk-config...  
 message)
 
 specially since now we don't have to recompile FPC
 anymore for a lib change.
 
 I do not understand this last part. Are you talking about dynamically  
 loading libraries at run time or so?

No. Simple the alias stuff. See the original msg from me, last part. 

To
- change a libname mentioned in a linklib, 
- to conditionally add a lib (include lib a if lib b is used, like the libgcc
during 2.0.4 pkging, though maybe that must be static),
- or to change order of libs,

no FPC repository or fpc binary recompile is necessary anymore
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Micha Nelissen]

Marco van de Voort wrote:
 On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote:
 the library name correctly according to that distro's packaging rules)
 then all dependent software is automatically recompiled for the new
 version (and name), and thus no one notices any breakages. Except 3rd
 parties like us.
 
 This is not for inbetween releases, since not all software will be
 automatically recompiled in all cases. 

Then a lot of users of FreeBSD tracking 6.0 or development, or how you'd
call it, should have gotten into trouble as well (since there were no
symlinks) ?

 And in this case specifically it
 doesn't matter at all. 

What doesn't matter and why ?

 Moreover source and binary packages can be used
 together (and in practice, are), and there are build clusters (pointy hat)
 that check this.

What do they check ?

 It only is true for full releases, since that forces all apps to recompile,
 then we get the heat. But this is also so on Linux, usually we only get the
 indication that something is wrong when new distro (+version) emerges.

Mainly I guess because we do not have manpower to check more often :-).
Not that I'm saying we should have to check that often...

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2

[Jonas Maebe]

On 17 Jul 2006, at 14:31, Marco van de Voort wrote:


There's no reason why a default fallback to the current system
couldn't be supported.


If it doesn't exist. But what if it fails?


The current solution also fails from time to time. And there would  
switch to disable this gtk-config calling (just like there are  
switches to disable assembling and/or linking).



Or if a user pops up in the
maillist with a gtk-config related error? Do you really want to  
support

something that you don't control?


Yes, I prefer that unless the existing solution is so bad it fails  
almost all the time, or if the alternative is at least as versatile/ 
compatible and has significant advantages. Most of the messages about  
*config failing is that the script isn't found at all by the  
configure script, which would be a non-issue for us.



_and_ at the same time have to maintain
the backup too?


The backup must be maintained anyway for libraries which do not  
come with such a script.



I do not understand this last part. Are you talking about dynamically
loading libraries at run time or so?


No. Simple the alias stuff. See the original msg from me, last part.

To
- change a libname mentioned in a linklib,
- to conditionally add a lib (include lib a if lib b is used, like  
the libgcc

during 2.0.4 pkging, though maybe that must be static),
- or to change order of libs,

no FPC repository or fpc binary recompile is necessary anymore


I see this rather as complementary to supporting the *config scripts:  
if the *config scripts fail, and if the library names defined in the  
units are wrong, then you can still work around it with these options.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel