From goffioul at imec.be  Mon Sep  4 09:37:41 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Mon, 4 Sep 2006 11:37:41 +0200
Subject: [rdnzl-devel] FW: [Fwd: example apropos.lisp failed to load in ECL]
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE044821BC@WINEX2.imec.be>

 

________________________________

From: Dean O'Connor [mailto:dean.oconnor at ite.com.au] 
Sent: Wednesday 30 August 2006 17:10
To: Goffioul Michael
Subject: [Fwd: example apropos.lisp failed to load in ECL]


hello michael

I subscribe to the ECL mail list and was having a look at RDNZL. Pretty
cool stuff.
I just noticed an loading error for one of the examples.
I tried to send the below info to the mail list but got rejected cause I
wasn't subscribed - and don't really want to for just this one small
thing.

I assume you are, and was wondering if you'd mind posting this sometime.

ps. I was very impressed by RDNZL. One of the few lisp packages I've
downloaded and run (as per documentation) without hassle in ECL.

cheers
dean.

-------- Original Message -------- 
Subject: 	example apropos.lisp failed to load in ECL	
Date: 	Thu, 31 Aug 2006 00:49:08 +1000	
From: 	Dean O'Connor <dean.oconnor at ite.com.au>
<mailto:dean.oconnor at ite.com.au> 	
To: 	rdnzl-devel at common-lisp.net	


hello just trying out your RDNZL examples with ECL and noticed that
apropos.lisp failed to load.


RDNZL-USER> (load "examples/apropos.lisp")
;;; Loading "F:/projects/lisp/RDNZL-0.10.3/examples/apropos.lisp"
(:CORMANLISP :ECL) is not a valid feature expression.
Broken at LOAD.
RDNZL-USER>>


This change worked for me in ECL.
In function copy-to-clipboard, I changed this line:

	#+(:cormanlisp :ecl) (setq apropos-text (lf-to-crlf
apropos-text))

to this:

	#+(or :cormanlisp :ecl) (setq apropos-text (lf-to-crlf
apropos-text))

Cheers
deano



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20060904/d4a34385/attachment.html>

