Re: [fpc-devel] Unicode paths

[Martin Schreiber]

On Tuesday 12 April 2016 18:46:15 Marco van de Voort wrote:
>
> Anyway, I never liked the fact that argv and argc are exported symbols. If
> they weren't public, we could change them at will and/or have differing
> implementations and encodings depending on target.  I would deprecate them
> (being public)
>
Is there a possibility to still get the raw data in case one wants to handle 
encoding himself?

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Thorsten Engler]

Sven Barth wrote:
> In that specific example you would be right, but units are seldomly used
in
> isolation and once both unit1 and unit2 are used in more units it isn't
that
> clear (to the user) anymore which unit is initialized first.

I've always found the rules about this very clear in Delphi (and I assumed
so far it applies to FPC as well):

If your unit depends on another unit being initialized before and finalized
after your unit, then that other unit must be listed in the interface uses
clause.

Units in the implementation uses clause may initialize before or after your
unit, and the order may change in the future depending on the contents of
other units in the project. But all units in the interface section are
guaranteed to have been initialized before your unit and are guaranteed to
finalize after your unit.

So if you depend on another unit being initialized first, list it in the
interface section. If you can't because of circular references, then your
code is broken and what you want to do is impossible.

Delphi ensures this is true, even when dynamically loaded packages come into
play, by essentially creating the following code for each unit behind the
scenes:

Unit ThisUnit;

Interface

Uses
  InterfaceUsedUnit1,
  InterfaceUsedUnit2;

//...

Procedure AddRef;
Procedure Release;

Implementation

Uses
  ImplementationUsedUnit;

Procedure Init;
Begin
  InterfaceUsedUnit1.AddRef;
  InterfaceUsedUnit2.AddRef;
  ImplementationUsedUnit.AddRef;
  //.. code from original initialization section goes here
End;

Procedure Done;
Begin 
  //.. code from original finalization section goes here
  ImplementationUsedUnit.Release;
  InterfaceUsedUnit2.Release;
  InterfaceUsedUnit1.Release;
End;

Var
  RefCount: Integer;

Procedure AddRef;
Begin
  If LockedInc(RefCount) = 1 then
Init; 
End;

Procedure Release;
Begin
  If LockedDec(RefCount) = 0 then
Done;
End;

Initialization
  AddRef;
Finalization
  Release;
End.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Jonas Maebe]

Sven Barth wrote:

Functions that use such global variables could have a flag added which
gets added recursively and thus we could warn in the initialization
sections if such routines are used nevertheless.


This is not desirable, because then you need to modify the interface 
information for such routines after their implementation gets parsed. 
Even if you do that, it's not possible, because
a) in case of circular dependencies, the implementation of unit1, which 
uses such a routine from the interface of unit2, may already be compiled 
by the time you set that flag

b) procedure variables


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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Sven Barth]

On 12.04.2016 21:12, Florian Klämpfl wrote:
> Am 12.04.2016 um 08:57 schrieb Maciej Izak:
>> 2016-04-11 23:36 GMT+02:00 Sven Barth > >:
>>
>> I know this is a rather constructed example, but it's similar to the C++
>> code we had at work, so it's code that can happen in the real world.
>> If we don't find a way to solve this problem then I'm afraid that I
>> won't include your changes in trunk, cause I don't want to open that can
>> of worms.
>>
>>
>> E? I am a little shocked by your arguments because that kind of bug is 
>> possible since we have
>> initialization/finalization section and uses section in 
>> interface/implementation section. *The
>> programmer must be aware of*. The mentioned bugs are here a looong time. For 
>> example fixed by me for
>> Lazarus:
>> http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=lazarus=date=49547
>>
> 
> I agree with Maciej here: this kind of stuff can also happen with normal 
> initialization code and
> uses of units in the implementation part. In this case the programmer must 
> simply be very careful.
> Though in your example I think unit1 is always initialized first as it does 
> not depend on unit2. The
> problem might pop up though if you use unit2 in the implementation part of 
> unit1.

In that specific example you would be right, but units are seldomly used
in isolation and once both unit1 and unit2 are used in more units it
isn't that clear (to the user) anymore which unit is initialized first.
As I wrote in another mail a good solution would probably be for these
kind of global variables to be initialized after all initialization
sections have run and to have that documented like that. This way we
avoid adding *another* potential pitfall with unit initializations.
Functions that use such global variables could have a flag added which
gets added recursively and thus we could warn in the initialization
sections if such routines are used nevertheless.
The latter could be also done in case we indeed don't do anything
special with these records. This way the user would at least be warned...

