And now the news from VODC Germany
in [Visual Objects]
|
Prev: Vo 2.7 Garbage Collector
Next: CRC32
From: hei_mue on 16 Nov 2006 01:51 Don, Ginny, thank you for the informations. I think I have now all what I need to make a decision... Heiko Mueller
From: rob on 16 Nov 2006 07:54 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. Cheers, Rob Ginny Caughey wrote: > rob, > > >>> Yes you can do the whole CodeDom thing in Vulcan too just as you > >>> suggest. > > Have you worked with CodeDom in Vulcan or C#? > > No, I'm not really a macro sort of person. But Vulcan is just .NET and can > make use of all the .NET classes, and Vulcan includes a CodeDom provider. > > >> As far as I know that's more or less how macros are implemented in Vulcan > >> anyway. But with Vulcan you also have the option of just easily using > >> macros > >> like in VO. > > I seriously doubt that. Are you aware everytime you compile code in > > memory using CodeDom it creates an assembly in memory and the only way > > to unload this assembly would be to compile into seperate application > > domain? If Vulcan is compiling this code every time it is run then you > > are going to have a serious memory leak. > > I don't know the technical details, but I do understand that macros in > 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 > wasteful. I bet the Vulcan runtime is smarter than that since performance > seems to be the #2 goal after compatibility with VO, which is #1. > > Ginny > > > > > Rob > > > > Ginny Caughey wrote: > >> Heiko, > >> > >> Yes you can do the whole CodeDom thing in Vulcan too just as you suggest. > >> As > >> far as I know that's more or less how macros are implemented in Vulcan > >> anyway. But with Vulcan you also have the option of just easily using > >> macros > >> like in VO. > >> > >> -- > >> Ginny > >> > >> > >> "hei_mue" <h.mueller(a)wincontent.de> wrote in message > >> news:1163410811.581495.65600(a)i42g2000cwa.googlegroups.com... > >> > Hi Markus, > >> > > >> > Markus Feser schrieb: > >> >> in Vulcan > >> >> s := "System.Environment.CurrentDirectory" > >> >> ? &s > >> > > >> > This isn't very impressive. Encapsulate the Compiler-Calling in a > >> > simple static method (? is nothing other) is easy. But the allways > >> > available Compilers in .NET can do much more for you... > >> > > >> > Here is a simple Method that creates a Class from Sourcecode that is > >> > consigned as string (think about storing classes in a Database for > >> > really DataDrivern-Applications): > >> > > >> > At First 'How To call this in your own Source'... > >> > > >> > object > >> > oMyObject=ClassHelper.CreateFromSource(sMySource,"TestClass",this,new > >> > ArrayList()) > >> > > >> > And this is the Code (only a smale example - for 'real world use' you > >> > shouldt have to add a better errror-handling (try catch finally): > >> > > >> > public static object CreateFromSource(string sSource, string > >> > sClassName, object oOwner, ArrayList aAssemblies) > >> > { > >> > CodeDomProvider oCompiler = new CSharpCodeProvider(); > >> > CompilerParameters oParameters = new CompilerParameters(); > >> > CompilerResults oResult; > >> > Assembly oAssembly; > >> > object oReturn = null; > >> > > >> > aAssemblies.Add("System.dll"); > >> > aAssemblies.Add("System.Data.dll"); > >> > aAssemblies.Add("System.Xml.dll"); > >> > foreach (string sAssembly in aAssemblies) > >> > { > >> > oParameters.ReferencedAssemblies.Add(sAssembly); > >> > } > >> > oParameters.GenerateInMemory = true; > >> > > >> > oResult = oCompiler.CompileAssemblyFromSource(oParameters, sSource); > >> > > >> > if (oResult.Errors.HasErrors) > >> > { > >> > string sMessage = ""; > >> > sMessage = oResult.Errors.Count.ToString() + " Fehler : "; > >> > for (int x = 0; x < oResult.Errors.Count; x++) > >> > { > >> > sMessage += "\r\nLine : " + oResult.Errors[x].Line.ToString() > >> > + " - " + oResult.Errors[x].ErrorText; > >> > } > >> > MessageBox.Show("Fehler beim erzeugen der Klasse.\r\n"+sMessage); > >> > } > >> > > >> > oAssembly = oResult.CompiledAssembly; > >> > > >> > oReturn = oAssembly.CreateInstance(sClassName, false, > >> > BindingFlags.CreateInstance, null, new object[] { oOwner }, > >> > System.Globalization.CultureInfo.CurrentCulture, null); > >> > if (oReturn == null) > >> > { > >> > MessageBox.Show("Objekt der Klasse "+sClassName+" konnte nicht > >> > erzeugt werden."); > >> > return oReturn; > >> > } > >> > > >> > return oReturn; > >> > } > >> > > >> > As you can see: The CodeDom-Provider in .NET is much more then a simple > >> > ? in VO... > >> > > >> > Heiko Mueller > >> > > >> > PS: Of course you can do all this things in Vulcan (I hope this for > >> > you). Its not Vulcan or C# or whatever - its .NET... > >> > > >
From: Ginny Caughey on 16 Nov 2006 08:05 Rob, You may have missed Don's message indicating that macro support in Vulcan uses a subset of the Vulcan compiler in memory and does not use CodeDom at all. As I understand it, the Vulcan macro compiler is actually more powerful than the VO one. But I also mentioned that I don't choose to use macros myself and I probably won't even with Vulcan's apparently improved macro support compared with VO. -- Ginny "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. > > Cheers, > Rob > > Ginny Caughey wrote: >> rob, >> >> >>> Yes you can do the whole CodeDom thing in Vulcan too just as you >> >>> suggest. >> > Have you worked with CodeDom in Vulcan or C#? >> >> No, I'm not really a macro sort of person. But Vulcan is just .NET and >> can >> make use of all the .NET classes, and Vulcan includes a CodeDom provider. >> >> >> As far as I know that's more or less how macros are implemented in >> >> Vulcan >> >> anyway. But with Vulcan you also have the option of just easily using >> >> macros >> >> like in VO. >> > I seriously doubt that. Are you aware everytime you compile code in >> > memory using CodeDom it creates an assembly in memory and the only way >> > to unload this assembly would be to compile into seperate application >> > domain? If Vulcan is compiling this code every time it is run then you >> > are going to have a serious memory leak. >> >> I don't know the technical details, but I do understand that macros in >> 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 >> wasteful. I bet the Vulcan runtime is smarter than that since performance >> seems to be the #2 goal after compatibility with VO, which is #1. >> >> Ginny >> >> > >> > Rob >> > >> > Ginny Caughey wrote: >> >> Heiko, >> >> >> >> Yes you can do the whole CodeDom thing in Vulcan too just as you >> >> suggest. >> >> As >> >> far as I know that's more or less how macros are implemented in Vulcan >> >> anyway. But with Vulcan you also have the option of just easily using >> >> macros >> >> like in VO. >> >> >> >> -- >> >> Ginny >> >> >> >> >> >> "hei_mue" <h.mueller(a)wincontent.de> wrote in message >> >> news:1163410811.581495.65600(a)i42g2000cwa.googlegroups.com... >> >> > Hi Markus, >> >> > >> >> > Markus Feser schrieb: >> >> >> in Vulcan >> >> >> s := "System.Environment.CurrentDirectory" >> >> >> ? &s >> >> > >> >> > This isn't very impressive. Encapsulate the Compiler-Calling in a >> >> > simple static method (? is nothing other) is easy. But the allways >> >> > available Compilers in .NET can do much more for you... >> >> > >> >> > Here is a simple Method that creates a Class from Sourcecode that is >> >> > consigned as string (think about storing classes in a Database for >> >> > really DataDrivern-Applications): >> >> > >> >> > At First 'How To call this in your own Source'... >> >> > >> >> > object >> >> > oMyObject=ClassHelper.CreateFromSource(sMySource,"TestClass",this,new >> >> > ArrayList()) >> >> > >> >> > And this is the Code (only a smale example - for 'real world use' >> >> > you >> >> > shouldt have to add a better errror-handling (try catch finally): >> >> > >> >> > public static object CreateFromSource(string sSource, string >> >> > sClassName, object oOwner, ArrayList aAssemblies) >> >> > { >> >> > CodeDomProvider oCompiler = new CSharpCodeProvider(); >> >> > CompilerParameters oParameters = new CompilerParameters(); >> >> > CompilerResults oResult; >> >> > Assembly oAssembly; >> >> > object oReturn = null; >> >> > >> >> > aAssemblies.Add("System.dll"); >> >> > aAssemblies.Add("System.Data.dll"); >> >> > aAssemblies.Add("System.Xml.dll"); >> >> > foreach (string sAssembly in aAssemblies) >> >> > { >> >> > oParameters.ReferencedAssemblies.Add(sAssembly); >> >> > } >> >> > oParameters.GenerateInMemory = true; >> >> > >> >> > oResult = oCompiler.CompileAssemblyFromSource(oParameters, >> >> > sSource); >> >> > >> >> > if (oResult.Errors.HasErrors) >> >> > { >> >> > string sMessage = ""; >> >> > sMessage = oResult.Errors.Count.ToString() + " Fehler : "; >> >> > for (int x = 0; x < oResult.Errors.Count; x++) >> >> > { >> >> > sMessage += "\r\nLine : " + >> >> > oResult.Errors[x].Line.ToString() >> >> > + " - " + oResult.Errors[x].ErrorText; >> >> > } >> >> > MessageBox.Show("Fehler beim erzeugen der >> >> > Klasse.\r\n"+sMessage); >> >> > } >> >> > >> >> > oAssembly = oResult.CompiledAssembly; >> >> > >> >> > oReturn = oAssembly.CreateInstance(sClassName, false, >> >> > BindingFlags.CreateInstance, null, new object[] { oOwner }, >> >> > System.Globalization.CultureInfo.CurrentCulture, null); >> >> > if (oReturn == null) >> >> > { >> >> > MessageBox.Show("Objekt der Klasse "+sClassName+" konnte nicht >> >> > erzeugt werden."); >> >> > return oReturn; >> >> > } >> >> > >> >> > return oReturn; >> >> > } >> >> > >> >> > As you can see: The CodeDom-Provider in .NET is much more then a >> >> > simple >> >> > ? in VO... >> >> > >> >> > Heiko Mueller >> >> > >> >> > PS: Of course you can do all this things in Vulcan (I hope this for >> >> > you). Its not Vulcan or C# or whatever - its .NET... >> >> > >> > >
From: Don Caton on 16 Nov 2006 08:42 "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 09:42
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 |