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

On Fri, Apr 15, 2016 at 3:01 AM, Maciej Izak wrote: > > I'm too lazy to do things in that way. I need object inspector with > properties/events tabs + WYSIWYG. ;) > > That is also the reason of introducing smart pointers branch. I'd like to > omit any Free/FreeMems. > >

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

The biggest problem I ran into has to do with asset lifetime management. That is, allowing for ad-hoc creation or loading and unloading of (list to follow): Textures Models Storyboards Skeletons Scripts Audio Samples Fonts Skyboxes Shaders/Shader programs ... and anything else which a game

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

2016-04-14 23:16 GMT+02:00 Anthony Walter : > Looks really good. Why did you feel the need to have IDE integration? From > my perspective (having written a game toolkit) the only point I needed IDE > integration was a project template to add a reference to my game engine >

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

2016-04-15 1:36 GMT+02:00 Anthony Walter : > As far as game engine design, I wanted/prefer a KISS style similar to XNA. > That is you just derive a game class and override two methods: Logic() and > Render() and each is passed a Stopwatch class representing time. One you > fill

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

2016-04-15 0:19 GMT+02:00 Sven Barth : > My hope is to do some more IDE integration for the Castle Game Engine as > well sometime(TM) in the future > !!! that is also my target. To start my work on this I need anonymous methods, Generics.Collections, extended RTTI

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

Am 15.04.2016 01:37 schrieb "Anthony Walter" : > Plus a whole lot more external tools. So from my perspective (and maybe a lot of others as well) a game engine IDE should primarily be focused on making compilation and targetting of many platforms transparent. But that's not what

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

I am really looking forward to runtime package support. :) As far as game engine design, I wanted/prefer a KISS style similar to XNA. That is you just derive a game class and override two methods: Logic() and Render() and each is passed a Stopwatch class representing time. One you fill in with

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

Am 14.04.2016 21:52 schrieb "Maciej Izak" : > > 2016-04-14 16:26 GMT+02:00 Anthony Walter : >> >> A game engine? What happened to it? I've moved my game engine to OpenGL ES 2.0 for all platforms and am looking to create a FPC Android starter template. > > >

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

Am 14.04.2016 23:24 schrieb "Anthony Walter" : > > Looks really good. Why did you feel the need to have IDE integration? He wrote that he intended that as a "Delphied Unity3D" and Unity3D is a game engine together with an IDE. And I personally agree as that makes things much

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

Looks really good. Why did you feel the need to have IDE integration? From my perspective (having written a game toolkit) the only point I needed IDE integration was a project template to add a reference to my game engine package and create a source code file. All the tools which can be used to

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

2016-04-14 16:26 GMT+02:00 Anthony Walter : > A game engine? What happened to it? I've moved my game engine to OpenGL ES > 2.0 for all platforms and am looking to create a FPC Android starter > template. > Yes, but strictly integrated with XE2 (WYSIWYG + events like OnClick but

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

Maciej, A game engine? What happened to it? I've moved my game engine to OpenGL ES 2.0 for all platforms and am looking to create a FPC Android starter template. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

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

2016-04-13 22:01 GMT+02:00 Sven Barth : > I doubt that. > E? Sparta project was initially game engine created as plugin for Delphi XE2 with a lot of packages and with complicated dependencies system (330 modules + 15 packages). I can say that proposed sections

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

2016-04-13 22:00 GMT+02:00 Sven Barth : > The code provided by Thorsten is sufficient (and needed for dynamic > packages anyway); an additional section is not needed, that just adds > unnecessary complexity for users. > Yes I agree with that :) you should know why it

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

On 13.04.2016 19:50, Florian Klämpfl wrote: >> 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

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

On 13.04.2016 18:57, Maciej Izak wrote: > 2016-04-13 15:24 GMT+02:00 Maciej Izak >: > > I think I have other solution (that also can help to solve old > problems). What is needed is new section like > "managementinitialization" and

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

On 13.04.2016 15:24, Maciej Izak wrote: > 2016-04-12 17:15 GMT+02:00 Sven Barth >: > > > 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

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

On 13.04.2016 19:50, Florian Klämpfl wrote: >> 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

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

Am 13.04.2016 um 20:11 schrieb Maciej Izak: > 2016-04-13 19:50 GMT+02:00 Florian Klämpfl >: > > Just make a simple rule: custom managed types are initialized directly > before (...) initialization > > > Current implementation

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

2016-04-13 19:50 GMT+02:00 Florian Klämpfl : > Just make a simple rule: custom managed types are initialized directly > before (...) initialization > Current implementation (smart_pointers branch) works in that way... custom managed types are initialized directly before

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

Am 12.04.2016 um 23:10 schrieb 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

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

2016-04-13 15:24 GMT+02:00 Maciej Izak : > I think I have other solution (that also can help to solve old problems). > What is needed is new section like "managementinitialization" and > "managementfinalization" (to complement "initialization"/"finalization" > with a little

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

2016-04-12 17:15 GMT+02:00 Sven Barth : > > 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 >

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

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

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

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

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

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

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

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

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:

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:

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

On 11.04.2016 15:27, Maciej Izak wrote: > 2016-04-11 14:38 GMT+02:00 Sven Barth >: > > There is another problem that occurred to.me after my > previous mail. Have you ever heard of the "static initialization

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

2016-04-11 14:38 GMT+02:00 Sven Barth : > There is another problem that occurred to.me after my previous mail. Have > you ever heard of the "static initialization order fiasco"? I've stumbled > upon that a few weeks ago at work with C++ and was glad that we don't have

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

Am 11.04.2016 08:37 schrieb "Maciej Izak" : > Thanks for introduction. Workaround is not a case, eventually patch to fix order of class constructor/destructor and variable implicit initialization/finalization (as mentioned in http://bugs.freepascal.org/view.php?id=29245 ).

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

2016-04-11 6:55 GMT+02:00 Anthony Walter : > I've done a little testing on your smart pointer branch but haven't found > any issues recently. Can you tell me if there is a tag for this feature in > mantis yet and/or if there are any known issues? > As Sven stated I am not core

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

2016-04-10 23:54 GMT+02:00 Sven Barth : > There are two things to differentiate: > > - Default() used in global variables > - Default() used locally > > The latter creates a local variable and basically FillChar()s it while the > former creates a zero initialized

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

Am 11.04.2016 06:56 schrieb "Anthony Walter" : > > Maciej, > > I've done a little testing on your smart pointer branch but haven't found any issues recently. Can you tell me if there is a tag for this feature in mantis yet and/or if there are any known issues? There is no tag

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

Maciej, I've done a little testing on your smart pointer branch but haven't found any issues recently. Can you tell me if there is a tag for this feature in mantis yet and/or if there are any known issues? Thanks ___ fpc-devel maillist -

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

Am 10.04.2016 23:54 schrieb "Sven Barth" : > > Am 10.04.2016 21:34 schrieb "Maciej Izak" : > > > > Hi, > > > > Is right to call Initialize operator for Default(TFoo) where TFoo is record with management operators? IMO the right direction is to keep

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

Am 10.04.2016 21:34 schrieb "Maciej Izak" : > > Hi, > > Is right to call Initialize operator for Default(TFoo) where TFoo is record with management operators? IMO the right direction is to keep "meta record instance" in place where TFoo is declared and call Initialize operator

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

Hi, Is right to call Initialize operator for Default(TFoo) where TFoo is record with management operators? IMO the right direction is to keep "meta record instance" in place where TFoo is declared and call Initialize operator before "class constructors" and before initialize section (TFoo class