>
> procedure TTestTIBaseObject.ValidFail1;
> var
> LO : TtiBaseObject;
> begin
> LO := TtiBaseObject(Random(2)+2000);
> writeln(' here we start'); // debug line
> LO.TestValid(False); // <== AV occurs here
> writeln('passed 1'); // debug line
> // check(not LO.TestValid
On Mon, 19 Nov 2007, Steve Howe wrote:
> Hello all,
>
> > > Then the TDaemonThread.CheckControlMessage() method should be declared
> > > virtual, so that messages could actually be checked for, shouldn't it ?
> >
> > No, why ? It must simply be implemented globally by default?
> >
> > If you wa
Hello,
The FPC team has been recently made aware that a number of routines in the
Classes unit are apparently based on code originally from Borland/CodeGear.
After someone found a tool to automatically compare source code bodies to look
for structural similarities, we improved its support for Obj
Hello Michael,
> > Yes, I could want to override the default for several reasons, such as
> > changing the sleep time. Would it hurt to make it virtual ?
>
> No, so I will do so :-)
Thanks :)
--
Best Regards,
Steve Howe
___
fpc-devel maillist - fpc-d
On 19/11/2007, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> be based on Delphi/Kylix code. All such identified routines of sufficient
> complexity and/or likeliness have been or are in the process of being
> rewritten
> from scratch using a clean room approach: by someone who is not intimate
On Mon, 19 Nov 2007, Graeme Geldenhuys wrote:
> On 19/11/2007, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> >
> > be based on Delphi/Kylix code. All such identified routines of sufficient
> > complexity and/or likeliness have been or are in the process of being
> > rewritten
> > from scratc
such as
changing the sleep time. Would it hurt to make it virtual ?
Is it really necessary to do polling (with or without sleep) here ?
Avoiding polling in any case would improve the performance and reduce
intrusiveness.
-Michael
___
fpc-devel m
Steve Howe ha scritto:
Hello all,
While using the daemonapp.pp unit to code a daemon, I've found that
applications that it eat 100% of the CPU. After tracking and debugging, I've
found out that the problem is in the daemonapp's TDaemonThread.Execute()
method:
procedure TDaemonThread.Execute
On Mon, 19 Nov 2007, Michael Schnell wrote:
>
> > such as changing the sleep time. Would it hurt to make it virtual ?
> >
> Is it really necessary to do polling (with or without sleep) here ? Avoiding
> polling in any case would improve the performance and reduce intrusiveness.
On linux, yo
Michael Van Canneyt wrote:
On linux, you can only do polling.
Of course you don't need polling, but the current architecture is only
suited for polling.
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mai
On Mon, 19 Nov 2007, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > On linux, you can only do polling.
>
> Of course you don't need polling, but the current architecture is only suited
> for polling.
On linux, everything comes down to polling. The only non-polling solution,
signals, ar
Michael Van Canneyt wrote:
On linux, everything comes down to polling. The only non-polling solution,
signals, are not suitable since you don't know in which thread the signal
ends up, and you must start using complicated inter-thread communication.
Use fpsigaction to mask the signal in the t
On Mon, 19 Nov 2007, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > On linux, everything comes down to polling. The only non-polling solution,
> > signals, are not suitable since you don't know in which thread the signal
> > ends up, and you must start using complicated inter-thread comm
Hello all,
> > such as
> > changing the sleep time. Would it hurt to make it virtual ?
>
> Is it really necessary to do polling (with or without sleep) here ?
> Avoiding polling in any case would improve the performance and reduce
> intrusiveness.
On Windows you have alternatives such as someone po
Steve Howe wrote:
Hello all,
such as
changing the sleep time. Would it hurt to make it virtual ?
Is it really necessary to do polling (with or without sleep) here ?
Avoiding polling in any case would improve the performance and reduce
intrusiveness.
On Windows you have alternatives such as some
On linux, everything comes down to polling. The only non-polling solution,
signals, are not suitable since you don't know in which thread the signal
ends up, and you must start using complicated inter-thread communication.
There are lots of concepts in Linux that theoretically could be used
Yes.On windows you could create event and wait for it to be
signaled.This particularly move response for loop to the windows core
and makes a huge difference in CPU usage.
Of course there are many zero overhead signaling methods in Linux.
AFAIK, several inter thread / inter process communica
> Hello,
>
> I have spent some time to profile the compiler using callgrind, and was
> able to improve its speed by about 20%. Attached are the changes that I
> made to the sources.
I gave the patch a quick try and the speed stays the same for compiling the
compiler sources. Can
you explain how y
Sounds goodl! Was it an overall improvement? What 'benchmark' was '20% faster'
with the patches? Guess it was compiling the compiler?
Regards John
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Sergei Gorelkin
> Sent: 19 November 2007 15:50
>
Peter Vreman wrote:
I gave the patch a quick try and the speed stays the same for compiling the
compiler sources. Can
you explain how you did measure the performance gain?
First, I compiled the compiler using -gl switch in order to have
procedure names in logs.
Then I compiled a project (it w
* Andrey Gusev <[EMAIL PROTECTED]> [Fri, 16 Nov 2007 17:35:26 +0300]:
Can anybody explain to me, why dynamically created forms with
TApplicationProperties.OnIdle(),
incline to AV ??? With Delphi it was impeccability !
Please see attached sample. Stack backtrace included.
f
Peter Vreman schrieb:
>> Hello,
>>
>> I have spent some time to profile the compiler using callgrind, and was
>> able to improve its speed by about 20%. Attached are the changes that I
>> made to the sources.
>
> I gave the patch a quick try and the speed stays the same for compiling the
> compil
> Peter Vreman wrote:
>>
>> I gave the patch a quick try and the speed stays the same for compiling the
>> compiler sources.
>> Can
>> you explain how you did measure the performance gain?
>>
> First, I compiled the compiler using -gl switch in order to have
> procedure names in logs.
> Then I com
On Tue, 20 Nov 2007 00:08:20 +0300
Andrey Gusev <[EMAIL PROTECTED]> wrote:
> * Andrey Gusev <[EMAIL PROTECTED]> [Fri, 16 Nov 2007 17:35:26 +0300]:
>
> Can anybody explain to me, why dynamically created forms with
> TApplicationProperties.OnIdle(),
> incline to AV ???
Because the destructor was
> I'm wondering if anybody has sufficient knowledge in this (I don't).
> Many developers that moved over to the dark side (.NET) using
> Delphi.Net or C# always rave about .Net Reflection and how
> much better it is to RTTI.
> Anybody actually know what is better? What limits are they
> talkin
Hi,
I'm wondering if anybody has sufficient knowledge in this (I don't).
Many developers that moved over to the dark side (.NET) using
Delphi.Net or C# always rave about .Net Reflection and how much better
it is to RTTI.
Anybody actually know what is better? What limits are they talking
about in
> (...)
> As far as the information itself that's available through RTTI / Reflection
> is concerned, the type information available in .NET is truly complete, down
> to every field and every method of every type. Also, the ability to
> associate any number of custom attributes with any of the enti
> You forgot to complete: (...) but 99% of time the it just
> makes for useless bloat ;-)
The type information required to make this work is required anyway to a)
support the compilation of IL into machine code b) to allow verification of
type safety and c) support the garbage collector. As such
28 matches
Mail list logo
