Re: [fpc-pascal] Custom NewInstance allocator

[Tony Whyman via fpc-pascal]

You may find that compiling with "{$OBJECTCHECKS OFF}" allows your 
program to run and as long as your object has  no virtual methods nor  
does it require its fields to be initialised to zero, then it might even 
give a useful result - otherwise, you also need to call InitInstance.


On 04/06/2024 09:54, Hairy Pixels via fpc-pascal wrote:

In the manual it at https://www.freepascal.org/docs-html/ref/refse38.html it says 
"Calling the constructor will provoke a call to the virtual class method 
NewInstance, which, in its default implementation, calls GetMem, to allocate enough space 
to hold the class instance data, and then zeroes out the memory."

I'm trying this like below but it crashes. Is this correct? The fact 
NewInstance returns TObject instead of Pointer doesn't make sense to me and 
suggests this isn't correct.

   class function TDataObject.NewInstance: TObject;
   begin
 result := TObject(GetMem(InstanceSize));
   end;

Regards,
Ryan Joseph

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

Return-Path: 
Received: from mail3.mwassocs.co.uk (mail3.mwassocs.co.uk 
[IPv6:2a00:da00:1800:8207:0:0:0:1])
by olympus.mwassocs.co.uk (8.17.1.9/8.17.1.9/Debian-2) with ESMTP id 
454925ln001681
for ; Tue, 4 Jun 2024 10:02:13 +0100
Authentication-Results: mail3.mwassocs.co.uk;
dkim=fail reason="signature verification failed" (2048-bit key; 
unprotected) header.d=googlegroups.com header.i=@googlegroups.com header.a=rsa-sha256 
header.s=20230601 header.b=QYUmS2JD;
dkim-atps=neutral
Received: from mwa2023.mwassocs.co.uk (localhost [127.0.0.1])
by mail3.mwassocs.co.uk (8.17.1.9/8.17.1.9/Debian-2) with ESMTPS id 
4547BXql783561
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
for ; Tue, 4 Jun 2024 07:11:33 GMT
Received: (from tony@localhost)
by mwa2023.mwassocs.co.uk (8.17.1.9/8.17.1.9/Submit) id 4547BXAJ783560
for t...@olympus.mwassocs.co.uk; Tue, 4 Jun 2024 07:11:33 GMT
Received: from mail-wr1-x438.google.com (mail-wr1-x438.google.com 
[IPv6:2a00:1450:4864:20:0:0:0:438])
by mail3.mwassocs.co.uk (8.17.1.9/8.17.1.9/Debian-2) with ESMTPS id 
4547BUZr783552
(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=FAIL)
for ; Tue, 4 Jun 2024 07:11:31 GMT
Received: by mail-wr1-x438.google.com with SMTP id 
ffacd0b85a97d-35e7d4f4243sf466477f8f.1
 for ; Tue, 04 Jun 2024 00:11:31 -0700 
(PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1717485084; cv=pass;
 d=google.com; s=arc-20160816;
 b=z3rh7siQ5LSx2gqOn6Mj2et1j7nRVra3IEAIQP3K+wiLPpUXI7Tr01d/nylJ1HaFGg
  TKMLH/7nimkBSESeSME1HlbXG/UZ3e0eDyQJiX/+9xPvWikDEfUquqMOn/mNiqw7e0Xd
  +pZECf4Ja5GvrNIdwhvWwE19XAy47TOFoHfh8g+88q2NBW4fHsKwqVJKpqfi9Ph4V+hq
  u28lFheObpB69LUI3OFdETpRigKxoVZmMBYY1yGyfHTzR2shJuyPqpj/rx6Ltbp2QHKu
  YPBSqS9MC+jWyvogY3jalcSBCQOmlTMB2lS5dkJCSFv/U9c+waOqTUnyq9NKuUe13Nqz
  IrTA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
 h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
  :list-id:mailing-list:precedence:reply-to:content-transfer-encoding
  :in-reply-to:organization:from:content-language:references:to
  :subject:user-agent:mime-version:date:dkim-filter:message-id
  :dkim-signature;
 bh=VKy8eSS7uMgsfe7Vrkk4zMlxj8C0nXu9E/pOm4K0rMk=;
 fh=GfuQ6oQp7YQ6NU+kiZIdgjvraiHPaEC7d1yzxmt/vc4=;
 b=0lhn/6GQITvaXqpbaKK84AIaB2cjpSaDetDLj6vUj73e+DeHzE4+kqx30HeD4RUwhZ
  J8nfrgcc/XKIDNflRql2my0pBwCNIatSqJOWvZNkvdt1UM62LwnaAb4o0nG8e7zb7E6r
  VGEPv5RotVFDMnrtRhED3pKlLKQkyqBGG6yb0IqUtkyCB/BcBAjhO6sYbO3QGcRs2wPW
  ZAEb/oSv5DTEO3TYDSHjAwyQ4E/q9WjDtd954my1tHUvaXPbzDnR8YvaTXQ6a1wktIDI
  ZqGD68N9Fmcf7KsICOqThJrRERmgdzP6247CcqS0PN5CUDoaGMo604eJbDbSpIU6Rymo
  0Nrg==;
 darn=mccallumwhyman.com
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@lawinegevaar.nl header.s=protagio header.b=xOXklYHI;
spf=pass (google.com: domain of m...@lawinegevaar.nl designates 
2a00:51c0::5fd7:bd14 as permitted sender) smtp.mailfrom=m...@lawinegevaar.nl;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=lawinegevaar.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlegroups.com; s=20230601; t=1717485084; x=1718089884; 
darn=mccallumwhyman.com;
 h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
  :list-id:mailing-list:precedence:reply-to
  :x-original-authentication-results:x-original-sender
  :content-transfer-encoding:in-reply-to:organization:from
  :content-language:references:to:subject:user-agent:mime-version:date
  :dkim-filter:message-id:from:to:cc:subject:date:message-id:reply-to;
 

Re: [fpc-pascal] FPC 3.3.x breaks the Firebird Project's Firebird.pas

[Tony Whyman via fpc-pascal]

Michael,

I believe that the diplomatic answer to your response is that it is 
"disappointing". This is a serious problem and needs to be discussed.


Interfaces between modules written in different programming languages or 
even built with different compilers are never easy and depend on having 
published and stable definitions for each data type and structure. This 
is a common problem for anyone using Pascal given how so many code 
libraries are written 'C' or C++. Change can imply breaking many user 
programs and should not be done lightly and for purely internal reasons.


Both object and class type data structures are published in the Free 
Pascal Documentation and I do not believe that it is unreasonable to 
expect that the FPC developers will do their best to maintain stability 
for these structures as they would for any other data type. You seem to 
think that assuming that the object data structure is a stable and well 
known data structure that can be relied upon to be the same in each 
successive compiler version is "an invalid assumption". If that is the 
case then can we rely upon the stability of any data type and hence of 
any interface between FPC and other language environments?


In the case of monitor data, you have said that Delphi have implemented 
this as a "hidden" field. I presume that you mean that this uses a 
technique such as a negative offset to the object instance pointer. This 
would certainly be a good way to add system information to an object 
without destabilising the data structure for the user. Surely the right 
way to go.


The Firebird OO API may be the only interface library that uses the 
existing object layout in order to implement the interface. That would 
surprise me and there may well be more interfaces that are broken by  
FPC 3.3.x.


In the case of the Firebird OO API a complete redesign will be needed to 
work around your change - requiring a separation of the data blocks 
exchanged via the interface, and the classes supporting them. Even 
though a code generator is used, there are still about a hundred classes 
to consider with some used as callbacks. The Firebird.pas unit itself 
comprises about 14,000 lines of code and comments. You are asking 
voluntary programmers to devote hundreds, perhaps thousands of hours of 
time, to build and test a new interface design purely for the benefit of 
FPC, when the existing design works with both Delphi and FPC and has 
done so since the early part of the last decade. Until someone puts in 
this effort Pascal users of Firebird will be restricted to using the old 
legacy interface (which has not been updated since Firebird 2.5 and 
misses many important features), keeping with the old version of the 
compiler, or just moving to Delphi.


And, before going down this path, perhaps you might like to give a heads 
up of what other changes are in the pipeline that may knowing break 
interfaces to other programming environments.


Tony Whyman


On 02/05/2024 13:55, Michael Van Canneyt via fpc-pascal wrote:



On Thu, 2 May 2024, Tony Whyman via fpc-pascal wrote:

This is a problem reported to me by an IBX user. I have not yet 
confirmed it (need to find the time to set up the latest development 
branch of FPC), but the issue looks solid, and is due to the 
following addition to TObject (copied from the GitLab master branch)


|TObject = class|{$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
strictprivate
_MonitorData : Pointer;
private
functionSetMonitorData(aData,aCheckOld : Pointer):Pointer; inline;
functionGetMonitorData:Pointer; inline;
{$ENDIF}
  ...

Since Firebird 3.0, the Firebird project has provided a file called 
"Firebird.pas" in order to provide an interface to Pascal (both 
Delphi and FPC) from a C++ environment. There is an underlying 
assumption in the interface. That is TObject contains no fields.


This assumption is not valid in Delphi either. It also has this field, 
but

it is 'hidden' at a not-fixed location.



The idea is simple enough. There is a single entry point to the 
Firebird client library with the Pascal signature


function fb_get_master_interface : IMaster; cdecl;

This returns a pointer to a structure that may contain fields but is 
primarily a list of pointers to cdecl functions. These functions can 
perform various tasks. In the case of IMaster, they can also return 
similar structures representing other "interfaces".


On the Pascal side, IMaster is defined as a class with no virtual 
methods and a single field called "vTable" and this is set to the 
pointer to the structure returned by fb_get_master_interface. The 
rest of the class comprises methods used to call functions from the 
vTable. This makes IMaster look like a normal class and hides the use 
of function pointers. The code is generated by a program know as 
"cloop". All Firebird interfaces declared in Firebird.pas follow the 
same approach.


Given th

[fpc-pascal] FPC 3.3.x breaks the Firebird Project's Firebird.pas

[Tony Whyman via fpc-pascal]

This is a problem reported to me by an IBX user. I have not yet 
confirmed it (need to find the time to set up the latest development 
branch of FPC), but the issue looks solid, and is due to the following 
addition to TObject (copied from the GitLab master branch)


|TObject = class|{$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
strictprivate
_MonitorData : Pointer;
private
functionSetMonitorData(aData,aCheckOld : Pointer):Pointer; inline;
functionGetMonitorData:Pointer; inline;
{$ENDIF}
   ...

Since Firebird 3.0, the Firebird project has provided a file called 
"Firebird.pas" in order to provide an interface to Pascal (both Delphi 
and FPC) from a C++ environment. There is an underlying assumption in 
the interface. That is TObject contains no fields.


The idea is simple enough. There is a single entry point to the Firebird 
client library with the Pascal signature


function fb_get_master_interface : IMaster; cdecl;

This returns a pointer to a structure that may contain fields but is 
primarily a list of pointers to cdecl functions. These functions can 
perform various tasks. In the case of IMaster, they can also return 
similar structures representing other "interfaces".


On the Pascal side, IMaster is defined as a class with no virtual 
methods and a single field called "vTable" and this is set to the 
pointer to the structure returned by fb_get_master_interface. The rest 
of the class comprises methods used to call functions from the vTable. 
This makes IMaster look like a normal class and hides the use of 
function pointers. The code is generated by a program know as "cloop". 
All Firebird interfaces declared in Firebird.pas follow the same approach.


Given the assumption that TObject defines no fields, it is possible to 
coerce the pointer returned by fb_get_master_interface to appear as an 
object "instance" of the IMaster class, and similarly for every other 
Firebird interface class. This coercion ceases to be valid as soon as a 
field, such as _MonitorData is added to TObject.


It is probably a valid argument to say that this is Firebird's problem 
as the TObject definition is an internal data structure. However, this 
ignores a serious real world problem. A fix or workaround is needed and 
that has to be in Firebird.pas. It would be a logistic nightmare to try 
and change the C++ Firebird client DLL/SO.


Also, does anyone know whether a similar problem will arise with Delphi, 
or is thus just an FPC issue?


One of the following seems to be needed:

a) Rewriting Firebird.pas to set the vTable field explicitly rather than 
implicitly through coercion - ideally without breaking any user code... 
(note: no current need to free IMaster etc)


b) Taking a different approach to introducing _MonitorData e.g.

i) Putting in a class helper (is this possible?)

ii) Having a version of TObject (e.g. TUnmonitoredObject) which is the 
current TObject and making TObject a descendent class introducing 
_MonitorData. The Firebird classes can then descend from 
TUnMonitoredObject, either explicitly or as a result of a new compiler 
directive setting the default class ancestor.


iii) Anything else that works.

I am primarily looking for a solution that will work with IBX, but also 
one that I can suggest to the Firebird Devs to make generally available.


Tony Whyman

MWA Software
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] client certificate mandatory and verification

[Tony Whyman via fpc-pascal]

If you want to use OpenSSL then you might be interesting in trying out 
my proposed update to the Indy components. This is to support the latest 
versions of OpenSSL and can be downloaded from:


https://github.com/MWASoftware/Indy.proposedUpdate

There is a test case in Test/OpenSSL/openssl-server which is based on 
the use of the Indy http server and OpenSSL which includes a test case 
where a client certificate must be validated by the server. This appears 
to work on both Linux and Windows and hopefully other platforms.


On 10/04/2024 01:34, Flávio Etrusco via fpc-pascal wrote:

Hello,

This doesn't seem to have an easy solution right now. Many of the 
functions needed to set up openssl for this doesn't even seem to have 
imports in the FPC package.
You'd then have to import the functions and implement a custom 
TSSLSocketHandler, and then hook it using either
(fphttpapp.)Application.HTTPHandler.HTTPServer.OnGetSocketHandler or 
TSSLSocketHandler.SetDefaultHandlerClass();


Some pointers:
https://stackoverflow.com/questions/4261369/openssl-verify-peer-client-certificate-in-c
https://stackoverflow.com/questions/21050366/testing-ssl-tls-client-authentication-with-openssl
https://stackoverflow.com/questions/16291809/programmatically-verify-certificate-chain-using-openssl-api
https://stackoverflow.com/questions/3412032/how-do-you-verify-a-public-key-was-issued-by-your-private-ca

Best regards,
Flávio


Em sáb., 23 de mar. de 2024 às 08:47, Jos Wegman via fpc-pascal 
 escreveu:


Hi,

Out of the info on the wiki I created a simple Webserver with a
server-certificate.
To get this code working you need to create the necessary certificate.
For this I used xca from https://hohnstaedt.de but you can use
OpenSSL to do the same.


[code=pascal]
program webserver;

{$mode objfpc}{$H+}

uses
  {$ifdef UNIX}
  cthreads, cmem,
  {$endif}
  fphttpapp,
  httpdefs,
  httproute,
  opensslsockets;

var
  fUseSSL: boolean;
const
  fCertificatePassword: string = 'hello';
  fCertificateHostName: string = 'localhost';
  fCertificateFileName: string = 'Server.crt';
  fCertificatePrivateKey: string = 'Server.key';

  procedure route1(aReq: TRequest; aResp: TResponse);
  begin
    aResp.Content := 'Route 1 The
Default';
  end;

  procedure route2(aReq: TRequest; aResp: TResponse);
  begin
    aResp.Content := 'Route 2';
  end;

begin
  HTTPRouter.RegisterRoute('/', @route1);
  HTTPRouter.RegisterRoute('/2', @route2);
  Application.Port := 1999;
  fUseSSL :=true;
  Application.UseSSL := fUseSSL;
  if fUseSSL then
  begin
    Application.CertificateData.KeyPassword := fCertificatePassword;
    Application.CertificateData.HostName := fCertificateHostName;
    Application.CertificateData.Certificate.FileName :=
fCertificateFileName;
    Application.CertificateData.PrivateKey.FileName :=
fCertificatePrivateKey;
  end;
  Application.Threaded := True;
  Application.Initialize;
  Application.Run;
end.
[/code]

My questions are:
*- How can I modify this example to enforce the use of a client
certificate?
- How can I verify a client certificate in the server?*

In the TLS handshake a client certificate is optional but the
server can ensure that it is mandatory.

Any help, pointers, sample code is appreciated.

Sincerely,

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


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

[fpc-pascal] Can FPC link a program with static (.a) libraries on Windows

[Tony Whyman via fpc-pascal]

I have a Pascal program, compiled with FPC 3.2.2 and which appears to 
happily link and run with a static library compiled with gcc and having 
a ".a" prefix on linux. The functions in the static library and declared 
as external functions using the "external  name name>" directive. The "".a" library is copied to the same directory as 
the program unit before compiling and linking.


However, compiling the same program on Windows always seems to result in 
the loader complaining that the corresponding .dll is not 
present, indicating that instead of linking with the static library, the 
program is attempting to "statically" load the correspoinding dll at 
initialisation time.


I have tried to force it to link with the static library (e.g. using the 
-Xt command line switch) but no luck.


Hence the question, does FPC 3.2.2 support linking with static libraries 
on windows?


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

[fpc-pascal] RIP: Software design pioneer and Pascal creator Niklaus Wirth

[Tony Whyman via fpc-pascal]

"Swiss computer scientist Professor Niklaus Wirth died on New Year's 
Day, roughly six weeks before what would have been his 90th birthday."


https://www.theregister.com/2024/01/04/niklaus_wirth_obituary/?utm_source=daily_medium=newsletter_content=top-article

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

Re: [fpc-pascal] case statement

[Tony Whyman via fpc-pascal]

On 16/12/2023 19:07, Gerhard Scholz via fpc-pascal wrote:


ELSE/OTHERWISE

I assume that came historically; the first implementation of a PASCAL 
compiler I have seen had no else or otherwise in the case startement. 
Some ater dialects introduced ELSE, other dialect(s) used OTHERWISE, 
FPC then allowed both.


The historical context has interested me as well.

Going back to the original "Pascal User Manual and Report" (Jensen and 
Wirth 1978), there is no Else/Otherwise clause for a case statement. The 
syntax is given as (in the original BNF):


 ::= case  of
   |;] end
 ::=  :  | 
 ::=  | [ ,  ]

Note that the semi-colon is used here in its traditional Algol role as a 
statement separator and not the 'C' usage as a statement terminator.


Back in the early eighties, I worked at ICL and we made extensive use of 
the Prospero Pascal compiler building embedded systems based on the Z80 
microprocessor. I still have a 1988 edition of the language 
specification, and this uses EBNF to define the case statement as:


case-statement = "CASE" case-index "OF"
  case-list-element {";" case-list-element }
   [ ";" OTHERWISE statement][";"] "END"

case-index = expression
case-list-element = case-range-list ":" statement
case-range-list = case-range {"," case-range }
case-range = case-constant [".." case-constant ]
case-constant = constant

What is interesting about the above is not just that it uses "otherwise" 
but that it insists on a semi-colon before the "otherwise". This may not 
have been strictly necessary but it does enforce the separation between 
the case -list-elements and the "otherwise", making the "otherwise" 
clause into another case-list-element. It also aids readability and it 
may be why I have always added a semi-colon after the final 
case-list-element. Note that the final optional ";" is probably needed 
to allow those that always like to end a statement in a semi-colon.


Prospero Pascal was close to ISO Pascal (although I have lost my 
original copy of ISO Pascal) and I would guess that the above is copied 
from ISO Pascal.


The change from "otherwise" to "else" is probably a Borland Pascal 
invention preferring a shorter word and then overlooking the importance 
of the semi-colon case-list-element separator and the resulting 
ambiguity. The same error then flowed through to exception handling.


As an aside, I much prefer OTHERWISE to ELSE given that it is much 
closer to natural language. The IF...THEN..ELSE construct probably dates 
back to Algol 60 and I wonder why it was proposed. In normal English 
use, "else" is not used in this way. It usually follows another word, 
such as "anyone else", "anything else", "or else".


You might say

"If I go to town then I will be out. Otherwise, I will stay at home". I 
would never replace "otherwise" with "else" in such a sentence. "Else" 
belongs in a statement such "Does anyone else have a view".


Tony Whyman


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

[fpc-pascal] Issue #39746 fpwidestring case conversion string too long

[Tony Whyman via fpc-pascal]

This issue seems to be still open after one year. There was a proposed 
fix: https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/158. 
However the discussion seems to tail off without an obvious resolution.


This is a clear bug in fpwidestring and needs to be fixed. What is the 
status?


A workaround using the Trim function seems to work (e.g. 
Trim(AnsiUpperCase(s))) - I am just not sure if it works all the time.


Tony

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

Re: [fpc-pascal] I am offering a $100 reward for linking static libraries

[Tony Whyman via fpc-pascal]

Once upon a time (late-1990s) I had some reasonable success (shareware) 
marketing a JPEG library for Delphi. This was a wrapper around the 
Independent JPEG Group's JPEG software which was written in 'C'. My JPEG 
library had thus to link to a 'C' library and both dynamic and static 
linking was offered. I too had the problem of too many C DLLs to link in.


The way it was solved for static libraries was to first link in the JPEG 
object files e.g.


{IDG JPEG objects modules to both compression and decompression}

{$L jdapimin.obj}
{$L jmemmgr.obj}
{$L jmemnobs.obj}
{$L jerror.obj}


{IDG JPEG modules for decompression}

{$L jdinput.obj}
{$L jdtrans.obj}
...

and then to identify the missing 'C' library functions (via linker 
errors). I then wrote Pascal equivalents (placed just before the $L 
statements. e.g.


{ Stubs for external C RTL functions referenced by JPEG OBJ files.}

function _malloc(size: Integer): Pointer; cdecl;
begin
  GetMem(Result, size);
end;

procedure _free(P: Pointer); cdecl;
begin
  FreeMem(P);
end;

procedure _memset(P: Pointer; B: Byte; count: Integer);cdecl;
begin
  FillChar(P^, count, B);
end;

procedure _memcpy(dest, source: Pointer; count: Integer);cdecl;
begin
  Move(source^, dest^, count);
end;

function __ftol: Integer;
var
  f: double;
begin
  asm
leaeax, f //  BC++ passes floats on the FPU stack
fstp  qword ptr [eax] //  Delphi passes floats on the CPU stack
  end;
  Result := Trunc(f);
end;

As long as you can reduce the missing dependencies to a relatively small 
number, it should all work.


Regards

Tony Whyman

MWA

On 21/08/2022 18:34, Anthony Walter via fpc-pascal wrote:
I will pay $100 to the first person that can solve my problem of 
linking a compiled C static library to a Free Pascal program on Windows.


Recently I have been building many C libraries with GCC on Linux and 
linking them to Free Pascal. These include building C libraries such 
as "libxmp" for decoding mod/tracker music into PCM audio samples, 
"libchuimpmunk2d" for simulating 2D solid body physics, or "libsdl2" 
for cross platform controller input and haptic feedback among other 
things.


So far on Linux I am happily able to use a cmake/make/gcc toolchain to 
build these C libraries from source and easily statically link them to 
my Free Pascal programs.


Here is an example and abbreviated Pascal unit that links to a static 
build of Chimpmunk 2D:


unit Chimpmunk2D;

interface

type
  cpSpace = Pointer;

function cpSpaceNew: cpSpace; cdecl; external;
procedure cpSpaceDestroy(space: cpSpace); cdecl; external;

implementation

{$ifdef linux}
  {$linklib c}
  {$linklib m}
  {$linklib chipmunk-linux}
{$endif}

end.

Where libchipmunk-linux.a is my static library build on Linux from the 
Chipmunk2D C source code and is in the same folder as the source code 
as "Chimpmunk2D.pas". This works fine on Linux.


I am also able to use mingw32 gcc to compile this same C source into a 
static library for Windows using these two commands while inside the 
folder containing the Chipmunk2D sources:


x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99 
-ffast-math src/*.c -Iinclude -c

x86_64-w64-mingw32-ar rcs libchipmunk-win.a *.o
rm *.o

The problem then arises when I try to use {$linklib chipmunk-win}. No 
matter how I try to arrange the static dependencies I cannot resolve 
missing functions.


Many attempts were made compiling against other mingw32 static 
libraries for Windows.


{$ifdef windows}
  {$linklib mingw32}
  {$linklib mingwex}
  {$linklib kernel32}
  {$linklib msvcrt}
  {$linklib chipmunk-win}
{$endif}

I get many errors similar to these below:

Verbose: Compiling resource 
C:\Development\Projects\physics\lib\x86_64-win64\Physics.obj

Verbose: Linking C:\Development\Pascal\Projects\physics\Physics.exe
Physics.lpr(30,1) Error: Undefined symbol: ___chkstk_ms
Physics.lpr(30,1) Error: Undefined symbol: __mingw_raise_matherr
Physics.lpr(30,1) Error: Undefined symbol: __imp_WideCharToMultiByte
Physics.lpr(30,1) Error: Undefined symbol: __imp_IsDBCSLeadByteEx
Physics.lpr(30,1) Error: Undefined symbol: __imp_MultiByteToWideChar
Physics.lpr(30,1) Verbose: There were 5 errors compiling module, stopping
Verbose: Compilation aborted

BUT

If I use mingw32-w64 on Linux to create a DLL instead, then m 
problems on Windows go away.


x86_64-w64-mingw32-gcc-win32 -static -shared -static-libgcc -std=gnu99 
-ffast-math src/*.c -Iinclude -o libchipmunk-win.dll


However, I am not satisfied with an ever growing list of DLLs (I am at 
6 currently) that must be deployed on Windows to build / run any 
project using my Pascal toolkit. I thought I could resolve this static 
linking problem on Windows at a later date, thus eliminating all the 
DLLs required to run projects using my toolkit on Windows, but every 
time I return to try another attempt I cannot resolve the external 
dependencies of something like "libchipmunk

Re: [fpc-pascal] Repost: TFieldType declaration change in FPC fixes_3_2 branch

[Tony Whyman via fpc-pascal]

Yes - but is that really a bug fix that justifies a non-backwards 
compatible change?


On 17/10/2021 11:09, Michael Van Canneyt via fpc-pascal wrote:



On Sun, 17 Oct 2021, Tony Whyman via fpc-pascal wrote:


/Reposted with correct branch identifier/.

I thought that a fixes branch was only for bug fixes and not for 
issuing non-backwards compatible changes. However, TFieldType in 
db.pas now has 6 extra elements.


The result is that IBX no longer compiles with the fixes_3_2 branch. 
I have also heard the same for zeoslib.


Is the rollout of this patch to fixes_3_2 a mistake, or is there a 
good reason for rolling out a change that breaks other packages?


Delphi compatibility fix:

   fcl-db: base: add some of new Delphi field types into enumeration 
TFieldType
    (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, 
ftExtended)


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


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

[fpc-pascal] Repost: TFieldType declaration change in FPC fixes_3_2 branch

[Tony Whyman via fpc-pascal]

/Reposted with correct branch identifier/.

I thought that a fixes branch was only for bug fixes and not for issuing 
non-backwards compatible changes. However, TFieldType in db.pas now has 
6 extra elements.


The result is that IBX no longer compiles with the fixes_3_2 branch. I 
have also heard the same for zeoslib.


Is the rollout of this patch to fixes_3_2 a mistake, or is there a good 
reason for rolling out a change that breaks other packages?


Tony Whyman
MWA Software
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to check if a network is available?

[Tony Whyman via fpc-pascal]

Yep, that's the golden rule in networking. The only way that you know 
that a bi-directional path is open is an end-to-end ping. Even then, you 
only know that it's open at the time the ping completed.


If you are using TCP then you can always enable keepalive packets that 
effectively do the same thing while the TCP connection is open. The 
IPsec Internet Key Exchange Protocol also has the same capability for 
Dead Peer Detection (DPD) which works between the two end points of a 
VPN tunnel.


On 18/06/2021 13:34, James Richters via fpc-pascal wrote:

Do a Ping to an address on the network to see if it's connected?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
I would like to know how I can check if a remote network is available, i.e. if
the VPN system has succeeded to connect the remote network.

I need this in a class that connects an OpenVPN tunnel on demand and takes it
down after use. Unfortunately openvpn-gui does not have an API call to do
this...
It provides an API for connect, disconnect, reconnect etc but not for returning
the state of a connection for example.
https://github.com/OpenVPN/openvpn-gui#send-commands-to-a-running-instance-of-openvpn-gui

Any suggestions for Windows?
I just want to know if a call to connect succeeded.


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

Re: [fpc-pascal] Sending Hex codes over TCP/IP

[Tony Whyman via fpc-pascal]

A TCP connection is no more than a pair of byte streams - one in each 
direction. You have to define your own structure for each byte stream and the 
procedures for use i.e. a protocol. lt will be easier if you can use a standard 
protocol such as http. An http POST is one way to send an array of bytes to a 
server and to receive a response.
if you want to define your own protocol then you could send your array of bytes 
as an integer length followed by the bytes encoded one after the other. If you 
want your protocol to be platform independent then be careful to define the bit 
order (little endien or big endien) and how multibyte integers are encoded (low 
order byte first or high order byte first).Your protocol could be as simple as 
one side iniiates a connection, sends a byte count followed by the byte array. 
The receiver, once it has received all bytes (as given by the byte count) 
processes the data and then returns the response preceded by a byte count. Of 
course your application may be more complex than that, which is why protocol 
design is such an interesting problem.
 Original message From: James Richters via fpc-pascal 
 Date: 11/09/2020  21:59  (GMT+00:00) To: 
'FPC-Pascal users discussions'  Cc: James 
Richters  Subject: [fpc-pascal] Sending Hex 
codes over TCP/IP I'm trying to figure out how to send and receive Arrays of 
Bytes or perhaps a buffer of hex codes over TCP/IP,  but everything I find 
seems to want to send and receive strings.  Can someone please point me in the 
right direction on how to do this?   Basically I want to make a connection 
to an IP address at a specific port and then send some bytes to the server then 
get some bytes back from the server.  The data sent is just hexadecimal and it 
can't be followed by linefeeds or carriage returns, and I want to just receive 
the bytes back into a buffer of some sort so I can look at it one byte at a 
time.  I prefer some kind of array of bytes so I can just access the bytes with 
elements of the array.  I've been going round and round trying to figure this 
out.  Any help is greatly 
appreciatedJames___fpc-pascal 
maillist  -  
fpc-pascal@lists.freepascal.orghttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Help with TList example

[Tony Whyman via fpc-pascal]

See https://www.freepascal.org/docs-html/rtl/system/dispose.html

On 08/09/2020 12:51, James Richters wrote:

Can you please give me an example of the correct way to use new and dispose?

I'll try the pointer

Thanks for the advice

James

-Original Message-
From: fpc-pascal  On Behalf Of Tony 
Whyman via fpc-pascal
Sent: Tuesday, September 8, 2020 7:21 AM
To: fpc-pascal@lists.freepascal.org
Cc: Tony Whyman 
Subject: Re: [fpc-pascal] Help with TList example

Two observations:

1. In Pascal you should use "new" and "dispose" to allocate and deallocate 
record types - not GetMem and FreeMem.

2. MyRec is a pointer type and you should code the line as

MyRec^.Value := tmp


On 08/09/2020 12:10, James Richters via fpc-pascal wrote:

I'm trying to figure out how TList works.  I found the code example below by 
doing a search, but I can't compile it,  I get Error: Illegal qualifier on the 
line
  MyRec.Value := tmp;
It's indicating the error is on the V of Value

I tried commenting that line out, then I get the same error on
  MyRec.AByte := Byte(tmp);
At the A of AByte

So I commented that out too and then I get the error on

 Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ',
MyRecList[tmp].AByte); At the V on Value after MyRecList[tmp].

I don't know enough about the syntax to figure out what's wrong here.  Does 
anyone have any ideas?  It seems like there is something fundamentally wrong.

I'm trying to make a temporary list of records.  Kind of like a TStringList, 
but instead of a list of strings, a list of my own custom records.  Perhaps 
there is a better way?


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

uses
SysUtils, Classes;

type
PMyRec=^TMyRec;
TMyRec=record
  Value: Integer;
  AByte: Byte;
end;

TMyRecList=class(TList)
private
  function Get(Index: Integer): PMyRec;
public
  destructor Destroy; override;
  function Add(Value: PMyRec): Integer;
  property Items[Index: Integer]: PMyRec read Get; default;
end;

{ TMyRecList }

function TMyRecList.Add(Value: PMyRec): Integer; begin
Result := inherited Add(Value);
end;

destructor TMyRecList.Destroy;
var
i: Integer;
begin
for i := 0 to Count - 1 do
  FreeMem(Items[i]);
inherited;
end;

function TMyRecList.Get(Index: Integer): PMyRec; begin
Result := PMyRec(inherited Get(Index)); end;

var
MyRecList: TMyRecList;
MyRec: pMyRec;
tmp: Integer;
begin
MyRecList := TMyRecList.Create;
for tmp := 0 to 9 do
begin
  GetMem(MyRec, SizeOf(TMyRec));
  MyRec.Value := tmp;
  MyRec.AByte := Byte(tmp);
  MyRecList.Add(MyRec);
end;

for tmp := 0 to MyRecList.Count - 1 do
  Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ', 
MyRecList[tmp].AByte);
WriteLn('  Press Enter to free the list');
ReadLn;
MyRecList.Free;
end.

James

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


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



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

Re: [fpc-pascal] Help with TList example

[Tony Whyman via fpc-pascal]

Two observations:

1. In Pascal you should use "new" and "dispose" to allocate and 
deallocate record types - not GetMem and FreeMem.


2. MyRec is a pointer type and you should code the line as

MyRec^.Value := tmp


On 08/09/2020 12:10, James Richters via fpc-pascal wrote:

I'm trying to figure out how TList works.  I found the code example below by 
doing a search, but I can't compile it,  I get Error: Illegal qualifier on the 
line
 MyRec.Value := tmp;
   It's indicating the error is on the V of Value

I tried commenting that line out, then I get the same error on
 MyRec.AByte := Byte(tmp);
At the A of AByte

So I commented that out too and then I get the error on

Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ', MyRecList[tmp].AByte);
At the V on Value after MyRecList[tmp].

I don't know enough about the syntax to figure out what's wrong here.  Does 
anyone have any ideas?  It seems like there is something fundamentally wrong.

I'm trying to make a temporary list of records.  Kind of like a TStringList, 
but instead of a list of strings, a list of my own custom records.  Perhaps 
there is a better way?


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

uses
   SysUtils, Classes;

type
   PMyRec=^TMyRec;
   TMyRec=record
 Value: Integer;
 AByte: Byte;
   end;

   TMyRecList=class(TList)
   private
 function Get(Index: Integer): PMyRec;
   public
 destructor Destroy; override;
 function Add(Value: PMyRec): Integer;
 property Items[Index: Integer]: PMyRec read Get; default;
   end;

{ TMyRecList }

function TMyRecList.Add(Value: PMyRec): Integer;
begin
   Result := inherited Add(Value);
end;

destructor TMyRecList.Destroy;
var
   i: Integer;
begin
   for i := 0 to Count - 1 do
 FreeMem(Items[i]);
   inherited;
end;

function TMyRecList.Get(Index: Integer): PMyRec;
begin
   Result := PMyRec(inherited Get(Index));
end;

var
   MyRecList: TMyRecList;
   MyRec: pMyRec;
   tmp: Integer;
begin
   MyRecList := TMyRecList.Create;
   for tmp := 0 to 9 do
   begin
 GetMem(MyRec, SizeOf(TMyRec));
 MyRec.Value := tmp;
 MyRec.AByte := Byte(tmp);
 MyRecList.Add(MyRec);
   end;

   for tmp := 0 to MyRecList.Count - 1 do
 Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ', MyRecList[tmp].AByte);
   WriteLn('  Press Enter to free the list');
   ReadLn;
   MyRecList.Free;
end.

James

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


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

Re: [fpc-pascal] fpcmake packaging

[Tony Whyman via fpc-pascal]

On 01/09/2020 14:29, Ryan Joseph via fpc-pascal wrote:



On Sep 1, 2020, at 7:46 PM, Tony Whyman via fpc-pascal 
 wrote:

fpcmake is a pre-processor that generates makefiles for fpc projects. You can 
use it to do just about anything a standard makefile can do, including 
including resource files and running scripts. I use it all the time for 
building production versions of lazarus programs and prior to packaging the 
programs and resources in .deb and .rpm files.

On 01/09/2020 13:37, Ryan Joseph via fpc-pascal wrote:


Apparently there is fpmake and fpcmake, which I didn't know.

I guess what you're saying is that I start with fpcmake and get makefiles which 
I can then use to do packing and all the stuff I need? I've thought of using 
makefiles before but I ran into the problem of have all this logic that I need 
to duplicate for each project. What I'm really after is something more like 
lazbuild that takes a config file and does all the commands for you. I guess I 
could even use lazbuild but again, the packaging doesn't seem possible since 
lazbuild is so Lazarus focused (obviously).

Regards,
Ryan Joseph


My primary motivation for going with fpcmake is that it is a very good 
fit with the debian package management system (and rpmbuild). My normal 
build target is Ubuntu and hence I want to generate .deb files in order 
to distribute my application. The Debian Package Manager does not 
actually mandate use of makefiles - but it is built around the makefile 
concept and I have only ever seen examples of use based on makefiles.


I would position fpcmake as similar to autoconf/ automake in the C/C++ 
work. With automake, you need a Makefile.am in every directory of your 
project that contains something to compile or include in your package. 
With fpcmake you need a Makefile.fpc instead. This file contains the 
directives needed to generate the makefile and looks like an ini file.


An example follows taken from a simple application I have for 
Requirements Management.


The Makefile.fpc uses external environment variables, such as 
"INTERFACE". An external script (or a Debian rules file) that calls 
"make" itself to compile the project would define


export INTERFACE=gtk2

assuming you want gtk2 for your GUI.

Otherwise, the [compiler] section defines the fpc options, and 
directories to search. Most of these are part of my project. I have also 
used environment variables to define the build target and where to find 
the lazarus units. The [install] section is where I tell it  to install 
resource files. This includes an icon for the program and Firebird 
resource files. My project also requires that a .res file is built 
before the program is linked and there is a [prerules] section for this. 
"mkversioninfo" is my own utility, which generates the input to the 
windres utility for .res file generation.


Finally, there is an extra [rules] section to ensure that my resources 
are built when a "make all" is called.


[requires]
packages=fcl-res
libc=y

[compiler]
options= -MDelphi -Scghi -O3 -CX -Xs -vewnhi -l -dUseCThreads -dLCL 
-dLCL$(INTERFACE)

unittargetdir=units/$(CPU_TARGET)-$(OS_TARGET)
includedir=$(LZINCLUDE)
unitdir=$(LAZUNITDIR)/*  $(LAZUNITDIR)/*/$(INTERFACE) \
../frames \
../forms \
../dlg \
../reports \
../ole \
../ \
.


[target]
programs=RequirementsManagerPersonal

[install]
datadir=$(INSTALL_PREFIX)/share/RequirementsManager
files=RequirementsManagerPersonal.xpm firebird.conf firebird.msg

[prerules]
resources:
    rm -f RequirementsManagerPersonal.res
    mkversioninfo requirementsmanager-personal RequirementsManager.ico 
| $(WINDRES) -o RequirementsManagerPersonal.res


[rules]
all: resources fpc_all

A debian rules file for use with fpcmake is usually the same for every 
fpc project i.e.


Note this calls fpcmake automatically. A C/C++ build would call 
"configure" at the same point. I have defined the INTERFACE as an 
argument to the call to make.


#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
#
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of 
dh-make.

#
# Modified to make a template file for a multi-binary package with separated
# build-arch and build-indep targets  by Bill Allombert 2001

# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1

# This has to be exported to make some magic below work.
export DH_OPTIONS

DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

export FPCDIR=/usr/lib/fpc/$(shell fpc -iV)

configure: configure-stamp
configure-stamp:
    dh_testdir
    # Add here commands to configure the package.
    fpcmake -r Makefile.fpc

    touc

Re: [fpc-pascal] fpcmake packaging

[Tony Whyman via fpc-pascal]

fpcmake is a pre-processor that generates makefiles for fpc projects. 
You can use it to do just about anything a standard makefile can do, 
including including resource files and running scripts. I use it all the 
time for building production versions of lazarus programs and prior to 
packaging the programs and resources in .deb and .rpm files.


On 01/09/2020 13:37, Ryan Joseph via fpc-pascal wrote:

I've never used fpcmake before and instead relied on my own custom build system 
solutions which are a pain to maintain and non-standard which it makes extra 
work configuring the pascal language server I'm using now.

My first question of fpcmake is, can I package application bundles and copy 
resources using it? For example some things I need to do:

- create a directory structure and copy the executable into it
- copy resource files that may have changed
- run some shell commands which apple provides for compiling various resources 
files
- copy a info.plist text file and replace some patterns in the file to reflect 
the build version

Are those the kind of things fpcmake can do or do I need another build system 
for this?

Regards,
Ryan Joseph

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


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

Re: [fpc-pascal] FCL-DB Classes Implementation.

[Tony Whyman]

Then you might want to have a look at the IBX implementation of 
TIBArrayField.



On 31/10/2019 08:09, Michael Van Canneyt wrote:



On Wed, 30 Oct 2019, Kakoulidis Ioulianos wrote:

Are there plans to implement TArrayField, TADTField, TReferenceField, 
TDatasetField classes in fcl-db package?


Yes, as it happens, I started working on them 2 weeks ago. Currently I 
am working on TArrayField.


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


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

Re: [fpc-pascal] Read lines into UnicodeString variable from UCS2 (UTF-16) encoded text file

[Tony Whyman]

Text files and the console should look the same from the programmer's 
point of view. The general principle is that you should be able to 
redirect stdin to a file and for there to be no difference as far the 
program is concerned when reading a file as opposed to reading console 
input.


If there is a problem here, it is that the code page of text files 
cannot be declared.  While under Linux, FPC seems to have an implicit 
assumption that the console and text files are both UTF8, under Windows 
it seems to assume UCS2 (and then transliterated to the current code 
page) for the console and (by default) UTF8 for text files. A built-in 
assumption of UCS2 for Windows text files would seem to be more consistent.


Under all OSs you should be able to set the actual code page for a text 
file and the code page that input should be transliterated to.


On 05/09/2019 10:49, Tomas Hajny wrote:

On 2019-09-05 10:24, Tony Whyman wrote:

A few points:

1. IMHO: This is currently a Windows problem where the console buffer
is UCS2. Linux (and probably all other cases its UTF8 - to be
verified).

 .
 .

No, the subject refers to text files, not to console. Obviously, 
console output has its caveats, but that's something else - the 
possibly added functionality of being able to read and write text 
files with UTF-16 encoding using Read(Ln)/Write(Ln) does not imply 
that you might be able to change the console to whatever codepage 
value directly (this is not the case today either: you can perfectly 
write UTF-8 to a text file under GO32v2 if using the fpWideString 
manager, but the underlying communication is performed using the 
console encoding, not the text file encoding, and translation is 
needed on the fly).


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


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

Re: [fpc-pascal] Read lines into UnicodeString variable from UCS2 (UTF-16) encoded text file

[Tony Whyman]

Apologies: when I typed "FTP" below I meant "FPC" :( I'm currently 
drowning in acronym soup.


On 05/09/2019 09:24, Tony Whyman wrote:


A few points:

1. IMHO: This is currently a Windows problem where the console buffer 
is UCS2. Linux (and probably all other cases its UTF8 - to be verified).


2. The following Microsoft blog post is interesting background on 
where MS are going with this:


https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/

3. The current Windows API includes "SetConsoleCP" which should (I 
haven't tested this) allow you to set transliteration to UTF-8 when 
you call the Windows ReadConsoleInput API function. This seems to 
imply that FTP can be a consistent UTF8 environment even when the 
Windows Console buffer is UCS2.


4. Because console input is buffered, you probably cannot have a 
situation where readln changes the console code page to fit the type 
(unicode or ansistring) of the variable that you are reading into.


5. You could change FTP so that under Windows, the console is always 
read using UCS2 with transliteration to ansistring happening when 
required and depending on the type of the variable that you are 
reading into. I think that is probably what you are asking for under 
Windows:


- The console code page is always UCS2.

- Console input is read into unicodestrings in native mode

- Console input is read into ansistrings with transliteration from 
UCS2 after the input buffer has been parsed.


- Conversion to integers, floats, etc. occurs after transliteration to 
ansistring in order to avoid too many changes to the RTL.


- Under other OSs, Console input is UTF8 (or a supported ANSI code 
page). Transliteration to unicodestrings occurs after parsing the 
input buffer.


6. The question is: is it worth having a different approach to Windows 
when Windows allows you to set the console input buffer to UTF8 and 
hence have a common input environment for all OSs?


On 05/09/2019 08:00, LacaK wrote:
Is there consensus/demand on such solution and any patch in this 
direction will be accepted?
If yes we must agree on implementation details and IMO also someone 
must check what situation is in Delphi ... because I guess, that if 
Delphi does not support this that also FPC will not diverge?
Question1: should be supported "SetTextCodePage(CP_UTF16)" and 
"SetTextCodePage(CP_UTF16BE)"?

Question2: is this supported in Delphi?
If answer to both questions is YES then I will fill bug report as 
start point.


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

Re: [fpc-pascal] Read lines into UnicodeString variable from UCS2 (UTF-16) encoded text file

[Tony Whyman]

A few points:

1. IMHO: This is currently a Windows problem where the console buffer is 
UCS2. Linux (and probably all other cases its UTF8 - to be verified).


2. The following Microsoft blog post is interesting background on where 
MS are going with this:


https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/

3. The current Windows API includes "SetConsoleCP" which should (I 
haven't tested this) allow you to set transliteration to UTF-8 when you 
call the Windows ReadConsoleInput API function. This seems to imply that 
FTP can be a consistent UTF8 environment even when the Windows Console 
buffer is UCS2.


4. Because console input is buffered, you probably cannot have a 
situation where readln changes the console code page to fit the type 
(unicode or ansistring) of the variable that you are reading into.


5. You could change FTP so that under Windows, the console is always 
read using UCS2 with transliteration to ansistring happening when 
required and depending on the type of the variable that you are reading 
into. I think that is probably what you are asking for under Windows:


- The console code page is always UCS2.

- Console input is read into unicodestrings in native mode

- Console input is read into ansistrings with transliteration from UCS2 
after the input buffer has been parsed.


- Conversion to integers, floats, etc. occurs after transliteration to 
ansistring in order to avoid too many changes to the RTL.


- Under other OSs, Console input is UTF8 (or a supported ANSI code 
page). Transliteration to unicodestrings occurs after parsing the input 
buffer.


6. The question is: is it worth having a different approach to Windows 
when Windows allows you to set the console input buffer to UTF8 and 
hence have a common input environment for all OSs?


On 05/09/2019 08:00, LacaK wrote:
Is there consensus/demand on such solution and any patch in this 
direction will be accepted?
If yes we must agree on implementation details and IMO also someone 
must check what situation is in Delphi ... because I guess, that if 
Delphi does not support this that also FPC will not diverge?
Question1: should be supported "SetTextCodePage(CP_UTF16)" and 
"SetTextCodePage(CP_UTF16BE)"?

Question2: is this supported in Delphi?
If answer to both questions is YES then I will fill bug report as 
start point.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Read lines into UnicodeString variable from UCS2 (UTF-16) encoded text file

[Tony Whyman]

You may be able to improve on this using system.BlockRead.

Also, you are assuming low order byte first which may not be portable.

On 04/09/2019 11:14, LacaK wrote:

Nice! Thank you very much.

As an alternative for F:TextFile I am using:

procedure UCS2ReadLn(var F: TextFile; out s: String);
var
  c: record
  case boolean of
   false: (a: array[0..1] of AnsiChar);
   true : (w: WideChar);
 end;
begin
  s:='';
  while not Eof(F) do begin
    System.Read(F,c.a[0]);
    System.Read(F,c.a[1]);
    if c.w in [#10,#13] then
  if s = '' then {begin of line} else break {end of line}
    else
  s := s + c.w;
  end;
end;

which works for me also, but I would be like to have better solution. 
I will try LoadFromFile with TEncoding once FPC 3.2 will be out.


-L.


Stupid an lazy workaround, probably not suitable for larger files.

{$mode objfpc}
{$h+}
uses
   sysutils;

type
   TUCS2TextFile = file of WideChar;

procedure ReadLine(var F: TUCS2TextFile; out S: UnicodeString);
var
   WC: WideChar;
begin
   //Assume file is opend for read
   S := '';
   while not Eof(F) do
   begin
 Read(F, WC);
 if WC = WideChar(#$000A) then
   exit
 else
   if (WC <> WideChar(#$000D)) and (WC<>WideChar(#$FEFF {Unicode LE
BOM})) then S := S + WC;
   end;
end;

var
   UFile: TUCS2TextFile;
   US: UnicodeString;
begin
   AssignFile(UFile, 'ucs2.txt');
   Reset(Ufile);
   while not Eof(UFile) do
   begin
 ReadLine(UFile, US);
 writeln('US = ',US);
   end;
   CloseFile(UFile);
end.

Outputs
US = Line1
US = Line2
US = Line3
which is correct for my test file (Unicode LE encoding created with 
Notepad).


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

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


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

Re: [fpc-pascal] MD5 Hash of StringList

[Tony Whyman]

Be careful, the code below is codepage dependent. TStrings.GetTextStr 
does not inspect the codepage of each string and simply moves the 
characters into a common buffer. Fast, but the question is: are you 
using the hash to compare two string lists that are binary equivalent or 
two string lists that contain the same unicode characters. The code 
below only guarantees to answer the first question.


On 04/07/2019 23:58, Bo Berglund wrote:

On Thu, 4 Jul 2019 18:13:44 +0200, José Mejuto
 wrote:


El 04/07/2019 a las 18:13, James Richters escribió:

Thanks you!

That got me on the right path.
Here's the working sample:

Hash  := Md5Print(MD5String(MyStringlist.Text));


Warning! That's platform dependent code due the new line sequences.

Maybe:

MyStringList.LineBreak := #10;
Hash  := Md5Print(MD5String(MyStringlist.Text));

Then the new line issue may be solved?



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

Re: [fpc-pascal] [OT] Mantis offline

[Tony Whyman]

Seems to be online in the UK.

On 10/05/2019 15:33, silvioprog wrote:

Hello.

Could anyone check if Mantis is online? I've tried to access 
http://bugs.freepascal.org  now (Fri 10 
May 2019 11:30:37 AM BRT), but got "This site can’t be reached". Some 
hours ago it was OK.


--
Silvio Clécio

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

Re: [fpc-pascal] how to make a type private to the unit but not defining it in the implementation section?

[Tony Whyman]

I would use an "interface" type in this situation.

In the unit's "interface" section define the interface type and a 
function to create a new instance of the interface.


In the unit's implementation define all your classes including a class 
that provides the interface. The implementation of the function that 
creates a new instance of the interface should create and return a new 
instance of the class that provides the interface.


If you are using COM interfaces then you don't even need to explicitly 
destroy the interface as they are automatically deleted when all 
references go out of scope. if you use CORBA interfaces then your 
interface definition should include a method to free the interface.


On 07/03/2019 08:10, Dennis wrote:

unit frproxyserver;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ExtCtrls, Grids,
  frBase;

type

  TMyStringGrid=class(TStringGrid) //how to I make this class visible 
only to this unit?

  public
  end;

  { TProxyServerFrame }

  TProxyServerFrame = class(TBaseFrame)
    Panel_Top: TPanel;
    StringGrid1: TMyStringGrid;
  private

  public

  end;

implementation

{$R *.lfm}

end.

=
My reason is I don't want to pollute the name space but if I put the 
declaration of TMyStringGrid in the implementation section, it cannot 
be used by the field in the class declaration of TProxyServerFrame.


if there a compiler directive that I can put around
TMyStringGrid to make it only visible to the unit frproxyserver?

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


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

[fpc-pascal] Weird FPC String Manager Bug

[Tony Whyman]

There seems to be some sort of weird race condition with the FPC 
string/memory manager. It is not easy to replicate, but the program 
Gabor Boros posted earlier today to the Lazarus list does seem to find 
the problem consistently.


The program he posted is a simple example of using MWA's Firebird Pascal 
Interface and causes an unhandled exception on program exit. This seems 
to occur after all user code has terminated and the heaptrc unit has 
reported its results. It only seems to occur when using "release" 
versions of the RTL and FCL libraries and not when using debug versions. 
A simple fix is to add "sleep(1);" to the end of the program. Just how 
weird it that!


I believe that I have isolated the problem to this code snippet - which 
looks simple enough:


procedure TOutputBlockItem.SetString(out S: AnsiString; Buf: PByte;
  Len: integer; CodePage: TSystemCodePage);
var rs: RawByteString;
begin
  system.SetString(rs,PAnsiChar(Buf),len);
  SetCodePage(rs,CodePage,false);
  S := rs;
end;

Its purpose is to set an AnsiString from text in a buffer and to set its 
codepage. If I change it to:


procedure TOutputBlockItem.SetString(out S: AnsiString; Buf: PByte;
  Len: integer; CodePage: TSystemCodePage);
var rs: RawByteString;
    i: integer;
begin
  rs := '';
  for i := 0 to len-1 do
    rs := rs + PAnsiChar(buf+i)^;
  SetCodePage(rs,CodePage,false);
  S := rs;
end;

then the bug goes away and the program completes normally. On the other 
hand, if I change it to:


procedure TOutputBlockItem.SetString(out S: AnsiString; Buf: PByte;
  Len: integer; CodePage: TSystemCodePage);
var rs: RawByteString;
begin
  SetLength(rs,len)
  if len > 0 then
    Move(Buf^,rs[1],len);
  SetCodePage(rs,CodePage,false);
  S := rs;
end;

then the exception is still raised at the end of the program. On the 
other hand, if I combine the two fixes to:


procedure TOutputBlockItem.SetString(out S: AnsiString; Buf: PByte;
  Len: integer; CodePage: TSystemCodePage);
var rs: RawByteString;
    i: integer;
begin
  SetLength(rs,len)
  if len > 0 then
    Move(Buf^,rs[1],len);
  rs := '';
  for i := 0 to len-1 do
    rs := rs + PAnsiChar(buf+i)^;
  SetCodePage(rs,CodePage,false);
  S := rs;
end;

then the program completes with no exception. My guess is that the 
problem is something to do with setting the length on a rawbytestring 
and its disposal when the rawbytestring goes out of scope. Can anyone 
see an obvious problem that I am missing?



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

Re: [fpc-pascal] -CR Command line switch and Firebird.pas

[Tony Whyman]

Many thanks - not the most obvious of switch names - but it works.


On 04/03/18 14:41, Jonas Maebe wrote:

On 04/03/18 15:38, Tony Whyman wrote:
Is there anyway of turning off the command line switch -CR 
(Verify object method call validity) on a per unit basis in the same 
way that -Cr (range checking) can be turned off using {$R-}? I can't 
see any such directive in the FPC documentation.


{$OBJECTCHECKS off}


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



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

Re: [fpc-pascal] Comp type

[Tony Whyman]

Thanks for the history. Comp has always puzzled me before, especially 
with these two functions from the RTL


function MSecsToTimeStamp(MSecs: Comp): TTimeStamp;
function TimeStampToMSecs(const TimeStamp: TTimeStamp): comp;

I assume that these have come down from Turbo Pascal - but it still 
seems odd that milliseconds is represented by a "real" type.


Tony Whyman


On 10/01/18 08:04, Jonas Maebe wrote:

Mattias Gaertner wrote:

Comp is Int64 div 1.

No, that is currency. Comp is a plain 64 bit integer. It originally
comes from Turbo Pascal, which did not have a regular 64 bit integer
type. The x87 fpu can be used to perform 64 bit integer math though, so
it was originally a 64 bit integer type whose calculations were
performed using the fpu.

In FPC, it's the same on platforms that still use the x87 fpu. On other
platforms, comp is an alias for the int64 type.


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



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

Re: [fpc-pascal] Possible Memory Leak in TThread.Synchronize

[Tony Whyman]

Thanks, I found the problem - the thread was not being destroyed 
correctly on completion and this manifested itself in what looked like a 
weird memory leak.



On 03/01/18 11:49, Michael Van Canneyt wrote:



On Wed, 3 Jan 2018, Tony Whyman wrote:



The line "Dispose(tmpentry);" also disposes of a SynchronizeEvent 
but, unlike TThread.DoneSynchronizeEvent, there is no RtlEventDestroy.


Am I correct in pointing the finger here for the memory leak?


I doubt it, since AFAIK the RTL event is a OS object, and as such is 
not allocated on the

heap ?

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



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

[fpc-pascal] Possible Memory Leak in TThread.Synchronize

[Tony Whyman]

I have been investigating a possible memory leak in a multi-threading 
Lazarus program compiled with 3.0.4 where the stack trace with heaptrc 
shows:


Heap dump by heaptrc unit
7014 memory blocks allocated : 131978472/131992352
7004 memory blocks freed : 114543216/114557096
10 unfreed memory blocks : 17435256
True heap size : 19267584
True free heap : 1831200
Should be : 1831048
Call trace for block $7FFFE2A9D0C0 size 96
  $0043B31A line 354 of ../inc/heap.inc
  $00450FE8 line 888 of ../unix/cthreads.pp
  $0043DB9F line 294 of ../inc/thread.inc
  $004AE6B4 line 322 of ../objpas/classes/classes.inc
  $004AE754 line 344 of ../objpas/classes/classes.inc
  $004AE7F0 line 357 of ../objpas/classes/classes.inc
  

Line 322 of classes.inc reads:

    FSynchronizeEntry^.SyncEvent := RtlEventCreate;

Hence the implication is that the SyncEvent is not being disposed of 
correctly. Later on TThread.DoneSynchronizeEvent reads


procedure TThread.DoneSynchronizeEvent;
  begin
    if not Assigned(FSynchronizeEntry) then
  Exit;

    RtlEventDestroy(FSynchronizeEntry^.SyncEvent);
    Dispose(FSynchronizeEntry);
    FSynchronizeEntry := Nil;
  end;

So no problem here it seems. However, investigating further, this is not 
the only place that a SynchronizeEvent is disposed of. At line 379 of 
classes.inc we see:


function CheckSynchronize(...)

and this ends with:

    else
  begin
  { for Queue entries we dispose the entry and raise the exception }
  Dispose(tmpentry);
  if Assigned(exceptobj) then
    raise exceptobj;
  end;
    tmpentry := PopThreadQueueHead;
    end;

The line "Dispose(tmpentry);" also disposes of a SynchronizeEvent but, 
unlike TThread.DoneSynchronizeEvent, there is no RtlEventDestroy.


Am I correct in pointing the finger here for the memory leak?

Tony Whyman

MWA


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

Re: [fpc-pascal] Database apps on Debian etc.

[Tony Whyman]

There are actually two issues sitting here:

1. Transaction Recovery and

2. Knowing when you've lost a connection and when to restart it.

I am not familiar with PostgreSQL but with a transaction oriented 
database such as Firebird or Oracle, when you lose a connection, 
re-connecting doesn't also imply recovering the transaction. Your 
transaction may be in limbo and require manual rollback or commit 
depending on what is the most desirable outcome and, until you do this 
your database may not be in a consistent state - depending on the 
application. It gets even more complication with transactions across 
multiple databases when two phase commit issues appear.


It is also not always obvious when you have lost a connection. TCP 
depends on both retransmission and inactivity timers to detect 
connection loss and some implementations don't even detect connection 
loss during periods of inactivity and only detect the loss when no reply 
is received after several retries. In short, there can be a long time 
between connection loss and it being noticed by either the server or the 
client - and those events may be well separated in time. Indeed, the 
user may already be on the line to the help desk  complaining that their 
computer is no longer responding, long  before the lost connection error 
message gets displayed.


The bottom line is that neither detecting connection loss nor recovering 
from it is a simple matter. In any serious database application, you 
need to think about how responsive you need to be to connection loss, 
and how to recover from it. How quickly you need to detect it and then 
once detected, what is the recovery strategy. Will it require a database 
administrator action to rollback or commit outstanding transactions? Is 
it appropriate to always rollback limbo transactions, or do you need to 
decide the appropriate recovery on a case by case basis?


There is no "one size fits all" answer to the problem. The ideal is that 
there are no lost connections, except in extreme circumstances such as 
hardware failure. Automatic updates may seem a good idea, but sometimes 
it's better to plan and schedule upgrades during planned outages rather 
than letting them happen when you least want them.



On 11/11/17 18:41, Mark Morgan Lloyd wrote:
Graeme started a short thread on databases in "The Other Place" a few 
days ago, but I thought this might be of sufficient general relevance 
to raise here.


I had a system outage this morning, with all apps suddenly losing 
their connectivity to the PostgreSQL server.


It turned out that the cause of that was that Debian had done an 
unattended upgrade of the Postgres server, and by restarting it had 
killed all persistent connections. There is no "Can we kill your 
database when we feel like it?" question during Debian installation.


I anticipate that the same problem will affect other databases or 
software to which a client program maintains a persistent session, 
unless explicit steps are taken to recognise and recover from a 
server-side restart.


Noting that the traditional way of using the data-aware controls 
introduced by Delphi etc., is particularly vulnerable, and noting that 
the FPC/Lazarus controls do a good job of presenting a common API 
irrespective of what backend server is being used, would it be 
feasible to have a "reconnect monitor" or similar to help recover from 
this sort of thing?




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

Re: [fpc-pascal] Problem with array of const

[Tony Whyman]

I've fallen into various traps with array of const before. I would 
always recommend that:


1. Test the vType before accessing the argument value and raise an 
exception if it is not what is expected. You are dealing with a free 
union and the compiler may not always do what you expect it to.


2. Values such as VAnsiString are best dealt with as PChars as otherwise 
you can quickly get into problems with reference counts.


For example:

program test_args;

procedure test(name: string; args: array of const);
begin
  writeln(name);

  case args[0].vType of

  vtAnsiString:
    writeln(strpas(PAnsiChar(args[0].VAnsiString)));
  else
    raise Exception.Create('Unexpected vtype');
  end;

end;

begin
  test('name', ['arg']);
end.

Use of "strpas" is probably unnecessary in the above, but it does 
illustrate the point.



On 28/10/17 23:59, Darius Blaszyk wrote:
Consider the application below. When I run it I do get the following 
output:


name
rg
name�F&{---C000-0046}

In other words I lose the first character (a) from the arguments 
supplied and the string returns with a lot of garbage. What am I doing 
wrong here?


Rgds, Darius

program test_args;

procedure test(name: string; args: array of const);
begin
  writeln(name);
  writeln(args[0].VString^);
end;

begin
  test('name', ['arg']);
end.


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


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

Re: [fpc-pascal] CRT unit and Windows' terminal

[Tony Whyman]

It may be worth looking at the SetTextCodePage in the System unit. On 
Windows targets I often find it necessary to include


SetTextCodePage(output,cp_utf8);

to avoid problems writing UTF-8 to the console.


On 14/10/17 08:12, pasc...@piments.com wrote:

On 13/10/17 14:39, James Richters wrote:
I‘ve tried Writeln(Chr(9556)) but chr() has a limit of 255, and I’ve 
tried just Writeln(#9556) and while that compiles and runs, it 
doesn’t produce the correct character.. I have a feeling (but have 
not tested it) that it keeps cycling around the first 256 characters 
if you use anything above 255….. pretty sure a character is defined 
as a byte here.



Thanks for that lengthy description of the problem, much better than 
OP's just describing output as rubbish, or something similar.


since char is a single byte type a large value will just get 
truncated. If you turn on range checking it should return a compiler 
time error. You could check that.


Maybe doing that would cast some light on what is going wrong in CRT 
as well.


P

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



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

Re: [fpc-pascal] {$DEFINE DEVEL}

[Tony Whyman]

Try adding a space between the { and $ e.g.

{ $DEFINE DEVEL}

FPC then ignores the define


On 11/10/17 10:00, pasc...@piments.com wrote:

Hi ,

I had a little trick that I used on BP and Delphi code that does not 
work on Lazarus.


I define compiler variable which I could toggle on and off by adding a 
second opening curly bracket, since the define only works if the line 
starts {$



{$DEFINE DEVEL}


If I start the line {{$  Delphi ignores it but Lazarus then highlights 
the rest of the code as a comment and it fails to compile.


main.pas(172,1) Warning: Comment level 2 found


Is this a bug or a feature?

Can anyone suggest a similar one key trick ?

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



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

Re: [fpc-pascal] alternative name fpc cross

[Tony Whyman]

On 10/10/17 13:50, pasc...@piments.com wrote:

On 10/10/17 13:29, Karoly Balogh (Charlie/SGR) wrote:

  Linux Subsystem for Windows.


While I know what you mean ...

I used to be maintainer on Wine AppDB for several years. Nothing ever 
worked from one release to the next.  WINE spent 10y  as an alpha 
release and it started to get embarrassing so they called it beta. 
Everything still, broke , it is still an alpha produce in all but name.


Sadly the target is moving faster than their ability to emulate it.

As for attempting to run a stable and secure  OS inside an insecure 
and unstable one, that's a great way to combine all the disadvantages 
of both. Probably clinically certifiable behaviour or at least 
"autistic spectrum".



On the other hand, without wine (and mono) I couldn't run WIX on Linux.

 If I couldn't run WIX on Linux then I could not build WIndows 
Installer Packages on Linux.


 If I couldn't build WIndows Installer Packages on Linux then I would 
not be able to have one script building for both Linux and Windows targets.


And then what would be the point of having cross-compilers and cross 
platform libraries in the first place.

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

Re: [fpc-pascal] getting cross with the cross compiler

[Tony Whyman]

On 10/10/17 05:51, pasc...@piments.com wrote:
$make all NOGDB=1 OS_TARGET=linux CPU_TARGET=x86_64 
INSTALL_PREFIX=/usr
Makefile:2914: *** The only supported starting compiler version is 
3.0.0. You are trying to build with 3.1.1..  Stop.


BTW is  that msg  is correct? I just built with 3.0.2 , it seems that 
the version block is not specific enough or the message missed a 
version bump. 
Yes, that message is always very irritating - but probably right. The 
FPC compiler I currently use is built from the fixes_3_0 branch and this 
demands the 3.0.0 compiler to initially compile the compiler. The first 
time I build from source there is no problem. I install the 3.0.0 
compiler from a binary and build the source and install it. The second 
time, the error message occurs because you now have a more recent 
version as the installed compiler.


The way I avoid the problem is to have a script I always use to build 
from source and to force the use of the 3.0.0 compiler for the initial 
build. This is still on the system and will stay there (unless 
explicitly deleted) even after the later version is installed. My script 
saves the initial compiler version in a file "build-version" which is 
added to my working copy of the source code tree. The script is given 
below as an example and is intended to be run in the root directory of 
the source tree. Note the use of the PP make variable for passing the 
path to the initial build compiler.


  PREFIX=/usr
  FPCPROG=ppcx64

    if [ ! -f build-version ]; then
      fpc -iV >build-version
    fi

  BUILDVERSION=`cat build-version`

  if [ ! -x $PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG ]; then
    echo "FPC Build Version ($BUILDVERSION) not found"
    exit 1
  fi

  echo "make default target compiler and libraries"

  export FPCDIR=$PREFIX/lib/fpc/$BUILDVERSION


  make all PP=$PREFIX/lib/fpc/$BUILDVERSION/$FPCPROG OPTIMIZE=1
  if [ $? -ne 0 ]; then
    exit $?
  fi

  if [ ! -x compiler/$FPCPROG ]; then
    echo "Failed to build compiler"
    exit 1
  fi

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

Re: [fpc-pascal] getting cross with the cross compiler

[Tony Whyman]

On 10/10/17 05:51, pasc...@piments.com wrote:
Were it not for the version restrictions in building fpc one could 
arguably say this was a reasonable assumption.  As it is, it leads to 
a very confused and confusing state which has taken several days to 
understand and untangle.



Maybe that could be addressed.

Thanks for the help along the way. 
I do make a lot of use of the cross-compiler and the cross-platform 
libraries capability of FPC and I am wondering if you might be looking 
at the problem in the wrong way, especially when you seem to be talking 
about using the cross-compiler for the Lazarus IDE. Here's how I use 
them and hopefully this will inform your own understanding.


1. When I develop a program using the Lazarus IDE, I am only working 
with the native (debug) libraries for the development platform. In my 
case, this is 64-bit Linux. Occasionally, I will run 64-bit Windows in a 
virtual machine and Lazarus (in native Windows mode) to test for Windows 
specific issues. During the development and test cycle I do not use 
cross-compilers or libraries and you would probably only need to do this 
when compiling for a target on which it is just not practical to run the 
Lazarus IDE.


2. The cross-compiler and libraries come into their own when I generate 
production executables and installation packages as they enable the 
whole process to be performed on the same platform (Linux 64-bit) for my 
required target platforms: Linux (32-bit and 64-bit) and Windows (32-bit 
and 64-bit), and automated using a single script - which then goes on to 
build the Debian packages and Windows installer packages.


3. I always compile FPC from source. For the development platform, a 
64-bit compiler is needed and the FPC RTL and FCL libraries include 
debug symbols. The Lazarus IDE compiles its libraries (LCL and 
components) using this compiler and the FPC libraries, and works very 
nicely without the user needing to understand too much about what is 
going on - or even having to do much in the way of IDE configuration.


4. For the production platform, a 32-bit cross complier is also needed 
as are optimised RTL and FCL libraries and optimised Lazarus libraries. 
These libraries have to be built explicitly for each of the production 
platforms. I have a separate location in the filesystem for the 
production libraries (separate from development libraries) with 
sub-directories for x86_64-linux, x86_64-win64, i386-linux, i386-win32. 
Within the Lazarus parts of the libraries, the Linux libs have the gtk2 
interface libraries, while the Windows ones have the win32 interfaces 
libraries (both win32 and win64).


5. I then use FPC Makefiles to build for each target platform in turn 
which reference the production and not the development libraries. This 
includes Lazarus programs and the Lazarus IDE does not have anything to 
do with this part of the process. Indeed, it would complicate matters no 
end to try and use the IDE to build for each production target.


If you have taken only a few days to dis-entangle all there is to know 
about cross compilation and cross platform libraries then I think you 
are doing very well. It has taken me far longer than that to work out 
the toolchain that I need and I am still learning the best way to do 
things. Indeed, there may be no "best way" to do things. The above works 
for me, but may not work for you. However, the advice that I would give 
is that as soon as you start to talk about cross-compilers, then you 
need to start thinking about the differences between development and 
production environments. Unless you are working with embedded systems, 
then my advice is don't try to work with cross-compilers for 
development. On the other hand, when you generate production executables 
then cross-compilers and cross platform libraries are very useful for 
automating the process and ensuring consistent quality across all target 
platforms. However, you do need to think through carefully how the 
toolchain works and explicitly generate optimised libraries for each 
target platform including the Lazarus interface appropriate for the 
target. Use the IDE for development but have a separate scripted 
environment for generating production executables.


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

[fpc-pascal] Yet another thread on Unicode Strings

[Tony Whyman]

Unicode Character String handling is a question that keeps coming up on 
the Free Pascal Mailing lists and, empirically, it is hard to avoid the 
conclusion that there is something wrong with the way these character 
string types are handled. Otherwise, why does this issue keep arising?


Supporters of the current implementation point to the rich set of 
functions available to handle both UTF-8 and UTF-16 in addition to 
legacy ANSI code pages. That is true – but it may be that it is also the 
problem. The programmer is too often forced to be aware of how strings 
are encoded and must make a choice as to which is the preferred 
character encoding for their program. There then follows confusion over 
how to make that choice. Is Delphi compatibility the goal? What 
Languages must I support? If I want platform independence which is the 
best encoding? Which encoding gives the best performance for my 
algorithm? And so on.


Another problem is that there is no character type for a Unicode 
Character. The built-in type “WideChar” is only two bytes and cannot 
hold a UTF-16 code point comprising two surrogate pairs. There is no 
char type for a UTF-8 character and, while UCS4Char exists, the Lazarus 
UTF-8 utilities use “cardinal” as the type for a code point (not exactly 
strong typing).


In order to stop all this confusion I believe that there has to be a 
return to Pascal's original fundamental concept. That is the value of a 
character type represents a character, while the encoding of the 
character is platform dependent and a choice the compiler makes and not 
the programmer. Likewise a character string is an array of characters 
that can be indexed by character (not byte) number, from which 
substrings can be selected and compared with other strings according to 
the locale and the unicode standard collating sequence. Let the 
programmer worry about the algorithm and the compiler worry about the 
best implementation.


I want to propose a new character type called “UniChar” - short for 
Unicode Character, along with a new string type “UniString” and a new 
collection “TUniStrings”. I have presented my thoughts here in a 
detailed paper


see https://mwasoftware.co.uk/docs/unistringproposal.pdf

This is intended to be a fully worked proposal and I have circulated it 
to provoke discussion and in the hope that it may be useful.


The intent is to create a character and string handling design that is 
natural to use with the programmer rarely if ever having to think about 
the character or string encoding. They are dealing with Unicode 
Characters and strings of Unicode Characters and that is all. When 
necessary, transliteration happens naturally and as a consequence of 
string concatenation, input/output, or in the rare cases when 
performance demands a specific character encoding.


There is also a strong desire to avoid creating more choice and hence 
more confusion. The intent is to “embrace and replace”. Both AnsiString 
and UnicodeString should be seen as subsets or special cases of the 
proposed UniString, and with concrete types such as AnsiChar, WideChar 
and WideString, other than for legacy reasons, existing primarily to 
define external interfaces.


Tony Whyman

MWA Software

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

Re: [fpc-pascal] Where and Why is there a memory leak?

[Tony Whyman]

Is history repeating itself:

http://lists.freepascal.org/pipermail/fpc-pascal/2016-August/048579.html


On 06/09/17 09:31, Graeme Geldenhuys wrote:

Hi,

Playing with this small sample application to answer another question 
in this mailing list, I noticed the sample application has a memory 
leak. For the life of me I can't see why or how to resolve it.


I tested with FPC 2.6.4, 3.0.2 and 3.0.4-rc1 under 64-bit FreeBSD.

===[ project1.pas ]
program project1;

{$mode objfpc}{$H+}
{$interfaces COM}

type
  IHook = interface
['{4BCAEDD8-92D8-11E7-88D3-C86000E37EB0}']
procedure DoIt;
  end;

type
  THook = class(TInterfacedObject, IHook)
  private
procedure DoIt;
  end;

  procedure THook.DoIt;
  begin
writeln(ClassName + ' did it');
  end;

type
  TBaseClass = class(TInterfacedObject, IHook)
  private
FHook: IHook;
property Hook: IHook read FHook implements IHook;
  public
constructor Create;
destructor Destroy; override;
  end;

  constructor TBaseClass.Create;
  begin
FHook := THook.Create;  // FPC 2.6.4 reports a memory leak here
  end;

  destructor TBaseClass.Destroy;
  begin
// nothing to do here
  end;


var
  base: IHook;

begin
  base := TBaseClass.Create;
  base.DoIt;
  base := nil; // just to see if it helped with the memory leak - it 
doesn't


end.
==[ end ]==


When I run the program, the output is as follows:

[t1]$ ./project1
THook did it
Heap dump by heaptrc unit
4 memory blocks allocated : 115/120
2 memory blocks freed : 51/56
2 unfreed memory blocks : 64
True heap size : 1114112 (32 used in System startup)
True free heap : 1113696
Should be : 1113760
Call trace for block $00080072F180 size 32
  $00400379 line 35 of project1.lpr
Call trace for block $00080072F0C0 size 32



Personally I always use CORBA style interfaces, never reference 
counted COM style interfaces. So my programs normally don't have this 
issue, and I use interfaces a lot.





Regards,
  Graeme



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

[fpc-pascal] Proposed tidy-up of the FPC Manual section on Character Types and the FPC Wiki

[Tony Whyman]

There has been some heated discussion on the Lazarus lists on the 
subject to character encodings etc. This has exposed several issues with 
the FPC Manual that I wanted to record.


1. The char type

The manual says: "A Char is exactly 1 byte in size, and contains one 
ASCII character. "


This was probably true when Pascal was first defined, but char is often 
now used for any on-byte character set e.g. ISO 8859-1. Replace ASCII 
with ANSI.


2. WideChar

The Manual says: "A WideChar is exactly 2 bytes in size, and contains 
one UNICODE character in UTF-16 encoding. "


This seems to be wrong as UTF-16 is not limited to code points defined 
using a single 16-bit code unit, but also permits code points comprising 
two 16-bit code units. The definition should be updated to indicate that 
a WideChar was really created for the obsolescent UCS-2 and is limited 
to a UTF-16 subset (Unicode characters that can be expressed as a single 
16-bit code unit).


Proposed replacement text: "A WideChar is exactly 2 bytes in size, and 
contains one UNICODE character in UCS-2 encoding or UTF-16 encoding 
limited to the Basic Multilingual Plane. Note that Unicode Characters 
represented by a UTF-16 code points that require two 16-bit code units 
cannot be contained in a single WideChar variable."


3. UnicodeStrings

The Manual says: "For multi-byte string types, the basic character has a 
size of at least 2."


Proposed improvement:

"Multi-byte string types are used to represent Unicode characters 
encoded as code points requiring two or four bytes".


As with UTF8String, the following caveat should also be added:

"Since a unicode character may require two or four bytes to be 
represented in the UTF-16 encoding, there are 2 points to take care of 
when using UnicodeString/WideString:


1. The character index – which retrieves a WideChar at a certain 
position – must be used with care: the expression S[i] will not 
necessarily be a valid character for a string S of type 
UnicodeString/WideString.


2. The  length of the string is not necessarily equal to the number of 
elements in the array. The standard function length cannot be used to 
get the character length of the string, it will always return the array 
length.


--

Wiki Page on "Character and string Type"

1. This needs to start with a Health Warning on the use of the word 
Unicode. Proposed Text (borrowing from Wikipedia):


"Free Pascal supports several character and string types. They range 
from single ANSI characters to unicode strings and also include pointer 
types. Differences also apply to encodings and reference counting. ANSI 
is typically used to refer to single byte character encodings - although 
FPC also uses AnsiStrings to hold Unicode UTF-8 encoded strings.


Unicode is a computing industry standard for the consistent encoding, 
representation, and handling of text expressed in most of the world's 
writing systems. Developed in conjunction with the Universal Coded 
Character Set (UCS) standard and published as The Unicode Standard, the 
latest version of Unicode contains a repertoire of 136,755 characters 
covering 139 modern and historic scripts, as well as multiple symbol sets.


Unicode can be implemented by different character encodings. The Unicode 
standard defines UTF-8, UTF-16, and UTF-32, and several other encodings 
are in use. The most commonly used encodings are UTF-8, UTF-16 and 
UCS-2, a precursor of UTF-16.


The original idea behind Unicode was to replace the typical 
256-character encodings requiring 1 byte per character with an encoding 
using 2^16 = 65,536 values requiring 2 bytes per character.The early 
2-byte encoding was usually called "Unicode", but is now called "UCS-2". 
UCS-2 differs from UTF-16 by being a constant length encoding and only 
capable of encoding characters of Basic Multilingual Plane (BMP), it is 
supported by many programs. However, "UCS-2 should now be considered 
obsolete. It no longer refers to an encoding form in either 10646 or the 
Unicode Standard.


Unfortunately, the term Unicode, in common usage, is still often used to 
refer to the UCS-2 two byte encoding and this can give rise to much 
confusion e.g. when Unicode is used when referring to the UTF-8 encoding."


2. The text on WideChar is too terse and needs to be expanded. Proposed 
text:


"A variable of type WideChar, also referred to as UnicodeChar (which 
derives from the archaic use of Unicode to mean UCS-2), is exactly 2 
bytes in size, and usually contains either:


(a) a single UCS-2 code point, or

(b) a single UTF-16 code unit.

In case (b), this is sufficient for Unicode Characters that have a 
UTF-16 code point that comprises a single 16-bit code unit i.e. 
characters in the Basic Multilingual Plane. However, all other UTF-16 
characters have a UTF-16 code point that comprises a two 16-bit code 
units. FPC provides no specific support for such characters which 
require, e.g. a 

[fpc-pascal] FPC FIXES__3_0 fails to compile

[Tony Whyman]

When compiling the latest fixes branch under Linux 64-bit fpc 3.0.2, 
with the following make command:


make all  OS_TARGET=linux CPU_TARGET=x86_64 NOGDB=1 OPT=-O3 NEWOPT=-O4

The compilation failed with:

/bin/mkdir -p x86_64/units/x86_64-linux
make ./msg2inc
make[6]: Entering directory `/home/tony/fpcsrc/fpcfixes/compiler'
/usr/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems 
-Fu/home/tony/fpcsrc/fpcfixes/rtl/units/x86_64-linux -Fix86_64 -FE. 
-FUx86_64/units/x86_64-linux -Cg -dRELEASE -O3   -dx86_64 -dGDB 
-dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp

msg2inc.pp(800,8) Warning: Variable "Mode" does not seem to be initialized
msg2inc.pp(824) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[6]: *** [msg2inc] Error 1
make[6]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler'
make[5]: *** [msgtxt.inc] Error 2
make[5]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler'
make[4]: *** [next] Error 2
make[4]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler'
make[3]: *** [ppc1] Error 2
make[3]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler'
make[2]: *** [cycle] Error 2
make[2]: Leaving directory `/home/tony/fpcsrc/fpcfixes/compiler'
make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory `/home/tony/fpcsrc/fpcfixes'
make: *** [build-stamp.x86_64-linux] Error 2

The output of svn info is

Working Copy Root Path: /home/tony/fpcsrc/fpcfixes
URL: https://svn.freepascal.org/svn/fpc/branches/fixes_3_0
Relative URL: ^/branches/fixes_3_0
Repository Root: https://svn.freepascal.org/svn/fpc
Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2
Revision: 36236
Node Kind: directory
Schedule: normal
Last Changed Author: pierre
Last Changed Rev: 36152
Last Changed Date: 2017-05-07 23:13:21 +0100 (Sun, 07 May 2017)

As  a sanity check, I tried the same make command with fpc trunk 
(r36236) and that compiles with no errors.


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

Re: [fpc-pascal] Out of scope method?

[Tony Whyman]

Ryan,

If you want an example of a complete API implemented using reference 
counted interfaces than you could do worse than look at my Firebird 
Pascal API (See https://www.mwasoftware.co.uk/fb-pascal-api).


It's fully documented and works with both FPC and Delphi.

Tony Whyman
MWA


On 06/04/17 15:48, Ryan Joseph wrote:

On Apr 6, 2017, at 9:42 PM, Marcos Douglas B. Santos <m...@delfire.net> wrote:

Lose type checking?
Of course not. You still use the same language, interfaces, classes...

Don't confuse "New, the function" with "New, a method in a class".

I should say that you need to have a matching interface for all your classes, 
and if not then you’ll lose type checking. IAction needs to have all the 
methods in TAction for type checking to work right?

Regards,
Ryan Joseph

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



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

Re: [fpc-pascal] Out of scope method?

[Tony Whyman]

See http://freepascal.org/docs-html/current/ref/refse48.html#x101-1230007.7
for an example.

See also http://wiki.freepascal.org/How_To_Use_Interfaces

On 06/04/17 10:08, Ryan Joseph wrote:

On Apr 6, 2017, at 3:45 PM, Tony Whyman <tony.why...@mccallumwhyman.com> wrote:

Isn't this what a COM Interface does - or at least a descendent of 
TInterfacedObject?

Tony Whyman

No idea. Examples?

Regards,
Ryan Joseph

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



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

Re: [fpc-pascal] Out of scope method?

[Tony Whyman]

Isn't this what a COM Interface does - or at least a descendent of 
TInterfacedObject?


Tony Whyman

MWA


On 06/04/17 09:00, Ryan Joseph wrote:

Does it exist now or has it ever been discussed that a method in TObject could 
be called when an instance of an object goes out of scope? It’s common to clean 
up objects in a function body after the function exits and calling a method 
would be a nice way to handle this. I think c++ has such a feature but I never 
heard of it in Pascal.

Regards,
Ryan Joseph

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



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

Re: [fpc-pascal] Threading vs Parallelism ?

[Tony Whyman]

On 31/03/17 09:55, Gary Doades wrote:

However, multiple independent compute units must be required for*true*  
parallelism. On a single processor any tasks running at the same time is just 
an illusion, normally created by the OS in time slicing between tasks based on 
certain criteria (priority, I/O, cpu usage etc.). That applies equally to 
threads or processes
I think that what are referring to here is not so much *true* 
parallelism but that when parallelism is designed into an application, 
it enables real time parallel computing when the application is deployed.


For example, this distinction is very important in matrix algorithms. 
When operating on two matrices to produce another, the operations on 
each cell can be identified as n x m parallel actions at design time. At 
deployment time, it is often desirable to have a scalable implementation 
that can use anything from 1 to n x m processors to do the job. Thus you 
can have a design that identifies parallelism leading to an 
implementation that can non-parallel, partly or wholly parallel (in real 
time) depending on the size of the matrices and the number of processors 
available.


At what point does this become *true* parallelism?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Threading vs Parallelism ?

[Tony Whyman]

The problem I have with this thread (no pun intended) is that it is not 
comparing like with like. As demonstrated by many of the replies, 
Parallelism and Threads are not the same thing.


I would offer the following definitions:

- Parallelism is a (design) concept for expressing collateral actions in 
which the processing order of the actions is unspecified. They may take 
place serially or contemporaneously in real time, or a mixture of the two.


- Threads are an implementation mechanism for realising collateral 
actions within a single processing environment.


Neither of the above implies multiple CPUs or processing units.


On 31/03/17 07:43, Ryan Joseph wrote:

On Mar 30, 2017, at 3:06 PM, Michael Schnell  wrote:


Huh, ok, but why parallelism is better and how to do it with fpc ?


Parallelism within a process always is based on threads.

AFAIK, fpc does not (yet) provide a more convenient abstraction for parallelism 
(such as parallel loops) than TThread.

-Michael

It’s my understanding that for parallelism to make sense you need to have at 
least more than 1 separate compute unit, be that a CPU core or a GPU.

If you had a GPU with 250 compute units or a CPU with 250 cores you would need 
to design your task in a way so that it could be broken down into as many 
discrete portions as possible so that you could take advantage of the multiple 
cores running in parallel. Even if you didn’t have a single thread and the 
execution blocked until finished you wouldn’t see any performance increases 
unless you designed your program to scale for parallelism. Running 250 threads 
on a single core isn’t going to be 250x faster but running 250 threads on 250 
cores may be.


Regards,
Ryan Joseph

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



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

Re: [fpc-pascal] https how does it work

[Tony Whyman]

Thanks. It's good to know this. Perhaps the Indy site at 
http://www.indyproject.org should be updated to reflect this. You have 
to dig very deep to find the links to the svn (and labelled as a 
development snapshot). The last source code package appears to be the 
2004 release 10.0.52. With the site copyright being 1993 - 2008 it does 
look rather moribund.



On 13/03/17 07:20, Bo Berglund wrote:

On Thu, 16 Feb 2017 14:18:28 +, Tony Whyman
<tony.why...@mccallumwhyman.com> wrote:


The downside is that the indy components do not seem to have been
updated for a long time and have not kept up-to-date with OpenSSL. I
have attached below a patch I have used to keep the components
up-to-date with SSL headers.

The Indy project is hosted on Fulgan here:
https://indy.fulgan.com/
You can find current versions of both SSL and Indy here.

It is easy to get using svn too:
svn co https://svn.atozed.com:444/svn/Indy10/trunk/Lib/ indy10

If you want to use one of the tagged versions then you face the caveat
concerning the svn tags that they contain spaces so you have to
replace these with %20 when you construct the svn command for
downloading a tag thus:
https://svn.atozed.com:444/svn/Indy10/tags/Indy%2010.6.2%20-%20XE8%20RTM/Lib/


Current version is 10.6.2 and it includes a lazarus package as well.
It is in constant development so no need to complain about not being
up-to-date! Last activity was 2017-03-08

You can browse the svn store by using your browser:
https://svn.atozed.com:444/svn/Indy10/

Go there and browse the versions for yourself.
Username is : Indy-Public-RO
No password needed for read-only access.

Lazarus package is: Lib/indylaz.lpk




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

Re: [fpc-pascal] https how does it work

[Tony Whyman]

You can always use the indy components. They have a working https 
implementation which I have successfully used in a SOAP based 
application and Lazarus's WST package. (see 
http://wiki.lazarus.freepascal.org/Indy_with_Lazarus).


The downside is that the indy components do not seem to have been 
updated for a long time and have not kept up-to-date with OpenSSL. I 
have attached below a patch I have used to keep the components 
up-to-date with SSL headers.


Tony



On 16/02/17 12:41, Rainer Stratmann wrote:

How does httpy work, what is needed?

TLS/SSL library?

A http webserver without encryption I programed already on my own and wanted
to integrate https.

Is there any example code of https?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Index: fpc/IdSSLOpenSSLHeaders.pas
===
--- fpc/IdSSLOpenSSLHeaders.pas(.../tags/R10-2-0-3)(revision 8065)
+++ fpc/IdSSLOpenSSLHeaders.pas(.../trunk)(revision 8065)
@@ -7073,7 +7076,8 @@
   where the symbolic link libbsl.so and libcrypto.so do not exist}
   SSL_DLL_name = 'libssl'; {Do not localize}
   SSLCLIB_DLL_name = 'libcrypto'; {Do not localize}
-  SSLDLLVers : array [0..4] of string = 
('','0.9.9','.0.9.8','.0.9.7','0.9.6');
+  SSLDLLVers : array [0..6] of string = 
('','1.0.1','1.0.0','0.9.9','.0.9.8','.0.9.7','0.9.6');
+//  SSLDLLVers : array [0..3] of string = 
('0.9.9','.0.9.8','.0.9.7','0.9.6');

   {$ENDIF}
   {$IFDEF WIN32_OR_WIN64_OR_WINCE}
   SSL_DLL_name   = 'ssleay32.dll';  {Do not localize}
@@ -9479,9 +9485,9 @@
   @IdSslWrite := LoadFunction(fn_SSL_write);
   @IdSslCtxCtrl := LoadFunction(fn_SSL_CTX_ctrl);
   @IdSslGetError := LoadFunction(fn_SSL_get_error);
-  @IdSslMethodV2 := LoadFunction(fn_SSLv2_method);
-  @IdSslMethodServerV2 := LoadFunction(fn_SSLv2_server_method);
-  @IdSslMethodClientV2 := LoadFunction(fn_SSLv2_client_method);
+//  @IdSslMethodV2 := LoadFunction(fn_SSLv2_method);
+//  @IdSslMethodServerV2 := LoadFunction(fn_SSLv2_server_method);
+//  @IdSslMethodClientV2 := LoadFunction(fn_SSLv2_client_method);
   @IdSslMethodV3 := LoadFunction(fn_SSLv3_method);
   @IdSslMethodServerV3 := LoadFunction(fn_SSLv3_server_method);
   @IdSslMethodClientV3 := LoadFunction(fn_SSLv3_client_method);

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

Re: [fpc-pascal] Readln a password

[Tony Whyman]

On 27/11/16 17:07, Michael Van Canneyt wrote:

If you mean in a cross-platform way, I think we would welcome patches :)

Michael.


Today, I also came up against the problem of how to read a password from 
the console without echo. With a bit of googling and code bashing, I 
have created the following cross-platform code from a "getpassword" 
function.


uses ...
{$IFDEF WINDOWS} ,Windows {$ENDIF}
{$IFDEF UNIX} ,TermIO, IOStream {$ENDIF}
;

...
{$IFDEF UNIX}
function getpassword: string;
var oldattr, newattr: termios;
stdinStream: TIOStream;
c: char;
begin
  Result := '';
  stdinStream := TIOStream.Create(iosInput);
  try
TCGetAttr(stdinStream.Handle, oldattr);
newattr := oldattr;
newattr.c_lflag := newattr.c_lflag and not (ICANON or ECHO);
tcsetattr( stdinStream.Handle, TCSANOW, newattr );
try
  repeat
read(c);
if c = #10  then break;
write('*');
Result += c;
  until false;
  writeln;
finally
  tcsetattr( stdinStream.Handle, TCSANOW, oldattr );
end;
  finally
stdinStream.Free;
  end;
end;
{$ENDIF}
{$IFDEF WINDOWS}
function getpassword: string;
var oldmode, newmode: DWORD;
c: char;
begin
  Result := '';
  GetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), oldmode);
  newmode := oldmode - ENABLE_ECHO_INPUT - ENABLE_LINE_INPUT;
  SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE),newmode);
  try
repeat
  read(c);
  if c = #13 then break;
  write('*');
  Result += c;
until false;
writeln;
  finally
SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE),oldmode);
  end
end;
{$ENDIF}

Seems to work for me.

Tony





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

[fpc-pascal] Error: Internal error 2014052302

[Tony Whyman]

Any ideas as to what this means?

Seen on FPC 3.0.0 under AMD64 Linux Mint 17

The odd thing about this one is that :

a) Always on the same blank line just after a constructor

b) Goes away when you recompile clean

c) Seems to be fixed by just moving the constructor to the end of the unit.

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

Re: [fpc-pascal] Interface performance

[Tony Whyman]

  Isn’t MyObject2 still pointing to MyObject1?
If you go back to the FPC documentation, in the User Guide it says 
"Objects are stored in memory just as ordinary records with an extra 
field: a pointer to the Virtual Method Table (VMT)." My understanding is 
that an interface is stored similarly, except that a different VMT is 
used i.e. that which defines the interface. If you try and assign one to 
the other by just coercing the type then you will get undefined results.



On 11/11/16 11:25, Ryan Joseph wrote:

On Nov 11, 2016, at 5:52 PM, Tony Whyman <tony.why...@mccallumwhyman.com> wrote:

Someone else may correct me, but with CORBA, I believe you have to explicitly 
add a function to the interface such as

function GetObject: TMyObject;

and implement as

function TMyObject.GetObject: TMyObject;
begin
  Result := self;
end;

I think I’m out of time now but I’ll try this in my code that was crashing 
before.

How is this different from just casting the interface to an object? There’s 
your example below basically like I was doing it before with the seemingly 
random crashes. Isn’t MyObject2 still pointing to MyObject1?

type
IMyInterface = interface
procedure MyProc;
end;

TMyObjectClass = class(TInterfacedObject,IMyInterface)
public
   procedure MyProc;
end;

var MyObject1, MyObject2: TMyObjectClass;
  MyInterface: IMyInterface;

begin
  MyObject1 := TMyObjectClass.Create;
  MyInterface := MyObject1;

  MyInterface.MyProc;

  MyObject2 := TMyObjectClass(MyInterface);

  MyObject1.Free {OK for CORBA - will cause an exception in COM}
  {MyObject1, MyObject2 and MyInterface are now all invalid}
end;


Regards,
Ryan Joseph

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



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

Re: [fpc-pascal] Interface performance

[Tony Whyman]

On 11/11/16 10:59, Ryan Joseph wrote:

What does memory management even mean for interfaces? I never allocate an 
interface I just implement it in a class so what’s there to be freed? All these 
crashes I’m getting suggest memory is being trashed by the compiler at some 
point without my knowledge. I never explicitly allocate an interface like an 
object so there’s nothing to manage in my mind.
May be that the best way to understand an interface is to think of it as 
a pointer to a class's VMT (or at least a VMT derived from the class's 
VMT) plus a reference to the object 'self'). When you call a method that 
belongs to an interface, the underlying code simply performs a VMT 
lookup and calls the method at the selected table location and provides 
the 'self' reference to the method. The result is then no different to a 
normal method call.


Interfaces do exist independent of objects. They depend on underlying 
object instances for their implementation.


An interface continues to work as long as the 'self' reference is valid. 
Once the underlying object is freed then the 'self'' reference becomes 
invalid and the interface no longer works.


With CORBA, you are responsible for creating and freeing the object 
instances providing an interface. Under COM, you are still responsible 
for creating the objects. They are automatically freed when the 
interface (and any copies) go out of scope.

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

Re: [fpc-pascal] Interface performance

[Tony Whyman]

On 11/11/16 10:08, Ryan Joseph wrote:

I’m trying your code example now and I get "Class or COM interface type 
expected, but got “IMyInterface”” when I try to cast with “as”. I was using 
{$interfaces corba} so maybe that’s the problem?

Ooops, as you may guess, I typically work with COM interfaces.

Someone else may correct me, but with CORBA, I believe you have to 
explicitly add a function to the interface such as


function GetObject: TMyObject;

and implement as

function TMyObject.GetObject: TMyObject;
begin
  Result := self;
end;

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

Re: [fpc-pascal] Interface performance

[Tony Whyman]

On 11/11/16 10:25, Ryan Joseph wrote:

On Nov 11, 2016, at 4:56 PM, Tony Whyman <tony.why...@mccallumwhyman.com> wrote:

3. To get an object back from an interface you must use the "as" operator.

Another point to do with CORBA. The manual says they are not reference counted 
and programmer needs to do book keeping. The crash I was getting was in line 
with accessing memory that has been deallocated so perhaps because I didn’t do 
my “book keeping” it was freed as it passed scopes. Not sure how to manage 
reference counting for interfaces though because the docs didn’t actually 
explain this.

Maybe the better question is should I ditch CORBA in favor or COM?


Regards,
Ryan Joseph

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


If last question doesn't send the list into overdrive then nothing will;)

With CORBA you are responsible for freeing the objects that provide an 
interface in the same way that you are always responsible for freeing 
the objects that you create. If you free an object before you finish 
using it then it's a bug and using interfaces does not change that.


With COM, once you assign the object providing the interface to a 
variable with an interface type then you are no longer responsible for 
freeing the object. The object is now managed by the system and if you 
do free it then you get an exception. It's really the same principle as 
AnsiStrings and dynamic arrays, which are also reference counted objects.


The classic newbie problem with COM comes when you have an interface 
with a method that returns another interface. If the underlying objects 
"know" about each other and reference each other's data then the order 
in which they are freed becomes important and automatic reference 
counting does not always give the right answer. There are design 
techniques to manage this, such as objects keeping interface references 
to other objects - but then you have to be careful to avoid circular 
references that prevent the objects ever being released.


I would start working with interfaces by using CORBA. It's more obvious 
what is going on and fewer traps for the unwary. However, if you are 
designing a standard package providing an API realised as a Pascal 
Interface then I would argue that a properly designed COM based 
interface is easier for the API user, in the same way that AnsiStrings 
just "work".

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

Re: [fpc-pascal] Interface performance

[Tony Whyman]

On 11/11/16 09:46, Ryan Joseph wrote:

I just don’t plain get it. The examples given seem to be a redundant property 
that could be replaced with a reference the interface itself.
Interface delegation is really just an optimisation and is equivalent to 
defining a set of methods to support the interface and each one then 
calls the same method in the "delegated" interface. IMHO, extending the 
definition of a property for this optimisation isn't exactly intuitive.


Delegated interfaces cause even more problems with reference counted COM 
interfaces. Unless you are really confident in your use of interfaces - 
just don't go there.

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

Re: [fpc-pascal] Interface performance

[Tony Whyman]

On 11/11/16 09:46, Ryan Joseph wrote:

Just as I got this message I’m running into some inexplicable memory related 
crashes casting from interfaces to objects and calling methods.  Are you sure 
you can just cast these around like that? The compiler seems to get confused 
and lose track of what the type actually is. In my first test this didn’t 
happen and I was able to use an interface as a type then cast it to an object, 
pass to a function and call a method. In the 2nd example the variable went from 
a couple classes first and died at the end. Seems very unstable.
You will probably need to post some examples to get more help. But here 
are some simple rules:


1. Classes that provide interfaces in most cases will have 
TInterfacedObject as their ancestor.


2. If you have an object with a class definition that explicitly 
supports a given interface then to get an interface reference all you 
need to do is to assign it to a variable of the interface type.


3. To get an object back from an interface you must use the "as" operator.

e.g.

type
 IMyInterface = interface
procedure MyProc;
 end;

 TMyObjectClass = class(TInterfacedObject,IMyInterface)
 public
   procedure MyProc;
 end;

var MyObject1, MyObject2: TMyObjectClass;
  MyInterface: IMyInterface;

begin
  MyObject1 := TMyObjectClass.Create;
  MyInterface := MyObject1;

  MyInterface.MyProc;

  MyObject2 := MyInterface as TMyObjectClass;

  MyObject1.Free {OK for CORBA - will cause an exception in COM}
  {MyObject1, MyObject2 and MyInterface are now all invalid}
end;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface performance

[Tony Whyman]

Ryan,

You'll find a couple threads earlier this year in heated debate about 
interface delegation and how it is implemented. My conclusion was to 
avoid interface delegation - there are just too many traps for the unwary.


There is also another thread bemoaning some odd features about the 
"supports" function.


In use, once you have a variable containing a reference to an interface, 
it behaves, for the most part, the same as a reference to an object 
supporting the same methods and properties and should be used as such.


Tony Whyman

MWA


On 11/11/16 08:25, Ryan Joseph wrote:

I did some experimenting this morning and found out I could pass references to 
the interface and call methods directly without using Supports and incurring 
the string compare penalty. There’s also interface delegation I read about and 
using “implements” keyword but I couldn’t understand what the purpose of this 
is and why it’s even useful.


On Nov 10, 2016, at 6:45 PM, Ryan Joseph <r...@thealchemistguild.com> wrote:

Some times when I want to communicate with a class I don’t have full scope 
access to I’ll use interfaces and the Supports function to call a method. I’ve 
noticed however that the string compare function that it is used to find the 
interface in the class is very slow and makes them not useable for high 
performance situations. Is there a better way to do this or should I not use 
interfaces like this in FPC?

Regards,
Ryan Joseph

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



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

Re: [fpc-pascal] Implicit conversion problem with TDate type

[Tony Whyman]

On 02/11/16 11:29, Jonas Maebe wrote:

On 02/11/16 12:09, Tony Whyman wrote:

It's an interesting concept i.e. if a bug exists in Delphi then it must
also exist in FPC. Perhaps a better alternative is to fix these sort of
bugs in FPC and  to introduce a "full Dephi compatibility mode" i.e.
mode Delphi plus the bugs.


There is a difference between having a code construct that can be 
compiled in one mode and not in another, and code that has different 
behaviour in different modes. The former can be easily recognised, the 
latter is much harder. In particular, it complicates reading code, 
because you constantly have to be aware of the mode to know what the 
code means. The same goes for changing behaviour across compiler 
versions, and we have to do this way more often than I like.
There was a certain amount of sarcasm in my comment that perhaps got 
lost in translation. I suggested introducing a "delphi with bugs" mode 
to illustrate the absurdity of the idea. My point is that why should FPC 
still feel constrained by Delphi? Let's get on and fix the bugs/features 
that Delphi should have fixed long ago.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implicit conversion problem with TDate type

[Tony Whyman]

It's an interesting concept i.e. if a bug exists in Delphi then it must 
also exist in FPC. Perhaps a better alternative is to fix these sort of 
bugs in FPC and  to introduce a "full Dephi compatibility mode" i.e. 
mode Delphi plus the bugs.



On 02/11/16 11:04, Gabor Boros wrote:

2016. 11. 02. 11:38 keltezéssel, Michael Van Canneyt írta:

If Delphi prints another result, then we can look at fixing the
implementation.


With Delphi 10.1 and "D: TDate;" the result is "date is 5" and with 
"D: TDateTime;" the result is "date is 7". So, the results are same 
with FPC and Delphi.


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



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

Re: [fpc-pascal] inherited interfaces not seen by queryinterface / supports

[Tony Whyman]

On 27/10/16 03:47, Graeme Geldenhuys wrote:

A common misconception about how interfaces work. In fact, I don't
actually know why FPC and Delphi bother with Interface Inheritance,
because I simply don't see the point.
To make your "t_2" class support both interface, you need to specify
both in the class declaration. Even though i_2 inherits from i_1, both
i_1 and i_2 must be specified in the t_2 class.


I must be missing something here because interface inheritance seems to 
work fine for me e.g.


i1 = interface
 procedure Do1;
end;

i2 = interface(i1)
 procedure Do2;
end;

TMyObject = class(TInterfacedObject,i2)
public
  procedure Do1;
  procedure Do2;
end;

var intf: i2;
begin
  i2 := TMyObject.Create;
  i2.Do1; {seems to work for me}
End;

I have plenty of examples where an interface is inherited and includes 
the inherited methods and properties.


I also have cases where e.g.

var SomeInterface: IUnknown;
begin
   SomeInterface := TMyObject.Create;
end;

that is the inherited interface is extracted from the object. There are 
also useful cases, where e.g.


TMyObject1 = class(TInterfacedObject,i1)
public
  procedure Do1;
end;

TMyObject2 = class(TMyObject1,i2)
public
  procedure Do2;
end;

That is you can build an object hierarchy to parallel an interface 
hierarchy.


I don't use the "Supports" primitive. - so maybe there is a bug in this 
feature but otherwise, what is the problem with interface inheritance?


Tony Whyman
MWA
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] what is the possible cause of EPrivilege Privileged instruction ?

[Tony Whyman]

A couple of ideas (no more than this)

1. A corrupt stack has resulted in a function return address being 
corrupted and the program jumps to an illegal instruction.


2. Executing data (shouldn't really happen).

3. Corrupt VMT sgain resulting in the program jumping to an illegal 
instruction.


The problem with these type of bugs is that cause and effect can be some 
way apart. I tend to debug multi-threaded programs that are mis-behaving 
by having lots of writeln statements and then looking at the output log 
to see which patterns of behaviour lead to the problem. Can be an art 
rather than a science.



On 26/10/16 16:57, Dennis wrote:
I have a multi threaded program which executes a list of tasks in real 
time.
It is difficult to debug with a debugger on this program (since 
debugging will pause the execution which will be messy for this 
application).


So, I log the exceptions to a log file and I found this exception:
EPrivilegePrivileged instruction

What could possibly raise this exception?

My program is win 32 from Lazarus 1.7  FPC 3.1.1
and running on Win 7 64 bit.

thanks in advance.

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


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

Re: [fpc-pascal] The Next Release

[Tony Whyman]

Of course, fpc might skip version 4 altogether. There is precedent. 
Winamp skipped version 4 with some lame excuse about not wanting to 
market  "Winamp 4" skins ;-)



On 13/10/16 10:56, Graeme Geldenhuys wrote:

On 2016-10-13 09:58, Bart wrote:

The danger in that is that he might get so excited by the prospect of
seeing a 4.0 version of fpc, that he may die of cardiac arrest in the
process.

Thankfully FPC comes with the following disclaimer.  :-p

“
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
”

Regards,
   Graeme

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



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

[fpc-pascal] The Next Release

[Tony Whyman]

What's the timetable for the next release? Can we assume that all of 
"trunk" will be in it or will it be more nuanced?


Tony Whyman

MWA

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

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

On 07/10/16 12:29, stdreamer wrote:
No! Delegation is a mechanism, when used, you have to know exactly how 
it works. Delegation is only used to minimize code instead of writing 
a bunch of procedures that call the contained object's methods. That's 
it and nothing more.


I believe that I now understand the issues around interface delegation 
and how to use it. You are correct, it's only an optimisation - and it 
sucks. I would never recommend anyone to use interface delegation as you 
have to only put a "foot wrong" and can end up memory leaks on one side, 
or access violations on the other. Writing a "bunch of procedures" may 
be tedious but it's less work in the end.

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

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

On 07/10/16 12:29, stdreamer wrote:
The point is that you are trying to equate delegation with contained 
objects/interfaces and that is not what delegates are about. 
Delegation has nothing to do with the underlined mechanism you choose 
to use. 


Hmm, not so sure about that. I have updated my original example from 
August to use TContainedObject (see below). As a workaround for the 
interface delegation problem it works, as long as you don't try and use 
TDelegateClass on its own. This is because although it appears as a 
reference counted com interface, it still relies upon another object to 
free it. The example returns:


Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TMyClass
Destroying TDelegateClass

i.e. there is a missing call to the TDelegateClass destructor. This is 
because I created it standalone (in "DoRun) just to illustrate the point.


There is a real need to update the FPC manual to include 
TContainedObject. It's importance for interface delegation and its 
limitations. How you implement interface delegation clearly has a big 
outcome on how the interface is used by the user.


program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils, CustApp
  { you can add units after this };

type

  { TDelegateTest }

  TDelegateTest = class(TCustomApplication)
  protected
procedure DoRun; override;
  public
constructor Create(TheOwner: TComponent); override;
destructor Destroy; override;
procedure WriteHelp; virtual;
  end;

  IMyInterface = interface
 procedure P1;
   end;

  { TDelegateClass }

   TDelegateClass = class(TContainedObject, IMyInterface)
   private
 procedure P1;
   public
 constructor Create(aController: IUnknown);
 destructor Destroy; override;
   end;

   { TMyClass }

   TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: TDelegateClass;
 property MyInterface: TDelegateClass
   read FMyInterface implements IMyInterface;
   public
 constructor Create;
 destructor Destroy; override;
   end;

{ TDelegateClass }

procedure TDelegateClass.P1;
begin
  writeln('P1');
end;

constructor TDelegateClass.Create(aController: IUnknown);
begin
  inherited Create(aController);
  writeln('Creating ',ClassName);
end;

destructor TDelegateClass.Destroy;
begin
  writeln('Destroying ',ClassName);
  inherited Destroy;
end;

{ TMyClass }

constructor TMyClass.Create;
begin
  inherited Create;
  FMyInterface := TDelegateClass.Create(self);
  writeln('Creating ',ClassName);
end;

destructor TMyClass.Destroy;
begin
  writeln('Destroying ',ClassName);
  if FMyInterface <> nil then FMyInterface.Free;
  inherited Destroy;
end;

{ TDelegateTest }

procedure TDelegateTest.DoRun;
var Intf: IUnknown;
Intf2: IMyInterface;
begin
   Intf := TMyClass.Create;
   Intf2 := TDelegateClass.Create(Intf); {never destroyed}
  // stop program loop
  Terminate;
end;

constructor TDelegateTest.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
  StopOnException := True;
end;

destructor TDelegateTest.Destroy;
begin
  inherited Destroy;
end;

procedure TDelegateTest.WriteHelp;
begin
  { add your help code here }
  writeln('Usage: ', ExeName, ' -h');
end;

var
  Application: TDelegateTest;
begin
  Application := TDelegateTest.Create(nil);
  Application.Title := 'Interface Delegation Test';
  Application.Run;
  Application.Free;
end.

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

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

On 07/10/16 11:08, stdreamer wrote:
I see no rabbit hole or any other problem in the code posted so far 
except perhaps lack of proper clean up which might be intentional. 
A Rabbit Hole is not the same as a bug and my point is not that 
"interface delegation" does not work, it is that it is counter-intuitive 
and poorly documented to the point of undocumented. Your introduction of 
TContainedObject is just another example of missing information.


Reference Counted interfaces must be easy to use and should not require 
the user to have advanced knowledge of how they work. If that last point 
is true then all the that nay-sayers that argue against reference 
counted interfaces have their point made for them.


A Rabbit Hole comes from Alice in Wonderland and when you fall down it 
you are not just chasing a White Rabbit, you have found yourself in 
another universe that has a different logic to your own. Reference 
counting with Interface Delegation seems to have a different logic to 
that of normal reference counted interfaces - and that is why you feel 
that you have fallen down a Rabbit Hole as soon as you start trying to 
use them.


“But I don’t want to go among mad people," Alice remarked.
"Oh, you can’t help that," said the Cat: "we’re all mad here. I’m mad. 
You’re mad."

"How do you know I’m mad?" said Alice.
"You must be," said the Cat, "or you wouldn’t have come here.”
― Lewis Carroll, Alice in Wonderland
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

You seem to be playing around with words. Perhaps I am guilty of sloppy 
English when I say "interface is copied" when meaning "an interface 
reference is copied". However, this does not change the underlying problem.


The problem being referred to is the functionality described here:

http://freepascal.org/docs-html/current/ref/refse44.html#x98-127.4

under the title "Interface delegation". The word "contained" does not 
appear here. Maybe it should, but it doesn't. If TContainedObject does 
indeed solve the problem then it would be useful to have it documented 
and, if so, for interface delegation using a TInterfacedObject subclass 
to be at least deprecated and may be even barred.


The problem is that this is Rabbit Hole and it needs filling in 
otherwise more will fall down it.



On 07/10/16 10:31, stdreamer wrote:

On 05/10/2016 19:13 μμ, Tony Whyman wrote:

Marcos,

I believe I concluded that this could be a bug or feature. Either way it
is a Bear Trap waiting for the unwary programmer and it would be nice if
in some way the implementation could be improved. The problem, as I see
it is:

Basics:

1. Whenever an interface reference is coerced from an interfaced object,
the object's reference count is incremented.
I'm guessing that by "coerced" you mean "reference a contained 
interface".


2. When the interface is copied that reference count is again 
incremented.
Interface can not be copied only implement objects can be copied and 
when they are their interface counter has nothing to do with the 
original interface, in fact it is the exact opposite, after a copy you 
need to make sure that the counter has been reset, which leads to 
believe that I misunderstood something.



3. When the interface goes out of scope, the reference count is
decremented and when it reaches zero, the object is freed.

So far so good, but, when you have a delegated interface:

Terminalogy: In the example:

 TMyValue = class(TInterfacedObject,IValue);

 TMyObject = class (TinterfacedObject,IMyInterface)
 ...
 property Value: IValue read FValue implements IValue;
 end;

 Then a TMyValue object "is the source of" the delegated interface.
 A TMyObject object "provides" the delegated interface.


That is not a delegated interface that is a contained interface.

A delegated interface goes something like this

  IValue = interface
  ['{72D8B44F-5834-425D-AB3A-45785E94E2E4}']
function AsString:string;
  end;

  IMyInterface = interface
   ['{5E04F587-E4A0-42A7-850C-74C882BB5958}']
   procedure DoSomething;
  end;

  //tmyvalue can inherit from tContainedobject
  //for simplification.
  TMyValue = class(TInterfacedObject, IValue)
function AsString:String;
  end;
  //IValue must be part of TMyObject not a simple property.
  TMyObject = class(TInterfacedObject, IMyInterface, IValue)
  private
property MyValue :TMyValue implements IValue;
  end;

Τhe problem of a contained interface has already been solved, see the 
TContainedObject. To sum it up a contained object reference counting 
mechanism increments and decrements the container's reference counter 
it does not have a life of its own.


Sorry the rest look like a rabbit hole based on the wrong assumptions 
to me, there might be some merit but I have no will to search for it.



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



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

Re: [fpc-pascal] fcl-db + IPv6 + Firebird

[Tony Whyman]

On 07/10/16 09:43, Graeme Geldenhuys wrote:

1. Does fcl-db code support connecting to databases (any DB servers)
  listening to IPv6 connections?

   2. Does anybody know how to tell Firebird RDBMS to listen to IPv6
 connections? From the 'netstat -a' output I can see that
 my Firebird server is only listening to IPv4 tcp connections.
With Firebird this should have nothing to do with the fcl-db and 
everything to do with the Firebird Client library DLL or ".so". You will 
need Firebird 3 for IPv6 and my understanding is that this uses IPv6 by 
default with fallback to IPv4. That is the server will normally listen 
on an IPv6 socket but accept IPv4 incoming. The client initiated 
connection uses IPv6 or IPv4 depending on the database path name. The 
release notes have more info.


Tony Whyman
MWA
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

On 06/10/16 11:08, Graeme Geldenhuys wrote:

I've seem some
COM Interface code where they had to resort to using raw Pointer types
etc to try and avoid reference counting and causing unexpected memory
leaks.
I have also seen plenty of examples of poor coding with classes, but the 
fact that someone writes bad object oriented programs doesn't mean that 
object oriented is a poor programming technique. Likewise, poor 
programming using com interfaces doesn't invalidate the use of com 
interfaces.


When you work with interfaces, there are two issues to consider:

1. How easy is the interface to use
2. How do you write the underlying classes.

To me, the first rules out delegated interfaces and COM. Even advanced 
level programmers will get it wrong and you will never get an easy to 
use interface with this combination. It looks like a design error that 
came from Delphi and was copied by FPC. However, if you rule out this 
combination, COM does make for what seems to be a very intuitive easy to 
use interface, in the same way that AnsiStrings are easy to use.


On the other hand, implementing the classes that provide a com interface 
does require some skill and is not for everyone.

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

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

On 05/10/16 23:03, Graeme Geldenhuys wrote:

Martin Schreiber recently mentioned in another Interface discussion that
there is a very good reason he doesn’t use COM style interfaces…
Reference Counting!
Used properly reference counted interfaces are very powerful and allow 
for some very elegant programming. Do you complain about AnsiStrings? 
They are reference counted. Would you really want to have to free every 
string explicitly? Dynamic arrays are similarly reference counted.


Reference counted interfaces allow you to create classes (and objects) 
that behave in the same way as AnsiStrings. IMHO, a lot of standard 
packages would be greatly improved if they used com interfaces.

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

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

On 05/10/16 19:19, Marcos Douglas wrote:

Hi Tony,

On Wed, Oct 5, 2016 at 1:13 PM, Tony Whyman
<tony.why...@mccallumwhyman.com> wrote:

[...]

7. You are responsible for freeing the object that "provides" the delegated
interface.

But I'm working only using Interfaces. All variables are interfaces type.
So, I can't free the object myself.
As I understand it, it depends on the variable to which the object is 
first assigned. For example:


TMyClass = class(TInterfacedObject,IUnknown);

var Obj: TMyClass; {Note the var is of type TMyClass}
begin
  Obj := TMyClass.Create;
  try
   ...
  finally
Obj.Free; {This is OK and necessary}
  end
end;

Alternatively:

var Obj: IUnknown;
begin
  Obj := TMyClass.Create;
  try
   ...
  finally
Obj.Free; {Not required and will cause an exception when obj goes 
out of scope}

  end
end;


Where do we go from here?
==

Provided you understand what is happening then it works - but there is no
real documentation and it is really easy to get this wrong.

I disagree.
Well, works, but with memleaks... so, I can't have a real program on
the server with memleaks.
No, if you explicitly free the provider class there will be no memleaks. 
My point is that having to do this is counter-intuitive and  easy to get 
wrong - or to overlook cases where it is necessary.



For me the consistent approach should be that when you coerce an interface
from an object, the reference count of the object that "provides" the
delegated interface is always the one that is incremented and the interface
remains tied to that object  An object that "is the source of" a delegated
interface should always have its lifetime tied to that of the object that
"provides" the delegated interface. i.e. it has an implicit reference to the
object that is the source of the interface.

I understood you but I can't help, because I don't know how the
compiler works to do this 'kind of magic' — I think only Object Pascal
has delegation in that way, right?

Here I was suggesting a compiler change (bug fix?)


Delegates is a powerful feature. I can write less and compose complexy
objects using delegation. Really cool.

We need to compare with Delphi?
I don't have it, but I guess this problem there isn't there.
I never used delegated interfaces in Delphi. In FPC I try to avoid them 
given the problems you get. On the other hand, reference counted com 
interfaces are a great feature and it's a pity delegated interfaces are 
so awkward.


What do you think?

Best regards,
Marcos Douglas

On Wed, Oct 5, 2016 at 1:13 PM, Tony Whyman
<tony.why...@mccallumwhyman.com> wrote:

On 05/10/16 16:26, Marcos Douglas wrote:

Tony Whyman had posted on August 10 a problem with the compiler using
Delegates.
He used a workaround to "solve" his problem and the thread died.


Marcos,

I believe I concluded that this could be a bug or feature. Either way it is
a Bear Trap waiting for the unwary programmer and it would be nice if in
some way the implementation could be improved. The problem, as I see it is:

Basics:

1. Whenever an interface reference is coerced from an interfaced object, the
object's reference count is incremented.

2. When the interface is copied that reference count is again incremented.

3. When the interface goes out of scope, the reference count is decremented
and when it reaches zero, the object is freed.

So far so good, but, when you have a delegated interface:

Terminalogy: In the example:

 TMyValue = class(TInterfacedObject,IValue);

 TMyObject = class (TinterfacedObject,IMyInterface)
 ...
 property Value: IValue read FValue implements IValue;
 end;

 Then a TMyValue object "is the source of" the delegated interface.
 A TMyObject object "provides" the delegated interface.

4. Whenever an interface reference to a delegated interfaced is coerced from
an interfaced object, it is the reference count of the object that "is the
source of" the delegated interface that is incremented.

5. When the interface is copied the reference count of the object that "is
the source of" the delegated interface is incremented.

6. When the interface goes out of scope, the reference count of the object
that "is the source of" the delegated interface is decremented and when it
reaches zero, that object is freed.

7. You are responsible for freeing the object that "provides" the delegated
interface.

To me this is counter-intuitive behaviour and this counter-intuitiveness is
compounded by the case where:

a. An interfaced object provides only a delegated interface.

b. An inherited interface (e.g. IUnknown) is coerced from the object.

In this case, the reference count incremented is that of the object that
"provides" the delegated interface  and not the object that "is the source
of" the delegated interface.

Where do we go from here?
===

Re: [fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Tony Whyman]

On 05/10/16 16:26, Marcos Douglas wrote:
Tony Whyman had posted on August 10 a problem with the compiler using 
Delegates.

He used a workaround to "solve" his problem and the thread died.


Marcos,

I believe I concluded that this could be a bug or feature. Either way it 
is a Bear Trap waiting for the unwary programmer and it would be nice if 
in some way the implementation could be improved. The problem, as I see 
it is:


Basics:

1. Whenever an interface reference is coerced from an interfaced object, 
the object's reference count is incremented.


2. When the interface is copied that reference count is again incremented.

3. When the interface goes out of scope, the reference count is 
decremented and when it reaches zero, the object is freed.


So far so good, but, when you have a delegated interface:

Terminalogy: In the example:

TMyValue = class(TInterfacedObject,IValue);

TMyObject = class (TinterfacedObject,IMyInterface)
...
property Value: IValue read FValue implements IValue;
end;

Then a TMyValue object "is the source of" the delegated interface.
A TMyObject object "provides" the delegated interface.

4. Whenever an interface reference to a delegated interfaced is coerced 
from an interfaced object, it is the reference count of the object that 
"is the source of" the delegated interface that is incremented.


5. When the interface is copied the reference count of the object that 
"is the source of" the delegated interface is incremented.


6. When the interface goes out of scope, the reference count of the 
object that "is the source of" the delegated interface is decremented 
and when it reaches zero, that object is freed.


7. You are responsible for freeing the object that "provides" the 
delegated interface.


To me this is counter-intuitive behaviour and this counter-intuitiveness 
is compounded by the case where:


a. An interfaced object provides only a delegated interface.

b. An inherited interface (e.g. IUnknown) is coerced from the object.

In this case, the reference count incremented is that of the object that 
"provides" the delegated interface  and not the object that "is the 
source of" the delegated interface.


Where do we go from here?
==

Provided you understand what is happening then it works - but there is 
no real documentation and it is really easy to get this wrong.


For me the consistent approach should be that when you coerce an 
interface from an object, the reference count of the object that 
"provides" the delegated interface is always the one that is incremented 
and the interface remains tied to that object  An object that "is the 
source of" a delegated interface should always have its lifetime tied to 
that of the object that "provides" the delegated interface. i.e. it has 
an implicit reference to the object that is the source of the interface.


Tony Whyman
MWA

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

Re: [fpc-pascal] Free Delphi 10.1 Berlin Starter Edition

[Tony Whyman]

On 23/08/16 20:19, geneb wrote:
EULAs have the same value as toilet paper and should be used for the 
same purpose.  I for one, will use Delphi for whatever I like, and if 
Embarcadero has a problem with that, they're invited to kiss my ass. :)


In which case I would suggest that you never release any software 
whether under a licence or not. For example. the GPL has some very 
useful clauses in it, such as:


THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 
APPLICABLE LAW.. WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE 
OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU 
ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.


The EULA exists to protect the rights of the author who may or may not 
be the vendor. This includes the right to demand an income from your 
work, to demand that others do not exploit your work for their own gain, 
and to protect you from the mis-use of your work.


If you don't like a given EULA then don't buy or use the product. But 
the one thing that any software developer must do is to respect the 
whole concept of the EULA


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

Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted

[Tony Whyman]

On 18/08/16 10:53, Graeme Geldenhuys wrote:

I think you are getting confused between TObject and TInterfaceObject
instances, and what is required from both.
No, the problem is that I could not find a way of achieving what I 
wanted to achieve. That is ensuring that an interfaced object that used 
a delegated interface would be reference counted and hence automatically 
destroyed. The derived requirement is that I wanted neither a memory 
leak nor the risk of a double free.


What I eventually discovered is that if an interfaced object is defined as:

  TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: IMyInterface;
 property MyInterface: IMyInterface
   read FMyInterface implements IMyInterface;
   public
 constructor Create(obj: TDelegateClass);
 destructor Destroy; override;
   end;

and then a TMyClass object is assigned to a variable of type 
IMyInterface, the result is that the compiler ignores the TMyClass 
object and references solely the object implementing IMyInterface i.e. 
the TDelegateClass object. Intuitively, I had expected the reference to 
be to the TMyClass Object as that was the one I assigned to the variable.


The result is that neither object gets freed automatically. The TMyClass 
object does not get freed because it was ignored when the interface was 
assigned and the TDelegateClass object was not freed because TMyClass 
still has a reference to it.


On the other hand, if I assign a TMyClass object to a variable of type 
IUnknown (which both TMyClass and TDelegateClass inherit), the compiler 
now takes the interface from TMyClass and references this object. The 
result is that at the end of the program both objects are automatically 
destroyed.


I would certainly argue that this is confusing and counter-intuitive. I 
can be persuaded either way that it is a bug or a feature, but I would 
also argue that the intuitive outcome would be for the compiler to take 
the reference to the TMyClass object in all cases.


Whatever view you take, the resulting behaviour needs to be carefully 
documented as it is inviting memory leaks/double frees.



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

Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted [Solved]

[Tony Whyman]

I think that I have now found why the test program below (originally 
posted a couple of weeks ago) did not work. It seems that when an 
interface is delegated, the compiler may take a reference directly on 
the delegated part of the interface and not to the object doing the 
delegation.


In my original post, the main procedure was:

procedure TDelegateTest.DoRun;
var Intf: IMyInterface;
Intf2: IMyInterface;
begin
   Intf := TMyClass.Create(TDelegateClass.Create);
   Intf2 := TDelegateClass.Create;
...

and the output showed that TMyClass was not being automatically 
destroyed. Changing the local variables declaration to:


procedure TDelegateTest.DoRun;
var Intf: IUnknown;
Intf2: IMyInterface;

results in this output:

Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TMyClass
Destroying TDelegateClass

That is TMyClass is now being automatically destroyed, while the 
TDelegateClass used to delegate the interface is not.


Changing the class definition to:

   TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: IMyInterface; // class type
 property MyInterface: IMyInterface
   read FMyInterface implements IMyInterface;
   public
 constructor Create(obj: TDelegateClass);
 destructor Destroy; override;
   end;

gives the output:

Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TMyClass
Destroying TDelegateClass
Destroying TDelegateClass

which is really what I wanted. On the other hand, if I change the 
procedure header back to:


procedure TDelegateTest.DoRun;
var Intf: IMyInterface;
Intf2: IMyInterface;
begin

the output is now back to:

Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TDelegateClass

It seems that the main problem I had is due to the way the compiler 
chooses which interface to reference count when you get an interface 
from an object that has a delegated interface. If the type of the left 
hand side of the assignment is that of the delegated interface, it 
simply extracts that interface and only references it. On the other 
hand, if it is any other compatible interface type (even IUnknown) then 
the interface reference is to the object on the right hand side of the 
assignment rather than to the delegated object.


This is probably a feature rather than a bug, but is certainly 
confusing. It took me some time to get my head around it. The worst 
thing is that I took the example from the FPC Documentation. The FPC 
documentation on reference counting does not mention how it interacts 
with delegated interfaces. It probably should.


Tony Whyman
MWA


On 10/08/16 13:42, Tony Whyman wrote:
I'm using fpc 3.0.0 and trying to debug a program using COM 
interfaces. While reference counting seems to be working fine, there 
is one exception, that is when an interface is being used by 
delegation. In this case, the object doing the delegation does not 
seem to be reference counted. Is this a bug, a feature, or have I 
missed something?


A simple test program follows. The output is:

Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TDelegateClass
Destroying TDelegateClass

In the example, TMyClass is the interface class doing the delegation 
and while TDelegateClass is being destroyed when it goes out of scope, 
TMyClass is not.


Tony Whyman

MWA

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils, CustApp
  { you can add units after this };

type

  { TDelegateTest }

  TDelegateTest = class(TCustomApplication)
  protected
procedure DoRun; override;
  public
constructor Create(TheOwner: TComponent); override;
destructor Destroy; override;
procedure WriteHelp; virtual;
  end;

  IMyInterface = interface
 procedure P1;
   end;

{ TDelegateClass }

   TDelegateClass = class(TInterfacedObject, IMyInterface)
   private
 procedure P1;
   public
 constructor Create;
 destructor Destroy; override;
   end;

   { TMyClass }

   TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: TDelegateClass; // class type
 property MyInterface: TDelegateClass
   read FMyInterface implements IMyInterface;
   public
 constructor Create(obj: TDelegateClass);
 destructor Destroy; override;
   end;

{ TDelegateClass }

procedure TDelegateClass.P1;
begin
  writeln('P1');
end;

constructor TDelegateClass.Create;
begin
  inherited Create;
  writeln('Creating ',ClassName);
end;

destructor TDelegateClass.Destroy;
begin
  writeln('Destroying ',ClassName);
  inherited Destroy;
end;

{ TMyClass }

constructor TMyClass.Create(obj: TDelegateClass);
begin
  inherited Create;
  FMyInterface := obj;
  writeln('Creating ',ClassName);
end;

destructor TMyClass.Destroy;
begin
  writeln('Destroying ',ClassName);
  inherited Destroy;
end;

{ TDelegateTest }

procedure TDelegateTest.DoRun;
var Intf: IMyInterface

Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted

[Tony Whyman]

Graeme,

You are explicitly freeing MyClass. My point is that with reference 
counted interfaces and in the example I posted, you shouldn't have to 
explicitly free the delegated interface. It should be freed 
automatically as soon as it goes out of scope.


Tony Whyman

MWA

On 10/08/16 16:43, Graeme Geldenhuys wrote:

On 2016-08-10 13:42, Tony Whyman wrote:

In the example, TMyClass is the interface class doing the delegation and
while TDelegateClass is being destroyed when it goes out of scope,
TMyClass is not.

Maybe I'm missing something, but here is a quick example I put together.
Testing with FPC 2.6.4 under FreeBSD and classes are created and freed
as they are supposed to.

Here is the console output:

$ ./test2
Creating TMyClass
Creating TMyInterface
TMyInterface.P1
TMyInterface.P2
Destroying TMyClass
Destroying TMyInterface

And the code for the test project.

===[ test2.pas ]===
program test2;

{$mode objfpc}{$H+}

{ Delegating to an interface-type property }

type
   IMyInterface = interface
 procedure P1;
 procedure P2;
   end;

   TMyInterface = class(TInterfacedObject, IMyInterface)
   private
  procedure P1;
  procedure P2;
   public
 constructor Create;
 destructor Destroy; override;
   end;

   TMyClass = class(TObject, IMyInterface)
 FMyInterface: IMyInterface;
 property MyInterface: IMyInterface read FMyInterface implements
IMyInterface;
   public
 constructor Create;
 destructor Destroy; override;
   end;


procedure TMyInterface.P1;
begin
   writeln('TMyInterface.P1');
end;

procedure TMyInterface.P2;
begin
   writeln('TMyInterface.P2');
end;

constructor TMyInterface.Create;
begin
   writeln('Creating ',ClassName);
end;

destructor TMyInterface.Destroy;
begin
   writeln('Destroying ',ClassName);
   inherited Destroy;
end;



var
   MyClass: TMyClass;
   MyInterface: IMyInterface;

{ TMyClass }

constructor TMyClass.Create;
begin
   writeln('Creating ',ClassName);
end;

destructor TMyClass.Destroy;
begin
   writeln('Destroying ',ClassName);
   inherited Destroy;
end;

begin
   MyClass := TMyClass.Create;
   MyClass.FMyInterface := TMyInterface.Create;  // some object whose
class implements IMyInterface
   MyInterface := MyClass;
   MyInterface.P1;
   MyInterface.P2;
   MyClass.Free;
end.

[ end ]

Regards,
   Graeme



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

Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted

[Tony Whyman]

On 10/08/16 15:05, Marco van de Voort wrote:

The way how Tony passes owner is wrong and that messes up reference
counting.

If in the test he would do  TMyclass.Create(Tsomeclass.create); it probably
would be ok.


But in my test, the code reads:

   Intf := TMyClass.Create(TDelegateClass.Create);

So, why didn't this work?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted

[Tony Whyman]

On 10/08/16 13:57, Marcos Douglas wrote:

Hi,

See the "problem" bellow:

TMyClass = class(TInterfacedObject, IMyInterface)
private
  FMyInterface: TDelegateClass; <<< HERE >>>
  property MyInterface: TDelegateClass
read FMyInterface implements IMyInterface;
public
  constructor Create(obj: TDelegateClass);
  destructor Destroy; override;
end;

and...

Just trying some further variations:

with

  TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: IMyInterface; // class type
 property MyInterface: IMyInterface
   read FMyInterface implements IMyInterface;
   public
 constructor Create(obj: TDelegateClass);
 destructor Destroy; override;
   end;

the output is:

Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TDelegateClass

so it is actually worse with both interfaces left dangling

You get the same result with:

   TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: IMyInterface; // class type
 property MyInterface: IMyInterface
   read FMyInterface implements IMyInterface;
   public
 constructor Create(obj: IMyInterface); << The change
 destructor Destroy; override;
   end;

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

Re: [fpc-pascal] Delegate Interface class does not seem to be referenced counted

[Tony Whyman]

Marcos,

Thanks for the suggestions, but I had already tried the first variation:

   TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: IMyInterface; // class type
 property MyInterface: IMyInterface
   read FMyInterface implements IMyInterface;
   public
 constructor Create(obj: IMyInterface);
 destructor Destroy; override;
   end;

and that did not work.

Destroying FMyInterface in the destructor does not make a difference - 
mainly because the TMyClass destructor is not being called anyway.


On 10/08/16 13:57, Marcos Douglas wrote:

Hi,

See the "problem" bellow:

TMyClass = class(TInterfacedObject, IMyInterface)
private
  FMyInterface: TDelegateClass; <<< HERE >>>
  property MyInterface: TDelegateClass
read FMyInterface implements IMyInterface;
public
  constructor Create(obj: TDelegateClass);
  destructor Destroy; override;
end;

and...

procedure TDelegateTest.DoRun;
var Intf: IMyInterface;
 Intf2: IMyInterface;
begin
Intf := TMyClass.Create(TDelegateClass.Create); <<< HERE >>>
Intf2 := TDelegateClass.Create;

You're treating the instance using class types instead of interface type.

You can:

1. Change FMyInterface: TDelegateClass to FMyInterface: IMyInterface;
or
2. Destroy FMyInterface on destructor.

Best regards,
Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

[fpc-pascal] Delegate Interface class does not seem to be referenced counted

[Tony Whyman]

I'm using fpc 3.0.0 and trying to debug a program using COM interfaces. 
While reference counting seems to be working fine, there is one 
exception, that is when an interface is being used by delegation. In 
this case, the object doing the delegation does not seem to be reference 
counted. Is this a bug, a feature, or have I missed something?


A simple test program follows. The output is:

Creating TDelegateClass
Creating TMyClass
Creating TDelegateClass
Destroying TDelegateClass
Destroying TDelegateClass

In the example, TMyClass is the interface class doing the delegation and 
while TDelegateClass is being destroyed when it goes out of scope, 
TMyClass is not.


Tony Whyman

MWA

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils, CustApp
  { you can add units after this };

type

  { TDelegateTest }

  TDelegateTest = class(TCustomApplication)
  protected
procedure DoRun; override;
  public
constructor Create(TheOwner: TComponent); override;
destructor Destroy; override;
procedure WriteHelp; virtual;
  end;

  IMyInterface = interface
 procedure P1;
   end;

{ TDelegateClass }

   TDelegateClass = class(TInterfacedObject, IMyInterface)
   private
 procedure P1;
   public
 constructor Create;
 destructor Destroy; override;
   end;

   { TMyClass }

   TMyClass = class(TInterfacedObject, IMyInterface)
   private
 FMyInterface: TDelegateClass; // class type
 property MyInterface: TDelegateClass
   read FMyInterface implements IMyInterface;
   public
 constructor Create(obj: TDelegateClass);
 destructor Destroy; override;
   end;

{ TDelegateClass }

procedure TDelegateClass.P1;
begin
  writeln('P1');
end;

constructor TDelegateClass.Create;
begin
  inherited Create;
  writeln('Creating ',ClassName);
end;

destructor TDelegateClass.Destroy;
begin
  writeln('Destroying ',ClassName);
  inherited Destroy;
end;

{ TMyClass }

constructor TMyClass.Create(obj: TDelegateClass);
begin
  inherited Create;
  FMyInterface := obj;
  writeln('Creating ',ClassName);
end;

destructor TMyClass.Destroy;
begin
  writeln('Destroying ',ClassName);
  inherited Destroy;
end;

{ TDelegateTest }

procedure TDelegateTest.DoRun;
var Intf: IMyInterface;
Intf2: IMyInterface;
begin
   Intf := TMyClass.Create(TDelegateClass.Create);
   Intf2 := TDelegateClass.Create;
  // stop program loop
  Terminate;
end;

constructor TDelegateTest.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
  StopOnException := True;
end;

destructor TDelegateTest.Destroy;
begin
  inherited Destroy;
end;

procedure TDelegateTest.WriteHelp;
begin
  { add your help code here }
  writeln('Usage: ', ExeName, ' -h');
end;

var
  Application: TDelegateTest;
begin
  Application := TDelegateTest.Create(nil);
  Application.Title := 'Interface Delegation Test';
  Application.Run;
  Application.Free;
end.

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

Re: [fpc-pascal] old school crc32

[Tony Whyman]

On 24/07/16 00:18, wkitt...@windstream.net wrote:
i've already checked the polynomial ($edb88320) is the same in both, 
the original implementation (converted to TP4 in 1988) and this 
implementation...


Are you sure that you are dealing with a CRC algorithm? ISO 8073 TP4 
uses an arithmetic checksum (Fletcher).


If you are using genuine CRC32 then

http://www.tty1.net/pycrc/

is a good reference for all the different variations. It will generate 
'C' code for you but still a good baseline reference. I've used it 
successfully for CRC implementations (some quite oddball in the aviation 
sector).


Regards

Tony Whyman
MWA

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

Re: [fpc-pascal] Resource strings, passwords etc.

[Tony Whyman]

What's interested me is how this thread has almost looped back to a 
recent thread on that steaming heap of brown stuff know as GTK and the 
attitude of the programmers behind it.


I had a similar problem a few years ago whiich I wanted to solve by 
putting the passwords in an external file and using file permissions to 
hide it from the bad guys. The file could be owned and only readable by 
root, or better some ordinary user. The preferred solution was to make 
it read/write a non-login user and read only to a group but no one else. 
Users had to be members of the group to read it. Better still was to 
make the program setgid to that group, allowing anyone who could run the 
program (and login into the database) to get access to the password 
controlled info without being able to actually read the password themselves.


However, GTK gets in the way of this because some bozo GTK developer 
thinks they should police use of setuid and setgid from GTK and will 
raise an exception if run from a setgid program. Google "gtk setgid" for 
examples. I can't see a security problem from setgid to a normal group - 
to me its a security mechanism, but you try telling that to the GTK team.


Read http://www.gtk.org/setuid.html for an example of some incredibly 
muddled thinking. They make the point here that GTK is (too) complex and 
difficult to analyse hence setuid (and setgid) is bad on the grounds 
that no one knows how it could be mis-used. They then recommend writing 
an setuid backend in such situations, without recognising that all they 
have done is to move a problem rather than solve it. I wanted my program 
to be setgid so that only it could access privileged information. If I 
write a setgid backend program now I have to find a way of 
authenticating my GTK frontend to my backend (Oh perhaps I should 
have an embedded password).


The point is that while it is reasonable for a developer to give 
guidance on what is good practice, actively stopping a user from using 
your code in a way that you do not approve is not just stupid and 
contemptuous of your users, it can actually get in the way of the right 
solution to a problem that you do not know about.


Assuming that this problem still exists in GTK2, it may get in the way 
of what otherwise could be a good way to solve the original problem in 
this thread.


Tony

On 13/07/16 08:31, Mark Morgan Lloyd wrote:

Michael Van Canneyt wrote:

On Tue, 12 Jul 2016, Mark Morgan Lloyd wrote:

Please excuse one of my regular silly questions. Elsewhere, a 
(former) Delphi programmer is uneasy having found that his binaries 
have had embedded SQL queries, passwords and so on visible "in 
clear" for the last 20 years or so.


Can FPC be told to obfuscate ResourceStrings?


No. The default value for resourcestrings is stored as-is in the binary.

To solve this, I store the username/password encrypted in the binary 
as consts, and they are decrypted when needed.


Sometimes it's difficult to avoid having to do that sort of thing, or 
obfuscating them in an external file.




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

Re: [fpc-pascal] PChars and AnsiString Code Pages

[Tony Whyman]

On 18/05/16 14:27, Jonas Maebe wrote:

  s := string(Buf); {seems to work - but should it?}
end;


Why shouldn't it? 


Because I couldn't find any documentation saying this should work and I 
wasn't sure if this worked by luck or design.


To repeat what I said in about every message in the previous 
disinformation thread on this topic: everything will work exactly the 
same in FPC 2.6.4 and FPC 3.0 if you use the same types (with the same 
effective modes/modeswitch) in both FPC versions, except for 
utf8string (which is an alias for ansistring in FPC 2.6.4, and an 
ansistring(CP_UTF8) in FPC 3.0).


Yes. I know you've said that, but the problem with such a statement is 
that it only applies to what is supposed to work and undocumented 
features that worked in the past may no longer be valid once the 
implementation has been updated.


While the online documentation says a lot about tyepcasting PChars to 
AnsiStrings, there seems to be nothing on the reverse.


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

Re: [fpc-pascal] RTL and Unicode Strings

[Tony Whyman]

On 11/05/16 10:18, Graeme Geldenhuys wrote:

In my application I enable unicodestring mode. So I'm reading data from
a Firebird database. The data is stored as UTF-8 in a VarChar field. The
DB connection is set up as UTF-8.  Now lets assume my FreeBSD box is set
up with a default encoding of Latin-1.

So I read the UTF-8 data from the database, somewhere inside the SqlDB
code it gets assigned to a TField's String property. ie: UTF-8 ->
Latin-1 conversion.


Now this is what interests me as well - in the context of IBX if nothing 
else.


It was news to me yesterday that FPC now stores page code information 
with AnsiStrings and while IBX still works OK with FPC 3.0.0, it should 
work better with this new facility. The IBX code here comes from years 
ago and is:



function TIBStringField.GetValue(var Value: string): Boolean;
var
  Buffer: PChar;
begin
  Buffer := nil;
  IBAlloc(Buffer, 0, Size + 1);
  try
Result := GetData(Buffer);
if Result then
begin
  Value := string(Buffer);
  if Transliterate and (Value <> '') then
DataSet.Translate(PChar(Value), PChar(Value), False);
end
  finally
FreeMem(Buffer);
  end;
end; 
Note the really nasty coercion that comes after the call to 
TField.GetData (which is common to all DB Drivers)  - GetData returns 
untyped data into a buffer. DataSet.Translate is a no-op, and I was 
never sure what purpose it has - if anything.


To make this code play properly with the new AnsiString, it looks like I 
should revise this to (e.g. for utf-8 fields)


  Value := string(Buffer);
  SetCodePage(Value,cp_UTF8,false);
  ...

The outgoing side has a similar problem e.g.


procedure TIBStringField.SetAsString(const Value: string);
var
  Buffer: PChar;
begin
  Buffer := nil;
  IBAlloc(Buffer, 0, Size + 1);
  try
StrLCopy(Buffer, PChar(Value), Size);
if Transliterate then
  DataSet.Translate(Buffer, Buffer, True);
SetData(Buffer);
  finally
FreeMem(Buffer);
  end;
end; 


This probably needs a

SetCodePage(Value,cp_UTF8,true);

before the StrLCopy.

Anyone know if this is a correct interpretation of the AnsiString 
codepage facility?

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

Re: [fpc-pascal] String theory

[Tony Whyman]

I don't think this is what I meant as StringCodePage is a unicode string 
function. I am looking at the single byte string types.


On 10/05/16 14:15, Bart wrote:

It already is [part of the string type.
See the StringCodePage function.


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

[fpc-pascal] String theory

[Tony Whyman]

While my first thought over the "String Type" or "End of World" threads 
was this is another "how many angels to the pinhead" type discussion. 
However, having worked through it, I believe that there is an issue here 
and Pascal could be improved by including (for string types) the code 
page as part of the string data itself rather than having to infer it.


As a programmer, I want the freedom to choose which was the appropriate 
character encoding for my application - or even to mix encodings in the 
same application.


- I would always choose UTF-8 for database columns as that is the best 
compromise between international support and compact encoding (and hope 
that my RDBMS was not so dumb as to allocate four times the max 
character width for every UTF-8 string).


- If I was doing a lot of intensive CPU string processing of strings 
with international support then UTF-16 is what I would want to use for 
internal representation - as long as the cost of UTF-8 to UTF-16 
transliteration was justified when reading/writing to disk.


- On the other hand, if I am working on an in house application that I 
know is always going to be working in English (or Western Europe) then 
use of a National Character set (or more likely ISO 10589-1) seems the 
obvious choice.


Pascal does seem to support what I want. It has the unicodestring type 
for UTF-16 and the string type (with code page) for UTF-8 and national 
character sets. However, the problem is that Pascal (or FPC) permits an 
ambiguity between the use of UTF-8 and national character sets.


If you program is in English and your data is in English then UTF-8 and 
Ansistrings (or even different 8-bit code pages) look the same and is 
very easy to get sloppy, use the basic string type all over the place,  
and to get very confused as to what your string code page really is. The 
whole thing then just falls apart when you try and internationalise it.


I would argue that this problem would be avoided if the code page was 
part of the string data (just as the byte count is already) and that 
strings defined without an explicit code page could have a string with 
any code page assigned to them, while strings with an explicit code code 
as part of their type could only be assigned a string of that code page 
(perhaps with automatic transliteration on assignment from another code 
page). Also, byte length and character length could then be returned by 
standard routines.


This is in contrast to the current situation where strings without an 
explicit code page setting are simply assumed to use the 
DefaultSystemCodePage with limited run time checking (often none).


Indeed, if the code page was part of the string data, then the "string" 
type should be able to unify both wide string and ansistrings.



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

[fpc-pascal] Problem using ipc with OSX and fpc 3.0.0

[Tony Whyman]

I have a problem with some existing code that compiled with fpc 2.6.4 
under OSX and does not compile with fpc 3.0.0.


The problem is that the code makes a direct call to the semctl function 
(defined in ipc.pp) and uses the SEM_GETVAL constant as the command 
value. "Identifier not found errors" are returned for SEM_GETVAL (and 
SEM_SETVAL as well).


Checking the ipc.pp source, both SEM_GETVAL and SEM_SETVAL are defined 
for Linux, but when it comes to alternative flavours of unix you now see:


{$if not defined(aix) and not defined(darwin)}
  SEM_GETNCNT = 3;   { Return the value of sempid (READ)  }
  SEM_GETPID  = 4;   { Return the value of semval (READ)  }
  SEM_GETVAL  = 5;   { Return semvals into arg.array (READ)  }
  SEM_GETALL  = 6;   { Return the value of semzcnt (READ)  }
  SEM_GETZCNT = 7;   { Set the value of semval to arg.val (ALTER)  }
  SEM_SETVAL  = 8;   { Set semvals from arg.array (ALTER)  }
  SEM_SETALL  = 9;
{$endif}

That is these identifiers appear to have been removed for OSX and with 
no alternative given. This was not the case with 2.6.4.


Does anyone know why this was done and, if so, how calls to semctl 
should have their command value given under OSX (preferably in a 
platform independent manner).


Tony Whyman
MWA
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] A better way?

[Tony Whyman]

Just remembered, FPC also supports macros - see 
http://www.freepascal.org/docs-html/prog/progse5.html


I haven't tested it, but you should be able to do

{$MACRO On}

{$DEFINE aClassBObject:=TClassB(FClassBObject) }

and then use aClassBObject instead of the coercion.

On 15/04/16 11:13, Tony Whyman wrote:
In the end though this is just a "what's in a name? A rose by any 
other name would smell as sweet" debate. No matter how you approach 
the problem, you have to have an identifier for the other class when 
you reference its methods and properties. If you don't want to declare 
two mutually referential classes in the same unit, then one of them 
(but only one) has to use some technique to avoid circular references. 
Type casting is a simple technique and you either have to coerce each 
use (think of TClassB(FObject) as just being a longer name for the 
same thing) or declare an alias of the correct type - a "With" 
statement can also be your friend here. 


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

Re: [fpc-pascal] A better way?

[Tony Whyman]

On 15/04/16 10:00, Ryan Joseph wrote:

So, a common scenario is a member variable being declared as TObject then 
having to typecast it every time I need to access one of it’s methods. 
Declaring another variable in each function instead of typecasting is perhaps 
more work but maybe I’m not getting it.

Thanks.
Here's an update of my previous example. In this example, "absolute" is 
just a way of tidying up the code when you need to make multiple 
references to a variable that always has to have its type coerced.


In the end though this is just a "what's in a name? A rose by any other 
name would smell as sweet" debate. No matter how you approach the 
problem, you have to have an identifier for the other class when you 
reference its methods and properties. If you don't want to declare two 
mutually referential classes in the same unit, then one of them (but 
only one) has to use some technique to avoid circular references. Type 
casting is a simple technique and you either have to coerce each use 
(think of TClassB(FObject) as just being a longer name for the same 
thing) or declare an alias of the correct type - a "With" statement can 
also be your friend here.


It's not that big an overhead and when it comes to type casts a 'C' 
programmer would wonder what all the fuss was about.


unit unitA;

interface

type

class TClassA
private
  FClassBObject: TObject;
public
  procedure SomeProc;
end;

implementation

uses unitB;

procedure TClassA.SomeProc;
var aClassBObject: TClassB absolute FClassBObject;
begin
  aClassBObject.OtherProc;
end;

end.

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

Re: [fpc-pascal] A better way?

[Tony Whyman]

Ryan,

If you want to get rid of (ugly) typecasts then maybe you should 
investigate the "absolute" keyword. You get a lot of examples in the 
LCL. For example, here's one I chose at random:


function TGtk2WidgetSet.RawImage_CreateBitmaps(const ARawImage: 
TRawImage; out

  ABitmap, AMask: HBitmap; ASkipMask: boolean): boolean;
var
  GdiObject: PGDIObject absolute ABitmap;
  GdiMaskObject: PGDIObject absolute AMask;
  Desc: TRawImageDescription absolute ARawImage.Description;



You could describe it as typecast done in the var clause of a method. 
The right hand identifier is not restricted to function parameters.


Regards

Tony Whyman
MWA

On 15/04/16 07:15, Ryan Joseph wrote:

I’ve cleaned up some code by declaring uses in the implementation and using 
generic untyped variables like TObject for parameters. This compiles but I’m 
left with lots of ugly type casting in the implementation because the 
parameters for methods are untyped. Yes it works but I feel like the compiler 
could be helping more.





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

Re: [fpc-pascal] A better way?

[Tony Whyman]

Ryan,


Maybe I’m doing something stupid but other languages have forward declarations 
so I wonder why Pascal isn’t doing this also since it seems like the obvious 
solution.

Pascal does have forward declarations e.g.

class TClassB;

class TClassA
private
  FClassBObject: TClassB;
end;

class TClassB
...
end;

Otherwise, if you really want to avoid defining interdependent classes 
in the same unit (not sure why you want to avoid this) then try this:


unit unitA;

interface

type

class TClassA
private
  FClassBObject: TObject;
public
  procedure SomeProc;
end;

implementation

uses unitB;

Maybe I’m doing something stupid but other languages have forward declarations 
so I wonder why Pascal isn’t doing this also since it seems like the obvious 
solution.


procedure TClassA.SomeProc;
begin
  TClassB(FClassBObject).OtherProc;
end;

end.

unitB is pretty similar.

As long as you make sure that FClassBObject really is a TClassB object 
when it is assigned, the above should all work. The only extra effort is 
with the TClassB(...) wrapper for each reference to FClassBObject.


On 14/04/16 11:35, Ryan Joseph wrote:

On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt  wrote:

You should not need TClassB here. You defeat the point of using an
interface.

I’m using the interface for specific communication I want denoted in the 
interface but I’m still typically using properties of the child class in 
addition to the interface. Offloading all properties to the interface would 
work but it would be making accessing them very cumbersome because it requires 
using Support instead of just accessing them directly.

The interface was probably over complicating the example actually because the true 
problem is having this pattern of a parent->child relationship where both 
classes need to know about each other to some extent but putting them in the same 
unit causes clutter and pollution in other units namespaces. In this example it’s 
likely that many other units  use TClassB and it’s not exclusive to TClassA so 
putting them in the same unit doesn’t make sense.

Maybe I’m doing something stupid but other languages have forward declarations 
so I wonder why Pascal isn’t doing this also since it seems like the obvious 
solution.

Regards,
Ryan Joseph

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



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

Re: [fpc-pascal] A better way?

[Tony Whyman]

Ryan,

Reading through your post, I hope that you are aware that most circular 
dependencies can be avoided by referencing other units from the "uses" 
clause in the "implementation" section and keeping the "uses" clauses in 
"interfaces" down to those references strictly necessary for the unit's 
interface.


Having probably told you something you already know, i do sometimes get 
circular reference problems and usually because a program has evolved 
rather than having been designed properly. Sometimes it's better just to 
take as a hint to structure your program better but, otherwise, the 
techniques available are:


1. Abstract classes (as you suggest)

2. Interfaces

3. Dynamic casts.

Of the three, dynamic casts are often the quick and dirty way of fixing 
the problem as they can allow you to move a problematic unit reference 
from the "interface uses" to the "implementation uses", replacing the 
class reference in the unit interface to something generic like 
"TObject" and them coercing it to the required class when you actually 
use it.


I hope this helps.

Regards

Tony Whyman
MWA

On 14/04/16 05:29, Ryan Joseph wrote:

The most annoying problem I have with Pascal currently is with circular unit 
dependanices and “global” classes that need to be referenced from many units. In 
other languages I would make a forward declaration of the class in  one file then 
implement it in another file so that all files could reference the class. It’s maybe 
a symptom of a “bad" design but sometimes it’s just faster and easier so it’s a 
problem I have to fight Pascal to make it work.

When I moved to FPC the solution I started using was this pattern below where I 
make an abstract class then override the methods I need in the global namespace 
within in the “main unit”. This is a bad hack to workaround a feature of the 
language but I wonder if there’s a better way. Does anyone have any ideas I 
could try?



"global” unit shared by many other units:

type
   TSomeClassAbstract = class (TObject)
 procedure DoSomething; virtual; abstract;
   end;
   
“main” unit which implements the class:
   
type

   TSomeClass = class (TSomeClassAbstract)
 procedure DoSomething; override;
   end;


Regards,
Ryan Joseph

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



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

[fpc-pascal] Running fpcmake, lazarus and fpc 3.0.0

[Tony Whyman]

When building release versions of lazarus programs I use build scripts 
that build both linux and windows targets on the same system using the 
fpcross compiler (from linux x64_86 to win32). To do this I obviously 
need to build both x64_86 and win32 versions of the lazarus libraries on 
the same linux system. Generally, this is not a problem but you do need 
to run fpcmake on the lazarus directory before building each library 
version. The script starts off like this:


  echo "Building $CPU_TARGET-$OS_TARGET"

  mkdir -p $LAZBUILD
  echo "rsync:  $LAZSRC/* to $LAZBUILD"
  rsync -a $LAZSRC/* $LAZBUILD --exclude units --exclude lib

  find $LAZBUILD -name 'Makefile' -exec rm '{}' \;
  find $LAZBUILD -name 'Makefile.fpc' -exec fpcmake 
-T$CPU_TARGET-$OS_TARGET '{}' \;



Basically, it copies the lazarus source to some build location, scrubs 
out the Makefiles and runs fpcmake to recreate them for the desired target.


This all works fine with fpc 2.6.4 but fpcmake fails with fpc 3.0.0 with 
the error message:


Error: Target "linux", package "regexpr" not found

I am using the standard binary for linux x86_64 installed from 
fpc-3.0.0.x86_64-linux.tar and downloaded from Sourceforge.


After some digging the problem seems to be that regexpr/Package.fpc is 
missing from the standard distribution. I then download the fpc 3.0.0 
sources. "make install" using the sources does not fix then problem. I 
thus install it the hard way:


cd ~/fpc-3.0.0/packages/regexpr
sudo make fpc_install INSTALL_CREATEPACKAGEFPC=1 INSTALL_PREFIX=/usr

seems to work.

Back to fpcmake on lazarus and it fails again, but this time the package 
"fpmkunit" can't be found. Repeat the above. Next up in "hash" and then 
"paszlib", "fcl-process" and finally "libtar". Once these all have there 
Package.fpc files installed, lazarus will build!


It looks to me as if fpc-3.0.0 has forgotten to install the Package.fpc 
files for all packages breaking lazarus builds amongst others.


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

[fpc-pascal] Issues with fpc-build-3.0.0

[Tony Whyman]

I'm experimenting with building fpc from source in various combinations 
and a couple of issues have come up which could be bugs or just me not 
knowing which environment variables to set.


The build environment is a clean install of Linux Mint 17.2 Cinnamon (64 
bit) with fpc 2.6.4 installed from the binary distribution. 
fpc-build-3.0.0.tar.gz is then expanded into my home directory and I 
start off by cd-ing into the directory and starting the build with:


make all NOGDB=1

This seems to happily build the compiler and libraries for the default 
environment. I then do a test install with:


make install NOGDB=1 INSTALL_PREFIX=/tmp/fpc

All seems to be installed fine expect for two things:

1. Missing softlink.
==

The make install does not add the softlink:

ln -s /tmp/fpc/lib/3.0.0/ppcx86 /tmp/bin/ppcx86

I originally came across this problem when installing over 2.6.4 when 
everything was OK expect that the old softlink /usr/bin/ppcx86 had been 
left in place with the result that the new compiler was being ignored 
when I call "fpc -iV" (i.e. 2.6.4 was still the active compiler).


2. Package.fpc is not installed
===

This seems to affect all packages. The problem comes up when compiling 
the lazarus sources. For example:


I now install fpc 3.0.0 with

make install NOGDB=1 INSTALL_PREFIX=/usr

and fix the softlink.


 extract a copy of lazarus 1.6.0rc2, cd to its directory and then run:

fpcmake

it fails with "Error: Target "linux", package "regexpr" not found".

I can maually create regexpr's "Package.fpc" and copy it to 
"/usr/lib/fpc/3.0.0/units/x86_64-linux/regexpr". Repeating the above 
then results in the error "Error: Target "linux", package "fpmkunit" not 
found" and so on.


For some reason the package Package.fpc files are not being generated by 
the fpc build install process.


So, are these bugs or am I just missing something?

Tony





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

Re: [fpc-pascal] Issues with fpc-build-3.0.0

[Tony Whyman]

On 29/01/16 13:17, Michael Van Canneyt wrote:

This is as designed.

The symlink is only installed with the installsymlink make target in 
the compiler directory.


Why? This means that "make install" is effectively broken as the symlink 
is essential for the compiler to work.

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

Re: [fpc-pascal] Issues with fpc-build-3.0.0

[Tony Whyman]

On 29/01/16 13:14, Sven Barth wrote:


Am 29.01.2016 13:24 schrieb "Tony Whyman" 
<tony.why...@mccallumwhyman.com <mailto:tony.why...@mccallumwhyman.com>>:

>
> I'm experimenting with building fpc from source in various 
combinations and a couple of issues have come up which could be bugs 
or just me not knowing which environment variables to set.

>
> The build environment is a clean install of Linux Mint 17.2 Cinnamon 
(64 bit) with fpc 2.6.4 installed from the binary distribution. 
fpc-build-3.0.0.tar.gz is then expanded into my home directory and I 
start off by cd-ing into the directory and starting the build with:


You should use fpc-src-3.0.0. fpc-build is for building a release 
installer.




OK, done that - with the same result. Both issues are still present.


Regards,
Sven



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


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

Re: [fpc-pascal] Issues with fpc-build-3.0.0

[Tony Whyman]

I am not convinced that it is a good idea for the default install to 
result in a broken system.


Wouldn't it be better to have a "NOSYMLINK" environment variable instead 
to handle the developer versions? Failing that a "README" file giving 
basic build instructions could be useful or a final message on install 
completion saying something like "Now run make -C complier 
installsymlink to complete the installation".


BTW, the most up-to-date instructions I have been able to find on 
building fpc from source is buried in the wiki under a page titled 
"Installing Lazarus", and that suggests creating the symlink manually.


On 29/01/16 13:35, Jonas Maebe wrote:
The symlink is only installed with the installsymlink make target in 
the compiler directory.


Why?


Because "make install" is often used to install development versions 
of FPC, and the you don't necessarily want it to change the default 
compiler version at the same time.


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

Re: [fpc-pascal] Issues with fpc-build-3.0.0

[Tony Whyman]

I think that my concern is that I fell into a simple trap. Now I know 
it's there I probably won't do it again - but I want to report it so 
that others don't do the same thing.


The problem is that intuitively "make install" should install a working 
program or bring an existing one up-to-date. Clearly, in FPC, that is 
not true and it installs a program suitable for testing with a separate 
action needed to make it the live version. Ideally, there should be a 
separate "make testinstall" for a test system and with "make install" 
having its usual semantic. However, it seems to late to change that.


A message emitted at the end of "make install" along the lines of "now 
enter make -C compiler installsymlink" would have probably stopped me 
falling into the trap and I think that would be a good thing to add to 
always remind the user about the extra step to make the compiler the 
live version.


However, it may also be worth adding a warning message to the fpc binary 
to warn when the selected symlink points to a binary with a different 
version number to fpc. That could also be useful diagnosing broken or 
partly updated installations.


Tony

On 29/01/16 15:26, Mark Morgan Lloyd wrote:


I wonder whether a useful compromise would be to install a sufficient 
symlink that  fpc -V  reaches a plausible binary. After all, I'm sure 
I'm not the only person who has a symlink layer like  ppcx86-3.0.0  
and having  ppcx86  forcibly overwritten before I was ready for it 
might not be what I wanted.


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

[fpc-pascal] XML Registry Bug?

[Tony Whyman]

I came across this trying to track down a bug in a linux program where 
two separate instances of TRegistry were being used to both read and 
write data to the registry. Depending on the order in which operations 
were done, writes were being lost and not turning up in the XML file. 
The outcome is even more unpredictable when the TRegistry instances are 
owned by multiple threads.


Digging deeper, the problem seems to be that:

a) Each TRegistry instance creates its own TXMLRegistry object.

b) When the TXMLRegistry is created, it loads the XML File into memory.

c) Where a key is closed, the cached data is written back (flushed), but 
never refreshed.


The result is that with each TRegistry instance caching its own copy, 
every time a key is closed, the updates from the other instances are 
overwritten.


This seems to be a bug to me as there is nothing to say that you should 
only have one TRegistry instance at any one time.


The obvious fix seems to be for there to be a single instance of 
TXMLRegistry shared between all instances of TRegistry - or at least one 
TXMLRegistry for use when GlobalXMLFile is true and another for when 
GlobalXMLFile is false.


Is there a good reason not to propose this as a bug fix?

Tony Whyman
MWA
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to compile Lazarus program using only FPC?

[Tony Whyman]

Rather than going down the lazbuild path as others have suggested, you 
might want to think about fpcmake and creating a "Makefile.fpc" for your 
project. That should be the standard way of building a lazarus project 
just using fpc.


You will need to write a Makefile.fpc that does the same job as the 
lazarus .lpi file and include the LCL and components you use in the 
search paths but once you have done it once, its very easy to copy and 
paste to then next project. Here's a snippet that I often use:


[compiler]
options= -Scghi -O3 -CX -Xs -vewnhi -l -dUseCThreads -dLCL 
-dLCL$(INTERFACE)

unittargetdir=units/$(CPU_TARGET)-$(OS_TARGET)
unitdir= $(LZSOURCE) .

[target]
programs=myprogram

where I have defined under [prerules}

SRCDIR=/my/path/to/lazarus

LZSOURCE=\
$(SRCDIR)/lazarus/components/cairocanvas/lib/$(CPU_TARGET)-$(OS_TARGET)/$(INTERFACE) 
\
$(SRCDIR)/lazarus/components/lazcontrols/lib/$(CPU_TARGET)-$(OS_TARGET)/$(INTERFACE) 
\
$(SRCDIR)/lazarus/components/ideintf/units/$(CPU_TARGET)-$(OS_TARGET)/$(INTERFACE) 
\

$(SRCDIR)/lazarus/packager/units/$(CPU_TARGET)-$(OS_TARGET)/ \
$(SRCDIR)/lazarus/lcl/units/$(CPU_TARGET)-$(OS_TARGET)/ \
$(SRCDIR)/lazarus/components/lazutils/lib/$(CPU_TARGET)-$(OS_TARGET)/ \
$(SRCDIR)/lazarus/lcl/units/$(CPU_TARGET)-$(OS_TARGET)/$(INTERFACE) \
$(SRCDIR)/lazarus/components/memds/lib/$(CPU_TARGET)-$(OS_TARGET)/$(INTERFACE) 
\
$(SRCDIR)/lazarus/components/printers/lib/$(CPU_TARGET)-$(OS_TARGET)/$(INTERFACE) 



Note that this includes a few common components. You need to include the 
path to each component you are using which may vary from the above. The 
above also assumes that the components have already been compiled - 
which should be true if they are included in the IDE.


To build for a GTK2 target, you will then need to run:

export FPCDIR=/usr/lib/fpc/`fpc -iV`
fpcmake  Makefile.fpc
make INTERFACE=gtk2

If you are running on Windows then you will do something like:
FPCDIR=
fpcmake  Makefile.fpc
make INTERFACE=win32

I tend to perform Windows builds using a cross compiler on Linux, 
because its so much easier to script. The you will call something like:


export FPCDIR=/usr/lib/fpc/`fpc -iV`
fpcmake -r -Ti386-win32 Makefile.fpc
make OS_TARGET=win32 CPU_TARGET=i386 BINUTILSPREFIX=amd64-mingw32msvc- 
INTERFACE=win32


Tony Whyman
MWA



On 24/09/15 14:48, Bo Berglund wrote:

I want to check my options regarding Lazarus and FPC.

If I develop a program on Windows Lazarus, move it to Debian Lazarus
(x86) and then finally want to compile on ARM on for example Raspberry
Pi but outside of Lazarus, how is that done?
Does FPC recognize the Lazarus project file such that paths etc are
observed?
Or is thare a separate file for FPC I have to prepare in order to set
the unit paths?




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