Re: [fpc-devel] mips-linux and mipsel-linux snapshots available
On Mon, 17 Dec 2012, Nikolai Zhubr wrote: Hi Sergei and Mark, 16.12.2012 12:41, Sergei Gorelkin: [...] This was caused by insufficient alignment of Double-typed temp variables, fixed in r23146. Moreover, it appeared that function UnixToWinAge wasn't doing anything useful since year 2005, so it was removed in r23145, making FindFirst/FindNext routines somewhat faster (and able to run without FPU). Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll be able to reproduce it, too. This is to remind you guys that if you wish to do some testing/debugging/etc on a real mips device via ssh, two debian mips boxes (big and little endian) with plenty of disk space are running here 24/7 for exactly that purpose. They are not much loaded and I can create some account(s) for you any time. The FPC team has a MIPS device (longsoon?) available. It's currently switched off, but can be switched on at any time. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is this future save? class casting for var-param
On Mon, 3 Dec 2012, Martin wrote: having a procedure Foo(var x: TSomeClass); calling it with Foo(TSomeClass(ObjOfBaseClassOfTSomeClass)); It compiles with 2.6.0. Just want to be sure, it wont stop in future versions. It should not stop. 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 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]
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] 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 jonas.ma...@elis.ugent.be 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] Tests of observer feature [was: Considerations about observer]
On Thu, 29 Nov 2012, luiz americo pereira camara wrote: 2012/11/29 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 :-) 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] 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 jonas.ma...@elis.ugent.be 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
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] 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] 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: 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]
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] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Tue, 27 Nov 2012, luiz americo pereira camara wrote: 2012/11/27 Michael Van Canneyt mich...@freepascal.org: On Tue, 27 Nov 2012, luiz americo pereira camara wrote: Hi, i requested a change to observer interface with some considerations in http://bugs.freepascal.org/view.php?id=23394 It will not happen. If you want to pass around interfaces safely, then you need to implement them as descendents of IUnknown to maintain reference counts. They are implemented as CORBA interfaces exactly to avoid the overhead of IUnknown. The consequence is that you must pass around the objects themselves. I don't see the point. It would be true if the IFPObserved (e.g., TPersistent) takes ownership of the attached observers. That is not the case. Currently, in the observer feature, there's no difference between plain TObject and corba interface (IFPObserver) regarding the life cycle management. Correct. Both there are no guarantees that they will still be alive when accessed. The current approach limits the programmer flexibility and adds unnecessary overhead. As practical example take a LCL Form that is supposed to be observed. It takes an Observer property and attach it to certain child controls (TEdit etc) 1) Currently i'm forced to declare as the Observer property as an TObject. If i declare Observer property as IFPObserver i cannot attach to children controls. I do not understand this ? 2) Each time i attach to a child control this Observer property will be queried to see if implements IFPObserver (but we already know that it implements, we already checked !!!) You only gain speed when notifying. When calling FPOAttachAbserver or FPODetachAbserver, you would need to typecast some object anyway if we would change the interface, so there is no speed gain there... During notification, we can gain speed by internally storing the interface. 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. I can change the internals so speed is gained during notifyobservers, but I do not see sufficient reasons to change the interface and introduce an incompatibility. Michael. ___ 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]
On Wed, 28 Nov 2012, Vincent Snijders wrote: 2012/11/28 michael.vancann...@wisa.be It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. It's rather the opposite. This code was developed and has been in use since years. I simply integrated the code in the classes unit, making the production code simpler. Apart from that, I don't see the point in changing it to an interface. At some point, there must be an object, and at some point, there is a typecast, this is unavoidable. Nothing is gained by changing the API to use an interface. I can see the speed argument when notifying, but that can be changed by an internal change, without API changes. Michael. ___ 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]
On Wed, 28 Nov 2012, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. It's rather the opposite. This code was developed and has been in use since years. I simply integrated the code in the classes unit, making the production code simpler. Yes, and by doing that you submit it to public scrutiny, risking other opinions. Sure. Based on feedback, the interface was already changed slightly, but not in a super invasive way as asked here. Apart from that, I don't see the point in changing it to an interface. At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent What does reroot external components mean ? (and thus Tinterfacedobject), you can add an interface in a child class. The interfaces are CORBA, so there is no need for TInterfacedObject. That the interface is CORBA was a conscious decision so reference counting and all the overhead associated with it was avoided. As far as I know, this rules out COM provided interfaces (if this is what you refer to by external components). That is a tradeoff I find acceptable. I can see the speed argument when notifying, but that can be changed by an internal change, without API changes. As Paul and Vincent correctly state, from the view of the FPC project, the interface is not yet fixed. Correct. But I want to see some stronger reasons than the ones given before I change the API. Like I said: The one about speed in notifyupdates is not a problem, I'll improve that, implementation speed is important. Michael. ___ 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]
On Wed, 28 Nov 2012, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent What does reroot external components mean ? (Change the root of their inheritance tree. e.g. something that doesn't inherit from interfacedobject to inherit from it) (and thus Tinterfacedobject), you can add an interface in a child class. The interfaces are CORBA, so there is no need for TInterfacedObject. Ok. I assumed they also had to be COM compatible because of tiopf. That the interface is CORBA was a conscious decision so reference counting and all the overhead associated with it was avoided. As far as I know, this rules out COM provided interfaces (if this is what you refer to by external components). That is a tradeoff I find acceptable. For me personally that is unacceptable. But that is not with just an FPC hat on. The probability of using COM with the observer interface is IMHO almost zero. That's simply not the main intended use case, in casu: GUI elements observing business objects: both will normally be in-process. Given the benefit of no reference counting and all that implies (TInterfacedObject etc), it was obvious that CORBA interfaces were the way to go. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Memory Streams unable to handle reads past 2GB
On Mon, 5 Nov 2012, Andrew Brunner wrote: Same problem with TMemoryStream.Write :-( On 11/05/2012 10:09 PM, Andrew Brunner wrote: objpas/classes/classesh.inc TCustomMemoryStream function Read(var Buffer; Count: LongInt): LongInt; override; Having Read result declared as LongInt is problematic on 64 bit systems with large streams. Read result MUST be either PtrInt or Int64 but it cannot be LongInt. Since you can only read 2GB (Count is a longint) in a single read operation, it makes no sense to return a 64-bit result. Note that the operating system only allows 2Gb reads anyway, even on 64-bit systems. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Observer support in Delphi
On Tue, 23 Oct 2012, luiz americo pereira camara wrote: While looking for the new TextHint property in Delphi docs, i found that recent Delphi implements Observer support. See: http://docwiki.embarcadero.com/Libraries/XE3/en/System.Classes.TComponent.Observers http://docwiki.embarcadero.com/Libraries/XE2/en/System.Classes.TObservers_Methods Recently observer support was added to fpc. Just wondering what path fpc will follow: 1) Ditches the current fpc implementation and implements a Delphi compatible interface 2) Time to diverge from Delphi. Keeps fpc own implementation 3) Implement both interfaces Probably 3. However, given the total lack of documentation, it is hard to say. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Observer support in Delphi
On Wed, 24 Oct 2012, Graeme Geldenhuys wrote: On 2012-10-24 07:52, michael.vancann...@wisa.be wrote: However, given the total lack of documentation, it is hard to say. +1 I had a look too, the Embarcadero website isn't much help. From what I've seen, I can surmise it is geared towards their 'livebindings' feature. Seeing things like http://docwiki.embarcadero.com/Libraries/XE3/en/System.Classes.TLinkObservers.EditGridLinkEdit in the classes (!) unit, makes me shudder, though. How anyone can create such a convoluted system is beyond me. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Observer support in Delphi
On Wed, 24 Oct 2012, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: Recently observer support was added to fpc. Just wondering what path fpc will follow: 1) Ditches the current fpc implementation and implements a Delphi compatible interface 2) Time to diverge from Delphi. Keeps fpc own implementation 3) Implement both interfaces Probably 3. However, given the total lack of documentation, it is hard to say. I can still unmerge the observer functionality from fixes/2.6.2. Then (1) is also still a possibility. Not if I have anything to say about it :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC related fairy tale
On Thu, 18 Oct 2012, Sven Barth wrote: Hello together! Over the past weeks I've spent some time on getting something to work in FPC and now I'm about to commit this either this evening or at least this weekend (depending on the time I have). Now I thought that I'd make a little test to see how good you know FPC and thus I've written a little fairy tale which is more or less loosely based on the work I've done. One important note beforehand though: it may sound as if I'm critizing some actions of the other FPC core devs in this tale, but this is definitely NOT my intention, so take the story not too seriously, please ;) [and also keep in mind, please, that I'm not a native English speaker...] Hm. I've been on the core team since a very long time, but I don't have a clue what this is about. I can think of several things that could apply, but the story really doesn't give clear hints - well, not to me at least. (but then, I've never been good at symbolics) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Parser problems with C-Data and Character Encoding
On Thu, 27 Sep 2012, Andrew Brunner wrote: On 09/27/2012 04:19 AM, Mattias Gaertner wrote: Have you tried setting the right encoding in the xml? http://mantis.freepascal.org/view.php?id=22990 I have, and it did and it did work (thanks Sergei :-) Maybe you can explain what you are trying to do? I have a cloud social virtual operating system and each read/write operation is done via XML. So adding content encoding mechanism for comparing each byte is extremely costly from a client/server standpoint. Just imagine 1M+ users and having to encode/decode each xml fragment just to get the parser to parse the data - unwanted latency. AFAIK such statements have seldom a positive effect on volunteer projects. My frustration is not with FPC team, because they are drawing code from projects like firefox. To my knowledge, we are not ? I am extremely sensitive towards wasted cpu cycles as efficiency in scale is maximized by reducing things like byte encoding. Some of my stream fragments can be as large as 1.4MB deflated from 8MB. Multiply that number by say 100 concurrent users on that 1 node and you'll begin to see my frustration. If you are sensible to that, drop XML and use JSON. It will parse much faster, contains far less overhead (smaller packet size). It was invented exactly because XML became too heavyweight. I did some benchmarking. Using XML (well, SOAP) makes a typical application 6 times slower than a comparative binary transmission mechanism. To me, an XML parser is just looking for etc. Once it hits a CDATA section it should only look for ]]. Therefore I was surprised to learn that it required the encoding tag (which in itself just increased the average network packet size) that I must transmit from client to my server nodes. You cannot just choose which parts of XML to use, and which not. XML is highly standardized, and so are XML parsers. That is why people have standards. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 27 Sep 2012, at 15:51, Marcos Douglas wrote: What is the advantages to the compiler return the error bellow? ERROR: unit1.pas(31,3) Error: Duplicate identifier FooVar Why the compiler do not respect the scope, ie, the local variable should have the preference, I'm not right? Yes, but the human brain is very good at confusing such things, and it's very easy to accidentally assign something to a local variable instead of to a field. Only Pascal uses that way? No, the brain works that way. The FPC team decided to protect you from accidental mistakes by forbidding this special case in $mode objfpc. For me, it has become second nature never ever to have a variable with the same name as a property, even in Delphi. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: But this is a programmer's choice, ie, using or not the Self. The problem, IMHO, is that I can't choose when we talk about local variables. You can: Use delphi mode. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: Yes, it's always possible. In practice, I haven't seen this happen a single time in the 10+ years that the compiler has had this feature. That doesn't mean that it's impossible, but it's another factor in the good to have versus causes more harm than good equation. Well, happened on the own compiler. ;-) IMHO, these collisions happen a lot and because of this many programmers use prefixes in local variables, see: lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.). Exactly. The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Using Macros for IInterface
On Wed, 26 Sep 2012, Graeme Geldenhuys wrote:
On 2012-09-25 22:16, Henry Vermaak wrote: I've used a macro for this in the
past. E.g. :
{$macro on}
{$ifdef windows}
{$define CCONV:=stdcall}
{$else}
{$define CCONV:=cdecl}
{$endif}
Then use CCONV where you would specify the calling convention.
Couldn't something like this be applied to IInterface too? So we can get rid
of those horrible IFDEF lines. If you don't know what I am talking about,
have a look at the IInterface definition.
IUnknown = interface
['{---C000-0046}']
function QueryInterface({$IFDEF
FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} iid : tguid;out obj) :
longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
function _AddRef : longint;{$IFNDEF
WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
function _Release : longint;{$IFNDEF
WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
end;
IInterface = IUnknown;
And all those IFDEF's must go in your own code too when you implement a class
with IInterface support. Yuck!!
Since years I am a proponent of a libcall calling convention which translates
to the
common library calling convention for the platform. i.e. stdcall on windows,
cdecl on all other platforms. A much cleaner solution IMHO.
The FPC_HAS_CONSTREF should disappear as soon as the RTL must not be
compilable with a previous version that does not have CONSTREF.
(which in fact could be 2.6.0, but someone would have to confirm that)
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Using Macros for IInterface
On Wed, 26 Sep 2012, Sven Barth wrote:
Am 26.09.2012 12:28, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
end;
IInterface = IUnknown;
This depends on whether we want to enable $macro in the system unit...
It doesn't work at all since macro's don't export over unit borders.
Nowhere did I mention that it needs to be exported... that's why I thought of
the following as a convention.
My suggestions (if we do indeed enable it):
intfconst for constref/const
intfdecl for stdcall/cdecl {I would not use extdecl so that there are no
potential conflicts}
libcall was already mentioned. It also helps in a lot of other places, and
kills ninetynine percent of macro use. (which IMHO is always a good thing)
The question is then whether this should indeed be a new calling convention
or merely something that translates to stdcall/cdecl...
I would be in favour of handling it at the level of the parser, but
simply translate to cdecl/stdcall.
I would not use a macro that is handled on the level of the scanner.
The parser has more info at it's disposal, which could be useful if the
behaviour needs to be refined.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] inode number
On Mon, 24 Sep 2012, Michael Schnell wrote: In the RTL, is there an encapsulation for finding the inode number of a file in an extX file system ? Or dis anybody already do code for this ? You need to use the fpstat function for this. The stat record contains the inode number. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] URIParser is not up to spec
On Wed, 19 Sep 2012, Sergei Gorelkin wrote: 19.09.2012 11:45, Graeme Geldenhuys пишет: Hi, I have to deal with complex URL's in a new part in my project, and thought I would take advantage of the already existing URIParser unit in FPC. At closer inspection I noticed that the URIParser is not up to RFC-3986 specs. Even some of the terminology and values used in URIParser is different to the official RFC's. Would anybody mind if I updated the URIParser unit to be more correct, or is it the FPC pereference to leave it as it is, and I'll make my own amendments for my project. http://tools.ietf.org/rfc/rfc3986.txt Originally uriParser code was written to handle only URLs, without RFC3986 in mind. Later I updated it so the logic became closer to RFC3986, but had to keep URI syntax components as is in order to preserve compatibility with existing code. So I think if we go after strict RFC compliance, we should introduce a new unit and deprecate an old one. I agree. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and arguments with quotes
On Wed, 5 Sep 2012, Martin wrote: From http://bugs.freepascal.org/view.php?id=22801 You should not pass quotes. The quotes are only needed in a shell. That is not always possible. And the quotes work on most platforms. Windows is an exception (as usual). See below. I know TProcess changed from a single command-line to a listof arguments. So I couldn't find the User Changes note for this. You don't need the 'User changes'. It is documented. Press F1. An application may however have a list of arguments in a single string (e.g. the IDE ask the user to specify extra arguments. This can be 0, 1 or many) So ? Those must be broken into individual strings. TProcess does that if send as command line. No, it does not break anything down. On non-windows, each element in the params list is passed as-is in the argv array; No changes are performed at all. On windows, each string is surrounded by quotes if there is a space and no quotes in the string. The string itself is not touched. This is necessary because the Windows API (CreateProcess) requires a single string: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Note that the API does not mention anywhere how quotes or spaces should be handled. The reason is that the started application on windows is supposed to handle its own command-line processing. Unlike Unix, the started application gets the whole command-line and is supposed to take care of everything by itself. How it does this is ruled by custom only. In short: Windows doesn't cater very well for the command-line. What quoting may work for application 1, may not work for application 2. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and arguments with quotes
On Wed, 5 Sep 2012, michael.vancann...@wisa.be wrote: On Wed, 5 Sep 2012, Martin wrote: From http://bugs.freepascal.org/view.php?id=22801 You should not pass quotes. The quotes are only needed in a shell. That is not always possible. And the quotes work on most platforms. Windows is an exception (as usual). See below. I know TProcess changed from a single command-line to a listof arguments. So I couldn't find the User Changes note for this. You don't need the 'User changes'. It is documented. Press F1. An application may however have a list of arguments in a single string (e.g. the IDE ask the user to specify extra arguments. This can be 0, 1 or many) So ? Those must be broken into individual strings. TProcess does that if send as command line. No, it does not break anything down. On non-windows, each element in the params list is passed as-is in the argv array; No changes are performed at all. On windows, each string is surrounded by quotes if there is a space and no quotes in the string. The string itself is not touched. This is necessary because the Windows API (CreateProcess) requires a single string: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Note that the API does not mention anywhere how quotes or spaces should be handled. I should specify here: for parameters. For the binary, it is specified, because of the spaces in the path. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and arguments with quotes
On Wed, 5 Sep 2012, Martin wrote: On 05/09/2012 10:38, Martin wrote: function RunCommand(const cmdline:string;var outputstring:string):boolean; deprecated; Sorry seen to late, it is deprecated... Seems that FPC is missing the functionality for commandline (which is a property that existed for very long). Seen that it is now deprecated probably means there are no plans to implement it? Correct. However the reason On 05/09/2012 10:00, Marco van de Voort wrote: The reason why tprocess changed to a list is to avoid the need to concatenate arguments (and thus split them again). So in time it is urgently recommended to follow that. does not explain the lack of a working command line property. For code that has already individual params, the new Parameters[] property could live together with a fully implemented commandline. The reason we want to get rid of the commandline is EXACTLY what you are experiencing. The quoting rules, which are non-existent and application specific on Windows, and which cause nothing but problems on Unix because most people do not understand them. To avoid these, we switched to Parameters. They have the benefit of a simple use, and it is easier to 'imitate' windows using the unix Argv paradigm than vice versa. Namely: it avoids parsing. Assuming, that there are many apps that have a single string, IMHO it would be a good idea to add this functionality in fpc. It will not be added to TProcess. On the contrary: CommandLine is marked deprecated becase it will disappear. I have explained what to do, I will check if the documentation needs some enhancements. But you must use parameters correctly. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TProcess and arguments with quotes
On Wed, 5 Sep 2012, Marco van de Voort wrote: In our previous episode, Martin said: function RunCommand(const cmdline:string;var outputstring:string):boolean; deprecated; Sorry seen to late, it is deprecated... Seems that FPC is missing the functionality for commandline (which is a property that existed for very long). Seen that it is now deprecated probably means there are no plans to implement it? Nope. Actually issues like this were the reason to deprecate it. There barely has been a FPC version without changes to the quoting, and every usage could possibly break something else again. Users also seemed to be unable to handle the difference between api and shell, which also caused constant confusion. Exactly. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implementing a Dataset
On Mon, 3 Sep 2012, Felipe Monteiro de Carvalho wrote: On Mon, Sep 3, 2012 at 11:18 AM, michael.vancann...@wisa.be wrote: I think your best bet is to create a descendent of TBufDataset: it is in itself a full TDataset. You'll have to implement the least amount of methods there, and you can see in TSQLQuery which ones. But why would this be a better solution? TBufDataset is huge ... it me it looks much harder to understand how it works and subclass it then to attempt to start with empty methods and see if implementing something on them will work. Believe me, it is not :-) And do not forget, you don't need to do TBufDataset, but TSQLQuery. That just implements a few simple things. The rest is taken care of by TBufDataset. In essence you need to define which fields you need (i.e. populate TFieldDefs) and then a routine to copy data from the source to the buffer, and vice versa. If you want, you can also look at the JSON Dataset. That is quite simple. 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 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 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 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] Does FPC optimize unused parameters ?
On Wed, 8 Aug 2012, Jonas Maebe wrote:
Martin wrote on Wed, 08 Aug 2012:
Out of curiosity. Is there an optimization like this
[removing calculation/load of unused parameters]
No.
(or is it possible?
After the body of the called routine has been parsed, it would be possible in
theory (with indeed all the caveats the compiler would have to take care of
such as side effects -- note that these may include non-obvious side-effects,
such as potential overflow exceptions and invalid pointer accesses).
You'd need to check the caller routine as well, values for parameters might
still be used after the call to the function.
Dbg:=SomeCalculatingFunction+' Some message';
DebugLn(Dbg); // If debugln is empty, you don't need dbg for it, so the
previous call is not needed.
Writeln(dbg); // but you need it here.
And you don't know what SomeCalculatingFunction may have as side effects.
Function SomeCalculatingFunction : String;
begin
LastKnownAlive:=Now;
Result:=DateTimeToStr(LastKnownAlive);
end;
If the call to this function is optimized away, LastKnownAlive is not updated
correctly
any more...
Of course, all highly theoretical.
I still use ifdefs for debug messages, and have a template to quickly insert :
{$ifdef debugmsg}SendDebug('|');{$endif debugmsg}
This way, there is no extra code in my final build.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Opening FPC base classes
On Mon, 23 Jul 2012, Martin Schreiber wrote: Hi, I am the author of MSEide+MSEgui, a Free Pascal development environment: http://sourceforge.net/projects/mseide-msegui/ MSEide+MSEgui is not Delphi compatible and handles some basic TComponent issues differently to Lazarus: http://www.lazarus.freepascal.org/ Is it possible to add protected //for toolkit access only property OwnerPrivate: TComponent read FOwner write FOwner; deprecated; property NamePrivate: TComponentName read FName write FName; deprecated; property ComponentsPrivate: TfpList read FComponents write FComponents; deprecated; property ComponentStatePrivate: TComponentState read FComponentState write FComponentState; deprecated; property FreeNotifiesPrivate: TFpList read FFreeNotifies write FFreeNotifies; deprecated; to TComponent in order other toolkits than Lazarus can fulfil their taskwithout the necessity of changes in the FPC RTL? These fields must remain private to ensure proper functioning of the component system. Too much depends on the proper functioning of the notification API and the owner/owned relations and its inherent memory management. We can discuss alternative solutions for the tasks you need to do, if you'd care to explain them in detail. TReader and TWriter are classes which normally are used by frameworks only. Is it possible to move all private fields of TFiler, TReader and TWriter to protected in order other toolkits than Lazarus can fulfil their task without the necessity of changes in the FPC RTL? No problems here, we can give protected access to all of these fields. Is it possible to add protected //for toolkit access only property HandlePrivate: THandle read FHandle write FHandle; deprecated; to THandleStream No problems here. We can do this as well, provided we can make the signature slightly different: protected Procedure SetHandle(AHandle : THandle); virtual; property HandlePrivate: THandle read SetHandle SetHandle will just set the FHandle fields, but I want a virtual setter so descendent classes get a chance to react on the change in case they need to. and protected //for toolkit access only property CapacityPrivate: PtrInt read FCapacity write FCapacity; deprecated; to TMemoryStream? TMemoryStream.Capacity is already read/write. Why do you think you need direct access to the field ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Opening FPC base classes
On Mon, 23 Jul 2012, Martin Schreiber wrote: On Monday 23 July 2012 15:31:42 michael.vancann...@wisa.be wrote: I don't see why you cannot do the same. It's perfectly possible to use the streaming system for both TComponent and other classes. All it takes is RTTI, which happens to be enabled in TPersistent. Because of integration of third party components. But you are probably right, it seems to be the time to leave FCL compatibility. The design of TPersistent/TComponent and the whole classes unit has been made by Borland so that it made the development of a concurrent IDE to Delphi as difficult as possible. I've never seen it as such. There is nothing special about the classes unit. It uses available RTTI in a certain way, that's it. You're free to create a system that uses the same RTTI in a completely different way, and build an eco system around this. That you then cannot use code that expects the functionality of the classes unit, is a consequence you must accept. I hope Free Pascal has not the same attitude. ;-) Well, for starters, I don't draw the same conclusion as you: You don't need to leave compatibility behind. IMO it is perfectly possible to design a streaming system that streams both TComponents as non-TComponents, given a few small changes to TFiler. That would allow you to re-use third-party TComponent descendents and still offer all the things you need in msegui/mseide. I see that as a useful extension, and you can always ask for changes that would make this possible. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packpage Installer.
On Fri, 20 Jul 2012, Cristofer Martins wrote: I think it could be very usefull for all the comunity. Python have pypi and ruby have ruby Gems, FreePascal having its own easy way of install/uninstall packpages would make installing and using packpages easy, with a good standard library, FreePascal can truly shiny. This exists already. fmpake and fppkg. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Wed, 18 Jul 2012, Martin Schreiber wrote: On Tuesday 17 July 2012 09:40:36 michael.vancann...@wisa.be wrote: Maybe, but what about performance? Another complication is the updatebuffer with the oldvalues. Thinking about it: I would allocate the buffer as is, with for all string fields an integer-sized slot in the buffer. The slot contains an index, pointing to a separate array of strings containing N*M*2 strings. (N=number of records, M= Number of string fields per record, factor 2 for old values) Field value = Element [Index [+1 for old value]] in the array. where the [Index] is stored in the buffer. The speed performance penalty of this system should be negligable, since you assume all records are in memory anyway. And: everything can be done without meddling with the internals of TField. Thank you. There are more items in the db.pas list... But I think first we should concentrate on classes.pas because I really don't want to fork it. Forking db.pas is less problematic and I probably prefer it in place of an endless discussion and in my eyes not optimal solutions. With a forked db.pas I can eliminate the many workarounds I already had to implement. Currently needed crackerclasses by MSEide+MSEgui: Used by MSEide for different tasks (example: ask for ancestor forms and frames/submodules while loading a form/datamodule, recover in case of an error) and for streaming of frames with additional components/widgets: TComponent: - FComponents - FComponentState - FFreeNotifies Descendent classes should not manipulate these except through the right methods such as insert/remove component and FreeNotification/RemoveFreeNotification ? You have the means to manipulate the contents, what is wrong ? TWriter: - FPropPath - FAncestors I see no problem in making these available as read-only protected properties. TReader: - FStream - FLoaded Used in order TParams create tmseparam items instead of TParam: TCollection: - FItemClass A collection must always contain the same items. The class is determined when the collection is instantiated. Used to unify memorystreams/files/pipes/sockets/stringstreams: THandlestream: - FHandle The handle is fixed throughout the lifetime of the stream. It is set when creating the stream, and closed when destroying the stream. TMemoryStream: - FCapacity What is wrong with the r/w property Capacity ? I think you are missing an important point: You want some radical changes, so I expect you to be the one giving the reasons/motivations for a change. I want to help find solutions, but not at the price of destroying what is in my eyes a correctly constructed class hierarchy. If you don't give a detailed explanation why you need to manipulate all these private fields outside of the proper methods, then I cannot help you find solutions for the problems you experience, so please: elaborate. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Wed, 18 Jul 2012, Martin Schreiber wrote: On Wednesday 18 July 2012 08:19:02 Martin Schreiber wrote: Used in order TParams create tmseparam items instead of TParam: TCollection: - FItemClass Probably can be solved in a forked db.pas Or by 2 other solutions: * having a global variable ParamsClass : TParamsClass and use that whenever a TParams instance is created. * Or have a virtual function CreateParams which is used everywhere. There are always other solutions. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Wed, 18 Jul 2012, Martin Schreiber wrote: On Wednesday 18 July 2012 09:33:09 michael.vancann...@wisa.be wrote: I think you are missing an important point: You want some radical changes, so I expect you to be the one giving the reasons/motivations for a change. I want to help find solutions, but not at the price of destroying what is in my eyes a correctly constructed class hierarchy. If you don't give a detailed explanation why you need to manipulate all these private fields outside of the proper methods, then I cannot help you find solutions for the problems you experience, so please: elaborate. If I only could be sure that it is worth the effort... Does this mean you're not even going to try ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Tue, 17 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 17:25:58 michael.vancann...@wisa.be wrote:
On Mon, 16 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote:
Well, from your code adding the following to the protected section:
Property ValueBuffer : Pointer Read FValueBuffer;
Property Validating : Boolean Read FValidating ;
Should be enough to remove the need for the TFieldCracker ?
Unfortunately no:
procedure tmsebufdataset.checkfreebuffer(const afield: tfield);
begin
{$ifdef FPC}{$warnings off}{$endif}
with tfieldcracker(afield) do begin
{$ifdef FPC}{$warnings on}{$endif}
if foffset and 2 0 then begin
freemem(fvaluebuffer);
fvaluebuffer:= nil;
end;
end;
end;
If I understand correctly, you have in the record buffer just the pointer
of the (wide)string instead of the actual string data ?
Correct. The UnicodeString pointer. That has not directly to do with the
procedure above BTW. This one is to allow changing field values in OnValidate
IIRC.
If so, why then didn't you implement the string fields as blobs are
implemented in SQLDB (it is basically the same problem), in that case you
would not need the internal fields of TField at all ?
Maybe, but what about performance? Another complication is the updatebuffer
with the oldvalues.
Thinking about it:
I would allocate the buffer as is, with for all string fields an
integer-sized slot in the buffer. The slot contains an index, pointing
to a separate array of strings containing N*M*2 strings. (N=number of
records, M= Number of string fields per record, factor 2 for old values)
Field value = Element [Index [+1 for old value]] in the array.
where the [Index] is stored in the buffer.
The speed performance penalty of this system should be negligable, since you
assume all records are in memory anyway.
And: everything can be done without meddling with the internals of TField.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Sun, 15 Jul 2012, Martin Schreiber wrote: On Sunday 15 July 2012 19:21:58 Michael Van Canneyt wrote: On Sun, 15 Jul 2012, Martin Schreiber wrote: Currently I need access to the following private FCL class fields because of MSEide+MSEgui extensions: I have looked at your list. (I sent my previous mail about this without having seen the list) At first sight, I see no reason to make any of these fields protected. Jup, I feared it. ;-) I wrote 'at first sight', because without explanation I don't know what you try to achieve. For example: TParam.FBound Is directly accessible through TParam.Bound, so why on earth would you need to have it protected ?? Hmm, this probably is a mistake from me. Was it writeable in all FPC versions? This I don't know. At least, now it is writable. Can you give some explanations at least of what you're trying to do, maybe we can find workarounds for your problems ? Before I started to use cracker classes I searched workarounds for weeks or even months already... 2 pairs of eyes always see more than one. If you want you can grep the MSEide+MSEgui sources for cracker in order see what I do with them. That does not tell me why you do something ? TComponent, TWriter, TReader for example because in MSEide+MSEgui one can place additional components in an inserted tframe and combination of inherited frames and inherited forms need special handling. Basically, you want to drop a component on a Form containing a frame, and make it's owner the frame ? The DB components mainly because MSEgui stores string fields as UnicodeString in datasets and because of the direct data access by index without scrolling. So you take away the concept of cursor. That is a radical change. This assumes that all records are always in memory ? The string fields should not necessitate the access of private fields, you can just always create TWideStringField instances ? Maybe we need a function to decide the class of a string field ? The stream components because in MSEgui there is a single hierarchy for file and memory stream so the more specialized descendants (ttextstream, ttextdatastream) can work on files and on memory. I'm sorry, I don't understand what this means ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Mon, 16 Jul 2012, Mattias Gaertner wrote: On Mon, 16 Jul 2012 09:35:16 +0200 (CEST) michael.vancann...@wisa.be wrote: [...] TComponent, TWriter, TReader for example because in MSEide+MSEgui one can place additional components in an inserted tframe and combination of inherited frames and inherited forms need special handling. Basically, you want to drop a component on a Form containing a frame, and make it's owner the frame ? I guess he meant adding a component with Owner=Form, Parent=nested frame As far as I remember TReader (or TWriter I'm not sure) does not support this. Lazarus artificially forbids this too. Internally most code supports this. I see no reason why TWriter would not support this, because it uses GetChildren to get the list of children ? There must be something else. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Mon, 16 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 09:35:16 michael.vancann...@wisa.be wrote:
The DB components mainly because MSEgui stores string fields as
UnicodeString in datasets and because of the direct data access by index
without scrolling.
So you take away the concept of cursor. That is a radical change.
The cursor concept still exists, direct access without scrolling is an
extension.
This assumes that all records are always in memory ?
In tmsebufdataset yes.
I will look at what can be done here.
The string fields should not necessitate the access of private fields, you
can just always create TWideStringField instances ?
TWideStringField probably can not handle the MSEgui storage of UnicodeString
with variable length in datasets.
The code of tmsestringfield:
[...]
function tmsebufdataset.getmsestringdata(const sender: tmsestringfield;
out avalue: msestring): boolean;
var
po1: pointer;
int1: integer;
begin
{$ifdef FPC}{$warnings off}{$endif}
with tfieldcracker(sender) do begin
{$ifdef FPC}{$warnings on}{$endif}
if fvalidating then begin
result:= (fvaluebuffer nil) and (foffset and 1 = 0);
So you need to access to
FValueBuffer : Pointer;
FValidating : Boolean;
I can make these available as protected properties.
Maybe we need a function to decide the class of a string field ?
Probably does not help if the descendant can not access private base fields.
Well, from your code adding the following to the protected section:
Property ValueBuffer : Pointer Read FValueBuffer;
Property Validating : Boolean Read FValidating ;
Should be enough to remove the need for the TFieldCracker ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class field reordering
On Mon, 16 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote:
Well, from your code adding the following to the protected section:
Property ValueBuffer : Pointer Read FValueBuffer;
Property Validating : Boolean Read FValidating ;
Should be enough to remove the need for the TFieldCracker ?
Unfortunately no:
procedure tmsebufdataset.checkfreebuffer(const afield: tfield);
begin
{$ifdef FPC}{$warnings off}{$endif}
with tfieldcracker(afield) do begin
{$ifdef FPC}{$warnings on}{$endif}
if foffset and 2 0 then begin
freemem(fvaluebuffer);
fvaluebuffer:= nil;
end;
end;
end;
If I understand correctly, you have in the record buffer just the pointer of
the (wide)string instead of the actual string data ?
If so, why then didn't you implement the string fields as blobs are implemented
in SQLDB (it is basically the same problem), in that case you would not need the
internal fields of TField at all ?
If that is not possible, it means you need a mechanism to 'finalize' the record
buffer
whenever it is re-filled or goes out of scope ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to delete cookie in fcl-web?
On Mon, 2 Jul 2012, silvioprog wrote: Hello, What better way to delete a cookie using fcl-web? Remembering that to delete a cookie simply set the 'Thu, 01-Jan-70 00:00:01 GMT' date to expires property. There is a demo in freepascal showing how to do this? I think it would be interesting to have a method to do this. :/ Presumably a ExpireCookie method can be added to TCookie. This simply sets the date to the correct value. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Windows 64bit SEH exception handling
On Wed, 20 Jun 2012, Sergei Gorelkin wrote: 19.06.2012 23:43, tomek пишет: Hello, with reference to http://bugs.freepascal.org/view.php?id=12742 about random crash with Windows OpenDialog Box only on Win7 64bit. Today I compile trunk-fpc with TEST_WIN64_SEH support and it seems that this bug is resolved with SEH. I checked a few times to make sure that this is due to SEH support. My question is, why? how is it possible that support for SEH exceptions handling fix OpenDialog issue ? or perhaps an exception is hidden ? as described in http://support.microsoft.com/kb/976038 do have you any suggestions ? Non-SEH exception handling on Win64 is known to handle exceptions too early, bypassing frame-based handlers and therefore disrupting the intended control flow. Most probably the exception under question was meant to be handled within OS libraries and not passed to the application. It makes you wonder why they created 2 systems in the first place... Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parallel procedures
On Fri, 15 Jun 2012, Mattias Gaertner wrote: Hi, FPC does not yet have parallel loops/procedures, but there is a unit that helps to create parallel procedures/methods (mtprocs). http://wiki.freepascal.org/Parallel_procedures I use this unit since 4 years in several of my projects, which run on linux, os x and windows. Not much was done on the unit in the last years, because it simply works. mtprocs implements a thread pool, although it is not a general purpose one. It uses one extra unit mtpcpu, which has a function to guess the number of cores. I think both features would be nice to have in fpc by default, so maybe they should be added. What do you think? Pending language support for parallellism, I think this is a good idea. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
On Wed, 2 May 2012, Martin Schreiber wrote: On 01.05.2012 17:37, Michael Van Canneyt wrote: As written before, in MSEgui I'll define a bookmarkty type, so MSEgui users have bookmarkty in order to avoid the warning. FPC and Lazarus probably can't do the same because of Delphi compatibility. Suggestion: remove deprecated from TBookmarkStr in fixes_2_6. Well, I think it is better to warn people of a coming change. So I have added a description that warns people that it will disappear in 2.6.3. For users who do not want to see the deprecated warnings in fixes_2_6 do In MSEide+MSEgui: Use bookmarkty instead of TBookmarkStr for bookmark variables. In Lazarus: Use string instead of TBookmarkStr for bookmark variables. This last one is bad advice, this code will break as soon as they switch to 2.6.3. Which, presumably, eventually they will. If you really want to avoid the messages, it is better to use TBookmark, GetBookmarkData and FreeBookmark. That will not generate warnings and will continue to work with 2.6.3. Or you can simply ignore the warnings, which is by far the easiest option. I can't believe people are making such fuss over a couple of warnings. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
On Wed, 25 Apr 2012, Marco van de Voort wrote: In our previous episode, Ludo Brands said: that is increasingly happening, with the first D7 supports disappearing) The underlying problem is that the Delphi Tbookmark definition migrated from the simple record tag to something that holds (or can hold) the state of the record. A reason the more to not rely on implementation details, but treat it as an opague type as much as possible. But note that changing it to tbytes IMHO doesn't mean you can skip freebookmark, if you do that you cut corners, and program for a specific tdataset OK. I understand your point. But now that the dataset implementers, who follow 2.7.1 as you indicated, have added freebookmark to their code, can we move on the next phase: tbytes? No need to linger on TBookmark=pointer. Well, are you sure that the whole FPC+Lazarus codebases properly use freebookmark everywhere? Definitely not. I've never used it in my life. It was the whole point of having TBookmarkStr: not needing to call freebookmark. And we use bookmark a lot in our server app. IMHO FreeBookmark is a relic of the Delphi 12 days. The switch to a managed TBytes only reinforces this hypothesis. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: sqlDB extend TStatementType
On Thu, 19 Apr 2012, LacaK wrote: Hi , now we have in sqlDB.pp: TStatementType = (stNone, stSelect, stInsert, stUpdate, stDelete, stDDL, stGetSegment, stPutSegment, stExecProcedure, stStartTrans, stCommit, stRollback, stSelectForUpd); Statement type is initialy determined by parsing SQL.Text in function TCustomSQLQuery.SQLParser and function TSQLConnection.StrToStatementType based on first word (token) of SQL.Text. (i.e. 'SELECT ...' - stSelect, 'INSERT ...' - stInsert, 'CREATE ...' - stDDL, etc.) As you can see there is very limited count of sql statements which are recognized (but this is not problem ;-)). Statement types stSelect and stExecProcedure have special meaning, because only these two types are allowed when using Open method (i.e. only these two types are expecting, that return any data rows; see procedure TCustomSQLQuery.InternalOpen; ) In fact, this is not quite correct. Insert into table (a,b,c) returning values (x,y,z) can also be done with an Open, yet it will probably get stInsert as type. Due to this fact also other sql statements like SHOW, PRAGMA, TRANSFORM, MySQL Admin.statements (CHECK TABLE, REPAIR TABLE etc.) which return data are mapped to stSelect (and others ATM unhandled like CTEs 'WITH ...' and 'PIVOT ...' etc. must in future also map to stSelect). This is OK as far as we do not expect, that stSelect = 'SELECT ...' , which is NON-intuitive assumption. So I am thinking about adding new statement type stQuery and map all other than 'SELECT ...' statements that return dataset to this general statement type. ( See also http://docwiki.embarcadero.com/VCL/en/DB.TPSCommandType and http://docwiki.embarcadero.com/VCL/en/IBSQL.TIBSQLTypes ) But because this change is not unavoidable I am not sure if go this way or leave it as is and definitely abandon that stSelect is 'SELECT ...' ? What do you think ? It is not clear to me what are you trying to accomplish with this change ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: sqlDB extend TStatementType
On Thu, 19 Apr 2012, LacaK wrote: In fact, this is not quite correct. Insert into table (a,b,c) returning values (x,y,z) can also be done with an Open, yet it will probably get stInsert as type. This case is handled in PrepareStatement phase. In case of IBConnection is StatementType re-mapped to stExecProcedure and in case of PQConnection is re-maped to stSelect. That should obviously be changed to return the same type :-) But because this change is not unavoidable I am not sure if go this way or leave it as is and definitely abandon that stSelect is 'SELECT ...' ? What do you think ? It is not clear to me what are you trying to accomplish with this change ? Hm, good point ;-) Answer depends on answer of question what is purpose of StatementType ? What kind of information do we expect ? How detailed ? In my mind is strange if stSelect is once true 'SELECT ' then 'INSERT INTO ... RETURNING ' then 'SHOW TABLES' then 'REPAIR TABLES' etc. I would expect, that stSelect is always only 'SELECT' and other sql statements, that may return data map to any other StatementType ... may be, we can all other map to stExecProcedure (if we do not want introduce new statement type)? (like it is done internaly by fbclient for ...returning statements) As far as I know, the statementtype is mostly (if not only) used to determine whether Open or ExecSQL must be used. For this purpose, no new statement type is needed IMHO. If you want more detailed information, then the new statement type can be introduced. But then one could argue that a lot of new types can be introduced: stAlterObject or stDDL and so on. One would also need to see to it that stQuery can be used both in Open and ExecSQL, since you don't know in detail what the statement does. Maybe Joost can comment on this. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Request to review patch from 21530
On Wed, 11 Apr 2012, Luiz Americo Pereira Camara wrote: Hi, Can someone review the patch of http://bugs.freepascal.org/view.php?id=21530 ? I applied the patch, but I don't see what the reason is for having it read-only. I can think of use-cases where I would want to set the dataset as not-modified. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sqlite support for Android
On Mon, 2 Apr 2012, Felipe Monteiro de Carvalho wrote:
Hello,
In Android a dlopen operation without a full path will fail:
sqliteDLL:=DlOpen('libsqlite.so',RTLD_LAZY); == fails
sqliteDLL:=DlOpen('libsqlite3.so',RTLD_LAZY); == fails
sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite3.so',RTLD_LAZY);
== fails
sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite.so',RTLD_LAZY);
== works
sqliteDLL:=DlOpen('/system/lib/libsqlite.so',RTLD_LAZY); == works
So the existing sqlite bindings fail. The simples solution would be
hardcode for Android /system/lib/libsqlite.so but this is somewhat of
a grey area since this library is not guaranteed to exist. The other
option is placing it in our lib folder, but then you need to pass the
entire path for dlopen and this path will necessarely change with each
project, for example: '/data/data/com.pascal.lcltest/lib/libsqlite.so'
constains the name of the project com.pascal.lcltest
The solution would be to make this library name a variable then, but
this won't work because the sqlite bindings need to support static
linking too =O So maybe a variable only in the case of dynamic
binding.
This variable already exists: SQLiteDefaultLibrary.
Well, so basically I am just sending this e-mail to start talks about
what kind of solution would be accepted, maybe someone has better
ideas then I had. I am tempted towards:
{$ifdef Android}
libsqlite3 = '/system/lib/libsqlite.so';
{$else}
This is the most practical solution, just redefine the constant.
The SQLiteDefaultLibrary variable is initialized from this constant.
In case a private library is used, users can always explicitly do a
InitialiseSQLite('/path/to/private/sqlite.so');
to override the default behaviour.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sqlite support for Android
On Tue, 3 Apr 2012, Felipe Monteiro de Carvalho wrote:
On Tue, Apr 3, 2012 at 11:47 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
In Android a dlopen operation without a full path will fail:
A bit of googling suggests that the above statement is wrong:
http://groups.google.com/group/android-ndk/browse_thread/thread/2779732b85fef9b3#f0cb99298fa286e1
ops, it seams you are correct. In a new test sending only sqlite.so
worked properly ... no idea why the first test failed. Probably I was
using an old APK or library which tested against libsqlite3.so which
fails.
Continuing I have an even much wierder issue. The following code:
procedure TForm3.Button2Click(Sender : TObject) ;
begin
SQLite3Connection1.ExecuteDirect('CREATE TABLE IF NOT EXISTS PRODUTOS ( '+
'CODPRODUTO INTEGER NOT NULL, '+
'DESCRICAO VARCHAR(50), '+
'PRECO NUMERIC(12,3), '+
'ALTERADO TIMESTAMP, '+
' CONSTRAINT PK_PRODUTOS PRIMARY KEY (CODPRODUTO)); ');
end;
Causes a very wierd crash without stacktrace and no way to work
around, but only in LCL-CustomDrawn it works fine in LCL-Gtk2:
(gdb) break fpc_raiseexception
Breakpoint 1 at 0x8058d46
(gdb) cont
Continuing.
MouseMove x=47 y=93
MouseMove x=-9 y=63
MouseMove x=-79 y=47
MouseMove x=-57 y=58
MouseMove x=-26 y=63
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
Missing debug package(s), you should install: sqlite3-debug-3.7.9-1.1.mga1.i586
(gdb) bt
Target is executing.
This package does not exist. And if I add cthreads as the first unit
in the project automagically it starts working o.O It looks really
wierd that sqlite is using threading behind my back, or is it sqldb?
SQLDb does not use threads by itself.
It can be that the sqlite library uses threads, and if a SQLite callback
is done from a different thread, then the RTL may present you with a nice error.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TStrings Add(array of string)
On Sun, 1 Apr 2012, Andrew Haines wrote: On 04/01/12 05:13, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: I was thinking about TStrings possibly having an overloaded function Add or AddStrings where the argument is an array of string? procedure Add(strs: array of string); overload; or procedure AddStrings(strs: array of string); overload; Better implement the second. AddStrings already exists for a TStrings, it is more similar in functionality. Maybe better extending tprocess to have a array of const function than tstrings? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Here are two patches that do both. One extends TStrings with AddStrings and the other extends TProcess with AddParams. I'll let someone else decide which is better. :) I added the overloaded version of AddStrings. It comes in handy for other cases as well. Rev 20691. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are C style operators default or not?
On Tue, 27 Mar 2012, Sven Barth wrote: Am 27.03.2012 07:47, schrieb Gennadiy Poryev: Hi all, I’ve recently ran into weird problem with “C style operators”. Though the story is about Lazarus, I thought I better ask it here. All of a sudden, my Lazarus trunk had refused to build (http://bugs.freepascal.org/view.php?id=21571 ) and I've tracked the problem to the use of += operator somewhere in the recent revisions. Apparently this is easily fixed by adding -Sc compiler option to the makefile, had it not been the fact that I seem to be the only one experiencing this issue :( How this can be? I use latest fpc trunk with no self-made modifications, and it thinks that -Sc is not the default. Please enlighten me on this. As far as I can see from the source the default should be not enabled. I had the same problems. C style operators are by default off. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Fri, 23 Mar 2012, LacaK wrote: Michael, I updated patch for fcl-db test suite. See: http://bugs.freepascal.org/view.php?id=17303 Would you be so glad and will you apply them please ? Done, rev. 20572. As I wrote yesterday, I uploaded last patch for fcl-db test suite to http://bugs.freepascal.org/view.php?id=17303 From me side it is all for this moment. Applied. Rev. 20585. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Thu, 22 Mar 2012, LacaK wrote: And will you apply also diffs to fcl-db tests ? So we can run complete test suite ... I will do so later today. Michael, I updated patch for fcl-db test suite. See: http://bugs.freepascal.org/view.php?id=17303 Would you be so glad and will you apply them please ? Done, rev. 20572. Sorry for the delay. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, 20 Mar 2012, Marcos Douglas wrote:
On Tue, Mar 20, 2012 at 8:12 PM, michael.vancann...@wisa.be wrote:
On Tue, 20 Mar 2012, Marcos Douglas wrote:
On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
On Tue, 20 Mar 2012, Marcos Douglas wrote:
No.
Anyway, I change the colum names (id,name to col1, col2)
The error is:
Cannot insert the value NULL into column 'col', table tempdb.dbo.#t...
This error has nothing to do with FPC or SQLDB.
Your SQL statement is trying to insert NULL in a required field.
No Michael, see the example I wrote before.
I saw the example :-)
Create table:
create table #t (col1 int, col2 varchar(60))
OBS: No column is required.
This INSERT works:
insert into #t values (1, 'bla bla bla')
This INSERT do NOT works:
insert into #t (col2) values ('bla bla')
This kind of SQL is passed as-is to MSSQL. To my knowledge, SQLDB does not
change it.
If you had been using parameters, it would have been a different story.
Does matter if I use or not parameters.
Yes, of course. In that case, SQLDB does some preprocessing of your SQL
statement.
This can easily be checked. Try setting ParamCheck to 'False' before
executing your statement.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the state of string?
On Wed, 21 Mar 2012, Hans-Peter Diettrich wrote:
I wonder about much code in the RTL/FCL, that depends on String type
arguments, like:
Procedure TStream.WriteAnsiString (const S : String);
Var L : Longint;
begin
L:=Length(S);
WriteBuffer (L,SizeOf(L));
WriteBuffer (Pointer(S)^,L);
end;
This method will work only as long as String=AnsiString, because Length
*bytes* are written, not *chars* of a possibly different byte count.
Is the use of generic types, like String, really okay in the library code,
when the concrete type matters?
No. This work still needs to be done.
The documentation on strings (3.2 Character types) is not really helpful,
most entries look like they deserve an update reflecting the role of
UnicodeString and the generic String type, and implicit string conversions.
In detail I miss instructions on how to determine or specify the String type,
with different FPC versions.
{$H} is documented, {$IFOPT} is documented.
That's all there is.
As soon as the rest is implemented, it will be documented as well.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Wed, 21 Mar 2012, Marcos Douglas wrote: On Wed, Mar 21, 2012 at 3:34 AM, LacaK la...@zoznam.sk wrote: create table #t (col1 int NULL, col2 varchar(60) NULL) (MS SQL Server nullability is controled by database setting ANSI null default so you can check this setting on your temp database also) L. Yes, of course... you're right. I have this code that worked before so, I thought something broked. I had tested before in a different machine with other installation of MSSQL. My mistake, sorry. If I find some problems I can post in bugtracker or still early to do this? -- Michael, sorry for your time. No problem. I'm glad the problem turned out not to be in FPC, and that it is now solved anyway. It means there is lots of useful expertise on these mailinglists :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, 20 Mar 2012, Marcos Douglas wrote:
On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
On Tue, 20 Mar 2012, Marcos Douglas wrote:
No.
Anyway, I change the colum names (id,name to col1, col2)
The error is:
Cannot insert the value NULL into column 'col', table tempdb.dbo.#t...
This error has nothing to do with FPC or SQLDB.
Your SQL statement is trying to insert NULL in a required field.
No Michael, see the example I wrote before.
I saw the example :-)
Create table:
create table #t (col1 int, col2 varchar(60))
OBS: No column is required.
This INSERT works:
insert into #t values (1, 'bla bla bla')
This INSERT do NOT works:
insert into #t (col2) values ('bla bla')
This kind of SQL is passed as-is to MSSQL. To my knowledge, SQLDB does not
change it.
If you had been using parameters, it would have been a different story.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Mon, 19 Mar 2012, LacaK wrote: michael.vancann...@wisa.be wrote / napísal(a): On Thu, 15 Mar 2012, Marcos Douglas wrote: On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas m...@delfire.net wrote: On Mon, Feb 27, 2012 at 5:08 AM, michael.vancann...@wisa.be wrote: On Mon, 27 Feb 2012, LacaK wrote: Hi, let me share same basic info/ideas about TMSSQLConnection : 1. As Marcos wrote it is descendant of sql-db TSQLConnection class and provides native connector for MS SQL Servers and Sybase servers 2. is depends/requires on FreeTDS open-source cross platform DB-Library (alternatively can be used also Microsoft db-library ntwdblib.dll) 3. all what is needed are 2-3 files: - mssqlconn.pp (implementation of TMSSQLConnection and TSybaseConnection) - dblib.pp (interface to FreeTDS db-library ABI dblib.dll on Windows, libsybdb.so on *NIX) - readme.txt (some info for users/developers) 4. according to market share of MS SQL Server and Sybase there may be many users, which will welcome alternative to TODBCConnection 5. there is on http://www.freepascal.org/future.var in Improve the database support Drivers (descendants) for more database types so I understand it as FPC is open for new stuff ;-) 6. if there is any problem please let us know. If you decide to include it into fcl-db then you can place files for example into src/sqldb/mssql folder ;-) I will have a look and include both units. And the dream will become true... Thanks Michael. Any chance to merge in fixes_2_6 in short time? Marcos Douglas Hi Michael, Do you have some prediction to include the sources? My apologies, I had totally forgotten; I am buried in work currently. Committed in revision 20522. I didn't commit any examples or tests. Please test if everything works OK. I compiled on Linux 64-bit, I don't have a working FPC/Lazarus 32-bit windows development environment currently. Hi Michael, splitting files into two packages was unavoidable? Yes. As you can see for the other databases, we always keep the header imports separate from the components. Standard time-tested practice. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Mon, 19 Mar 2012, LacaK wrote: Hi Michael, splitting files into two packages was unavoidable? Yes. As you can see for the other databases, we always keep the header imports separate from the components. Standard time-tested practice. Hm, although I am not happy with this, I can do nothing with it ;-) Then I have minor comments: - in packages/dblib/fpmake.pp at line 23: Author put please instead of Lacak2 Ladislav Karrach (as in dblib.pp header) - in packages/fcl-db/src/sqldb/mssql/makefile.fpc at line 2: change IBConnection to MSSQLConnection ;-) Done. Rev. 20540 and 20541. And will you apply also diffs to fcl-db tests ? So we can run complete test suite ... I will do so later today. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Thu, 15 Mar 2012, Marcos Douglas wrote: On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas m...@delfire.net wrote: On Mon, Feb 27, 2012 at 5:08 AM, michael.vancann...@wisa.be wrote: On Mon, 27 Feb 2012, LacaK wrote: Hi, let me share same basic info/ideas about TMSSQLConnection : 1. As Marcos wrote it is descendant of sql-db TSQLConnection class and provides native connector for MS SQL Servers and Sybase servers 2. is depends/requires on FreeTDS open-source cross platform DB-Library (alternatively can be used also Microsoft db-library ntwdblib.dll) 3. all what is needed are 2-3 files: - mssqlconn.pp (implementation of TMSSQLConnection and TSybaseConnection) - dblib.pp (interface to FreeTDS db-library ABI dblib.dll on Windows, libsybdb.so on *NIX) - readme.txt (some info for users/developers) 4. according to market share of MS SQL Server and Sybase there may be many users, which will welcome alternative to TODBCConnection 5. there is on http://www.freepascal.org/future.var in Improve the database support Drivers (descendants) for more database types so I understand it as FPC is open for new stuff ;-) 6. if there is any problem please let us know. If you decide to include it into fcl-db then you can place files for example into src/sqldb/mssql folder ;-) I will have a look and include both units. And the dream will become true... Thanks Michael. Any chance to merge in fixes_2_6 in short time? Marcos Douglas Hi Michael, Do you have some prediction to include the sources? My apologies, I had totally forgotten; I am buried in work currently. Committed in revision 20522. I didn't commit any examples or tests. Please test if everything works OK. I compiled on Linux 64-bit, I don't have a working FPC/Lazarus 32-bit windows development environment currently. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPImage unit ImageHandlersManager design problem
On Thu, 15 Mar 2012, Andrew Brunner wrote: Having just looked over the class factory for images in FPC, I found that ImageHandlersManager is missing a critical method to obtain a reader or write by the extension used. Presently the getReader uses the TypeName and not the Extenstion. I find this quite annoying. Can someone please extend the manager to handle a GetReaderByExt(sExt) ? Thanks! I would be willing to do it myself but don't know if it would be accepted. It would be accepted. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreeNotification and opRemove
On Thu, 8 Mar 2012, Martin wrote:
Further more:
the program below, does not crash in delphi (turbo delphi)
I also noticed. I suspect the problem is the owner;
If it gets a free notification, it should pass it to all the children.
Michael.
On 08/03/2012 09:56, Martin wrote:
I found a behaviour, of which I am not sure, if it is intended. Maybe
someone can comment
My understanding is that FreeNotification are *always* set up
bi-directional ?
At least
C1.FreeNotification(C2);
will set up for C1 to inform C2, and for C2 to inform C1 whichever is
destroyed first to call the other
And
C1.RemoveFreeNotification(C2);
will remove both.
C2.Notification(C1, opRemove);
breaks that.
It will lead to C2 removing C1 from it's list of FreeNotifies, but C1 will
keep C2 on the list.
If then C2 is destroyed, it does not inform C1 about that, and C1 ends up
with a dangling pointer to the no longer existing C2.
Destroying C2 will then crash.
In the example below (compile with -gt) opRemove is caused by
Owner.RemoveComponent.
It crashes on the last line.
I was briefly wondering, if in case C1 did call C1.FreeNotification(c2);,
then C1 should overwrite Notification and check for the opRemove and call
RemoveFreeNotification itself?
But if that was the case, then why does TComponent interfer with the
FreeNotify list at all?
program Project1;
{$mode objfpc}{$H+}
uses Classes;
var
Owner, C1, C2: TComponent;
begin
Owner := TComponent.Create(nil);
C1 := TComponent.Create(Owner);
C2 := TComponent.Create(Owner);
C1.FreeNotification(c2);
Owner.RemoveComponent(C1); // C2 Gets on opRemove
C2.Free;
C1.Free; // crash
ReadLn;
end.
___
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Mon, 27 Feb 2012, LacaK wrote: Hi, let me share same basic info/ideas about TMSSQLConnection : 1. As Marcos wrote it is descendant of sql-db TSQLConnection class and provides native connector for MS SQL Servers and Sybase servers 2. is depends/requires on FreeTDS open-source cross platform DB-Library (alternatively can be used also Microsoft db-library ntwdblib.dll) 3. all what is needed are 2-3 files: - mssqlconn.pp (implementation of TMSSQLConnection and TSybaseConnection) - dblib.pp (interface to FreeTDS db-library ABI dblib.dll on Windows, libsybdb.so on *NIX) - readme.txt (some info for users/developers) 4. according to market share of MS SQL Server and Sybase there may be many users, which will welcome alternative to TODBCConnection 5. there is on http://www.freepascal.org/future.var in Improve the database support Drivers (descendants) for more database types so I understand it as FPC is open for new stuff ;-) 6. if there is any problem please let us know. If you decide to include it into fcl-db then you can place files for example into src/sqldb/mssql folder ;-) I will have a look and include both units. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PParser.IsTokenHint deserves an update
On Mon, 20 Feb 2012, Hans-Peter Diettrich wrote: The extended syntax of hint tokens should be reflected in IsTokenHint. See oldlinux.pp: unit oldlinux deprecated 'Use Baseunix/Unix'; Perhaps it's sufficient to skip the next token after an hint, when it is a string literal? Dunno about the concrete syntax changes... I have this fixed locally, but it is not yet committed. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MakeSkel problem with operators?
On Mon, 20 Feb 2012, Hans-Peter Diettrich wrote: In an attempt to check the yet undocumented FCL units for use with FPDoc and MakeSkel, I got an error in the created skeleton for gmp: element name=operator (MPFloat, MPFloat): Boolean The and chars in operator names should be escaped in the XML files. Last time this was remarked on, there was discussion whether and need to be escaped inside attribute values. I never got around to checking the XML specs. In each case it's easily fixable. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem documenting source code
On Fri, 17 Feb 2012, Hans-Peter Diettrich wrote: After adding documentation for some items in the FPDoc Editor, I have problems running MakeSkel or FPDoc. Both report errors in the input file, which seem to be related to wrong or missing compiler options for that file. How can a documentation writer determine the required compiler options, so that the fpdoc tools can be made work? In former times[tm] I used make all -n in the source directory, to make the compiler options visible. But this approach fails now, the fpmake commandlines are not informative enough for that purpose. It may be a bad example (work in progress?), but I couldn't figure out the required compiler options for e.g. fcl-process/pipesipc.pp, in an attempt to create the skeletons for the fcl-process package. Why would you want to do that ? These units are fully documented ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On Tue, 7 Feb 2012, Felipe Monteiro de Carvalho wrote: On Mon, Feb 6, 2012 at 9:35 PM, Sergei Gorelkin sergei_gorel...@mail.ru wrote: So, this is basically a first step of locking Windows RTL to use utf-8 by default No, it will not use UTF-8 by default because that would break compatibility. It will use the system encoding by default and you can use SetMultiByteConversionCodePage to change it to use UTF-8. And this is not about just about Windows, but all platforms of the Ansi RTL. Just that most other platforms are already using APIs which can handle Unicode so they don't need changes. SetMultiByteConversionCodePage is not specific to the Windows RTL. and reducing chances it ever will call 'W' API without conversions? This is a very strange argument. You cannot oppose something by arguing that then it will be successful and people will not want to implement your way. There are no such barriers in a volunteer led project. If someone wants the UnicodeString RTL ... he can write it. I am not against another RTL existing which will use UnicodeString or which will use 1 different string in each platform or 1 different string for each weather condition. But I just don't want to use it. I want to use the Ansi RTL + SetMultiByteConversionCodePage to make it UTF-8 capable, so that's what I am writing. Let me intercede here: The plans are already laid out. The ANSI RTL will be exactly that: ANSI; No unicode or UTF-8 hacks will be added to it. The planned unicode RTL will be unicode, and by corollary will support UTF-8. So any patches to utf8-enable the Ansi RTL will not be accepted. You'll have to wait for the unicode RTL or start work on it yourself. If you want, I can send you the details in private, and you can decide for yourself what to do. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc imports
On Thu, 2 Feb 2012, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Well, It took me about 15 lines to implement it in dglobals.pas of fpdoc. I moved one function out of fpdocoptsxml to mkfpdoc to split the input line. First tests work fine. See revision 20213. A fine solution :-) I happen to get an AV during the Engine destruction, when the packages are released (in TPasElement.Release). It seems to occur when the current package is relased, not for imported packages. In one test I found each module duplicated in the modules list, so that the release of the first entry will invalidate the second one. One reason may be the different assumptions about the content of the FProcessedUnits list, where either the input file part or the entire input specification is stored. But this seems not to be the only bug :-( The entire input spec is stored. I could change this, but I don't think it is the problem. (eventually I probably will, but for other reasons) In each case: Connecting this mail to your other mail reports of packages automatically appearing etc, I'm inclined to think that the automatisms you added in your private version are somehow interfering with the regular workings. But that is a wild guess. In each case: If you want to file bug reports, please use the official sources only to reproduce the problem. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc imports
On Wed, 1 Feb 2012, Hans-Peter Diettrich wrote: Sven Barth schrieb: Am 31.01.2012 14:42, schrieb Hans-Peter Diettrich: I still wonder why the number of units in the imported RTL package increases over time. Initially it contains 7 modules, and 38 modules in the end, where the RTL currently consists of 46 units. 6 of the initial modules contain classes, but I couldn't find the 7th module iostream anywhere, which is the first module in the list. The only iostream unit I'm aware of is in packages/fcl-base/src. Right, and it somehow found its way into the rtl package. I'll know more soon. In the meantime I found a solution for the input files order, by recursive compilation. Unfortunately I couldn't test it right now, for several reasons. Most important is the large number of affected units, which may make some people reject such an patch immediatly. So let me explain first what I implemented so far, and what remains to be done. First the storage format of the fpdoc Inputs is not really handy, every commandline has to be parsed for the input filename, from which the unit name can be extracted. It would help when the storage format would be modified, so that the entries can be found with IndexOfName, as implemented in FPDocManager. This is what I didn't implement yet. Next problem is the separation between parser, engine and the fpdoc creators, which are involved in finding the used units in the current package. Herfore I added a method AddModule to the engine, which adds the newly created module to the Modules list, and also notifies fpdoc of the addition by an OnAddModule callback. Then the creator can put the TPasModule into Inputs.Objects, to signify that it is or has been parsed. Why do you need this ? You make it quite complicated. All you need is a FindModule(Const AName,AFileHint : String) : TPasModule call in TPasTreeContainer which must be overridden in a descendent (such as TFPDocEngine). The default implementation returns nil. This call can search the module list if it has one. If it doesn't find it, it can then decide to parse it anyway and return the just-parsed instance. All the parser needs to do is call FindModule whenever it encounters a unit in a uses clause; The rest will happen then automagically. Then you can create a TPasTreeContainer descendent called TModulesPasTreeContainer which keeps a list of modules and which implements FindModule with the above described recursive mechanism. The FPDoc engine can then be a descendent of that class. The above is what I was planning to implement. It is simple and will do the job, plus, for circumstances where there is no need for the recursive mechanism, nothing changes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)
On Mon, 30 Jan 2012, steve smithers wrote: Finally, the suggestions about developing FreePascal/370 as an ASCII compiler seem somewhat pointless to me. Why would anyone want to use an ASCII compiler on an EBCDIC system? I accept fully that producing an EBCDIC version will present problems, but if this compiler is actually going to be used by anyone, these have to be overcome. I think the reason for producing an ASCII version first is very simple: All FPC sources - including the compiler - are in ASCII encoding. Whatever is made, the hypothetical compiler will need to understand ASCII in the first place, or it cannot recompile itself or it's RTL... Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)
On Mon, 30 Jan 2012, rvmart...@ntlworld.com wrote: michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53: I think the reason for producing an ASCII version first is very simple: All FPC sources - including the compiler - are in ASCII encoding. I don't understand this statement - ASCII and EBCDIC are just human representations of a computer's internal code. I write my programs in the Latin (or Roman) alphabet and the computer does the rest. When I was writing VS/Pascal programs I used the same source code as input to VS/Pascal on the mainframe and to Virtual Pascal on the PC. Unless the FP source code is to be fed into a mainframe compiler like IBM's VS/Pascal or the Stanford compiler then the first step is surely to write a backend for the (eg PC) compiler to produce 370 assembler code. Producing EBCDIC rather than ASCII sounds a trivial part of the task. I had in mind the following scenario: 1) Somehow we build - using cross-compilation - a first version of the compiler that actually runs on the 370. This binary is transferred to a 370 machine. 2) The sources of the compiler and RTL are transferred to the 370. I assume that after the file transfer, the sources are still in ASCII format ? 3) At that point the compiler can try to recompile itself on the 370 machine. Unless you have performed some tranformation of the compiler/RTL sources, the compiler in step 3 will read and compile from ASCII sources, no ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc improvements
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote: Unfortunately I managed to supply the EasyImports.patch twice, please drop Mantis #21168 as a dupe of #21167. Sorry for the inconvenience :-( Thank you. I will look at it. Starting with this patch I suggest further improvements of fpdoc. Except for the RTL docs, which require a couple of special compiler options for every input file, a package project can be shrunk essentially to the specification of these options: --package the package name --imports a list of related packages --input-dir containing all source files --descr-dir containing all XML files --output-dir where the output files are created --format the document format As I said before: Neither --input-dir nor --descr-dir will be put in the fpdoc implementation. I don't see the problem of having to specify all files that are part of the project explicitly. Make does it, Lazarus does it, Delphi does it, Visual Studio does it. All require you to specify exactly which files should be there when compiling, and rightly so. For the --input-dir there is an extra reason: the order of files is important. Just like in the compiler, which must compile dependent units first, fpdoc should first document dependent units. It currently does not know how to do this by itself. So, a patch providing these 2 options will not be applied. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc improvements
On Fri, 27 Jan 2012, Hans-Peter Diettrich wrote: should first document dependent units. It currently does not know how to do this by itself. Again, what are you talking about? FPDoc doesn't require a special order of input files, neither source nor documentation files :-) It does, see the explanation of Marco. Which is why I again removed the input-dir option (but this is not yet committed). Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New bug in building RTL docs
On Wed, 25 Jan 2012, michael.vancann...@wisa.be wrote: On Wed, 25 Jan 2012, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: On Tue, 24 Jan 2012, Hans-Peter Diettrich wrote: michael.vancann...@wisa.be schrieb: Today I had problems in the FPDocManager, where the scanner/parser throws an exception String list does not allow duplicates. Reason may be duplicate include paths, definitely a duplicate -dCPU32 from both the parser and the commandline. The sources have been stripped from dupError a long time ago. So I can't reproduce this. See pscanner.pp line 947, where FDefines is created with dupError. What is the problem ? Defines or include paths ? The problem is at least one list which reject duplicates. Since the error message is too vague, I only can guess what may be the exact problem. Defines definitely are a problem. Not here. Perhaps not on your platform, but perhaps on many others. The -dCPU32 in the fpdoc commandline may be inserted on a Win64 platform only... Look, I tested by inserting the same define twice on the command-line, and all worked fine. Further, there is not a single piece of evidence that dupError is used in defines in the SVN sources. Always doubt yourself. I checked here at work, and here the SVN copy is different than at home. So I committed a fix, please test rev. 20169. Now I should learn to doubt and check before writing an answer. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New bug in building RTL docs
On Wed, 25 Jan 2012, Hans-Peter Diettrich wrote: michael.vancann...@wisa.be schrieb: I checked here at work, and here the SVN copy is different than at home. So I committed a fix, please test rev. 20169. Just tested: the dupes error has gone away :-) Great. Now remain the syntax errors, see Mantis #21148. For those, I still need to test. BTW. In future, please file separate reports for separate issues. There are 2 distinct problems: * the duplicate defines, and * the parsing of certain constructs. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New bug in building RTL docs
On Tue, 24 Jan 2012, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: On Mon, 23 Jan 2012, Hans-Peter Diettrich wrote: Today I had problems in the FPDocManager, where the scanner/parser throws an exception String list does not allow duplicates. Reason may be duplicate include paths, definitely a duplicate -dCPU32 from both the parser and the commandline. The sources have been stripped from dupError a long time ago. So I can't reproduce this. See pscanner.pp line 947, where FDefines is created with dupError. What is the problem ? Defines or include paths ? If you think there is a problem with double defines, please state this clearly. From your report I understand you think there is a problem with include paths. I cannot reproduce this: Yesterday I built FCL and RTL with ALL include paths doubled. Everything went well, so I think the problem is on your machine. If you think there is an additional problem with defines, then state this clearly or at the very least in a separate report. Another parser error occurs in systemh.inc line 283 col. 30: UCS4Char= type 0..$10; where the parser expects an = after type. Wasn't this syntax recognized already before 2.6? As far as I know, I have fixed this already in trunk. The reported problems exist since my last FPC 2.7 SVN update (yesterday), they did not exist in the last months. For this one, please file a separate bug report. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Michael Schnell wrote: AFAI learned: I suppose the code generator should be doable, regarding that there already are several supported CPUs. At least a working compiler might come into existence in a decent amount of time, adding optimizations is another project. OTOH I suppose that a porting the RTL to a mainframe OS will not be easy and without this the compiler is quite useless. I do not think it is more difficult than any other OS. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Tomas Hajny wrote: On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote: On Wed, 18 Jan 2012, Michael Schnell wrote: AFAI learned: I suppose the code generator should be doable, regarding that there already are several supported CPUs. At least a working compiler might come into existence in a decent amount of time, adding optimizations is another project. OTOH I suppose that a porting the RTL to a mainframe OS will not be easy and without this the compiler is quite useless. I do not think it is more difficult than any other OS. ...except for the EBCDIC stuff, because the common parts of our RTL assume ASCII in many places (most of them probably not that difficult to fix by adding some platform specific constants changing the behaviour from ASCII only to consider EBCDIC too, but scattered around many places and thus difficult to find). That doesn't mean it shouldn't be doable, of course, it will just require debugging even parts which didn't have to be touched during ports to other operating systems. ? It just means you must convert ascii to ebcdic in OS calls that require strings. All these calls must be re-implemented anyway, so a generic routine to do this conversion seems like the obvious path. I doubt this will be the real bottleneck :-) As for using Linux: I have no idea how this works in practice, so I can't comment on that. I know that people here use Hercules inside linux to develop for zSeries, but then again running a linux inside that seems a bit like overkill :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 11:23, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Tomas Hajny wrote:
On Wed, January 18, 2012 10:15, michael.vancann...@wisa.be wrote:
On Wed, 18 Jan 2012, Michael Schnell wrote:
AFAI learned:
I suppose the code generator should be doable, regarding that there
already
are several supported CPUs. At least a working compiler might come
into
existence in a decent amount of time, adding optimizations is another
project.
OTOH I suppose that a porting the RTL to a mainframe OS will not be
easy
and
without this the compiler is quite useless.
I do not think it is more difficult than any other OS.
...except for the EBCDIC stuff, because the common parts of our RTL
assume
ASCII in many places (most of them probably not that difficult to fix by
adding some platform specific constants changing the behaviour from
ASCII
only to consider EBCDIC too, but scattered around many places and thus
difficult to find). That doesn't mean it shouldn't be doable, of course,
it will just require debugging even parts which didn't have to be
touched
during ports to other operating systems.
? It just means you must convert ascii to ebcdic in OS calls that require
strings. All these calls must be re-implemented anyway, so a generic
routine
to do this conversion seems like the obvious path. I doubt this will be
the
real bottleneck :-)
It should not be a bottleneck, but I'm afraid that you underestimate it a
bit. As an example, searching for #10 and #9 across files (just) in
rtl/inc (there's much more in rtl/objpas) shows quite a few places which
would need to be changed for EBCDIC support and which are not touched
otherwise during a RTL port (control characters have completely different
layout in EBCDIC compared to ASCII). Also case insensitive search for
'a' (just as an example - there are more ways how this can appear in the
code) finds several places containing code assuming either certain
position of the standard alphabet ('a'..'z') in the character set - both
assumptions regarding the absolute value of 'a' (or 'A') used e.g. for
translation of hexadecimal numbers, or assumptions about the whole
alphabet being in one consecutive range (which is not the case for
EBCDIC).
But then you are assuming the RTL should be using EBCDIC internally as well ?
Obviously, that will be a lot more work.
But I don't think this should be so.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] On a port of Free Pascal to the IBM 370
On Wed, 18 Jan 2012, Tomas Hajny wrote: But then you are assuming the RTL should be using EBCDIC internally as well ? Obviously, that will be a lot more work. But I don't think this should be so. I may be overlooking something, of course. However: Our RTL is based on common (target specific) routines for reading (and writing) text and binary files (do_read do_write). You cannot translate between ASCII and EBCDID in these target specific routines because you don't know how the input would be used at that point (not even mentioning the fact that there is nothing like translation between ASCII and EBCDIC because there are multiple different character sets for both and real conversion isn't possible without taking this into account and knowing the real character sets which again depends on the context which is again not known at this low level). Once more: I do not think this is the task of the RTL. FPC and the RTL works with ASCII. That includes the expected contents of text files and whatnot. That a hypothetical FPC program opening an EBCDIC file on OS/370 needs to convert this to ASCII first is in my view the responsability of the programmer. The same goes for the FPC sources. I do not suppose that a FPC port would first convert the current ASCII sources to EBCDIC, but would continue to use the ASCII version. If you define the RTL as being able to handle EBCDIC on OS/370, it is a different matter, and a lot more work. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cant' compile trunk
On Tue, 27 Dec 2011, José Mejuto wrote: Hello FPC, I can't compile trunk: [...] make[1]: Entering directory `F:/fpc/svn/utils/importtl' F:/fpc/fpc/2.4.4/bin/i386-win32/ppc386.exe -Fu../../rtl/units/i386-win32 -FE. -FUunits/i386-win32 -di386 importtl.pas Free Pascal Compiler version 2.4.4 [2011/12/16] for i386 Copyright (c) 1993-2010 by Florian Klaempfl Target OS: Win32 for i386 Compiling importtl.pas Fatal: Can't find unit typelib used by importtl Fatal: Compilation aborted make[1]: *** [importtl.exe] Error 1 make[1]: Leaving directory `F:/fpc/svn/utils/importtl' make: *** [importtl_all] Error 2 I was trying to fix the makefile but me and makefiles are not good friends :) Should be fixed in rev. 19895. As a workaround, compile *and install* the latest version of the packages. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Paramstr trailing spaces, bug or not?
On Thu, 22 Dec 2011, Joost van der Sluis wrote: Hi all, With this command-line: fpmake --prefix=bla --baseistall=test paramstr(1) gives --prefix=bla . Thus with the trailing space. Is this a bug or a feature? It's what the shell has passed on. The paramstr() code doesn't do any parsing on Linux. It returns the elements in argv[] Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MakeSkel and FPDoc projects
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Feel free to create this program. If I may give some advice: the tasks you outline belong in a Documentation writers IDE. To some degree, maybe. But checking for updates should be doable by a script, without a need to open an IDE - for every single package! I have done so for years, with the existing tools, using the Makefiles. No changes were necessary. So you'll hopefully excuse me if I think you are seeking problems where there are none... I will cooperate on additional options which enhance the operation of the tools within the frame of their purpose, as I have done recently. I think that makeskel can be enhanced to use a project file to create an update for a single unit file, to spare you the effort of typing all options again, but that's about it. This would be very kind, of course :-) Can you also add this option to FPDoc, so that it will allow to do a test build for an single unit file? Yes, this was already planned. Consider what happens when FPDoc, MakeSkel or MkFpdocProj *update* a project - a new file will be created, that contains whatever the programs have extracted from the input project, and whatever else they find worth to store in the output project. When they do not update the projects themselves, how can the user be informed of possible changes, so that he can update the project file himself? That is where your IDE jumps in. Currently changes to the RTL and FCL (MakeFiles) require a dry-run of make, analysis of the resulting commandline, and a manual merge with the existing project. According to the Unix philosophy another tool is required, that automates the project file update, and one more for updating the project file when description files are added... According to Unix philosophy, the person doing so is aware of what he is doing, and makes the necessary changes (if there are such changes) to the project file himself. I do not believe the tools can make the correct decisions, except in the most trivial circumstances. 2. If command-line options override the defaults in the file (as they do), you just need to specify the correct options on the command-line in case the project file contains the wrong ones. This means in practice that almost all settings have to be given on the commandline (except the file lists), or to inspect every single project for the contained settings, in order to find out what must not necessarily be overridden. Of course. No tool can do this for you, for the very simple fact that computers are very stupid. They can help you organize your life, but they do not organize your life for you. You are in the driver's seat, not the computer. But when I have to use Lazarus with different settings, for building applications (last release or trunk, with or without patches for a dockable IDE), and for different FPC versions (e.g. trunk for building the documentation tools), life can become very complicated :-( No doubt. But instead of blaming the tools, maybe you should reconsider the way you organize your work. I have many versions of FPC and Lazarus floating around, on various platforms. I seem not to have all these problems you are experiencing, yet I use the same tools. So excuse me for believing that the problem is not in the tools :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Determin file size - how?
On Thu, 15 Dec 2011, Hans-Peter Diettrich wrote: Tomas Hajny schrieb: I wonder how to obtain the size of an file on disk. The only function I could find so far is FileSize, which requires an open File, but nothing for an file name :-( ATM FileSize(TEXT) would help, too, but FileSize only accepts an FILE, not TEXT :-( What exactly do you want to achieve? Effectively I'm missing a function FileSize(filename), similar to FileExists or FileAge, for general use. Is it because the file may be open as a text and denied sharing wouldn't allow parallel opening for reading as an untyped file (as suggested by Vinzent)? If this is the case, there is a nasty but completely platform independent hack which you could use (based on the fact that the underlying operating systems and their APIs make no difference between file and text). Normally I use TFileStream's, which have a Size property. But I find it nasty to open an file, when I only want to know its size. FPC (like Delphi) lacks some basic file/directory handling functions (Size, Remove, Rename...), at I think you didn't look very well in the docs. DeleteFile RenameFile I agree the filesize is missing. I will look into adding them to the documentation topics. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Determin file size - how?
On Thu, 15 Dec 2011, Hans-Peter Diettrich wrote: michael.vancann...@wisa.be schrieb: Normally I use TFileStream's, which have a Size property. But I find it nasty to open an file, when I only want to know its size. FPC (like Delphi) lacks some basic file/directory handling functions (Size, Remove, Rename...), at I think you didn't look very well in the docs. DeleteFile RenameFile After I couldn't find it in the FPC docs, I looked into the D7 docs, where many more functions are listed in File management routines. I understand that FPC has to implement some functions with the Delphi names, but when most other file related functions start with File, how should a user know (and search for) names *ending* with File :-( I repeat: you didn't search very well. http://www.freepascal.org/docs-html/rtl/sysutils/renamefile.html http://www.freepascal.org/docs-html/rtl/sysutils/deletefile.html They have the same names as their Delphi counterparts. I agree the filesize is missing. I will look into adding them to the documentation topics. Thanks :-) IMO a separation into topics File handling (FILE based) and File management (by filename) would be a good idea. Now I also found an topic General File handling routines, but it seems to list only Posix functions, not avaialble on other platforms - should read Posix File ... instead? Where did you find this topic ? I will investigate what can be done to make the topics more clear and helpful. As already mentioned, I still miss platform independent versions of the file management routines. Lazarus implements some routines, but IMO these should become part of the RTL, not of FCL or LCL. Which ones do you think are missing apart from FileSize ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
On Thu, 8 Dec 2011, Graeme Geldenhuys wrote: On 7 December 2011 23:09, Hans-Peter Diettrich DrDiettrich1@ wrote: Does there exist a chance (trick) to use the input files of a different installation, without copying the description files? If you use the make command to generate the docs, simply pass the FPCSRCDIR command line parameter. eg: make rtl.chk fcl.chk FPCSRCDIR=/opt/fpc_2.4.5/src/ That's correct, but AFAIK, he uses a private description file. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
On Thu, 8 Dec 2011, Felipe Monteiro de Carvalho wrote: Some more changes I'd like to propose. It seams that Rectangle is not TCanvas compatible: procedure TFPPixelCanvas.DoRectangle (const Bounds:TRect); A rectangle over (0, 0, 10, 10) should not include the pixels line with x=10 and y=10 but instead go only to x=9 and y=9, it is considered that the position is in the top-left of the pixel DoLine should not include the last point of the line (maybe unless you have a pen cap), although this one is a bit confusing. But it is how TCanvas works. Yes, but changing this will break existing code ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
On Thu, 8 Dec 2011, Felipe Monteiro de Carvalho wrote: On Thu, Dec 8, 2011 at 9:33 AM, michael.vancann...@wisa.be wrote: Yes, but changing this will break existing code ? Yes, it cannot do both at the same time, unless we add a property PaintLikeTCanvas or something like that. Hm. I would reverse the property. UseFPCPaint, which must be switched 'on'. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPDoc parser doesn't handle forward declarations properly?
On Thu, 8 Dec 2011, Hans-Peter Diettrich wrote: michael.vancann...@wisa.be schrieb: Does there exist a chance (trick) to use the input files of a different installation, without copying the description files? If you use the make command to generate the docs, simply pass the FPCSRCDIR command line parameter. eg: make rtl.chk fcl.chk FPCSRCDIR=/opt/fpc_2.4.5/src/ That's correct, but AFAIK, he uses a private description file. Right. I didn't test what fpdoc stores in the new project file when invoked with such a commandline, and whether it could be substituted by --input-dir (most probably not). Since the document sources reside in their own repository, I simply move around that directory on my system, for now. Currently the following steps are required to build the project file and the docs: 1. make whatever -n mydocs.bat 2. edit mydocs.bat to make fpdoc create an project file 3. mydocs.bat 4. edit the mydocs.xml project as required 5. fpdoc mydocs.xml 2+3 could be omitted, when fpdoc would automatically create a project. Or if the documentation is created from projectfile directly, which is the plan. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
On Wed, 7 Dec 2011, Felipe Monteiro de Carvalho wrote: On Wed, Dec 7, 2011 at 8:06 AM, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: Indeed good idea, I am implementing like that with slightly different names (TFPCustomRegion and IsPointInRegion). commited, I did not mention anything from Clip in the name of the region because it is not necessary useful only for drawing clipping, it can also be the base of event clipping and window and control shaping. I also joined zeljko's idea. If the region is not rectangular and you read the property ClipRect, it will return the bounding rectangle of the region. For rectagular regions it does the same, but the bounding box matches the region rectangle. It comes with a class for rectangular region clipping which is the trivial case for backwards compatibility. Great job ! Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
