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

Am 13.04.2016 03:38 schrieb "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.

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

Am 12.04.2016 23:54 schrieb "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, beca

Re: [fpc-devel] Unicode paths

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

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

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

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

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 suc

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

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 tha

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

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

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

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

Re: [fpc-devel] Unicode paths

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

Re: [fpc-devel] Unicode paths

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 necessari

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

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 dynam

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

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

Re: [fpc-devel] FPC 3.0.2 release target

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 pac

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

Στις 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 no

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

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-

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

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

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

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 ot

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

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 n

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

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

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

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 m

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

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 bran

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

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 t

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

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(TCustomAttri

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

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(TC

Re: [fpc-devel] Unicode paths

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 ap

Re: [fpc-devel] Unicode paths

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 kn

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

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 i

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

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: >

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

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

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

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

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

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. > >

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

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 afr

Re: [fpc-devel] Unicode paths

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

Re: [fpc-devel] Unicode paths

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 g

Re: [fpc-devel] FPC 3.0.2 release target

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. __

Re: [fpc-devel] FPC 3.0.2 release target

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 so