Regards,
Sven

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

Re: [fpc-devel] Management operators AddRef and Copy vs Copy

[Florian Klämpfl]

Am 10.04.2016 um 18:53 schrieb Maciej Izak:
> 2016-04-10 14:45 GMT+02:00 Florian Klämpfl  >:
> 
> I think this is the wrong way:
> - AddRef means only to increase the ref. count of the passed data 
> structure
> - Copy is no deep copy, it means only: copy the current data structure, 
> if it references managed
> types, their ref. count is increased but they are not copied
> 
> Example with dyn. arrays:
> - AddRef increases the ref. count of the passed array, not its members
> - Copy creates a copy of the array, if the members of the array are 
> managed, their ref. count is
> increased
> 
> So I would call the operator Copy, in case of custom implemented ref. 
> counted records, this would be
> an AddRef operation. For a real copy, a procedure like Clone should be 
> declared.
> 
> 
> Proposed implementation is compatible with internal rtti.inc usage 
> (FPC_ADDREF and FPC_COPY). In my
> example I mean dyn array of records and related usage of operators only in 
> context of items of those
> array.
> 
> Important note:
> operator Initialize is called after system int_initialize for required record 
> fields
> operator Finalize is called before system int_finalize for required record 
> fields
> operator AddRef is called after int_addref for required fields
> operator Copy is called after fpc_Copy_internal for required fields
> 
> note for note:
> in current FPC implementation int_initialize = FPC_INITIALIZE, int_finalize = 
> FPC_FINALIZE,
> int_addref = FPC_ADDREF, fpc_Copy_internal = FPC_COPY
> 
> Let me explain this with complex example:
> 
> === code begin ===
> type
>   TFoo = record // record with all management operators. Existence of 
> management operators means
> that the record became managed
>   public
> {... some field definitions ...  }
>   private
> class operator Initialize(var aFoo: TFoo);
> class operator Finalize(var aFoo: TFoo);
> class operator AddRef(var aFoo: TFoo);
> class operator Copy(constref aSrc: TFoo; var aDst: TFoo);
>   end;
> 
> procedure TestValue(Value: TFoo); begin end;
> procedure TestVar(var Value: TFoo); begin end;
> procedure TestConst(const Value: TFoo); begin end;
> procedure TestOut(out Value: TFoo); begin end;
> procedure TestConstref(constref Value: TFoo); begin end;
> 
>   TFooArray = array of TFoo;
> 
> var
>   Foos: TFooArray;
>   Foos2: TFooArray;
> begin
>   SetLength(Foos, 5); // call 5x FPC_INITIALIZE and 5x TFoo.Initialize
>   SetLength(Foos, 6); // call 1x FPC_INITIALIZE and 1x TFoo.Initialize
>   SetLength(Foos, 5); // call 1x FPC_FINALIZE and 1x TFoo.Finalize
>   Foos2 := Copy(Foos); // call 5x FPC_ADDREF and 5x TFoo.AddRef
>   Foos2[0] := Foos[1]; // call 1x FPC_COPY and 1x TFoo.Copy
> 
>   // call 1x FPC_ADDREF and 1x TFoo.AddRef
>   TestValue(Foos2[1]);
>   // call 1x FPC_FINALIZE and 1x TFoo.Finalize
> 
>   // ... none
>   TestVar(Foos2[1]);
>   // ... none
> 
>   // ... none
>   TestConst(Foos2[1]);
>   // ... none
> 
>   // call 1x FPC_FINALIZE and 1x TFoo.Finalize
>   // call 1x FPC_INITIALIZE and 1x TFoo.Initialize
>   TestOut(Foos2[1]);
>   // ... none
> 
>   // ... none
>   TestConstref(Foos2[1]);
>   // ... none
> 
> end;  // call 10x FPC_FINALIZE and 10x TFoo.Finalize (for Foos and Foos2)
> === code end ===

Besides the naming, looks good to me.

> 
> As far as I understand your proposal is to use TFoo.Clone instead of  
> TFoo.Copy and TFoo.Copy
> instead of TFoo.AddRef. That is correct?

Yes. Maybe we have to do some more research what appropriate names are, the 
names in system.pp are
historic.

> IMO a little confusing from system.pp point of view ;)
> 

Yes. Addref is IMO something which is implementation specific and should not be 
exposed. C++ does
not know natively (!) ref. counted types. Instead the copy constructor does the 
ref. counting and a
separate method normally does the deep copy. So the question arises imo if the 
deep copy deserves an
own operator.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Florian Klämpfl]

