Graeme Geldenhuys wrote on do, 19 nov 2009:
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Can't that behaviour be limited to Windows platform only.
It would change the behaviour of code between Windows and non-Windows
platforms. One
On Thu, Nov 19, 2009 at 18:36, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
More importantly, another thing it would affect is that in case someone has
written their own fillchar with an out parameter, and *expects* reference
counted structures to be finalised at the caller side before they
Alexander Klenin wrote on do, 19 nov 2009:
On Thu, Nov 19, 2009 at 18:36, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
More importantly, another thing it would affect is that in case someone has
written their own fillchar with an out parameter, and *expects* reference
counted structures to be
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
Without COM, FPC wouldn't have out parameters.
Why do you say that?
Because I added it for Delphi compatibility which needs it for COM?
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
Jonas Maebe wrote:
Alexander Klenin wrote on do, 19 nov 2009:
Can you give an example code which would be (badly) affected by
proposed change?
type
tr = record
str: ansistring;
end;
procedure clear(out rec; size: ptruint);
begin
fillchar(rec,size,0);
end;
var
r: tr;
begin
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
I search the latest FP Language Reference document, and there is no
mention of 'varout'. I also tried to use varout in a procedure as
follows - which gave a compiler error with FPC 2.4.0-rc1
Alexander Klenin wrote:
Can you give an example code which would be (badly) affected by
proposed change?
Thanks Alexander, you beat me to that question. :-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
Graeme Geldenhuys schreef:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
First one is not compilable, but the second one is. So no, I don't
understand your comment about 'varout'? Please explain more.
varout could be the name of the
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
I search the latest FP Language Reference document, and there is no
mention of 'varout'. I also tried to use varout in a procedure as
follows - which gave a
Vincent Snijders schrieb:
Graeme Geldenhuys schreef:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
First one is not compilable, but the second one is. So no, I don't
understand your comment about 'varout'? Please explain more.
Vincent Snijders wrote:
varout could be the name of the new parameter modifier that Jonas
mentions[1] and that has the semantics that you think out should
have, but hasn't.
Ah, now I understand. Thanks Vincent.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using
Florian Klaempfl wrote:
initialized. But be warned: with such a parameter type you can easily
create memory leaks with automated types like ansistrings.
Well, isn't that what heaptrc is for? I enable heaptrc by default for
all my projects (except on release builds). That way I can catch
Hello FPC,
The Graeme's comment about heaptrace bring me some questions about it
that were lost in my pocket.
(Windows only I think, and I do not know if Lazarus exclusive)
Is there any way to only show the heaptrace window when leaks are
present ?
Is there any way to add a cancel button to the
Graeme Geldenhuys wrote:
Florian Klaempfl wrote:
initialized. But be warned: with such a parameter type you can easily
create memory leaks with automated types like ansistrings.
Well, isn't that what heaptrc is for?
No, the language should protect you from such easy to make mistakes.
In
Graeme Geldenhuys wrote:
As I stated in the other mailing list. It's not about a obsession to get
hint warning free code. It's about spoting REAL issues in code between
all the crap the compiler currently spits out. If your project uses a
lot of structure types, you can quickly sit with
Paul Ishenin schrieb:
Graeme Geldenhuys wrote:
As I stated in the other mailing list. It's not about a obsession to get
hint warning free code. It's about spoting REAL issues in code between
all the crap the compiler currently spits out. If your project uses a
lot of structure types, you
Marc Weustink wrote:
Well, isn't that what heaptrc is for?
No, the language should protect you from such easy to make mistakes.
I guess that's the ideal situation. Currently the language doesn't stop
me from creating other memory leaks like not freeing a TStringList or
other object
I still do not fully understand.
On Thu, Nov 19, 2009 at 19:20, Martin laza...@mfriebe.de wrote:
Jonas Maebe wrote:
[skipped example]
Well in this case, the code is actually positively affected by the out
param (because it avoids the mem leak)
Jonas, can you confirm that your example is
Paul Ishenin wrote:
Compiler will add a flag for each var/const argument that they dont
require that checks.
Can't the compiler simply initialize structured types by default?
Initialize char arrays to empty strings, other structures like pointers
to nil, byte arrays to #0 etc..?
After all,
On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 19:20, Martin laza...@mfriebe.de wrote:
Jonas Maebe wrote:
[skipped example]
Well in this case, the code is actually positively affected by the
out
param (because it avoids the mem leak)
Jonas, can you confirm
Felipe Monteiro de Carvalho wrote:
How would one proceed to port Free Pascal to a new architecture? Any
initial steps? I haven't found anything about this.
Please take a look at the backlog of this mailing list. It has been
discussed just recently in the LLVM Backend? thread and also was
Mattias Gaertner schreef:
On Thu, 19 Nov 2009 10:53:09 +0100
JoshyFun joshy...@gmail.com wrote:
Hello FPC,
The Graeme's comment about heaptrace bring me some questions about it
that were lost in my pocket.
(Windows only I think, and I do not know if Lazarus exclusive)
Is there any way to
On 18 Nov 2009, at 11:40, Felipe Monteiro de Carvalho wrote:
How would one proceed to port Free Pascal to a new architecture? Any
initial steps?
Start from an initial backend that is most similar to your cpu. E.g.,
probably ARM or SPARC in your case. Then modify the code.
I haven't
Jonas Maebe wrote:
If you change the behaviour of out so that such parameters are no
longer finalised before the routine is entered, then the above will
cause a memory leak. You can verify this by changing the out rec
parameter into var rec.
Then this is definitely not a sextopod but an
Jonas Maebe wrote:
On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
Well in this case, the code is actually positively affected by the
out
param (because it avoids the mem leak)
Jonas, can you confirm that your example is incorrect one,
and Martin's example below is actually what you
In our previous episode, Graeme Geldenhuys said:
initialized. But be warned: with such a parameter type you can easily
create memory leaks with automated types like ansistrings.
Well, isn't that what heaptrc is for? I enable heaptrc by default for
all my projects (except on release
On Thu, Nov 19, 2009 at 20:31, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 19:20, Martin laza...@mfriebe.de wrote:
Jonas Maebe wrote:
[skipped example]
Well in this case, the code is actually positively affected
On 19 Nov 2009, at 11:24, Graeme Geldenhuys wrote:
Paul Ishenin wrote:
Compiler will add a flag for each var/const argument that they dont
require that checks.
Can't the compiler simply initialize structured types by default?
The compiler already initialises the reference counted fields
On 19 Nov 2009, at 11:39, Thaddy wrote:
Jonas Maebe wrote:
If you change the behaviour of out so that such parameters are no
longer finalised before the routine is entered, then the above will
cause a memory leak. You can verify this by changing the out rec
parameter into var rec.
On 19 Nov 2009, at 11:42, Alexander Klenin wrote:
No, I asked for an example of code that would be negatively affected
by
changing var to out in FillChar parameter.
I don't know by heart anymore, but as I mentioned the compiler crashed
when I tried that (or if you did that move, which
Here another quote from the said thread:
---
Florian Klaempfl wrote:
Another backend for FPC is 4k-5k lines (pascal, no need to
learn C), just make it a bounty for say 2000 Eur and I'am sure, somebody
will write you a backend for the desired processor.
JoshyFun wrote:
(Windows only I think, and I do not know if Lazarus exclusive)
Is there any way to add a cancel button to the window that show leaks
?
It's not specific to Lazarus or Windows. As Vincent said, rather output
to file using an environment variable. The heaptrc documentation
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 19 Nov 2009, at 11:42, Alexander Klenin wrote:
No, I asked for an example of code that would be negatively affected by
changing var to out in FillChar parameter.
I don't know by heart anymore, but as I mentioned
Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 19 Nov 2009, at 11:42, Alexander Klenin wrote
No, I asked for an example of code that would be negatively affected by
changing var to out in FillChar parameter.
I don't know by
On 19 Nov 2009, at 11:51, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe
jonas.ma...@elis.ugent.be wrote:
I don't know by heart anymore, but as I mentioned the compiler
crashed when
I tried that (or if you did that move, which has the same problem).
There is
probably
Hello Vincent,
Thursday, November 19, 2009, 11:36:31 AM, you wrote:
VS I am not so sure. Heaptrc outputs to stdout. If the
VS application is compiled -WG the
VS RTL redirects the output to message windows. I would
VS recommend to let heatprc write
VS to file. See
VS
On Thu, Nov 19, 2009 at 21:02, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
Ok, so how about introducing, say, FillMem procedure, which is
identical to FillChar
except that it has out parameter,
See http://lists.freepascal.org/lists/fpc-devel/2009-November/018559.html
FillMem would be a
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell mschn...@lumino.de wrote:
This is great news for me, as I am considering a NIOS2 Port and NIOS2 is
very similar to MIPS32 so we might be able to work together on this and
the resulting thingy would support both architectures.
I already have 2
JoshyFun wrote:
on each run and in the development process and test you must manually
open the file to know if something leaks (easy to forget).
Under any unix-type environment do the following in a console window...
Simply keep this console window open in one corner of your screen.
$ tail
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell mschn...@lumino.de wrote:
This is great news for me, as I am considering a NIOS2 Port and NIOS2 is
very similar to MIPS32 so we might be able to work together on this and
the resulting thingy would support both architectures.
What operating
Felipe Monteiro de Carvalho wrote:
http://sourceforge.net/projects/fpc-mips/develop
AFAIK, this only contains some initial steps that someone tool ages ago
and did not proceed.
Maybe this work could be ported to the latest trunk.
I have no hope regarding this and suppose to do code for
Felipe Monteiro de Carvalho wrote:
What operating system will you be targetting?
Linux
I think that telling FPC which ASM instructions to use should be quite
easy, the main problem should be getting a grip in the binutils, how
to link libraries and all other stuff that comes with it.
Felipe Monteiro de Carvalho schrieb:
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell mschn...@lumino.de wrote:
This is great news for me, as I am considering a NIOS2 Port and NIOS2 is
very similar to MIPS32 so we might be able to work together on this and
the resulting thingy would support
Florian Klaempfl flor...@freepascal.org:
Without COM, FPC wouldn't have out parameters.
And because there would be no difference between var and out then, it also
wouldn't have the hint. Case dismissed. ;)
Vinzent.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt
Hi
You can help improve the upcoming 2.4.0 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_2.4.0
How is one supposed to reported the results of the test suite ?
That is what I got so far ( Vista 32 bits/
Graeme Geldenhuys escreveu:
JoshyFun wrote:
(Windows only I think, and I do not know if Lazarus exclusive)
Is there any way to add a cancel button to the window that show leaks
?
It's not specific to Lazarus or Windows. As Vincent said, rather output
to file using an environment
Without COM, FPC wouldn't have out parameters.
And because there would be no difference between var and out then, it also
wouldn't have the hint. Case dismissed. ;)
Vinzent.
Yup.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Martin schreef:
IMHO the IDE should by default set the enviromane so the heaptrc gets
written to a file in the project dir (which is cleared by the IDE
before). Then the IDE can pick it up...
Nice idea, if only the bug in gdb (on windows) to set environment
variables in the debuggee would
On 19 Nov 2009, at 20:31, Vincent Snijders wrote:
Nice idea, if only the bug in gdb (on windows) to set environment variables
in the debuggee would be fixed...
Where's the gdb bug report? I can't find it.
Jonas___
fpc-devel maillist -
Jonas Maebe schreef:
On 19 Nov 2009, at 20:31, Vincent Snijders wrote:
Nice idea, if only the bug in gdb (on windows) to set environment variables in
the debuggee would be fixed...
Where's the gdb bug report? I can't find it.
Where should it be reported?
How should report it?
Vincent
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with such a parameter type you can easily create memory leaks
with automated types like
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with such a parameter type you can easily create memory leaks
with
On 19 Nov 2009, at 20:42, Vincent Snijders wrote:
Jonas Maebe schreef:
On 19 Nov 2009, at 20:31, Vincent Snijders wrote:
Nice idea, if only the bug in gdb (on windows) to set environment variables
in the debuggee would be fixed...
Where's the gdb bug report? I can't find it.
Where
Graeme Geldenhuys gra...@mastermaths.co.za:
Can't the compiler simply initialize structured types by default?
[...]
After all, this is already done for AnsString, Integer type, real types
etc...
No, it's not (except for AnsiString, because it's reference counted).
Vinzent.
--
GRATIS für
Jonas Maebe schreef:
On 19 Nov 2009, at 20:42, Vincent Snijders wrote:
Jonas Maebe schreef:
On 19 Nov 2009, at 20:31, Vincent Snijders wrote:
Nice idea, if only the bug in gdb (on windows) to set environment variables in
the debuggee would be fixed...
Where's the gdb bug report? I can't
Florian Klaempfl flor...@freepascal.org:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with such a parameter
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with
Hello Vincent,
Thursday, November 19, 2009, 9:35:30 PM, you wrote:
Using a reproducible case described step by step, similar to an
FPC bug report. Bonus points if you can provide a C program to
reproduce it. If you only have an FPC program, it's best to include
also a compiled version so
On 19 Nov 2009, at 22:31, Florian Klaempfl wrote:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
procedure p(varout v : ansistring);
begin
v:='asdf';
end;
I don't think that this could cause a memory leak, otherwise this
Florian Klaempfl flor...@freepascal.org:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
That's a semantic definition, not an explanation. IOW: What stops you from
selecting to implement the proper semantics depending on the
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
That's a semantic definition, not an explanation.
Sorry, but it seems you didn't follow up the thread, so I
Florian Klaempfl flor...@freepascal.org:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
That's a semantic definition, not an explanation.
Sorry, but
Hello, FPC developers' list.
I tried to build the compiler with gprof profile code. In the compiler
dir I executed:
make clean all OPT=-gl -pg
As result of linking I have the next errors:
Linking .\pp.exe
pp.pas(224,1) Error: Import library not found for c
pp.pas(224,1) Error: Import
Paul Ishenin schreef:
Hello, FPC developers' list.
I tried to build the compiler with gprof profile code. In the compiler
dir I executed:
make clean all OPT=-gl -pg
As result of linking I have the next errors:
Linking .\pp.exe
pp.pas(224,1) Error: Import library not found for c
64 matches
Mail list logo
