Am 07.09.2017 03:48 schrieb "Ryan Joseph" :
>
>
> > On Sep 6, 2017, at 10:20 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > You're missing that FHook was declared as IHook, not THook.
> >
>
> In terms of memory why does it matter how it was declared? The memory was
On Wed, Sep 6, 2017 at 10:17 PM, Ryan Joseph wrote:
>
>> On Sep 6, 2017, at 10:20 PM, Sven Barth via fpc-pascal
>> wrote:
>>
>> You're missing that FHook was declared as IHook, not THook.
>>
>
> In terms of memory why does it matter how it was declared? The memory was
> allocated in Create() so
> On Sep 6, 2017, at 10:20 PM, Sven Barth via fpc-pascal
> wrote:
>
> You're missing that FHook was declared as IHook, not THook.
>
In terms of memory why does it matter how it was declared? The memory was
allocated in Create() so the declaration is just relevant for the assignment of
the n
On 09/06/2017 05:21 PM, Marc Santhoff wrote:
On Mi, 2017-09-06 at 23:06 +0200, Bo Berglund wrote:
On Wed, 06 Sep 2017 22:52:12 +0200, Bo Berglund
wrote:
I have now added extra binary logging to the relaying program only to
find that the data received and processed are missing about 50 k of
th
El 06/09/2017 a las 21:22, Bo Berglund escribió:
Inc(RxTcp, Length(Buf));
SerWrite(FComH, Buf[0], Length(Buf));
Inc(TxSer, Length(Buf));
Where could I be losing incoming serial data?
Hello,
Where do you check that "Length(Buf)" has been sent ?
if SerWrite(FCom
On Mi, 2017-09-06 at 23:06 +0200, Bo Berglund wrote:
> On Wed, 06 Sep 2017 22:52:12 +0200, Bo Berglund
> wrote:
>
> >I have now added extra binary logging to the relaying program only to
> >find that the data received and processed are missing about 50 k of
> >the 1M transmission.
> >Next I will
On Wed, 06 Sep 2017 22:52:12 +0200, Bo Berglund
wrote:
>I have now added extra binary logging to the relaying program only to
>find that the data received and processed are missing about 50 k of
>the 1M transmission.
>Next I will edit serial.pp and up the buffers from 2K to 60K or so.
By the way
On Wed, 06 Sep 2017 22:52:12 +0200, Bo Berglund
wrote:
>Next I will edit serial.pp and up the buffers from 2K to 60K or so.
Question:
If I edit the content of serial.pp (the one that is brought up by
right clicking and "Find declaration") such that it looks like this:
const bufSize= 61440; //
On Wed, 06 Sep 2017 22:27:49 +0200, Marc Santhoff
wrote:
>On Mi, 2017-09-06 at 21:22 +0200, Bo Berglund wrote:
>> Where could I be losing incoming serial data?
>
>Only for completeness:
>
>Can you rule out problems reagrding the hardware side? Mabe there are
>some weak line drivers or a faulty ca
On Mi, 2017-09-06 at 21:22 +0200, Bo Berglund wrote:
> Where could I be losing incoming serial data?
Only for completeness:
Can you rule out problems reagrding the hardware side? Mabe there are
some weak line drivers or a faulty cable involved?
Worth checking, at least.
HTH anyhow,
Marc
_
On Wed, 6 Sep 2017 18:58:57 +, Mark Morgan Lloyd
wrote:
>> Is there some hidden property that makes it possible to increase thisvalue?
>>What is the maximum size one can set it too?
>
>Not that I was responsible for. Refer to the Windows API for any limits.
I might add that the problem manif
On 06/09/17 18:45, Bo Berglund wrote:
I have created a simple application which relays data from anapplication I am
debugging in Windows7 to/from a remotely locatedembedded data system.I use the
built-in fpc Serial unit to handle the serial data and anIndy10 TIdTcpClient
for the network part.D
I have created a simple application which relays data from an
application I am debugging in Windows7 to/from a remotely located
embedded data system.
I use the built-in fpc Serial unit to handle the serial data and an
Indy10 TIdTcpClient for the network part.
Data coming in on the serial port are m
On 2017-09-06 16:27, Tony Whyman wrote:
Is history repeating itself:
Quite likely. It did all sound awfully familiar. :-)
I've now [finally] added this to my "Personal Programming Notes" archive
(yes, I actually have such a file). So hopefully now I will not forget
about the gotcha of memory
On Wed, 6 Sep 2017, Tony Whyman wrote:
Is history repeating itself:
http://lists.freepascal.org/pipermail/fpc-pascal/2016-August/048579.html
Any historian will confirm this :)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
h
Is history repeating itself:
http://lists.freepascal.org/pipermail/fpc-pascal/2016-August/048579.html
On 06/09/17 09:31, Graeme Geldenhuys wrote:
Hi,
Playing with this small sample application to answer another question
in this mailing list, I noticed the sample application has a memory
lea
Am 06.09.2017 17:03 schrieb "Ryan Joseph" :
>
>
> > On Sep 6, 2017, at 8:03 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> >
> > I couldn't call .Free because FHook was a interface reference type of
type IHook, not THook.
>
> But TInterfacedObject is a class isn’t it? Then you call
> On Sep 6, 2017, at 8:03 PM, Graeme Geldenhuys
> wrote:
>
> I couldn't call .Free because FHook was a interface reference type of type
> IHook, not THook.
But TInterfacedObject is a class isn’t it? Then you call FHook := THook.Create;
so a I’d expect a Free(). What am I missing?
type
THoo
On 2017-09-06 11:33, Marcos Douglas B. Santos wrote:
You have resolved just by change FHookInstance
as a class, not an Interface, plus using TAggregatedObject too.
Ah yes, that seems to work too. Many thanks for pointing that out.
So here is another implementation that works with NO memory lea
On 2017-09-06 10:30, Ryan Joseph wrote:
FHook := THook.Create;
so you need a FHook.Free call? The class is THook = class(TInterfacedObject,
IHook) right?
I couldn't call .Free because FHook was a interface reference type of
type IHook, not THook.
Regards,
Graeme
--
fpGUI Toolkit - a cr
On Wed, Sep 6, 2017 at 6:55 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
>
> I can't remember ever [while using Delphi] being forced to implement a
> getter method in the "property ... implements..." line, but it seems that
> is the only way it remove memory leaks under FPC. Weird
On 2017-09-06 10:55, Graeme Geldenhuys wrote:
On 2017-09-06 10:41, Sven Barth via fpc-pascal wrote:
I think THook needs to derive from TAggregatedObject, cause that couples
the reference counting to that of the controlling instance.
That seems to be heading in the right direction, but such a c
Didn’t you say:
FHook := THook.Create;
so you need a FHook.Free call? The class is THook = class(TInterfacedObject,
IHook) right?
> On Sep 6, 2017, at 4:24 PM, Graeme Geldenhuys
> wrote:
>
> I changed the destructor to the code shown below. Just so you know, I tried
> this before I posted
> On Sep 6, 2017, at 4:55 PM, Graeme Geldenhuys
> wrote:
>
> Either way, modifying the example to use a getter method AND
> TAggregatedObject, I managed to get rid of both memory leaks. Here is the
> working [memory leak free] code now:
Does the original code work if you just add the Free()
On 2017-09-06 10:41, Sven Barth via fpc-pascal wrote:
I think THook needs to derive from TAggregatedObject, cause that couples
the reference counting to that of the controlling instance.
That seems to be heading in the right direction, but such a change on
its own doesn't seem to solve the two
Am 06.09.2017 10:31 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
> type
> IHook = interface
> ['{4BCAEDD8-92D8-11E7-88D3-C86000E37EB0}']
> procedure DoIt;
> end;
>
> type
> THook = class(TInterfacedObject, IHook)
> private
> procedure DoIt;
> end;
>
> proced
On 2017-09-06 09:03, Ryan Joseph wrote:
For the sake of discussion can you see why it makes sense that “hook.” syntax
would be implied because the class does indeed supposedly implement the
interface? Everything about the syntax says that the methods in IHook should be
in TBaseClass so I can’t
Am 06.09.2017 10:34 schrieb "Ryan Joseph" :
>
>
> > On Sep 6, 2017, at 2:50 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> >
> > There is NO need to make Hook public, because you can always get access
to that functionality via the Supports() call and get a reference to IHook.
>
> T
On 2017-09-06 09:37, Michael Van Canneyt wrote:
type
TBaseClass = class(TInterfacedObject, IHook)
private
FHook: IHook;
property Hook: IHook read FHook implements IHook;
public
constructor Create;
destructor Destroy; override;
end;
constructor TBaseClass.Create
On Wed, 6 Sep 2017, Graeme Geldenhuys wrote:
Hi,
Playing with this small sample application to answer another question in
this mailing list, I noticed the sample application has a memory leak.
For the life of me I can't see why or how to resolve it.
I tested with FPC 2.6.4, 3.0.2 and 3.0.
> On Sep 6, 2017, at 2:50 PM, Graeme Geldenhuys
> wrote:
>
> There is NO need to make Hook public, because you can always get access to
> that functionality via the Supports() call and get a reference to IHook.
The Supports() call is the key takeaway here.
For the sake of discussion can you
On 2017-09-06 09:19, Graeme Geldenhuys wrote:
For example:
** Compiled with FPC 3.0.2 or FPC 3.0.4 - no line info
The complete sample application is here:
===[ project1.pas ]
program project1;
{$mode objfpc}{$H+}
{$interfaces COM}
type
Hi,
Playing with this small sample application to answer another question in
this mailing list, I noticed the sample application has a memory leak.
For the life of me I can't see why or how to resolve it.
I tested with FPC 2.6.4, 3.0.2 and 3.0.4-rc1 under 64-bit FreeBSD.
On 2017-07-18 09:44, Marco van de Voort wrote:
You can help improve the upcoming 3.0.4 release by downloading and
testing this release.
I've been using FPC 3.0.4 for a while now under 64-bit FreeBSD. I've
noticed that a tracelog with line info generated by the applications are
not working as
On 2017-09-05 05:05, Ryan Joseph wrote:
That’s what I was looking for in terms of a practical use patterns
for “implements properties”. I should have seen that at the start but
I’m still hung up on how it’s implemented.
And to come back to your example in your first post:
// your code
TBase
35 matches
Mail list logo
