Re: [fpc-pascal] CheckSynchronize
On 6/22/07, Jonas Maebe [EMAIL PROTECTED] wrote: Resources patch: up to the Windows maintainers. And what do the Windows maintainers say? Considering that lazarus snapshots are now build with a patched fpc 2.1.5 (Vincent, correct me if I am wrong), and it is working fine here, maybe this could be reconsidered? Or, at least the release of 2.2.2 could be made on a shorter time frame then usual, as there are plans to release a Lazarus version with features that depend on that patch before the currently scheduled time for 2.2.2 (someone said it would be summer 2008, is that right?) I would like to find an agreement were all sides are happy. thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 27 Jun 2007, at 23:27, Felipe Monteiro de Carvalho wrote: before the currently scheduled time for 2.2.2 (someone said it would be summer 2008, is that right?) Nobody has said that in this thread afaics, and even if someone did that would be very unlikely to be right. The only estimates I have seen are 2008 and late 2007. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On Fri, 22 Jun 2007 06:58:55 +0200 (CEST) [EMAIL PROTECTED] (Marco van de Voort) wrote: On 21 jun 2007, at 20:52, Marco van de Voort wrote: ... That said, you are clearly in favour of merging those patches, and so is Vincent. ... I'm a simple echo of Vincent. The point is that I see Lazarus more or less as the (only) Tier 1 customer. They earned that right by their feedback over the years. If they can't use the release straight up, I have some doubts about the processes use. It is not that we can't use the release, but we (at least I) rather risk a possible instability rather than have some some known bugs and limitations. And that I want to invest time in it by distributing patched versions of fpc. I think this is similar to why there is debian for people who value stability and ubuntu for people who want faster bug fixes or new features. -- Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 6/22/07, Vincent Snijders [EMAIL PROTECTED] wrote: It is not that we can't use the release, but we (at least I) rather risk a possible instability rather than have some some known bugs and limitations. And that I want to invest time in it by distributing patched versions of fpc. I think this is similar to why there is debian for people who value stability and ubuntu for people who want faster bug fixes or new features. Are the bugs really that severe that people can't wait for 2.2.2? I think that maintaining such separate branch isn't a good idea. If the fixes haven't been commited because they can have unprevisible side effects, releasing Lazarus with them may just as well fix a bug for some users, but add new bugs for lot's of other people, and then make this Lazarus release unusable for lot's of people. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
- Original Message - From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] Date: Friday, June 22, 2007 10:04 am Subject: Re: [fpc-pascal] CheckSynchronize On 6/22/07, Vincent Snijders [EMAIL PROTECTED] wrote: It is not that we can't use the release, but we (at least I) rather risk a possible instability rather than have some some known bugs and limitations. And that I want to invest time in it by distributing patched versions of fpc. I think this is similar to why there is debian for people who value stability and ubuntu for people who want faster bug fixes or new features. Are the bugs really that severe that people can't wait for 2.2.2? Sure they can wait. Lazarus users are really patient people, they are waiting for more than three years now for Lazarus 1.0.0. I think that maintaining such separate branch isn't a good idea. If the fixes haven't been commited They have been committed, but have not been merged to the fixes branch. because they can have unprevisible side effects, releasing Lazarus with them may just as well fix a bug for some users, but add new bugs for lot's of other people, and then make this Lazarus release unusable for lot's of people. Any fix can have unprevisible side effects. Unless we test, we don't know the impact. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 22 jun 2007, at 00:17, Vincent Snijders wrote: I see the following options, start with the IMHO most preferable to the least preferable: A: merge those patches to the fixes branch now. As far as the checksynchronize patch is concerned: since it (almost?) only affects Lazarus and mside, I guess it's most logical to leave it up you to decide whether or not it should be merged. Resources patch: up to the Windows maintainers. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On Friday 22 June 2007 11.19, Jonas Maebe wrote: On 22 jun 2007, at 00:17, Vincent Snijders wrote: I see the following options, start with the IMHO most preferable to the least preferable: A: merge those patches to the fixes branch now. As far as the checksynchronize patch is concerned: since it (almost?) only affects Lazarus and mside, I guess it's most logical to leave it up you to decide whether or not it should be merged. MSEgui has its own synchronizing mechanism, feel free to merge the patch. BTW, what is the status of winlikewidestrings for FPC 2.2 (Mantis 8481)? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
- Original Message - From: Jonas Maebe [EMAIL PROTECTED] Date: Tuesday, June 19, 2007 10:34 am Subject: Re: [fpc-pascal] CheckSynchronize On 18 jun 2007, at 19:48, Vincent Snijders wrote: Is it our fault that we call CheckSynchronize nested (i.e. indirectly from a synchronized method) or is a CheckSynchronize not smart enough not to call the synchronized method (i.e MyMessage) twice, even if Synchronize is called only once for this method. If the latter It is the latter. Nested CheckSynchronize calls are currently unsupported. The following patch from Micha works with pfc 2.1.5: I tried to run the test programs with fpc 2.3.1 too, but I had too much troubles with the heapmanager to be able to test it. Can this patch be applied? Vincent Index: rtl/objpas/classes/classes.inc === --- rtl/objpas/classes/classes.inc (revision 7729) +++ rtl/objpas/classes/classes.inc (working copy) @@ -177,12 +177,12 @@ if DoSynchronizeMethod then begin +DoSynchronizeMethod:=false; try SynchronizeMethod; except SynchronizeException:=Exception(AcquireExceptionObject); end; -DoSynchronizeMethod:=false; RtlEventSetEvent(ExecuteEvent); end; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 14:45, [EMAIL PROTECTED] wrote: The following patch from Micha works with pfc 2.1.5: I tried to run the test programs with fpc 2.3.1 too, but I had too much troubles with the heapmanager to be able to test it. Can this patch be applied? I think it's ok. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
- Original Message - From: Jonas Maebe [EMAIL PROTECTED] Date: Thursday, June 21, 2007 2:54 pm Subject: Re: [fpc-pascal] CheckSynchronize On 21 jun 2007, at 14:45, [EMAIL PROTECTED] wrote: The following patch from Micha works with pfc 2.1.5: I tried to run the test programs with fpc 2.3.1 too, but I had too much troubles with the heapmanager to be able to test it. Can this patch be applied? I think it's ok. Shall I apply to trunk, so that it can be merged to the fixes_2_2 branch later this week? Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 14:54, Jonas Maebe wrote: On 21 jun 2007, at 14:45, [EMAIL PROTECTED] wrote: The following patch from Micha works with pfc 2.1.5: I tried to run the test programs with fpc 2.3.1 too, but I had too much troubles with the heapmanager to be able to test it. Can this patch be applied? I think it's ok. But I'd prefer not to apply it in 2.1.5 (and rather wait for 2.2.1), because it is hard to see/know all side effects from such a change. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
- Original Message - From: Jonas Maebe [EMAIL PROTECTED] Date: Thursday, June 21, 2007 2:57 pm Subject: Re: [fpc-pascal] CheckSynchronize On 21 jun 2007, at 14:54, Jonas Maebe wrote: On 21 jun 2007, at 14:45, [EMAIL PROTECTED] wrote: The following patch from Micha works with pfc 2.1.5: I tried to run the test programs with fpc 2.3.1 too, but I had too much troubles with the heapmanager to be able to test it. Can this patch be applied? I think it's ok. But I'd prefer not to apply it in 2.1.5 (and rather wait for 2.2.1), because it is hard to see/know all side effects from such a change. I committed it in trunk in r7756. I created a wiki page with missing changes in the fixes branch. I am considering to add them the snapshots built for Lazarus. http://wiki.lazarus.freepascal.org/Useful_changes_not_in_the_fixes_branch Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 16:52, [EMAIL PROTECTED] wrote: I committed it in trunk in r7756. I created a wiki page with missing changes in the fixes branch. I am considering to add them the snapshots built for Lazarus. http://wiki.lazarus.freepascal.org/ Useful_changes_not_in_the_fixes_branch Please do not call such a modified FPC release 2.2.0, that will lead to confusion and we will have to start asking which 2.2.0 release people have installed. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 16:52, [EMAIL PROTECTED] wrote: I committed it in trunk in r7756. I created a wiki page with missing changes in the fixes branch. I am considering to add them the snapshots built for Lazarus. http://wiki.lazarus.freepascal.org/ Useful_changes_not_in_the_fixes_branch Please do not call such a modified FPC release 2.2.0, that will lead to confusion and we will have to start asking which 2.2.0 release people have installed. You can also wait after the release and then use the 2.2.1 snapshot. After the release tag/branch is created the listed revisions can be merged to fixes_2_2 which is then know as 2.2.1 in svn. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On Thu, 21 Jun 2007 17:08:05 +0200 Jonas Maebe [EMAIL PROTECTED] wrote: On 21 jun 2007, at 16:52, [EMAIL PROTECTED] wrote: I committed it in trunk in r7756. I created a wiki page with missing changes in the fixes branch. I am considering to add them the snapshots built for Lazarus. http://wiki.lazarus.freepascal.org/ Useful_changes_not_in_the_fixes_branch Please do not call such a modified FPC release 2.2.0, that will lead to confusion and we will have to start asking which 2.2.0 release people have installed. What do you propose? 2.2.0.L 2.2.0.1? Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On Thu, 21 Jun 2007 18:27:48 +0200 (CEST) Peter Vreman [EMAIL PROTECTED] wrote: On 21 jun 2007, at 16:52, [EMAIL PROTECTED] wrote: I committed it in trunk in r7756. I created a wiki page with missing changes in the fixes branch. I am considering to add them the snapshots built for Lazarus. http://wiki.lazarus.freepascal.org/ Useful_changes_not_in_the_fixes_branch Please do not call such a modified FPC release 2.2.0, that will lead to confusion and we will have to start asking which 2.2.0 release people have installed. You can also wait after the release and then use the 2.2.1 snapshot. After the release tag/branch is created the listed revisions can be merged to fixes_2_2 which is then know as 2.2.1 in svn. Waiting until after the release has the disadvantage that these things cannot be tested, unless you use fpc 2.3.1, which to unstable at the moment. And I do actually want to be as close as possible to the release code, but IMHO opnion the merge policy of the fpc team is too strict. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
I think it's a bad idea to release Lazarus with a patched FPC 2.2 If FPC 2.2 isn't suitable for a Lazarus release, IMHO we should wait for 2.2.2 or similar. thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 18:39, Vincent Snijders wrote: And I do actually want to be as close as possible to the release code, but IMHO opnion the merge policy of the fpc team is too strict. Afaics none of the two issues listed on that wiki page are regressions. I therefore don't think it is unreasonable to not merge changes of which no one knows the overall effects 1 month before the final release, with not even a beta release in between. We have done such things before (like switching the compiler to executeprocess shortly before a release because dos.exec had 255 char limitations, and then after the release it turned out that in some not that uncommon situations executeprocess didn't work properly) and we learnt from those mistakes, which is the whole reason why we now have a release/merge procedure. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On Thu, 21 Jun 2007 18:49:39 +0200 Jonas Maebe [EMAIL PROTECTED] wrote: On 21 jun 2007, at 18:39, Vincent Snijders wrote: And I do actually want to be as close as possible to the release code, but IMHO opnion the merge policy of the fpc team is too strict. Afaics none of the two issues listed on that wiki page are regressions. I therefore don't think it is unreasonable to not merge changes of which no one knows the overall effects 1 month before the final release, with not even a beta release in between. We have done such things before (like switching the compiler to executeprocess shortly before a release because dos.exec had 255 char limitations, and then after the release it turned out that in some not that uncommon situations executeprocess didn't work properly) and we learnt from those mistakes, which is the whole reason why we now have a release/merge procedure. I understand that. And it hurts. We have a fix now for a threading issue, and people cannot use it. What do you suggest for the next Lazarus release? Because of stabiliy reasons, we don't want to use snapshot or the fixes branch for releases. Will you release 2.2.2 with these (for the moment two merged revisions, one or two weeks after the 2.2.0. Then we can wait for 2.2.2. Otherwise it is better to have a patched 2.2.0, with a small number of controlled patches, rather than a 2.2.1 with tens of patches already waiting in trunk to be merged. Then I can hardly guarantee stability. The fact that these bugs are in fpc for years already is (for me) not a convincing reason to say, that we should wait until sometime in 2008 for the fix in a Lazarus release. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 19:41, Vincent Snijders wrote: We have done such things before (like switching the compiler to executeprocess shortly before a release because dos.exec had 255 char limitations, and then after the release it turned out that in some not that uncommon situations executeprocess didn't work properly) and we learnt from those mistakes, which is the whole reason why we now have a release/merge procedure. I understand that. And it hurts. Releasing 2.2.0 with a major bug because of merging one of those revisions would hurt me just as much. We have a fix now for a threading issue, and people cannot use it. What do you suggest for the next Lazarus release? Because of stabiliy reasons, we don't want to use snapshot or the fixes branch for releases. Will you release 2.2.2 with these (for the moment two merged revisions, one or two weeks after the 2.2.0. Then we can wait for 2.2.2. Otherwise it is better to have a patched 2.2.0, with a small number of controlled patches, rather than a 2.2.1 with tens of patches already waiting in trunk to be merged. Then I can hardly guarantee stability. We can merge those particular fixes first after 2.2.0 is released, then you can use that revision of 2.2.1 (we're not going to merge everything to be merged in one go from trunk into fixes_2_2 anyway, that would make isolating potential issues way too hard). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 18:39, Vincent Snijders wrote: And I do actually want to be as close as possible to the release code, but IMHO opnion the merge policy of the fpc team is too strict. Afaics none of the two issues listed on that wiki page are regressions. I therefore don't think it is unreasonable to not merge changes of which no one knows the overall effects 1 month before the final release, with not even a beta release in between. Currently, I don't see 2.2 being released before september (because of holidays, we are getting awfully close to july). So, - Maybe we should simply acknowledge that fact, and get that release as good as possible. - That also means postponing anything pretty much schedules it for 2008. (3 months between releases would be a record, at least since the 0.99.12c stuff) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 20:30, Marco van de Voort wrote: Currently, I don't see 2.2 being released before september (because of holidays, we are getting awfully close to july). Afaik everyone who is needed for release building is still available in the last week of July. So, - Maybe we should simply acknowledge that fact, and get that release as good as possible. Nobody will dispute that, regardless of when the release is. That's also not what the discussion is about. The question is whether it's better to risk introducing new unknown bugs by merging those particular patches than leaving those known defects in. - That also means postponing anything pretty much schedules it for 2008. (3 months between releases would be a record, at least since the 0.99.12c stuff) Regardless of whether we release in July, August or September, the next release will probably be close to 2008 anyway. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 20:30, Marco van de Voort wrote: Currently, I don't see 2.2 being released before september (because of holidays, we are getting awfully close to july). Afaik everyone who is needed for release building is still available in the last week of July. True, but rushing wouldn't do the release any good IMHO. So, - Maybe we should simply acknowledge that fact, and get that release as good as possible. Nobody will dispute that, regardless of when the release is. That's also not what the discussion is about. The question is whether it's better to risk introducing new unknown bugs by merging those particular patches than leaving those known defects in. As opposed to the risk that heavy users like mside and lazarus start using snapshots/own rolled releases quickly after a release has been made? Because that voids the whole release effort. - That also means postponing anything pretty much schedules it for 2008. (3 months between releases would be a record, at least since the 0.99.12c stuff) Regardless of whether we release in July, August or September, the next release will probably be close to 2008 anyway. Exactly. So postponing a fix for a known problem is pretty serious. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 20:52, Marco van de Voort wrote:
On 21 jun 2007, at 20:30, Marco van de Voort wrote:
Afaik everyone who is needed for release building is still available
in the last week of July.
True, but rushing wouldn't do the release any good IMHO.
I don't think the end of July is rushing it, as that was the original
plan afaik. And if we delay the release, I think it's quite likely
that more such patches which are critical to certain groups of people
will pop up. The whole point of a release is to cut that off at some
point, let things settle down and get it out of the door.
Nobody will dispute that, regardless of when the release is. That's
also not what the discussion is about. The question is whether it's
better to risk introducing new unknown bugs by merging those
particular patches than leaving those known defects in.
As opposed to the risk that heavy users like mside and lazarus
start using
snapshots/own rolled releases quickly after a release has been made?
Both approaches absolutely have arguments in favour of them.
Because that voids the whole release effort.
I disagree. I think that at most, it can void the actual packaging
effort. The release effort is what enables them to have a stable
basis which they can modify with a few known patches to suit their
needs. Merging uncertain patches is what, in my eyes, voids release
efforts (because you can keep trying to stabilise forever if you do
things like that). It's obviously much more preferable if they don't
have to do that at all and if it's a make or break point, my
preferred option would be a second beta release at the end of July
(although in general I would not look forward to making another
installation package, another couple months of waiting, possibly more
critical patches popping up and possibly delaying again after that).
That said, you are clearly in favour of merging those patches, and so
is Vincent. I prefer not to do it, both because of past experiences
(as explained earlier), and because e.g. the resources patch already
had one unforeseen consequence (which was fortunately not that bad:
the version of ld.exe shipped with FPC 2.0.4 apparently cannot not
handle the resulting resources).
For all big endian users, merging the set rewrite could also be
argued, because without it {$packsets} is completely broken on big
endian in 2.1.x (so if you use it in 2.2.0, you have to put {$ifndef
FPC_BIG_ENDIAN} everywhere). There are some serious fixes to the
threading system which aren't merged (mantis 9016 -- we don't clean
up all resources allocated for terminateonfree threads under *nix --
that may even be a regression compared to 2.0.4, although a whole
bunch of other tthread stuff didn't work at all under *nix/2.0.4 and
overall the situation still improved)
I'm not trying to put up any veto here (nor do I *insist* on having
another beta release if they would be merged). I'm just trying to
explain my reasons for disliking the merging of them.
And there probably quite a few more patches which are quite vital to
several groups of people.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On Thu, 21 Jun 2007 21:31:59 +0200
Jonas Maebe [EMAIL PROTECTED] wrote:
Nobody will dispute that, regardless of when the release is. That's
also not what the discussion is about. The question is whether it's
better to risk introducing new unknown bugs by merging those
particular patches than leaving those known defects in.
As opposed to the risk that heavy users like mside and lazarus
start using
snapshots/own rolled releases quickly after a release has been made?
Both approaches absolutely have arguments in favour of them.
Because that voids the whole release effort.
I disagree. I think that at most, it can void the actual packaging
effort. The release effort is what enables them to have a stable
basis which they can modify with a few known patches to suit their
needs. Merging uncertain patches is what, in my eyes, voids release
efforts (because you can keep trying to stabilise forever if you do
things like that). It's obviously much more preferable if they don't
have to do that at all and if it's a make or break point, my
preferred option would be a second beta release at the end of July
(although in general I would not look forward to making another
installation package, another couple months of waiting, possibly more
critical patches popping up and possibly delaying again after that).
I value the release procedure very much and that is why I don't want to base a
Lazarus release on a snapshot. I see the following options, start with the IMHO
most preferable to the least preferable:
A: merge those patches to the fixes branch now.
B: Second choice, merge them right after tagging 2.2.0, and tag that as 2.2.2
or 2.2.0.1, that we can use a tagged version for Lazarus releases.
C: If this is not possible, then I can keep a patch file for fpc 2.2.0
somewhere that I apply before buiding the fpc 2.2.0 version for Lazarus.
D: Tell people that until 2008 these are known issues with Lazarus releases,
but that these issues are fixed in snapshots. E.g. having version info and a
manifest does not work.
That said, you are clearly in favour of merging those patches, and so
is Vincent. I prefer not to do it, both because of past experiences
(as explained earlier), and because e.g. the resources patch already
had one unforeseen consequence (which was fortunately not that bad:
the version of ld.exe shipped with FPC 2.0.4 apparently cannot not
handle the resulting resources).
For the record, it was ld shipped with fpc 2.0.2, so it would not even have
been noticed if I made a proper 2.1.5 installation using the binutils from the
fpcbuild repository.
And I found about this issue, because I merged this patch to 2.1.5 in my local
copy to test it.
For all big endian users, merging the set rewrite could also be
argued, because without it {$packsets} is completely broken on big
endian in 2.1.x (so if you use it in 2.2.0, you have to put {$ifndef
FPC_BIG_ENDIAN} everywhere). There are some serious fixes to the
threading system which aren't merged (mantis 9016 -- we don't clean
up all resources allocated for terminateonfree threads under *nix --
that may even be a regression compared to 2.0.4, although a whole
bunch of other tthread stuff didn't work at all under *nix/2.0.4 and
overall the situation still improved)
I'm not trying to put up any veto here (nor do I *insist* on having
another beta release if they would be merged). I'm just trying to
explain my reasons for disliking the merging of them.
Well explained. I think it is clear you want to run minimal risks with fpc
2.2.0. I don't have the illusion that fpc 2.2.0 will have those fixes, now
let's see how we can have these fixes in a Lazarus release as soon as possible.
And there probably quite a few more patches which are quite vital to
several groups of people.
Let's gather them in the wiki page. To be eligible, they need not be too large
and have to heavy inpact (e.g. merging the internal linker to fpc 2.0.4 would
have been too large and I think the same goes for the set handling rewrite).
I want to test them as soon as possible with the fixes branch. I will merge
those patches them in the lazarus snapshot packages with fpc 2.1.5, currently
win32, win64 and i386-darwin, so testing can start as soon as possible.
Do you want me to mark the version of those fpc executables in any special way?
2.1.5.1? 2.1.5.Lazarus?
Vincent
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 21 jun 2007, at 20:52, Marco van de Voort wrote: ... That said, you are clearly in favour of merging those patches, and so is Vincent. ... I'm a simple echo of Vincent. The point is that I see Lazarus more or less as the (only) Tier 1 customer. They earned that right by their feedback over the years. If they can't use the release straight up, I have some doubts about the processes use. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CheckSynchronize
On 18 jun 2007, at 19:48, Vincent Snijders wrote: Is it our fault that we call CheckSynchronize nested (i.e. indirectly from a synchronized method) or is a CheckSynchronize not smart enough not to call the synchronized method (i.e MyMessage) twice, even if Synchronize is called only once for this method. If the latter It is the latter. Nested CheckSynchronize calls are currently unsupported. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
