Re: [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, LacaK said: > > Policy wise, I merge revisions for utils, packages and the higher level > > units of RTL like sysutils and classes if they are a couple of weeks old > > (3-4 weeks), but I usually leave big changes a bit longer. > > > ok it is answer to my question ;-) > So we can expect backporting after approx. month yes. Depending on time of course. Recently e.g. the mysqlconnection55 was in the "difficult" category, since the makefile stuff has to be done totally different for the fixes branch. Such things can take longer, since I usually have to find a day to work on it with some calm days after to mob up fall-out. > > Since last weekend there is a notes system that allows me to add notes to > > the revs in mergelogs. See r21037 on the database page, it has a red "notes" > > attached to it. Clicking it will unfold it. > > > yes I noticed it ;-) > > Please add also red comment to *21009* that this revision DO NOT > backport (it is "only" test), because I used there array constructor, > which AFAIK is not implemented in 2.6 (so it will fail to compile) Done. Note that clicking the revision (in bold) will fold out the affect files. ___ 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
Policy wise, I merge revisions for utils, packages and the higher level units of RTL like sysutils and classes if they are a couple of weeks old (3-4 weeks), but I usually leave big changes a bit longer. ok it is answer to my question ;-) So we can expect backporting after approx. month Since last weekend there is a notes system that allows me to add notes to the revs in mergelogs. See r21037 on the database page, it has a red "notes" attached to it. Clicking it will unfold it. yes I noticed it ;-) Please add also red comment to *21009* that this revision DO NOT backport (it is "only" test), because I used there array constructor, which AFAIK is not implemented in 2.6 (so it will fail to compile) At a certain point you have to start considering risks vs benefits of merging something. Yes Thanks for deep explanation. -Laco. ___ 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] Breaking change in FPC 2.6.1
In our previous episode, LacaK said: > >> explicitly asked by sb ? > > > > Trivial bugfixes especially in the RTL or packages are often > > backported (though we now have the additional difference in the > > buildsystem). > Yes I am here speaking mostly about packages. > And when happens this backporting? Short time before release in a batch > (more bugs in one merge) ? > I known from Marco, that there is mergelog > http://www.stack.nl/~marcov/mergelogs26/database.html > But I do not know, if all this bugs are candidates for merging or simply > it is list of all bugs fixed in trunk and not yet merged? > So I am not sure what will be realy backported and what not ... The main page of the mergelogs of fpc 2.6 atm is http://www.stack.nl/~marcov/mergelogs26/ This is indeed simply a categorization of all differences between trunk and fixes. The "All" page is all eligible revisions (refreshed +/- hourly), and below I've created a rough categorization of the various commits. I also have such page for the lazarus fixes branch, but prefer to move everything to a FPC server before going public with that. Since last weekend this is now hyperlinked (e.g. if a revisions is mentioned like r43324 you can click it, same for mantis rapports). The text versions are also still available (since handier for search as it is a flat file) Policy wise, I merge revisions for utils, packages and the higher level units of RTL like sysutils and classes if they are a couple of weeks old (3-4 weeks), but I usually leave big changes a bit longer. Since last weekend there is a notes system that allows me to add notes to the revs in mergelogs. See r21037 on the database page, it has a red "notes" attached to it. Clicking it will unfold it. This allows for see also and dependencies to be annotated. Besides me, Jonas and Pierre merge part of their fixes themselves, and Florian usually asks me to do it. > > In the compiler it depends on the severity of the changes. E.g. I > > personally don't want to backport most of the generic fixes I have > > done as they introduced or depend on massive changes in the compiler. > Yes it is logical ;-) The work that has to be done various also for e.g. packages. When a branch is fairly new it is easy, between the .2 and the .4 branch it gets harder. At a certain point you have to start considering risks vs benefits of merging something. ___ 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
Sven Barth wrote / napísal(a): Am 03.05.2012 08:39, schrieb LacaK: Hi, I have question indirectly related to this subject ;-) If there are fixed some bugs in trunk (2.7.1 now) can we expect that they will be backported in some of next stable release 2.6 (2.6.2, 2.6.3)? If yes , are there any rules which bugs are / can be / will be backported ? (Now I am not speaking about new features added, but only about bugs fixed) Depends it on fact how complex / risky is fix or must be backporting explicitly asked by sb ? Trivial bugfixes especially in the RTL or packages are often backported (though we now have the additional difference in the buildsystem). Yes I am here speaking mostly about packages. And when happens this backporting? Short time before release in a batch (more bugs in one merge) ? I known from Marco, that there is mergelog http://www.stack.nl/~marcov/mergelogs26/database.html But I do not know, if all this bugs are candidates for merging or simply it is list of all bugs fixed in trunk and not yet merged? So I am not sure what will be realy backported and what not ... In the compiler it depends on the severity of the changes. E.g. I personally don't want to backport most of the generic fixes I have done as they introduced or depend on massive changes in the compiler. Yes it is logical ;-) -Laco. ___ 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
Am 03.05.2012 08:39, schrieb LacaK: Hi, I have question indirectly related to this subject ;-) If there are fixed some bugs in trunk (2.7.1 now) can we expect that they will be backported in some of next stable release 2.6 (2.6.2, 2.6.3)? If yes , are there any rules which bugs are / can be / will be backported ? (Now I am not speaking about new features added, but only about bugs fixed) Depends it on fact how complex / risky is fix or must be backporting explicitly asked by sb ? Trivial bugfixes especially in the RTL or packages are often backported (though we now have the additional difference in the buildsystem). In the compiler it depends on the severity of the changes. E.g. I personally don't want to backport most of the generic fixes I have done as they introduced or depend on massive changes in the compiler. Regards, Sven ___ 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
Hi, I have question indirectly related to this subject ;-) If there are fixed some bugs in trunk (2.7.1 now) can we expect that they will be backported in some of next stable release 2.6 (2.6.2, 2.6.3)? If yes , are there any rules which bugs are / can be / will be backported ? (Now I am not speaking about new features added, but only about bugs fixed) Depends it on fact how complex / risky is fix or must be backporting explicitly asked by sb ? Thanks -Laco. ___ 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
Paul Ishenin schrieb: 02.05.12 18:18, Graeme Geldenhuys wrote: So instead of jumping around with various delphi versions (a bit of D7 and a bit of 2009 etc), maybe start from the oldest delphi version (eg: D7) and move towards the newest? Maybe you can teach us how to do this by sending appropriate patches? We will sit then and criticize them. You cannot expect *users* to supply patches, it's already work enough to only supply test programs which allow to reproduce failures. FPC should not be patchwork, this could be achieved even without core developers. DoDi ___ 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
Tomas Hajny schrieb: On Wed, May 2, 2012 12:27, Hans-Peter Diettrich wrote: Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: The solution is so easy: don't mark it as deprecated. I also have a clear opinion about Delphi compatibility: Every FPC version must be compatible to a Delphi version. A mix of incompatible features from different Delphi versions is useless. We don't have packages. That is what, D3? functionality, so we should now strip down FPC to D3 level? There exist *limitations* due to the FPC multi-platform approach, of course. We cannot claim full compatibility to any Delphi version and we cannot provide complete list of incompatibilities between any particular FPC version and any particular Delphi version. If you're able to create something like that, you're welcome to document and maintain it (e.g. in our Wiki). This would require a list of FPC features, which could be compared to a list of Delphi features. As far as what is more advantageous for users or not - your statement is apparently based on certain assumptions which are probably not valid for all FPC users and probably not even most FPC users. In particular, your statement is fully correct for users extensively using almost all features provided in a particular Delphi version and always rewriting their own previous code (based on language constructs and units delivered with earlier Delphi versions) to the newest set. I had in mind users which must maintain legacy software, written for a specific Delphi version. Or for newbies, which have a working Delphi project and want to check whether it would work with FPC/Lazarus, too. Some picky Delphi users jump in whenever I suggest to have a look at FPC/Lazarus, in a Delphi forum, and report that they downloaded the latest release and tried to run a simple test project, which failed miserably. Other people observe a strange behaviour in an FPC/Lazarus project, and write a test program to find out what Delphi does. They are not really happy when either Delphi or FPC refuse to even *build* that project, due to arbitrary incompatibilities. DoDi ___ 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 2 May 2012 15:59, Paul Ishenin wrote: > ... > Details about these new features can be found at > http://wiki.freepascal.org/FPC_New_Features_2.6.0 Thanks Paul. I didn't know (or forgot) about these links. This would be helpful in creating a wiki matrix page of FPC vs Delphi features. If I get the Delphi versions wrong, maybe somebody with more knowledge of recent Delphi versions could correct those for me. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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, May 2, 2012 at 11:47 AM, Martin Schreiber wrote: > On 02.05.2012 15:41, Marcos Douglas wrote: >> >>> 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. >> Well, that was the way I chose. >> > Please don't forget to call FreeBookmark() in a try ... finally block > otherwise there will be memory leaks in case of exceptions. Yes, I do this always. This is not the best way, I agree, but works. >>> 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. >> The problem, for me, would be break the sources in production. >> If GetBookmarkData and FreeBookmark will continue work so, that is >> what I will use. >> > You could define a "bookmarkty" alias yourself if Lazarus does not > provide it. This is one idea, yes. But I will wait the finish of this history and what will be decided. Marcos Douglas ___ 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 02.05.2012 10:47, michael.vancann...@wisa.be wrote: > > > 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. > MSEide+MSEgui compiles without FPC warnings and notes. I assume other FPC users also make code without warnings and notes. While waiting for compilation we check the compiler output in message window. If there are warnings from your deprecated statement we have to check every time if it is a real warning or a "FPC-Delphi-Future" warning which can't be fixed without using try-finally blocks which should later be removed with FPC trunk because they are redundant thanks to the managed TBytes type. Martin ___ 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 02.05.2012 15:41, Marcos Douglas wrote: > >> 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. > Well, that was the way I chose. > Please don't forget to call FreeBookmark() in a try ... finally block otherwise there will be memory leaks in case of exceptions. >> 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. > The problem, for me, would be break the sources in production. > If GetBookmarkData and FreeBookmark will continue work so, that is > what I will use. > You could define a "bookmarkty" alias yourself if Lazarus does not provide it. Martin ___ 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
02.05.12 21:32, Graeme Geldenhuys wrote: Maybe the FPC core team will be so kind as to create a new "FPC features since xxx" page on the wiki (similar to what I have done for Lazarus). From the anouncement of FPC 2.6.0 which was posted to this mail list: Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.0 ... Details about these new features can be found at http://wiki.freepascal.org/FPC_New_Features_2.6.0 Best regards, Paul Ishenin ___ 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, May 2, 2012 at 5:47 AM, wrote: > > > 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. Well, that was the way I chose. > 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. The problem, for me, would be break the sources in production. If GetBookmarkData and FreeBookmark will continue work so, that is what I will use. Marcos Douglas ___ 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 2 May 2012 13:55, Mattias Gaertner wrote: > > Please don't feed the trolls. By no means did I mean to troll. It was a legit statement, and something that confuses the hell out of FPC developers like myself. For example: tiOPF branched off version 3 so as to support Delph 2009+ support including Unicode (though no delphi unicode features have been added to tiOPF v3 yet). With the mixed bag of Delphi features in Free Pascal, I have no idea when we will be able to add FPC support to tiOPF v3??? A brief attempt showed that FPC 2.6.0 was not able to work, and I have no idea what Delphi features are implemented in FPC Trunk. Maybe the FPC core team will be so kind as to create a new "FPC features since xxx" page on the wiki (similar to what I have done for Lazarus). And on that page have a table or roadmap indicating what Delphi features are supported in what FPC versions. That would give developers like myself, and other commercial entities a clear indication of how "compatible" FPC is with Delphi and if dual-compiler support is possible in our products. @Paul & Mattias I have no idea why you guys think this is trolling. From my point of view [in our company], I need to show a business case for spending my company time working on open source projects especially dual-compiler (Delphi and FPC) projects like tiOPF that require a lot more testing. And no, tiOPF is not the only project like this that our company works on. And again, I don't think I am the only developer with this problem either. I'm pretty sure other companies would appreciate such clear and transparent information from the FPC core team, after all, nobody else is more qualified to know what FPC does and doesn't support. @Everybody else I'm perfectly fine with Michael's solution to this message thread. I don't mind deprecated compiler warnings at all - this gives me enough warning to update my affected source code before the next stable release. But I wasn't appreciative of Macro's idea of simply breaking a stable branch without warning (thus I raised my concern). I'm glad this problem is solved though. @Marco By the looks of recent events, maybe you advice is indeed correct. Maybe my idea of only using the latest released FPC version is too a narrow minded view. Maybe I should test FPC Trunk every few weeks to keep more up to date with FPC developments, and smooth out any possible compatibility problems in our code in preparation of new FPC releases. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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, May 2, 2012 12:27, Hans-Peter Diettrich wrote: > Marco van de Voort schrieb: >> In our previous episode, Hans-Peter Diettrich said: >>> The solution is so easy: don't mark it as deprecated. >>> >>> I also have a clear opinion about Delphi compatibility: Every FPC >>> version must be compatible to a Delphi version. A mix of incompatible >>> features from different Delphi versions is useless. >> >> We don't have packages. That is what, D3? functionality, so we should >> now >> strip down FPC to D3 level? > > There exist *limitations* due to the FPC multi-platform approach, of > course. We cannot claim full compatibility to any Delphi version and we cannot provide complete list of incompatibilities between any particular FPC version and any particular Delphi version. If you're able to create something like that, you're welcome to document and maintain it (e.g. in our Wiki). As far as what is more advantageous for users or not - your statement is apparently based on certain assumptions which are probably not valid for all FPC users and probably not even most FPC users. In particular, your statement is fully correct for users extensively using almost all features provided in a particular Delphi version and always rewriting their own previous code (based on language constructs and units delivered with earlier Delphi versions) to the newest set. In reality, users typically combine code created for earlier versions with selected parts available in newer versions depending on their needs and priorities. Users like this will probably appreciate availability of a certain very new Delphi feature regardless from the fact that certain older Delphi feature may not be supported in FPC yet. For one, they may not use the older feature at all. Even if they do, users like this still need to change less code on their side if the newer feature is supported in FPC. Even when talking about incompatibilities between two particular Delphi versions, they may be less or more relevant/important for a particular user depending on his needs. Some code may be perfectly shared between pre-Unicode and Unicode based Delphi RTL without any changes and some code needs to be rewritten almost completely. In summary, I personally believe that majority of our users would not benefit from your proposal. Nevertheless, you're free to create a special branches selectively merging changes from FPC trunk based on their compatibility with specific Delphi versions. Something like that may be useful for people creating components and units targetting both FPC and Delphi users, but not necessarily for others. In any case, Delphi releases do not drive FPC releases and I personally believe that it is right that way. Tomas ___ 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, 02 May 2012 18:49:13 +0800 Paul Ishenin wrote: > 02.05.12 18:18, Graeme Geldenhuys wrote: > > > So instead of jumping around with various delphi versions (a bit of D7 > > and a bit of 2009 etc), maybe start from the oldest delphi version > > (eg: D7) and move towards the newest? > > Maybe you can teach us how to do this by sending appropriate patches? We > will sit then and criticize them. > > If you don't like the dish - cook yourself. Please don't feed the trolls. This is starting to become off-topic. Mattias ___ 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
02.05.12 18:18, Graeme Geldenhuys wrote: So instead of jumping around with various delphi versions (a bit of D7 and a bit of 2009 etc), maybe start from the oldest delphi version (eg: D7) and move towards the newest? Maybe you can teach us how to do this by sending appropriate patches? We will sit then and criticize them. If you don't like the dish - cook yourself. Best regards, Paul Ishenin ___ 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 2 May 2012 09:00, Hans-Peter Diettrich wrote: > To the user this means "not compatible with D7 nor D2009" :-[ +1000 -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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 1 May 2012 23:48, Hans-Peter Diettrich wrote: > Simply specify the Delphi version, to which FPC 2.6.1 should be compatible, > then the rest is clear. In a way I agree here... It is damn confusing when just saying "delphi compatible". Delphi is NOT a product that is standing still any more, so FPC should start saying which Delphi version they are compatible with - otherwise the statement is just plain vague and helps nobody. This fact of "unknown to which delphi version fpc is compatible with" is causing a maintenance nightmare in some of the dual-compiler (Delphi and FPC) open source projects I maintain. I'm pretty sure I'm not alone in this situation too. So instead of jumping around with various delphi versions (a bit of D7 and a bit of 2009 etc), maybe start from the oldest delphi version (eg: D7) and move towards the newest? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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
Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: The solution is so easy: don't mark it as deprecated. I also have a clear opinion about Delphi compatibility: Every FPC version must be compatible to a Delphi version. A mix of incompatible features from different Delphi versions is useless. We don't have packages. That is what, D3? functionality, so we should now strip down FPC to D3 level? There exist *limitations* due to the FPC multi-platform approach, of course. DoDi ___ 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 02.05.2012 10:47, michael.vancann...@wisa.be wrote: >> 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. That's the idea. When one switches to trunk the compiler will stop at the wrong types and one can change the types possibly in conditional defines if one needs FPC 2.6.0 compatibility. Or maybe Lazarus can define "bookmarkty" too for those who don't care about Delphi compatibility? Martin ___ 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: [fpc-devel] Breaking change in FPC 2.6.1
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. Martin ___ 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
In our previous episode, Hans-Peter Diettrich said: > The solution is so easy: don't mark it as deprecated. > > I also have a clear opinion about Delphi compatibility: Every FPC > version must be compatible to a Delphi version. A mix of incompatible > features from different Delphi versions is useless. We don't have packages. That is what, D3? functionality, so we should now strip down FPC to D3 level? Lazarus likewise, due to MDI? ___ 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
02.05.2012 15:00, Hans-Peter Diettrich wrote: To the user this means "not compatible with D7 nor D2009" :-[ It is both compatible with D7 and some D2009 features. Best regards, Paul Ishenin. ___ 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, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Simply specify the Delphi version, to which FPC 2.6.1 should be compatible, then the rest is clear. There is no such version. 2.6.1 is in many ways D7 compatible, but also has a lot of D20O9 compatible features. I wonder what "in many ways" here means? To the user this means "not compatible with D7 nor D2009" :-[ When a user wants to convert a project from D7 to FPC, which FPC version should he use? In my experience, the "D7 or D2009" version question is the least of the worries if you convert a project. The real important questions are: - Are any third-party components used ? - What database technology is used ? - What reporting technology is used ? The answer to your question is always the same, regardless of the Delphi version: Use the latest stable version. There is no other. 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
Michael Van Canneyt schrieb: Simply specify the Delphi version, to which FPC 2.6.1 should be compatible, then the rest is clear. There is no such version. 2.6.1 is in many ways D7 compatible, but also has a lot of D20O9 compatible features. I wonder what "in many ways" here means? To the user this means "not compatible with D7 nor D2009" :-[ When a user wants to convert a project from D7 to FPC, which FPC version should he use? DoDi ___ 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
Il 01/05/2012 22:05, Sven Barth ha scritto:
On 01.05.2012 22:03, Sven Barth wrote:
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real use. IMO "deprecated"
means to the user that he should change his code *now*, in
anticipation of the coming change. This obviously is not the case
with the breaking change of the bookmark type, where *no* workaround
exists in the current release.
Instead of repeating the remark, suggesting a solution would be
useful.
Criticism is easy. Coming up with solutions obviously much less so.
I never used TDataset.Bookmark, and I'm not likely to use it in future,
so my attitude is that of an external observer, which might be
completely unaware of implications, but, as a general rule, wouldn't it
be wise to surround with an {$mode Delphi} all changes made to comply
with Delphi whims, to satisfy those who need Delphi compatibility, and
keep for the rest of the users things as stable and consistent as
possible, avoiding whenever possible to break compatibility with
existing code?
You can not "surround" code with {$mode Delphi}. It's a unit global
option and also it only changes syntax and semantic handling in the
compiler not code in the units.
Also we are talking about three kinds of Delphi compatible here:
* pre-Delphi 2007 for which used String
* Delphi 2007 which used Pointer
* Delphi 2009 and newer which uses TBytes
This is another reason why using something like "{$mode delphi}" would
be useless here.
Well {$mode Delphi} was just a way to illustrate the point, which could
perhaps obtained with some {$ifdef Delphi-pre07} or {$ifdef Delphi-07}
or {$ifdef Delphi-09} or whatever. Leaving whoever doesn't define a
Delphi compatibility to take advantage of a sane fpc way.
Giuliano
___
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 Tue, 1 May 2012, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Well, then they'll have to live with the warning. And this is the point of having the warning in the first place. Make people aware of a coming change. As already mentioned in this thread, a mere hint about "may change somehow, in the next version" is of no real use. IMO "deprecated" means to the user that he should change his code *now*, in anticipation of the coming change. This obviously is not the case with the breaking change of the bookmark type, where *no* workaround exists in the current release. Instead of repeating the remark, suggesting a solution would be useful. The solution is so easy: don't mark it as deprecated. I also have a clear opinion about Delphi compatibility: Every FPC version must be compatible to a Delphi version. A mix of incompatible features from different Delphi versions is useless. Simply specify the Delphi version, to which FPC 2.6.1 should be compatible, then the rest is clear. There is no such version. 2.6.1 is in many ways D7 compatible, but also has a lot of D20O9 compatible features. 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
Michael Van Canneyt schrieb: Well, then they'll have to live with the warning. And this is the point of having the warning in the first place. Make people aware of a coming change. As already mentioned in this thread, a mere hint about "may change somehow, in the next version" is of no real use. IMO "deprecated" means to the user that he should change his code *now*, in anticipation of the coming change. This obviously is not the case with the breaking change of the bookmark type, where *no* workaround exists in the current release. Instead of repeating the remark, suggesting a solution would be useful. The solution is so easy: don't mark it as deprecated. I also have a clear opinion about Delphi compatibility: Every FPC version must be compatible to a Delphi version. A mix of incompatible features from different Delphi versions is useless. Simply specify the Delphi version, to which FPC 2.6.1 should be compatible, then the rest is clear. DoDi ___ 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 01.05.2012 20:17, Mattias Gaertner wrote:
On Tue, 01 May 2012 15:05:57 +0200
Sven Barth wrote:
[...]
You can locally disable warnings by using the $warn directive (not
documented yet it seems, but available in 2.6.0).
It looks like this:
{$warn MSGID (on|off|error)}
* on: MSGID will be emitted as a warning
* off: MSGID will not be emitted
* error: MSGID will be emitted as an error (and handled as such by the
compiler!)
You can find out the MSGID by passing "-vq" to the compiler then it will
additionally print the ID for each message it writes. For the case of
"deprecated" there are two message IDs: One which is used if a custom
message is given and one for the other case. For the first the ID is
5066 and for the latter 5043.
The following is a demonstration of the potential usage of $warn:
=== example begin ===
program warntest;
{$mode objfpc}
type
TTest = class
procedure Test; deprecated 'Test';
end;
procedure TTest.Test;
begin
end;
var
t: TTest;
begin
{$push} //<= used to restore the state afterwards; you could use {$warn
5066 on} as well
{$warn 5066 off}
t.Test; // here no warning will be emitted
{$pop}
t.Test; // here a warning will be emitted
end.
=== example end ===
Alternatively you can also use
{$warn symbol_deprecated off}
which will switch of both custom and non-custom deprecated messages for
symbols (units have an extra name).
Here is a list of all those recognized identifiers (out of Delphi
compatibility):
CONSTRUCTING_ABSTRACT
IMPLICIT_VARIANTS
NO_RETVAL
SYMBOL_DEPRECATED
SYMBOL_EXPERIMENTAL
SYMBOL_LIBRARY
SYMBOL_PLATFORM
SYMBOL_UNIMPLEMENTED
UNIT_DEPRECATED
UNIT_EXPERIMENTAL
UNIT_LIBRARY
UNIT_PLATFORM
UNIT_UNIMPLEMENTED
ZERO_NIL_COMPAT
IMPLICIT_STRING_CAST
IMPLICIT_VARIANTS
NO_RETVAL
SYMBOL_DEPRECATED
SYMBOL_EXPERIMENTAL
SYMBOL_LIBRARY
SYMBOL_PLATFORM
SYMBOL_UNIMPLEMENTED
UNIT_DEPRECATED
UNIT_EXPERIMENTAL
UNIT_LIBRARY
UNIT_PLATFORM
UNIT_UNIMPLEMENTED
ZERO_NIL_COMPAT
IMPLICIT_STRING_CAST
IMPLICIT_STRING_CAST_LOSS
EXPLICIT_STRING_CAST
EXPLICIT_STRING_CAST_LOSS
CVT_NARROWING_STRING_LOST
Thanks. I added them to codetools.
Is there a similar list for notes and hints?
These strings were added for Delphi compatibility and AFAIK there isn't
any such feature for hints and notes. At least in FPC {$warn MSGID ...}
DOES work for notes and hints messages, but I don't whether this is
intentional or not... (just in case someone thinks that: setting a
hint/note message to "on" using $warn does not make that message behave
like a warning; it will still be a hint or note; {$warn ... error} does
make the message behave like an error though)
As you added this to the codetools another note:
The following syntax is also supported:
{$warn MSGID +} for {$warn MSGID on}
{$warn MSGID -} for {$warn MSGID off}
(works for the mentioned identifiers as well)
Regards,
Sven
___
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 01.05.2012 22:03, Sven Barth wrote:
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real use. IMO "deprecated"
means to the user that he should change his code *now*, in
anticipation of the coming change. This obviously is not the case
with the breaking change of the bookmark type, where *no* workaround
exists in the current release.
Instead of repeating the remark, suggesting a solution would be useful.
Criticism is easy. Coming up with solutions obviously much less so.
I never used TDataset.Bookmark, and I'm not likely to use it in future,
so my attitude is that of an external observer, which might be
completely unaware of implications, but, as a general rule, wouldn't it
be wise to surround with an {$mode Delphi} all changes made to comply
with Delphi whims, to satisfy those who need Delphi compatibility, and
keep for the rest of the users things as stable and consistent as
possible, avoiding whenever possible to break compatibility with
existing code?
You can not "surround" code with {$mode Delphi}. It's a unit global
option and also it only changes syntax and semantic handling in the
compiler not code in the units.
Also we are talking about three kinds of Delphi compatible here:
* pre-Delphi 2007 for which used String
* Delphi 2007 which used Pointer
* Delphi 2009 and newer which uses TBytes
This is another reason why using something like "{$mode delphi}" would
be useless here.
Regards,
Sven
___
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 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real use. IMO "deprecated"
means to the user that he should change his code *now*, in
anticipation of the coming change. This obviously is not the case
with the breaking change of the bookmark type, where *no* workaround
exists in the current release.
Instead of repeating the remark, suggesting a solution would be useful.
Criticism is easy. Coming up with solutions obviously much less so.
I never used TDataset.Bookmark, and I'm not likely to use it in future,
so my attitude is that of an external observer, which might be
completely unaware of implications, but, as a general rule, wouldn't it
be wise to surround with an {$mode Delphi} all changes made to comply
with Delphi whims, to satisfy those who need Delphi compatibility, and
keep for the rest of the users things as stable and consistent as
possible, avoiding whenever possible to break compatibility with
existing code?
You can not "surround" code with {$mode Delphi}. It's a unit global
option and also it only changes syntax and semantic handling in the
compiler not code in the units.
Regards,
Sven
___
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 Tue, 01 May 2012 15:05:57 +0200
Sven Barth wrote:
>[...]
> You can locally disable warnings by using the $warn directive (not
> documented yet it seems, but available in 2.6.0).
>
> It looks like this:
>
> {$warn MSGID (on|off|error)}
>
> * on: MSGID will be emitted as a warning
> * off: MSGID will not be emitted
> * error: MSGID will be emitted as an error (and handled as such by the
> compiler!)
>
> You can find out the MSGID by passing "-vq" to the compiler then it will
> additionally print the ID for each message it writes. For the case of
> "deprecated" there are two message IDs: One which is used if a custom
> message is given and one for the other case. For the first the ID is
> 5066 and for the latter 5043.
>
> The following is a demonstration of the potential usage of $warn:
>
> === example begin ===
>
> program warntest;
>
> {$mode objfpc}
>
> type
>TTest = class
> procedure Test; deprecated 'Test';
>end;
>
> procedure TTest.Test;
> begin
>
> end;
>
> var
>t: TTest;
> begin
> {$push} // <= used to restore the state afterwards; you could use {$warn
> 5066 on} as well
> {$warn 5066 off}
>t.Test; // here no warning will be emitted
> {$pop}
>t.Test; // here a warning will be emitted
> end.
>
> === example end ===
>
> Alternatively you can also use
>
> {$warn symbol_deprecated off}
>
> which will switch of both custom and non-custom deprecated messages for
> symbols (units have an extra name).
>
> Here is a list of all those recognized identifiers (out of Delphi
> compatibility):
>
> CONSTRUCTING_ABSTRACT
> IMPLICIT_VARIANTS
> NO_RETVAL
> SYMBOL_DEPRECATED
> SYMBOL_EXPERIMENTAL
> SYMBOL_LIBRARY
> SYMBOL_PLATFORM
> SYMBOL_UNIMPLEMENTED
> UNIT_DEPRECATED
> UNIT_EXPERIMENTAL
> UNIT_LIBRARY
> UNIT_PLATFORM
> UNIT_UNIMPLEMENTED
> ZERO_NIL_COMPAT
> IMPLICIT_STRING_CAST
> IMPLICIT_VARIANTS
> NO_RETVAL
> SYMBOL_DEPRECATED
> SYMBOL_EXPERIMENTAL
> SYMBOL_LIBRARY
> SYMBOL_PLATFORM
> SYMBOL_UNIMPLEMENTED
> UNIT_DEPRECATED
> UNIT_EXPERIMENTAL
> UNIT_LIBRARY
> UNIT_PLATFORM
> UNIT_UNIMPLEMENTED
> ZERO_NIL_COMPAT
> IMPLICIT_STRING_CAST
> IMPLICIT_STRING_CAST_LOSS
> EXPLICIT_STRING_CAST
> EXPLICIT_STRING_CAST_LOSS
> CVT_NARROWING_STRING_LOST
Thanks. I added them to codetools.
Is there a similar list for notes and hints?
Mattias
___
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
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real use. IMO "deprecated"
means to the user that he should change his code *now*, in
anticipation of the coming change. This obviously is not the case
with the breaking change of the bookmark type, where *no* workaround
exists in the current release.
Instead of repeating the remark, suggesting a solution would be useful.
Criticism is easy. Coming up with solutions obviously much less so.
I never used TDataset.Bookmark, and I'm not likely to use it in future,
so my attitude is that of an external observer, which might be
completely unaware of implications, but, as a general rule, wouldn't it
be wise to surround with an {$mode Delphi} all changes made to comply
with Delphi whims, to satisfy those who need Delphi compatibility, and
keep for the rest of the users things as stable and consistent as
possible, avoiding whenever possible to break compatibility with
existing code?
Giuliano
___
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 1 May 2012 12:11, Martin Schreiber wrote: > Thanks Graeme, I wanted to write something similar but do not dare. I always speak my mind (here and in my personal life) - no point in beating around the bush. This might offend some sensitive readers, but I get my point across as I see it. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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 Tuesday, 1 May 2012, Michael Van Canneyt wrote:. > > On Tue, 1 May 2012, Graeme Geldenhuys wrote: > As I said, the matter is under discussion on Core. Discussions take time. > Marco's and my mail just crossed, that's all. I simply wanted to highlight the fact that those emails gave contradicting information. > > However, be advised that the change to TBytes will be done after 2.6.2 is > out, (so, in 2.6.3) and TBookmarkStr will be marked 'Deprecated' in 2.6.1 > to indicate the upcoming change. A much more sane way of handling it, thanks. > > Graeme. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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 Tue, May 1, 2012 at 12:23 PM, Martin Schreiber wrote: > On Tuesday 01 May 2012 17:08:55 Michael Van Canneyt wrote: >> On Tue, 1 May 2012, Hans-Peter Diettrich wrote: >> > Michael Van Canneyt schrieb: >> >> Well, then they'll have to live with the warning. >> >> >> >> And this is the point of having the warning in the first place. Make >> >> people aware of a coming change. >> > >> > As already mentioned in this thread, a mere hint about "may change >> > somehow, in the next version" is of no real use. IMO "deprecated" means >> > to the user that he should change his code *now*, in anticipation of the >> > coming change. This obviously is not the case with the breaking change of >> > the bookmark type, where *no* workaround exists in the current release. >> >> Instead of repeating the remark, suggesting a solution would be useful. >> >> Criticism is easy. Coming up with solutions obviously much less so. >> > 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. +1 Marcos Douglas ___ 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 Tue, 1 May 2012, Martin Schreiber wrote: On Tuesday 01 May 2012 17:08:55 Michael Van Canneyt wrote: On Tue, 1 May 2012, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Well, then they'll have to live with the warning. And this is the point of having the warning in the first place. Make people aware of a coming change. As already mentioned in this thread, a mere hint about "may change somehow, in the next version" is of no real use. IMO "deprecated" means to the user that he should change his code *now*, in anticipation of the coming change. This obviously is not the case with the breaking change of the bookmark type, where *no* workaround exists in the current release. Instead of repeating the remark, suggesting a solution would be useful. Criticism is easy. Coming up with solutions obviously much less so. 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. 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 Tuesday 01 May 2012 17:08:55 Michael Van Canneyt wrote: > On Tue, 1 May 2012, Hans-Peter Diettrich wrote: > > Michael Van Canneyt schrieb: > >> Well, then they'll have to live with the warning. > >> > >> And this is the point of having the warning in the first place. Make > >> people aware of a coming change. > > > > As already mentioned in this thread, a mere hint about "may change > > somehow, in the next version" is of no real use. IMO "deprecated" means > > to the user that he should change his code *now*, in anticipation of the > > coming change. This obviously is not the case with the breaking change of > > the bookmark type, where *no* workaround exists in the current release. > > Instead of repeating the remark, suggesting a solution would be useful. > > Criticism is easy. Coming up with solutions obviously much less so. > 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. Martin ___ 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 Tue, May 1, 2012 at 12:08 PM, Michael Van Canneyt wrote: > > > On Tue, 1 May 2012, Hans-Peter Diettrich wrote: > >> Michael Van Canneyt schrieb: >> >>> Well, then they'll have to live with the warning. >>> >>> And this is the point of having the warning in the first place. Make >>> people aware of a coming change. >> >> >> As already mentioned in this thread, a mere hint about "may change >> somehow, in the next version" is of no real use. IMO "deprecated" means to >> the user that he should change his code *now*, in anticipation of the coming >> change. This obviously is not the case with the breaking change of the >> bookmark type, where *no* workaround exists in the current release. > > > Instead of repeating the remark, suggesting a solution would be useful. > > Criticism is easy. Coming up with solutions obviously much less so. > > Michael. IMHO, I think they want to back how was before, ie., using TBookmarkStr without 'deprecated'... while the core do not have a solution, first in trunk. Marcos Douglas ___ 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 Tue, 1 May 2012, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: Well, then they'll have to live with the warning. And this is the point of having the warning in the first place. Make people aware of a coming change. As already mentioned in this thread, a mere hint about "may change somehow, in the next version" is of no real use. IMO "deprecated" means to the user that he should change his code *now*, in anticipation of the coming change. This obviously is not the case with the breaking change of the bookmark type, where *no* workaround exists in the current release. Instead of repeating the remark, suggesting a solution would be useful. Criticism is easy. Coming up with solutions obviously much less so. 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 Tuesday 01 May 2012 17:42:51 Hans-Peter Diettrich wrote: > Michael Van Canneyt schrieb: > > Well, then they'll have to live with the warning. > > > > And this is the point of having the warning in the first place. Make > > people aware of a coming change. > > As already mentioned in this thread, a mere hint about "may change > somehow, in the next version" is of no real use. IMO "deprecated" means > to the user that he should change his code *now*, in anticipation of the > coming change. This obviously is not the case with the breaking change > of the bookmark type, where *no* workaround exists in the current release. > Exactly. Thanks DoDi for clarifying my concerns. :-) Martin ___ 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
Michael Van Canneyt schrieb: Well, then they'll have to live with the warning. And this is the point of having the warning in the first place. Make people aware of a coming change. As already mentioned in this thread, a mere hint about "may change somehow, in the next version" is of no real use. IMO "deprecated" means to the user that he should change his code *now*, in anticipation of the coming change. This obviously is not the case with the breaking change of the bookmark type, where *no* workaround exists in the current release. DoDi ___ 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 Tue, 1 May 2012, Martin Schreiber wrote:
On Tuesday 01 May 2012 15:05:57 Sven Barth wrote:
What do you suggest to avoid the warning?
You can locally disable warnings by using the $warn directive (not
documented yet it seems, but available in 2.6.0).
It looks like this:
{$warn MSGID (on|off|error)}
Thanks, but I think this is much work for the MSEide+MSEgui users to switch
the warning off before every use of TDataset.Bookmark and switch on again
afterwards.
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place.
Make people aware of a coming change.
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 01.05.2012 15:19, Martin Schreiber wrote:
On Tuesday 01 May 2012 15:05:57 Sven Barth wrote:
What do you suggest to avoid the warning?
You can locally disable warnings by using the $warn directive (not
documented yet it seems, but available in 2.6.0).
It looks like this:
{$warn MSGID (on|off|error)}
Thanks, but I think this is much work for the MSEide+MSEgui users to switch
the warning off before every use of TDataset.Bookmark and switch on again
afterwards.
Only because it is normally used locally does not mean that you MUST use
it locally... you can put it at the top of your unit as well, but this
means that ALL deprecated messages will not be shown for that unit.
Alternatively you can also use the "-vmMSGID[,MSGID[,...]]" option which
allows you to mute a message on the command line (this option is
supported by Lazarus btw.).
In the particular case you'd pass -vm5066,5043 to the compiler to mute
both kinds of deprecated messages (of course this has the same drawback
as putting the $warn directive at the top of the unit).
There are no other possibilities to hide the message.
Regards,
Sven
___
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 Tuesday 01 May 2012 15:05:57 Sven Barth wrote:
> > What do you suggest to avoid the warning?
>
> You can locally disable warnings by using the $warn directive (not
> documented yet it seems, but available in 2.6.0).
>
> It looks like this:
>
> {$warn MSGID (on|off|error)}
>
Thanks, but I think this is much work for the MSEide+MSEgui users to switch
the warning off before every use of TDataset.Bookmark and switch on again
afterwards.
Martin
___
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 01.05.2012 13:57, Martin Schreiber wrote:
On Tuesday 01 May 2012 13:50:49 Sven Barth wrote:
On 01.05.2012 13:50, Martin Schreiber wrote:
Anyway, the change is undone, we're back on TBookmarkStr.
TBookMarkStr is now marked deprecated. Revision 21155.
Thank you very much. That means it is not possible to work with fixes_2_6
without "deprecated" warnings? TDataset.Bookmark is of type TBookmarkStr
but TBookmarkStr is deprecated?
Exactly. These were added to remind everyone who uses TBookmarkStr that
there WILL be a change after 2.6.2 has been released (thus in 2.6.3) as
Michael explained.
What do you suggest to avoid the warning?
You can locally disable warnings by using the $warn directive (not
documented yet it seems, but available in 2.6.0).
It looks like this:
{$warn MSGID (on|off|error)}
* on: MSGID will be emitted as a warning
* off: MSGID will not be emitted
* error: MSGID will be emitted as an error (and handled as such by the
compiler!)
You can find out the MSGID by passing "-vq" to the compiler then it will
additionally print the ID for each message it writes. For the case of
"deprecated" there are two message IDs: One which is used if a custom
message is given and one for the other case. For the first the ID is
5066 and for the latter 5043.
The following is a demonstration of the potential usage of $warn:
=== example begin ===
program warntest;
{$mode objfpc}
type
TTest = class
procedure Test; deprecated 'Test';
end;
procedure TTest.Test;
begin
end;
var
t: TTest;
begin
{$push} // <= used to restore the state afterwards; you could use {$warn
5066 on} as well
{$warn 5066 off}
t.Test; // here no warning will be emitted
{$pop}
t.Test; // here a warning will be emitted
end.
=== example end ===
Alternatively you can also use
{$warn symbol_deprecated off}
which will switch of both custom and non-custom deprecated messages for
symbols (units have an extra name).
Here is a list of all those recognized identifiers (out of Delphi
compatibility):
CONSTRUCTING_ABSTRACT
IMPLICIT_VARIANTS
NO_RETVAL
SYMBOL_DEPRECATED
SYMBOL_EXPERIMENTAL
SYMBOL_LIBRARY
SYMBOL_PLATFORM
SYMBOL_UNIMPLEMENTED
UNIT_DEPRECATED
UNIT_EXPERIMENTAL
UNIT_LIBRARY
UNIT_PLATFORM
UNIT_UNIMPLEMENTED
ZERO_NIL_COMPAT
IMPLICIT_STRING_CAST
IMPLICIT_VARIANTS
NO_RETVAL
SYMBOL_DEPRECATED
SYMBOL_EXPERIMENTAL
SYMBOL_LIBRARY
SYMBOL_PLATFORM
SYMBOL_UNIMPLEMENTED
UNIT_DEPRECATED
UNIT_EXPERIMENTAL
UNIT_LIBRARY
UNIT_PLATFORM
UNIT_UNIMPLEMENTED
ZERO_NIL_COMPAT
IMPLICIT_STRING_CAST
IMPLICIT_STRING_CAST_LOSS
EXPLICIT_STRING_CAST
EXPLICIT_STRING_CAST_LOSS
CVT_NARROWING_STRING_LOST
Regards,
Sven
___
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 Tuesday 01 May 2012 14:48:48 Michael Van Canneyt wrote: > On Tue, 1 May 2012, Martin Schreiber wrote: > > On Tuesday 01 May 2012 13:50:49 Sven Barth wrote: > >> On 01.05.2012 13:50, Martin Schreiber wrote: > Anyway, the change is undone, we're back on TBookmarkStr. > TBookMarkStr is now marked deprecated. Revision 21155. > >>> > >>> Thank you very much. That means it is not possible to work with > >>> fixes_2_6 without "deprecated" warnings? TDataset.Bookmark is of type > >>> TBookmarkStr but TBookmarkStr is deprecated? > >> > >> Exactly. These were added to remind everyone who uses TBookmarkStr that > >> there WILL be a change after 2.6.2 has been released (thus in 2.6.3) as > >> Michael explained. > > > > What do you suggest to avoid the warning? > > fpc yourproject |& grep -iv deprecated > I don't think MSEide users like that solution. What about real "deprecated" warnings where it is possible to use a not deprecated construct instead? In MSEgui I probably will introduce "bookmarkty" in order to hide the change but what about Lazarus which must be Delphi compatible? Martin ___ 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 Tue, 1 May 2012, Martin Schreiber wrote: On Tuesday 01 May 2012 12:51:39 Michael Van Canneyt wrote: As I wrote to Graeme: These things take time, and you should allow for this. Remember, FPC is a hobby project for the core team. I have currently 2 paying jobs to make ends meet, but do try to squeeze in as much FPC as I possibly can. Jup, I have a similar situation with MSEide+MSEgui. Thanks for your time. :-) So patience, please. All this picking on FPC core does not help. The solution is simple: do not merge breaking Delphi compatibility changes to fixes_2_6. Opinions on this vary. And it takes time to resolve differences in opinion. Often more so than resolving bugs. 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 Tue, 1 May 2012, Martin Schreiber wrote: On Tuesday 01 May 2012 13:50:49 Sven Barth wrote: On 01.05.2012 13:50, Martin Schreiber wrote: Anyway, the change is undone, we're back on TBookmarkStr. TBookMarkStr is now marked deprecated. Revision 21155. Thank you very much. That means it is not possible to work with fixes_2_6 without "deprecated" warnings? TDataset.Bookmark is of type TBookmarkStr but TBookmarkStr is deprecated? Exactly. These were added to remind everyone who uses TBookmarkStr that there WILL be a change after 2.6.2 has been released (thus in 2.6.3) as Michael explained. What do you suggest to avoid the warning? fpc yourproject |& grep -iv deprecated 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 Tuesday 01 May 2012 13:50:49 Sven Barth wrote: > On 01.05.2012 13:50, Martin Schreiber wrote: > >> Anyway, the change is undone, we're back on TBookmarkStr. > >> TBookMarkStr is now marked deprecated. Revision 21155. > > > > Thank you very much. That means it is not possible to work with fixes_2_6 > > without "deprecated" warnings? TDataset.Bookmark is of type TBookmarkStr > > but TBookmarkStr is deprecated? > > Exactly. These were added to remind everyone who uses TBookmarkStr that > there WILL be a change after 2.6.2 has been released (thus in 2.6.3) as > Michael explained. > What do you suggest to avoid the warning? Martin ___ 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 01.05.2012 13:50, Martin Schreiber wrote: Anyway, the change is undone, we're back on TBookmarkStr. TBookMarkStr is now marked deprecated. Revision 21155. Thank you very much. That means it is not possible to work with fixes_2_6 without "deprecated" warnings? TDataset.Bookmark is of type TBookmarkStr but TBookmarkStr is deprecated? Exactly. These were added to remind everyone who uses TBookmarkStr that there WILL be a change after 2.6.2 has been released (thus in 2.6.3) as Michael explained. Regards, Sven ___ 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 Tuesday 01 May 2012 12:51:39 Michael Van Canneyt wrote: > > As I wrote to Graeme: > These things take time, and you should allow for this. > > Remember, FPC is a hobby project for the core team. > I have currently 2 paying jobs to make ends meet, > but do try to squeeze in as much FPC as I possibly can. > Jup, I have a similar situation with MSEide+MSEgui. Thanks for your time. :-) > So patience, please. All this picking on FPC core does not help. > The solution is simple: do not merge breaking Delphi compatibility changes to fixes_2_6. > Anyway, the change is undone, we're back on TBookmarkStr. > TBookMarkStr is now marked deprecated. Revision 21155. > Thank you very much. That means it is not possible to work with fixes_2_6 without "deprecated" warnings? TDataset.Bookmark is of type TBookmarkStr but TBookmarkStr is deprecated? Martin ___ 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 Tue, 1 May 2012, Martin Schreiber wrote: On Tuesday 01 May 2012 11:52:07 Graeme Geldenhuys wrote: On 30 April 2012 14:22, Marco van de Voort wrote: What is the decision of FPC-core? Still the same. I'm waiting till it is suffiently tested to merge it back. OK, am I understanding this correctly. One core member, Michael, say there is no decision yet (revert or keep). Then another core developer, you, say the change will stay and trunk changes will be merged back into 2.6.1 when trunk is tested WTF?!#@! Core members can't agree on what is happening in FPC. The left hand doesn't know what the right hand is doing!! And who suffers, the FPC users and framework developers. Thanks Graeme, I wanted to write something similar but do not dare. As I wrote to Graeme: These things take time, and you should allow for this. Remember, FPC is a hobby project for the core team. I have currently 2 paying jobs to make ends meet, but do try to squeeze in as much FPC as I possibly can. So patience, please. All this picking on FPC core does not help. Anyway, the change is undone, we're back on TBookmarkStr. TBookMarkStr is now marked deprecated. Revision 21155. 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 Tuesday 01 May 2012 11:52:07 Graeme Geldenhuys wrote: > On 30 April 2012 14:22, Marco van de Voort wrote: > >> What is the decision of FPC-core? > > > > Still the same. I'm waiting till it is suffiently tested to merge it > > back. > > OK, am I understanding this correctly. One core member, Michael, say > there is no decision yet (revert or keep). Then another core > developer, you, say the change will stay and trunk changes will be > merged back into 2.6.1 when trunk is tested > > WTF?!#@! Core members can't agree on what is happening in FPC. The > left hand doesn't know what the right hand is doing!! And who suffers, > the FPC users and framework developers. Thanks Graeme, I wanted to write something similar but do not dare. Martin ___ 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 Tue, 1 May 2012, Graeme Geldenhuys wrote: On 30 April 2012 14:22, Marco van de Voort wrote: What is the decision of FPC-core? Still the same. I'm waiting till it is suffiently tested to merge it back. OK, am I understanding this correctly. One core member, Michael, say there is no decision yet (revert or keep). Then another core developer, you, say the change will stay and trunk changes will be merged back into 2.6.1 when trunk is tested WTF?!#@! Core members can't agree on what is happening in FPC. The left hand doesn't know what the right hand is doing!! And who suffers, the FPC users and framework developers. Graeme, please calm down. No need to get excited. As I said, the matter is under discussion on Core. Discussions take time. Marco's and my mail just crossed, that's all. The way things are looking now, the merge will be undone, I will be doing it myself. However, be advised that the change to TBytes will be done after 2.6.2 is out, (so, in 2.6.3) and TBookmarkStr will be marked 'Deprecated' in 2.6.1 to indicate the upcoming change. This will allow for testing in trunk and will give people time to adapt their code to work with both branches. At the same time, we're slowly moving forward the 2.6 branch to a more Delphi 2009+ compatible state, which was Marco's initial goal. 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 30 April 2012 14:22, Marco van de Voort wrote: >> >> What is the decision of FPC-core? > > Still the same. I'm waiting till it is suffiently tested to merge it back. OK, am I understanding this correctly. One core member, Michael, say there is no decision yet (revert or keep). Then another core developer, you, say the change will stay and trunk changes will be merged back into 2.6.1 when trunk is tested WTF?!#@! Core members can't agree on what is happening in FPC. The left hand doesn't know what the right hand is doing!! And who suffers, the FPC users and framework developers. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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
In our previous episode, Martin Schreiber said: > > > > > > > > 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). > > > > I strongly recommend to revert the type of TDataSet.Bookmark to > > TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of > > TDataSet.Bookmark = tbytes in FPC 2.7.1 only. > > What is the decision of FPC-core? Still the same. I'm waiting till it is suffiently tested to merge it back. ___ 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
In our previous episode, Alexander Klenin said: > On Fri, Apr 27, 2012 at 20:28, Marco van de Voort wrote: > > Calling a virtual(!) method when a bookmark is no longer needed allows to do > > other things too, like releasing something with db handles, and allows > > descendents of TDataset to do such things. > > Did you consider declaring TBookmark an interface? No. The considerations were to chiefly to become delphi compatible, and reduce disruption in the long run. I did a misguided attempt at a D2007 inbetween step, and now trunk has the definitive D2009+ layout. > This way you may get the benefits of both worlds -- > automatic memory management plus an ability to hook > into a deallocation. When designed from scratch that would have been a possibility, certainly. ___ 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 Mon, 30 Apr 2012, Martin Schreiber wrote: On Monday 30 April 2012 13:40:43 Marcos Douglas wrote: I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in FPC 2.7.1 only. What is the decision of FPC-core? I think is TDataSet.Bookmark = TBytes. Thanks. So the decision is to change TDataSet.Bookmark from TBookmarkStr to TBytes in FPC 2.6.1 which breaks FPC 2.6.0 user and framework code? Are there other breaking changes planned for FPC 2.6.1? cpstrnew related maybe? Wait. The matter is still under discussion on core. 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 Monday 30 April 2012 13:40:43 Marcos Douglas wrote: > >> I strongly recommend to revert the type of TDataSet.Bookmark to > >> TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of > >> TDataSet.Bookmark = tbytes in FPC 2.7.1 only. > > > > What is the decision of FPC-core? > > I think is TDataSet.Bookmark = TBytes. > Thanks. So the decision is to change TDataSet.Bookmark from TBookmarkStr to TBytes in FPC 2.6.1 which breaks FPC 2.6.0 user and framework code? Are there other breaking changes planned for FPC 2.6.1? cpstrnew related maybe? Martin ___ 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 Mon, Apr 30, 2012 at 1:56 AM, Martin Schreiber wrote: > On Thursday 26 April 2012 06:58:01 Martin Schreiber wrote: >> On Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote: >> > 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). >> >> I strongly recommend to revert the type of TDataSet.Bookmark to >> TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of >> TDataSet.Bookmark = tbytes in FPC 2.7.1 only. > > What is the decision of FPC-core? I think is TDataSet.Bookmark = TBytes. Marcos Douglas ___ 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 Thursday 26 April 2012 06:58:01 Martin Schreiber wrote: > On Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote: > > 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). > > I strongly recommend to revert the type of TDataSet.Bookmark to > TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of > TDataSet.Bookmark = tbytes in FPC 2.7.1 only. What is the decision of FPC-core? Thanks, Martin ___ 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 Fri, Apr 27, 2012 at 20:28, Marco van de Voort wrote: > Calling a virtual(!) method when a bookmark is no longer needed allows to do > other things too, like releasing something with db handles, and allows > descendents of TDataset to do such things. Did you consider declaring TBookmark an interface? This way you may get the benefits of both worlds -- automatic memory management plus an ability to hook into a deallocation. -- Alexander S. Klenin ___ 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 4/27/2012 03:45, Ivan Bobyr wrote: PS: If the main advantage of FPC over C/C++ is its automatic memory management then we should obviously use it, correct ? FWIW and as late to the conversation as it is, i must add that it isn't memory management that's the big plus for pascal languages... it is the structured format that's the biggest plus... ie: define variables in their place before using them and not in the middle of code where they may be missed... there is, of course, the gun and foot problem that C and C related languages bring to the table... that being that they will help one find the gun, point it at their foot and it will also putt the trigger for them ;) my apologies if that seem evangelical and/or off topic ;) ___ 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 Thu, Apr 26, 2012 at 5:35 AM, Graeme Geldenhuys wrote: > On 26 April 2012 06:58, Martin Schreiber wrote: >> >> I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr >> in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in >> FPC 2.7.1 only. > > > Macro wants feedback, well here is some... I fully agree with Martin. > Please revert such code breaking changes in the STABLE 2.6.x release! > > When I (and many other FPC users) update our 2.6.x to the latest > "fixes" commits, we don't expect breakage! Breakages belong in TRUNK > only. +1 IMHO even new things and improvements would be welcome, but not break the old things. Marcos Douglas ___ 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 Friday 27 April 2012 11:33:50 Jonas Maebe wrote: > marcov wrote on Fri, 27 Apr 2012: > > In our previous episode, Ivan Bobyr said: > >> But it's difficult to object to the below Martin's statement: > >> -- > >> Please change TDataset.Bookmark to tbytes = array of byte if you > >> absolutely need to change it in fixes_2_6 so we have a bookmark type > >> with automatic memory management again. > > > > That's what he _first_ said. Later he didn't want to change anything at > > all. > > Well, in fairness he did add "if you absolutely need to change it in > fixes_2_6" the first time, so I think the fact that he prefers no > change at all to this API did not change. > Correct. Martin ___ 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
marcov wrote on Fri, 27 Apr 2012: In our previous episode, Ivan Bobyr said: But it's difficult to object to the below Martin's statement: -- Please change TDataset.Bookmark to tbytes = array of byte if you absolutely need to change it in fixes_2_6 so we have a bookmark type with automatic memory management again. That's what he _first_ said. Later he didn't want to change anything at all. Well, in fairness he did add "if you absolutely need to change it in fixes_2_6" the first time, so I think the fact that he prefers no change at all to this API did not change. Jonas ___ 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
In our previous episode, Ivan Bobyr said: > But it's difficult to object to the below Martin's statement: > -- > Please change TDataset.Bookmark to tbytes = array of byte if you absolutely > need to change it in fixes_2_6 so we have a bookmark type with automatic > memory management again. That's what he _first_ said. Later he didn't want to change anything at all. Currently in 2.7.1 this (TBytes) is already done, I'm waiting for (testing)feedback before merging. > PS: > If the main advantage of FPC over C/C++ is its automatic memory management > then we should obviously use it, correct ? Not all problems in programming are related to (automatic or not) memory management :-) Calling a virtual(!) method when a bookmark is no longer needed allows to do other things too, like releasing something with db handles, and allows descendents of TDataset to do such things. But apparently I was mistaken about this (or at least how recent freebookmark use was in the Delphi community). So let's just push it to the current Delphi situation as quickly as reasonably possible, and lets forget about the whole thing. As far as the C/C++ vs Pascal comparison goes, FPC has as advantage over mandatory GC languages like Java that you are not chained to automatic memorymanagement. So use of it must be scrutinized. ___ 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
But it's difficult to object to the below Martin's statement: -- Please change TDataset.Bookmark to tbytes = array of byte if you absolutely need to change it in fixes_2_6 so we have a bookmark type with automatic memory management again. PS: If the main advantage of FPC over C/C++ is its automatic memory management then we should obviously use it, correct ? ___ 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 26 April 2012 06:58, Martin Schreiber wrote: > > I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr > in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in > FPC 2.7.1 only. Macro wants feedback, well here is some... I fully agree with Martin. Please revert such code breaking changes in the STABLE 2.6.x release! When I (and many other FPC users) update our 2.6.x to the latest "fixes" commits, we don't expect breakage! Breakages belong in TRUNK only. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ 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 Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote: > 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). I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in FPC 2.7.1 only. I invite the FPC 2.6.1 users to write here if they like such breaking changes in fixes_2_6 or not so Marco can make a well-founded decision. At least TDataSet.Bookmark = TBookmark should be reverted to TDataSet.Bookmark = TBookmarkStr immediately so FPC 2.6.1 users don't have to change their code from " var bm: tbookmarkstr; [...] bm:= .bookmark; //do something with .bookmark:= bm; //restore DB cursor " to " var bm: tbookmark; [...] bm:= .bookmark; try //do something with .bookmark:= bm; //restore DB cursor finally .freebookmark(bm); //avoid memory leak end; " for several weeks. Please note, it affects *all* user code with TDataset.Bookmark the problem is not internal to the toolkits only. Martin ___ 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, 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: [fpc-devel] Breaking change in FPC 2.6.1
Jonas Maebe schrieb: Graeme Geldenhuys wrote on Wed, 25 Apr 2012: 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! That's not entirely correct. It's of course mainly for fixes, but small new features or important bug fixes that may break backwards compatibility can also be merged under certain circumstances. What is acceptable and what is not is obviously in the eye of the beholder, and it's not uncommon to also have internal discussions about that among the core developers. From the user VP the newer Delphi versions introduce a couple of breaking changes, so that it's highly desireable to have different Delphi *and* FPC versions available for maintaining legacy projects. In Delphi this ends up in the use of different versions for different projects - but what about FPC (and Lazarus)? What's the last maintained FPC version, compatible with pre-Unicode Delphi? Do we have a compatibility list, between Delphi and FPC/Lazarus versions? IMO changes introduced in Unicode Delphi (>2009) should be introduced only into equivalent Unicode FPC, not into older versions. DoDi ___ 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: [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Graeme Geldenhuys said: > Ah yes, the core developers live by different rules to all of use. Graeme, please stick to the topic, and leave your perceived project management whining out of it. If you want to avoid these kind of issues, I encourage you to step up your trunk testing to at least once every six weeks, and speak up in time next time. (and preferably on topic, with patches and testdata) Without serious testing of trunk, it is hard to take your criticism on policies seriously, since all you do is criticise in retrospect. ___ 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: [fpc-devel] Breaking change in FPC 2.6.1
On 25 April 2012 13:10, Jonas Maebe wrote: > > That's not entirely correct. Ah yes, the core developers live by different rules to all of use. > features or important bug fixes that may break backwards compatibility can > also be merged under certain circumstances. Strange then that in the last few years of me using FPC released versions and tracking the "fixes" branch, I can't recall every seeing a merge that breaks so much code in a "stable release" - yet is allowed to stay. Hell, I asked for much less in the past - and that was declined purely because it was a "minor new feature" - even though it wouldn't break anybody's code. -- Regards, - Graeme - ___ 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
Graeme Geldenhuys wrote on Wed, 25 Apr 2012: 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! That's not entirely correct. It's of course mainly for fixes, but small new features or important bug fixes that may break backwards compatibility can also be merged under certain circumstances. What is acceptable and what is not is obviously in the eye of the beholder, and it's not uncommon to also have internal discussions about that among the core developers. [Marco: practice what you preach] If your intention is to get this resolved to your satisfaction, then making it personal probably also has the "total opposite effect". Jonas ___ 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
RE : RE : [fpc-devel] Breaking change in FPC 2.6.1
> > It broke also lazarus, MDO, rxmemds. > > 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. > > to the change to pointer isn't needed anymore for tbytes as it is a > > managed type. Why not bite the bullet immediately and just skip > > pointer? Avoiding incompatibility clearly failed. > > That can be discussed. Specially if sb can confirm that it works. > > I can however remember having read that freebookmark is still > recommended, and if I look at the method, it is virtual and > allows descendants to do extra processing. > > Probably because one can't trigger and event on freeing of an > automated type (at least not the array based ones, interfaces > is a differnet matter) > > 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. IMHO that would be only the case for those datasets that were developped with the intermediate non-managed Tbookmark=pointer. 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. > > On the Delphi forums, similar discussions have been going > on: people > > complaining about the different Tbookmark implementations > and having > > to change their code. Wish we could have learned from that. > > 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. > > > Freebookmark should have been called already, afaik it is at > > > least since D2006, if not easier, and FPC also implements it > > > quite a while. > > > > > > > > http://docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.FreeBookm > > ark > > Quote: "TBookmark is an alias of TBytes. This means that > TBookmark is > > automatically garbage collected when it goes out of scope. > Because TBookmark > > does not need to free memory, the FreeBookmark method is > blank for the > > default implementation." > > True. But it is virtual, so if your code is agnostic wrt the > dataset you use, or can be layered on top of otther datasets, > you should call freebookmark probably even if it doesn't for > the default dataset. > > 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. Delphi created a mess. Don't let us add to it. Having an empty freebookmark implementation will ease migration from Delphi code that needed it at one point in time. Just make that new fpc code won't need it. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Breaking change in FPC 2.6.1
In our previous episode, Ludo Brands said: > It broke also lazarus, MDO, rxmemds. 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 first changed it to tbytes (as it is in D2009+), but got > > some comments that that was very incompatible, and a lot of > > method signatures would change. So I kept it pchar. (planning > > to change it to tbytes in trunk eventually) > > > > If it were pchar we wouldn't have the problems since pchar and string are > assignment compatible. It is pointer now. Sorry, mixed up with the trecordbuffer stuff again, which I kept pchar, which is not "later Delphi" compatible, as Martin Schreiber clearly exposed in his mail. The bookmark situation is different. I can't really recall what the rationale was atm. I assume the main rationale was to simply start with creating a division between tbookmark and tbookmarkstr. > Don't know where the comments came from but here we are in a situation where > most 3rd party datasets had to be adapted to the change to pointer and will > have to change again to tbytes later on. On top of that the freebookmark > that a lot of third code had to add to catch up to the change to pointer > isn't needed anymore for tbytes as it is a managed type. Why not bite the > bullet immediately and just skip pointer? Avoiding incompatibility clearly > failed. That can be discussed. Specially if sb can confirm that it works. I can however remember having read that freebookmark is still recommended, and if I look at the method, it is virtual and allows descendants to do extra processing. Probably because one can't trigger and event on freeing of an automated type (at least not the array based ones, interfaces is a differnet matter) But I assume that is more for the dataset users that use tbookmark than for internal use in tdataset implementers. > On the Delphi forums, similar discussions have been going on: people > complaining about the different Tbookmark implementations and having to > change their code. Wish we could have learned from that. 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. > > Freebookmark should have been called already, afaik it is at > > least since D2006, if not easier, and FPC also implements it > > quite a while. > > > > http://docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.FreeBookmark > Quote: "TBookmark is an alias of TBytes. This means that TBookmark is > automatically garbage collected when it goes out of scope. Because TBookmark > does not need to free memory, the FreeBookmark method is blank for the > default implementation." True. But it is virtual, so if your code is agnostic wrt the dataset you use, or can be layered on top of otther datasets, you should call freebookmark probably even if it doesn't for the default dataset. IOW my idea is document and recommendthe way that always works now, not shortcuts that may be possible for historic reasons. ___ 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
> -Message d'origine- > De : fpc-devel-boun...@lists.freepascal.org > [mailto:fpc-devel-boun...@lists.freepascal.org] De la part de > Marco van de Voort > Envoyé : mardi 24 avril 2012 23:13 > À : FPC developers' list > Objet : Re: [fpc-devel] Breaking change in FPC 2.6.1 > > > In our previous episode, Martin Schreiber said: > > Changing TDataset.Bookmark from TBookmarkStr to TBookmark > in fixes_2_6 > > breaks > > FPC 2.6.0 compatible code. Is this intended? > > Yes. It should not break proper code (since that would > already treat it as abstract type and call freebookmark). > It broke also lazarus, MDO, rxmemds. > > TBookmark is defined as "Pointer" which has no automatic memory > > management so > > probably TDataset.FreeBookmark() must be called in a try > finally block for > > every assignment of TDataset.Bookmark to a variable. > > As intended too? > > I first changed it to tbytes (as it is in D2009+), but got > some comments that that was very incompatible, and a lot of > method signatures would change. So I kept it pchar. (planning > to change it to tbytes in trunk eventually) > If it were pchar we wouldn't have the problems since pchar and string are assignment compatible. It is pointer now. Don't know where the comments came from but here we are in a situation where most 3rd party datasets had to be adapted to the change to pointer and will have to change again to tbytes later on. On top of that the freebookmark that a lot of third code had to add to catch up to the change to pointer isn't needed anymore for tbytes as it is a managed type. Why not bite the bullet immediately and just skip pointer? Avoiding incompatibility clearly failed. On the Delphi forums, similar discussions have been going on: people complaining about the different Tbookmark implementations and having to change their code. Wish we could have learned from that. > Freebookmark should have been called already, afaik it is at > least since D2006, if not easier, and FPC also implements it > quite a while. > http://docwiki.embarcadero.com/Libraries/en/Data.DB.TDataSet.FreeBookmark Quote: "TBookmark is an alias of TBytes. This means that TBookmark is automatically garbage collected when it goes out of scope. Because TBookmark does not need to free memory, the FreeBookmark method is blank for the default implementation." Ludo ___ 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 Tuesday 24 April 2012 23:13:26 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6
> > breaks FPC 2.6.0 compatible code. Is this intended?
>
> Yes. It should not break proper code (since that would already treat it as
> abstract type and call freebookmark).
>
I don't understand. This is from FPC 2.6.0:
"
{ TDataSet }
TBookmark = Pointer;
TBookmarkStr = string;
[...]
procedure FreeBookmark(ABookmark: TBookmark); virtual;
property Bookmark: TBookmarkStr read GetBookmarkStr write SetBookmarkStr;
"
Proper FPC 2.6.0 code treat TDataset.Bookmark as TBookmarkStr, will not call
TDataSet.FreeBookmark() because the parameter does not match and will not use
an additional try finally block because there is an implicit try finally to
finalize the variables with automatic memory management by the compiler
already.
> > TBookmark is defined as "Pointer" which has no automatic memory
> > management so probably TDataset.FreeBookmark() must be called in a try
> > finally block for every assignment of TDataset.Bookmark to a variable.
> > As intended too?
>
> I first changed it to tbytes (as it is in D2009+), but got some comments
> that that was very incompatible, and a lot of method signatures would
> change. So I kept it pchar. (planning to change it to tbytes in trunk
> eventually)
>
Please change TDataset.Bookmark to tbytes = array of byte if you absolutely
need to change it in fixes_2_6 so we have a bookmark type with automatic
memory management again.
> Freebookmark should have been called already, afaik it is at least
> since D2006, if not easier, and FPC also implements it quite a while.
>
Marco, please, in my opinion the purpose of Free Pascal should be to provide a
handy, versatile and user friendly tool which can be used from pupils to
professionals. I know that there is a need to have a Delphi second source
compiler in case Embarcadero drops it but there are other requirements too. I
am really angry now.
Martin
___
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 Tue, Apr 24, 2012 at 6:18 PM, Marco van de Voort wrote:
> In our previous episode, Marcos Douglas said:
>> > every assignment of TDataset.Bookmark to a variable.
>> > As intended too?
>>
>> This broke the ZEOS 6.6.6-stable and 7.0.0-alpha too (patch to zeos 7
>> in attachment for somebody want).
>
> zeoslib_testing (7 trunk) has a "have_tbookmark" define to handle it, and it
> was
> already prepared for these (and the recordbuffer) changes:
>
> {$IF FPC_FULLVERSION>20600} // will be introduced in 2.6.2 (and up to date
> 2.6.1)
> {$DEFINE WITH_TRECORDBUFFER}
> {$DEFINE WITH_TBOOKMARK} // Have TBookmark
> {$IFEND}
I didn't know that. But I'm using 7-alpha now.
Anyway, thanks for the tip.
> ZEOS 6.6.6 stable was already broken on 2.6.0 anyway due to the "constref"
> changes.
Yes, but I changed the code to work.
Marcos Douglas
___
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
In our previous episode, Vincent Snijders said: > >> FPC 2.6.0 compatible code. Is this intended? > >> TBookmark is defined as "Pointer" which has no automatic memory management > >> so > >> probably TDataset.FreeBookmark() must be called in a try finally block for > >> every assignment of TDataset.Bookmark to a variable. > >> As intended too? > > > > This broke the ZEOS 6.6.6-stable and 7.0.0-alpha too (patch to zeos 7 > > in attachment for somebody want). > > > > If this changes is kept, maybe it should be added to > http://wiki.freepascal.org/User_Changes_Trunk and Will do tomorrow. I thought I had already done it as part of the TRecordBuffer changes. ___ 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
In our previous episode, Marcos Douglas said:
> > every assignment of TDataset.Bookmark to a variable.
> > As intended too?
>
> This broke the ZEOS 6.6.6-stable and 7.0.0-alpha too (patch to zeos 7
> in attachment for somebody want).
zeoslib_testing (7 trunk) has a "have_tbookmark" define to handle it, and it was
already prepared for these (and the recordbuffer) changes:
{$IF FPC_FULLVERSION>20600} // will be introduced in 2.6.2 (and up to date
2.6.1)
{$DEFINE WITH_TRECORDBUFFER}
{$DEFINE WITH_TBOOKMARK} // Have TBookmark
{$IFEND}
ZEOS 6.6.6 stable was already broken on 2.6.0 anyway due to the "constref"
changes.
___
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
In our previous episode, Martin Schreiber said: > Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks > FPC 2.6.0 compatible code. Is this intended? Yes. It should not break proper code (since that would already treat it as abstract type and call freebookmark). > TBookmark is defined as "Pointer" which has no automatic memory management so > probably TDataset.FreeBookmark() must be called in a try finally block for > every assignment of TDataset.Bookmark to a variable. > As intended too? I first changed it to tbytes (as it is in D2009+), but got some comments that that was very incompatible, and a lot of method signatures would change. So I kept it pchar. (planning to change it to tbytes in trunk eventually) Freebookmark should have been called already, afaik it is at least since D2006, if not easier, and FPC also implements it quite a while. ___ 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
Op 24 april 2012 21:16 heeft Marcos Douglas het volgende geschreven: > On Tue, Apr 24, 2012 at 3:56 PM, Martin Schreiber wrote: >> Hi, >> Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks >> FPC 2.6.0 compatible code. Is this intended? >> TBookmark is defined as "Pointer" which has no automatic memory management so >> probably TDataset.FreeBookmark() must be called in a try finally block for >> every assignment of TDataset.Bookmark to a variable. >> As intended too? > > This broke the ZEOS 6.6.6-stable and 7.0.0-alpha too (patch to zeos 7 > in attachment for somebody want). > If this changes is kept, maybe it should be added to http://wiki.freepascal.org/User_Changes_Trunk and http://wiki.freepascal.org/User_Changes_2.6.2 (to be created). Vincent ___ 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 Tue, Apr 24, 2012 at 3:56 PM, Martin Schreiber wrote: > Hi, > Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks > FPC 2.6.0 compatible code. Is this intended? > TBookmark is defined as "Pointer" which has no automatic memory management so > probably TDataset.FreeBookmark() must be called in a try finally block for > every assignment of TDataset.Bookmark to a variable. > As intended too? This broke the ZEOS 6.6.6-stable and 7.0.0-alpha too (patch to zeos 7 in attachment for somebody want). Marcos Douglas zeos7.0.0-alpha__fpc2.6.1 Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Breaking change in FPC 2.6.1
Hi, Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks FPC 2.6.0 compatible code. Is this intended? TBookmark is defined as "Pointer" which has no automatic memory management so probably TDataset.FreeBookmark() must be called in a try finally block for every assignment of TDataset.Bookmark to a variable. As intended too? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