Am 12.04.2016 um 08:57 schrieb Maciej Izak:
> 2016-04-11 23:36 GMT+02:00 Sven Barth  >:
> 
> I know this is a rather constructed example, but it's similar to the C++
> code we had at work, so it's code that can happen in the real world.
> If we don't find a way to solve this problem then I'm afraid that I
> won't include your changes in trunk, cause I don't want to open that can
> of worms.
> 
> 
> E? I am a little shocked by your arguments because that kind of bug is 
> possible since we have
> initialization/finalization section and uses section in 
> interface/implementation section. *The
> programmer must be aware of*. The mentioned bugs are here a looong time. For 
> example fixed by me for
> Lazarus:
> http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=lazarus=date=49547
> 

I agree with Maciej here: this kind of stuff can also happen with normal 
initialization code and
uses of units in the implementation part. In this case the programmer must 
simply be very careful.
Though in your example I think unit1 is always initialized first as it does not 
depend on unit2. The
problem might pop up though if you use unit2 in the implementation part of 
unit1.

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

Re: [fpc-devel] Unicode paths

[Sven Barth]

Am 12.04.2016 18:46 schrieb "Marco van de Voort" :
>
> In our previous episode, Michael Van Canneyt said:
> > >> If argv/argc is known to be UTF8 encoded, then I see no problem with
> > >> keeping getopts ?
> > >
> > > Getopts is not utf8 but shortstring, so ACS on Windows. Or do you
plan to
> > > redo it using utf8string or unicodestring?
> >
> > I don't necessarily plan to do so, I was proposing it as a way out.
>
> If getopts is not leading, then the needs of the unicode
T(Custom)Application
> classes is probably the best indicator for which way to go.
>
> If they don't need argv and argc, just leave them as they are.
>
> Anyway, I never liked the fact that argv and argc are exported symbols. If
> they weren't public, we could change them at will and/or have differing
> implementations and encodings depending on target.  I would deprecate them
> (being public)

Agreed. They are only exported for ObjPas and that can be solved in the
same way as other symbols uses there are solved.

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

Re: [fpc-devel] Unicode paths

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
> >> If argv/argc is known to be UTF8 encoded, then I see no problem with
> >> keeping getopts ?
> >
> > Getopts is not utf8 but shortstring, so ACS on Windows. Or do you plan to
> > redo it using utf8string or unicodestring?
> 
> I don't necessarily plan to do so, I was proposing it as a way out.

If getopts is not leading, then the needs of the unicode T(Custom)Application
classes is probably the best indicator for which way to go.

If they don't need argv and argc, just leave them as they are.

Anyway, I never liked the fact that argv and argc are exported symbols. If
they weren't public, we could change them at will and/or have differing
implementations and encodings depending on target.  I would deprecate them
(being public)

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Sven Barth]

Am 12.04.2016 14:58 schrieb "Maciej Izak" :
>>
>> > Note: these attributes are on my TODO list.
>>
>> Please don't do anything attribute related until I've merged Joost's
class attributes branch which lays the foundations for the attributes. I've
planned this for after the reintegration of my dynamic packages branch
which is currently WIP (the merge, not the branch ;) )
>
> IIRC the branch is incomplete (for example RTTI in early stage and for
example TValue need to be improved). Extending these branch is also on my
TODO. :) Maybe the only target of mentioned branch is to allow attributes
of classes (which has no much sense without Invoke method and extended RTTI
- and that is absolutely unimplemented).

Attributes are implemented differentlybin FPC than in Delphi. In FPC a
constructor routine is created which calls the attribute class'
constructor. This in turn is what's provided in the RTTI (don't know
whether the parameters are currently provided as well, but they shouldn't
be needed anyway with that approach). This has the added benefit that
attributes don't need a working Invoke() implementation on each and every
platform (which is an important point for a cross platform compiler like
FPC).
Also I'm aware that the branch currently only allows class attributes, but
that should be the least problematic part to extend.
So just let me reintegrate the code and we can work from there.

>> That together with your suggestion to force this attribute for records
with management operators might indeed be useful, but there are some
problems... (see below)
>>
>> > ...
>>
>> The system unit's initialization *must* be run first, otherwise you
won't have a heap or synchronisation primitives or whatever you might need.
That then also extends to units like heaptrc, cmem, cthreads, etc.
>>
>> Maybe it would be better to initialize such records always *after* *all*
initialization sections have been run... :/ (and deinitialized first)
>
> Maybe "run" for my idea is a bad word. We don't need to run any section
before initialization section from system. What we need is the table/list
with "fixed" variables which needs to be initialized in system.pp
initialization (and finalized in finalization). I think that is doable.

