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] Bug in trunk?
Why should it be true ? The specs only say something about writing, not about reading. It is a misconception to think that you can read a stream and thus restore a component to it's "original designed state". The behaviour of reading a component from stream is only well-defined after it was just created. If you want a general streaming mechanism (javabeans like), then you simply should not use "stored" or "default", then you'll have something that comes close. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel This was about modifiers http://bugs.freepascal.org/view.php?id=10080 Current impementation of propert writer is Delphi incompatible (eg does not take in account modifiers as the Delphi does). Anton ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] freepascal.org HTTP and SVN access
Evgeniy Ivanov wrote: Gabor Boros пишет: Hi, I have same problem too. I can access http://www.freepascal.org from home but not from the office. If try ping www.freepascal.org at the office i get response. But the http://62.166.198.202 not working. At home everything works. Sometimes I have the same problem. Server: Apache/2.2.4 (Ubuntu) DAV/2 SVN/1.4.4 PHP/5.2.3-1ubuntu6.3 Problem is in 2 keywords IMHO 1. Apache/2.2.4 configuration of default site handling (w/o site: header field) and php scripts timeout 2. Ubuntu (too hot and too new versions) As the Debianist I can say only - use STABLE, Luke Regards, Anton Kavalenka ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28 Mar 2008, at 16:58, Martin Schreiber wrote: On Friday 28 March 2008 16.42:52 Jonas Maebe wrote: On 28 Mar 2008, at 16:41, Martin Schreiber wrote: On Friday 28 March 2008 16.36:35 Jonas Maebe wrote: Floats not, integers yes, I think ? FPC cannot deal properly with floats either as far as I can see from the compiler source code. But since there is apparently no way to easily create a simple test program, I can't verify this. AFAIK there is a inherent default of 0.0, "default" property keyword can not be used with floats. In can be in FPC. Uuh, no rounding problems across platforms No, because it forces everything into a single (although wrongly, as far as I can see). and by ObjectTextToBinary<->ObjectBinaryToText? ;-) As I said, I don't think it works at all currently, but I have no test program to verify that assumption. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Friday 28 March 2008 16.42:52 Jonas Maebe wrote: > On 28 Mar 2008, at 16:41, Martin Schreiber wrote: > > On Friday 28 March 2008 16.36:35 Jonas Maebe wrote: > >>> Floats not, integers yes, I think ? > >> > >> FPC cannot deal properly with floats either as far as I can see from > >> the compiler source code. But since there is apparently no way to > >> easily create a simple test program, I can't verify this. > > > > AFAIK there is a inherent default of 0.0, "default" property keyword > > can not > > be used with floats. > > In can be in FPC. > Uuh, no rounding problems across platforms and by ObjectTextToBinary<->ObjectBinaryToText? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28 Mar 2008, at 16:41, Martin Schreiber wrote: On Friday 28 March 2008 16.36:35 Jonas Maebe wrote: Floats not, integers yes, I think ? FPC cannot deal properly with floats either as far as I can see from the compiler source code. But since there is apparently no way to easily create a simple test program, I can't verify this. AFAIK there is a inherent default of 0.0, "default" property keyword can not be used with floats. In can be in FPC. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Friday 28 March 2008 16.36:35 Jonas Maebe wrote: > > > > Floats not, integers yes, I think ? > > FPC cannot deal properly with floats either as far as I can see from > the compiler source code. But since there is apparently no way to > easily create a simple test program, I can't verify this. > AFAIK there is a inherent default of 0.0, "default" property keyword can not be used with floats. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28 Mar 2008, at 16:19, Michael Van Canneyt wrote: On Fri, 28 Mar 2008, Micha Nelissen wrote: Michael Van Canneyt wrote: Oh come on! It's not *that* far from a general streaming mechanism; so I consider this a design flaw. IMHO, it's very far, see Mattias' remarks :( Hmm well the other "fun" thing was that in Delphi you could not have no default for floats or integers IIRC. Maybe this was fixed though? Floats not, integers yes, I think ? FPC cannot deal properly with floats either as far as I can see from the compiler source code. But since there is apparently no way to easily create a simple test program, I can't verify this. 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 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
Re: [fpc-devel] Bug in trunk?
On Fri, 28 Mar 2008, Micha Nelissen wrote: > Michael Van Canneyt wrote: > > > Oh come on! It's not *that* far from a general streaming mechanism; so I > > > consider this a design flaw. > > > > IMHO, it's very far, see Mattias' remarks :( > > Hmm well the other "fun" thing was that in Delphi you could not have no > default for floats or integers IIRC. Maybe this was fixed though? Floats not, integers yes, I think ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Michael Van Canneyt wrote: Oh come on! It's not *that* far from a general streaming mechanism; so I consider this a design flaw. IMHO, it's very far, see Mattias' remarks :( Hmm well the other "fun" thing was that in Delphi you could not have no default for floats or integers IIRC. Maybe this was fixed though? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Fri, 28 Mar 2008, Micha Nelissen wrote: > Michael Van Canneyt wrote: > > If you want a general streaming mechanism (javabeans like), then you > > simply should not use "stored" or "default", then you'll have something > > that comes close. > > Oh come on! It's not *that* far from a general streaming mechanism; so I > consider this a design flaw. IMHO, it's very far, see Mattias' remarks :( Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Michael Van Canneyt wrote: If you want a general streaming mechanism (javabeans like), then you simply should not use "stored" or "default", then you'll have something that comes close. Oh come on! It's not *that* far from a general streaming mechanism; so I consider this a design flaw. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Fri, 28 Mar 2008, Micha Nelissen wrote: > Michael Van Canneyt wrote: > > > FYI: so before streaming, the "streamer" has to reset the values to their > > > defaults to stream properly. Unfortenately, there is no function to do > > > this, > > > and it's usually done in constructor. Therefore streaming twice does not > > > work > > > properly. > > > > This is not correct. > > > > The default value is the value at create time and remains fixed during the > > lifetime of the component. It has no influence on the number of times you > > stream a component. > > Example: suppose a component has been written out that uses the default for a > certain property X. Now if you do: > > class.X := ; > stream.readstream(class); > (class.X = ) is false, while it should be true. Why should it be true ? The specs only say something about writing, not about reading. It is a misconception to think that you can read a stream and thus restore a component to it's "original designed state". The behaviour of reading a component from stream is only well-defined after it was just created. If you want a general streaming mechanism (javabeans like), then you simply should not use "stored" or "default", then you'll have something that comes close. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Michael Van Canneyt wrote: FYI: so before streaming, the "streamer" has to reset the values to their defaults to stream properly. Unfortenately, there is no function to do this, and it's usually done in constructor. Therefore streaming twice does not work properly. This is not correct. The default value is the value at create time and remains fixed during the lifetime of the component. It has no influence on the number of times you stream a component. Example: suppose a component has been written out that uses the default for a certain property X. Now if you do: class.X := ; stream.readstream(class); (class.X = ) is false, while it should be true. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Fri, 28 Mar 2008, Mattias Gärtner wrote: > Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > > > > > On Fri, 28 Mar 2008, Micha Nelissen wrote: > > > > > Michael Van Canneyt wrote: > > > > It is used in streaming in the classes unit; the streaming mechanism > > checks > > > > the actual > > > > value against this value: if it is the same, the value is not streamed. > > > > > > FYI: so before streaming, the "streamer" has to reset the values to their > > > defaults to stream properly. Unfortenately, there is no function to do > > this, > > > and it's usually done in constructor. Therefore streaming twice does not > > work > > > properly. > > > > This is not correct. > > > > The default value is the value at create time and remains fixed during the > > lifetime of the component. It has no influence on the number of times you > > stream a component. > > Theoretically yes. > Practically it works this way: > TWriter writes a value if it differs from the 'default'. The 'default' is > 1. if there is a stored function, and it returns false, then the current value > is a default. > 2. if there is an ancestor, then the current value of the ancestor > 3. the 'default' constant of the property. > > So, it is not always possible to find out if _a_ value is default. > You can only find out if the _current_ value is default. Yes, but now you are juggling with terms, and mixing concepts: - The "default" keyword means the value when the class was created. Nothing more, nothing less. As such the current implementation does what it needs to do. - Stored is a mechanism, separate from default, to determine whether a property should be stored at all, regardless of the value, be it default or not. - The ancestor never acts as 'default'. Visual inheritance is a diff mechanism, nothing else: only the differences between ancestor and child should be streamed. The streaming mechanism uses these 3 concepts to minimalize the size of the stream that it creates. It couldn't care less about resetting the component or whatever. If a 'reset to defaults' mechanism is required, then a different set of concepts must be developed and used. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Fri, 28 Mar 2008, Micha Nelissen wrote: > > > Michael Van Canneyt wrote: > > > It is used in streaming in the classes unit; the streaming mechanism > checks > > > the actual > > > value against this value: if it is the same, the value is not streamed. > > > > FYI: so before streaming, the "streamer" has to reset the values to their > > defaults to stream properly. Unfortenately, there is no function to do > this, > > and it's usually done in constructor. Therefore streaming twice does not > work > > properly. > > This is not correct. > > The default value is the value at create time and remains fixed during the > lifetime of the component. It has no influence on the number of times you > stream a component. Theoretically yes. Practically it works this way: TWriter writes a value if it differs from the 'default'. The 'default' is 1. if there is a stored function, and it returns false, then the current value is a default. 2. if there is an ancestor, then the current value of the ancestor 3. the 'default' constant of the property. So, it is not always possible to find out if _a_ value is default. You can only find out if the _current_ value is default. And even worse: This is only true for normal properties. The DefineProperties can do nearly anything. Conclusion: In general you can not 'reset' an arbitrary component. Graeme's SetDefaults could be extended to apply all ancestor streams. Then it would probably set the defaults for 99% of all properties correct, assuming that the properties define good stored functions, good constructor values and good default constants. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TVarRec.VAnsiString memory leak? - solved
On Fri, Mar 28, 2008 at 10:17:01AM +0100, Michael Van Canneyt wrote: > This is a correct way: > > program str; > > uses > heaptrc; > > var > s,t: ansistring; > vr: TVarRec; > > begin > SetString(s, 'xxx', 3); //ok > vr.VType := vtAnsiString; > t:='yyy'; > vr.VAnsiString:=Pointer(T); > end. > Final solution is not to use VAnsiString because reference counting little confusing. My problem was to fill "array of const" with strings. And these strings must be somewere stored. Then i use vr.VPChar = StrNew(PChar(s)); ... StrDispose(vr.VPChar); Petr -- Ing. Petr Kristan . EPOS PRO s.r.o., Bozeny Nemcove 2625, 530 02 Pardubice tel: +420 466335223Czech Republic (Eastern Europe) fax: +420 466510709 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Fri, 28 Mar 2008, Micha Nelissen wrote: > Michael Van Canneyt wrote: > > It is used in streaming in the classes unit; the streaming mechanism checks > > the actual > > value against this value: if it is the same, the value is not streamed. > > FYI: so before streaming, the "streamer" has to reset the values to their > defaults to stream properly. Unfortenately, there is no function to do this, > and it's usually done in constructor. Therefore streaming twice does not work > properly. This is not correct. The default value is the value at create time and remains fixed during the lifetime of the component. It has no influence on the number of times you stream a component. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28/03/2008, Martin Schreiber <[EMAIL PROTECTED]> wrote:
> > Unrelated (because I think such declarations are
> > broken for fpu types/values): what code do you have to write so that
> > this default value is actually used?
> >
>
> fcolor is initialized to the default value in constructor. TWriter does
Well, you can set the default values automatically without having to
do it manually in the constructor. :-) I have been toying with this
idea in fpGUI. All that the developer needs to do is set the default
value in the class declaration.
I created a descendant TComponent class and in the AfterConstructor
method I call the SetDefaults();
procedure TfpgWindowBase.AfterConstruction;
begin
inherited AfterConstruction;
{ Here is a neater way by using RTTI to set default property
values all automatically. No need to duplicate the efforts
and manually set the property default values in the
constructor. This code is now the same for each
TfpgWindowBase descendant (which includes GUI widgets) }
SetDefaults(self);
end;
// This function uses RTTI to automatically set the default values
// of properties. That means we don't have to do it in the
// constructor anymore! :-)
procedure SetDefaults(Obj: TObject);
var
PropInfos: PPropList;
Count, Loop: Integer;
begin
PropInfos := nil;
{ Find out how many properties we'll be considering }
Count := GetPropList(Obj.ClassInfo, tkPropsWithDefault, nil);
{ Allocate memory to hold their RTTI data }
GetMem(PropInfos, Count * SizeOf(PPropInfo));
try
{ Get hold of the property list in our new buffer }
GetPropList(Obj.ClassInfo, tkPropsWithDefault, PropInfos);
{ Loop through all the selected properties }
for Loop := 0 to Count - 1 do
with PropInfos^[Loop]^ do
{ If there is supposed to be a default value... }
if Default <> NoDefault then
{ ...then jolly well set it }
SetOrdProp(Obj, PropInfos^[Loop], Default)
finally
FreeMem(PropInfos, Count * SizeOf(PPropInfo));
end;
end;
RTTI can be very handy sometimes! ;-)
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28/03/2008, Jonas Maebe <[EMAIL PROTECTED]> wrote: > > It compiles again. Unrelated (because I think such declarations are > broken for fpu types/values): what code do you have to write so that > this default value is actually used? fpGUI's UI Designer generates GUI code directly in the .pas unit, not via BinaryObjectToText() etc.. It checks the default value of a property before it decides to generate code or not. Here is an example of a Boolean property. function TPropertyBoolean.GetPropertySource(wg: TfpgWidget; const ident: string): string; var i: integer; s: string; PropInfo: PPropInfo; begin PropInfo := GetPropInfo(wg.ClassType, Name); i := GetOrdProp(wg, Name); if PropInfo^.Default <> i then begin if i = 1 then s := 'True' else s := 'False'; Result := ident + Name + ' := ' + s + ';' + LineEnding; end else Result := ''; end; Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Friday 28 March 2008 11.23:07 Jonas Maebe wrote: > On 28 Mar 2008, at 07:47, Martin Schreiber wrote: > > What is wrong with this code: [...] > > It compiles again. Thanks! > Unrelated (because I think such declarations are > broken for fpu types/values): what code do you have to write so that > this default value is actually used? > fcolor is initialized to the default value in constructor. TWriter does not stream property values which are equal to the default value. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Michael Van Canneyt wrote: It is used in streaming in the classes unit; the streaming mechanism checks the actual value against this value: if it is the same, the value is not streamed. FYI: so before streaming, the "streamer" has to reset the values to their defaults to stream properly. Unfortenately, there is no function to do this, and it's usually done in constructor. Therefore streaming twice does not work properly. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On Fri, 28 Mar 2008, Jonas Maebe wrote:
>
> On 28 Mar 2008, at 07:47, Martin Schreiber wrote:
>
> >What is wrong with this code:
> >"
> >program rangeerror;
> >{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
> >{$ifdef mswindows}{$apptype console}{$endif}
> >uses
> >{$ifdef FPC}{$ifdef linux}cthreads,{$endif}{$endif}
> >sysutils;
> >type
> >colorty = type longword;
> >const
> >cl_mapped = colorty($9000);
> >type
> >ttestclass = class
> > private
> > fcolor: colorty;
> > published
> > property color: colorty read fcolor write fcolor default cl_mapped; //<<--
> >end;
> >begin
> >end.
>
> It compiles again. Unrelated (because I think such declarations are broken for
> fpu types/values): what code do you have to write so that this default value
> is actually used?
It is used in streaming in the classes unit; the streaming mechanism checks the
actual
value against this value: if it is the same, the value is not streamed.
Martin by himself probably doesn't have specific code.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28 Mar 2008, at 07:47, Martin Schreiber wrote:
What is wrong with this code:
"
program rangeerror;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
{$ifdef FPC}{$ifdef linux}cthreads,{$endif}{$endif}
sysutils;
type
colorty = type longword;
const
cl_mapped = colorty($9000);
type
ttestclass = class
private
fcolor: colorty;
published
property color: colorty read fcolor write fcolor default
cl_mapped; //<<--
end;
begin
end.
It compiles again. Unrelated (because I think such declarations are
broken for fpu types/values): what code do you have to write so that
this default value is actually used?
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TVarRec.VAnsiString memory leak?
On Fri, 28 Mar 2008, [EMAIL PROTECTED] wrote: > Hi. > > This construction of setup vr.VAnsiString cause memoryleak: > > program str; > uses > heaptrc; > var > s: ansistring; > vr: TVarRec; > begin > SetString(s, 'xxx', 3); //ok > vr.VType := vtAnsiString; > SetString(AnsiString(vr.VAnsiString), 'yyy', 3); //Memory leak. > end. This is a correct way: program str; uses heaptrc; var s,t: ansistring; vr: TVarRec; begin SetString(s, 'xxx', 3); //ok vr.VType := vtAnsiString; t:='yyy'; vr.VAnsiString:=Pointer(T); end. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TVarRec.VAnsiString memory leak?
Hi. This construction of setup vr.VAnsiString cause memoryleak: program str; uses heaptrc; var s: ansistring; vr: TVarRec; begin SetString(s, 'xxx', 3); //ok vr.VType := vtAnsiString; SetString(AnsiString(vr.VAnsiString), 'yyy', 3); //Memory leak. end. Heap dump by heaptrc unit 2 memory blocks allocated : 24/32 1 memory blocks freed : 12/16 1 unfreed memory blocks : 12 True heap size : 32768 True free heap : 32672 Should be : 32688 Call trace for block $B7FEE0C0 size 12 $08050E82 $fpc_ansistr_setlength, line 569 of /home/common/fpc/rtl/inc/astrings.inc $080480DF main, line 10 of str.pas $080678B1 _FPC_proc_start, line 67 of ./i386/si_prc.inc Is right that in destroying TVarRec is not decremented ansistring reference? If so, how to correctly set TVarRec.VAnsiString without memoryleak? I need to fill "a: array of TVarRec" with ansistrings. Thanks. Petr -- Ing. Petr Kristan . EPOS PRO s.r.o., Bozeny Nemcove 2625, 530 02 Pardubice tel: +420 466335223Czech Republic (Eastern Europe) fax: +420 466510709 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28/03/2008, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > > and TfpgColor is defined as follows: > > TfpgColor = type longword; > > With FPC 2.2.0 (64bit and 32bit) the code compiles with out issues. And some predefined colors used in fpGUI are defined as follows: clSilver= TfpgColor($C0C0C0); clTeal = TfpgColor($008080); clWhite = TfpgColor($FF); clYellow= TfpgColor($00); clNone = TfpgColor($1FFF); clDefault = TfpgColor($2000); Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
On 28/03/2008, Martin Schreiber <[EMAIL PROTECTED]> wrote: > Hi, > What is wrong with this code: Michael Van Canneyt detected a similar issue with fpGUI code and FPC 2.3.1 - It doesn't compile with my 2.3.1 compiler. (64 bit) Free Pascal Compiler version 2.3.1 [2007/07/04] for x86_64 Copyright (c) 1993-2007 by Florian Klaempfl gfx_widget.pas(126,117) Error: range check error while evaluating constants gfx_widget.pas(127,88) Error: range check error while evaluating constants gfx_widget.pas(137,1) Fatal: There were 2 errors compiling module, stopping The lines referred to are: property BackgroundColor: TfpgColor read FBackgroundColor write SetBackgroundColor default clWindowBackground; property TextColor: TfpgColor read FTextColor write SetTextColor default clText1; and TfpgColor is defined as follows: TfpgColor = type longword; With FPC 2.2.0 (64bit and 32bit) the code compiles with out issues. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
