- rdnzl-devel@common-lisp.net - mailman3.common-lisp.net

[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

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

15 Sep '06

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

1 0

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

14 Sep '06

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.

2 1

[rdnzl-devel] Handling of static events
by Goffioul Michael 14 Sep '06

14 Sep '06

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.

2 1

RE: [rdnzl-devel] Re: RDNZL and Mono
by Goffioul Michael 07 Sep '06

07 Sep '06

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

1 0

[rdnzl-devel] Re: RDNZL and Mono
by Edi Weitz 07 Sep '06

07 Sep '06

[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(a)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.

1 0