It doesn't matter. You need to run the initializer operators and these
might rely on functionality that is not initialized yet. So the safest
approach would definitely be to init these after all initialization
sections and to document this and the reasons behind it. This also
alleviates the need to use attributes for this (or a keyword or whatever).

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Sven Barth]

Am 12.04.2016 16:12 schrieb "Dimitrios Chr. Ioannidis" <
d.ioanni...@nephelae.eu>:
>
> Στις 2016-04-12 16:31, Maciej Izak έγραψε:
>>
>> 2016-04-12 14:48 GMT+02:00 Michael Van Canneyt
>> :
>>
>>> I really don't think you should delegate such things to attributes.
>>> You make 2 completely unrelated language constructs suddenly
>>> related. A bad design decision.
>>
>>
>> I think you are wrong. Attributes are not only dedicated to RTTI just
>> look at other languages: Delphi, C#, Java. Instead of extending
>> language into infinity you can use simple attribute with parameter. I
>> don't see any reason why don't use attributes to describe some
>> compiler/RTL behavior? Any attribute can be easier placed in many
>> language structures without breaking language syntax. That is much
>> harder with new keywords.
>
>
> Just my 2 ...
>
>  AFAIU, attributes in Delphi are ignorable ( ... Attributes do not modify
the behavior of types or members by themselves. The consumer code must
specifically query for their existence and take appropriate actions when
this is required ... ).
>
>  IMO attributes that aren't ignorable aren't really attributes in the
narrow sense, they're just keywords in disguise.

I agree, that's why I also don't like the use of attributes for this. The
question is how Delphi compatible do we want to be? (I personally wouldn't
mind not achieving compatibility for this)

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

Re: [fpc-devel] FPC 3.0.2 release target

[Luiz Americo Pereira Camara]

2016-04-12 5:03 GMT-03:00 Marco van de Voort :

> In our previous episode, Michael Van Canneyt said:
> >
> > I also think so, we've already been merging the necessary fixes to
> > fixes_3_x
>
> For people that missed this hint: PLEASE retest your issues with the fixes
>

Fixes branch is missing packages/googleapi

When asked previously there was no technical reason to not ship it

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Dimitrios Chr. Ioannidis]

Στις 2016-04-12 16:31, Maciej Izak έγραψε:

2016-04-12 14:48 GMT+02:00 Michael Van Canneyt
:


I really don't think you should delegate such things to attributes.
You make 2 completely unrelated language constructs suddenly
related. A bad design decision.


I think you are wrong. Attributes are not only dedicated to RTTI just
look at other languages: Delphi, C#, Java. Instead of extending
language into infinity you can use simple attribute with parameter. I
don't see any reason why don't use attributes to describe some
compiler/RTL behavior? Any attribute can be easier placed in many
language structures without breaking language syntax. That is much
harder with new keywords.


Just my 2 ...

 AFAIU, attributes in Delphi are ignorable ( ... Attributes do not 
modify the behavior of types or members by themselves. The consumer code 
must specifically query for their existence and take appropriate actions 
when this is required ... ).


 IMO attributes that aren't ignorable aren't really attributes in the 
narrow sense, they're just keywords in disguise.


regards,

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 15:33 GMT+02:00 Michael Van Canneyt :


Quite strange, Joost claimed the exact opposite :-)



Maybe different approach than in Delphi, or I miss something. But as far as
I can see, there is something like that:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/joost/classattributes/tests/test/tclassattribute4.pp?view=markup=date


I don't think Joost planned to support the same low-level API as delphi.

I remember discussions about that, but this is meanwhile some years ago.
The best source of information is still Joost.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 15:33 GMT+02:00 Michael Van Canneyt :

> Quite strange, Joost claimed the exact opposite :-)


Maybe different approach than in Delphi, or I miss something. But as far as
I can see, there is something like that:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/joost/classattributes/tests/test/tclassattribute4.pp?view=markup=date

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 14:48 GMT+02:00 Michael Van Canneyt :

> I really don't think you should delegate such things to attributes. You
> make 2 completely unrelated language constructs suddenly related. A bad
> design decision.


I think you are wrong. Attributes are not only dedicated to RTTI just look
at other languages: Delphi, C#, Java. Instead of extending language into
infinity you can use simple attribute with parameter. I don't see any
reason why don't use attributes to describe some compiler/RTL behavior? Any
attribute can be easier placed in many language structures without breaking
language syntax. That is much harder with new keywords.