From edi at agharta.de  Mon Sep  4 10:19:45 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 04 Sep 2006 12:19:45 +0200
Subject: [rdnzl-devel] New version 0.10.4 (Was: example apropos.lisp failed
 to load in ECL)
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE044821BC@WINEX2.imec.be>
	(Goffioul Michael's message of "Mon, 4 Sep 2006 11:37:41 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE044821BC@WINEX2.imec.be>
Message-ID: <uhczoj5mm.fsf@agharta.de>

On Mon, 4 Sep 2006 11:37:41 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> #+(:cormanlisp :ecl) (setq apropos-text (lf-to-crlf apropos-text))

Thanks for spotting that, I've made a new release (0.10.4) which fixes
that.

Download:

  http://weitz.de/files/rdnzl.tar.gz

Note: For now, I'll stop keeping the c-l.net CVS repository in sync
with my local repository as nobody with write access seems to use it
anyway.  If one of you wants to start hacking on RDNZL again, let me
know and I'll re-sync.

Cheers,
Edi.


From edi at agharta.de  Tue Sep  5 14:56:17 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 05 Sep 2006 16:56:17 +0200
Subject: [rdnzl-devel] Re: New version 0.10.4
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04482221@WINEX2.imec.be>
	(Goffioul Michael's message of "Mon, 4 Sep 2006 12:26:03 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04482221@WINEX2.imec.be>
Message-ID: <u1wqqxsz2.fsf@agharta.de>

Hi Michael!

On Mon, 4 Sep 2006 12:26:03 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> BTW, another function improvement idea: I got to a situation where I
> needed to import a type from an assembly whose DLL name didn't match
> the namespace name, hence I couldn't use import-types. However, as
> import-type requires an assembly object, I had to load it manually.
> This is not a big deal, just annoying. Would it be possible to
> provide a more flexible type importing function where you could
> easily decouple the DLL and namespace names? (for instance by adding
> an ":assembly" keyword to the import-types function)

Yeah, I think that should be no big deal.  I can do it, but not in the
next days because I'm busy with other things.  Feel free to submit a
patch (preferably with updated documentation) in the meantime... :)

Cheers,
Edi.


From edi at agharta.de  Thu Sep  7 10:12:46 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 07 Sep 2006 12:12:46 +0200
Subject: [rdnzl-devel] Re: RDNZL and Mono
In-Reply-To: <c159f9ab0609070248y2ad9ed0exb3065e75e02a5107@mail.gmail.com>
	(Juan
	Jose Garcia-Ripoll's message of "Thu, 7 Sep 2006 11:48:07 +0200")
References: <c159f9ab0609070248y2ad9ed0exb3065e75e02a5107@mail.gmail.com>
Message-ID: <uodtsyogx.fsf@agharta.de>

[Sending a copy to the mailing list.  Maybe someone here has more to
say about it.]

On Thu, 7 Sep 2006 11:48:07 +0200, "Juan Jose Garcia-Ripoll" <juanjose.garciaripoll at googlemail.com> wrote:

> Do you think it is doable? Or is the package too Windows specific.

The main point of the DLL which is delivered with RDNZL and which is
kind of a bridge between Lisp and .NET is the fact that it mixes what
Microsoft calls "managed" and "unmanaged" code.  Roughly, from the
Lisp side it looks like plain old C code, and from the .NET side it
looks like, well, .NET code.

AFAIU (but I'm not 100% sure), this can only be done with Microsoft's
C++, and not, e.g., with their C# or one of their other .NET
languages.  There's surely /some/ way to do that with Mono because
Mono is open source and you'll be able to tweak it somehow.  However,
I have no idea how to do that (and no time to do it as well).

I think that at least this shared library must be replaced.
Everything in the Lisp code itself which might be Windows-specific
shouldn't be too hard to port.

Also, I don't know much about Mono, so I can't estimate how useful a
Mono port would be.  The good thing about RDNZL on Windows is that you
have access to the whole operating system including all the GUI stuff.
I guess this is not necessarily the case with Mono.

HTH,
Edi.


From goffioul at imec.be  Thu Sep  7 11:21:31 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Thu, 7 Sep 2006 13:21:31 +0200
Subject: [rdnzl-devel] Re: RDNZL and Mono
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04549583@WINEX2.imec.be>

> > Do you think it is doable? Or is the package too Windows specific.
> 
> The main point of the DLL which is delivered with RDNZL and 
> which is kind of a bridge between Lisp and .NET is the fact 
> that it mixes what Microsoft calls "managed" and "unmanaged" 
> code.  Roughly, from the Lisp side it looks like plain old C 
> code, and from the .NET side it looks like, well, .NET code.
> 
> AFAIU (but I'm not 100% sure), this can only be done with Microsoft's
> C++, and not, e.g., with their C# or one of their other .NET
> languages.  There's surely /some/ way to do that with Mono 
> because Mono is open source and you'll be able to tweak it 
> somehow.  However, I have no idea how to do that (and no time 
> to do it as well).

Just wait a couple of months, I'm sure some GCC solution will
popup :-) (apparently, there were some efforts in that direction
in the context of Google SoC).

Michael.


From goffioul at imec.be  Tue Sep 12 14:44:20 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Tue, 12 Sep 2006 16:44:20 +0200
Subject: [rdnzl-devel] Handling of static events
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE045FAD59@WINEX2.imec.be>

Hi,

I think that the RDNZL syntax does not handle static events correctly.
Indeed, let's imagine I have a class ClassA that defines a static event
EventB, then the following macro expansion is wrong:

ECL-0.9i % (macroexpand '[+ClassA.EventB (rdnzl:new
"System.EventHandler" #'identity)])
(RDNZL:INVOKE "add_ClassA"
              "EventB"
              (RDNZL:NEW "System.EventHandler" #'IDENTITY))

It should expand to

(RDNZL:INVOKE "ClassA"
              "add_EventB"
              (RDNZL:NEW "System.EventHandler" #'IDENTITY))

Michael.


From edi at agharta.de  Thu Sep 14 07:59:24 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Sep 2006 09:59:24 +0200
Subject: [rdnzl-devel] New version 0.10.5 (Was: Handling of static events)
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE045FAD59@WINEX2.imec.be>
	(Goffioul Michael's message of "Tue, 12 Sep 2006 16:44:20 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE045FAD59@WINEX2.imec.be>
Message-ID: <uk6463mlf.fsf@agharta.de>

On Tue, 12 Sep 2006 16:44:20 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> I think that the RDNZL syntax does not handle static events
> correctly.

Yes, you're right.  Thanks for catching that one.

I've made a new release which should fix that.

Cheers,
Edi.


From goffioul at imec.be  Thu Sep 14 08:25:07 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Thu, 14 Sep 2006 10:25:07 +0200
Subject: [rdnzl-devel] Generic types and default thread apartment
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682C73@WINEX2.imec.be>

Hi,

I have 2 small questions:

1) does RDNZL support generic types? If yes, how do I create such an
object
using RDNZL syntax?

2) from a GUI perpective, it would be better to set the apartment state
of the
RDNZL.dll assembly to STA, otherwise various components do not work
properly;
is there a reason to not do it?

Michael.


From edi at agharta.de  Thu Sep 14 08:32:03 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Sep 2006 10:32:03 +0200
Subject: [rdnzl-devel] Generic types and default thread apartment
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682C73@WINEX2.imec.be>
	(Goffioul Michael's message of "Thu, 14 Sep 2006 10:25:07 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682C73@WINEX2.imec.be>
Message-ID: <ufyeu3l30.fsf@agharta.de>

Hi!

On Thu, 14 Sep 2006 10:25:07 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> 1) does RDNZL support generic types? If yes, how do I create such an
> object using RDNZL syntax?

This is something that was introduced in .NET 2.0, right?  No, no
support yet, I haven't even thought about it.  You're welcome to
supply patches, I probably won't find the time to look into this in
the near future.

> 2) from a GUI perpective, it would be better to set the apartment
> state of the RDNZL.dll assembly to STA, otherwise various components
> do not work properly; is there a reason to not do it?

I have to admit that I don't even know what the apartment state of a
DLL is.  Could you tell me what it's for and how I change it?  And
what doesn't work if the state is as it is now?

Thanks,
Edi.


From goffioul at imec.be  Thu Sep 14 09:09:11 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Thu, 14 Sep 2006 11:09:11 +0200
Subject: [rdnzl-devel] Generic types and default thread apartment
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682CFE@WINEX2.imec.be>

> Hi!
> 
> On Thu, 14 Sep 2006 10:25:07 +0200, "Goffioul Michael" 
> <goffioul at imec.be> wrote:
> 
> > 1) does RDNZL support generic types? If yes, how do I 
> create such an 
> > object using RDNZL syntax?
> 
> This is something that was introduced in .NET 2.0, right?  
> No, no support yet, I haven't even thought about it.  You're 
> welcome to supply patches, I probably won't find the time to 
> look into this in the near future.

I had a look and you don't event need a patch :-) Generic objects
can be created on the fly by specifying the parameter type between
brackets, like:

(new "System.Collections.Generic.List`1[System.String]")

If you have 2 type parameters, then use "2" instead of "1" and
separate types with a comma. Of course, RDNZL could provide a wrapper
API to make the syntax simpler, but it's not mandatory.

> > 2) from a GUI perpective, it would be better to set the apartment 
> > state of the RDNZL.dll assembly to STA, otherwise various 
> components 
> > do not work properly; is there a reason to not do it?
> 
> I have to admit that I don't even know what the apartment 
> state of a DLL is.  Could you tell me what it's for and how I 
> change it?  And what doesn't work if the state is as it is now?

I'm not an expert neither, but I think this is related to Interop
and COM. In Single-Thread-Apartment (STA), all COM messages are
processed
in the same thread, while in Multi-Thread-Apartment (MTA, the default
in .NET if you don't specify anything) COM objects can be accessed by
multiple concurrent threads. In GUI, even in multithread application,
the GUI (message loop) must run in a single thread, I guess that's why
STA is preferable in Windows Forms application (In Visual Studio 2005,
when you use the wizard to start a GUI application, it set the threading
model to STA by default).

Now about the effects, I think that some .NET components are simply
based on existing COM components (which is hidden to the user). At least
I
had problems with common dialogs: the directory dialog and the file
dialog.
When using MTA, the directory selection dialog does not show the
directory
tree, and the file dialog does not list items correctly (for instance,
"My Computer" is empty, or the dialog does not update itself when you
change
the filter).

Try this (tried with .NET 2):

(rdnzl:enable-rdnzl-syntax)
(rdnzl:import-types "System.Windows.Forms" "FolderBrowserDialog")
(setq dlg (rdnzl:new "System.Windows.Forms.FolderBrowserDialog"))
[ShowDialog dlg]

This problem was the cause that made me recompile RDNZL-cpp under
VS2005.
If you look into StdAfx.cpp, you'll see how I changed the apartment
state,
but I don't know if it would work under VC.NET-2003.

Michael.


From edi at agharta.de  Thu Sep 14 17:18:29 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Sep 2006 19:18:29 +0200
Subject: [rdnzl-devel] Generic types and default thread apartment
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682CFE@WINEX2.imec.be>
	(Goffioul Michael's message of "Thu, 14 Sep 2006 11:09:11 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682CFE@WINEX2.imec.be>
Message-ID: <u1wqebc4a.fsf@agharta.de>

On Thu, 14 Sep 2006 11:09:11 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> I had a look and you don't event need a patch :-) Generic objects
> can be created on the fly by specifying the parameter type between
> brackets, like:
>
> (new "System.Collections.Generic.List`1[System.String]")
>
> If you have 2 type parameters, then use "2" instead of "1" and
> separate types with a comma.

Ah, good... :)

> Of course, RDNZL could provide a wrapper API to make the syntax
> simpler, but it's not mandatory.

Yeah, I'll keep that in mind for a future release.

> I'm not an expert neither, but I think this is related to Interop
> and COM. In Single-Thread-Apartment (STA), all COM messages are
> processed in the same thread, while in Multi-Thread-Apartment (MTA,
> the default in .NET if you don't specify anything) COM objects can
> be accessed by multiple concurrent threads. In GUI, even in
> multithread application, the GUI (message loop) must run in a single
> thread, I guess that's why STA is preferable in Windows Forms
> application (In Visual Studio 2005, when you use the wizard to start
> a GUI application, it set the threading model to STA by default).
>
> Now about the effects, I think that some .NET components are simply
> based on existing COM components (which is hidden to the user). At
> least I had problems with common dialogs: the directory dialog and
> the file dialog.  When using MTA, the directory selection dialog
> does not show the directory tree, and the file dialog does not list
> items correctly (for instance, "My Computer" is empty, or the dialog
> does not update itself when you change the filter).
>
> Try this (tried with .NET 2):
>
> (rdnzl:enable-rdnzl-syntax)
> (rdnzl:import-types "System.Windows.Forms" "FolderBrowserDialog")
> (setq dlg (rdnzl:new "System.Windows.Forms.FolderBrowserDialog"))
> [ShowDialog dlg]
>
> This problem was the cause that made me recompile RDNZL-cpp under
> VS2005.  If you look into StdAfx.cpp, you'll see how I changed the
> apartment state, but I don't know if it would work under
> VC.NET-2003.

So, do I understand correctly that you already experienced these
problems with the DLL compiled with VS2003?

Thanks,
Edi.


From goffioul at imec.be  Fri Sep 15 08:13:21 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Fri, 15 Sep 2006 10:13:21 +0200
Subject: [rdnzl-devel] Generic types and default thread apartment
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE0468325F@WINEX2.imec.be>


> > Try this (tried with .NET 2):
> >
> > (rdnzl:enable-rdnzl-syntax)
> > (rdnzl:import-types "System.Windows.Forms" "FolderBrowserDialog") 
> > (setq dlg (rdnzl:new "System.Windows.Forms.FolderBrowserDialog"))
> > [ShowDialog dlg]
> >
> > This problem was the cause that made me recompile RDNZL-cpp under 
> > VS2005.  If you look into StdAfx.cpp, you'll see how I changed the 
> > apartment state, but I don't know if it would work under 
> VC.NET-2003.
> 
> So, do I understand correctly that you already experienced 
> these problems with the DLL compiled with VS2003?

Yes. But this is not related to VS2003 itself. It just happened that
I needed to modify the CPP code (to change the default apartment state)
and that I only had VS2005 under the hand; hence I had to port the code
to the new CLI/C++ interface.

Michael.


From edi at agharta.de  Fri Sep 15 08:54:02 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 15 Sep 2006 10:54:02 +0200
Subject: [rdnzl-devel] New versions 0.10.6 / 0.5.1 (Was: Generic types and
 default thread apartment)
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682CFE@WINEX2.imec.be>
	(Goffioul Michael's message of "Thu, 14 Sep 2006 11:09:11 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682CFE@WINEX2.imec.be>
Message-ID: <uy7slzf11.fsf@agharta.de>

On Thu, 14 Sep 2006 11:09:11 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> If you look into StdAfx.cpp, you'll see how I changed the apartment
> state, but I don't know if it would work under VC.NET-2003.

OK, I just copied that and it seems to work fine for the old version
as well.  I could also reproduce the FolderBrowserDialog test case you
described.

New version (C++ code and Lisp tarball with the new DLL) are online.

Thanks,
Edi.


From edi at agharta.de  Thu Sep 21 21:24:08 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 21 Sep 2006 23:24:08 +0200
Subject: [rdnzl-devel] Generic types and default thread apartment
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682CFE@WINEX2.imec.be>
	(Goffioul Michael's message of "Thu, 14 Sep 2006 11:09:11 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04682CFE@WINEX2.imec.be>
Message-ID: <uu03029s7.fsf@agharta.de>

On Thu, 14 Sep 2006 11:09:11 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> I'm not an expert neither, but I think this is related to Interop
> and COM. In Single-Thread-Apartment (STA), all COM messages are
> processed in the same thread, while in Multi-Thread-Apartment (MTA,
> the default in .NET if you don't specify anything) COM objects can
> be accessed by multiple concurrent threads. In GUI, even in
> multithread application, the GUI (message loop) must run in a single
> thread, I guess that's why STA is preferable in Windows Forms
> application (In Visual Studio 2005, when you use the wizard to start
> a GUI application, it set the threading model to STA by default).

Just FYI - this change (RDNZL 0.10.6) also resolves the old issue
mentioned here

  http://common-lisp.net/pipermail/rdnzl-devel/2005-December/000041.html

for AllegroCL.  For LispWorks 4.4.6 you can find a workaround in the
mailing list, for LispWorks 5.0 and Corman Lisp you don't need a fix.


From edi at agharta.de  Thu Sep 21 22:14:30 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 22 Sep 2006 00:14:30 +0200
Subject: [rdnzl-devel] Re: FW: Problem loading load.lisp in ACL 7.0
In-Reply-To: <F0156184B564C14B9F3CE33714B442EA2D9C3A@cadmes01.petroleumplace.com>
	(Andrew Tuttle's message of "Thu, 21 Sep 2006 14:08:37 -0600")
References: <F0156184B564C14B9F3CE33714B442EA2D9C3A@cadmes01.petroleumplace.com>
Message-ID: <uhcz0yiih.fsf@agharta.de>

On Thu, 21 Sep 2006 14:08:37 -0600, "Tuttle, Andrew" <ATuttle at p2es.com> wrote:

> I tried to send this to the mailing list, but it said I'm not
> allowed to do that :-)

You have to be subscribed to send messages to the list - like with
almost every other mailing list.

> Do you have any suggestions?

Subscribe... :)

Seriously, I have the mailing list on Cc, but you probably won't see
the replies unless you are subscribed.

> From: Tuttle, Andrew 
> Sent: Thursday, September 21, 2006 1:59 PM
> To: 'rdnzl-devel at common-lisp.net'
> Subject: Problem loading load.lisp in ACL 7.0
>
> Hi all,
>
> When I try to load the file load.lsp, ACL7 crashes on me. I've
> narrowed it down to the call to DllEnsureInit. Has anyone seen this
> behavior?

Not me, but I don't have ACL7 anymore.  Can't you use ACL8?

> I noticed from the change log file that there may have been a recent
> change made to that function involving "STA"?

Yeah.  I wonder how this could affect AllegroCL, though.

> I have RDNZL.dll in the Allegro directory, and it appears to load
> fine.  It's only when the import file comes along that the crash
> happens.

It might be that AllegroCL only really loads the DLL when it comes
across the first FFI call.

Are you sure you have the newest version of the DLL (from RDNZL
0.10.6) in the Allegro directory?  Do you have the same problems if
you use the old DLL?

> I do have VC#.Net 2005 Express edition on my machine. I haven't
> recompiled the DLL; I'm just mentioning that in the off chance that
> the presence of .Net 2.0 could be relevant troubleshooting info.

Both versions of .NET should be able to co-exist peacefully.  I have
VS 2005 on my machine but I still use the DLL compiled with VS 2003
without problems.

Cheers,
Edi.


From edi at agharta.de  Tue Sep 26 13:47:37 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 26 Sep 2006 15:47:37 +0200
Subject: [rdnzl-devel] Re: Problem/crash with RDNZL under ECL
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895B63@WINEX2.imec.be>
	(Goffioul Michael's message of "Tue, 26 Sep 2006 15:24:05 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895B63@WINEX2.imec.be>
Message-ID: <u8xk63fk6.fsf@agharta.de>

[Cc to mailing list.]

Hi Michael!

On Tue, 26 Sep 2006 15:24:05 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> I discovered a crash problem at exit-time due to RDNZL under ECL.  I
> didn't notice it until recently because the application exited
> without notice about the crash. The problem is related to
> DelegateAdapter class and the release callback. It seems that the
> CLR registers an exit-hook function, I guess to run one last time
> the GC to release any allocated resources. DelegateAdapter objects
> are only released during that phase: I tried various combination of
> GC forcing in LISP and CLR, but those objects got never collected,
> except during the exit-hook. The problem is that this exit-hook is
> run after the LISP engine unloading, such that the release callback
> registered in the DelegateAdapter class just points to garbage
> memory.

Ouch...

> I don't know what's going on. I tried various workaround, without
> touching RDNZL code, but couldn't avoid the crash. Currently, the
> only solution I'm left with is to set the invoke and release
> callbacks of DelegateAdapter class to null before exiting and add
> nullity-check code to DelegateAdapter class before calling those
> callbacks.

Seems like a reasonable solution.

> Did you ever have that problem?

No, but I never ran anything under the VS debugger.

> In my case, I can easily reproduce it by running my LISP into the
> Visual Studio debugger and run the apropos example.  On exit, I'm
> warned by the debugger about the access violation. Note that if I
> run the LISP outside the debugger, I'm not notified at all.

I just tried with VS 2003.  I started LispWorks 5.0, then attached the
VS debugger to LW, then loaded RDNZL, then loaded and ran the apropos
example.  Finally, I quit LispWorks.  I didn't get any messages,
though.  Maybe this only happens with .NET 2.0?  Or is it specific to
ECL?  Or do I have to do something else?  I'm not familiar with the VS
debugger.

Nevertheless, it's pretty disturbing that DelegateAdapter objects are
/never/ released... :(

Cheers,
Edi.


From goffioul at imec.be  Tue Sep 26 14:33:50 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Tue, 26 Sep 2006 16:33:50 +0200
Subject: [rdnzl-devel] RE: Problem/crash with RDNZL under ECL
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895C2C@WINEX2.imec.be>

> > In my case, I can easily reproduce it by running my LISP into the 
> > Visual Studio debugger and run the apropos example.  On exit, I'm 
> > warned by the debugger about the access violation. Note 
> that if I run 
> > the LISP outside the debugger, I'm not notified at all.
> 
> I just tried with VS 2003.  I started LispWorks 5.0, then 
> attached the VS debugger to LW, then loaded RDNZL, then 
> loaded and ran the apropos example.  Finally, I quit 
> LispWorks.  I didn't get any messages, though.  Maybe this 
> only happens with .NET 2.0?  Or is it specific to ECL?  Or do 
> I have to do something else?  I'm not familiar with the VS debugger.
> 
> Nevertheless, it's pretty disturbing that DelegateAdapter 
> objects are /never/ released... :(

I don't know if this specific to .NET 2.0. There are so many different
parameters, it's difficult to tell. Can you trace whether your .NET
objects referenced in LISP get collected or not? In the case of the
apropos example, it appears that the KeyPressEventHandler object never
got collected in the LISP world.

Michael.


From edi at agharta.de  Tue Sep 26 18:37:07 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 26 Sep 2006 20:37:07 +0200
Subject: [rdnzl-devel] Re: Problem/crash with RDNZL under ECL
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895C5E@WINEX2.imec.be>
	(Goffioul Michael's message of "Tue, 26 Sep 2006 16:46:36 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895C5E@WINEX2.imec.be>
Message-ID: <uwt7qzd7w.fsf@agharta.de>

[Cc to mailing list.]

On Tue, 26 Sep 2006 16:46:36 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

>> I just tried with VS 2003.  I started LispWorks 5.0, then attached
>> the VS debugger to LW, then loaded RDNZL, then loaded and ran the
>> apropos example.  Finally, I quit LispWorks.  I didn't get any
>> messages, though.  Maybe this only happens with .NET 2.0?  Or is it
>> specific to ECL?  Or do I have to do something else?  I'm not
>> familiar with the VS debugger.
>> 
>> Nevertheless, it's pretty disturbing that DelegateAdapter objects
>> are /never/ released... :(
>
> Maybe you can try to latest binary package for the LISP shell I
> provided at http://sourceforge.net/projects/ecls . For me, it
> crashes at exit when I start the shell and open an existing LISP
> file in the editor.

I can't reproduce that.  I tried with VS 2003 as well as with VS 2005.
In both cases I started VS, then the Lisp shell, then I attached to
the Lisp shell from VS.  Then I opened an existing Lisp source file
from the Lisp shell and afterwards quit the application.

In the case of VS 2005 the debugger window said:

  The program '[3120] lispshell.exe: Managed' has exited with code 0 (0x0).

Hmmm...


From edi at agharta.de  Tue Sep 26 19:49:40 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 26 Sep 2006 21:49:40 +0200
Subject: [rdnzl-devel] Re: Problem/crash with RDNZL under ECL
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895CF7@WINEX2.imec.be>
	(Goffioul Michael's message of "Tue, 26 Sep 2006 17:59:18 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895CF7@WINEX2.imec.be>
Message-ID: <usliez9uz.fsf@agharta.de>

[Cc to mailing list.]

On Tue, 26 Sep 2006 17:59:18 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> For your information, I switched to RDNZL.dll compiled with VS2005
> and I can't reproduce the problem... Even if it does not explain
> everything, at least I have a workaround :-)

Hmm.  Did you experience the crashes with the latest VS2003 DLL?  The
one from 0.10.6?


From edi at agharta.de  Tue Sep 26 21:29:44 2006
From: edi at agharta.de (Edi Weitz)
Date: Tue, 26 Sep 2006 23:29:44 +0200
Subject: [rdnzl-devel] Re: Problem/crash with RDNZL under ECL
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895C2C@WINEX2.imec.be>
	(Goffioul Michael's message of "Tue, 26 Sep 2006 16:33:50 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895C2C@WINEX2.imec.be>
Message-ID: <uejtyz587.fsf@agharta.de>

On Tue, 26 Sep 2006 16:33:50 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> Can you trace whether your .NET objects referenced in LISP get
> collected or not? In the case of the apropos example, it appears
> that the KeyPressEventHandler object never got collected in the LISP
> world.

I tried with LW 5.0, the most recent version of RDNZL (0.10.6) and the
corresponding DLL (created with VS 2003).  If I run the apropos
example and then call (HCL:MARK-AND-SWEEP 3), the KeyPressEventHandler
is clearly collected on the Lisp side.

Methodology: I simply added a PRINT statement to
MAYBE-FREE-CONTAINER-POINTER, so I could see which objects are about
to be handed over to freeDotNetContainer.  Below is the list I got.

But wait - you're talking about ECL, right?  FLAG-FOR-FINALIZATION
isn't yet implemented for ECL, so you can't expect freeDotNetContainer
to be called in this case, can you?

#<RDNZL::CONTAINER System.Type #x1094540> 
#<RDNZL::CONTAINER System.Type #x1094500> 
#<RDNZL::CONTAINER System.Boolean #x10944C0> 
#<RDNZL::CONTAINER AproposGUI.AproposControl #x10944A0> 
#<RDNZL::CONTAINER System.Type #x10944D0> 
#<RDNZL::CONTAINER System.Type #x1094310> 
#<RDNZL::CONTAINER System.Boolean #x10942D0> 
#<RDNZL::CONTAINER System.Windows.Forms.Form #x10940E8> 
#<RDNZL::CONTAINER System.Type #x10942E0> 
#<RDNZL::CONTAINER System.Windows.Forms.DockStyle #x10940B8> 
#<RDNZL::CONTAINER System.Drawing.Size #x1094088> 
#<RDNZL::CONTAINER System.Windows.Forms.Label #x10940C8> 
#<RDNZL::CONTAINER System.Windows.Forms.TextBox #x1094008> 
#<RDNZL::CONTAINER System.Type #x1093F90> 
#<RDNZL::CONTAINER System.Type #x1093FC0> 
#<RDNZL::CONTAINER System.Boolean #x1093E80> 
#<RDNZL::CONTAINER System.Reflection.MethodInfo #x1093EC0> 
#<RDNZL::CONTAINER System.Type #x1093F60> 
#<RDNZL::CONTAINER System.Reflection.ParameterInfo[] #x1093DF0> 
#<RDNZL::CONTAINER System.Int32 #x1093E90> 
#<RDNZL::CONTAINER System.Reflection.ParameterInfo #x1093E30> 
#<RDNZL::CONTAINER System.Reflection.ParameterInfo #x1093D60> 
#<RDNZL::CONTAINER System.Type #x1093E00> 
#<RDNZL::CONTAINER System.Type #x1093DA0> 
#<RDNZL::CONTAINER System.Type #x1093F30> 
#<RDNZL::CONTAINER System.String #x1093D70> 
#<RDNZL::CONTAINER System.Type #x1093D50> 
#<RDNZL::CONTAINER System.Type[] #x1093CE0> 
#<RDNZL::CONTAINER System.String #x1093CA0> 
#<RDNZL::CONTAINER System.String #x1093CB0> 
#<RDNZL::CONTAINER System.String #x1092CE8> 
#<RDNZL::CONTAINER System.Type #x1093D20> 
#<RDNZL::CONTAINER System.Boolean #x10956F8> 
#<RDNZL::CONTAINER RDNZLPrivateAssembly._LispCallback_1 #x1094520> 
#<RDNZL::CONTAINER System.String #x1095718> 
#<RDNZL::CONTAINER System.String #x10954E8> 
#<RDNZL::CONTAINER System.Type #x10954D8> 
#<RDNZL::CONTAINER System.Boolean #x1095268> 
#<RDNZL::CONTAINER System.Type #x1095128> 
#<RDNZL::CONTAINER System.Reflection.MethodInfo #x1094E90> 
#<RDNZL::CONTAINER System.RuntimeMethodHandle #x1095258> 
#<RDNZL::CONTAINER System.IntPtr #x1094D50> 
#<RDNZL::CONTAINER System.Windows.Forms.KeyPressEventHandler #x1095488> 
#<RDNZL::CONTAINER System.Windows.Forms.Control+ControlCollection #x10953C8> 
#<RDNZL::CONTAINER System.Type #x1094E80> 
#<RDNZL::CONTAINER System.Object[] #x1095418> 
#<RDNZL::CONTAINER System.Int32 #x1095508> 
#<RDNZL::CONTAINER System.Object #x1095538> 
#<RDNZL::CONTAINER System.Windows.Forms.KeyPressEventArgs #x1095578> 
#<RDNZL::CONTAINER System.Char #x1094920> 
#<RDNZL::CONTAINER NULL #x1094910> 
#<RDNZL::CONTAINER System.Object[] #x1094970> 
#<RDNZL::CONTAINER System.Int32 #x10949B0> 
#<RDNZL::CONTAINER System.Object #x1095298> 
#<RDNZL::CONTAINER System.Windows.Forms.KeyPressEventArgs #x10952D8> 
#<RDNZL::CONTAINER System.Char #x1095318> 
#<RDNZL::CONTAINER NULL #x1095308> 
#<RDNZL::CONTAINER System.Object[] #x1095368> 
#<RDNZL::CONTAINER System.Int32 #x1095178> 
#<RDNZL::CONTAINER System.Object #x10951A8> 
#<RDNZL::CONTAINER System.Windows.Forms.KeyPressEventArgs #x10951E8> 
#<RDNZL::CONTAINER System.Char #x1095228> 
#<RDNZL::CONTAINER NULL #x1095218> 
#<RDNZL::CONTAINER System.Object[] #x1095048> 
#<RDNZL::CONTAINER System.Int32 #x1095088> 
#<RDNZL::CONTAINER System.Windows.Forms.TextBox #x10950B8> 
#<RDNZL::CONTAINER System.Windows.Forms.KeyPressEventArgs #x1094EB0> 
#<RDNZL::CONTAINER System.Char #x1094EF0> 
#<RDNZL::CONTAINER System.String #x1094F30> 
#<RDNZL::CONTAINER AproposGUI.AproposControl #x1094F60> 
#<RDNZL::CONTAINER System.Windows.Forms.TextBox #x1094D70> 
#<RDNZL::CONTAINER System.Int32 #x1094F90> 
#<RDNZL::CONTAINER System.Int32 #x1094DD0> 
#<RDNZL::CONTAINER System.String #x1094E00> 
#<RDNZL::CONTAINER System.String #x1094DC0> 
#<RDNZL::CONTAINER System.Int32 #x10955B8> 
#<RDNZL::CONTAINER NULL #x1094E50> 


From edi at agharta.de  Tue Sep 26 22:19:32 2006
From: edi at agharta.de (Edi Weitz)
Date: Wed, 27 Sep 2006 00:19:32 +0200
Subject: [rdnzl-devel] New versions 0.10.7 / 0.5.2 (Was: Problem/crash with
 RDNZL under ECL)
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895B63@WINEX2.imec.be>
	(Goffioul Michael's message of "Tue, 26 Sep 2006 15:24:05 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895B63@WINEX2.imec.be>
Message-ID: <u3bae46ff.fsf@agharta.de>

On Tue, 26 Sep 2006 15:24:05 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> Currently, the only solution I'm left with is to set the invoke and
> release callbacks of DelegateAdapter class to null before exiting
> and add nullity-check code to DelegateAdapter class before calling
> those callbacks.

I've released new versions of the Lisp and the C++ code which
implement this - just in case.  Thanks for the suggestion.



From goffioul at imec.be  Wed Sep 27 09:04:09 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Wed, 27 Sep 2006 11:04:09 +0200
Subject: [rdnzl-devel] RE: Problem/crash with RDNZL under ECL
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895EF9@WINEX2.imec.be>

> [Cc to mailing list.]
> 
> On Tue, 26 Sep 2006 17:59:18 +0200, "Goffioul Michael" 
> <goffioul at imec.be> wrote:
> 
> > For your information, I switched to RDNZL.dll compiled with 
> VS2005 and 
> > I can't reproduce the problem... Even if it does not explain 
> > everything, at least I have a workaround :-)
> 
> Hmm.  Did you experience the crashes with the latest VS2003 
> DLL?  The one from 0.10.6?

Yes, but I can't be sure this didn't happen with earlier versions.
Also there have been recent changes in ECL to implement finalizers,
which I'm trying to use in the ECL-port of RDNZL.

Michael.


From goffioul at imec.be  Wed Sep 27 09:09:30 2006
From: goffioul at imec.be (Goffioul Michael)
Date: Wed, 27 Sep 2006 11:09:30 +0200
Subject: [rdnzl-devel] RE: Problem/crash with RDNZL under ECL
Message-ID: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895F04@WINEX2.imec.be>

> > Maybe you can try to latest binary package for the LISP shell I 
> > provided at http://sourceforge.net/projects/ecls . For me, 
> it crashes 
> > at exit when I start the shell and open an existing LISP 
> file in the 
> > editor.
> 
> I can't reproduce that.  I tried with VS 2003 as well as with VS 2005.
> In both cases I started VS, then the Lisp shell, then I 
> attached to the Lisp shell from VS.  Then I opened an 
> existing Lisp source file from the Lisp shell and afterwards 
> quit the application.
> 
> In the case of VS 2005 the debugger window said:
> 
>   The program '[3120] lispshell.exe: Managed' has exited with 
> code 0 (0x0).

Lucky you! :-)
Actually, the RDNZL.dll included in the binary package is the one
compiled with VS2005, not the one provided in RDNZL package. Can you
retry by using your RDNZL.dll instead?

Michael.


From edi at agharta.de  Thu Sep 28 09:21:14 2006
From: edi at agharta.de (Edi Weitz)
Date: Thu, 28 Sep 2006 11:21:14 +0200
Subject: [rdnzl-devel] Re: FW: Problem loading load.lisp in ACL 7.0
In-Reply-To: <F0156184B564C14B9F3CE33714B442EAA3DF4E@cadmes01.petroleumplace.com>
	(Andrew Tuttle's message of "Wed, 27 Sep 2006 15:01:33 -0600")
References: <F0156184B564C14B9F3CE33714B442EAA3DF4E@cadmes01.petroleumplace.com>
Message-ID: <ud59ggxdh.fsf@agharta.de>

[Cc to mailing list.]

On Wed, 27 Sep 2006 15:01:33 -0600, "Tuttle, Andrew" <ATuttle at p2es.com> wrote:

> Just thought I'd let you know that I got RDNZL to work in ACL8.
>
> So it's either ACL7 or the way we have it set up that was causing
> the problem...

Thanks for the info.

If you find out that there's a specific problem with ACL7, let me
know, and I'll try to fix it.


From edi at agharta.de  Sat Sep 30 13:54:45 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 30 Sep 2006 15:54:45 +0200
Subject: [rdnzl-devel] Re: Problem/crash with RDNZL under ECL
In-Reply-To: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895F04@WINEX2.imec.be>
	(Goffioul Michael's message of "Wed, 27 Sep 2006 11:09:30 +0200")
References: <38C0C9E3083ADB42BFFFC6C2A8B012CE04895F04@WINEX2.imec.be>
Message-ID: <ur6xto3x6.fsf@agharta.de>

On Wed, 27 Sep 2006 11:09:30 +0200, "Goffioul Michael" <goffioul at imec.be> wrote:

> Actually, the RDNZL.dll included in the binary package is the one
> compiled with VS2005, not the one provided in RDNZL package. Can you
> retry by using your RDNZL.dll instead?

I did - with strange results.  In this case, the Lisp shell really
crashes if I exit the application, i.e. the Windows crash reporter
window comes up and asks me if I want to send a bug report to
Microsoft.  The "Debug" button in this window does nothing, though.
And VS 2005, if attached to lispshell.exe, still says that the
application exited normally.  However, VS 2003 does catch the error
which is an Access Violation.

Hmm...