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] Resourcestrings and encodings

[Martin Schreiber]

On Tuesday 29 September 2015 00:30:48 Jonas Maebe wrote:

> However, I would already like to ask everyone that uses resource strings
> to check FPC trunk r31881 or later with their program to ensure it still
> works correctly, and also try the changed rstconv utility. See
> http://bugs.freepascal.org/view.php?id=28717#c86146 for information
> about its default behaviour and new feature.
>
With the changes finally MSEi18n can support Unicode resourcestrings for FPC 
3.1.1, see
http://mseide-msegui.sourceforge.net/pics/msei18n_fpc_3_0.png
Thank you very much.

I do not use *.po files and rstconv -> not tested by me.

Martin
___
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] Resourcestrings and encodings

[Jonas Maebe]

Martin Schreiber wrote on Tue, 29 Sep 2015:


With the changes finally MSEi18n can support Unicode resourcestrings for FPC
3.1.1, see
http://mseide-msegui.sourceforge.net/pics/msei18n_fpc_3_0.png
Thank you very much.


Thanks for testing.


Jonas
___
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