Maybe that is not ideal but works excellent.
-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 14:48 GMT+02:00 Michael Van Canneyt :


I really don't think you should delegate such things to attributes. You
make 2 completely unrelated language constructs suddenly related. A bad
design decision.



I think you are wrong. Attributes are not only dedicated to RTTI just look
at other languages: Delphi, C#, Java. Instead of extending language into
infinity you can use simple attribute with parameter. I don't see any
reason why don't use attributes to describe some compiler/RTL behavior? Any
attribute can be easier placed in many language structures without breaking
language syntax. That is much harder with new keywords.

Maybe that is not ideal but works excellent.


Nono.

You deviate from an important design principle: orthogonality.

By linking 2 concepts, any change in 1 concept risks to influence the other.
This is ALWAYS bad. If you implement things orthogonally, a change in 1
concept does not risk influencing the other.

So you will really, really have to provide better arguments than 'but works 
excellent'.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 15:06 GMT+02:00 Michael Van Canneyt :


Attributes do not need Invoke ?



Of course they need Invoke. When
TRttiContext.GetType(TMyClassWithAttributes) is executed, deep inside
GetType is executed constructor for each attribute by Invoke. IMO mentioned
branch is far far from "ready to merge".


Quite strange, Joost claimed the exact opposite :-)



Maybe you thinking about attributes just as simple flags/marks without
constructors (not parameterized attributes), then you are right.


Yes. AFAIK this is what Joost had in mind. Maybe he used some trick to
parametrize, because AFAIK he needed/used it to implement a ORM
architecture; He used the attributes to specify in which DB field a
particular property needed to be stored.

But better ask Joost directly.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 15:06 GMT+02:00 Michael Van Canneyt :

> Attributes do not need Invoke ?


Of course they need Invoke. When
TRttiContext.GetType(TMyClassWithAttributes) is executed, deep inside
GetType is executed constructor for each attribute by Invoke. IMO mentioned
branch is far far from "ready to merge".

Maybe you thinking about attributes just as simple flags/marks without
constructors (not parameterized attributes), then you are right.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Maciej Izak wrote:


2016-04-12 14:33 GMT+02:00 Sven Barth :


[Note: this is less a "I don't want it", but a "I don't like it"]

phew!



Note: these attributes are on my TODO list.


Please don't do anything attribute related until I've merged Joost's class
attributes branch which lays the foundations for the attributes. I've
planned this for after the reintegration of my dynamic packages branch
which is currently WIP (the merge, not the branch ;) )


IIRC the branch is incomplete (for example RTTI in early stage and for
example TValue need to be improved). Extending these branch is also on my
TODO. :) Maybe the only target of mentioned branch is to allow attributes
of classes (which has no much sense without Invoke method and extended RTTI
- and that is absolutely unimplemented).


Attributes do not need Invoke ?

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 14:33 GMT+02:00 Sven Barth :

> [Note: this is less a "I don't want it", but a "I don't like it"]
>
> phew!

> > Note: these attributes are on my TODO list.
>
> Please don't do anything attribute related until I've merged Joost's class
> attributes branch which lays the foundations for the attributes. I've
> planned this for after the reintegration of my dynamic packages branch
> which is currently WIP (the merge, not the branch ;) )
>
IIRC the branch is incomplete (for example RTTI in early stage and for
example TValue need to be improved). Extending these branch is also on my
TODO. :) Maybe the only target of mentioned branch is to allow attributes
of classes (which has no much sense without Invoke method and extended RTTI
- and that is absolutely unimplemented).

> That together with your suggestion to force this attribute for records
> with management operators might indeed be useful, but there are some
> problems... (see below)
>
> > ...
>
> The system unit's initialization *must* be run first, otherwise you won't
> have a heap or synchronisation primitives or whatever you might need. That
> then also extends to units like heaptrc, cmem, cthreads, etc.
>
> Maybe it would be better to initialize such records always *after* *all*
> initialization sections have been run... :/ (and deinitialized first)
>
Maybe "run" for my idea is a bad word. We don't need to run any section
before initialization section from system. What we need is the table/list
with "fixed" variables which needs to be initialized in system.pp
initialization (and finalized in finalization). I think that is doable.
-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Sven Barth wrote:


Am 12.04.2016 12:01 schrieb "Maciej Izak" :


another way is to introduce attributes for selected language elements in

Delphi compatible way. For example in Delphi we have:


  TCustomAttribute = class(TObject)
  end;
  WeakAttribute = class(TCustomAttribute);
  UnsafeAttribute = class(TCustomAttribute);
  RefAttribute = class(TCustomAttribute);
  VolatileAttribute = class(TCustomAttribute);


