[fpc-devel] Bug in trunk?

2008-03-28 Thread Martin Schreiber
Hi, 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 =

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Graeme Geldenhuys
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Graeme Geldenhuys
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=

[fpc-devel] TVarRec.VAnsiString memory leak?

2008-03-28 Thread petr . kristan
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

Re: [fpc-devel] TVarRec.VAnsiString memory leak?

2008-03-28 Thread Michael Van Canneyt
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),

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Jonas Maebe
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Michael Van Canneyt
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}

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Martin Schreiber
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Graeme Geldenhuys
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,

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Graeme Geldenhuys
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Michael Van Canneyt
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

Re: [fpc-devel] TVarRec.VAnsiString memory leak? - solved

2008-03-28 Thread petr . kristan
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.

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Mattias Gärtner
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.

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Michael Van Canneyt
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Micha Nelissen
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Michael Van Canneyt
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Micha Nelissen
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Michael Van Canneyt
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Micha Nelissen
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Michael Van Canneyt
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

Re: [fpc-devel] Important: Call for testing.

2008-03-28 Thread Martin Schreiber
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Jonas Maebe
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Martin Schreiber
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Jonas Maebe
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Martin Schreiber
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.

Re: [fpc-devel] freepascal.org HTTP and SVN access

2008-03-28 Thread Anton Kavalenka
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

Re: [fpc-devel] Bug in trunk?

2008-03-28 Thread Anton Kavalenka
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

Re: [fpc-devel] Important: Call for testing.

2008-03-28 Thread Vincent Snijders
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

Re: [fpc-devel] Important: Call for testing.

2008-03-28 Thread Vincent Snijders
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