From iok at selvaag.no  Wed May  2 07:19:08 2007
From: iok at selvaag.no (Iver Odin Kvello)
Date: Wed, 2 May 2007 09:19:08 +0200
Subject: [rdnzl-devel] New patch for a COPY-CONTAINER operator
Message-ID: <c61534450705020019p31b3710dya21de0356f329f05@mail.gmail.com>

Here are a couple of patches to implement the COPY-CONTAINER operator
I missed. I hope I got things right with the formatting and the diffs
and so forth.

I did test the thing for the getting-the-lease-object problem, and it
worked as it should, in that

  (cast (invoke (cast (copy-container w)
                              "System.MarshalByRefObject")
                     "GetLifetimeService")
           "System.Runtime.Remoting.Lifetime.ILease")

.. will return the correct lease for the remote object w.

A potential issue: I had to rename the copier-function of the
CONTAINER-struct to be able to use the COPY-CONTAINER name. I couldn't
think of a good alternative, and the struct-copy function wasn't
actually in use, so I figured maybe it was ok.

Regards,
Iver Odin Kvello
iok at selvaag.no
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rdnzl-copy-container.patch
Type: application/octet-stream
Size: 2922 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20070502/fb66a05d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rdnzl-cpp-copy-container.patch
Type: application/octet-stream
Size: 1481 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20070502/fb66a05d/attachment-0001.obj>

From edi at agharta.de  Wed May  2 08:05:55 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 02 May 2007 10:05:55 +0200
Subject: [rdnzl-devel] New patch for a COPY-CONTAINER operator
In-Reply-To: <c61534450705020019p31b3710dya21de0356f329f05@mail.gmail.com>
	(Iver Odin Kvello's message of "Wed, 2 May 2007 09:19:08 +0200")
References: <c61534450705020019p31b3710dya21de0356f329f05@mail.gmail.com>
Message-ID: <ups5jlkf0.fsf@agharta.de>

On Wed, 2 May 2007 09:19:08 +0200, "Iver Odin Kvello" <iok at selvaag.no> wrote:

> Here are a couple of patches to implement the COPY-CONTAINER
> operator I missed. I hope I got things right with the formatting and
> the diffs and so forth.

Thanks a lot.  It'll take me a couple of days to review this as I'm
pretty busy with other stuff right now, though.

Cheers,
Edi.


From iok at selvaag.no  Fri May 11 10:13:32 2007
From: iok at selvaag.no (Iver Odin Kvello)
Date: Fri, 11 May 2007 12:13:32 +0200
Subject: [rdnzl-devel] A patch for CAST to enable casting to types from
	assemblies loaded using LoadFrom
Message-ID: <c61534450705110313q6671af5bt39b15acdc115a4a1@mail.gmail.com>

Hello,

Here is another set of patches that fixes a small issue with CAST: the
current CAST uses GetType with an assembly-qualified type-name only,
and therefore will not work with types in an assembly loaded using
System.Reflection.Assembly.LoadFrom and similar. The patch makes CAST
use a Type-object directly if passed one instead of a type-name, like
NEW already did.

That is, one can do

  (setf assembly (invoke "System.Reflection.Assembly" "LoadFrom" url))
  (setf mytype (invoke assembly "GetType" sometypename))
  (cast someobject mytype)

This should be the minimal neccessary support for these kinds of
assemblies in case they are needed for an application.

Regards,
Iver Odin Kvello
iok at selvaag.no
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rdnzl-cast.patch
Type: application/octet-stream
Size: 1736 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20070511/8e8e9970/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rdnzl-cpp-cast.patch
Type: application/octet-stream
Size: 3526 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20070511/8e8e9970/attachment-0001.obj>

From edi at agharta.de  Fri May 18 11:07:43 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 18 May 2007 13:07:43 +0200
Subject: [rdnzl-devel] New releases 0.11.0 and (for C++ code) 0.6.0 (Was:
 New patch for a COPY-CONTAINER operator)
In-Reply-To: <c61534450705020019p31b3710dya21de0356f329f05@mail.gmail.com>
	(Iver Odin Kvello's message of "Wed, 2 May 2007 09:19:08 +0200")
References: <c61534450705020019p31b3710dya21de0356f329f05@mail.gmail.com>
Message-ID: <uy7jm75kw.fsf@agharta.de>

On Wed, 2 May 2007 09:19:08 +0200, "Iver Odin Kvello" <iok at selvaag.no> wrote:

> Here are a couple of patches to implement the COPY-CONTAINER
> operator I missed.

Finally, after a long delay (sorry for that), I've applied both of
your patches and made new releases which are now available for
download.

Thanks a lot,
Edi.


From matt.lamari at gmail.com  Sun May 20 22:35:15 2007
From: matt.lamari at gmail.com (Matthew Lamari)
Date: Sun, 20 May 2007 17:35:15 -0500
Subject: [rdnzl-devel] Possible leak with RDNZL 0.11.0/Lispworks 5
Message-ID: <dc28374b0705201535g63acdb34m250268af7d8ddc0e@mail.gmail.com>

First off, thanks all for such useful bridging software.

I converged on this after seeing leaks in my interactions with a DLL.

My actual leak seems to occur on cast/unbox.  However, in
understanding what I may or may not be doing wrong, I present this
situation:

(loop for i from 0 do (rdnzl::invoke  (rdnzl::invoke "System.Guid"
"NewGuid") "ToString"))

Nothing particularly inherent to Guids, just an example I could find
that returns a string.

This loop sits there eating up Ram in a situation where I'm guessing
it shouldn't.  Putting garbage collects in the middle of its execution
doesn't change this, nor does running GC/clean-down after breaking
out.  I'm talking about post-collect menory usage continously rising.

It stereotypes a situation in my usage pattern of calling into dotnet
and returning strings.

Is there something I'm doing wrong?  An incorrect assumption about dotnet?

Any help appreciated.

Thanks,
Matt


From edi at agharta.de  Sun May 20 23:24:47 2007
From: edi at agharta.de (Edi Weitz)
Date: Mon, 21 May 2007 01:24:47 +0200
Subject: [rdnzl-devel] Possible leak with RDNZL 0.11.0/Lispworks 5
In-Reply-To: <dc28374b0705201535g63acdb34m250268af7d8ddc0e@mail.gmail.com>
	(Matthew Lamari's message of "Sun, 20 May 2007 17:35:15 -0500")
References: <dc28374b0705201535g63acdb34m250268af7d8ddc0e@mail.gmail.com>
Message-ID: <uwsz32i4g.fsf@agharta.de>

On Sun, 20 May 2007 17:35:15 -0500, "Matthew Lamari" <matt.lamari at gmail.com> wrote:

> First off, thanks all for such useful bridging software.

You're welcome... :)

> I converged on this after seeing leaks in my interactions with a
> DLL.
>
> My actual leak seems to occur on cast/unbox.  However, in
> understanding what I may or may not be doing wrong, I present this
> situation:
>
> (loop for i from 0
>       do (rdnzl::invoke (rdnzl::invoke "System.Guid" "NewGuid") "ToString"))

You don't need the double colons - one of them is enough.

> Nothing particularly inherent to Guids, just an example I could find
> that returns a string.
>
> This loop sits there eating up Ram in a situation where I'm guessing
> it shouldn't.  Putting garbage collects in the middle of its
> execution doesn't change this, nor does running GC/clean-down after
> breaking out.  I'm talking about post-collect menory usage
> continously rising.

Are you talking about a "leak" on the Lisp side?  How do you measure
it?  I don't understand how I am supposed to reproduce this.  I just
ran 500,000 iterations of the above and the allocation reported by
(ROOM) is the same before and after the loop.

Cheers,
Edi.


From matt.lamari at gmail.com  Sun May 20 23:30:18 2007
From: matt.lamari at gmail.com (Matthew Lamari)
Date: Sun, 20 May 2007 18:30:18 -0500
Subject: [rdnzl-devel] Possible leak with RDNZL 0.11.0/Lispworks 5
In-Reply-To: <uwsz32i4g.fsf@agharta.de>
References: <dc28374b0705201535g63acdb34m250268af7d8ddc0e@mail.gmail.com>
	<uwsz32i4g.fsf@agharta.de>
Message-ID: <dc28374b0705201630g5ebc42c2la2836ce5e0dafb0b@mail.gmail.com>

Thank you for such a quick response.  I was just typing up a retraction.

"How do you measure it" <-- indeed.  I concur that I have not provided
a basis for reproduction of any issue here, and retract the bug
report.

I need to investigate further, apologise for the interruption, and
thank you for your time.


On 5/20/07, Edi Weitz <edi at agharta.de> wrote:
> On Sun, 20 May 2007 17:35:15 -0500, "Matthew Lamari" <matt.lamari at gmail.com> wrote:
>
> > First off, thanks all for such useful bridging software.
>
> You're welcome... :)
>
> > I converged on this after seeing leaks in my interactions with a
> > DLL.
> >
> > My actual leak seems to occur on cast/unbox.  However, in
> > understanding what I may or may not be doing wrong, I present this
> > situation:
> >
> > (loop for i from 0
> >       do (rdnzl::invoke (rdnzl::invoke "System.Guid" "NewGuid") "ToString"))
>
> You don't need the double colons - one of them is enough.
>
> > Nothing particularly inherent to Guids, just an example I could find
> > that returns a string.
> >
> > This loop sits there eating up Ram in a situation where I'm guessing
> > it shouldn't.  Putting garbage collects in the middle of its
> > execution doesn't change this, nor does running GC/clean-down after
> > breaking out.  I'm talking about post-collect menory usage
> > continously rising.
>
> Are you talking about a "leak" on the Lisp side?  How do you measure
> it?  I don't understand how I am supposed to reproduce this.  I just
> ran 500,000 iterations of the above and the allocation reported by
> (ROOM) is the same before and after the loop.
>
> Cheers,
> Edi.
> _______________________________________________
> rdnzl-devel mailing list
> rdnzl-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
>