What I don't like about such a usage of attributes (aside from the syntax,
but that's an orthogonal problem) is that the compiler needs to be made
aware of each and every special attribute... (yes, it also needs to support
each keyword, but in the case of keywords it doesn't have to be somehow
defined in some units as well)
[Note: this is less a "I don't want it", but a "I don't like it"]


I really don't think you should delegate such things to attributes. 
You make 2 completely unrelated language constructs suddenly related. 
A bad design decision.


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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Sven Barth]

Am 12.04.2016 12:01 schrieb "Maciej Izak" :
>
> another way is to introduce attributes for selected language elements in
Delphi compatible way. For example in Delphi we have:
>
>   TCustomAttribute = class(TObject)
>   end;
>   WeakAttribute = class(TCustomAttribute);
>   UnsafeAttribute = class(TCustomAttribute);
>   RefAttribute = class(TCustomAttribute);
>   VolatileAttribute = class(TCustomAttribute);

What I don't like about such a usage of attributes (aside from the syntax,
but that's an orthogonal problem) is that the compiler needs to be made
aware of each and every special attribute... (yes, it also needs to support
each keyword, but in the case of keywords it doesn't have to be somehow
defined in some units as well)
[Note: this is less a "I don't want it", but a "I don't like it"]

>
> Note: these attributes are on my TODO list.

Please don't do anything attribute related until I've merged Joost's class
attributes branch which lays the foundations for the attributes. I've
planned this for after the reintegration of my dynamic packages branch
which is currently WIP (the merge, not the branch ;) )

> To protect our management operators we should declare in System.pp:
>
>   FixedAttribute = class(TCustomAttribute); // or
SystemInitializedAttribute
>
> Now the gSomething from example is declared as:
>
> var
>   [Fixed] gSomething: TSomeType; // fixed can be used only for global
variables and for class var/{$J+} const (aka static var)

That together with your suggestion to force this attribute for records with
management operators might indeed be useful, but there are some problems...
(see below)

> ... that means "don't' [Initialize|Finalize|FillChar|Whatever] this
variable from module but from System.pp (in special table in initialization
section)". Any module may contain special hidden section (if [Fixed]
attribute is detected); that will register all global variables declared
with [Fixed] and any variable with [Fixed] will be excluded from standard
initialization/finalization process. That special all "Fixed Sections" from
all modules should be called before any other initialize/finalize to
register all variables (and before system initialize section ofc, where all
registered fixed variables shall be initialized, and after all ofc
finalized).

The system unit's initialization *must* be run first, otherwise you won't
have a heap or synchronisation primitives or whatever you might need. That
then also extends to units like heaptrc, cmem, cthreads, etc.

Maybe it would be better to initialize such records always *after* *all*
initialization sections have been run... :/ (and deinitialized first)

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

Re: [fpc-devel] Unicode paths

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Marco van de Voort wrote:


In our previous episode, Michael Van Canneyt said:

I guess the only way, as always, is to have two duplicate systems on
windows.  One wide that is for unicode, (unicodestring paramstr and
D2009 compatible tapplication), one for old legacy ansi apps. (getopts etc).



If argv/argc is known to be UTF8 encoded, then I see no problem with
keeping getopts ?


Getopts is not utf8 but shortstring, so ACS on Windows. Or do you plan to
redo it using utf8string or unicodestring?


I don't necessarily plan to do so, I was proposing it as a way out.

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

Re: [fpc-devel] Unicode paths

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
> > I guess the only way, as always, is to have two duplicate systems on
> > windows.  One wide that is for unicode, (unicodestring paramstr and
> > D2009 compatible tapplication), one for old legacy ansi apps. (getopts etc).
 
> If argv/argc is known to be UTF8 encoded, then I see no problem with
> keeping getopts ?

Getopts is not utf8 but shortstring, so ACS on Windows. Or do you plan to
redo it using utf8string or unicodestring?


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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 11:17 GMT+02:00 Sven Barth :

