September 2006 - rdnzl-devel@common-lisp.net

[rdnzl-devel] RE: Problem/crash with RDNZL under ECL
by Goffioul Michael 30 Sep '06

30 Sep '06

> > 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.

2 1

[rdnzl-devel] Re: FW: Problem loading load.lisp in ACL 7.0
by Edi Weitz 28 Sep '06

28 Sep '06

[Cc to mailing list.] On Wed, 27 Sep 2006 15:01:33 -0600, "Tuttle, Andrew" <ATuttle(a)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.

1 0

[rdnzl-devel] RE: Problem/crash with RDNZL under ECL
by Goffioul Michael 27 Sep '06

27 Sep '06

> [Cc to mailing list.] > > On Tue, 26 Sep 2006 17:59:18 +0200, "Goffioul Michael" > <goffioul(a)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.

1 0

[rdnzl-devel] New versions 0.10.7 / 0.5.2 (Was: Problem/crash with RDNZL under ECL)
by Edi Weitz 26 Sep '06

26 Sep '06

On Tue, 26 Sep 2006 15:24:05 +0200, "Goffioul Michael" <goffioul(a)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.

1 0

[rdnzl-devel] RE: Problem/crash with RDNZL under ECL
by Goffioul Michael 26 Sep '06

26 Sep '06

> > 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.

2 1

[rdnzl-devel] Re: Problem/crash with RDNZL under ECL
by Edi Weitz 26 Sep '06

26 Sep '06

[Cc to mailing list.] On Tue, 26 Sep 2006 17:59:18 +0200, "Goffioul Michael" <goffioul(a)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?

1 0

[rdnzl-devel] Re: Problem/crash with RDNZL under ECL
by Edi Weitz 26 Sep '06

26 Sep '06

[Cc to mailing list.] On Tue, 26 Sep 2006 16:46:36 +0200, "Goffioul Michael" <goffioul(a)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...

1 0

[rdnzl-devel] Re: Problem/crash with RDNZL under ECL
by Edi Weitz 26 Sep '06

26 Sep '06

[Cc to mailing list.] Hi Michael! On Tue, 26 Sep 2006 15:24:05 +0200, "Goffioul Michael" <goffioul(a)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.

1 0

[rdnzl-devel] Re: FW: Problem loading load.lisp in ACL 7.0
by Edi Weitz 21 Sep '06

21 Sep '06

On Thu, 21 Sep 2006 14:08:37 -0600, "Tuttle, Andrew" <ATuttle(a)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(a)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.

1 0

RE: [rdnzl-devel] Generic types and default thread apartment
by Goffioul Michael 21 Sep '06

21 Sep '06

> Hi! > > On Thu, 14 Sep 2006 10:25:07 +0200, "Goffioul Michael" > <goffioul(a)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.

2 3