And now the news from VODC Germany
in [Visual Objects]
|
Prev: Vo 2.7 Garbage Collector
Next: CRC32
From: Don Caton on 16 Nov 2006 14:07 "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. What do you mean by "add references to the macro code"? -- Don
From: Ginny Caughey on 16 Nov 2006 14:32 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're describing would be a memory leak though, although >> >> >> > > it >> >> >> > > might be >> >> >> > It's very simple. Everytime you compile a code snippet (in >> >> >> > memory) >> >> >> > using CodeDom it will create/load an Assembly and that assembly >> >> >> > cannot >> >> >> > be unloaded until the Application Domain is shutdown. There are >> >> >> > other >> >> >> > techniques with secondary application domains but I seriously >> >> >> > doubt >> >> >> > Vulcan is taking that approach because of performance issues. >> >> >> >> >> >> Just so there's no misunderstanding... >> >> >> >> >> >> Vulcan's macro compiler does not create temporary assemblies in >> >> >> memory >> >> >> for macros, it creates dynamic methods which do not have the >> >> >> overhead >> >> >> of >> >> >> temporary assemblies. >> >> >> >> >> >> Regarding temporary assemblies, while it is true that they cannot >> >> >> currently be unloaded from an application domain, this is how >> >> >> things >> >> >> work by design. It has nothing to do with a CodeDom; there are >> >> >> several >> >> >> ways you can create a temporary assembly. >> >> >> >> >> >> 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". >> >> >> >> >> >> Also, you may not be aware of it but the C# (and probably all other >> >> >> language) packages in Visual Studio often create temporary >> >> >> assemblies >> >> >> in >> >> >> memory for various reasons. >> >> >> >> >> >> -- >> >> >> Don >> >> > >> > >
From: rob on 16 Nov 2006 15:04 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? Rob Don Caton wrote: > "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. > > What do you mean by "add references to the macro code"? > > -- > Don
From: rob on 16 Nov 2006 15:11 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're describing would be a memory leak though, although > >> >> >> > > it > >> >> >> > > might be > >> >> >> > It's very simple. Everytime you compile a code snippet (in > >> >> >> > memory) > >> >> >> > using CodeDom it will create/load an Assembly and that assembly > >> >> >> > cannot > >> >> >> > be unloaded until the Application Domain is shutdown. There are > >> >> >> > other > >> >> >> > techniques with secondary application domains but I seriously > >> >> >> > doubt > >> >> >> > Vulcan is taking that approach because of performance issues. > >> >> >> > >> >> >> Just so there's no misunderstanding... > >> >> >> > >> >> >> Vulcan's macro compiler does not create temporary assemblies in > >> >> >> memory > >> >> >> for macros, it creates dynamic methods which do not have the > >> >> >> overhead > >> >> >> of > >> >> >> temporary assemblies. > >> >> >> > >> >> >> Regarding temporary assemblies, while it is true that they cannot > >> >> >> currently be unloaded from an application domain, this is how > >> >> >> things > >> >> >> work by design. It has nothing to do with a CodeDom; there are > >> >> >> several > >> >> >> ways you can create a temporary assembly. > >> >> >> > >> >> >> 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". > >> >> >> > >> >> >> Also, you may not be aware of it but the C# (and probably all other > >> >> >> language) packages in Visual Studio often create temporary > >> >> >> assemblies > >> >> >> in > >> >> >> memory for various reasons. > >> >> >> > >> >> >> -- > >> >> >> Don > >> >> > > >> > > >
From: Ginny Caughey on 16 Nov 2006 15:39
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're describing would be a memory leak though, >> >> >> >> > > although >> >> >> >> > > it >> >> >> >> > > might be >> >> >> >> > It's very simple. Everytime you compile a code snippet (in >> >> >> >> > memory) >> >> >> >> > using CodeDom it will create/load an Assembly and that >> >> >> >> > assembly >> >> >> >> > cannot >> >> >> >> > be unloaded until the Application Domain is shutdown. There >> >> >> >> > are >> >> >> >> > other >> >> >> >> > techniques with secondary application domains but I seriously >> >> >> >> > doubt >> >> >> >> > Vulcan is taking that approach because of performance issues. >> >> >> >> >> >> >> >> Just so there's no misunderstanding... >> >> >> >> >> >> >> >> Vulcan's macro compiler does not create temporary assemblies in >> >> >> >> memory >> >> >> >> for macros, it creates dynamic methods which do not have the >> >> >> >> overhead >> >> >> >> of >> >> >> >> temporary assemblies. >> >> >> >> >> >> >> >> Regarding temporary assemblies |