Subject: Re: GetReferencedAssemblies - msg#00014

Previous Message by Date: click to view message preview

Re: GetReferencedAssemblies

Hi. > The preferred way to load some more dependant assemblies would be to > use pkg-config (that is -pkg: ncc switch), which would remove the > burden altogether. > > I guess the reason why csc does this is that developer should be aware > what he links his programs to. I guess when you have more dlls but divided into a few bigger modules you are much better off linking just one major dll from each module and not listing them all each time, but I don't know. btw. I have a related question that is not nemerle-specific: when you develop a program under M$.NET and you have dlls in a few subdirectories, is there any possibility to run the program for tests when you compile the dlls during developement? Under mono you can just set MONO_PATH and run it, but MS.NET will not see the dlls until you place them all in one directory or in GAC, which is not practical to do every time you recompile and want to test something. Can this be overriden by some setting ? - lk

Next Message by Date: click to view message preview

Bugs found involving nested interfaces.

This is a multi-part message in MIME format. Hi all, I've recently encountered a bug in Nemerle that involves deriving from a class in a different assembly that derives from a class in a 3rd assembly that implements an interface that is nested and internal to that 3rd assembly. The bug occurred when I was in the process of porting the BooBinding for SharpDevelop over to Nemerle. SharpDevelop defines an abstract class called AbstractOptionPanel that derives from System.Windows.Forms.UserControl. UserControl implements UnsafeNativeMethods+IOleControl and that is part of the problem. UnsafeNativeMethods is an internal class, but IOleControl is a nested public interface. That also led me to a second bug. I can't implement a public interface that is nested in an internal class, but I can in C#. first_2.n in my attachment shows the code. Anyways, in the example in my attachment for the first bug, you can see that I first derive from UserControl in one assembly. Then, in the second assembly I derive from the class in the first assembly, and the compile fails with the error: error: internal compiler error: unbound encoded type System.Windows.Forms.UnsafeNativeMethods+IQuickActivate at Nemerle.Compiler.Util.ice(String msg) at Nemerle.Compiler.TyCodec.decode(LibraryReference lib, SystemMap tenv, Term t) at Nemerle.Compiler._N_lm_decode_ty_31470.decode_ty(Object t) at Nemerle.Collections.List.RevMap(list l, Func1 f) at Nemerle.Collections.List.Map(list l, Func1 f) at Nemerle.Compiler.TyCodec.DecodeTypeBuilder(LibraryReference lib, SystemMap tenv, String s) at Nemerle.Compiler.NetTypeInfo..ctor(LibraryReference lib, Type h) at Nemerle.Compiler.LibraryReference.ConstructTypeInfo(Type reflected_type) at Nemerle.Compiler.NamespaceND.LookupType(list split) at Nemerle.Compiler._N_lm_collect_14557.collect(Object pref, Object res) at Nemerle.Collections.List.FoldLeft(list l, Object acc, Func2 f) at Nemerle.Compiler.GlobalEnv.LookupType(list name, TypeInfo from) at Nemerle.Compiler.GlobalEnv.GetType(list name, TypeInfo from) at Nemerle.Compiler._N_lm_f_31615.f(Object allow_ref, Object t) at Nemerle.Compiler.TEnv.bind(GlobalEnv env, TypeInfo curtc, PType t, Boolean check_parms) at Nemerle.Compiler._N_lm_bind_25864.bind(Object t) at Nemerle.Compiler.TypeBuilder.bind_types() at Nemerle.Compiler.TypeBuilder.Run() at Nemerle.Compiler.Passes.run(list decls) at Nemerle.Compiler.MainClass.do_main() at Nemerle.Compiler.MainClass.Main() I've attached example code. I tried poking around to see what caused the problem but I'm not up to the task. Thanks, Scott Fleckenstein nemerlebug.zip Description: nemerlebug.zip

Previous Message by Thread: click to view message preview

Re: GetReferencedAssemblies

Hi. > The preferred way to load some more dependant assemblies would be to > use pkg-config (that is -pkg: ncc switch), which would remove the > burden altogether. > > I guess the reason why csc does this is that developer should be aware > what he links his programs to. I guess when you have more dlls but divided into a few bigger modules you are much better off linking just one major dll from each module and not listing them all each time, but I don't know. btw. I have a related question that is not nemerle-specific: when you develop a program under M$.NET and you have dlls in a few subdirectories, is there any possibility to run the program for tests when you compile the dlls during developement? Under mono you can just set MONO_PATH and run it, but MS.NET will not see the dlls until you place them all in one directory or in GAC, which is not practical to do every time you recompile and want to test something. Can this be overriden by some setting ? - lk

Next Message by Thread: click to view message preview

Bugs found involving nested interfaces.

This is a multi-part message in MIME format. Hi all, I've recently encountered a bug in Nemerle that involves deriving from a class in a different assembly that derives from a class in a 3rd assembly that implements an interface that is nested and internal to that 3rd assembly. The bug occurred when I was in the process of porting the BooBinding for SharpDevelop over to Nemerle. SharpDevelop defines an abstract class called AbstractOptionPanel that derives from System.Windows.Forms.UserControl. UserControl implements UnsafeNativeMethods+IOleControl and that is part of the problem. UnsafeNativeMethods is an internal class, but IOleControl is a nested public interface. That also led me to a second bug. I can't implement a public interface that is nested in an internal class, but I can in C#. first_2.n in my attachment shows the code. Anyways, in the example in my attachment for the first bug, you can see that I first derive from UserControl in one assembly. Then, in the second assembly I derive from the class in the first assembly, and the compile fails with the error: error: internal compiler error: unbound encoded type System.Windows.Forms.UnsafeNativeMethods+IQuickActivate at Nemerle.Compiler.Util.ice(String msg) at Nemerle.Compiler.TyCodec.decode(LibraryReference lib, SystemMap tenv, Term t) at Nemerle.Compiler._N_lm_decode_ty_31470.decode_ty(Object t) at Nemerle.Collections.List.RevMap(list l, Func1 f) at Nemerle.Collections.List.Map(list l, Func1 f) at Nemerle.Compiler.TyCodec.DecodeTypeBuilder(LibraryReference lib, SystemMap tenv, String s) at Nemerle.Compiler.NetTypeInfo..ctor(LibraryReference lib, Type h) at Nemerle.Compiler.LibraryReference.ConstructTypeInfo(Type reflected_type) at Nemerle.Compiler.NamespaceND.LookupType(list split) at Nemerle.Compiler._N_lm_collect_14557.collect(Object pref, Object res) at Nemerle.Collections.List.FoldLeft(list l, Object acc, Func2 f) at Nemerle.Compiler.GlobalEnv.LookupType(list name, TypeInfo from) at Nemerle.Compiler.GlobalEnv.GetType(list name, TypeInfo from) at Nemerle.Compiler._N_lm_f_31615.f(Object allow_ref, Object t) at Nemerle.Compiler.TEnv.bind(GlobalEnv env, TypeInfo curtc, PType t, Boolean check_parms) at Nemerle.Compiler._N_lm_bind_25864.bind(Object t) at Nemerle.Compiler.TypeBuilder.bind_types() at Nemerle.Compiler.TypeBuilder.Run() at Nemerle.Compiler.Passes.run(list decls) at Nemerle.Compiler.MainClass.do_main() at Nemerle.Compiler.MainClass.Main() I've attached example code. I tried poking around to see what caused the problem but I'm not up to the task. Thanks, Scott Fleckenstein nemerlebug.zip Description: nemerlebug.zip