Re: [fpc-devel] Important: Call for testing.
Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > On Friday 04 April 2008 13.56:45 Michael Van Canneyt wrote: > > On Fri, 4 Apr 2008, Martin Schreiber wrote: > > > The next problem is childpos handling: > > > http://bugs.freepascal.org/view.php?id=11102 > > > > I've never understood what this is about, so some additional information > > would be welcome... > > > It is used in order change the widget stacking order in an inherited form for > example: > In ancestor form streaming- child- and creation-order is twidget1, twidget2, > twidget3 what means (in MSEgui, I don't know for Lazarus) twidget2 is over > twidget1, twidget3 is over twidget2. > Now you do 'Bring to Front' for twidget1 in a inherited form which changes > the > child order to twidget2, twidget3, twidget1. > The new child order must be written and read back while streaming the > descendent. It is done with ffChildPos filerflag and a following integer. > Repositioning of the inherited children is done by TComponent.SetChildOrder > IIRC. Same for lazarus. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 4 Apr 2008, Martin Schreiber wrote: > On Friday 04 April 2008 13.56:45 Michael Van Canneyt wrote: > > On Fri, 4 Apr 2008, Martin Schreiber wrote: > > > The next problem is childpos handling: > > > http://bugs.freepascal.org/view.php?id=11102 > > > > I've never understood what this is about, so some additional information > > would be welcome... > > > It is used in order change the widget stacking order in an inherited form for > example: > In ancestor form streaming- child- and creation-order is twidget1, twidget2, > twidget3 what means (in MSEgui, I don't know for Lazarus) twidget2 is over > twidget1, twidget3 is over twidget2. > Now you do 'Bring to Front' for twidget1 in a inherited form which changes > the > child order to twidget2, twidget3, twidget1. Bweeh :( That means I must compare original and new child order. OK, thanks. I'll try to fix this ASAP. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Friday 04 April 2008 13.56:45 Michael Van Canneyt wrote: > On Fri, 4 Apr 2008, Martin Schreiber wrote: > > The next problem is childpos handling: > > http://bugs.freepascal.org/view.php?id=11102 > > I've never understood what this is about, so some additional information > would be welcome... > It is used in order change the widget stacking order in an inherited form for example: In ancestor form streaming- child- and creation-order is twidget1, twidget2, twidget3 what means (in MSEgui, I don't know for Lazarus) twidget2 is over twidget1, twidget3 is over twidget2. Now you do 'Bring to Front' for twidget1 in a inherited form which changes the child order to twidget2, twidget3, twidget1. The new child order must be written and read back while streaming the descendent. It is done with ffChildPos filerflag and a following integer. Repositioning of the inherited children is done by TComponent.SetChildOrder IIRC. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 4 Apr 2008, Martin Schreiber wrote: > On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: > > > > While extensive testing has been done (using the FPCunit testing > > framework), and the working of Lazarus with this new code was verified, it > > is possible that bugs remain. We would therefor very much appreciate that > > if you have code that uses some of the routines below, that you test your > > code with the latest FPC from subversion (revision 10572 or above) and > > report any bugs that you may encounter. If you do, please submit a > > bugreport in mantis: > > > > http://bugs.freepascal.org/ > > > The next problem is childpos handling: > http://bugs.freepascal.org/view.php?id=11102 I've never understood what this is about, so some additional information would be welcome... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: > > While extensive testing has been done (using the FPCunit testing > framework), and the working of Lazarus with this new code was verified, it > is possible that bugs remain. We would therefor very much appreciate that > if you have code that uses some of the routines below, that you test your > code with the latest FPC from subversion (revision 10572 or above) and > report any bugs that you may encounter. If you do, please submit a > bugreport in mantis: > > http://bugs.freepascal.org/ > The next problem is childpos handling: http://bugs.freepascal.org/view.php?id=11102 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 4 Apr 2008, Martin Schreiber wrote: > On Thursday 03 April 2008 10.58:26 Michael Van Canneyt wrote: > > On Thu, 3 Apr 2008, Martin Schreiber wrote: > > > You used my copyrighted code, the sources look exactly the same. ;-) > > > > A strong case against all these copyright suits... :-) > > > And we made the same error, see attachment. It is a little bit more > complicated. > I hope I got the coding style right. ;-) Not quite, I adapted it, no big deal. It's like I said when I fixed the original issue: for inherited forms with inline forms, the original patch was not tested. Anyway, I applied your patch with a slight modification, thank you very much ! Revision 10601. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.58:26 Michael Van Canneyt wrote: > On Thu, 3 Apr 2008, Martin Schreiber wrote: > > You used my copyrighted code, the sources look exactly the same. ;-) > > A strong case against all these copyright suits... :-) > And we made the same error, see attachment. It is a little bit more complicated. I hope I got the coding style right. ;-) Martin --- home/mse/packs/standard/svn/fp/trunk/rtl/objpas/classes/.svn/text-base/writer.inc.svn-base 2008-04-03 11:06:35.0 +0200 +++ tmp/svndiff.tmp 2008-04-04 11:51:29.0 +0200 @@ -595,10 +595,15 @@ begin Dummy:=0; Flags := []; - If Assigned(FAncestor) then -Flags:=[ffInherited]; - if csInline in Instance.ComponentState then -Flags:=Flags+[ffInline]; + If (FAncestor <> nil) and + //has ancestor + (not (csInline in Instance.ComponentState) or + //no inline component + (csAncestor in Instance.Componentstate) and (FAncestors <> nil)) then + //the inline component is inherited +Flags:=[ffInherited] + else If csInline in Instance.ComponentState then +Flags:=[ffInline]; FDriver.BeginComponent(Instance,Flags, Dummy); WriteProperties(Instance); WriteListEnd; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thu, 3 Apr 2008, Martin Schreiber wrote: > On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: > > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > > On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: > > > > Martin Schreiber schreef: > > > > > Inline is used for subforms, components in a form which inherit from > > > > > another form (TFrame in Delphi), in MSEgui every form can be used as > > > > > inline component. The ffInline filer flag must be written and the > > > > > ancestor must be looked up on writing and reading like inherited > > > > > components. > > > > > > > > > >> Alternatively you can supply a patch ;-) > > > > > > > > > > I don't think I am "clean" enough... > > > > > > > > Alternatively, you can write the test case ;-) > > > > > > I'll do. The first is > > > http://bugs.freepascal.org/view.php?id=11069 > > > > Fixed; > > There is no test to see what happens when you stream a descendent of a form > > with an inline form; if you have such a case, please test it. > > > You used my copyrighted code, the sources look exactly the same. ;-) A strong case against all these copyright suits... :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: > > > Martin Schreiber schreef: > > > > Inline is used for subforms, components in a form which inherit from > > > > another form (TFrame in Delphi), in MSEgui every form can be used as > > > > inline component. The ffInline filer flag must be written and the > > > > ancestor must be looked up on writing and reading like inherited > > > > components. > > > > > > > >> Alternatively you can supply a patch ;-) > > > > > > > > I don't think I am "clean" enough... > > > > > > Alternatively, you can write the test case ;-) > > > > I'll do. The first is > > http://bugs.freepascal.org/view.php?id=11069 > > Fixed; > There is no test to see what happens when you stream a descendent of a form > with an inline form; if you have such a case, please test it. > You used my copyrighted code, the sources look exactly the same. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: > > > Martin Schreiber schreef: > > > > Inline is used for subforms, components in a form which inherit from > > > > another form (TFrame in Delphi), in MSEgui every form can be used as > > > > inline component. The ffInline filer flag must be written and the > > > > ancestor must be looked up on writing and reading like inherited > > > > components. > > > > > > > >> Alternatively you can supply a patch ;-) > > > > > > > > I don't think I am "clean" enough... > > > > > > Alternatively, you can write the test case ;-) > > > > I'll do. The first is > > http://bugs.freepascal.org/view.php?id=11069 > > Fixed; > There is no test to see what happens when you stream a descendent of a form > with an inline form; if you have such a case, please test it. > Argh, I just made it too! OK, I'll update from trunk and test it. There are interesting cases with inlined inherited components and the like. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: > On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: > > Martin Schreiber schreef: > > > Inline is used for subforms, components in a form which inherit from > > > another form (TFrame in Delphi), in MSEgui every form can be used as > > > inline component. The ffInline filer flag must be written and the > > > ancestor must be looked up on writing and reading like inherited > > > components. > > > > > >> Alternatively you can supply a patch ;-) > > > > > > I don't think I am "clean" enough... > > > > Alternatively, you can write the test case ;-) > > > I'll do. The first is > http://bugs.freepascal.org/view.php?id=11069 Fixed; There is no test to see what happens when you stream a descendent of a form with an inline form; if you have such a case, please test it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
C Western schreef: Giulio Bernardi wrote: Maybe this patch (for lazarus) solves the issue? (warning: lazarus compiles and runs but I didn't test it). Giulio It seems to work reasonably OK for me. It doesn't handle the copyright symbol quite right that was causing me problems, but I don't think the previous version did either. It does stop the error message though. Giulio, thanks for the patch. Colin, thanks for testing. Applied in r14698. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Giulio Bernardi wrote: Maybe this patch (for lazarus) solves the issue? (warning: lazarus compiles and runs but I didn't test it). Giulio It seems to work reasonably OK for me. It doesn't handle the copyright symbol quite right that was causing me problems, but I don't think the previous version did either. It does stop the error message though. Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Mon, 31 Mar 2008, Martin Schreiber wrote: > On Monday 31 March 2008 16.13:48 Michael Van Canneyt wrote: > > On Mon, 31 Mar 2008, Martin Schreiber wrote: > > > > I am not convinced. By controlling the order of the properties and the > > > load order of the forms it is possible to control the resolving order. > > > Does FPC loose on quality if you use the same order as Delphi? It is > > > possible that we don't know all future applications of resolving order at > > > the moment, why should we give away compatibility if not necessary? > > > > Simply said: if I must reverse order, then I have to redo the whole > > cleanroom stuff and it will be exactly as in Delphi. This is not an > > option. > > > I probably don't understand. What is the problem to reverse the iterating > order over a list? It's a single linked list. Not a TList. Reversing it would be a waste of time. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Monday 31 March 2008 16.13:48 Michael Van Canneyt wrote: > On Mon, 31 Mar 2008, Martin Schreiber wrote: > > I am not convinced. By controlling the order of the properties and the > > load order of the forms it is possible to control the resolving order. > > Does FPC loose on quality if you use the same order as Delphi? It is > > possible that we don't know all future applications of resolving order at > > the moment, why should we give away compatibility if not necessary? > > Simply said: if I must reverse order, then I have to redo the whole > cleanroom stuff and it will be exactly as in Delphi. This is not an > option. > I probably don't understand. What is the problem to reverse the iterating order over a list? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Op maandag 31-03-2008 om 16:13 uur [tijdzone +0200], schreef Michael Van Canneyt: > > Simply said: if I must reverse order, then I have to redo the whole > cleanroom stuff and it will be exactly as in Delphi. This is not an > option. Is this about mine (cleanroom) code? Maybe I can change it? If someone can explain to me what chould be changed and supply some tests... I haven't looked into the differences. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Mon, 31 Mar 2008, Martin Schreiber wrote: > On Sunday 30 March 2008 20.42:13 Michael Van Canneyt wrote: > > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > > > I'd like to second Colins wish. Please use the same resolving order as > > > Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an > > > unnecessary complication and error source. > > > > It's not a complication. Resolving order is and must be irrelevant. Until > > 'Loaded' is called, you're not supposed to make any assumptions about what > > property is and what property is not set, and hence also not about the > > order. > > > I am not convinced. By controlling the order of the properties and the load > order of the forms it is possible to control the resolving order. Does FPC > loose on quality if you use the same order as Delphi? It is possible that we > don't know all future applications of resolving order at the moment, why > should we give away compatibility if not necessary? Simply said: if I must reverse order, then I have to redo the whole cleanroom stuff and it will be exactly as in Delphi. This is not an option. And since resolving order is not something you are supposed to rely on, you're on dangerous ground. As soon as Delphi changes it, your code will break anyway. As I said: the only moment that is guaranteed is the 'loaded' call, stick to that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Monday 31 March 2008 15.00:02 Michael Van Canneyt wrote: > > It is like streaming of an inherited form. Lookup the ancestor and write > > the property differences. > > Nono, when streaming an inherited form, the IDE provides the ancestor > instance when the streaming starts, because it calls writedescendent. > > When you have a frame inside a form IDE, the IDE cannot provide the > ancestor of the frame: the streaming code must look for the original > instance of the frame by itself. My guess is that this is done by > setting the OnFindAncestor callback ? > Correct. Sorry that I didn't get your question right. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Important: Call for testing.
> From: [EMAIL PROTECTED] > To: fpc-devel@lists.freepascal.org > Subject: RE: [fpc-devel] Important: Call for testing. > Date: Sun, 30 Mar 2008 22:21:52 + > > >> I have noticed another incompatibility with the previous version - the >> TParser object in parser.inc can now return toWString as one of the >> possibilities; the previous version returned toString regardless, but >> offered a wide and normal version of the string. This change breaks >> lazarus on wide strings. Which should be changed? > > toWString was missing, now it's more delphi compatible and you don't have > to check every character of the widestring (returned with > TParser.TokenWideString) to determine if > the string is really a wide or an ansi string. > Note that now you still have a normal and wide version of the string > (TokenString / TokenWideString) but Token property can be toWString too. > So the only needed change should be in checking for toWString too when > checking for toString. Ok, toWString is declared in trunk only, so you should > use an ifdef for now. However it will be merged to fixes_2_2 too, so the > ifdef will be only needed till 2.2.2 is released. > Maybe this patch (for lazarus) solves the issue? (warning: lazarus compiles and runs but I didn't test it). Giulio _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE parser_wstring_patch.diff.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 20.42:13 Michael Van Canneyt wrote: > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > I'd like to second Colins wish. Please use the same resolving order as > > Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an > > unnecessary complication and error source. > > It's not a complication. Resolving order is and must be irrelevant. Until > 'Loaded' is called, you're not supposed to make any assumptions about what > property is and what property is not set, and hence also not about the > order. > I am not convinced. By controlling the order of the properties and the load order of the forms it is possible to control the resolving order. Does FPC loose on quality if you use the same order as Delphi? It is possible that we don't know all future applications of resolving order at the moment, why should we give away compatibility if not necessary? In my developments I try to constrict the possibilities as little as possible. Often the users of our code do things we never thought. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Mon, 31 Mar 2008, Martin Schreiber wrote: > On Sunday 30 March 2008 20.48:23 Michael Van Canneyt wrote: > > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > > Inline is used for subforms, components in a form which inherit from > > > another form (TFrame in Delphi), in MSEgui every form can be used as > > > inline component. The ffInline filer flag must be written and the > > > ancestor must be looked up on writing and reading like inherited > > > components. > > > > OK, So: > > > > Form1 = TForm1 > > Frame1 = TMyFrame [inline comes here somewhere] > > end > > end > > > > When Frame1 is streamed, where do I find TMyFrame ? It's Ancestor is not > > being streamed ? > > > It is like streaming of an inherited form. Lookup the ancestor and write the > property differences. Nono, when streaming an inherited form, the IDE provides the ancestor instance when the streaming starts, because it calls writedescendent. When you have a frame inside a form IDE, the IDE cannot provide the ancestor of the frame: the streaming code must look for the original instance of the frame by itself. My guess is that this is done by setting the OnFindAncestor callback ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 20.48:23 Michael Van Canneyt wrote: > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > Inline is used for subforms, components in a form which inherit from > > another form (TFrame in Delphi), in MSEgui every form can be used as > > inline component. The ffInline filer flag must be written and the > > ancestor must be looked up on writing and reading like inherited > > components. > > OK, So: > > Form1 = TForm1 > Frame1 = TMyFrame [inline comes here somewhere] > end > end > > When Frame1 is streamed, where do I find TMyFrame ? It's Ancestor is not > being streamed ? > It is like streaming of an inherited form. Lookup the ancestor and write the property differences. On reading TMyFrame is found by TReader.FindComponentClass (normally by GetFieldClass) as with non inlined child components. TMyFrame.Create loads the TMyFrame instance with the initial form resource data. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Important: Call for testing.
> I have noticed another incompatibility with the previous version - the > TParser object in parser.inc can now return toWString as one of the > possibilities; the previous version returned toString regardless, but > offered a wide and normal version of the string. This change breaks > lazarus on wide strings. Which should be changed? toWString was missing, now it's more delphi compatible and you don't have to check every character of the widestring (returned with TParser.TokenWideString) to determine if the string is really a wide or an ansi string. Note that now you still have a normal and wide version of the string (TokenString / TokenWideString) but Token property can be toWString too. So the only needed change should be in checking for toWString too when checking for toString. Ok, toWString is declared in trunk only, so you should use an ifdef for now. However it will be merged to fixes_2_2 too, so the ifdef will be only needed till 2.2.2 is released. Giulio _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
I have noticed another incompatibility with the previous version - the TParser object in parser.inc can now return toWString as one of the possibilities; the previous version returned toString regardless, but offered a wide and normal version of the string. This change breaks lazarus on wide strings. Which should be changed? Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: > On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote: > > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > > On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: > > > Looks good, thanks. There is a problem with inline components: > > > http://bugs.freepascal.org/view.php?id=11069 > > > Please delete 11068, it was posted private by accident. > > > > OK, I knew how to handle visual form inheritance so I could fix > > 11067, but inline I have no idea what it is. Can you explain me > > what needs to be done, and in what situations it is used ? > > > Inline is used for subforms, components in a form which inherit from another > form (TFrame in Delphi), in MSEgui every form can be used as inline > component. The ffInline filer flag must be written and the ancestor must be > looked up on writing and reading like inherited components. OK, So: Form1 = TForm1 Frame1 = TMyFrame [inline comes here somewhere] end end When Frame1 is streamed, where do I find TMyFrame ? It's Ancestor is not being streamed ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: > On Sunday 30 March 2008 18.08:24 Michael Van Canneyt wrote: > > On Sun, 30 Mar 2008, C Western wrote: > > > > Things now seem to work for me after a little adjustment. I don't know if > > > it is intentional, but the order in which references are satisfied seems > > > to have been reversed in the current version, which revealed a minor > > > error in my code. I suspect I won't be the only one, so it might be kind > > > to reverse the list to avoid similar problems. > > > > Nono, it's good that you fixed your bug. > > > > You should never rely on the loading order. For forms, for instance, it is > > dependent on the creation in the IDE. A simple cut and paste could change > > the order. Relying on this would be bad practice. > > > I'd like to second Colins wish. Please use the same resolving order as > Delphi. > MSEide+MSEgui compiles with Delphi7 so the reversed order is an unnecessary > complication and error source. It's not a complication. Resolving order is and must be irrelevant. Until 'Loaded' is called, you're not supposed to make any assumptions about what property is and what property is not set, and hence also not about the order. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: > Martin Schreiber schreef: > > Inline is used for subforms, components in a form which inherit from > > another form (TFrame in Delphi), in MSEgui every form can be used as > > inline component. The ffInline filer flag must be written and the > > ancestor must be looked up on writing and reading like inherited > > components. > > > >> Alternatively you can supply a patch ;-) > > > > I don't think I am "clean" enough... > > Alternatively, you can write the test case ;-) > I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 18.08:24 Michael Van Canneyt wrote: > On Sun, 30 Mar 2008, C Western wrote: > > Things now seem to work for me after a little adjustment. I don't know if > > it is intentional, but the order in which references are satisfied seems > > to have been reversed in the current version, which revealed a minor > > error in my code. I suspect I won't be the only one, so it might be kind > > to reverse the list to avoid similar problems. > > Nono, it's good that you fixed your bug. > > You should never rely on the loading order. For forms, for instance, it is > dependent on the creation in the IDE. A simple cut and paste could change > the order. Relying on this would be bad practice. > I'd like to second Colins wish. Please use the same resolving order as Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an unnecessary complication and error source. > > The other thing that struck me is that unsatisfied references do not > > throw an error - shouldn't they? (It would have made fixing the error a > > little easier) How about the following patch: > > Delphi doesn't throw an error either, and it should definitely not do so at > the end of local reference resolving; At most this could be done after all > loading is done, and you don't know when that is: forms can be created at > any time... > Agreed. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am "clean" enough... Alternatively, you can write the test case ;-) Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote: > On Sun, 30 Mar 2008, Martin Schreiber wrote: > > On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: > > Looks good, thanks. There is a problem with inline components: > > http://bugs.freepascal.org/view.php?id=11069 > > Please delete 11068, it was posted private by accident. > > OK, I knew how to handle visual form inheritance so I could fix > 11067, but inline I have no idea what it is. Can you explain me > what needs to be done, and in what situations it is used ? > Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. > Alternatively you can supply a patch ;-) > I don't think I am "clean" enough... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Michael Van Canneyt wrote: Nono, it's good that you fixed your bug. You should never rely on the loading order. For forms, for instance, it is dependent on the creation in the IDE. A simple cut and paste could change the order. Relying on this would be bad practice. Absolutely The other thing that struck me is that unsatisfied references do not throw an error - shouldn't they? (It would have made fixing the error a little easier) How about the following patch: Delphi doesn't throw an error either, and it should definitely not do so at the end of local reference resolving; At most this could be done after all loading is done, and you don't know when that is: forms can be created at any time... It still seems strange not to throw an error. The point I suggested is the first time that it is definitely known that the local reference will never be resolved, as at that point the reference is simply thrown away if not resolved. (Or am I missing something?) Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, C Western wrote: > Michael Van Canneyt wrote: > > Indeed. It completely short-circuits the idea of trying to locally resolve > > references before trying globally :) > > > > Anyway, your hint gave me the idea where to look. > > I fixed the issue properly. The error was in another routine altogether. > > > > Hopefully now 11060 is really fixed. > > > Things now seem to work for me after a little adjustment. I don't know if it > is intentional, but the order in which references are satisfied seems to have > been reversed in the current version, which revealed a minor error in my code. > I suspect I won't be the only one, so it might be kind to reverse the list to > avoid similar problems. Nono, it's good that you fixed your bug. You should never rely on the loading order. For forms, for instance, it is dependent on the creation in the IDE. A simple cut and paste could change the order. Relying on this would be bad practice. > > The other thing that struck me is that unsatisfied references do not throw an > error - shouldn't they? (It would have made fixing the error a little easier) > How about the following patch: Delphi doesn't throw an error either, and it should definitely not do so at the end of local reference resolving; At most this could be done after all loading is done, and you don't know when that is: forms can be created at any time... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: > On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: > > On Sat, 29 Mar 2008, Martin Schreiber wrote: > > > On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: > > > > > > > > Seems like the most obvious bugs are fixed. > > > > Now I wait for the subtle ones to appear ;-) > > > > > > Here it is the first one: > > > http://bugs.freepascal.org/view.php?id=11067 > > > (Wrong ancestor value in defineproperties). > > > > Seems fixed now. > > I hope I have done it correct (your test program runs fine) > > and didn't break anything else... :( > > > Looks good, thanks. There is a problem with inline components: > http://bugs.freepascal.org/view.php?id=11069 > Please delete 11068, it was posted private by accident. OK, I knew how to handle visual form inheritance so I could fix 11067, but inline I have no idea what it is. Can you explain me what needs to be done, and in what situations it is used ? Alternatively you can supply a patch ;-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Jonas Maebe wrote: > > On 30 Mar 2008, at 01:32, Michael Van Canneyt wrote: > >On Sat, 29 Mar 2008, Martin Schreiber wrote: > > > > >On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: > > > > > > > >Jesus just told me that it is fixed in r10587. > > > > > > > >Great, I set the bug to resolved. > > > > > > > >Seems like the most obvious bugs are fixed. > > > >Now I wait for the subtle ones to appear ;-) > > > > > > >Here it is the first one: > > >http://bugs.freepascal.org/view.php?id=11067 > > >(Wrong ancestor value in defineproperties). > > > >Seems fixed now. > > Can you also commit tests for these fixed bugs (11059, 11060, 11067) to svn? I converted them to fpcunit tests while implementing, but since I don't know yet how to handle those in the testsuite, I didn't commit them yet. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Michael Van Canneyt wrote: Indeed. It completely short-circuits the idea of trying to locally resolve references before trying globally :) Anyway, your hint gave me the idea where to look. I fixed the issue properly. The error was in another routine altogether. Hopefully now 11060 is really fixed. Things now seem to work for me after a little adjustment. I don't know if it is intentional, but the order in which references are satisfied seems to have been reversed in the current version, which revealed a minor error in my code. I suspect I won't be the only one, so it might be kind to reverse the list to avoid similar problems. The other thing that struck me is that unsatisfied references do not throw an error - shouldn't they? (It would have made fixing the error a little easier) How about the following patch: Colin diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc --- trunk/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 21:15:01.0 + +++ trunk.w/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-30 12:11:52.0 +0100 @@ -658,7 +658,9 @@ begin G:=AddToResolveList(R.FInstance); G.Addreference(R.FRoot,R.FPropInfo,Copy(R.FRelative,1,P-1),Copy(R.FRelative,P+1,Length(R.FRelative)-P)); - end; + end +else + raise EReadError.CreateFmt(SResNotFound, [Ref]); end; L.RemoveItem(R,True); R:=RN; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On 30 Mar 2008, at 01:32, Michael Van Canneyt wrote: On Sat, 29 Mar 2008, Martin Schreiber wrote: On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). Seems fixed now. Can you also commit tests for these fixed bugs (11059, 11060, 11067) to svn? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: > On Sat, 29 Mar 2008, Martin Schreiber wrote: > > On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: > > > > > > Seems like the most obvious bugs are fixed. > > > Now I wait for the subtle ones to appear ;-) > > > > Here it is the first one: > > http://bugs.freepascal.org/view.php?id=11067 > > (Wrong ancestor value in defineproperties). > > Seems fixed now. > I hope I have done it correct (your test program runs fine) > and didn't break anything else... :( > Looks good, thanks. There is a problem with inline components: http://bugs.freepascal.org/view.php?id=11069 Please delete 11068, it was posted private by accident. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sat, 29 Mar 2008, Martin Schreiber wrote: > On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: > > > > Jesus just told me that it is fixed in r10587. > > > > Great, I set the bug to resolved. > > > > Seems like the most obvious bugs are fixed. > > Now I wait for the subtle ones to appear ;-) > > > Here it is the first one: > http://bugs.freepascal.org/view.php?id=11067 > (Wrong ancestor value in defineproperties). Seems fixed now. I hope I have done it correct (your test program runs fine) and didn't break anything else... :( Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: > > Jesus just told me that it is fixed in r10587. > > Great, I set the bug to resolved. > > Seems like the most obvious bugs are fixed. > Now I wait for the subtle ones to appear ;-) > Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). 11060 seems to be fixed for MSEide too, thanks a lot. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sat, 29 Mar 2008, Vincent Snijders wrote: > Jesus Reyes A. schreef: > > > > - Original Message - From: "C Western" <[EMAIL PROTECTED]> > > To: "FPC developers' list" > > Sent: Saturday, March 29, 2008 11:04 AM > > Subject: Re: [fpc-devel] Important: Call for testing. > > > > > > > There also seems to be a problem with fixing up references to other > > > components while reading - TLabel.FocusControl seems to be one of the > > > things that is tripping this up. Local unresolved references are being > > > silently discarded, but I think should be added to the global list. The > > > attached patch fixes it for my application, but might not be the best > > > general fix. > > > > > > Colin > > > > > This patch fixes issue 11060, however, while trying to open project's > > compiler options dialog I get this: > > > > > > > > Other dialogs seems to be fine though. > > > > Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Jesus Reyes A. schreef: - Original Message - From: "C Western" <[EMAIL PROTECTED]> To: "FPC developers' list" Sent: Saturday, March 29, 2008 11:04 AM Subject: Re: [fpc-devel] Important: Call for testing. There also seems to be a problem with fixing up references to other components while reading - TLabel.FocusControl seems to be one of the things that is tripping this up. Local unresolved references are being silently discarded, but I think should be added to the global list. The attached patch fixes it for my application, but might not be the best general fix. Colin This patch fixes issue 11060, however, while trying to open project's compiler options dialog I get this: Other dialogs seems to be fine though. Jesus just told me that it is fixed in r10587. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sat, 29 Mar 2008, C Western wrote: > There also seems to be a problem with fixing up references to other components > while reading - TLabel.FocusControl seems to be one of the things that is > tripping this up. Local unresolved references are being silently discarded, > but I think should be added to the global list. The attached patch fixes it > for my application, but might not be the best general fix. Indeed. It completely short-circuits the idea of trying to locally resolve references before trying globally :) Anyway, your hint gave me the idea where to look. I fixed the issue properly. The error was in another routine altogether. Hopefully now 11060 is really fixed. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
- Original Message - From: "C Western" <[EMAIL PROTECTED]> To: "FPC developers' list" Sent: Saturday, March 29, 2008 11:04 AM Subject: Re: [fpc-devel] Important: Call for testing. There also seems to be a problem with fixing up references to other components while reading - TLabel.FocusControl seems to be one of the things that is tripping this up. Local unresolved references are being silently discarded, but I think should be added to the global list. The attached patch fixes it for my application, but might not be the best general fix. Colin This patch fixes issue 11060, however, while trying to open project's compiler options dialog I get this: TApplication.HandleException Cannot focus a disabled or invisible window Stack trace: $0041910F TCUSTOMFORM__SETACTIVECONTROL, line 1264 of ../include/customform.i nc $004843DB SETORDPROP, line 938 of E:/fpcsvn/fpcmirror/rtl/objpas/typinfo.pp $00484754 SETOBJECTPROP, line 1096 of E:/fpcsvn/fpcmirror/rtl/objpas/typinfo ..pp $004657BE TUNRESOLVEDREFERENCE__RESOLVE, line 233 of E:/fpcsvn/fpcmirror/rtl /objpas/classes/resref.inc $0046596A TUNRESOLVEDINSTANCE__RESOLVEREFERENCES, line 287 of E:/fpcsvn/fpcm irror/rtl/objpas/classes/resref.inc $00465DD4 TRESOLVEREFERENCEVISITOR__VISIT, line 453 of E:/fpcsvn/fpcmirror/r tl/objpas/classes/resref.inc $00465416 TLINKEDLIST__FOREACH, line 92 of E:/fpcsvn/fpcmirror/rtl/objpas/cl asses/sllist.inc $00465654 VISITRESOLVELIST, line 131 of E:/fpcsvn/fpcmirror/rtl/objpas/class es/resref.inc $004656DD GLOBALFIXUPREFERENCES, line 151 of E:/fpcsvn/fpcmirror/rtl/objpas/ classes/resref.inc $0046C6DA TREADER__READROOTCOMPONENT, line 1299 of E:/fpcsvn/fpcmirror/rtl/o bjpas/classes/reader.inc $004BDCAD INITCOMPONENT, line 2746 of lresources.pp $004BDB0F INITLAZRESOURCECOMPONENT, line 2766 of lresources.pp $004B8DF7 INITRESOURCECOMPONENT, line 542 of lresources.pp $0041957D TCUSTOMFORM__CREATE, line 1377 of ./include/customform.inc $0041AE26 TFORM__CREATE, line 2115 of ./include/customform.inc $007668BA TFRMCOMPILEROPTIONS__CREATE, line 294 of compileroptionsdlg.pp $0042F612 TMAINIDE__MNUPROJECTCOMPILERSETTINGSCLICKED, line 3516 of main.pp Other dialogs seems to be fine though. Jesus Reyes A. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
There also seems to be a problem with fixing up references to other
components while reading - TLabel.FocusControl seems to be one of the
things that is tripping this up. Local unresolved references are being
silently discarded, but I think should be added to the global list. The
attached patch fixes it for my application, but might not be the best
general fix.
Colin
diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc
--- trunk/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 16:56:06.0 +
+++ trunk.w/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 16:57:37.0 +
@@ -630,7 +630,7 @@
procedure TReader.DoFixupReferences;
Var
- R,RN : TLocalUnresolvedReference;
+ R : TLocalUnresolvedReference;
G : TUnresolvedInstance;
Ref : String;
C : TComponent;
@@ -644,7 +644,6 @@
R:=TLocalUnresolvedReference(L.Root);
While (R<>Nil) do
begin
- RN:=TLocalUnresolvedReference(R.Next);
Ref:=R.FRelative;
If Assigned(FOnReferenceName) then
FOnReferenceName(Self,Ref);
@@ -654,14 +653,10 @@
else
begin
P:=Pos('.',R.FRelative);
-If (P<>0) then
- begin
- G:=AddToResolveList(R.FInstance);
- G.Addreference(R.FRoot,R.FPropInfo,Copy(R.FRelative,1,P-1),Copy(R.FRelative,P+1,Length(R.FRelative)-P));
- end;
+G:=AddToResolveList(R.FInstance);
+G.Addreference(R.FRoot,R.FPropInfo,Copy(R.FRelative,1,P-1),Copy(R.FRelative,P+1,Length(R.FRelative)-P));
end;
- L.RemoveItem(R,True);
- R:=RN;
+ R:=TLocalUnresolvedReference(R.Next);
end;
FreeAndNil(FFixups);
end;
diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/resref.inc trunk.w/fpcsrc/rtl/objpas/classes/resref.inc
--- trunk/fpcsrc/rtl/objpas/classes/resref.inc 2008-03-28 09:19:50.0 +
+++ trunk.w/fpcsrc/rtl/objpas/classes/resref.inc 2008-03-29 16:57:37.0 +
@@ -220,7 +220,10 @@
C : TComponent;
begin
- C:=FindGlobalComponent(FGlobal);
+ if FGlobal <> '' then
+C:=FindGlobalComponent(FGlobal)
+ else
+C:=FRoot;
Result:=(C<>Nil);
If Result then
begin
@@ -229,7 +232,7 @@
If Result then
SetObjectProp(Instance, FPropInfo,C);
end;
-end;
+end;
Function TUnresolvedReference.RootMatches(ARoot : TComponent) : Boolean; Inline;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sat, 29 Mar 2008, C Western wrote: > There seems to be a problem in TReader.FindComponentClass - the search in > FindInFieldTable does not properly include ancestors. Great, I applied the patch. This should probably fix issue 11060 ! Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
There seems to be a problem in TReader.FindComponentClass - the search in FindInFieldTable does not properly include ancestors. See attached patch Colin diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc --- trunk/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-28 09:19:50.0 + +++ trunk.w/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 13:38:54.0 + @@ -1470,7 +1470,7 @@ // descendants of TComponent while ComponentClassType<>TComponent do begin FieldClassTable := -PFieldTable((Pointer(RootComponent.ClassType)+vmtFieldTable)^)^.ClassTable; +PFieldTable((Pointer(ComponentClassType)+vmtFieldTable)^)^.ClassTable; if assigned(FieldClassTable) then begin for i := 0 to FieldClassTable^.Count -1 do begin Entry := FieldClassTable^.Entries[i]; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Vincent Snijders schreef: Michael Van Canneyt schreef: There still is a memleak in the reader, when starting and stopping Lazarus: 333861 memory blocks allocated : 48899445/49814032 333803 memory blocks freed : 48898000/49812384 58 unfreed memory blocks : 1445 I think I plugged that one (Vincent: we had it in the tests too, if you recall). Can you test please ? If it persists, please send me the heaptrc output, that will make searching easier. It is not yet fixed. I sent heaptrc to you privately. Fixed in 10583: Heap dump by heaptrc unit 338700 memory blocks allocated : 45274460/46194864 338700 memory blocks freed : 45274460/46194864 0 unfreed memory blocks : 0 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Michael Van Canneyt schreef: There still is a memleak in the reader, when starting and stopping Lazarus: 333861 memory blocks allocated : 48899445/49814032 333803 memory blocks freed : 48898000/49812384 58 unfreed memory blocks : 1445 I think I plugged that one (Vincent: we had it in the tests too, if you recall). Can you test please ? If it persists, please send me the heaptrc output, that will make searching easier. It is not yet fixed. I sent heaptrc to you privately. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 28 Mar 2008, Vincent Snijders wrote: > Martin Schreiber schreef: > > On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: > > > While extensive testing has been done (using the FPCunit testing > > > framework), and the working of Lazarus with this new code was verified, it > > > is possible that bugs remain. We would therefor very much appreciate that > > > if you have code that uses some of the routines below, that you test your > > > code with the latest FPC from subversion (revision 10572 or above) and > > > report any bugs that you may encounter. If you do, please submit a > > > bugreport in mantis: > > > > > > http://bugs.freepascal.org/ > > > > > http://bugs.freepascal.org/view.php?id=11059 > > Does this cause no problems for Lazarus? > > 11059 should be fixed. > > I added this and 11060 to the cleanroom page. > http://wiki.lazarus.freepascal.org/FPC_Cleanroom#Bug_reports > > There still is a memleak in the reader, when starting and stopping Lazarus: > 333861 memory blocks allocated : 48899445/49814032 > 333803 memory blocks freed : 48898000/49812384 > 58 unfreed memory blocks : 1445 I think I plugged that one (Vincent: we had it in the tests too, if you recall). Can you test please ? If it persists, please send me the heaptrc output, that will make searching easier. 11060 is a harder nut to crack, though. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Martin Schreiber schreef: On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? I added this and 11060 to the cleanroom page. http://wiki.lazarus.freepascal.org/FPC_Cleanroom#Bug_reports There still is a memleak in the reader, when starting and stopping Lazarus: 333861 memory blocks allocated : 48899445/49814032 333803 memory blocks freed : 48898000/49812384 58 unfreed memory blocks : 1445 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Martin Schreiber schreef: On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? Yes, it does. I didn't notice before though. It is a problem for non-control TComponent you drop on a form, like a TOpenDialog. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: > > While extensive testing has been done (using the FPCunit testing > framework), and the working of Lazarus with this new code was verified, it > is possible that bugs remain. We would therefor very much appreciate that > if you have code that uses some of the routines below, that you test your > code with the latest FPC from subversion (revision 10572 or above) and > report any bugs that you may encounter. If you do, please submit a > bugreport in mantis: > > http://bugs.freepascal.org/ > http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Important: Call for testing.
Hello, at the end of last year, the FPC team was notified that certain portions of the FPC codebase contained possible copyright infringements on copyrighted code from Codegear (Borland). As a precaution, an internal audit was done by the FPC team using an automated tool, and a list of routines was compiled that could possibly be considered a copyright infringement. The complete list is at the end of this mail. It was decided that these routines should be re-implemented with cleanroom implementations, to remove all suspicion from the FPC codebase. The FPC team has now finally completed creating cleanroom implementations, and the implementations have been committed to the main branch (trunk) of the FPC codebase. Later, these will be merged to the fixes branch, and release 2.2.2 will be created with this implementation. While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ We'll give the code 2 weeks to be tested, and unless major problems pop up, the code will be merged to the fixes branch, and then release 2.2.2 will be started with this code. It is therefor vital that the code be tested very well, as it will definitely end up in the next release. For the FPC team, Michael. --- Complete list of replaced routines: Classes unit: - ExtractStrings TParser.TokenComponentIdent TParser.NextToken TWriter.WriteComponent TWriter.WriteComponentData TWriter.WriteProperties TStringList.Grow TStringList.QuickSort TStringList.Find FindNestedComponent GlobalFixupReferences GetFixupInstanceNames RemoveFixupReferences RedirectFixupReferences GetFixupInstanceNames RemoveGlobalFixup RemoveFixups TReader.DoFixupReferences TReader.FindComponentClass TReader.ReadCollection TList.Extract TFPList.Assign TCollection.GetNamePath Strutils unit: -- SearchBuf DecodeSoundexInt Varutils unit: -- DoVarClearArray Math unit: -- MomentSkewKurtosis ComObj unit: HandleSafeCallException DB unit: TDataset.CalculateFields TDataset.DataEvent TDataset.EnableControls TDataLink.CalcFirstRecord TField.CalcLookupValue TField.RefreshLookupList ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
