Subject: Re: Compiling an add-in with generic methods - msg#00060

Previous Message by Date: click to view message preview

Re: Compiling an add-in with generic methods

On Sat, 2005-10-22 at 09:10 +0200, Alejandro Serrano wrote: > John Luke escribiÃ: > > I've tried compiling all MonoDevelop with gmcs, but then it can't load > any plug-in, I don't know why. At first, there was an error with an > specific library load that I managed to resolve, but then any code > completion or code colorizing works. I implied things wouldn't work and that you would have to figure them out for yourself if you go this route. I believe Kamil has already looked into some of them maybe he can provide more insight. But this is not really a good solution, just a temporary hack. > However, I think MD should switch to the 2.0 runtime, because MD 1.0 > will sure target Mono 1.2, that already has generics support and so on, > so everybody could benefit. It is more complicated I think, and I really wouldn't mind doing so myself, but we also have to consider: - apps developed will then depend on 2.0 - are the 2.0 libraries stable and complete and supported - do the mono/mcs maintainers want to support 2.0 at this time - more small things that will delay a possible 1.0 MD release In the past, people have expressed the desire for MD to slow down its reliance on unstable or extremely new dependencies, so I think that is where we stand until all the above and other things is answered to the maintainers' (which is not me) satisfaction.

Next Message by Date: click to view message preview

help me

  Dear SIr, I 've dowloaded the monodevelop package installed in Mandrake Linux version 10.0. But I can not run this software. While trying to run it i get the following error. MonoDevelop:2733): libglade-WARNING **: unknown property `decorated' for class `GtkDialog' (MonoDevelop:2733): libglade-WARNING **: unknown property `gravity' for class `GtkDialog' (MonoDevelop:2733): libglade-WARNING **: unknown property `focus_on_click' for class `GtkButton' (MonoDevelop:2733): libglade-WARNING **: unknown widget class 'GtkExpander' Unable to set value for field expander Unhandled Exception: System.ArgumentException: Object type Gtk.Label cannot be converted to target type: Gtk.Expander Parameter name: val in <0x0016f> System.Reflection.MonoField:SetValue (System.Object obj, System.Object val, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Globalization.CultureInfo culture) in <0x00194> Glade.XML:BindFields (System.Object target, System.Type type) Please help me to rectify this problem. Madhu VT University of Calicut Kerala India _______________________________________________ Monodevelop-list mailing list Monodevelop-list@xxxxxxxxxxxxxxxx http://lists.ximian.com/mailman/listinfo/monodevelop-list

Previous Message by Thread: click to view message preview

Re: Compiling an add-in with generic methods

