Hi,

I was investigating the lazarus bug report http://www.freepascal.org/mantis/view.php?id=9068.

It is caused by the following sequence of events (... eventually calls): Synchronize(@MyMessage)

In the MainThread:
ProcessMessages
CheckSynchronize
...
MyMessage
...
AForm.ShowModal
...
ProcessMessage
CheckSynchronize
...
MyMessage
...
AForm.ShowModal
Error: trying to call showmodal on visible form.

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, I will create a fpc bug report without the LCL example code.

Vincent

It is the latter. Nested CheckSynchronize calls are currently unsupported.

Jonas

----- Original Message -----

Hi,
I saw an interesting bug on C++, and I was wondering how to solve this type of bug in Pascal:

{$MODE OBJFPC}
program namespace_test;
function test : boolean;
begin
  result := true;
end;
type
  TTest = class
     function test : boolean;
  end;
function TTest.test : boolean;
begin
  result := test;
end;
var
  c_test : TTest;
begin
  c_test := TTest.create;
  try
    writeln (c_test.test);
  finally
    c_test.free;
  end;
end.

OK the question is, the TTest.test, what is the test function that it will call, the one inside the class, or the one outside it (I belive that it will call itself once), and how can i call the function outside the class ?

Ido

I think it's ok.

Jonas

----- Original Message -----

----- Original Message -----

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

Op Thu, 21 Jun 2007, schreef

I think it will call itself, until it runs out of stack space (error 202).

No, it won't, "test" here refers to the function result variable.

Daniël

----- Original Message -----

Hi! New list member here...

I saw an interesting bug on C++, and I was wondering how to solve this type of bug in Pascal:

This is easily resolved.

Try this version:
{$MODE OBJFPC}
program namespace_test;
function test : boolean;
begin
 writeln('public function test called.');
 result := true;
end;
type
 TTest = class
    function test : boolean;
 end;
function TTest.test : boolean;
begin
 writeln('method TTest.test called.');
 result := test;
end;
var
 c_test : TTest;
begin
 c_test := TTest.create;
 try
   writeln (c_test.test); // calls the class method
   writeln (namespace_test.test); // calls the public function
 finally
   c_test.free;
 end;
end.

Tom

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

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.

What do you propose?
2.2.0.L
2.2.0.1?

Vincent

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

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,

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

Hi,

Thank you all for the answer. I learned that i can do program_name. for namespace as well cool :)

Ido

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

Releasing 2.2.0 with a major bug because of merging one of those revisions would hurt me just as much.

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

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)

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.

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.

Regardless of whether we release in July, August or September, the next release will probably be close to 2008 anyway.

Jonas

True, but rushing wouldn't do the release any good IMHO.

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.

Exactly. So postponing a fix for a known problem is pretty serious.

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.

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

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.

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.

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

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 Snijders 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.

----- Original Message -----

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

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

The code should be put into a Unit instead.

Even inside UnitOne you can still reference Unit 1 "SELF" by going unit1.test.

A program doesn't have a namespace that one can access, AFAIK (someone care to correct?).

Shoving algorithms into a program rather than placing them in units leads to global C-like or old standard pascal like code where there are no units, just all one big monolithic collosal program melted together with include files or jammed into one big source file.

The other option would be to put the Test function inside a Record and access the test function through the record, treating the record as a namespace. The record would have to be initialized:

TNameSpace = record
  test: function:boolean;
end;
function test: boolean;
begin
  result:= true;
end;
var  // initialized record
  NameSpace: TNameSpace(test: @test);
begin
  NameSpace.test
end.

A program doesn't have a namespace that one can access, AFAIK (someone care to correct?).

Note to self: Actually it does, as mentioned in another email from IK.

i.e.
program1.test

var // initialized record NameSpace: TNameSpace(test: @test);

I meant:

   NameSpace: TNameSpace = (test: @test);

Jonas Maebe 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 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