Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
2012/11/29 luiz americo pereira camara : > > There's a more concrete example about the duplicate typecast. > > I'm developing a model manager that would be responsible to easily > create LCL forms/frames, html forms, LazReport reports etc with the > same set of data/models > > Each project has a TModels collection with a TModel item > Each TMode item has a TFields collection with a TField item > Each TField has a unique Id managed per project > Currently to set the id of new Fields i have a circular reference > TField <> Project > My idea is to isolate TModel/TField to be independent of TProject > I can add a intermediate class to connect each other > But i could also takes advantage of Observer so i could observe the > Fields collection of each TModel to update the id when is added > The idea is add a FieldsObserver property to TModels and attach it to > each TModel > > It can be done as today?. Sure. My concerns are > > - I cannot define FieldsObserver as IFPObserver (the reasons why do i > prefer as it are above) > - Using FieldsObserver as TObject each time i attach/dettach from a > TFields there will be a type cast that i know before hand is not > necessary and could avoid. Attached is the classes as is today. I'll try to get rid of circular dependency from TProject using the observer pattern. I 'll post the result later Luiz datamodelclasses.pas Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
2012/11/29 : > > > On Thu, 29 Nov 2012, luiz americo pereira camara wrote: > > > Yes. I still do not see how your example shows this ? > > Your wizard knows it can observe. It attaches itself to the frame. > The code frame does not need to know the observing object ? Yes, you are right in this wizard case the page owner would know it's an observer. [] >> It can crash since not necessarily owner (e.g. a simple TForm) will >> implements IFPObserver? > > > Who takes the decision to observe or not ? The TForm, I assume. > Somewhere the decision is made. In this location you will necessarily know > who will do the observing, and you will know it has IFPObserver. OK >> >> You would not be forced or induced to use an interface it would be >> optional. > > > Eh ? I would need to do a AttachObserver(MyObservingObject as IFPObserver) > everywhere where I want to observe, instead of > AttachObserver(MyObservingObject). > > That is hardly optional ? > It's the small cost i pointed elsewhere. In the other hand makes the code contract (what AttachObserver expects) clear in the declaration. Also improves compiler type check This is a trade off. I see your reason to hides the interface. >> >> BTW: did you read my comment about observer method not being public? >> By the currently implementation to attach a Observer to a TPersistent >> the programmer is _forced_ to use an interface contradicting what you >> said above. > > > I already fixed that. I also fixed the sender problem. In my cases I always > had (Sender=Self). > Thanks Did you read the TGUID (not necessary) part? >> I know what to expect when i see an IFPObserver property but not when >> i see an TObject (although i can guess by the name). > > > I am sorry, but I really still do not understand your problem with the > interface. > > Contrary to what it may look like, it is not so that I am dead set against > such a change. However, to me, your change presents a serious disadvantage. > Therefore I expect you at least to show to me that there is a substantial > need or benefit in this for all of us. > > Because till now I simply do not see the need or benefit... In the program that i mentioned in other message there's a use case for observer. I'll try to implement it and post the result here. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] off topic: win 64 stack align.
2012/11/29 Martin : > I noted that for example on Mac the stack needs to be aligned on 16 byte > (32 bit) > > Is there anything like that on win 64 intel? http://blogs.embarcadero.com/abauer/2011/10/10/38940 Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] off topic: win 64 stack align.
I noted that for example on Mac the stack needs to be aligned on 16 byte (32 bit) Is there anything like that on win 64 intel? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Hello luiz, Thursday, November 29, 2012, 9:39:36 PM, you wrote: > In the message of the example observer: It seems Gmail searching has failed me. Thanks for fulfilling my curiosity. As for my comment. It was purely a suggestion (for convenience). My personal preference is still to use interface methods only via a interface reference. As I also mentioned in my quoted comment - there is good arguments for doing so. -- Best regards, Graeme fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win64 calling convention
2012/11/29 Martin : > Just to confirm my observations. (again trying to get pascal script to work) > 64 bit windows > Recently, i faced similar situation (porting assembly to 64bit). You can look there how i managed: http://lazarus-ccr.svn.sourceforge.net/viewvc/lazarus-ccr/components/virtualtreeview-new/branches/4.8/include/intf/win32/vtgraphicsi.inc?r1=2543&r2=2544 You can take into account also that Win64 is different from non windows See that i needed to ifdef in qt: http://lazarus-ccr.svn.sourceforge.net/viewvc/lazarus-ccr/components/virtualtreeview-new/branches/4.8/include/intf/qt/vtgraphicsi.inc?r1=2534&r2=2548 Luiz > procedure FOO(Sender: TSynEdit; const M: String; const P1, P2: TPoint); > > "const P1, P2: TPoint" versus "P1, P2: TPoint" > > if "const" is NOT used, then TPoint is put into a register > if "const" is used, then TPoint is in mem, and the register is a reference. > > Is that right? (I know the doc says, no assumption, and can be ref or > value) > > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win64 calling convention
Martin schrieb: Just to confirm my observations. (again trying to get pascal script to work) 64 bit windows procedure FOO(Sender: TSynEdit; const M: String; const P1, P2: TPoint); "const P1, P2: TPoint" versus "P1, P2: TPoint" if "const" is NOT used, then TPoint is put into a register if "const" is used, then TPoint is in mem, and the register is a reference. Is that right? (I know the doc says, no assumption, and can be ref or value) In Delphi it's clear: Without "const" the data *must* be copied (by-val), so that the subroutine cannot change the original data. "const" *allows* the compiler to pass the original data structure by-ref, because the subroutine will not change the data. Whether the parameter is passed by value or reference depends, on e.g. the sizeof the data structures and pointers, and whether optimizing for speed or size. FPC has added "constref", definitely forcing by-ref. AFAIR this was required for the ObjectiveC interface. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
michael.vancann...@wisa.be schrieb: Are there cases where locals are set to a sane initial state, e.g. for strings and dynamic arrays? What about (references to) objects? Managed types are normally initialized. That means Ansistrings, UnicodeString, and COM interfaces and dynamic arrays (maybe I forget some) Classes and objects are not. I am not sure about widestrings on Windows. But again, not always: For instance Function a(B : Integer) : Ansistring; begin Result:=Result+' something'; end; You would think that Result is initialized because it is managed: it is an ansistring. In fact, it is not initialized, leading sometimes to surprises. I'd expect that the Result is passed in as a reference, which is initialized before the call. Just like record results are handled. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mips-linux and mipsel-linux snapshots available
Mark Morgan Lloyd wrote: Pierre Free Pascal wrote: Hi Mark, do you use my patch for mips to handle stack? Without it, the backtrace doesn't work... The bad thing is that I submitted it to gdb-patches, but it was refused, I was told that $fp should be equal to $sp according to ABI... If you use a stock GDB, try to unpack a recent GDB source tree, apply the one line patch below, and recompile GDB. Can you tell us if the backtrace looks better after this? Thanks Pierre, I'll work on it between other things. I think I got that patch into the sources from Debian, although it had moved somewhat: I I read things correctly it went into the first of two similar blocks. Running the program using the modified GDB, I get the same as before: 0 1>markMLl@pye-dev-07d:~$ which gdb /usr/local/bin/gdb 0 1>markMLl@pye-dev-07d:~$ gdb /usr/local/bin/ppcmips GNU gdb (GDB) 7.0.1-debian .. (gdb) set arg -h (gdb) run Starting program: /usr/local/bin/ppcmips -h Program received signal SIGBUS, Bus error. 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () (gdb) bt #0 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () #1 0x0043fa6c in SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN () #2 0x0043fdc4 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) A curious thing is that when I first ran it from the build directory without "make install" I appeared to get more info: Program received signal SIGBUS, Bus error. 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () (gdb) bt #0 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () #1 0x0043fa6c in SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN () #2 0x0043fdc4 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT () #3 0x00440074 in SYSUTILS_$$_FINDFIRST$ANSISTRING$LONGINT$TSEARCHREC$$LONGINT () During symbol reading, couldn't parse type; debugger out of date?. #4 0x00453428 in TCACHEDDIRECTORY__RELOAD (this=variable>) at cfileutl.pas:277 #5 0x00453050 in TCACHEDDIRECTORY__FORCEUSECACHE (this=variable>) at cfileutl.pas:234 #6 0x00452fd8 in TCACHEDDIRECTORY__TRYUSECACHE (this=variable>) at cfileutl.pas:223 #7 0x00453ad8 in TCACHEDDIRECTORY__DIRECTORYEXISTS (ANAME=0x2aaa880c 'mipseb-linux', this=) at cfileutl.pas:357 #8 0x00454244 in TDIRECTORYCACHE__DIRECTORYEXISTS ( ANAME=0x2aac822c '/usr/local/lib/fpc/2.7.1/units/mipseb-linux', this=) at cfileutl.pas:433 #9 0x004555b8 in PATHEXISTS (F=0x2aac826c '/usr/local/lib/fpc/2.7.1/units/mipseb-linux/', ALLOWCACHE=true) at cfileutl.pas:687 #10 0x00457e40 in TSEARCHPATHLIST__ADDPATH (SRCPATH=0x0, S=0x0, ADDFIRST=true, this=) at cfileutl.pas:1131 #11 0x00456b88 in TSEARCHPATHLIST__ADDPATH (S=0x2aac816c '/usr/local/lib/fpc/2.7.1/units/mipseb-linux', ADDFIRST=true, this=) at cfileutl.pas:986 #12 0x0063bf64 in TOPTION__INTERPRET_OPTION ( OPT=0x2aab910c '-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget', ISPARA=false, this=) at options.pas:1146 #13 0x00641724 in TOPTION__INTERPRET_FILE (FILENAME=0x2aaa87ac '/etc/fpc.cfg', this=) at options.pas:2237 #14 0x00644358 in READ_ARGUMENTS (CMD=0x0) at options.pas:2932 #15 0x00427f90 in INITCOMPILER (CMD=0x0) at compiler.pas:190 #16 0x004280c0 in COMPILE (CMD=0x0) at compiler.pas:237 #17 0x0040043c in main () at pp.pas:233 (gdb) quit However I don't entirely trust this since there could be some unholy mix of modified and unmodified libraries. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
2012/11/29 Graeme Geldenhuys : > Hello luiz, > > Thursday, November 29, 2012, 12:31:41 PM, you wrote: > >> BTW: Graeme already pointed, that the Observer methods should be >> public. Does not makes sense to protect methods that are exposed by an >> interface. > > When did I say that? [Though my memory has been failing me once or > twice. :)] In the message of the example observer: " 1) I would probably surface the IFPObserver methods to Public. Though there is good arguments to not do it either - thus you are forced to use correct interface usage... via Supports(), getting a interface pointer back, and using that interface pointer to make method calls. " Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Hello luiz, Thursday, November 29, 2012, 12:31:41 PM, you wrote: > BTW: Graeme already pointed, that the Observer methods should be > public. Does not makes sense to protect methods that are exposed by an > interface. When did I say that? [Though my memory has been failing me once or twice. :)] As far as I'm concerned it should be the other way round. Interface implementations should all be done private - because you should always access those interface methods using an Interface reference. That's the way I do it in my own code. -- Best regards, Graeme ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win64 calling convention
On 29 Nov 2012, at 17:21, Martin wrote: > Just to confirm my observations. (again trying to get pascal script to work) > 64 bit windows > > procedure FOO(Sender: TSynEdit; const M: String; const P1, P2: TPoint); > > "const P1, P2: TPoint" versus "P1, P2: TPoint" > > if "const" is NOT used, then TPoint is put into a register > if "const" is used, then TPoint is in mem, and the register is a reference. > > Is that right? (I know the doc says, no assumption, and can be ref or value) And it can change at any time. Interfacing with such routines at the assembler level is simply not supportable in FPC code, and trying to do so anyway is guaranteed to only lead to much frustration. Either use constref (by reference) or a value parameter (by value). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On Thu, 29 Nov 2012, luiz americo pereira camara wrote: - I cannot define FieldsObserver as IFPObserver (the reasons why do i prefer as it are above) - Using FieldsObserver as TObject each time i attach/dettach from a TFields there will be a type cast that i know before hand is not necessary and could avoid. That depends on the implementation. Not everybody will have the IFPObserver available as a separate field. I suspect that in many cases, it will be the observer object itself. In that case you would have to do (YourObserverObject as IFPObserver) anyway, and you gain nothing. the 'as' does the same thing as what is now in the implementation of attachobserver... In my proposition, is up to programmer decide if will use TObject or IFPObserver in FieldsObserver, different from today that i'm tied with TObject. Since every object is TObject, I do not see this as a problem. Since in your code you will only attach a FieldsObserver, you lose nothing in the process. Different from what Michael stated in previous email, in my proposition there would be no increase of interface usage in the functionality itself. Just would be explicit to the programmer that this feature requires a interface rather than now, that is hidden in the implementation. That it is hidden, is exactly what I wanted. To me, that is a plus. Anyway, with this I have a clearer example of what you want to achieve. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests in Delphi XE3 regarding Type Helpers
Am 29.11.2012 10:56, schrieb Marco van de Voort: Otherwise: Thank you so far. :) As soon as it is finished, you go back to generics? :-) I don't know yet what I'll finish first (this was just some preparation), but I do hope that I'll get to decreasing my "feature list" in the next weeks :D (and yes, this includes generics) I was just teasing. You might only have been teasing, but there are features on my list that I wait for to use for quite some time already :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] win64 calling convention
Just to confirm my observations. (again trying to get pascal script to work) 64 bit windows procedure FOO(Sender: TSynEdit; const M: String; const P1, P2: TPoint); "const P1, P2: TPoint" versus "P1, P2: TPoint" if "const" is NOT used, then TPoint is put into a register if "const" is used, then TPoint is in mem, and the register is a reference. Is that right? (I know the doc says, no assumption, and can be ref or value) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On Thu, 29 Nov 2012, luiz americo pereira camara wrote: I fail to see how the current interface forbids this ? It does not forbids. It's just an example of the need to check if a object implements an IFPObserver before attaching it. You have said that there's no real life situation you need to do this check since the programmer should know that implements always before hand Yes. I still do not see how your example shows this ? Your wizard knows it can observe. It attaches itself to the frame. The code frame does not need to know the observing object ? In the two cases one does not know about the other. What links is if the owner implements an interface or not and the implicit contract of this interface usage that is defined by the programmer. So i cannot simply call AttachObserver(Owner). So you say, but you do not explain why not. It can crash since not necessarily owner (e.g. a simple TForm) will implements IFPObserver? Who takes the decision to observe or not ? The TForm, I assume. Somewhere the decision is made. In this location you will necessarily know who will do the observing, and you will know it has IFPObserver. Anyway, to me is clear that you wont change your mind regardless of the arguments i use since you are not willing to change your code that relies on it. No, actually that is the least of my worries. It is an argument, not *the* argument. The argument is: I am not a fan of interfaces, and will avoid them like the plague when possible. The current implementation makes absolute minimal use of them and it works. Your proposal goes against all that I try to avoid, meaning that if I do as you ask, I am in fact changing it to something that I will later try to avoid as much as possible ? You would not be forced or induced to use an interface it would be optional. Eh ? I would need to do a AttachObserver(MyObservingObject as IFPObserver) everywhere where I want to observe, instead of AttachObserver(MyObservingObject). That is hardly optional ? Other programmer can have a different view/need of you. It's up to him decide what to use. BTW: did you read my comment about observer method not being public? By the currently implementation to attach a Observer to a TPersistent the programmer is _forced_ to use an interface contradicting what you said above. I already fixed that. I also fixed the sender problem. In my cases I always had (Sender=Self). I am willing to do this for the sake of FPC in general, but then you'll have to convince me of the huge benefits this change will bring. OK You now present a use case where you do not want to change your own implementation in order to be able to use Observer ? As i said Observer would simplify the usage, so i'm willing to change my code. OK. When in fact you could most likely perfectly use it as it is (see the "as TObject" elsewhere), or in the worst case slightly change your interface so the observer support can be used. All you need to do is 'expose' the observer TObject (implicitly or explicitly). I hardly see how this compromises your interface/implementation separation, by definition it is a TObject anyway ? I know what to expect when i see an IFPObserver property but not when i see an TObject (although i can guess by the name). I am sorry, but I really still do not understand your problem with the interface. Contrary to what it may look like, it is not so that I am dead set against such a change. However, to me, your change presents a serious disadvantage. Therefore I expect you at least to show to me that there is a substantial need or benefit in this for all of us. Because till now I simply do not see the need or benefit... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
2012/11/29 Graeme Geldenhuys : > Hi Luiz, > > First off, thanks for take the trouble it creating test projects. > Thanks for looking at them ;-) > > On 2012-11-29 02:59, luiz americo pereira camara wrote: >> >> Test1 >> As is today, if you have a reference to a IFPObserver is not possible >> to use it to attach to, e.g., child objects. This occurs because AFAIK >> you can't get a TObject from a interface reference. > > > OK, there are quite a few things I consider wrong with your Test1 > application. > > 1) Nothing stops Michael from extending the IPFObserver interface to > include a GetObject function that returns a TObject reference of > the observer. > I have seen many such cases in the wild. Not sure if I agree > with it, but that is another story. Yep but would be yet another type cast although Sven have concerns about if is really possible > 2) What exactly are you observing in Test1? What are you trying to > accomplish? It's just to say that sometimes you have only an interface reference (in the case IFPObserver) In some of my code i have properties of an interface type like IPageController. So i know what it does (or what is supposed todo) and i'm not tied for any specific implementation or class. In this case a IPageController can be a non visual component placed in a form that controls the page behavior or it can be TTreeView or TListBox descendant > > 4) If you change FChildren to TObjectList, then it can be observer. > Then simply attach observers directly to the Children property. That > way if you add or remove children, the observers are notified. The example was simply a quick demo. Think Children as private and not necessarily a TObjectList or TList, just an structure that holds more than one object that can be observed by the same observer. BTW: the objective of Test2 is to show that it can be unnecessary typecasts. In the example if Observer was IFPObserver no type casts would be done when attaching child objects > 5) I guess this depends on what you want to accomplish. But if you > first add children, then only call Initialize, then the observer > will never be notified that children was added to the list. > It was actually hard to figure out what you are trying to accomplish > with your test project. I think I'm still unclear of this. I'm seriously > under the weather at the moment (bad case of flu), so that probably > affects my judgement. So if I misinterpreted your Test project, please > do let me know. In the mean time, I modified your test1 (see attached). > The Observer now observes the Children List, and each Child - again, not > 100% sure what you wanted to accomplish. See above There's a more concrete example about the duplicate typecast. I'm developing a model manager that would be responsible to easily create LCL forms/frames, html forms, LazReport reports etc with the same set of data/models Each project has a TModels collection with a TModel item Each TMode item has a TFields collection with a TField item Each TField has a unique Id managed per project Currently to set the id of new Fields i have a circular reference TField <> Project My idea is to isolate TModel/TField to be independent of TProject I can add a intermediate class to connect each other But i could also takes advantage of Observer so i could observe the Fields collection of each TModel to update the id when is added The idea is add a FieldsObserver property to TModels and attach it to each TModel It can be done as today?. Sure. My concerns are - I cannot define FieldsObserver as IFPObserver (the reasons why do i prefer as it are above) - Using FieldsObserver as TObject each time i attach/dettach from a TFields there will be a type cast that i know before hand is not necessary and could avoid. In my proposition, is up to programmer decide if will use TObject or IFPObserver in FieldsObserver, different from today that i'm tied with TObject. Different from what Michael stated in previous email, in my proposition there would be no increase of interface usage in the functionality itself. Just would be explicit to the programmer that this feature requires a interface rather than now, that is hidden in the implementation. BTW: TField name is abbreviated so no clash with db.TField Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
2012/11/29 : > > > On Thu, 29 Nov 2012, luiz americo pereira camara wrote: > >> >> >> Well i have at least two situations, with code that is already >> running, that the observer pattern would fit as i described. >> >> - I implemented a Wizard Page component where i can attach a page to >> any TFrame. Each page can be assigned as an instance or it can be >> created at demand when is entered. Optionally the TFrame (Observed) >> can implement a CORBA interface to communicate with the wizard >> controller (Observer). This same TFrame can be used elsewhere, e.g, in >> a configuration page, in this case, the wizard functionality will be >> ignored since there's no observer. >> >> I could use the native Observer support to simplify the interface, >> making easier implement. > > > I still do not see how this is forbidden by the observers as they work now. >> >> - I have a code that takes a TFrame and show as dialog with some >> configurable buttons. To communicate to inform of state changes i use >> LCL messages that is really cumbersome. >> >> I could use the native observer support also. So if something changed >> in the TFrame i could enable the save button or popup a dialog to save >> the changes. If this same frame is used every where the Notidications >> would be discarded since there's no observer > > > I fail to see how the current interface forbids this ? It does not forbids. It's just an example of the need to check if a object implements an IFPObserver before attaching it. You have said that there's no real life situation you need to do this check since the programmer should know that implements always before hand > > >> In the two cases one does not know about the other. What links is if >> the owner implements an interface or not and the implicit contract of >> this interface usage that is defined by the programmer. So i cannot >> simply call AttachObserver(Owner). > > > So you say, but you do not explain why not. > It can crash since not necessarily owner (e.g. a simple TForm) will implements IFPObserver? >> Anyway, to me is clear that you wont change your mind regardless of >> the arguments i use since you are not willing to change your code that >> relies on it. > > > No, actually that is the least of my worries. It is an argument, not *the* > argument. > > The argument is: > > I am not a fan of interfaces, and will avoid them like the plague when > possible. The current implementation makes absolute minimal use of them and > it works. > > Your proposal goes against all that I try to avoid, meaning that if I do as > you ask, I am in fact changing it to something that I will later try to > avoid as much as possible ? You would not be forced or induced to use an interface it would be optional. Other programmer can have a different view/need of you. It's up to him decide what to use. BTW: did you read my comment about observer method not being public? By the currently implementation to attach a Observer to a TPersistent the programmer is _forced_ to use an interface contradicting what you said above. > > I am willing to do this for the sake of FPC in general, but then you'll have > to convince me of the huge benefits this change will bring. OK > You now present a use case where you do not want to change your own > implementation in order to be able to use Observer ? As i said Observer would simplify the usage, so i'm willing to change my code. > When in fact you could most likely perfectly use it as it is (see the "as > TObject" elsewhere), or in the worst case slightly change your interface so > the observer support can be used. > > All you need to do is 'expose' the observer TObject (implicitly or > explicitly). I hardly see how this compromises your interface/implementation > separation, by definition it is a TObject anyway ? I know what to expect when i see an IFPObserver property but not when i see an TObject (although i can guess by the name). > So in my eyes, you fail to present a clear use case to show that > use of interfaces would actually be beneficial for the majority of intended > use cases of observers. Ok. Thanks for taking your time reading my comments Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Am 29.11.2012 10:44, schrieb michael.vancann...@wisa.be: On Thu, 29 Nov 2012, Sven Barth wrote: Am 29.11.2012 03:59, schrieb luiz americo pereira camara: As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. At least for COM interfaces "as" and "is" with a class type on the right side is supported. The corresponding code for Corba interfaces is not implemented (yet). This feature exists at least since 2.6.0. Well. I did not know of this feature. I should document it :-) It's also supported by newer Delphi versions (I don't know from when on though...) interfaces: What routine needs to be implemented to do this for Corba interfaces ? After thinking this through a bit I don't think that this will be possible... the "intf as class" and "intf is class" code relies no the existence of the QueryInterface function which is not supported by CORBA interfaces. It's also not possible to cast a CORBA interfaces to a another CORBA interface (or even a COM interface) exactly because of this. Nevertheless the corresponding RTL code is located in rtl/inc/objpas.inc from ~ line 110 to ~ line 270 (these are the compilerprocs which are used by the compiler). Of course compiler code would be needed as well... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
On Thu, 29 Nov 2012, Mark Morgan Lloyd wrote: michael.vancann...@wisa.be wrote: You must initialize local variables. Are there cases where locals are set to a sane initial state, e.g. for strings and dynamic arrays? What about (references to) objects? Managed types are normally initialized. That means Ansistrings, UnicodeString, and COM interfaces and dynamic arrays (maybe I forget some) Classes and objects are not. By which I presume that (references to) objects are not set to nil, in the same way that an integer or pointer wouldn't be set to zero or nil. Yes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On Thu, 29 Nov 2012, luiz americo pereira camara wrote: Well i have at least two situations, with code that is already running, that the observer pattern would fit as i described. - I implemented a Wizard Page component where i can attach a page to any TFrame. Each page can be assigned as an instance or it can be created at demand when is entered. Optionally the TFrame (Observed) can implement a CORBA interface to communicate with the wizard controller (Observer). This same TFrame can be used elsewhere, e.g, in a configuration page, in this case, the wizard functionality will be ignored since there's no observer. I could use the native Observer support to simplify the interface, making easier implement. I still do not see how this is forbidden by the observers as they work now. - I have a code that takes a TFrame and show as dialog with some configurable buttons. To communicate to inform of state changes i use LCL messages that is really cumbersome. I could use the native observer support also. So if something changed in the TFrame i could enable the save button or popup a dialog to save the changes. If this same frame is used every where the Notidications would be discarded since there's no observer I fail to see how the current interface forbids this ? In the two cases one does not know about the other. What links is if the owner implements an interface or not and the implicit contract of this interface usage that is defined by the programmer. So i cannot simply call AttachObserver(Owner). So you say, but you do not explain why not. Anyway, to me is clear that you wont change your mind regardless of the arguments i use since you are not willing to change your code that relies on it. No, actually that is the least of my worries. It is an argument, not *the* argument. The argument is: I am not a fan of interfaces, and will avoid them like the plague when possible. The current implementation makes absolute minimal use of them and it works. Your proposal goes against all that I try to avoid, meaning that if I do as you ask, I am in fact changing it to something that I will later try to avoid as much as possible ? I am willing to do this for the sake of FPC in general, but then you'll have to convince me of the huge benefits this change will bring. You now present a use case where you do not want to change your own implementation in order to be able to use Observer ? When in fact you could most likely perfectly use it as it is (see the "as TObject" elsewhere), or in the worst case slightly change your interface so the observer support can be used. All you need to do is 'expose' the observer TObject (implicitly or explicitly). I hardly see how this compromises your interface/implementation separation, by definition it is a TObject anyway ? So in my eyes, you fail to present a clear use case to show that use of interfaces would actually be beneficial for the majority of intended use cases of observers. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On 2012-11-29 12:10, michael.vancann...@wisa.be wrote: > > The primary reason of existence for TFPList and TFPObjectList is speed and > minimal overhead. OK, I understand now. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
michael.vancann...@wisa.be wrote: You must initialize local variables. Are there cases where locals are set to a sane initial state, e.g. for strings and dynamic arrays? What about (references to) objects? Managed types are normally initialized. That means Ansistrings, UnicodeString, and COM interfaces and dynamic arrays (maybe I forget some) Classes and objects are not. By which I presume that (references to) objects are not set to nil, in the same way that an integer or pointer wouldn't be set to zero or nil. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
2012/11/29 : > > > On Wed, 28 Nov 2012, luiz americo pereira camara wrote: > >> Given the considerations i did about the observer feature, here are >> some simple projects that supports my concerns and therefore the >> request i made to change the interface of two functions. >> >> Test1 >> As is today, if you have a reference to a IFPObserver is not possible >> to use it to attach to, e.g., child objects. This occurs because AFAIK >> you can't get a TObject from a interface reference. >> >> This limits the programmer choice to use a TObject in such situations, >> in this case the Observer property. > > > All objects in memory descend from TObject, so this is not a problem. > COM provided objects are not supported. That would require COM interfaces. > > I have looked at your tests. They are IMHO rather theoretical and will not > happen in real life. I can think of plenty of things that will not work even > with TComponent or TObject. That doesn't mean they will happen. > > Your 'problem' is that you store only interfaces for objects that will > observe. Indeed, this is a programming model I do not care to support *for > observers*, because I do not think it is likely to happen in real life > situations. > I explain this below. > > >> Test3 >> Pretty simple: if you don't know if a TObject descendant instance >> implements a IFPObserver (most cases) you have to do a check before >> attaching to a IFPObserved otherwise an exception is raised. > > > Let me get this straight: > > What you say is that you get from somewhere an unknown object (or an > interface) and just decide to let it observe another object ? For what ? For > fun ? > That is a very strange argument. You don't "accidentally" observe. > It is also not true that all objects A that have the IFPObserver interface > are suitable to observe a particular object B. > > You observe for a purpose. I'll say even more: in most cases your observer > will be written to specifically observe the observed class. > > You will not let object A observe object B for no good reason. > Observing introduces an overhead. For this reason alone, you should not > 'just observe'. > > A will observe B in order to react on changes that B reports, > and A will act on these changes. In almost all cases, A will have specific > knowledge about B: even if it is just that B has a published property named > XYZ. > > So you will know in advance that when attaching A to B, that A will have the > IFPObserver interface. Well i have at least two situations, with code that is already running, that the observer pattern would fit as i described. - I implemented a Wizard Page component where i can attach a page to any TFrame. Each page can be assigned as an instance or it can be created at demand when is entered. Optionally the TFrame (Observed) can implement a CORBA interface to communicate with the wizard controller (Observer). This same TFrame can be used elsewhere, e.g, in a configuration page, in this case, the wizard functionality will be ignored since there's no observer. I could use the native Observer support to simplify the interface, making easier implement. - I have a code that takes a TFrame and show as dialog with some configurable buttons. To communicate to inform of state changes i use LCL messages that is really cumbersome. I could use the native observer support also. So if something changed in the TFrame i could enable the save button or popup a dialog to save the changes. If this same frame is used every where the Notidications would be discarded since there's no observer In the two cases one does not know about the other. What links is if the owner implements an interface or not and the implicit contract of this interface usage that is defined by the programmer. So i cannot simply call AttachObserver(Owner). Anyway, to me is clear that you wont change your mind regardless of the arguments i use since you are not willing to change your code that relies on it. The alternative i proposed does not forbid the current usage pattern, just add an option with possible performance benefits with no, or very small, costs. Generally now, it's up to the programmer takes what way best fit his need and if a pattern is not used by a programmer, how good or experienced he is, does not mean there are not valid usage scenarios. This is even more true with new stuff that still not exposed for a wider audience. I won't discuss this more, the arguments are there to anyone judge. BTW: Graeme already pointed, that the Observer methods should be public. Does not makes sense to protect methods that are exposed by an interface. You can just do (APersistent as IFPObserved).FPOAttachObserver. And yes, i have real life examples that should be useful. Also in TPersistent.FPONotifyObservers you should not be using ASender in Obs.FPOObservedChanged? Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/
Re: [fpc-devel] farm memmove implementation still not avaliable by default (bug #18079)
On 29 Nov 2012, at 13:00, Anton Kavalenka wrote: http://bugs.freepascal.org/view.php?id=18079 now closed I've just tested latest SVN trunk (Revision: 23078) and still get 5000 ms What define should i pass building the compiler to achieve same performance as i386 (300 msec)? The title of your mail is wrong: the assembler move implementation / is/ enabled by default on x86-64 now. The other problem is some bad behaviour by the memory manager apparently, but I am unable to reproduce it anywhere. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On Thu, 29 Nov 2012, Graeme Geldenhuys wrote: Hi Luiz, First off, thanks for take the trouble it creating test projects. On 2012-11-29 02:59, luiz americo pereira camara wrote: Test1 As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. OK, there are quite a few things I consider wrong with your Test1 application. 1) Nothing stops Michael from extending the IPFObserver interface to include a GetObject function that returns a TObject reference of the observer. I have seen many such cases in the wild. Not sure if I agree with it, but that is another story. 2) What exactly are you observing in Test1? What are you trying to accomplish? TMyParentView is a TObject. Adding children to the Children property doesn't notify the observer about anything. ... now if the Observer property is holding reference to something that should observer each of the Children, well, then that is very easy to accomplish too. Simply changes the Observer property to a TObject instance. 3) Something Michael should fix. TFPObjectList doesn't support IPFObserver. TObjectList does though. I guess many of the list classes in the Contnrs unit should be double checked. No. This is left out on purpose. If you want observer support, you need TObjectList and TList. The primary reason of existence for TFPList and TFPObjectList is speed and minimal overhead. TList and it's observer/notification capabilities introduce a serious speed penalty. For instance when doing a Clear, all items are removed one by one as opposed to just de-allocating the array used to hold them. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
On Thu, 29 Nov 2012, Mark Morgan Lloyd wrote: michael.vancann...@wisa.be wrote: On Thu, 29 Nov 2012, Alexander Klenin wrote: On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe wrote: Will global variables and static global arrays be always initialized to zero? Yes. Then I suggest to amend the first paragraph of http://www.freepascal.org/docs-html/ref/refse22.html which directly contradicts this. It does not directly contradict this ? For local variables the statement is 100% correct. You must initialize local variables. Are there cases where locals are set to a sane initial state, e.g. for strings and dynamic arrays? What about (references to) objects? Managed types are normally initialized. That means Ansistrings, UnicodeString, and COM interfaces and dynamic arrays (maybe I forget some) Classes and objects are not. I am not sure about widestrings on Windows. But again, not always: For instance Function a(B : Integer) : Ansistring; begin Result:=Result+' something'; end; You would think that Result is initialized because it is managed: it is an ansistring. In fact, it is not initialized, leading sometimes to surprises. I only learned about this relatively recently, much to my surprise. It is one of the reasons I am reluctant to document this in detail, there always seem to pop up new cases. In general, you are safer off by assuming that nothing is initialized. Initializing it again does no damage. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] farm memmove implementation still not avaliable by default (bug #18079)
Dear FPC-All http://bugs.freepascal.org/view.php?id=18079 now closed I've just tested latest SVN trunk (Revision: 23078) and still get 5000 ms What define should i pass building the compiler to achieve same performance as i386 (300 msec)? regards, Anton ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
michael.vancann...@wisa.be wrote: On Thu, 29 Nov 2012, Alexander Klenin wrote: On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe wrote: Will global variables and static global arrays be always initialized to zero? Yes. Then I suggest to amend the first paragraph of http://www.freepascal.org/docs-html/ref/refse22.html which directly contradicts this. It does not directly contradict this ? For local variables the statement is 100% correct. You must initialize local variables. Are there cases where locals are set to a sane initial state, e.g. for strings and dynamic arrays? What about (references to) objects? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Hi Luiz,
First off, thanks for take the trouble it creating test projects.
On 2012-11-29 02:59, luiz americo pereira camara wrote:
>
> Test1
> As is today, if you have a reference to a IFPObserver is not possible
> to use it to attach to, e.g., child objects. This occurs because AFAIK
> you can't get a TObject from a interface reference.
OK, there are quite a few things I consider wrong with your Test1
application.
1) Nothing stops Michael from extending the IPFObserver interface to
include a GetObject function that returns a TObject reference of
the observer.
I have seen many such cases in the wild. Not sure if I agree
with it, but that is another story.
2) What exactly are you observing in Test1? What are you trying to
accomplish?
TMyParentView is a TObject. Adding children to the Children property
doesn't notify the observer about anything.
... now if the Observer property is holding reference to something
that should observer each of the Children, well, then that is very
easy to accomplish too. Simply changes the Observer property to
a TObject instance.
3) Something Michael should fix. TFPObjectList doesn't support
IPFObserver. TObjectList does though. I guess many of the list
classes in the Contnrs unit should be double checked.
4) If you change FChildren to TObjectList, then it can be observer.
Then simply attach observers directly to the Children property. That
way if you add or remove children, the observers are notified.
5) I guess this depends on what you want to accomplish. But if you
first add children, then only call Initialize, then the observer
will never be notified that children was added to the list.
It was actually hard to figure out what you are trying to accomplish
with your test project. I think I'm still unclear of this. I'm seriously
under the weather at the moment (bad case of flu), so that probably
affects my judgement. So if I misinterpreted your Test project, please
do let me know. In the mean time, I modified your test1 (see attached).
The Observer now observes the Children List, and each Child - again, not
100% sure what you wanted to accomplish.
So solving your supposedly "impossible" problem was rather easy. So I'm
still on Michael's side that the FPC Observer API needs no change.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
program ObserverTest1;
{$mode objfpc}{$H+}
uses
Classes, contnrs;
type
{ TMyParentView }
TMyParentView = class
private
FChildren: TObjectList;
FObserver: TObject;
public
constructor Create;
destructor Destroy; override;
procedure Initialize;
property Children: TObjectList read FChildren;
property Observer: TObject read FObserver write FObserver;
end;
{ TMyObserver }
TMyObserver = class(TObject, IFPObserver)
public
procedure FPOObservedChanged(ASender : TObject; Operation : TFPObservedOperation; Data : Pointer);
end;
{ TMyObserver }
procedure TMyObserver.FPOObservedChanged(ASender: TObject; Operation: TFPObservedOperation;
Data: Pointer);
begin
writeln('Observer changed');
end;
constructor TMyParentView.Create;
begin
writeln('Creating MyParentView...');
FChildren := TObjectList.Create(True);
end;
destructor TMyParentView.Destroy;
var
i: Integer;
Observed: IFPObserved;
Child: TObject;
begin
writeln('Destroying MyParentView...');
for i := 0 to FChildren.Count-1 do
begin
Child := FChildren[i];
if Child.GetInterface(SGUIDObserved, Observed) then
begin
//AFAIK it's not possible to get a TObject instance from an interface reference
//so if you have an IFPObserver variable or field it cannot be used to attach dettach to IFPObserved
Observed.FPODetachObserver(FObserver);
end;
end;
FChildren.Destroy;
inherited Destroy;
end;
procedure TMyParentView.Initialize;
var
i: Integer;
Observed: IFPObserved;
Child: TObject;
begin
for i := 0 to FChildren.Count-1 do
begin
Child := FChildren[i];
if Child.GetInterface(SGUIDObserved, Observed) then
begin
//AFAIK it's not possible to get a TObject instance from an interface reference
//so if you have an IFPObserver variable or field it cannot be used to attach dettach to IFPObserved
Observed.FPOAttachObserver(FObserver);
end;
end;
end;
var
View: TMyParentView;
ObserverObj: TMyObserver;
begin
ObserverObj := TMyObserver.Create;
View := TMyParentView.Create;
View.Observer := ObserverObj; // as IFPObserver;
View.Children.FPOAttachObserver(ObserverObj);
View.Children.Add(TPersistent.Create);
View.Children.Add(TPersistent.Create);
View.Children.Add(TPersistent.Create);
View.Initialize;
//Execute View
View.Destroy;
ObserverObj.Destroy;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On Thu, 29 Nov 2012, luiz americo pereira camara wrote: 2012/11/29 : On Thu, 29 Nov 2012, Sven Barth wrote: Am 29.11.2012 03:59, schrieb luiz americo pereira camara: As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. At least for COM interfaces "as" and "is" with a class type on the right side is supported. The corresponding code for Corba interfaces is not implemented (yet). This feature exists at least since 2.6.0. Well. I did not know of this feature. I should document it :-) If so, that solves Luiz' problem, since it would allow him to retrieve the object to use as an observer. I'm assuming that Luiz uses COM interfaces. Again: in this case, i don't use COM interfaces nor do i propose to use That's not what I meant with this statement: I meant that if you do happen to use COM interfaces for everything else, the above means you can get the object that's associated with it and pass it on as an observer, so the current implementation will work for you as it is now. If you use CORBA interfaces, it means you must wait till the corresponding code is implemented (which I am willing to do) for it to work. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
2012/11/29 : > > > On Thu, 29 Nov 2012, Sven Barth wrote: > >> Am 29.11.2012 03:59, schrieb luiz americo pereira camara: >>> >>> As is today, if you have a reference to a IFPObserver is not possible >>> to use it to attach to, e.g., child objects. This occurs because AFAIK >>> you can't get a TObject from a interface reference. >> >> >> At least for COM interfaces "as" and "is" with a class type on the right >> side is supported. The corresponding code for Corba interfaces is not >> implemented (yet). This feature exists at least since 2.6.0. > > > Well. I did not know of this feature. I should document it :-) > > If so, that solves Luiz' problem, since it would allow him to retrieve the > object > to use as an observer. > > I'm assuming that Luiz uses COM interfaces. Again: in this case, i don't use COM interfaces nor do i propose to use Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
Alexander Klenin wrote / napísal(a):
On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe wrote:
Will global variables and static global arrays be always initialized to
zero?
Yes.
Then I suggest to amend the first paragraph of
http://www.freepascal.org/docs-html/ref/refse22.html
which directly contradicts this.
I have rather curious story behind this request.
In Russia, schoolchildren must pass "Unified State Exam" ("ЕГЭ" in
russian) upon graduation.
The exam on informatics includes requirement to write a simple program.
Currently, the program is allowed to be written in any programming language,
but it is written on paper, the pupil must precisely specify the language,
and the program is graded manually by teachers.
Some pupils wrote in Free Pascal, which is moderately popular in schools
(something around 20% IIRC). Several of them omitted initialization of
global arrays
based on the assumption that they will be zeroed automatically.
Those pupils were failed for that, and the graders stated that even if
current implementation
happens to zero global variables, this is not documented and so is merely
an implementation artifact which must not be relied upon.
Hence, this omission resulted in lower grades for some schoolchildren.
Very nice story!
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
On Thu, 29 Nov 2012, Alexander Klenin wrote: On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe wrote: Will global variables and static global arrays be always initialized to zero? Yes. Then I suggest to amend the first paragraph of http://www.freepascal.org/docs-html/ref/refse22.html which directly contradicts this. It does not directly contradict this ? For local variables the statement is 100% correct. You must initialize local variables. For global variables, it's a different story. The last time that this discussion popped up - exactly 3 years ago in fpc-pascal - there was some confusion as to what is now exactly behaviour and what is spec for global variables. From what I can see in the archives, the FPC behaviour is to zero out because Delphi and TP do so. The Pascal spec is not to assume that it is zeroed out. So, based on the specs, the teachers are right. Based on docs as they are now, they are also right. The docs does not specifically say something about the difference between global and local variables. (unless I've missed it) But I will amend the docs. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe wrote:
>
>> Will global variables and static global arrays be always initialized to
>> zero?
>
> Yes.
Then I suggest to amend the first paragraph of
http://www.freepascal.org/docs-html/ref/refse22.html
which directly contradicts this.
I have rather curious story behind this request.
In Russia, schoolchildren must pass "Unified State Exam" ("ЕГЭ" in
russian) upon graduation.
The exam on informatics includes requirement to write a simple program.
Currently, the program is allowed to be written in any programming language,
but it is written on paper, the pupil must precisely specify the language,
and the program is graded manually by teachers.
Some pupils wrote in Free Pascal, which is moderately popular in schools
(something around 20% IIRC). Several of them omitted initialization of
global arrays
based on the assumption that they will be zeroed automatically.
Those pupils were failed for that, and the graders stated that even if
current implementation
happens to zero global variables, this is not documented and so is merely
an implementation artifact which must not be relied upon.
Hence, this omission resulted in lower grades for some schoolchildren.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests in Delphi XE3 regarding Type Helpers
In our previous episode, Sven Barth said: > > D:\testing\rechelp>dcc32 tthlpsize.pas > > Embarcadero Delphi for Win32 compiler version 24.0 > > Copyright (c) 1983,2012 Embarcadero Technologies, Inc. > > tthlpsize.pas(78) Fatal: F2084 Internal Error: SY3502 > Fascinating results... Thank you! :D QC #110917 > >> Otherwise: Thank you so far. :) > > As soon as it is finished, you go back to generics? :-) > > > I don't know yet what I'll finish first (this was just some > preparation), but I do hope that I'll get to decreasing my "feature > list" in the next weeks :D (and yes, this includes generics) I was just teasing. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] calling convention on mac
On 28 Nov 2012, at 22:23, Carlo Kok wrote: The constructor call abi was changed twice (1 or 2 years ago), the last change undid the first. I don't remember that one. Was that across released FPC versions? That said, yes, you are right, bugs should be fixed. I'd just like to be able to say "it works with all these versions", instead of specific ones. Well, depending on machine level compiler-implementation detail is the ideal recipe for trouble, no matter how useful the result may be. And while normally calling convention-related stuff would almost never change because it would break all interfacing with dynamic libraries compiled by previous FPC versions, in practice such FPC-compiled libraries are (fortunately) not in widespread distribution or use and hence we can still fix such bugs. External review or rigorous testing of the calling convention code in all possible scenarios could also help with getting everything fixed in one release, instead of piecemeal one change at a time. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests in Delphi XE3 regarding Type Helpers
Am 29.11.2012 10:39, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
For tthlperr2.pas it would have been interesting to see if the same
error is reported if a helper is in scope, but the method is invalid...
could you please repeat that test with a string helper and a string
constant?
tthlperr2.pas(15) Error: E2003 Undeclared identifier: 'DoTest2'
Somehow what I hoped for. :)
Or change the type of the int helper to "uint8" which seems to
have helped in the tthlpsize.pas test...
Only for unsigned constants. I tried, and the results are the same dotest2.
Even with the unsigned value. Only if I change dotest2 to dotest1 I get the
operator not applicable. So somehow the method name has prio over the
literal type mismatch
D:\testing\rechelp>dcc32 tthlpminus.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpminus.pas(14) Error: E2018 Record, object or class type required
tthlpminus.pas(15) Error: E2018 Record, object or class type required
tthlpminus.pas(17)
1. Typecasting the "42" literals to integer works
2. changing record helper type to "int64" doesn't.
3. Changing to smaller types (int8,int16) doesn't help.
4. changing to uint8 works for the "42" one, not for the "-42" one.
Ok... so Delphi does use the minimum required size for the constant.
For unsigned ones yes.
Good. Does "int8" help for the "-42"? What if you change it to
"(-42).DoTest"?
Then it passes for the signed (int8) type. So it seems there is no helper
that will accept both positive and negative literals.
Yes, that's true, but at least one can get negative literals passed to a
helper...
D:\testing\rechelp>dcc32 tthlpself.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpself.pas(36)
37 lines, 0.09 seconds, 18816 bytes code, 13240 bytes data.
D:\testing\rechelp>tthlpself
-> throws RTE 105
It seems that I forgot a "{$apptype console}" :)
42
21
Type Helper
Hello Type Helper World
Great... this does not make that feature easier to implement -.-
D:\testing\rechelp>dcc32 tthlpsize.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpsize.pas(24) Error: E2003 Undeclared identifier: 'Short'
tthlpsize.pas(78) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(80) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(82) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(84) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(87)
The first is easily fixable by changing short (which probably should have
been shortint) to int16.
The introduction of the (U)IntXX types was one of the best things I
remember (and luckily we already have them in FPC as well :) ), as I
always forget how the smaller types are named... -.-
Why do you think I added them when I found out? :-) I never could either.
(specially smallint and shortint)
The remaining errors are the negative values. I didn't find a solution for
them with tthlpminus
So the hexadecimal values work correctly?
Yes
What if you here also try the
suggestion "(negativevalue).DoTest"? You might also want to add a
"{$apptype console}" here.
Strange results. All compile except (-1)
Input:
Writeln(0, #9, 0.DoTest);
// Writeln(-1, #9, (-1).DoTest);
Writeln($ABCD, #9, $ABCD.DoTest);
Writeln(-32987, #9, (-32987).DoTest);
Writeln(2345678, #9, 2345678.DoTest);
Writeln(-2345678, #9, (-2345678).DoTest);
Writeln($1234567887654321, #9, $1234567887654321.DoTest);
Writeln(-9876543211234, #9, (-9876543211234).DoTest);
Writeln(9876543211234, #9, 9876543211234.DoTest);
Output:
0 Byte
43981 Word
-32987 LongInt
2345678 LongInt
-2345678LongInt
1311768467139281697 Int64
-9876543211234 Int64
9876543211234 Int64
... which seems to have a bias for signed types that I didn't see
in earlier tests.
I played a bit with the minus one value, and got an IE:
Writeln(-129, #9, (-129).DoTest);
caused:
D:\testing\rechelp>dcc32 tthlpsize.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpsize.pas(78) Fatal: F2084 Internal Error: SY3502
Fascinating results... Thank you! :D
Otherwise: Thank you so far. :)
As soon as it is finished, you go back to generics? :-)
I don't know yet what I'll finish first (this was just some
preparation), but I do hope that I'll get to decreasing my "feature
list" in the next weeks :D (and yes, this includes generics)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests in Delphi XE3 regarding Type Helpers
In our previous episode, Marco van de Voort said: I was still playing, and decided to replace smallinthelper with "int8" instead of smallint or whatever. That suddenly made small (-1,-2) values compile. The range -129 .. -32768 though gives the IE. Strangely, the testresult is -10 SmallInt ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] calling convention on mac
Op 28-11-2012 22:15, Jonas Maebe schreef: On 28 Nov 2012, at 22:04, Carlo Ko wrote: Op 28-11-2012 21:50, Jonas Maebe schreef: On 28 Nov 2012, at 21:36, Martin wrote: It does not matter if I compile it with stdcall, cdecl, pascal. The below on a 32 bit intel mac (fpc 2.6.0) always returns result in 2 registers (eax, edx) Is there a way to change this (some declaration in the source, some switch)? It's a bug that's fixed in trunk: http://wiki.freepascal.org/User_Changes_Trunk#Location_of_certain_function_result_types As the author of pascalscript, I wasn't aware of this issue, however now I'm in a dilemma. FPC breaks things very often, and that url shows just one of these. It's not useful to talk in general terms when discussing specific issues. Would you have preferred that this particular bug had remained in the compiler, in the interest of backward compatibility? I suppose you're right. I'm just frustrated. Additionally, the URL does not just show "one of these", but a "bunch of those". We do our best to document every such case, and always in the same place on the wiki. If I want to fix this bug in Pascal Script, I have to undo the fix in 6-12 months again (or use version specific defines). The correct fix is indeed an version-specific define. Oke. I'm getting a bit frustrated with FPC changing things back and forward all the time (this isn't a new thing, this has been going on since I first ported it to FPC). "back and forward" suggests that we change it in one way in one version, and then back again to the old behaviour in a successive version. Afaik that has never happened until now. We do occasionally fix bugs that break backward compatibility, but as explained above I don't see an alternative to leaving in such bugs forever. The constructor call abi was changed twice (1 or 2 years ago), the last change undid the first. That said, yes, you are right, bugs should be fixed. I'd just like to be able to say "it works with all these versions", instead of specific ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
Once upon a time, on 11/28/2012 03:40 PM to be precise, luiz americo pereira camara said: >>> So, i keep my points. Even because is not a big change with easy >>> implementation that will fix the above issues. >> >> It IS a big change. There is production code out there that uses this, >> and this is an incompatible change. > 1) The change in code can be tedious but is simple. from Attach(MyObj) > to Attach(MyObj as IFPObserver) To fix incompatibility wouldn't a simple operator overload do the trick? Operator := (a: TObject): IFPObserver; or something like that? -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On Thu, 29 Nov 2012, Sven Barth wrote: Am 29.11.2012 03:59, schrieb luiz americo pereira camara: As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. At least for COM interfaces "as" and "is" with a class type on the right side is supported. The corresponding code for Corba interfaces is not implemented (yet). This feature exists at least since 2.6.0. Well. I did not know of this feature. I should document it :-) If so, that solves Luiz' problem, since it would allow him to retrieve the object to use as an observer. I'm assuming that Luiz uses COM interfaces. But in the case he uses CORBA interfaces: What routine needs to be implemented to do this for Corba interfaces ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests in Delphi XE3 regarding Type Helpers
In our previous episode, Sven Barth said:
> For tthlperr2.pas it would have been interesting to see if the same
> error is reported if a helper is in scope, but the method is invalid...
> could you please repeat that test with a string helper and a string
> constant?
tthlperr2.pas(15) Error: E2003 Undeclared identifier: 'DoTest2'
>Or change the type of the int helper to "uint8" which seems to
> have helped in the tthlpsize.pas test...
Only for unsigned constants. I tried, and the results are the same dotest2.
Even with the unsigned value. Only if I change dotest2 to dotest1 I get the
operator not applicable. So somehow the method name has prio over the
literal type mismatch
> > D:\testing\rechelp>dcc32 tthlpminus.pas
> > Embarcadero Delphi for Win32 compiler version 24.0
> > Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
> > tthlpminus.pas(14) Error: E2018 Record, object or class type required
> > tthlpminus.pas(15) Error: E2018 Record, object or class type required
> > tthlpminus.pas(17)
> >
> > 1. Typecasting the "42" literals to integer works
> > 2. changing record helper type to "int64" doesn't.
> > 3. Changing to smaller types (int8,int16) doesn't help.
> > 4. changing to uint8 works for the "42" one, not for the "-42" one.
> Ok... so Delphi does use the minimum required size for the constant.
For unsigned ones yes.
> Good. Does "int8" help for the "-42"? What if you change it to
> "(-42).DoTest"?
Then it passes for the signed (int8) type. So it seems there is no helper
that will accept both positive and negative literals.
> > D:\testing\rechelp>dcc32 tthlpself.pas
> > Embarcadero Delphi for Win32 compiler version 24.0
> > Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
> > tthlpself.pas(36)
> > 37 lines, 0.09 seconds, 18816 bytes code, 13240 bytes data.
> >
> > D:\testing\rechelp>tthlpself
> > -> throws RTE 105
>
> It seems that I forgot a "{$apptype console}" :)
42
21
Type Helper
Hello Type Helper World
> > D:\testing\rechelp>dcc32 tthlpsize.pas
> > Embarcadero Delphi for Win32 compiler version 24.0
> > Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
> > tthlpsize.pas(24) Error: E2003 Undeclared identifier: 'Short'
> > tthlpsize.pas(78) Error: E2015 Operator not applicable to this operand type
> > tthlpsize.pas(80) Error: E2015 Operator not applicable to this operand type
> > tthlpsize.pas(82) Error: E2015 Operator not applicable to this operand type
> > tthlpsize.pas(84) Error: E2015 Operator not applicable to this operand type
> > tthlpsize.pas(87)
> >
> > The first is easily fixable by changing short (which probably should have
> > been shortint) to int16.
> The introduction of the (U)IntXX types was one of the best things I
> remember (and luckily we already have them in FPC as well :) ), as I
> always forget how the smaller types are named... -.-
Why do you think I added them when I found out? :-) I never could either.
(specially smallint and shortint)
> > The remaining errors are the negative values. I didn't find a solution for
> > them with tthlpminus
> So the hexadecimal values work correctly?
Yes
> What if you here also try the
> suggestion "(negativevalue).DoTest"? You might also want to add a
> "{$apptype console}" here.
Strange results. All compile except (-1)
Input:
Writeln(0, #9, 0.DoTest);
// Writeln(-1, #9, (-1).DoTest);
Writeln($ABCD, #9, $ABCD.DoTest);
Writeln(-32987, #9, (-32987).DoTest);
Writeln(2345678, #9, 2345678.DoTest);
Writeln(-2345678, #9, (-2345678).DoTest);
Writeln($1234567887654321, #9, $1234567887654321.DoTest);
Writeln(-9876543211234, #9, (-9876543211234).DoTest);
Writeln(9876543211234, #9, 9876543211234.DoTest);
Output:
0 Byte
43981 Word
-32987 LongInt
2345678 LongInt
-2345678LongInt
1311768467139281697 Int64
-9876543211234 Int64
9876543211234 Int64
... which seems to have a bias for signed types that I didn't see
in earlier tests.
I played a bit with the minus one value, and got an IE:
Writeln(-129, #9, (-129).DoTest);
caused:
D:\testing\rechelp>dcc32 tthlpsize.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpsize.pas(78) Fatal: F2084 Internal Error: SY3502
> Otherwise: Thank you so far. :)
As soon as it is finished, you go back to generics? :-)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
On Wed, 28 Nov 2012, luiz americo pereira camara wrote: Given the considerations i did about the observer feature, here are some simple projects that supports my concerns and therefore the request i made to change the interface of two functions. Test1 As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. This limits the programmer choice to use a TObject in such situations, in this case the Observer property. All objects in memory descend from TObject, so this is not a problem. COM provided objects are not supported. That would require COM interfaces. I have looked at your tests. They are IMHO rather theoretical and will not happen in real life. I can think of plenty of things that will not work even with TComponent or TObject. That doesn't mean they will happen. Your 'problem' is that you store only interfaces for objects that will observe. Indeed, this is a programming model I do not care to support *for observers*, because I do not think it is likely to happen in real life situations. I explain this below. Test3 Pretty simple: if you don't know if a TObject descendant instance implements a IFPObserver (most cases) you have to do a check before attaching to a IFPObserved otherwise an exception is raised. Let me get this straight: What you say is that you get from somewhere an unknown object (or an interface) and just decide to let it observe another object ? For what ? For fun ? That is a very strange argument. You don't "accidentally" observe. It is also not true that all objects A that have the IFPObserver interface are suitable to observe a particular object B. You observe for a purpose. I'll say even more: in most cases your observer will be written to specifically observe the observed class. You will not let object A observe object B for no good reason. Observing introduces an overhead. For this reason alone, you should not 'just observe'. A will observe B in order to react on changes that B reports, and A will act on these changes. In almost all cases, A will have specific knowledge about B: even if it is just that B has a published property named XYZ. So you will know in advance that when attaching A to B, that A will have the IFPObserver interface. Therefore your test to see if A has the observer interface is simply redundant. Anyway, all this is why I think that using an interface-based API has no value in this case. There will be an object somewhere that you will have written to do some observations and act on changes. All I require is that you use the actual object in the API. It's guaranteed to be there anyway. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Am 29.11.2012 10:12, schrieb Marco van de Voort: In our previous episode, Sven Barth said: As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. At least for COM interfaces "as" and "is" with a class type on the right side is supported. The corresponding code for Corba interfaces is not implemented (yet). This feature exists at least since 2.6.0. Also: You can get a tcomponent though, if you implement IInterfaceComponentreference TComponent implements this. I haven't tested that, but does "SomeCorbaInterface as SomeCOMInterface" work? Because maybe the IInterfaceComponentReference trick would only work if the interface I'm working on is also a COM interface (because it could rely on the existence of QueryInterface)... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests in Delphi XE3 regarding Type Helpers
Am 29.11.2012 10:07, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
Could someone with access to Delphi XE3 please compile and run the
attached tests and provide me with the output of the test or (in case of
an error) with the output of the compiler?
The tthlperrX.pas tests should not compile, so here I'd like to get the
error messages.
The other tests should compile, so please try to adjust them until they
do and report me any adjustments you made. If you can't get them to
compile then please report me the errors you get with the initial test file.
D:\testing\rechelp>dcc32 tthlperr1.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlperr1.pas(4) Error: E2018 Record, object or class type required
tthlperr1.pas(6)
D:\testing\rechelp>dcc32 tthlperr2.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlperr2.pas(14) Error: E2018 Record, object or class type required
tthlperr2.pas(15) Error: E2018 Record, object or class type required
tthlperr2.pas(17)
Ok, the error for tthlperr1.pas was expected (though I was curious what
the error message would be).
For tthlperr2.pas it would have been interesting to see if the same
error is reported if a helper is in scope, but the method is invalid...
could you please repeat that test with a string helper and a string
constant? Or change the type of the int helper to "uint8" which seems to
have helped in the tthlpsize.pas test...
D:\testing\rechelp>dcc32 tthlpminus.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpminus.pas(14) Error: E2018 Record, object or class type required
tthlpminus.pas(15) Error: E2018 Record, object or class type required
tthlpminus.pas(17)
1. Typecasting the "42" literals to integer works
2. changing record helper type to "int64" doesn't.
3. Changing to smaller types (int8,int16) doesn't help.
4. changing to uint8 works for the "42" one, not for the "-42" one.
Ok... so Delphi does use the minimum required size for the constant.
Good. Does "int8" help for the "-42"? What if you change it to
"(-42).DoTest"?
D:\testing\rechelp>dcc32 tthlpself.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpself.pas(36)
37 lines, 0.09 seconds, 18816 bytes code, 13240 bytes data.
D:\testing\rechelp>tthlpself
-> throws RTE 105
It seems that I forgot a "{$apptype console}" :)
D:\testing\rechelp>dcc32 tthlpsize.pas
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
tthlpsize.pas(24) Error: E2003 Undeclared identifier: 'Short'
tthlpsize.pas(78) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(80) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(82) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(84) Error: E2015 Operator not applicable to this operand type
tthlpsize.pas(87)
The first is easily fixable by changing short (which probably should have
been shortint) to int16.
The introduction of the (U)IntXX types was one of the best things I
remember (and luckily we already have them in FPC as well :) ), as I
always forget how the smaller types are named... -.-
The remaining errors are the negative values. I didn't find a solution for
them with tthlpminus
So the hexadecimal values work correctly? What if you here also try the
suggestion "(negativevalue).DoTest"? You might also want to add a
"{$apptype console}" here.
Otherwise: Thank you so far. :)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
In our previous episode, Sven Barth said: > > As is today, if you have a reference to a IFPObserver is not possible > > to use it to attach to, e.g., child objects. This occurs because AFAIK > > you can't get a TObject from a interface reference. > > At least for COM interfaces "as" and "is" with a class type on the right > side is supported. The corresponding code for Corba interfaces is not > implemented (yet). This feature exists at least since 2.6.0. Also: You can get a tcomponent though, if you implement IInterfaceComponentreference TComponent implements this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests of observer feature [was: Considerations about observer]
Am 29.11.2012 03:59, schrieb luiz americo pereira camara: As is today, if you have a reference to a IFPObserver is not possible to use it to attach to, e.g., child objects. This occurs because AFAIK you can't get a TObject from a interface reference. At least for COM interfaces "as" and "is" with a class type on the right side is supported. The corresponding code for Corba interfaces is not implemented (yet). This feature exists at least since 2.6.0. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tests in Delphi XE3 regarding Type Helpers
In our previous episode, Sven Barth said: > > Could someone with access to Delphi XE3 please compile and run the > attached tests and provide me with the output of the test or (in case of > an error) with the output of the compiler? > The tthlperrX.pas tests should not compile, so here I'd like to get the > error messages. > The other tests should compile, so please try to adjust them until they > do and report me any adjustments you made. If you can't get them to > compile then please report me the errors you get with the initial test file. D:\testing\rechelp>dcc32 tthlperr1.pas Embarcadero Delphi for Win32 compiler version 24.0 Copyright (c) 1983,2012 Embarcadero Technologies, Inc. tthlperr1.pas(4) Error: E2018 Record, object or class type required tthlperr1.pas(6) D:\testing\rechelp>dcc32 tthlperr2.pas Embarcadero Delphi for Win32 compiler version 24.0 Copyright (c) 1983,2012 Embarcadero Technologies, Inc. tthlperr2.pas(14) Error: E2018 Record, object or class type required tthlperr2.pas(15) Error: E2018 Record, object or class type required tthlperr2.pas(17) D:\testing\rechelp>dcc32 tthlpminus.pas Embarcadero Delphi for Win32 compiler version 24.0 Copyright (c) 1983,2012 Embarcadero Technologies, Inc. tthlpminus.pas(14) Error: E2018 Record, object or class type required tthlpminus.pas(15) Error: E2018 Record, object or class type required tthlpminus.pas(17) 1. Typecasting the "42" literals to integer works 2. changing record helper type to "int64" doesn't. 3. Changing to smaller types (int8,int16) doesn't help. 4. changing to uint8 works for the "42" one, not for the "-42" one. D:\testing\rechelp>dcc32 tthlpself.pas Embarcadero Delphi for Win32 compiler version 24.0 Copyright (c) 1983,2012 Embarcadero Technologies, Inc. tthlpself.pas(36) 37 lines, 0.09 seconds, 18816 bytes code, 13240 bytes data. D:\testing\rechelp>tthlpself -> throws RTE 105 D:\testing\rechelp>dcc32 tthlpsize.pas Embarcadero Delphi for Win32 compiler version 24.0 Copyright (c) 1983,2012 Embarcadero Technologies, Inc. tthlpsize.pas(24) Error: E2003 Undeclared identifier: 'Short' tthlpsize.pas(78) Error: E2015 Operator not applicable to this operand type tthlpsize.pas(80) Error: E2015 Operator not applicable to this operand type tthlpsize.pas(82) Error: E2015 Operator not applicable to this operand type tthlpsize.pas(84) Error: E2015 Operator not applicable to this operand type tthlpsize.pas(87) The first is easily fixable by changing short (which probably should have been shortint) to int16. The remaining errors are the negative values. I didn't find a solution for them with tthlpminus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Tests in Delphi XE3 regarding Type Helpers
Hello together! Could someone with access to Delphi XE3 please compile and run the attached tests and provide me with the output of the test or (in case of an error) with the output of the compiler? The tthlperrX.pas tests should not compile, so here I'd like to get the error messages. The other tests should compile, so please try to adjust them until they do and report me any adjustments you made. If you can't get them to compile then please report me the errors you get with the initial test file. Thank you. Regards, Sven program tthlperr1; begin 42.DoTest; // <- no helper in scope end. program tthlperr2; type TOrdinalHelper = record helper for LongInt // <- adjust type so that first call compiles! procedure DoTest1; end; procedure TOrdinalHelper.DoTest1; begin end; begin 42.DoTest1; // <- should work 42.DoTest2; // <- compile error end. program tthlpminus; type TOrdinalHelper = record helper for LongInt // <- adjust, so that test compiles procedure DoTest; end; procedure TOrdinalHelper.DoTest; begin Writeln(Self); end; begin 42.DoTest; -42.DoTest; end. program tthlpself; type TIntegerHelper = record helper for Integer procedure DoTest; end; TStringHelper = record helper for String procedure DoTest; end; procedure TStringHelper.DoTest; begin Writeln(Self); Self := 'Hello ' + Self + ' World'; end; procedure TIntegerHelper.DoTest; begin Writeln(Self); Self := Self div 2; end; var i: Integer; s: String; begin i := 42; i.DoTest; Writeln(i); s := 'Type Helper'; s.DoTest; Writeln(s); end. program tthlpsize; type TByteHelper = record helper for Byte function DoTest: String; end; TWordHelper = record helper for Word function DoTest: String; end; TLongWordHelper = record helper for LongWord function DoTest: String; end; TUInt64Helper = record helper for UInt64 function DoTest: String; end; TSmallIntHelper = record helper for SmallInt function DoTest: String; end; TShortHelper = record helper for Short function DoTest: String; end; TLongIntHelper = record helper for LongInt function DoTest: String; end; TInt64Helper = record helper for Int64 function DoTest: String; end; function TInt64Helper.DoTest: String; begin Result := 'Int64'; end; function TLongIntHelper.DoTest: String; begin Result := 'LongInt'; end; function TShortHelper.DoTest: String; begin Result := 'Short'; end; function TSmallIntHelper.DoTest: String; begin Result := 'SmallInt'; end; function TUInt64Helper.DoTest: String; begin Result := 'UInt64'; end; function TLongWordHelper.DoTest: String; begin Result := 'LongWord'; end; function TWordHelper.DoTest: String; begin Result := 'Word'; end; function TByteHelper.DoTest: String; begin Result := 'Byte'; end; begin Writeln(0, #9, 0.DoTest); Writeln(-1, #9, -1.DoTest); Writeln($ABCD, #9, $ABCD.DoTest); Writeln(-32987, #9, -32987.DoTest); Writeln(2345678, #9, 2345678.DoTest); Writeln(-2345678, #9, -2345678.DoTest); Writeln($1234567887654321, #9, $1234567887654321.DoTest); Writeln(-9876543211234, #9, -9876543211234.DoTest); Writeln(9876543211234, #9, 9876543211234.DoTest); end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