One more thing to say: I've tried to load an add-in with generics and found an error about Mono.Cecil. I found the Mono.Cecil.dll that MD has is a bit updated, so just changing to gmcs and using the last Mono.Cecil.dll is OK. There are however some other bugs that relate to Cecil that prevents from working. In the same line as Kamil, I think switching to gmcs is not any problem, because code without generics will continue working as usual. But other code could benefit from it. And now we have an stable Mono implementation of generics, it's the time to use it in MD. Maybe Generic C# add-in has to wait, but that's a complete different problem. So, I think as community, we should take a step (and we won't have any problem with backwards compatibility, as MD 0.8 needs at least Mono 1.1.9, which already has generic support) and change to gmcs. Noone will loose anything and we could all take advantage from it. Alejandro Kamil Skalski escribió: 2005/10/22, Christian Hergert <christian.hergert@xxxxxxxxx>: It is my understanding that the 2.0 profile libraries are still very incomplete. I wouldn't want to hold addin developers back by limiting what they can use, especially since we are so close to a complete 1.1 I don't get it. 2.0 libraries are supersets of what 1.1 holds, so there is not such thing like "limiting". In fact you allow MUCH more to the developers, apart from using standard 1.1 features, they can use generics, new classes, new methods, etc. etc. profile. Furthermore, 2.0 hasn't even been released by Microsoft yet as Well, are we talking about compiling monodevelop on windows and MS NET. or on mono? Mono has a quite stable implementation of generics and other .NET 2.0 features. And increasing the availability of them to developers could cause people to report more bugreports to mono team and implement the lacking functionality. a stable platform. It just sounds like even more problems to start with. Lets fix the bugs we have now to make the platform actually stable before we add more craziness to it. Ok, this is a valid argument. This is the place for core developers to decide if they want more time on stabilization or jump into new possibilities. I would like to say once again, that switching to gmcs should not cause any real issues, since mono already supports it. ~ chris On Sat, 2005-10-22 at 14:17 +0200, Kamil Skalski wrote: As I mentioned in http://lists.ximian.com/pipermail/monodevelop-list/2005-October/002564.html I was able to compile and run monodevelop with gmcs and have plugins and code completion up and running (including completion over generic types). I am pretty sure that with a little bit more effort (compiling all libraries like monodoc using gmcs and then compiling monodevelop against them) it would be possible to switch monodevelop into 2.0 with minimal changes in its sources. There are several problems there: - by default many necessary mono libraries used by monodevelop are compiled targetting 1.0 profile. Moreover, I don't see an easy mechanism for fixing version numbers - for example there are gtk-sharp and gtk-sharp-2.0, which conforms to version changes of Gtk and are completely different story than .NET 1.1/2.0 versions... so the 2.0 profile for gtk would need to be named gtk-sharp2 and gtk-sharp2-2.0, which is ugly. I guess we should bring this issue to the public discussion (maybe also in mono-devel list) - I still have no idea why starting monodevelop compiled with gmcs takes sooooo much time (about 2 minutes) - maybe we should not switch monodevelop to compile only against 2.0 version assemblies (so one could still use some 1.1 libraries when developing monodevelop), but in this case the assemblyreferences loading should be rethinked/redesigned/reimplemented. Besides those technical issues, I don't see any reason why monodevelop should not be switched to 2.0 - mono supports it by default, so there shouldn't be any dependency issues. 2005/10/22, Alejandro Serrano <trupill@xxxxxxxx>: John Luke escribió: Hello, On Fri, 2005-10-21 at 12:43 -0700, Christian Hergert wrote: We are not currently targeting the 2.0 runtime. Therefore, this will not work. You need to use 1.1 profile assemblies only. ~ chris On Fri, 2005-10-21 at 15:49 +0200, Alejandro Serrano wrote: Hi, I need to compile an add-in using the Generics C# Compiler (gmcs) instead of normal mcs. My add-in is using generics methods from a library, so I cannot just use mcs or change to it. My question is: can I compile the add-in with gmcs and MonoDevelop will recognise it? My first attempts were not successful, so I need some help. A more sophisticated answer is that AddIns would have to be loaded in seperate AppDomains for that to be possible. Currently, MonoDevelop loads all addins in one AppDomain. This is simpler and slightly better performing. There is a fairly good presentation from MS on the tradeoffs of these type of things regarding AddIns among the PDC presentations which I can't seem to find right now. So you will either have to wait for MD to switch to 2.0, or try to compile it with gmcs and run it hacking around issues you notice. I've tried compiling all MonoDevelop with gmcs, but then it can't load any plug-in, I don't know why. At first, there was an error with an specific library load that I managed to resolve, but then any code completion or code colorizing works. However, I think MD should switch to the 2.0 runtime, because MD 1.0 will sure target Mono 1.2, that already has generics support and so on, so everybody could benefit. ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es _______________________________________________ Monodevelop-list mailing list Monodevelop-list@xxxxxxxxxxxxxxxx http://lists.ximian.com/mailman/listinfo/monodevelop-list -- Kamil Skalski http://nazgul.omega.pl _______________________________________________ Monodevelop-list mailing list Monodevelop-list@xxxxxxxxxxxxxxxx http://lists.ximian.com/mailman/listinfo/monodevelop-list -- Kamil Skalski http://nazgul.omega.pl ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es

Next Message by Thread: click to view message preview

Re: Compiling an add-in with generic methods

On Sat, 2005-10-22 at 09:10 +0200, Alejandro Serrano wrote: > John Luke escribiÃ: > > I've tried compiling all MonoDevelop with gmcs, but then it can't load > any plug-in, I don't know why. At first, there was an error with an > specific library load that I managed to resolve, but then any code > completion or code colorizing works. I implied things wouldn't work and that you would have to figure them out for yourself if you go this route. I believe Kamil has already looked into some of them maybe he can provide more insight. But this is not really a good solution, just a temporary hack. > However, I think MD should switch to the 2.0 runtime, because MD 1.0 > will sure target Mono 1.2, that already has generics support and so on, > so everybody could benefit. It is more complicated I think, and I really wouldn't mind doing so myself, but we also have to consider: - apps developed will then depend on 2.0 - are the 2.0 libraries stable and complete and supported - do the mono/mcs maintainers want to support 2.0 at this time - more small things that will delay a possible 1.0 MD release In the past, people have expressed the desire for MD to slow down its reliance on unstable or extremely new dependencies, so I think that is where we stand until all the above and other things is answered to the maintainers' (which is not me) satisfaction.