Re: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Marcos Douglas said: > > Done, trunk r21037. Affected were tdataset and bufdataset (conversion > > between Pbufbookmark and tbytes). > > What about 2.6.1, will change in a few days too? When it is sufficiently tested or when I give up waiting. (typically 6-8 weeks). ___ 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, Apr 25, 2012 at 1:52 PM, Marco van de Voort wrote: > In our previous episode, Marco van de Voort said: >> > If creating the patch is the issue, I'm volunteering ;) >> >> You can do it, if not, I will in the coming days. > > Done, trunk r21037. Affected were tdataset and bufdataset (conversion > between Pbufbookmark and tbytes). What about 2.6.1, will change in a few days too? Marcos Douglas ___ 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
In our previous episode, Marco van de Voort said: > > If creating the patch is the issue, I'm volunteering ;) > > You can do it, if not, I will in the coming days. Done, trunk r21037. Affected were tdataset and bufdataset (conversion between Pbufbookmark and tbytes). ___ 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 1&2 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: RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
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? Kidding, I never expected this much drama. If it is such big deal, and since we all agree over the eventual (tbytes) outcode let's just fix it. Make a patch, but do it in a way that keeps the current behaviour under (not active) ifdef if possible (nonautomatedbookmark or so). That way if we want to cleanup/detect missing freebookmarks, we only have to define that. That was probably the whole intended purpose of the exercise anyway. (and I do encourage people to test their code with that setting) > If creating the patch is the issue, I'm volunteering ;) You can do it, if not, I will in the coming days. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
> Yes, for instance if there are external resources like > cursors or locks coupled to it, and it is not just a matter > of freeing that single block of memory. > ... > Afaik the assumption that it is /modeled/ as managed is > simply wrong. It is currently modeled as NOT managed, it is > just that for historic reasons managed works for the default > base TDataset. But descendents don't have to support that > (e.g. if they don't support old Delphi versions, something > 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. > Ideally, in time we want the interface to be the same as > current Delphi's. > > 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. For most implementers the TBookmark changes are still fresh in memory and the sooner we get over with it the better. If creating the patch is the issue, I'm volunteering ;) Thanks, Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Ludo Brands said: > > They mostly track 2.7.1 also, so then it should be just a > > matter of enabling the right override for 2.6.x too (which is > > what I had in mind) > > I understand. Just wanted to clarify that, to my knowledge, all 3rd party > dataset descendants and some other programs using bookmarks are affected by > a change that wanted to minimize compatibility problems. Summary: afaik I wanted the change to go over as quickly as possible, but I assumed that a more freebookmark based approach was eventually the way to go anyway (and I still think that, unless the "virtual" is removed in XE2) I can only assume I chose pointer for minimal modifications AND to make people aware of it, so that unfreed bookmarks would show up in the heaptraces, so that at least the FPC+Lazarus codebase properly calls freebookmark everywhere. > > But I assume that is more for the dataset users that use > > tbookmark than for internal use in tdataset implementers. > > That only would be useful if the tdataset descendant would add code around > Tbookmark that would turn a managed type into a partially non-managed type. Yes, for instance if there are external resources like cursors or locks coupled to it, and it is not just a matter of freeing that single block of memory. > IMHO that would be only the case for those datasets that were developped > with the intermediate non-managed Tbookmark=pointer. And I hope for all future datasets and code using it. Since the method is still virtual, and I could take even the old "string" version simply only as a label or handle to an external resource. (cursors, indexes, locks) The fact that it is an automated string then only buys the freeing of the label, but doesn't solve the problem. There is no ability to run code that way. > I can't imagine a tdataset implementer that would turn a managed bookmark > type to an unmanaged one on purpose. Delphi has lived 2-3 years with the > Tbookmark=pointer situation and probably has created there some backwards > compatibility problems. One more reason to jump to tbytes as quickly as > possible. Afaik the assumption that it is /modeled/ as managed is simply wrong. It is currently modeled as NOT managed, it is just that for historic reasons managed works for the default base TDataset. But descendents don't have to support that (e.g. if they don't support old Delphi versions, something that is increasingly happening, with the first D7 supports disappearing) > > That's why I waited a while with merging, so that initially > > only 2.7.1 would be broken, and after a time without > > complaints, I merged it because then it is only the matter of > > connecting that change also with 2.6.1. > > I should have spoken up earlier then ;) The mention that the change to > tbytes is in the pipeline for trunk was what triggered my reaction. Ideally, in time we want the interface to be the same as current Delphi's. 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 > > IOW my idea is document and recommendthe way that always > > works now, not shortcuts that may be possible for historic reasons. > > If we skip Tbookmark=pointer, at least fpc won't create new 'historic > reasons' for requiring freebookmark. I think freebookmark is not historic. Code that treated tbookmark opague, and called freebookmark remained working with the change of tbytes. That is good design. It also gives a lot of freedom to dataasets to implement bookmark support. Opague type use is a good habit. > Delphi created a mess. Don't let us add to it. (to be honest, I think that the tbytes stuff is the mess. Bowing to pressure, compromising design. But I bet the idea is still that you call freebookmark) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
On 25 April 2012 11:08, Ludo Brands wrote: > > I understand. Just wanted to clarify that, to my knowledge, all 3rd party > dataset descendants and some other programs using bookmarks are affected by > a change that wanted to minimize compatibility problems. Indeed, and it now has the total opposite effect. Shouldn't such code breaking changes be left to Trunk (2.7.1) and new major FPC releases only. As far as I know, 2.6.x is now a "fixes" branch which should only allow _bug fix_ commits - nothing more! [Marco: practice what you preach] -- Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