> One possible solution would be to disallow records with management
> operators for global variables (variables created for Default() might be an
> exception here, but I'd need to think that through).
>
Maybe for global variables with management operators is good to force usage
of [Fixed] / [NonFixed] attribute. NonFixed is not described in my previous
messages. It can be used only to force programmer attention (has no real
effect, it only pass these kind of variable in compilation process).

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 12:12 GMT+02:00 Maciej Izak :

> 2016-04-12 12:01 GMT+02:00 Maciej Izak :
>
>> To protect our management operators we should declare in System.pp:
>>
>>   FixedAttribute = class(TCustomAttribute); // or
>> SystemInitializedAttribute
>>
>> Now the gSomething from example is declared as:
>>
>> var
>>   [Fixed] gSomething: TSomeType; // fixed can be used only for global
>> variables and for class var/{$J+} const (aka static var)
>>
>
> Of course is still possible to obtain the error, but to achieve this you
> need to really crave this.
>

To to enable the complicated dependencies is possible to allow priority
parameter for Fixed attribute:

  FixedAttribute = class(TCustomAttribute)
constructor Create(aPriority: Integer = 2000); // can be default set to
2000
  end;

... some module A ...

 var
  [Fixed] gFoo: TSomeType; // default priority is 2000
  [Fixed(10)] gSomething: TSomeType; // lower number means higher priority,
for example, first 1000 can be reserved for internal FPC usage


... somewhere in other module B, gSomething2 has Initialize operator, where
gSomething is used for something...

var
  [Fixed(100)] gSomething2: TSomeType; // has lower priority and will be
initialized after gSomething and finalized before gSomething

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 12:01 GMT+02:00 Maciej Izak :

> To protect our management operators we should declare in System.pp:
>
>   FixedAttribute = class(TCustomAttribute); // or
> SystemInitializedAttribute
>
> Now the gSomething from example is declared as:
>
> var
>   [Fixed] gSomething: TSomeType; // fixed can be used only for global
> variables and for class var/{$J+} const (aka static var)
>

Of course is still possible to obtain the error, but to achieve this you
need to really crave this.
-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-12 11:21 GMT+02:00 Sven Barth :

> > That might be, but this just adds a new category of possibilities for
> such bugs and that is something that we should not do, especially one as
> subtle as this.
> >
> > One possible solution would be to disallow records with management
> operators for global variables (variables created for Default() might be an
> exception here, but I'd need to think that through).
>
> Another possibility I just thought of: have the compiler analyse such
> inter unit dependencies in the initialization sections (yes, I know, easier
> said than done) and print a warning in case something might depend on the
> order of execution.
> If the user is at least aware that there might be something fishy going on
> then I'm more lenient.
>

another way is to introduce attributes for selected language elements in
Delphi compatible way. For example in Delphi we have:

  TCustomAttribute = class(TObject)
  end;
  WeakAttribute = class(TCustomAttribute);
  UnsafeAttribute = class(TCustomAttribute);
  RefAttribute = class(TCustomAttribute);
  VolatileAttribute = class(TCustomAttribute);

which is used like this:

procedure Foo([ref] const X: TFoo); // FPC equivalent is procedure
Foo(constref X: TFoo);

or like this for TObject field for ref. count for ARC:

[Volatile] FRefCount: Integer;

Note: these attributes are on my TODO list.

To protect our management operators we should declare in System.pp:

  FixedAttribute = class(TCustomAttribute); // or SystemInitializedAttribute

Now the gSomething from example is declared as:

var
  [Fixed] gSomething: TSomeType; // fixed can be used only for global
variables and for class var/{$J+} const (aka static var)

... that means "don't' [Initialize|Finalize|FillChar|Whatever] this
variable from module but from System.pp (in special table in initialization
section)". Any module may contain special hidden section (if [Fixed]
attribute is detected); that will register all global variables declared
with [Fixed] and any variable with [Fixed] will be excluded from standard
initialization/finalization process. That special all "Fixed Sections" from
all modules should be called before any other initialize/finalize to
register all variables (and before system initialize section ofc, where all
registered fixed variables shall be initialized, and after all ofc
finalized).

That approach is also usefully to fix existing problems with
initialize/finalize (!)

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Sven Barth]

Am 12.04.2016 11:17 schrieb "Sven Barth" :
>
> Am 12.04.2016 08:57 schrieb "Maciej Izak" :
> >
> > 2016-04-11 23:36 GMT+02:00 Sven Barth :
> >>
> >> I know this is a rather constructed example, but it's similar to the
C++
> >> code we had at work, so it's code that can happen in the real world.
> >> If we don't find a way to solve this problem then I'm afraid that I
> >> won't include your changes in trunk, cause I don't want to open that
can
> >> of worms.
> >
> >
> > E? I am a little shocked by your arguments because that kind of bug
is possible since we have initialization/finalization section and uses
section in interface/implementation section. *The programmer must be aware
of*. The mentioned bugs are here a looong time. For example fixed by me for
Lazarus:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=lazarus=date=49547
> >
>
> That might be, but this just adds a new category of possibilities for
such bugs and that is something that we should not do, especially one as
subtle as this.
>
> One possible solution would be to disallow records with management
operators for global variables (variables created for Default() might be an
exception here, but I'd need to think that through).

Another possibility I just thought of: have the compiler analyse such inter
unit dependencies in the initialization sections (yes, I know, easier said
than done) and print a warning in case something might depend on the order
of execution.
If the user is at least aware that there might be something fishy going on
then I'm more lenient.

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Sven Barth]

