Re: [fpc-devel] But what /is/ a string?
On Monday 27 August 2012 13:40:59 Michael Fuchs wrote: Am 27.08.2012 10:51, schrieb Michael Schnell: If in future TObject is reference (as it might be in a future Delphi version, according to an Embarcadero blog) counting (and thus using .Free is not mandatory any more), [...] I hope this will never happen. Me too. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
On Tue, 28 Aug 2012, Graeme Geldenhuys wrote: On 28/08/12 02:48, Luiz Americo Pereira Camara wrote: Back in 2010, in the thread about observer support in fcl, i asked if the actions would be customizable so i could, e.g., notify/observe if a child was added or removed in a tree structure. The answer was yes. I've emailed Michael 2-3 weeks ago about a previous mailing list discussion about Observer support too - which I concluded as will be accepted, Michael just needs time to commit his changes. Adding support for Observer into base RTL classes (not FCL). Any extra resources will only be used when the Observer functionality is actually requested, by the developer, it can't break any existing code because no such functionality existed before etc. Michael said it was again under discussion behind closed doors, but he will notify me of the outcome. I think you didn't read the original poster's mail subject line 100% carefully :-) The support has been committed. I didn't get around to notifying you yet. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
On 28/08/12 08:50, michael.vancann...@wisa.be wrote: The first: Procedure TmyObject.SomethingChanged; Var Rec : TMyOperationInfo; // Contains custom information about your operation. begin Rec.XYZ:=MoreInfo; // Set up as needed. FPONotifyObservers(Self,ooCustom,@Rec); end; Correct, and this is how I use it in tiOPF too — which has a similar observer implementation. It does not need one. The sender has changed, not an item in a list. The 'Item'-s are for when sender is a list, and an item is added to the list. Ah yes, I understand your thinking now. Scrap my earlier comment on this point. :) Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
On 28/08/12 08:57, michael.vancann...@wisa.be wrote: I think you didn't read the original poster's mail subject line 100% carefully :-) My apologies, I thought he was commenting on the FPObserver support added as a unit to FCL, not RTL. The subject line quoting a old post or something. The support has been committed. I didn't get around to notifying you yet. I just pulled a Trunk update and can see the changes now. Thank you very much for this contribution, it is going to come in very handy! Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
Em 28/8/2012 04:50, michael.vancann...@wisa.be escreveu: On Mon, 27 Aug 2012, Luiz Americo Pereira Camara wrote: I ask to change to a mechanism that could allow customizable operations (more than one) That is why you have ooCustom. I'm asking that because i have implemented a similar mechanism that support operations like Load, ChildAdd, ChildDelete, ChildChange. I believe that more developers are in the same situation,i.e., using observer pattern to an action not handled by those 5 types. It would be helpful to use the native implementation otherwise i will have to keep(re-implement) the observer support over TPersistent. That's why you have ooCustom and Data at your disposal. ooCustom is already used in TCollection if i remember correct. If i use it for a TCollection descendant that uses ooCustom with a record pointer i would get a conflict and a possible crash. Why not let TFPObservedOperation as integer and define constants. It could define a constant like ooUser = 32 Below ooUser is reserved for future default constants Above ooUser could be added custom messages This is how LCL messages works Its both light and extensible BTW: The names of the TFPObservedOperation are not consistent: ooChanged is in preterit while others not ooChanged does not has Item suffix It does not need one. The sender has changed, not an item in a list. The 'Item'-s are for when sender is a list, and an item is added to the list. (TList, TStringList, TCollection) I did the remark because in TCollection is fired because a a change in a Item. But is fine. Any way the preterit question is still valid Changed - Added - Deleted or Change - Add - Delete Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Em 28/8/2012 04:50, michael.vancann...@wisa.be escreveu: On Mon, 27 Aug 2012, Luiz Americo Pereira Camara wrote: I ask to change to a mechanism that could allow customizable operations (more than one) That is why you have ooCustom. I'm asking that because i have implemented a similar mechanism that support operations like Load, ChildAdd, ChildDelete, ChildChange. I believe that more developers are in the same situation,i.e., using observer pattern to an action not handled by those 5 types. It would be helpful to use the native implementation otherwise i will have to keep(re-implement) the observer support over TPersistent. That's why you have ooCustom and Data at your disposal. ooCustom is already used in TCollection if i remember correct. In TList and TCollection. I will change it to ooDeleteItem; The effect is the same. Extract and Delete are the same operation at the pointer level, after all. If i use it for a TCollection descendant that uses ooCustom with a record pointer i would get a conflict and a possible crash. A useful observation, and I will take it into account. Why not let TFPObservedOperation as integer and define constants. It could define a constant like ooUser = 32 Below ooUser is reserved for future default constants Above ooUser could be added custom messages This is how LCL messages works Exactly because it is not meant as a general messaging interface, and I want the interface to reflect this. There is a clear intended use case: Mainly notification of changes. In this sense, it is a unification and extension of the TStrings.Changed, TCollection.Notify and TList.Notify which already were defined by Delphi (and which, for some strange reason, have different interfaces). The enumerated reflects the intended use cases: Change notification, and for list-type objects, insertion and deletion of items. If you want to go outside that, then this is possible too: you can use ooCustom and Data. I will make sure it is not used in standard notifications. (see the change above) Using the outlined use-cases I gave you can still define an extension with an integer and put that in the object/record to use on ooCustom. If someone has an idea about a general-purpose notification type then that can of course be discussed. For example, on my 'doubtful' list I had ooPropertyChange, to be used in combination with the GetPropInfo() and a call in TPersistent: FPOPropertyChanged(Const APropName : String); I'm still not 100 % sure what to do with that. As for the preterit in ooChanged, I will look at it too. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
On 28/08/12 13:15, michael.vancann...@wisa.be wrote: For example, on my 'doubtful' list I had ooPropertyChange, to be used in combination with the GetPropInfo() and a call in TPersistent: FPOPropertyChanged(Const APropName : String); This could work, and I can see use-cases where this could be useful. I'm not sure how much overhead it will add though, but probably very small if done correctly. How would streaming affect this? eg: populating objects from a .lfm file. I don't use such streaming, but thought I need to mention it. For more accurate information, I guess the best would be to do a reference implementation, create a test case, and decide from there. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
Em 28/8/2012 09:15, michael.vancann...@wisa.be escreveu: On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Why not let TFPObservedOperation as integer and define constants. It could define a constant like ooUser = 32 Below ooUser is reserved for future default constants Above ooUser could be added custom messages This is how LCL messages works Exactly because it is not meant as a general messaging interface, and I want the interface to reflect this. There is a clear intended use case: Mainly notification of changes. This is the purpose i intend to use (replace my implementation). Basically is a tree structure that needs to be observed. To avoid performance problems like having to parse all the tree when a change occurs i defined actions when a Child is added, deleted or inserted. To be clear what i would need to do with the current approach: const ChildAdded = 1; type TMyNotifyInfo = record NType: Integer; NData: Pointer; end; PMyNotifyInfo = ^TMyNotifyInfo; //notify procedure TMyObserved.Changed; var R: TMyNotifyInfo; begin R.NType := ChildAdded; R.NData := ChildItemObject; FPONotifyObservers(Self,ooCustom,@R); end; //observe procedure TMyObserver.FPOObservedChanged(ASender : TObject; Operation : TFPObservedOperation; Data : Pointer); var R: PMyNotifyInfo; begin if Operation = ooCustom then begin R := PMyNotifyInfo(Data); if R^.Ntype = ChildAdded then DoChildAdd(R^.NData); end; end; compare with my proposed solution of defining the type as integer: const ooChildAdded = ooUser + 1; //notify procedure TMyObserved.Changed; begin FPONotifyObservers(Self, ooChildAdded, ChildItemObject); end; //observe procedure TMyObserver.FPOObservedChanged(ASender : TObject; Operation : TFPObservedOperation; Data : Pointer); begin if Operation = ooChildAdded then begin DoChildAdd(Data); end; end; Simpler, less code, less memory use, extensible. All that with just changing the TFPObservedOperation to a Integer or word type IMO such feature at a low level class should be usable in the most use cases, otherwise it will have a half observer support. My proposition does not increase complexity of the code, nor any type of overhead with the above gains. Can you point the drawbacks? Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Em 28/8/2012 09:15, michael.vancann...@wisa.be escreveu: On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Why not let TFPObservedOperation as integer and define constants. It could define a constant like ooUser = 32 Below ooUser is reserved for future default constants Above ooUser could be added custom messages This is how LCL messages works Exactly because it is not meant as a general messaging interface, and I want the interface to reflect this. There is a clear intended use case: Mainly notification of changes. This is the purpose i intend to use (replace my implementation). Basically is a tree structure that needs to be observed. To avoid performance problems like having to parse all the tree when a change occurs i defined actions when a Child is added, deleted or inserted. Exactly. You should use ooAddItem, ooDeleteItem, and pass the treenode in Data. To be clear what i would need to do with the current approach: Your example is not correct. I don't see why you would not use ooItemAdded. You observe a tree. Your observer code knows what it means if the tree sends a ooItemAdd or ooItemDelete. There is not even the need for a custom type here. Do not forget that the implementor of some control decides (and documents) what notifications he/she will send. The 4 standard ones will probably cover everything. The observers need to know what they observe, and know what to do for each operation. If you make the operation an integer, an observer will never know if it has covered all operations. With an enumerated type, the observer can implement the 5 enumerated values, and know that all operations have been covered. We can agree on the exact number of operations that we define, but I will not implement a system with an open number of operations. If you think that each and every possibly imaginable operation needs its own type of message, then you are IMHO on the wrong track. My original implementation didn't even have ooCustom, and I could observe all controls in the LCL with just the 4 messages ooChange,ooFree,ooItemAdd and ooItemDelete; That included observing a tree. Today or tomorrow I will commit the fpObserver unit, which contains a basic mediator factory which I used to implement just that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
Em 28/8/2012 12:46, michael.vancann...@wisa.be escreveu: On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Em 28/8/2012 09:15, michael.vancann...@wisa.be escreveu: On Tue, 28 Aug 2012, Luiz Americo Pereira Camara wrote: Why not let TFPObservedOperation as integer and define constants. It could define a constant like ooUser = 32 Below ooUser is reserved for future default constants Above ooUser could be added custom messages This is how LCL messages works Exactly because it is not meant as a general messaging interface, and I want the interface to reflect this. There is a clear intended use case: Mainly notification of changes. This is the purpose i intend to use (replace my implementation). Basically is a tree structure that needs to be observed. To avoid performance problems like having to parse all the tree when a change occurs i defined actions when a Child is added, deleted or inserted. Exactly. You should use ooAddItem, ooDeleteItem, and pass the treenode in Data. To be clear what i would need to do with the current approach: Your example is not correct. I don't see why you would not use ooItemAdded. This was just the first thing that comes in mind. I have a simple interface to observing a tree. Looking more carefully i really can use ooItem* for children. I also defined a Change notification for the object itself plus another for the child/item but i could differentiate using data as nil. The other missing one is to Load (lazy loading) We can agree on the exact number of operations that we define, but I will not implement a system with an open number of operations. I will do some tests and inform if there's a generic enough case to be included as a default notification Thanks for the explanations Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 27.08.2012 13:52, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: Seriously, even if you forget compatibility, it is impossible to assess something like that without in-depth design (and preferably a test implementation). Could always look at Delphi XE3: http://twitter.com/statuses/user_timeline/9146192.rss :) Assuming you mean the stringhelper remark, that is exactly what I wouldn't do. That looks like a compatibility workaround to me, instead of reengineering without compatibility. Adding helper support for primitive types was on my ToDo list anyway ^^ Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On Tue, 28 Aug 2012, Sven Barth wrote: On 27.08.2012 13:52, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: Seriously, even if you forget compatibility, it is impossible to assess something like that without in-depth design (and preferably a test implementation). Could always look at Delphi XE3: http://twitter.com/statuses/user_timeline/9146192.rss :) Assuming you mean the stringhelper remark, that is exactly what I wouldn't do. That looks like a compatibility workaround to me, instead of reengineering without compatibility. Adding helper support for primitive types was on my ToDo list anyway ^^ +1 ! :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] cross copiling x86_64 to i386 ?
I might be doing something wrong. I was trying to build a cross compiler (well I took a script that is to build a arm cross, and only did a search and replace... So there is plenty of room for error on by side. Before I go and look deeper: Should it work. Or is the below correct and it is not yet possible? C:/FPC/tag_build_2_6_0/fpcsrc/compiler/ppcx64.exe -Ur -Xs -O2 -n -Fui386 -Fusystems -FuC:/fpc/tag_build_2_6_0/fpcsrc/rtl/units/x86_64-win64 -Fii386 -FE. -FUi386 /units/x86_64-win64 -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems without support for an 80 bit extended floating point type to i386 is not yet supported at this time fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems without support for an 80 bit extended floating point type to i386 is not yet supported at this time fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems without support for an 80 bit extended floating point type to i386 is not yet supported at this time cutils.pas(154,1) Fatal: There were 3 errors compiling module, stopping Fatal: Compilation aborted ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent added support for Observer pattern in FCL
Luiz Americo Pereira Camara schrieb: This is the purpose i intend to use (replace my implementation). Basically is a tree structure that needs to be observed. To avoid performance problems like having to parse all the tree when a change occurs i defined actions when a Child is added, deleted or inserted. Why not create dedicated TObservedTree and TTreeObserver classes, which work together? This would allow for whatever kind of notifications required in a certain tree model, without any impact on the basic tree class. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cross copiling x86_64 to i386 ?
Martin schrieb: C:/FPC/tag_build_2_6_0/fpcsrc/compiler/ppcx64.exe -Ur -Xs -O2 -n -Fui386 -Fusystems -FuC:/fpc/tag_build_2_6_0/fpcsrc/rtl/units/x86_64-win64 -Fii386 -FE. -FUi386 /units/x86_64-win64 -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems without support for an 80 bit extended floating point type to i386 is not yet supported at this time I wonder why Extended should not be supported in 64 bit mode. The FPU still exists, as it's required in 32 bit mode, and AFAIK it also is accessible in 64 bit code. Of course the FPU doesn't work together with the MMX/MMY registers, but for the few conversions required in a compiler this should not be a big problem? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
