Re: [fpc-pascal] MSEide+MSEgui 4.4 for Free Pascal 3.0.2

[Martin Schreiber]

On Wednesday 01 March 2017 02:40:44 nore...@z505.com wrote:
> On 2017-02-14 08:51, Martin Schreiber wrote:
> > Hi,
> > MSEide+MSEgui 4.4 for Free Pascal 3.0.2 has been released:
> > https://sourceforge.net/projects/mseide-msegui/
> >
> > There are also new versions of the ARM (Raspberry Pi) cross and native
> > environments for Free Pascal:
> > https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/
> > https://sourceforge.net/projects/mseide-msegui/files/fpcarm/
> >
> > and new versions of MSEgit, MSEspice and MSErun:
> > https://sourceforge.net/projects/mseuniverse/
>
> Is there a wiki or information page explaining what mserun is, along
> with others mentioned above.. I could not find it on google.
>
MSErun is a tool which can be used to run command groups which are defined in 
a GUI in a hierarchical manner and which has the same flexible macro facility 
as MSEide. I use it as build tool for the MSE* projects and in order to run 
test cases. Please ask questions about the MSE* projects on the mailinglist:
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Archive:
http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/

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

[fpc-pascal] class operator in record

[noreply]

How come:

  class operator Initialize(var aFoo: TFoo);
  class operator Finalize(var aFoo: TFoo);

in a record are called class operator..

why not "record operator"?

Are these advanced neo-records considered classes?

Again, sorry I'm new to all this new record stuff (neo records ;-))

If they really are just classes, shouldn't it be called a class instead 
of record.


This also reminds me of the confusion between what an object is versus a 
class.

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

Re: [fpc-pascal] MSEide+MSEgui 4.4 for Free Pascal 3.0.2

[noreply]

On 2017-02-14 08:51, Martin Schreiber wrote:

Hi,
MSEide+MSEgui 4.4 for Free Pascal 3.0.2 has been released:
https://sourceforge.net/projects/mseide-msegui/

There are also new versions of the ARM (Raspberry Pi) cross and native
environments for Free Pascal:
https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/
https://sourceforge.net/projects/mseide-msegui/files/fpcarm/

and new versions of MSEgit, MSEspice and MSErun:
https://sourceforge.net/projects/mseuniverse/


Is there a wiki or information page explaining what mserun is, along 
with others mentioned above.. I could not find it on google.


I'm interested in the theory of such tools and what they do.

Found on post from Graeme about compiling with 8 cores, but that still 
does not explain what mserun is ;-)

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

Re: [fpc-pascal] Feature announcement: Management Operators

[Graeme Geldenhuys]

On 2017-02-28 20:40, nore...@z505.com wrote:
> Sorry, I've been out of touch with what's happening with Records lately 
> in modern pascal/delphi/etc.

Don't worry, I'm with you on that one. All I know is that
Borland/CodeGear/EMBT broken TP Objects somewhere in Delphi. Then they
decided they want that functionality back, so instead of fixing TP
Objects, the decided to butcher Records to act just like TP Objects
(well, pretty much)! Go figure.

I mostly code with classes, but do still us TP Objects mixed in with my
code for simpler data structures where I don't really want to
instantiate objects. Records - well, I use them like they were defined
in Delphi 7 and earlier. I really don't see the need for Records with
Methods (ie: TP Objects) and such.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[Jonas Maebe]

On 28/02/17 21:40, nore...@z505.com wrote:

What happens with a stack allocated record?
(no new() required, nor dispose() so is the record ever
initialized/finalized?)


Yes, just like records that contain e.g. an ansistring field.


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

Re: [fpc-pascal] TProcess usage and reading program output

[Benito van der Zander]

Hi,

 how would you handle large output and large stderr?


When you read from one and it writes to the other, the read blocks. Then 
it keeps writing to the other buffer, till that is full, and then its 
write is blocked, and it is deadlocked.


Probably check NumBytesAvailable before reading?

Bye,
Benito



On 02/28/2017 05:28 PM, Michael Van Canneyt wrote:



On Tue, 28 Feb 2017, Graeme Geldenhuys wrote:


Hi,

Can anybody see if there is something wrong with the code shown below.
The code is copied from one of my earlier projects where I call the FPC
compiler and it worked just fine in that project.

In the work I'm doing now, I'm calling the Delphi Command Line Compiler,
and made a few minor tweaks to the code, but this method never seems to
return when Delphi command line compiler is called, and I don't see any
output. If I call other utilities (eg: Git etc) then I do see output and
it works as expected. It's just the Delphi Command Line Compiler that
now seems to be giving troubles.

I would really appreciate it is anybody could spare a moment. Many 
thanks.


I marked two areas with "// ???" where I am unsure if I'm doing the
right thing.


poWaitOnExit should not be needed, as this will cause Execute to wait 
for process exit...


It seems likely that this will interfere with reading from output: 
when the

output buffer is full, the executed process will block.

The rest seems fine.

Also:
It may be that Delphi somehow writes directly to the console buffer, 
in that

case you will not catch any output. But then you should see the output on
the screen (just not caught by your process)

Michael.








==
function TBuildDelphiProject.RunTProcess(const Binary: string; args:
TStrings): boolean;
const
 BufSize = 1024;
var
 p: TProcess;
 Buf: string;
 Count: integer;
 i: integer;
 LineStart: integer;
 OutputLine: string;
begin
 p := TProcess.Create(nil);
 try
   p.Executable := Binary;
   // ??? Is poWaitOnExit needed here, it is called later down the code
   p.Options := [poUsePipes, poStdErrToOutPut, poWaitOnExit];
//p.CurrentDirectory := ExtractFilePath(p.Executable);
   p.ShowWindow := swoShowNormal;  // ??? Is this needed?

   p.Parameters.Assign(args);
   DoLog(etInfo,'Running command "%s" with arguments
"%s"',[p.Executable, p.Parameters.Text]);
   p.Execute;

   { Now process the output }
   OutputLine:='';
   SetLength(Buf,BufSize);
   repeat
 if (p.Output<>nil) then
 begin
   Count:=p.Output.Read(Buf[1],Length(Buf));
 end
 else
   Count:=0;
 LineStart:=1;
 i:=1;
 while i<=Count do
 begin
   if Buf[i] in [#10,#13] then
   begin
 OutputLine:=OutputLine+Copy(Buf,LineStart,i-LineStart);
 writeln(OutputLine);
 OutputLine:='';
 if (iBuf[i+1]) then
   inc(i);
 LineStart:=i+1;
   end;
   inc(i);
 end;
 OutputLine:=Copy(Buf,LineStart,Count-LineStart+1);
   until Count=0;
   if OutputLine <> '' then
 writeln(OutputLine);
   p.WaitOnExit;
   Result := p.ExitStatus = 0;
   if Not Result then
 Writeln('Command ', p.Executable ,' failed with exit code: ',
p.ExitStatus);
 finally
   FreeAndNil(p);
 end;
end;
==


Regards,
 Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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 maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[noreply]

On 2017-02-28 05:20, Maciej Izak wrote:


It works correctly in all possible ways with RTL:

* New (Initialize)
* Dispose (Finalize)


What happens with a stack allocated record?
(no new() required, nor dispose() so is the record ever 
initialized/finalized?)


Or stack records are forbidden?

One reason I love records is because you can create a stack record 
without any worry of freeing and creating it on heap, a huge advantage 
over OOP programming in delphi/fpc where everything is heap object 
(except old turbo pascal objects).


Sorry, I've been out of touch with what's happening with Records lately 
in modern pascal/delphi/etc.
(If it sounds like a silly newbie question, forgive me, I am not up on 
the latest and greatest!)

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

Re: [fpc-pascal] TProcess usage and reading program output

[Graeme Geldenhuys]

On 2017-02-28 20:03, nore...@z505.com wrote:
> Did you end up resolving the issue?

Yes, see my "closing thoughts" reply to Michael. What he suggested fixed
the issue.


> I'd be interested in creating a build tool that not only compiles 
> projects in FPC but also compiles with dcc32 (delphi compiler)..
> 
> Is that something like what you are doing?

I'm converting a *very* complex (and massive) multi-project Makefile
system into a single "build binary". Configuration is controlled via
project.json files. eg: build dependencies, build lists (if a project
consists of more that one project), compiler parameters with macro
support (macros are global configurations that can be injected in
compiler parameters etc).

This is not a general tool, but a specific commercial solution. Saying
that, it should be possible building a general tool that does similar -
reading project.json files to feed the build system. But then again,
there are probably multiple such solutions around already (I think).


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TProcess usage and reading program output

[Graeme Geldenhuys]

On 2017-02-28 16:28, Michael Van Canneyt wrote:
> poWaitOnExit should not be needed, as this will cause Execute to wait for 
> process exit...

This post is simply to close off this thread. Michael's suggestion was
the solution to my problem. I removed the poWaitOnExit and set my buffer
size to 2048 bytes and that seems to have resolved the issue.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TProcess usage and reading program output

[noreply]

On 2017-02-28 10:06, Graeme Geldenhuys wrote:

Hi,

Can anybody see if there is something wrong with the code shown below.
The code is copied from one of my earlier projects where I call the FPC
compiler and it worked just fine in that project.



Did you end up resolving the issue?

I'd be interested in creating a build tool that not only compiles 
projects in FPC but also compiles with dcc32 (delphi compiler)..


Is that something like what you are doing? I have a lot of projects that 
compile both in fpc and delphi and compiling manually using to compilers 
is a pain. One step just compiling it with a build tool that does both 
compilers would be nice.

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

Re: [fpc-pascal] parser combinator library

[noreply]

On 2017-02-24 15:00, Bernd wrote:

Hello,

Eight years ago someone asked whether there is a parser combinator
library for free pascal, nothing like that existed at that time and
also does not seem to exist up to the present day.

While I was reading about parser combinators in functional programming
languages (during my 42nd attempt to learn Haskell) I thought to
myself why not try to implement something like that in Object Pascal,
just so see how far we can push the boundaries of this imperative
object oriented language.

This is what I have come up with so far:
https://github.com/prof7bit/fpc_parser_combinators

Since we don't have lambdas I choose the next closest approach to
emulate them with object instances instead. This leads to a lot of
boiler plate in the definition of the elementary parsers and
combinators but fortunately it can all be hidden away in the library
and the usage of the combinators looks quite neat:

 // define the grammar
  EXPR  := Num or _PARENS;
  MULFUNC   := Sym('mul') and EXPR and EXPR;
  ADDFUNC   := Sym('add') and EXPR and EXPR;
  INNER := MULFUNC or ADDFUNC or Num;
  PARENS:= Sym('(') and INNER and Sym(')');

Please also note the unorthodox usage of and/or operators to invoke
the combinators :-)


Cool! Parsing is my favourite area of computing science..

And my 42 attempt at learning haskell I gave up because it seemed not to 
be able to do a simple char by char parser like any procedural language 
can do...


But, now that you've mentioned this, my interest has peaked in both 
Object Pascal and Haskell.




Please post improvements or variations of this theme, especially I am
interested in how to properly build up a syntax tree in the most
generic and reusable manner, this is something I have not yet
completely understood (because I am myself still quite unfamiliar with
this whole parsing business) currently all my parsers only return
arrays of strings that I can optionally post-process with an optional
hook function after a parser has completed.


I think parsing is still something computing science has to study more. 
There are many undiscovered techniques. The biggest issue I have seen is 
large long case statements where you start duplicating code in the case 
statement. Rob Pike has done some work on this, but I've had little time 
to research his solution proposed.

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

Re: [fpc-pascal] TProcess usage and reading program output

[Graeme Geldenhuys]

On 2017-02-28 16:28, Michael Van Canneyt wrote:
> poWaitOnExit should not be needed, as this will cause Execute to wait for 
> process exit...
> 
> It seems likely that this will interfere with reading from output: when the
> output buffer is full, the executed process will block.

Ah. I've also been reading the docs and this FPC wiki page...

   http://wiki.freepascal.org/Executing_External_Programs

In the wiki they talked about a dead-lock when poWaitOnExit is used and
the output buffer is full. It seems that is exactly what I experienced.
I'll increase the buffer size I use to 2048 and remove the poWaitOnExit
and see how it goes. The "Reading large output" example also uses a
TMemoryStream instead of a string buffer like I do, but I think we
should have the same end result.


http://wiki.freepascal.org/Executing_External_Programs#Reading_large_output

If my code still doesn't work, I'll switch to using a TMemorySteam for
storing the output and retest.

Thanks for the extra pair of eyes.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TProcess usage and reading program output

[Michael Van Canneyt]

On Tue, 28 Feb 2017, Graeme Geldenhuys wrote:


Hi,

Can anybody see if there is something wrong with the code shown below.
The code is copied from one of my earlier projects where I call the FPC
compiler and it worked just fine in that project.

In the work I'm doing now, I'm calling the Delphi Command Line Compiler,
and made a few minor tweaks to the code, but this method never seems to
return when Delphi command line compiler is called, and I don't see any
output. If I call other utilities (eg: Git etc) then I do see output and
it works as expected. It's just the Delphi Command Line Compiler that
now seems to be giving troubles.

I would really appreciate it is anybody could spare a moment. Many thanks.

I marked two areas with "// ???" where I am unsure if I'm doing the
right thing.


poWaitOnExit should not be needed, as this will cause Execute to wait for 
process exit...

It seems likely that this will interfere with reading from output: when the
output buffer is full, the executed process will block.

The rest seems fine.

Also:
It may be that Delphi somehow writes directly to the console buffer, in that
case you will not catch any output. But then you should see the output on
the screen (just not caught by your process)

Michael.








==
function TBuildDelphiProject.RunTProcess(const Binary: string; args:
TStrings): boolean;
const
 BufSize = 1024;
var
 p: TProcess;
 Buf: string;
 Count: integer;
 i: integer;
 LineStart: integer;
 OutputLine: string;
begin
 p := TProcess.Create(nil);
 try
   p.Executable := Binary;
   // ??? Is poWaitOnExit needed here, it is called later down the code
   p.Options := [poUsePipes, poStdErrToOutPut, poWaitOnExit];
//p.CurrentDirectory := ExtractFilePath(p.Executable);
   p.ShowWindow := swoShowNormal;  // ??? Is this needed?

   p.Parameters.Assign(args);
   DoLog(etInfo,'Running command "%s" with arguments
"%s"',[p.Executable, p.Parameters.Text]);
   p.Execute;

   { Now process the output }
   OutputLine:='';
   SetLength(Buf,BufSize);
   repeat
 if (p.Output<>nil) then
 begin
   Count:=p.Output.Read(Buf[1],Length(Buf));
 end
 else
   Count:=0;
 LineStart:=1;
 i:=1;
 while i<=Count do
 begin
   if Buf[i] in [#10,#13] then
   begin
 OutputLine:=OutputLine+Copy(Buf,LineStart,i-LineStart);
 writeln(OutputLine);
 OutputLine:='';
 if (iBuf[i+1]) then
   inc(i);
 LineStart:=i+1;
   end;
   inc(i);
 end;
 OutputLine:=Copy(Buf,LineStart,Count-LineStart+1);
   until Count=0;
   if OutputLine <> '' then
 writeln(OutputLine);
   p.WaitOnExit;
   Result := p.ExitStatus = 0;
   if Not Result then
 Writeln('Command ', p.Executable ,' failed with exit code: ',
p.ExitStatus);
 finally
   FreeAndNil(p);
 end;
end;
==


Regards,
 Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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] TProcess usage and reading program output

[Graeme Geldenhuys]

On 2017-02-28 16:06, Graeme Geldenhuys wrote:
> //p.CurrentDirectory := ExtractFilePath(p.Executable);


Just thought I would explain this. I don't change directory there (in
the TProcess instance), because the program itself changes the current
directory before calling RunTProcess().

As for the procedure not returning - from what I can see (I think) it
seems like if Delphi fails to compile the project, that's when my code
get stuck and never returns.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] TProcess usage and reading program output

[Graeme Geldenhuys]

Hi,

Can anybody see if there is something wrong with the code shown below.
The code is copied from one of my earlier projects where I call the FPC
compiler and it worked just fine in that project.

In the work I'm doing now, I'm calling the Delphi Command Line Compiler,
and made a few minor tweaks to the code, but this method never seems to
return when Delphi command line compiler is called, and I don't see any
output. If I call other utilities (eg: Git etc) then I do see output and
it works as expected. It's just the Delphi Command Line Compiler that
now seems to be giving troubles.

I would really appreciate it is anybody could spare a moment. Many thanks.

I marked two areas with "// ???" where I am unsure if I'm doing the
right thing.


==
function TBuildDelphiProject.RunTProcess(const Binary: string; args:
TStrings): boolean;
const
  BufSize = 1024;
var
  p: TProcess;
  Buf: string;
  Count: integer;
  i: integer;
  LineStart: integer;
  OutputLine: string;
begin
  p := TProcess.Create(nil);
  try
p.Executable := Binary;
// ??? Is poWaitOnExit needed here, it is called later down the code
p.Options := [poUsePipes, poStdErrToOutPut, poWaitOnExit];
//p.CurrentDirectory := ExtractFilePath(p.Executable);
p.ShowWindow := swoShowNormal;  // ??? Is this needed?

p.Parameters.Assign(args);
DoLog(etInfo,'Running command "%s" with arguments
"%s"',[p.Executable, p.Parameters.Text]);
p.Execute;

{ Now process the output }
OutputLine:='';
SetLength(Buf,BufSize);
repeat
  if (p.Output<>nil) then
  begin
Count:=p.Output.Read(Buf[1],Length(Buf));
  end
  else
Count:=0;
  LineStart:=1;
  i:=1;
  while i<=Count do
  begin
if Buf[i] in [#10,#13] then
begin
  OutputLine:=OutputLine+Copy(Buf,LineStart,i-LineStart);
  writeln(OutputLine);
  OutputLine:='';
  if (iBuf[i+1]) then
inc(i);
  LineStart:=i+1;
end;
inc(i);
  end;
  OutputLine:=Copy(Buf,LineStart,Count-LineStart+1);
until Count=0;
if OutputLine <> '' then
  writeln(OutputLine);
p.WaitOnExit;
Result := p.ExitStatus = 0;
if Not Result then
  Writeln('Command ', p.Executable ,' failed with exit code: ',
p.ExitStatus);
  finally
FreeAndNil(p);
  end;
end;
==


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[Maciej Izak]

2017-02-28 13:19 GMT+01:00 Michael Van Canneyt :

> You do now. I took care of that :)


Thanks ^^ now I can officially fix bugs related to new feature. Mhm.
Great... ;)

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[Michael Van Canneyt]

On Tue, 28 Feb 2017, Michael Van Canneyt wrote:




On Tue, 28 Feb 2017, Maciej Izak wrote:


2017-02-28 12:28 GMT+01:00 denisgolovan :


Thanks a lot.
I guess http://bugs.freepascal.org/view.php?id=30687 should be closed now
:)



I don't have such powers ;)


You do now. I took care of that :)

But I set it to fixed for you. Seeing you were the reporter, you can set it
to closed :)


By the way, thanks for the contribution.

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

Re: [fpc-pascal] Feature announcement: Management Operators

[Michael Van Canneyt]

On Tue, 28 Feb 2017, Maciej Izak wrote:


2017-02-28 12:28 GMT+01:00 denisgolovan :


Thanks a lot.
I guess http://bugs.freepascal.org/view.php?id=30687 should be closed now
:)



I don't have such powers ;)


You do now. I took care of that :)

But I set it to fixed for you. Seeing you were the reporter, you can set it
to closed :)

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

Re: [fpc-pascal] Feature announcement: Management Operators

[Maciej Izak]

2017-02-28 12:28 GMT+01:00 denisgolovan :

> Thanks a lot.
> I guess http://bugs.freepascal.org/view.php?id=30687 should be closed now
> :)
>

I don't have such powers ;)

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[denisgolovan]

Thanks a lot.I guess http://bugs.freepascal.org/view.php?id=30687 should be closed now :) -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Feature announcement: Management Operators

[Maciej Izak]

Hi,

I'm pleased to finally announce (again but now officially ;) ) the
additional record operators: Initialize, Finalize, AddRef and Copy.
Available in latest FPC trunk (r35485):

1. operator Initialize - is called after memory allocation for record (called
*after* FPC internal call recordrtti(data,typeinfo,@int_initialize);)

2. operator Finalize -  is called when record goes out of scope (called
*before* FPC internal call recordrtti(data,typeinfo,@int_finalize);)

3. operator AddRef - is called after the contents of a record has been
duplicated by copying the contents byte by byte (called *after* FPC
internal call recordrtti(data,typeinfo,@int_addref);  )

4. operator Copy - Copy operator (if exists) is called *instead of* default
copy behavior. Operator is responsible for copying everything that's needed
from the source to the target.

AddRef and Copy might be at beginning a little hard for understanding but
we have good explanation provided by Thorsten Engler in topic "Management
operators : Copy and Clone confusion..." :

=== quote begin ===
the reason for both to exist is that there are cases (e.g.
passing an interface parameter) where the callee is responsible for any
lifetime management implications (and the caller might not even be
implemented using fpc). The caller just passes the interface pointer on the
stack (or in a register), which, while it creates a copy of the bytes, does
not actually invoke the copy operator. In cases where reference counting is
required (parameter not marked as const), the callee may decide to simply
use the value that was passed on the stack as the backing for the parameter,
so it calls AddRef on that, without performing another copy.

Given this context, I find the terms AddRef and Copy to be perfectly
adequate, even when applied to types that aren't strictly speaking
performing reference counting; e.g. IIRC, AddRef for a BSTR (ole string type
for windows which does NOT have a reference count) actually involves making
a copy of the string contents and replacing the BSTR pointer.

AddRef here means "this is now an *additional* *reference* to whatever these
bytes might refer to".
=== quote end ===

my 2 cents for above: AddRef exist to speed up things.

New set of operators is unique and is called "management operators". That
is because:

A. each of record (even non managed or even empty) with management operator
becomes managed type.

B. is possible to implement new custom types (also thanks to other
operators) with own management of memory (new string types, fast TValue
implementations without hacks on RTL etc.).

C. "management operators" have no result.

D. For management operators is generated simple VMT (thanks to this is
possible to work with management operators together with all RTL functions
like InitializeArray/FinalizeArray).

=== example declaration begin ===
  PFoo = ^TFoo;
  TFoo = record
  private
class operator Initialize(var a: TFoo);
class operator Finalize(var a: TFoo);
class operator AddRef(var a: TFoo);
class operator Copy(constref aSrc: TFoo; var aDst: TFoo);
  end;
=== example declaration end ===

Management Operators feature can be used for many things:

* support for value types
* nullable types
* some custom ARC variations
* speed up existing types
* very fast RTTI.TValue implementation
* as replacement for manually called Init/Done record methods like in
mORMot for many types (for example SynCommons.TSynLocker).
* auto init/finit for pointers/classes/simple types or whatever we have in
Pascal

It works correctly in all possible ways with RTL:

* New (Initialize)
* Dispose (Finalize)
* Initialize (Initialize)
* Finalize (Finalize)
* InitializeArray (Initialize)
* FinalizeArray (Finalize)
* SetLength (Initialize/Finalize)
* Copy (AddRef)
* RTTI.IsManaged

Managements operators are often called implicitly in many cases. Few
examples:

* global variables (Initialize/Finalize)
* local variables (Initialize/Finalize)
* for fields inside: records, objects, classes (Initialize/Finalize)
* variable assignment (Copy)
* for parameters for routines (AddRef/Finalize/none - depends on modifiers
like var/constref/cons)

Own experiments recommended! :)

Complex example and test:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/tes
t/tmoperator8.pp?view=co=text%2Fplain

Note: Lazarus (trunk version) has support for all new operators syntax
(thanks for Mattias Gaertner).

Future directions and opened doors (where management operators can be used
but not directly):

+ "default" field for better handling smart pointers / nullable types
(maybe will be introduced new type called proxy record for handling
"default" modifier) (eg. https://github.com/maciej-izak/PascalSmartPointers
compilable with NewPascal)
+ New VMT entry "vmtManagedInit" for "Initialize operator" for record
fields inside classes (optimization)
+ Base for Nullable types syntax sugar
+ Probably base in some way for ARC classes (DELPHINEXTGEN compiler mode)
+ More Oxygene