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
pp.pas(224
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 libra
Florian Klaempfl :
> Vinzent Höfler schrieb:
> > Florian Klaempfl :
> >
> >> 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
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> 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 won't continue
her
Florian Klaempfl :
> 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 type?
(Especially when
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, otherwis
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
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> Vinzent Höfler schrieb:
>>> Florian Klaempfl :
>>>
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 y
Florian Klaempfl :
> Vinzent Höfler schrieb:
> > Florian Klaempfl :
> >
> >> 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
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 fin
Graeme Geldenhuys :
> 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 alle GMX-Mitglieder:
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.
>
>
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> 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 li
Florian Klaempfl :
> 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 ansistrings.
I don't underst
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
___
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 - fpc-deve
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 b
Luiz Americo Pereira Camara wrote:
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
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.
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 varia
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> Without COM, FPC wouldn't have out parameters.
>
> And because there would be no difference between "var" and "out" then,
There would be difference: no out keyword at all :)
> it also wouldn't have the hint. Case dismissed. ;)
_
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
Florian Klaempfl :
> 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 freischalten unter http://po
Felipe Monteiro de Carvalho schrieb:
> On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell 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 architect
> R01 used by Assembler for optimization (don't use)
> R02 Function Return Value (least significant 32 Bits) (Not used by
> Compiler)
Sorry, Typo: Of course R01 is the one that is not used by the compiler.
-Michael
___
fpc-devel maillist -
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 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
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell 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 system will you be t
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.
$ ta
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell 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 news about this.
On Thu, Nov 19, 2009 at 21:02, Jonas Maebe 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 very bad name th
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> http://www.freepascal.
On 19 Nov 2009, at 11:51, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe
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 rtl or generated initiali
Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe 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 m
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe 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 the compiler
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?
Initialize char arrays to empty strings, other structures like pointers
to nil, byte a
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 documentatio
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.
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
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: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 o
On Thu, Nov 19, 2009 at 20:31, Jonas Maebe wrote:
>
> On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
>
>> On Thu, Nov 19, 2009 at 19:20, Martin wrote:
>>
>>> Jonas Maebe wrote:
>>
>> [skipped example]
>>
>>> Well in this case, the code is actually positively affected by the "out"
>>> param (be
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
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 mean
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
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 found
Mattias Gaertner schreef:
On Thu, 19 Nov 2009 10:53:09 +0100
JoshyFun 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 only show the heapt
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
dis
On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 19:20, Martin 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
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
I still do not fully understand.
On Thu, Nov 19, 2009 at 19:20, Martin 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 incorrect one,
a
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 in
On Thu, 19 Nov 2009 10:53:09 +0100
JoshyFun 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 only show the heaptrace window w
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 ty
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 thousa
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 t
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 th
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 memo
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 usin
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 expl
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 ga
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 ne
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/
___
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-
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
r.str
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 :)?
___
Alexander Klenin wrote on do, 19 nov 2009:
On Thu, Nov 19, 2009 at 18:36, Jonas Maebe 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 s
On Thu, Nov 19, 2009 at 18:36, Jonas Maebe 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 are
> overwritten with ze
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 th
69 matches
Mail list logo
