And now the news from VODC Germany
in [Visual Objects]
|
Prev: Vo 2.7 Garbage Collector
Next: CRC32
From: rob on 16 Nov 2006 16:22 Ginny, > unable to unload code you no long needed by wrapping the code generation in > a class created in a different app domain, which you can kill as long as you > don't reference it directly from the app domain that you don't want to kill, This is exactly what I have implemented. The only point I was trying to make, because Markus said earlier in this thread to use Vulcan macros (http://groups.google.com/group/comp.lang.clipper.visual-objects/browse_frm/thread/83e2250fe414d209/bc29c019d895d30d?hl=en#bc29c019d895d30d), is that Vulcan macros will NOT allow dynamic execution of ALL .NET code. If one wants to stay in the box of Vulcan syntax then yes use Vulcan macros. Cheers, Rob Ginny Caughey wrote: > Rob, > > I didn't mean to imply there was anything trivial about it. That's my point! > The article however does provide a solution for the situation of being > unable to unload code you no long needed by wrapping the code generation in > a class created in a different app domain, which you can kill as long as you > don't reference it directly from the app domain that you don't want to kill, > and then invoking that code using a proxy. Certainly that's not trivial, and > it's a far cry from what a Vulcan developer would do to use existing VO > macro code in Vulcan, but if you're concerned by memory consumption in your > own VB or C# app, I would think this would be a technique you could use. > > If it's not helpful to you (or anybody else interested in using CodeDom in > their apps), then sorry for wasting your time. Vulcan developers who > currently use VO macros would just use the macro capability of the Vulcan > language and runtime to avoid this sort of complexity as well as the > performance penalty this approach imposes. I'm definitely not recommending > it to the Vulcan community, but it still looks like a solution for C# or VB > developers, if a non-trivial one, and it highlights how much easier macro > support is in a language like Vulcan that supports it natively. > > -- > Ginny > > > "rob" <rob_panosh(a)asdsoftware.com> wrote in message > news:1163707875.355320.226770(a)e3g2000cwe.googlegroups.com... > > Ginny, > > > > Rock climbing looks straight forward also ... but until you try it you > > don't know really how tough it is. Adding dynamic code compiling (like > > in VS) to your application is far from being straight forward and > > trivial. > > > > Rob > > > > Ginny Caughey wrote: > >> Rob, > >> > >> I guess I don't get it because the article looks fairly straightforward, > >> if > >> a bit of code. I'm not sure what you'd want to do that the article didn't > >> cover. > >> > >> -- > >> Ginny > >> > >> > >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message > >> news:1163703287.330813.231920(a)e3g2000cwe.googlegroups.com... > >> > Ginny, > >> > > >> >> http://www.west-wind.com/presentations/DynamicCode/DynamicCode.htm Of > >> >> course > >> >> it's not as easy as just using a Vulcan macro would be, but a solution > >> >> nonetheless. > >> > I don't think you get it. Using your example link above try running > >> > the small code for the link you provided. I would be willing to bet > >> > you CANNOT add references to the macro code. Then at runtime add a > >> > refrence to another another .NET assembly and try to run some of it's > >> > members. > >> > > >> > Rob > >> > > >> > Ginny Caughey wrote: > >> >> Rob, > >> >> > >> >> If it does become a problem for you, this article looks like it > >> >> provides > >> >> a > >> >> good technique for the situation you describe: > >> >> http://www.west-wind.com/presentations/DynamicCode/DynamicCode.htm Of > >> >> course > >> >> it's not as easy as just using a Vulcan macro would be, but a solution > >> >> nonetheless. > >> >> > >> >> -- > >> >> Ginny > >> >> > >> >> > >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message > >> >> news:1163692970.104797.148020(a)e3g2000cwe.googlegroups.com... > >> >> > Ginny, > >> >> > > >> >> > We have not hit the wall yet. We only compile the code when it has > >> >> > changed and in our application and once a user defines their code > >> >> > snippet it rarely changes. > >> >> > > >> >> >>>I would have thought that the dynamic memory manager of .NET would > >> >> >>>swap > >> >> >>>in and out >>for us. > >> >> > Has nothing to do with the dynamic memory manager. In .NET once you > >> >> > load a assembly (by compiling code into memory or read from disk) > >> >> > it > >> >> > cannot be unloaded until you shutdown the application domain. > >> >> > > >> >> > For example this would load 100 assemblies into the curent > >> >> > application > >> >> > domain: > >> >> > > >> >> > For x=1 TO 100 > >> >> > Me._compileResults = > >> >> > _provider.CompileAssemblyFromSource(Me._compileParameters, > >> >> > Me.ProductionSourceCode) > >> >> > Next > >> >> > > >> >> > Rob > >> >> > > >> >> > Ginny Caughey wrote: > >> >> >> Rob, > >> >> >> > >> >> >> Is this a situation you've run into? I would have thought that the > >> >> >> dynamic > >> >> >> memory manager of .NET would swap in and out for us. > >> >> >> > >> >> >> -- > >> >> >> Ginny > >> >> >> > >> >> >> > >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message > >> >> >> news:1163688147.536459.103300(a)h48g2000cwc.googlegroups.com... > >> >> >> > Don, > >> >> >> > > >> >> >> >> You cannot unload an assembly, no matter if it is a "normal" > >> >> >> >> assembly > >> >> >> >> on > >> >> >> >> disk or a temporary assembly in memory. This is not a memory > >> >> >> >> leak, > >> >> >> >> at > >> >> >> >> least not in the generally accepted definition of a "memory > >> >> >> >> leak". > >> >> >> > I understand that ... but if you keep compiling code a new > >> >> >> > assembly > >> >> >> > is > >> >> >> > created and placed into the current appllication domain .... at > >> >> >> > some > >> >> >> > point in time you are going to hit the wall. > >> >> >> > > >> >> >> > Rob > >> >> >> > > >> >> >> > Don Caton wrote: > >> >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message > >> >> >> >> news:1163681686.621166.315850(a)h48g2000cwc.googlegroups.com: > >> >> >> >> > >> >> >> >> > Ginny, > >> >> >> >> > > >> >> >> >> > > Vulcan use a subset of the Vulcan compiler. Strictly > >> >> >> >> > > speaking, > >> >> >> >> > > I > >> >> >> >> > > don't think > >> >> >> >> > > what you'
From: Ginny Caughey on 16 Nov 2006 16:32 Rob, Ok now I understand. I didn't see where you were going with this, I think, because I'm having a really hard time picturing my clients wanting to do such a thing, and obviously they aren't doing it now in VO. -- Ginny "rob" <rob_panosh(a)asdsoftware.com> wrote in message news:1163712178.416550.77000(a)h54g2000cwb.googlegroups.com... > Ginny, > >> unable to unload code you no long needed by wrapping the code generation >> in >> a class created in a different app domain, which you can kill as long as >> you >> don't reference it directly from the app domain that you don't want to >> kill, > This is exactly what I have implemented. The only point I was trying > to make, because Markus said earlier in this thread to use Vulcan > macros > (http://groups.google.com/group/comp.lang.clipper.visual-objects/browse_frm/thread/83e2250fe414d209/bc29c019d895d30d?hl=en#bc29c019d895d30d), > is that Vulcan macros will NOT allow dynamic execution of ALL .NET > code. If one wants to stay in the box of Vulcan syntax then yes use > Vulcan macros. > > Cheers, > Rob > > Ginny Caughey wrote: >> Rob, >> >> I didn't mean to imply there was anything trivial about it. That's my >> point! >> The article however does provide a solution for the situation of being >> unable to unload code you no long needed by wrapping the code generation >> in >> a class created in a different app domain, which you can kill as long as >> you >> don't reference it directly from the app domain that you don't want to >> kill, >> and then invoking that code using a proxy. Certainly that's not trivial, >> and >> it's a far cry from what a Vulcan developer would do to use existing VO >> macro code in Vulcan, but if you're concerned by memory consumption in >> your >> own VB or C# app, I would think this would be a technique you could use. >> >> If it's not helpful to you (or anybody else interested in using CodeDom >> in >> their apps), then sorry for wasting your time. Vulcan developers who >> currently use VO macros would just use the macro capability of the Vulcan >> language and runtime to avoid this sort of complexity as well as the >> performance penalty this approach imposes. I'm definitely not >> recommending >> it to the Vulcan community, but it still looks like a solution for C# or >> VB >> developers, if a non-trivial one, and it highlights how much easier macro >> support is in a language like Vulcan that supports it natively. >> >> -- >> Ginny >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> news:1163707875.355320.226770(a)e3g2000cwe.googlegroups.com... >> > Ginny, >> > >> > Rock climbing looks straight forward also ... but until you try it you >> > don't know really how tough it is. Adding dynamic code compiling (like >> > in VS) to your application is far from being straight forward and >> > trivial. >> > >> > Rob >> > >> > Ginny Caughey wrote: >> >> Rob, >> >> >> >> I guess I don't get it because the article looks fairly >> >> straightforward, >> >> if >> >> a bit of code. I'm not sure what you'd want to do that the article >> >> didn't >> >> cover. >> >> >> >> -- >> >> Ginny >> >> >> >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> >> news:1163703287.330813.231920(a)e3g2000cwe.googlegroups.com... >> >> > Ginny, >> >> > >> >> >> http://www.west-wind.com/presentations/DynamicCode/DynamicCode.htm >> >> >> Of >> >> >> course >> >> >> it's not as easy as just using a Vulcan macro would be, but a >> >> >> solution >> >> >> nonetheless. >> >> > I don't think you get it. Using your example link above try running >> >> > the small code for the link you provided. I would be willing to bet >> >> > you CANNOT add references to the macro code. Then at runtime add a >> >> > refrence to another another .NET assembly and try to run some of >> >> > it's >> >> > members. >> >> > >> >> > Rob >> >> > >> >> > Ginny Caughey wrote: >> >> >> Rob, >> >> >> >> >> >> If it does become a problem for you, this article looks like it >> >> >> provides >> >> >> a >> >> >> good technique for the situation you describe: >> >> >> http://www.west-wind.com/presentations/DynamicCode/DynamicCode.htm >> >> >> Of >> >> >> course >> >> >> it's not as easy as just using a Vulcan macro would be, but a >> >> >> solution >> >> >> nonetheless. >> >> >> >> >> >> -- >> >> >> Ginny >> >> >> >> >> >> >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> >> >> news:1163692970.104797.148020(a)e3g2000cwe.googlegroups.com... >> >> >> > Ginny, >> >> >> > >> >> >> > We have not hit the wall yet. We only compile the code when it >> >> >> > has >> >> >> > changed and in our application and once a user defines their code >> >> >> > snippet it rarely changes. >> >> >> > >> >> >> >>>I would have thought that the dynamic memory manager of .NET >> >> >> >>>would >> >> >> >>>swap >> >> >> >>>in and out >>for us. >> >> >> > Has nothing to do with the dynamic memory manager. In .NET once >> >> >> > you >> >> >> > load a assembly (by compiling code into memory or read from >> >> >> > disk) >> >> >> > it >> >> >> > cannot be unloaded until you shutdown the application domain. >> >> >> > >> >> >> > For example this would load 100 assemblies into the curent >> >> >> > application >> >> >> > domain: >> >> >> > >> >> >> > For x=1 TO 100 >> >> >> > Me._compileResults = >> >> >> > _provider.CompileAssemblyFromSource(Me._compileParameters, >> >> >> > Me.ProductionSourceCode) >> >> >> > Next >> >> >> > >> >> >> > Rob >> >> >> > >> >> >> > Ginny Caughey wrote: >> >> >> >> Rob, >> >> >> >> >> >> >> >> Is this a situation you've run into? I would have thought that >> >> >> >> the >> >> >> >> dynamic >> >> >> >> memory manager of .NET would swap in and out for us. >> >> >> >> >> >> >> >> -- >> >> >> >> Ginny >> >> >> >> >> >> >> >> >> >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> >> >> >> news:1163688147.536459.103300(a)h48g2000cwc.googlegroups.com... >> >> >> >> > Don, >> >> >> >> > >> >> >> >> >> You cannot unload an assembly, no matter if it is a "normal" >> >> >> >> >> assembly >> >> >> >> >> on >> >> >> >> >> disk or a temporary assembly in memory. This is not a memory >> >> >> >> >> leak, >> >> >> >> >> at >> >> >> >> >> least not in the generally accepted definition of a "memory >> >> >> >> >> leak". >> >> >> >> >
From: Don Caton on 16 Nov 2006 21:23 "rob" <rob_panosh(a)asdsoftware.com> wrote in message news:1163707458.365092.200860(a)e3g2000cwe.googlegroups.com: > Don, > > At runtime my users can write code as I do in Visual Studio. They also > have the capability to add references to other .NET assemblies and > invoke members in those assemblies. Can you do that with the macro > compiler in Vulcan? I don't have time to test it right now, but I don't see any reason why you couldn't call Assembly.Load() via a macro. That would load the assembly into the current app domain and make its types available. -- Don
From: Don Caton on 16 Nov 2006 21:30 "rob" <rob_panosh(a)asdsoftware.com> wrote in message news:1163712178.416550.77000(a)h54g2000cwb.googlegroups.com: > Ginny, > > > unable to unload code you no long needed by wrapping the code generation in > > a class created in a different app domain, which you can kill as long as you > > don't reference it directly from the app domain that you don't want to kill, > This is exactly what I have implemented. The only point I was trying > to make, because Markus said earlier in this thread to use Vulcan > macros > (http://groups.google.com/group/comp.lang.clipper.visual-objects/browse_frm/thread/83e2250fe414d209/bc29c019d895d30d?hl=en#bc29c019d895d30d), > is that Vulcan macros will NOT allow dynamic execution of ALL .NET > code. If one wants to stay in the box of Vulcan syntax then yes use > Vulcan macros. Not having used the Vulcan macro compiler, how do you know what it can or cannot do? What is the "box of Vulcan syntax" you are referring to? -- Don
From: Markus Feser on 17 Nov 2006 02:07
> This is exactly what I have implemented. The only point I was trying > to make, because Markus said earlier in this thread to use Vulcan > macros > (http://groups.google.com/group/comp.lang.clipper.visual-objects/browse_frm/thread/83e2250fe414d209/ bc29c019d895d30d?hl=en#bc29c019d895d30d), > is that Vulcan macros will NOT allow dynamic execution of ALL .NET > code. If one wants to stay in the box of Vulcan syntax then yes use > Vulcan macros. Rob, ??? is there an other inherent Markus in this thread, or is my english that bad? Regards, Markus Feser |