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] Trolling about: Breaking change in FPC 2.6.1
Giuliano Colla hat am 2. Mai 2012 um 17:21 geschrieben: > Mattias Gaertner ha scritto: >[...] > > This is starting to become off-topic. >[...] > Breaking compatibility is something very similar to leaving an old lady > in the middle of the road. Now it's off topic. > Whenever people agree with me, I always feel I must be wrong (O. Wilde) Since you have this signature for a long time, I assume you agree with it. I agree with Martin that it is unusual to mark something deprecated in a fixes branch. About trolling: Provoking Graeme has never helped. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Trolling about: Breaking change in FPC 2.6.1
Mattias Gaertner ha scritto: 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. IMHO a more open attitude towards criticism, instead of just labeling it as "trolling" would bring big benefits to everyone. I'm perfectly aware that we're all in debt to voluntary work created by good willing people. Nonetheless, whenever you undertake a task, be it for free or for a fee, you assume responsibilities for what you're doing, because there are people relying on you. If I undertake the task to help old ladies to cross the road, every old lady I help should be reasonably thankful for that. But if I leave an old lady in the middle of the road, to help another one, I don't believe that the first lady will be thankful. She may even, and rightly, use strong words against me. Breaking compatibility is something very similar to leaving an old lady in the middle of the road. If one knows how to help old ladies then he's welcome to do it. But if he happens to leave them in the middle of the road, then he'd better think twice before saying "If you don't like my way, then cross by yourself" to the lady standing in the middle of the highway and shouting between cars and buses! One of the reasons of the average good quality of open source, is that it takes advantage of user feedback. Better remember it, from time to time. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ 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