Am 12.04.2016 08:57 schrieb "Maciej Izak" :
>
> 2016-04-11 23:36 GMT+02:00 Sven Barth :
>>
>> I know this is a rather constructed example, but it's similar to the C++
>> code we had at work, so it's code that can happen in the real world.
>> If we don't find a way to solve this problem then I'm afraid that I
>> won't include your changes in trunk, cause I don't want to open that can
>> of worms.
>
>
> E? I am a little shocked by your arguments because that kind of bug
is possible since we have initialization/finalization section and uses
section in interface/implementation section. *The programmer must be aware
of*. The mentioned bugs are here a looong time. For example fixed by me for
Lazarus:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=lazarus=date=49547
>

That might be, but this just adds a new category of possibilities for such
bugs and that is something that we should not do, especially one as subtle
as this.

One possible solution would be to disallow records with management
operators for global variables (variables created for Default() might be an
exception here, but I'd need to think that through).

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

Re: [fpc-devel] Unicode paths

[Michael Van Canneyt]

On Tue, 12 Apr 2016, Marco van de Voort wrote:


In our previous episode, Jonas Maebe said:

They are not supported, because we get the original command line data
using the ansi version of the API call (see setup_arguments() in
rtl/win/syswin.inc). If this is "fixed", then we also have to decide
what to do with the argv p(ansi)char (a good place would be to check
what Windows itself returns from the ansi API call when passing command
line arguments that contain characters that cannot be represented in the
ansi code page.


The central place of posix argv/argc in the command processing (including
getopts), also on nonposix systems is indeed a bit of a problem.

I guess the only way, as always, is to have two duplicate systems on
windows.  One wide that is for unicode, (unicodestring paramstr and
D2009 compatible tapplication), one for old legacy ansi apps. (getopts etc).



If argv/argc is known to be UTF8 encoded, then I see no problem with keeping 
getopts ?


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

Re: [fpc-devel] FPC 3.0.2 release target

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
> 
> I also think so, we've already been merging the necessary fixes to
> fixes_3_x

For people that missed this hint: PLEASE retest your issues with the fixes
branch (3.0.1), specially if your problems were mostly library in nature.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.2 release target

[Michael Van Canneyt]

On Mon, 11 Apr 2016, Ondrej Pokorny wrote:


What are the plans on releasing 3.0.2?
We'd like to release Lazarus 1.6.2 - it would be good if it was released with 
FPC 3.0.2 because of the Currency bug.


I also think so, we've already been merging the necessary fixes to fixes_3_x

Now we need someone to volunteer to be buildmaster.
I will ask the previous buildmaster if he is game... :-)

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

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

[Maciej Izak]

2016-04-11 23:36 GMT+02:00 Sven Barth :

> I know this is a rather constructed example, but it's similar to the C++
> code we had at work, so it's code that can happen in the real world.
> If we don't find a way to solve this problem then I'm afraid that I
> won't include your changes in trunk, cause I don't want to open that can
> of worms.
>

E? I am a little shocked by your arguments because that kind of bug is
possible since we have initialization/finalization section and uses section
in interface/implementation section. *The programmer must be aware of*. The
mentioned bugs are here a looong time. For example fixed by me for Lazarus:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=lazarus=date=49547

The reason of memory leak in mentioned rev was the same as presented by
your example but in context of initialization/finalization. It was raised
in Lazarus in random cases (installed packages combination).

Pascal was never safe language because we have ASM, Pointers and other
stuff. The pros is much more than cons for management operators
(SmartPointer + Generics.Collections is awesome and big step forward).
Management operators is powerfully syntax and I don't want to drop them
because it is base for my next improvements. No one is forced to using
management operators. You are killing the whole tree. It is like atom
power. You can create nuclear weapon to kill, but you can use that power to
build nuclear power plant.

Seems like my existence here on mailing list and branches has no sense. I
will drop my branches here and move my work to github. What is the sense
working here if all work is rejected?

My github branch will be often synchronized with core trunk. Anyway good
luck and thanks for "maciej" branch! :)
-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel