Re: [fpc-devel] TCollection.FOwner

[Juha Manninen]

On Wed, Dec 27, 2017 at 6:39 PM, Michael Van Canneyt
 wrote:
> I don't want to burden TCollection with a field that will rarely be used.
>
> The proper solution is to implement GetOwner correctly for all cases that
> need it. That's why it is there.
>
> So if you report all cases where GetOwner is missing/not correctly set, I
> will fix them.

The cases I know were mentioned : TParams, TDefCollection and TFPWebActions.
There already is TOwnedCollection which adds an Owner. TDefCollection
is based on it but then it adds a useless Dataset instead of using the
Owner.
TParams adds its own FOwner instead of inheriting from TOwnedCollection.
I guess all classes that want to return their owner in GetOwner must
have a variable for it. They could as well inherit from
TOwnedCollection then.

I hope other people will report similar cases for other classes.

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

Re: [fpc-devel] TCollection.FOwner

[Michael Van Canneyt]

On Wed, 27 Dec 2017, Juha Manninen wrote:


I am proposing to add a private
 FOwner: TPersistent;
to TCollection and remove it from derived classes which already have it.
At least TParams has it but it is not used.


I don't want to burden TCollection with a field that will rarely be used.

The proper solution is to implement GetOwner correctly for all cases that
need it. That's why it is there.

So if you report all cases where GetOwner is missing/not correctly set, 
I will fix them.


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

Re: [fpc-devel] TCollection.FOwner

[Martin Schreiber]

On 12/27/2017 04:15 PM, Juha Manninen wrote:
> I am proposing to add a private
>   FOwner: TPersistent;
> to TCollection and remove it from derived classes which already have it.

Just a warning which does not necessarily apply to the TCollection issue
you report:
Be very careful to change component streaming behavior. It is difficult
to see all consequences with inlined and inherited components and all
possible combinations.

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

[fpc-devel] TCollection.FOwner

[Juha Manninen]

I am proposing to add a private
  FOwner: TPersistent;
to TCollection and remove it from derived classes which already have it.
At least TParams has it but it is not used.
The next step would be to assign a proper owner for derived
TCollection instances, case by case.
Lazarus has code to go up in hierarchy by TPersistent.GetOwner calls. See:
 function GetLookupRootForComponent(APersistent: TPersistent): TPersistent;
So, it already works perfectly if only the Owners are set.

My fundamental goal is to fix issue
  https://bugs.freepascal.org/view.php?id=25068
There is no link from a TCollection to its "owner" object which is
called "LookupRoot" in Lazarus sources. The Collection is not visible
in Object Inspector and changing a CollectionItem cannot mark the
top-level Form/DataUnit as modified.

Mattias has made a hack where the "LookupRoot" of certain TCollection
derivatives can be queried.
It was implemented for TFieldDefs with an explicit Dataset propery.
In r56855 changed it to query TDefCollection which actually defines
the Dataset and thus includes derived IndexDefs, too.
Yes, now FieldDefs and IndexDefs both show in OI and changing them
sets Modified flag correctly.
But, it is still a hack and does not scale. We need a general solution
for all TCollection derivatives.
What more, the "Owner" of TDefCollection is not used which is poor
design. It could be used instead of "Dataset".

TParams has FOwner which is correctly returned by overridden method GetOwner.
However it is never set which can be considered a bug.
I tried to assign owner DataSource.DataSet for it in the only place of
creation I found, but it has no effect.

  Function TCustomSQLStatement.CreateParams: TSQLDBParams;
  var
DS: TDataSet;
  begin
if Assigned(DataSource) then
  DS := DataSource.DataSet
else
  DS := Nil;
Result:=TSQLDBParams.Create(DS);
  end;

TFPWebActions is another TCollection derivative without an owner.
I am sure there are plenty more but I did not study them.
I can provide a patch to add FOwner to TCollection and to return it by
GetOwner but I don't know much about the derived classes in FPC libs.
Help is needed there.

One note: the TCollection.Owner explained here is not inherently tied
to memory management like TComponent.Owner is.

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

Re: [fpc-devel] An extension of fpc language: the BASED construct

[Sven Barth via fpc-devel]

Am 27.12.2017 00:54 schrieb "Giuliano Colla" :

Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto:

Am 26.12.2017 13:33 schrieb "Giuliano Colla" :

If the idea is not rejected, then a number of refinements (which I'm ready
to implement) are required to make the feature generally available:


My following remarks are independent of an eventual acceptance of the
feature :

- All architectures should be supported (now it's only for x86_64 -
symcpu.pas).

It might be possible to implement this in a platform independent way that
might simply need to expand the capabilites of "absolute".


The feature in itself is platform independent.

The only catch is that in pdecvar.pas (where variable declaration is
handled) there's a per platform hook for each symbol type, in order to
allow for special handling of some features.
For consistency I did follow the same rule, which is used for all the other
declarations, disregarding whether they're platform independent or not.
As a consequence, for each supported platform you must add in its specific
symcpu.pas a type entry:

tcpubasedvarsym = class(tbasedvarsym)
end;
tcpubasedvarsymclass = class of tcpubasedvarsym;

and a line of code:

  cbasedvarsym:=tcpubasedvarsym;

As this is tedious, I've only done it for the platform I'm using
(x86_64/symcpu.pas). To deploy the feature, the same lines must be added in
each platform symcpu.pas unit. There's no more that that.


No matter the syntax that might be chosen for this it will likely be
sufficient to handle that feature by an absolutevarsym with a boolean flag
or something like that. The difference to an ordinary absolute variable
appears to be too small to warrant a new sym type.



- It should be decided if internal error # which currently keep the same
number of the nearby ABSOLUTE internal error should be given new values.

Internal errors shall always be unique as they are used to find the error
location, even for copy pasted code.


What's the rule to avoiding clashes? I gathered sort of MMDD## is it
correct?


Correct.

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

Re: [fpc-devel] An extension of fpc language: the BASED construct

[jn]

Hello folks,

As described on my site 
programming.sirrida.de/pascal_proposals.html#offset I would propose a 
slightly more general approach to the theme. In contrast to the 
presented solution my offsets are separated from the base pointer.


Calculations with offsets, e.g.:
TYPE
  tr_rec = RECORD
a,b: integer;
END;
VAR
  v: tr_rec;
  o: OFFSET tr_rec OF integer;
BEGIN
  o := OFFSET(tr_rec,a);
  v.[o] := v.b;
  ...
  END.

An probably better alternative syntax for "OFFSET(tr_rec,a)" could be 
"tr_rec @ a" thereby overloading the address operator without using a 
new keyword.
The symbol pair ".[" denotes access "at offset" and should be applicable 
on records, objects, classes and arrays. This allows fields to be 
addressed similar to array elements. It might help to speed up multiple 
array accesses because the multiplication can happen earlier. In the 
implementation in assembler the offset is simply added to the base 
address. In contrast to general offsets, these specialized offsets can 
not be added, subtracted or even scaled.

The WITH statement could be enhanced to handle offsets as well.
You may emulate the functionality as follows:
TYPE
  tp_int = ^integer;
  ta_8u = ARRAY [0..maxint] OF byte;
  tpa_8u = ^ta_8u;
  tpr_rec = ^tr_rec;
VAR
  v: tr_rec;
  o: integer;
BEGIN
  o := integer(@tpr_rec(nil)^.a);  // o := OFFSET(tr_rec,a);
  tp_int(@tpa_8u(@v)^[o])^ := v.b;  // v.[o] := v.b;
  …
  END.
As you see, there are some nasty things necessary for the emulation: We 
assume that nil is zero and we use a cast from pointer to integer, and 
there are some more castings. An alternative approach using "extended 
syntax" (pointer arithmetic) is a little better. My proposal however is 
clean and type-safe and does not need any castings.
The ARRAY [0..maxint] is an example of a substitute of a half open array 
definition.


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

Re: [fpc-devel] An extension of fpc language: the BASED construct

[Mark Morgan Lloyd]

On 26/12/17 23:15, Giuliano Colla wrote:
Il 26/12/2017 14:27, Mark Morgan Lloyd ha scritto:> What does gdb (and 
possibly other debuggers) make of this? What currently gdb tells (and 
any other debugger would tell) is :

No symbol "Item" in current context.
Once the appropriate entries are implemented in the debugger symbol 
table, it will behave like it does in similar conditions, i.e. 
displaying a value referenced by a pointer. I didn't mention in my ToDo 
list because I'm a bit lazy, but this too has to be done.


I'm getting uncomfortable with the amount of "magic" required here.

Is it really 
appropriate to declare Item as a variable, when it's > really more akin 
to a macro? It's not different from the declarations:

myString: string;myObject: TObject;
where your declaration only reserves a pointer, while the actual string 
or object will be instantiated only at run time.
Item is a variable, whose location isn't known at compile time, but will 
be known only at run time.


Except that you've already said above that "Item" doesn't actually 
exist, while "myString" does even if the compiler etc. knows that it's 
to be implicitly dereferenced.


I'd suggest that this would be better approached either as a 
generalisation of managed types- strings and the rest, or as a final 
resolution of the "with" controversy including full consideration of the 
scope issues.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel